- Архитектура системы
- Определенные подмножества субъектов и объектов
- Доверенная компьютерная база
- Периметр безопасности
- Монитор обращений и ядро безопасности
- Политика безопасности
- Принцип наименьших привилегий
Обновлено: 02.05.2010
Проектирование операционной системы «с нуля» – это очень трудная задача со множеством запутанных и абстрактных целей, которые должны быть достигнуты с использованием математики, логики, дизайна, программирования и внедрения. Фундаментальные решения в отношении операционной системы должны быть приняты до начала фактического программирования. Безопасность – это только одна из целей операционной системы, но часто об этой цели беспокоятся только специалисты по безопасности.
Защитные меры, обеспечивающие доступность, целостность и конфиденциальность могут быть реализованы в различных местах. Например, компания может хранить информацию кредитных карт клиентов в базе данных, к которой имеют доступ многие пользователи. Эта информация явно требует защиты, обеспечивающей невозможность несанкционированного доступа и изменения. Мы должны начать с основополагающих, высокоуровневых вопросов, а затем двигаться вниз, в детали. Итак, где должна быть размещена защита? Следует применять средства управления доступом и присваивать права доступа пользователям на этапе их регистрации в системе? Следует ли обеспечивать защиту файлов данных, содержащих информацию кредитных карт, на уровне файловой системы? Следует ли обеспечивать защиту с помощью ограничения для пользователей возможных операций и действий? Или следует использовать комбинацию всего этого? Первый и наиболее глобальный вопрос – это «Где должна быть размещена защита: на стороне пользователей или в месте хранения данных, либо обеспечивать защиту путем ограничения действий пользователей в рамках среды?”. Это проиллюстрировано на рисунке 3-14.
Рисунок 3-14. Безопасность может находиться в трех основных областях
Такие же вопросы следует задавать при построении операционной системы. Когда ответы на эти основополагающие вопросы будут получены, нужно учесть размещение механизмов. Механизмы безопасности могут быть размещены в аппаратных средствах, ядре, операционной системе, службах и на уровне приложений. На каком уровне (уровнях) следует реализовывать механизмы безопасности? Если защита реализована на аппаратном уровне, это обеспечивает широкий диапазон защиты, поскольку на нем базируется безопасность всех компонентов, работающих выше аппаратного уровня. Если механизмы защиты расположены в непосредственной близости от пользователя (на самом высоком уровне архитектуры операционной системы), эти механизмы являются более детальными и узконаправленными, чем механизмы, работающие на более низких уровнях архитектуры.
Как правило, более сложные механизмы защиты обеспечивают меньше гарантий, независимо от их местонахождения в архитектуре операционной системы. Это связано с тем, что более сложные механизмы требуют большей технической квалификации от специалистов, которые их устанавливают, тестируют, поддерживают и эксплуатируют. Более сложные механизмы безопасности сложнее протестировать полностью и во всех возможных условиях. С другой стороны, простые механизмы не всегда могут предоставить богатую функциональность и гибкие настройки, хотя их проще установить, поддерживать, эксплуатировать и тестировать. Таким образом, необходимо хорошо понимать компромисс между функциональностью и гарантиями, чтобы правильно выбрать механизмы безопасности при проектировании системы.
Когда у проектировщики системы поняли, на чем должны фокусироваться механизмы безопасности (пользователи, операции или данные), на каком уровне должны быть размещены эти механизмы (на аппаратном уровне, в ядре, на уровне операционной системы, служб или на уровне приложений), насколько сложен должен быть каждый механизм, им нужно построить и интегрировать эти механизмы таким образом, чтобы они правильно взаимодействовали с другими частями системы.
Сначала команда проектировщиков должна решить, какие системные механизмы будут считаться доверенными и будут размещены на кольце 0. Затем они должны определить, как эти различные части кода будут безопасно взаимодействовать между собой. Хотя, казалось бы, предпочтительно было бы доверять всем компонентам системы, это может быть крайне сложно реализовать, кроме того это может стать «узким местом» с точки зрения производительности. Чтобы быть доверенным, механизм должен работать предсказуемым и безопасным образом, не оказывая неблагоприятного воздействия на другие доверенные и недоверенные механизмы. Доверенные компоненты имеют доступ к привилегированным службам и прямой доступ в память, обычно они имеют высокий приоритет при запросе компьютерного времени, а также обладают большим контролем над системными ресурсами. Поэтому доверенные субъекты и объекты должны быть надлежащим образом идентифицированы, отделены от недоверенных и размещены в определенных подмножествах (subset).
Как было сказано ранее, не все компоненты должны быть доверенными и поэтому не все компоненты попадают в рамки доверенной компьютерной базы (TCB – Trusted Computing Base). TCB определяется как сочетание всех защитных механизмов в рамках компьютерной системы. TCB включает в себя аппаратное и программное обеспечение, а также прошивки (firmware), поскольку все эти компоненты реализуют политику безопасности и не должны нарушать ее.
Компоненты, которые попадают в рамки TCB, должны быть идентифицированы, должны быть определены их стандартные возможности. Например, система, которая не требует высокого уровня доверия, может разрешить всем аутентифицированным пользователям доступ с правом внесения изменений в любые файлы на компьютере. Это широкое подмножество субъектов и объектов, которые свободно взаимодействуют внутри него. Однако система, от которой требуется высокий уровень доверия, может позволить, например, только двум субъектам иметь доступ на чтение ко всем файлам на компьютере, и только одному из них – доступ на изменение любых файлов. Такое подмножество будет гораздо меньше, а правила взаимодействия внутри него будут более строгими и детальными.
Архитектура безопасности – это один из компонентов архитектуры продукта в целом, она предоставляет правила, используемые при проектировании продукта. Архитектура безопасности должна описывать требуемый уровень гарантий и потенциальные воздействия различных этапов разработки продукта на его безопасность. Поскольку проект разработки программного обеспечения переходит от архитектуры к проектированию, затем к техническим требованиям, а затем к разработке кода, архитектура безопасности и требования безопасности становятся более детальными на каждом шаге.Если разработчики хотят разработать систему, соответствующую рейтингу D (очень низкий) классификации уровня гарантий Оранжевой книги, в рамки TCB попадет немного компонентов, т.к. от системы не ожидается очень высокого уровня безопасности. Однако если разработчики хотят разработать систему с рейтингом по Оранжевой книге B1 или B2 (гораздо более высокий, чем D), в рамки TCB попадет гораздо больше компонентов, а разработчики должны будут обеспечить правильное выполнение своих задач всеми этими компонентами. Эти компоненты TCB должны реализовывать жесткие правила, определяющие порядок взаимодействия субъектов и объектов. Разработчикам также нужно убедиться, что все эти компоненты идентифицированы, проконтролированы и работают предсказуемым образом, поскольку все они будут тщательно исследоваться и тестироваться в процессе оценки, прежде чем продукту будет дан рейтинг B2 или B1. (Оранжевая книга будет рассматриваться далее в этом Домене).
Термин «доверенная компьютерная база» (ТСВ), появившийся в Оранжевой Книге, не учитывает обеспечиваемый системой уровень безопасности, он учитывает уровень доверия к системе с точки зрения ее безопасности. Это связано с невозможностью защитить компьютерную систему полностью. Со временем меняются, развиваются и появляются новые виды атак и уязвимостей, поэтому при достаточном количестве времени и объеме ресурсов атака почти на любую систему будет успешной. Однако если система удовлетворяет определенным критериям, считается, что она обеспечивает определенный уровень доверия и будет реагировать предсказуемо в различных ситуациях.
TCB учитывает не только компоненты операционной системы, поскольку компьютер состоит не только из операционной системы. TCB учитывает аппаратное обеспечение, программное обеспечение и прошивки. Каждый из этих компонентов может оказать положительное или отрицательное воздействие на компьютерную среду, каждый из них обеспечивает поддержку и реализацию политики безопасности соответствующей системы. Некоторые компоненты и механизмы напрямую отвечают за поддержку политики безопасности (например, прошивка, которая не позволяет пользователю загрузиться с дискеты, или менеджер памяти, не позволяющий одному процессу напрямую записывать информацию в память другого процесса). Существуют и другие компоненты, которые не реализуют политику безопасности, но они должны соответствовать ей, чтобы не нарушить доверие к системе. Примерами способов нарушения компонентом политики безопасности системы могут быть попытки приложений напрямую обратиться к аппаратному устройству вместо использования соответствующего системного вызова с помощью механизмов операционной системы; попытки программ обратиться к памяти за пределами выделенного им пространства памяти; неправильное освобождение ресурсов программами после окончания их использования.
TCB для многих кажется абстрактной и непонятной концепцией, а множество изданных по этой теме книг и документов не упрощают понимание этого термина. Если операционная система использует TCB, это означает, что она имеет защищенное ядро, отделяющее системные процессы. Ядро состоит из аппаратного обеспечения, программного обеспечения и прошивок – оно, по сути, и является TCB. Но в рамки TCB могут быть включены и другие компоненты, такие как доверенные команды, программы, конфигурационные файлы, напрямую взаимодействующие с ядром. Например, при установке системы Unix администратор может выбрать установку ТСВ, в результате чего будет установлен доверенный канал, доверенная оболочка, а также средства контроля целостности системы. Доверенный канал (trusted path) – это коммуникационный канал взаимодействия между пользователями (или программами) и ядром. ТСВ обеспечивает защиту ресурсов, гарантируя невозможность компрометации этого канала. Доверенная оболочка (trusted shell) гарантирует, что работающий в ней пользователь не сможет выйти за ее пределы, и никто другой (никакой другой процесс) не попадет внутрь нее.
Некоторые команды Unix являются частью ТСВ, например, setupid (установка ID процесса) и setguid (установка группового ID процесса). Только привилегированный пользователь (такой как root) может менять информацию об ID процесса.
Ранние операционные системы (например, MS-DOS, Windows 3.11, Novell Netware версии 3 и т.п.) не имели TCB. Windows 95 имел TCB, но он мог использоваться только при работе в 32-битном режиме. Windows NT был первой версией Windows, в которой реально была реализована идея TCB. Microsoft часто использует слова «Доверенные вычисления» (Trustworthy Computing), но это концепция не принадлежит Microsoft. Многие производители разрабатывают все лучшие и лучшие TCB, создавая новые и совершенствуя существующие методы защиты программного обеспечения от компрометации. Просто Microsoft является первым производителем, внедрившим эти методы в свои продукты Windows 2003. В основном Microsoft строит свои продукты на основе текущей TCB, которую она назвала «Безопасной компьютерной базой нового поколения» (NGSCB – Next-Generation Secure Computing Base). Microsoft переименовала свое ядро безопасности, назвав его «nexus». Организация работы NGSCB выходит за рамки данной книги и экзамена CISSP, в основном операционная система просто делает то, что от нее ожидается, улучшает изоляцию между доверенными и недоверенными процессами, улучшает управление памятью, лучше защищая операции ввода/вывода, улучшает программные механизмы аутентификации.
ПРИМЕЧАНИЕ. Чтобы понять ядро Microsoft Windows 7, посетите страницу http://channel9.msdn.com/shows/Going+Deep/Mark-Russinovich-Inside-Windows-7/Каждая операционная система имеет ряд компонентов, компрометация которых может подвергнуть систему серьезной опасности. TCB предоставляет дополнительные уровни защиты вокруг таких компонентов, чтобы гарантировать невозможность их компрометации и обеспечить постоянную работу системы безопасным и предсказуемым образом.
Как TCB делает все это? Процессы в рамках TCB являются компонентами, защищающими систему в целом. Поэтому разработчики операционной системы должны позаботиться, чтобы эти процессы имели собственный домен выполнения. Это означает, что они размещаются на кольце 0, их команды выполняются в защищенном режиме, а менее доверенные процессы не могут напрямую взаимодействовать с ними. Разработчики должны обеспечить поддержку операционной системой изолированного домена выполнения, чтобы эти процессы не могли быть скомпрометированы или взломаны. Ресурсы, используемые процессами TCB, должны быть также изолированы, для чего должно быть реализовано строгое управление доступом и все запросы на доступ и операции с ресурсами должны надлежащим образом контролироваться.
Четырьмя основными функциями ТСВ являются: активация процессов, переключение доменов выполнения, защита памяти и операции ввода/вывода. Мы уже рассматривали все эти функции в предыдущих разделах без использования точной терминологии, поэтому подведем здесь итог. Активация процесса относится к деятельности, выполняющейся в тот момент, когда процессу нужно передать на обработку процессору свои команды и данные. Как было сказано ранее, процессор заполняет свои регистры информацией запрашивающего процесса (счетчик команд, базовый адрес и адрес границы области памяти, реальный или защищенный режим и т.д.). Процесс «активирован», когда вызвано его прерывание, позволяющее ему взаимодействовать с процессором. Процесс «деактивирован», когда его команды полностью выполнены процессором или когда другой процесс с более высоким приоритетом обратился к процессору. После деактивации процесса, регистры процессора должны быть заполнены новой информацией, относящейся к новому запрашивающему процессу. Данные, которые загружаются в регистры процессора и выгружаются из них, имеют критическое значение, поэтому компоненты TCB должны гарантировать их безопасность.
Переключение домена выполнения производится, когда процессу нужно вызвать другой, более доверенный, процесс, находящийся на более низком кольце защиты. Как объяснялось ранее, менее доверенные процессы работают в реальном режиме и не могут выполнять действия, такие как взаимодействие с аппаратными устройствами или прямая отправка запросов ядру. Процесс, работающий в реальном режиме (кольцо 3) должен делать запрос к службе операционной системы, которая работает на кольце 1. Информация менее доверенного процесса будет загружена в регистры процессора, и затем, когда процессор увидит, что была вызвана служба операционной системы, он переключит домены и контекст безопасности. Соответственно, информация процесса службы операционной системы будет загружена в регистры процессора, и процессор начнет выполнять ее команды в защищенном режиме. Таким образом, переключение домена выполнения – это, по сути, переключение процессора из выполнения команд в реальном режиме в защищенный режим и обратно. Все это должно происходить надлежащим образом, иначе менее доверенный процесс сможет выполняться в защищенном режиме и иметь прямой доступ к системным ресурсам.
Защита памяти и операции ввода/вывода обсуждались в предыдущих разделах, поэтому просто укажем, что за эти операции отвечают компоненты, находящиеся в рамках TCB. Защита достигается путем разделения этой деятельности на отдельные модули, фактически являющиеся процессами, из которых состоит ядро. При этом даже компрометация одного из процессов ядра не означает, что атакующий получит контроль над всеми процессами.
Не каждая часть системы должна быть доверенной. Частью процесса оценки уровня доверия к системе является определение ее архитектуры, служб безопасности и механизмов обеспечения гарантий, которые составляют TCB. В процессе оценки проводится тестирование, которое должно показать, насколько TCB защищен от умышленного и неумышленного воздействия и попыток компрометации. Чтобы достичь высокого рейтинга уровня доверия, системы должны удовлетворять строгим и четким требованиям TCB, а детали их рабочих состояний, этапов разработки, процедур тестирования и документация должны быть проанализированы более детально, чем при оценке систем, пытающихся достичь менее высокого рейтинга уровня доверия.
Использование определенных критериев безопасности позволяет встроить доверие в систему, оценить его и подтвердить. Такой подход дает клиенту метрики, позволяющие ему сравнить один продукт с другим. А производителям это дает четкие инструкции, говорящее им о том, что ожидается от их систем для присвоения им того или иного рейтинга уровня гарантий. Так, если кто-то говорит про систему с рейтингом C2, все остальные понимают, что конкретно под этим подразумевается.
Оранжевая книга – это один из критериев оценки. Она определяет доверенную систему как аппаратное и программное обеспечение, которое в определенной мере защищает классифицированные и неклассифицированные данные для определенного круга пользователей без нарушения прав доступа и политики безопасности. Она рассматривает все защитные механизмы системы, которые реализуют политику безопасности, и обеспечивает предсказуемое поведение среды. Это означает, что каждый следующий уровень системы должен доверять нижестоящим уровням, быть уверенным, что они будут выполнять ожидаемые функции, обеспечивать ожидаемый уровень защиты и работать предсказуемым образом во множестве различных ситуаций. Когда операционная система обращается к аппаратному устройству, она ожидает, что данные будут возвращены им в определенном формате, будут непротиворечивы и предсказуемы. Приложение, которое работает над операционной системой, ожидает наличия возможности делать системные вызовы, получать запрошенные данные, работать в надежной среде. Пользователи ожидают, что аппаратное обеспечение, операционная система и приложения работают одинаковым образом и предоставляют определенный уровень функциональности. Для того, чтобы все эти действия выполнялись предсказуемым образом, требования к системе должны быть учтены на этапе планирования, а не позднее.
Как было сказано ранее, не каждый процесс и ресурс попадает в рамки TCB, поэтому некоторые из этих компонентов находятся вне воображаемых границ, называемых периметром безопасности. Периметр безопасности (security perimeter) – это границы, которые отделяют доверенное от недоверенного. Чтобы система оставалась в безопасном и доверенном состоянии, должны быть разработаны четкие стандарты взаимодействия, гарантирующие, что любое взаимодействие компонента TCB с компонентом вне TCB не может привести к неожиданному нарушению безопасности системы. Такое взаимодействие производится и управляется посредством интерфейсов.
Например, ресурс, находящийся в рамках границ TCB или периметра безопасности, не должен позволить менее доверенным компонентам использовать критичные системные ресурсы. Процесс в рамках TCB также должен заботиться о командах и информации, которые он принимает от менее доверенных ресурсов. Эти ограничения встраиваются в интерфейсы, которые обеспечивают такой вид взаимодействия и являются механизмами, реализующими периметр безопасности. Взаимодействие между доверенными и недоверенными компонентами должно контролироваться для гарантий сохранения системы в стабильном и безопасном состоянии.
ПРИМЕЧАНИЕ. TCB и периметр безопасности являются не физическими сущностями, а концептуальными конструкциями, используемыми разработчиками систем для разделения доверенных и недоверенных компонентов.
Итак, к данному моменту наши разработчики архитектуры компьютерной системы сделали многие вещи. Они определили размещение механизмов безопасности (аппаратное обеспечение, ядро, операционная система, службы или программы), процессы, находящиеся в рамках TCB, а также взаимодействие механизмов безопасности и процессов друг с другом. Они определили периметр безопасности, который разделяет доверенные и недоверенные компоненты. Они разработали интерфейсы для безопасного взаимодействия всех этих сущностей. Теперь им нужно разработать и внедрить механизм, гарантирующий, что субъекты, которые обращаются к объектам, имеют необходимые для этого права. Это означает, что разработчики должны разработать монитор обращений и ядро безопасности.
Монитор обращений (reference monitor) – это абстрактная машина, являющаяся посредником, через которого проходят все обращения субъектов к объектам. Монитор обращений проверяет, что субъекты имеют необходимые права доступа, защищая объекты от несанкционированного доступа и изменения. Чтобы система достигла высокого уровня доверия, необходимо, чтобы субъекты (программы, пользователи и процессы) были полностью авторизованы перед их доступом к объектам (файлам, программам и ресурсам). Субъекту не должно быть позволено использовать запрошенный ресурс, пока ему не будут предоставлены соответствующие привилегии доступа. Монитор обращений – это концепция управления доступом, а не реальный физический компонент, поэтому его часто называют «концепцией монитора обращений» или «абстрактной машиной».
Ядро безопасности (security kernel) состоит из компонентов аппаратного обеспечения, программного обеспечения и прошивок, попадающих в рамки ТСВ и реализующих концепцию монитора обращений. Ядро безопасности осуществляет посредничество при доступе и работе субъектов с объектами. Ядро безопасности – это ядро ТСВ, это наиболее часто используемый подход к построению доверенных компьютерных систем (trusted computing system). Есть три основных требования к ядру безопасности:
- Оно должно обеспечивать изоляцию для процессов, реализующих концепцию монитора обращений, и процессов, которые должны быть защищены от внешних воздействий.
- Оно должно вызываться при каждой попытке доступа, не должно существовать возможностей обойти его.
- Оно должно быть полностью и всесторонне протестировано и проверено.
Хотя эти вопросы и являются абстрактными, они реализуются в реальном мире аппаратных устройств и программного кода. Компоненты, реализуя абстрактную идею монитора обращений, обеспечивают гарантии посредством тестирования и функциональности.
ПРИМЕЧАНИЕ. Монитор обращений – это концепция абстрактной машины, являющейся посредником во всех операциях доступа субъектов к объектам. Ядро безопасности – это аппаратное обеспечение, прошивки и программное обеспечение TCB, реализующее эту концепцию. TCB – это совокупность защитных механизмов компьютера, которые работают совместно для реализации политики безопасности. TCB включает в себя ядро безопасности и все остальные защитные механизмы.Приведем аналогию, показывающую взаимоотношения между процессами ядра, самим ядром и концептуальным монитором обращений. Общество состоит из людей. Представим, что люди – это процессы, а общество – ядро. Члены общества должны общаться между собой определенным образом, чтобы иметь определенные стандарты жизни. Для этого существуют законы. Законы – это монитор обращений, они обеспечивают правильность деятельности. Ожидается, что каждый человек останется в рамках законов и будет действовать определенным образом, чтобы не оказать неблагоприятного воздействия на общество в целом и не поставить под угрозу стандарты жизни. Компоненты в рамках системы должны оставаться в рамках законов монитора обращений, чтобы они не оказали неблагоприятного влияния на другие компоненты и не поставили под угрозу безопасность всей системы.
Ссылки по теме:
- “Rationale Behind the Evaluation Classes”
- The Reference Monitor Concept
- Implementing Complete Mediation
Как было указано ранее, TCB состоит из компонентов, непосредственно реализующих политику безопасности. Но что такое политика безопасности? Политика безопасности – это набор правил и практик, диктующих порядок управления критичной информацией и ресурсами, их защиты и распространения. Политика безопасности точно определяет целевой уровень безопасности и указывает, какие механизмы безопасности предполагается реализовать для его достижения. Это важный элемент, который играет ключевую роль при определении структуры системы. Политика безопасности – это основа для технических требований к системе, она предоставляет базис для оценки системы.
Домен 01 глубоко рассматривает политики безопасности, но эти политики задают направление для всей компании. Политики безопасности, рассматриваемые в настоящем Домене, относятся к операционным системам, устройствам и приложениям. Хотя эти различные политики похожи, они имеют различные цели: цели компании в первом случае и цели отдельной компьютерной системы – во втором.
Система обеспечивает доверие, выполняя и реализуя политику безопасности, контролируя взаимодействие между субъектами и объектами. Политика должна указывать, какие субъекты могут иметь доступ к определенным объектам, какие действия являются приемлемыми, а какие – нет. Политика безопасности дает основу для архитектуры безопасности системы.
Для обеспечения приемлемого уровня доверия, система должна быть основана на архитектуре, способной защитить себя от недоверенных процессов, случайных и преднамеренных нарушений безопасности, атак на разных уровнях системы. Большинство рейтингов доверия, определенных посредством проведения формальных оценок, требуют определения подмножеств субъектов и объектов, явно заданных доменов, изоляции процессов, а также управления их доступом и ведения аудита их действий.
Итак, мы знаем, что доверие к системе определяется тем, как она реализует свою собственную политику безопасности. Когда система протестирована на соответствие определенным критериям, системе присваивается рейтинг, и в дальнейшем этот рейтинг используется покупателями, производителями и компьютерным сообществом в целом. Критерии определяют, обеспечена ли должным образом реализация и поддержка политики безопасности. Политика безопасности основана на правилах и практиках, относящихся к тому, как осуществляется управление системой, ее защита и разрешение доступа к критичным ресурсам. Монитор обращений – это концепция, которая говорит, что все субъекты должны быть надлежащим образом авторизованы для доступа к объектам, эта концепция реализуется ядром безопасности. Ядро безопасности включает в себя все ресурсы, которые контролируют деятельность системы в соответствии с ее политикой безопасности и являются частью операционной системы, управляющей доступом к системным ресурсам. Чтобы ядро безопасности работало правильно, отдельные процессы должны быть изолированы друг от друга, а домены должны быть определены для указания того, какие объекты каким субъектам доступны.
Политики безопасности, которые предотвращают утечку информации с высокого уровня безопасности на более низкий, называются многоуровневыми политиками безопасности (multilevel security policy). Политики такого типа позволяют субъекту получить доступ к объекту, только если уровень безопасности субъекта выше или равен классификации объекта.
Как было указано ранее, рассмотренные в предыдущих разделахконцепции являются абстрактными идеями, которые используются физическими аппаратными компонентами, прошивками, кодом программного обеспечения, а также в процессе деятельности на этапе проектирования, построения и реализации системы. Эти идеи похожи на абстрактные цели и мечты, которые неплохо бы реализовать, путем сложной физической работы и дисциплины.
После обеспечения надлежащей изоляции процессов и ресурсов, необходимо внедрить принцип наименьших привилегий (least privilege). Он означает, что процессы должны иметь не больше привилегий, чем им необходимо для выполнения своих функций. Только процессам, которым необходимо выполнять критичные системные функции, должен быть разрешен доступ к критичным системным ресурсам, а другим, менее привилегированным процессам, при необходимости выполнения таких действий следует обращаться к более привилегированным процессам. Такой вид непрямого взаимодействия защищает систему от плохо написанного и неправильно работающего кода. Процессы должны владеть повышенным уровнем привилегий только в течение того времени, пока действительно существует такая необходимость. Например, если процессу нужно повысить свой статус, чтобы напрямую взаимодействовать с системными ресурсами, то, как только эта задача будет выполнена, статус процесса должен быть обратно понижен, чтобы другие механизмы не могли воспользоваться им для оказания негативного воздействия на систему. В ядре размещаются только процессы, которым необходим полный набор системных привилегий, другие, менее привилегированные процессы, обращаются к ним для выполнения критичных или деликатных операций.
Приведем пример управления доступом на основе принципа наименьших привилегий. Программа резервного копирования должна иметь доступ к файлам только на чтение, доступ на изменение этих файлов ей предоставляться не должен. Аналогично, программе восстановления должна быть позволена только запись в файлы на диске, но не их чтение.
Комментариев нет:
Отправить комментарий