какие существуют подходы к построению защищенной операционной системы
Подходы к построению защищенных ос
Существуют два основных подхода к созданию защищенных операционных систем – фрагментарный и комплексный. При фрагментарном подходе вначале организуется защита от одной угрозы, затем от другой и т.д. Примером фрагментарного подхода может служить ситуация, когда за основу берется незащищенная операционная система (например, Windows 95/98), на нее устанавливаются антивирусный пакет, система шифрования, система регистрации действий пользователей и т.д.
Основной недостаток фрагментарного подхода очевиден – при применении этого подхода подсистема защиты операционной системы представляет собой набор разрозненных программных продуктов, как правило, произведенных разными производителями. Эти программные средства работают независимо друг от друга, организовать их тесное взаимодействие практически невозможно. Кроме того, отдельные элементы такой подсистемы защиты могут некорректно работать в присутствии друг друга, что приводит к резкому снижению надежности системы. Поскольку подсистема защиты, созданная на основе фрагментарного подхода, не является неотьемлемым компонентом операционной системы, при отключении отдельных защитных функций в результате несанкционированных действий пользователя-нарушителя остальные элементы операционной системы продолжают нормально работать, что еще более снижает надежность защиты.
При комплексном подходе к организации защиты системы защитные функции вносятся в операционную систему на этапе проектирования архитектуры операционной системы и являются ее неотъемлемой частью. Отдельные элементы подсистемы защиты, созданной на основе комплексного подхода, тесно взаимодействуют друг с другом при решении различных задач, связанных с организацией защиты информации. Поскольку подсистема защиты разрабатывается и тестируется в совокупности, конфликты между ее отдельными компонентами практически невозможны. Подсистема защиты, созданная на основе комплексного подхода, может быть устроена так, что при фатальных сбоях в функционировании ее ключевых элементов она вызывает крах операционной системы, что не позволяет злоумышленнику отключать защитные функции системы. При использовании фрагментарного подхода такая организация подсистемы защиты невозможна.
Как правило, подсистему защиты операционной системы, создан- ную на основе комплексного подхода, проектируют так, что отдельные ее элементы заменяемы и соответствующие программные модули могут быть заменены другими модулями, реализующими предусмотренный интерфейс взаимодействия соответствующего программного модуля с другими элементами подсистемы защиты.
Основные функции подсистемы защиты операционной системы
Опишем основные функции, выполняемые подсистемой защиты:
идентификация, аутентификация и авторизация;
управление политикой безопасности;
Подсистема защиты практически никогда не представляет собой единый программный модуль. Как правило, каждая из перечисленных функций подсистемы защиты решается одним или несколькими программными модулями. некоторые функции встраиваются непосредственно в ядро операционной системы. Тем не менее должен существовать четко определенный интерфейс между различными модулями подсистемы защиты, используемый при взаимодействии модулей для решения общих задач.
В одних ОС, как в Windows NT/20000, подсистема защиты четко выделяется в общей архитектуре ОС, в других, как UNIX, защитные функции «размазаны» практически по всем элементам операционной системы.
Обычно подсистема защиты ОС допускает свое расширение дополнительными программными модулями.
Тут вы можете оставить комментарий к выбранному абзацу или сообщить об ошибке.
Понятие защищенной ОС
Операционную систему называют защищенной, если она предусматривает средства защиты от основных классов угроз. Защищенная ОС обязательно должна содержать средства разграничения доступа пользователей к своим ресурсам, а также средства проверки подлинности пользователя, начинающего работу с ОС. Кроме того, защищенная ОС должна содержать средства противодействия случайному или преднамеренному выводу ОС из строя.
Если ОС предусматривает защиту не от всех основных классов угроз, а только от некоторых, такую ОС называют частично защищенной.
Подходы к построению защищенных ОС
При применении фрагментарного подхода подсистема защиты ОС представляет собой набор разрозненных программных продуктов, как правило, от разных производителей. Эти программные средства работают независимо друг от друга, при этом практически невозможно организовать их тесное взаимодействие. Кроме того, отдельные элементы такой подсистемы защиты могут некорректно работать в присутствии друг друга, что приводит к резкому снижению надежности системы.
При комплексном подходе защитные функции вносятся в ОС на этапе проектирования архитектуры ОС и являются ее неотъемлемой частью. Отдельные элементы подсистемы защиты, созданной на основе комплексного подхода, тесно взаимодействуют друг с другом при решении различных задач, связанных с организацией защиты информации, поэтому конфликты между ее отдельными компонентами практически невозможны. Подсистема защиты, созданная на основе комплексного подхода, может быть устроена так, что при фатальных сбоях в функционировании ее ключевых элементов она вызывает крах ОС, что не позволяет злоумышленнику отключать защитные функции системы. При фрагментарном подходе такая организация подсистемы защиты невозможна.
Как правило, подсистему защиты ОС, созданную на основе комплексного подхода, проектируют так, чтобы отдельные ее элементы были заменяемы. Соответствующие программные модули могут быть заменены другими модулями.
Понятие защищенной ос. Подходы к построению защищенных ос.
Операционную систему называют защищенной, если она предусматривает средства защиты от основных классов угроз. Защищенная ОС обязательно должна содержать средства разграничения доступа пользователей к своим ресурсам, а также средства проверки подлинности пользователя, начинающего работу с ОС. Кроме того, защищенная ОС должна содержать средства противодействия случайному или преднамеренному выводу ОС из строя.
Если ОС предусматривает защиту не от всех основных классов угроз, а только от некоторых, такую ОС называют частично защищенной.
Подходы к построению защищенных ос
Существуют два основных подхода к созданию защищенных ОС — фрагментарный и комплексный. При фрагментарномподходе вначале организуется защита от одной угрозы, затем от другой и т. д. Примером фрагментарного подхода может служить ситуация, когда за основу берется незащищенная ОС (например, Windows 98), на нее устанавливаются антивирусный пакет, система шифрования, система регистрации действий пользователей и т. д.
При применении фрагментарного подхода подсистема защиты ОС представляет собой набор разрозненных программных продуктов, как правило, от разных производителей. Эти программные средства работают независимо друг от друга, при этом практически невозможно организовать их тесное взаимодействие. Кроме того, отдельные элементы такой подсистемы защиты могут некорректно работать в присутствии друг друга, что приводит к резкому снижению надежности системы.
При комплексном подходе защитные функции вносятся в ОС на этапе проектирования архитектуры ОС и являются ее неотъемлемой частью. Отдельные элементы подсистемы защиты, созданной на основе комплексного подхода, тесно взаимодействуют друг с другом при решении различных задач, связанных с организацией защиты информации, поэтому конфликты между ее отдельными компонентами практически невозможны. Подсистема защиты, созданная на основе комплексного подхода, может быть устроена так, что при фатальных сбоях в функционировании ее ключевых элементов она вызывает крах ОС, что не позволяет злоумышленнику отключать защитные функции системы. При фрагментарном подходе такая организация подсистемы защиты невозможна.
Как правило, подсистему защиты ОС, созданную на основе комплексного подхода, проектируют так, чтобы отдельные ее элементы были заменяемы. Соответствующие программные модули могут быть заменены другими модулями.
Административные меры защиты (ос)
Программно-аппаратные средства защиты ОС обязательно должны дополняться административными мерами защиты. Без постоянной квалифицированной поддержки со стороны администратора даже надежная программно-аппаратная защита может давать сбои. Перечислим основные административные меры защиты. 1. Постоянный контроль корректности функционирования ОС, особенно ее подсистемы защиты. Такой контроль удобно организовать, если ОС поддерживает автоматическую регистрацию наиболее важных событий (event logging) в специальном журнале. 2. Организация и поддержание адекватной политики безопасности. Политики безопасности ОС должна постоянно корректироваться, оперативно реагируя на попытки злоумышленников преодолеть защиту ОС, а также на изменения в конфигурации ОС, установку и удаление прикладных программ. 3. Инструктирование пользователей операционной системы о необходимости соблюдения мер безопасности при работе с ОС и контроль за соблюдением этих мер. 4. Регулярное создание и обновление резервных копий программ и данных ОС. 5. Постоянный контроль изменений в конфигурационных данных и политике безопасности ОС. Информацию об этих изменениях целесообразно хранить на неэлектронных носителях информации, для того чтобы злоумышленнику, преодолевшему защиту ОС, было труднее замаскировать свои несанкционированные действия.
В конкретных ОС могут потребоваться и другие административные меры защиты информации.
Лекция №2
Введение.
Проблема защиты от несанкционированных действий при взаимодействии с внешними сетями может быть успешно решена только на основе комплексной защиты информационных систем. Защищенные операционные системы относятся к базовым средствам многоуровневой комплексной защиты ИС.
Учебные вопросы (основная часть):
1.Проблемы обеспечения безопасности операционных систем.
Большинство программных средств защиты информации являются прикладными программами. Для их выполнения требуется поддержка операционной системы (ОС). Окружение, в котором функционирует ОС, называется доверенной вычислительной базой (ДВБ). ДВБ включает в себя полный набор элементов, обеспечивающих информационную безопасность: операционную систему, программы, сетевое оборудование, средства физической защиты и даже организационные процедуры. Краеугольным камнем этой пирамиды является защищенная операционная система. Без нее доверенная вычислительная база оказывается построенной на песке.
1.1. Угрозы безопасности операционной системы.
Организация эффективной и надежной защиты операционной системы невозможна без предварительного анализа возможных угроз ее безопасности. Угрозы безопасности операционной системы существенно зависят от условий эксплуатации системы, от того, какая информация хранится и обрабатывается в системе. Например, если операционная система используется для организации электронного документооборота, наиболее опасны угрозы, связанные с несанкционированным доступом (НСД) к файлам. Если же операционная система используется как платформа провайдера интернет-услуг, очень опасны атаки на сетевое программное обеспечение операционной системы.
Угрозы безопасности операционной системы можно классифицировать по различным аспектам их реализации.
Классификация угроз по цели атаки:
Классификация угроз по принципу воздействия на операционную систему:
Классификация угроз по типу используемой злоумышленником уязвимости защиты:
Классификация угроз по характеру воздействия на ОС:
Угрозы безопасности ОС можно также классифицировать по таким признакам, как способ действий злоумышленника, используемые средства атаки, объект атаки, способ воздействия на объект атаки, состояние атакуемого объекта ОС на момент атаки.
Операционная система может подвергнуться следующим типичным атакам:
1.2. Понятие защищенной операционной системы.
Операционную систему называют защищенной, если она предусматривает средства защиты от основных классов угроз. Защищенная операционная система обязательно должна содержать средства разграничения доступа пользователей к своим ресурсам, а также средства проверки подлинности пользователя, начинающего работу с операционной системой. Кроме того, защищенная операционная система должна содержать средства противодействия случайному или преднамеренному выводу операционной системы из строя.
Если операционная система предусматривает защиту не от всех основных классов угроз, а только от некоторых, такую ОС называют частично защищенной.
Подходы к построению защищенных операционных систем
Существует два основных подхода к созданию защищенных операционных систем – фрагментарный и комплексный. При фрагментарном подходе вначале организуется защита от одной угрозы, затем от другой.
Примером фрагментарного подхода может служить ситуация, когда за основу берется незащищенная операционная система (например, Windows 98), на нее устанавливают антивирусный пакет, систему шифрования, систему регистрации действий пользователей и т. д.
При применении фрагментарного подхода подсистема защиты операционной системы представляет собой набор разрозненных программных продуктов, как правило, от разных производителей. Эти программные средства работают независимо друг от друга, при этом практически невозможно организовать их тесное взаимодействие. Кроме того, отдельные элементы такой подсистемы защиты могут некорректно работать в присутствии друг друга, что приводит к резкому снижению надежности системы.
При комплексном подходе защитные функции вносятся в операционную систему на этапе проектирования архитектуры операционной системы и являются ее неотъемлемой частью. Отдельные элементы подсистемы защиты, созданной на основе комплексного подхода, тесно взаимодействуют друг с другом при решении различных задач, связанных с организацией защиты информации, поэтому конфликты между ее отдельными компонентами практически невозможны. Подсистема защиты, созданная на основе комплексного подхода, может быть устроена так, что при фатальных сбоях в функционировании ее ключевых элементов она вызывает крах операционной системы, что не позволяет злоумышленнику отключать защитные функции системы. При фрагментарном подходе такая организация подсистемы защиты невозможна.
Как правило, подсистему защиты операционной системы, созданную на основе комплексного подхода, проектируют так, чтобы отдельные ее элементы были заменяемы. Соответствующие программные модули могут быть заменены другими модулями.
Административные меры защиты.
Программно-аппаратные средства защиты операционной системы обязательно должны дополняться административными мерами защиты. Без постоянной квалифицированной поддержки со стороны администратора даже надежная программно-аппаратная защита может давать сбои. Перечислим основные административные меры защиты.
Адекватная политика безопасности.
Выбор и поддержание адекватной политики безопасности являются одной из наиболее важных задач администратора операционной системы. Если принятая в ОС политика безопасности неадекватна, это может привести к несанкционированному доступу злоумышленника к ресурсам системы и к снижению надежности функционирования ОС.
Известно утверждение: чем лучше защищена ОС, тем труднее с ней работать пользователям и администраторам. Это обусловлено следующими факторами:
Оптимальная адекватная политика безопасности – это такая политика безопасности, которая не только не позволяет злоумышленникам выполнять несанкционированные действия, но и не приводит к описанным выше негативным эффектам.
Адекватная политика безопасности определяется не только архитектурой ОС, но и ее конфигурацией, установленными прикладными программами и т. д. Формирование и поддержание адекватной политики безопасности ОС можно разделить на ряд этапов.
Специальных стандартов защищенности операционных систем не существует. Для оценки защищенности операционных систем используются стандарты, разработанные для компьютерных систем вообще. Как правило, сертификация операционной системы по некоторому классу защиты сопровождается составлением требований к адекватной политике безопасности, при безусловном выполнении которой защищенность конкретного экземпляра операционной системы будет соответствовать требованиям соответствующего класса защиты.
2.1. Основные функции подсистемы защиты операционной системы
Подсистема защиты ОС выполняет следующие основные функции:
Подсистема защиты обычно не представляет собой единый программный модуль. Как правило, каждая из перечисленных функций подсистемы защиты решается одним или несколькими программными модулями. Некоторые функции встраиваются непосредственно в ядро ОС. Между различными модулями подсистемы защиты должен существовать четко определенный интерфейс, используемый при взаимодействии модулей для решения общих задач.
2.2. Идентификация, аутентификация и авторизация субъектов доступа.
В защищенной ОС любой пользователь (субъект доступа), перед тем как начать работу с системой, должен пройти идентификацию, аутентификацию и авторизацию.
Идентификация субъекта доступа заключается в том, что пользователь (субъект) сообщает операционной системе идентифицирующую информацию о себе (имя, учетный номер) и таким образом идентифицирует себя.
Для того чтобы установить, что пользователь именно тот, за кого себя выдает, в информационных системах предусмотрена процедура аутентификации, задача которой – предотвращение доступа к системе нежелательных лиц.
Аутентификация субъекта доступа заключается в том, что субъект предоставляет операционной системе, помимо идентифицирующей информации, еще и аутентифицирующую информацию, подтверждающую, что он действительно является тем субъектом доступа, к которому относится идентифицирующая информация.
Авторизация субъекта доступа происходит после успешной идентификации и аутентификации. При авторизации субъекта ОС выполняет действия, необходимые для того, чтобы субъект мог начать работу в системе.
Авторизация субъекта не относится напрямую к подсистеме защиты операционной системы. В процессе авторизации решаются технические задачи, связанные с организацией начала работы в системе уже идентифицированного и аутентифицированного субъекта доступа.
С точки зрения обеспечения безопасности ОС, процедуры идентификации и аутентификации являются весьма ответственными. Действительно, если злоумышленник сумел войти в систему от имени другого пользователя, он легко получает доступ ко всем объектам ОС, к которым имеет доступ этот пользователь. Если при этом подсистема аудита генерирует сообщения о событиях, потенциально опасных для безопасности ОС, то в журнал аудита записывается не имя злоумышленника, а имя пользователя, от имени которого злоумышленник работает в системе.
Наиболее распространенными методами идентификации и аутентификации являются следующие:
2.3. Разграничение доступа к объектам операционной системы.
Основными понятиями процесса разграничения доступа к объектам операционной системы являются объект доступа, метод доступа к объекту и субъект доступа.
Объектом доступа (или просто объектом) называют любой элемент операционной системы, доступ к которому пользователей и других субъектов доступа может быть произвольно ограничен. Возможность доступа к объектам ОС определяется не только архитектурой операционной системы, но и текущей политикой безопасности. Под объектами доступа понимают, как ресурсы оборудования, так и программные ресурсы. В качестве примера ресурсов оборудования можно привести процессор, принтер, жесткие диски и ленты. Каждый объект имеет уникальное имя, отличающее его от других объектов в системе, и может быть доступен через хорошо определенные и значимые операции.
Методом доступа к объекту называется операция, определенная для объекта. Тип операции зависит от объектов. Например, процессор может только выполнять команды, сегменты памяти могут быть записаны и прочитаны, считыватель магнитных карт может только читать, а для файлов могут быть определены методы доступа «чтение», «запись » и «добавление» (дописывание информации в конец файла).
Субъектом доступа называют любую сущность, способную инициировать выполнение операций над объектами (обращаться к объектам по некоторым методам доступа). Обычно полагают, что множество субъектов доступа и множество объектов доступа не пересекаются.
Иногда к субъектам доступа относят процессы, выполняющиеся в системе. Однако логичнее считать субъектом доступа именно пользователя, от имени которого выполняется процесс. Естественно, под субъектом доступа подразумевают не физического пользователя, работающего с компьютером, а «логического», от имени которого выполняются процессы операционной системы.
Таким образом, объект доступа – это то, к чему осуществляется доступ, субъект доступа – это тот, кто осуществляет доступ, и метод доступа – это то, как осуществляется доступ.
Для объекта доступа может быть определен владелец – субъект, которому принадлежит данный объект и который несет ответственность за конфиденциальность содержащейся в объекте информации, а также за целостность и доступность объекта.
Обычно владельцем объекта автоматически назначается субъект, создавший данный объект; в дальнейшем владелец объекта может быть изменен с использованием соответствующего метода доступа к объекту. На владельца, как правило, возлагается ответственность за корректное ограничение прав доступа к данному объекту других субъектов.
Правом доступа к объекту называют право на получение доступа к объекту по некоторому методу или группе методов. Например, если пользователь имеет возможность читать файл, говорят, что он имеет право на чтение этого файла. Говорят, что субъект имеет некоторую привилегию, если он имеет право на доступ по некоторому методу или группе методов ко всем объектам ОС, поддерживающим данный метод доступа.
Разграничением доступа субъектов к объектам является совокупность правил, определяющая для каждой тройки субъект–объект–метод, разрешен ли доступ данного субъекта к данному объекту по данному методу. При избирательном разграничении доступа возможность доступа определена однозначно для каждой тройки субъект–объект–метод, при полномочном разграничении доступа ситуация несколько сложнее.
Субъекта доступа называют суперпользователем, если он имеет возможность игнорировать правила разграничения доступа к объектам.
Правила разграничения доступа
Правила разграничения доступа, действующие в операционной системе, устанавливаются администраторами системы при определении текущей политики безопасности. За соблюдением этих правил субъектами доступа следит монитор ссылок – часть подсистемы защиты операционной системы.
Правила разграничения доступа должны удовлетворять следующим требованиям:
Иными словами, если согласно правилам организации, доступ пользователя к некоторой информации считается несанкционированным, этот доступ должен быть ему запрещен.
Основные модели разграничения доступа
Существуют две основные модели разграничения доступа:
При избирательном разграничении доступа (Discretionary Access Control) определенные операции над конкретным ресурсом запрещаются или разрешаются субъектам или группам субъектов.
Большинство операционных систем реализуют именно избирательное разграничение доступа.
Полномочное разграничение доступа заключается в том, что все объекты могут иметь уровни секретности, а все субъекты делятся на группы, образующие иерархию в соответствии с уровнем допуска к информации. Иногда эту модель называют моделью многоуровневой безопасности, предназначенной для хранения секретов.
Избирательное разграничение доступа.
Система правил избирательного разграничения доступа формулируется следующим образом.
Этот привилегированный пользователь не может игнорировать разграничение доступа к объектам. Например, в ОС типа Windows администратор для обращения к чужому объекту (принадлежащему другому субъекту) должен вначале объявить себя владельцем этого объекта, используя привилегию администратора объявлять себя владельцем любого объекта, затем дать себе необходимые права, и только после этого администратор может обратиться к объекту. Последнее требование введено для реализации механизма удаления потенциально недоступных объектов.
При создании объекта его владельцем назначается субъект, создавший данный объект. В дальнейшем субъект, обладающий необходимыми правами, может назначить объекту нового владельца.
При этом субъект, изменяющий владельца объекта, может назначить новым владельцем объекта только себя. Такое ограничение вводится для того, чтобы владелец объекта не мог отдать владение объектом другому субъекту и тем самым снять с себя ответственность за некорректные действия с объектом.
Для определения прав доступа субъектов к объектам при избирательном разграничении доступа используются такие понятия, как матрица доступа и домен безопасности.
С концептуальной точки зрения текущее состояние прав доступа при избирательном разграничении доступа описывается матрицей, в строках которой перечислены субъекты доступа, в столбцах – объекты доступа, а в ячейках – операции, которые субъект может выполнить над объектом.
Домен безопасности определяет набор объектов и типов операций, которые могут производиться над каждым объектом операционной системы.
В ГОСТ Р ИСО/МЭК ТО 19791-2008 дано следующее определение: Домен безопасности (security domain) — часть автоматизированной системы, которая реализует одни и те же политики безопасности.
Термин домен (Domain) часто связывают с Microsoft, когда люди слышат этот термин, они представляют себе группу компьютеров и устройств в сетевом сегменте, управляемых сервером, на котором запущена служба каталогов Active Directory корпорации Microsoft для операционных систем семейства Windows Server, называемом контроллером домена.
В действительности, домен – это просто набор ресурсов, доступных субъекту. Помните, что субъект может быть пользователем, процессом или приложением. В рамках операционной системы, процесс имеет домен, который является набором системных ресурсов, доступных процессу для выполнения им своих задач. Этими ресурсами могут быть сегменты памяти, пространство на жестком диске, службы операционной системы и другие процессы. В сетевой среде, домен является набором доступных физических и логических ресурсов, которыми могут быть маршрутизаторы, файловые серверы, службы FTP, веб-серверы и т.д.
Термин домен безопасности (security domain) основывается на определении домена, добавляя к нему факт, что ресурсы в рамках этой логической структуры (домена) работают c одной и той же политикой безопасности и управляются одной группой. Таким образом, администратор может поместить компьютеры, учетные записи и сетевые ресурсы сотрудников бухгалтерии в Домен 1, а компьютеры, учетные записи и сетевые ресурсы руководства в Домен 2. Все эти элементы попадут в эти два контейнера, поскольку они (элементы) не только выполняют однотипные задачи, но также, что более важно, имеют один и тот же уровень доверия. Общий уровень доверия позволяет управлять этими элементами одной (отдельной) политикой безопасности.
Пример доменов показан в табл. 2.1.
Таблица 2.1. Специфицирование прав доступа к ресурсам. Матрица доступа. F1, F2, F3 – файлы, Printer – принтер.
Связь конкретных субъектов, функционирующих в операционных системах, может быть организована следующим образом:
Рассмотрим стандартную двухрежимную модель выполнения ОС. Когда процесс выполняется в режиме ядра (Kernel Mode), он может вызывать привилегированные инструкции и иметь полный контроль над компьютерной системой. С другой стороны, если процесс выполняется в пользовательском режиме (User Domain), он может вызывать только непривилегированные инструкции. Следовательно, он может выполняться лишь внутри предопределенного пространства памяти. Наличие этих двух режимов позволяет защитить ОС (Kernel Domain) от пользовательских процессов (выполняющихся в режиме User Domain). В мультипрограммных системах двух доменов недостаточно, так как появляется необходимость защиты пользователей друг от друга.
В ОС UNIX домен безопасности связан с пользователем. Каждый пользователь обычно работает со своим набором объектов.
Модель безопасности, специфицированная выше (см. табл. 2.1), имеет вид матрицы и называется матрицей доступа. Столбцы этой матрицы представляют собой объекты, строки – субъекты. В каждой ячейке матрицы хранится совокупность прав доступа, предоставленных данному субъекту на данный объект. Поскольку реальная матрица доступа очень велика (типичный объем матрицы для современной операционной системы составляет несколько десятков мегабайтов), ее никогда не хранят в системе в явном виде. В общем случае эта матрица будет разреженной, то есть большинство ее клеток будут пустыми. Матрицу доступа можно разложить по столбцам, в результате чего получаются списки прав доступа ACL (Access Control List).
Access Control List или ACL — список контроля доступа, который определяет, кто или что может получать доступ к конкретному объекту, и какие именно операции разрешено или запрещено этому субъекту проводить над объектом.
Списки контроля доступа являются основой систем с избирательным управлением доступа.
В результате разложения матрицы по строкам получаются мандаты возможностей (Capability List или Capability Tickets).
Элементами списка прав доступа ACL могут быть процессы, пользователи или группы пользователей. При реализации широко применяется предоставление доступа по умолчанию для пользователей, права которых не указаны. Например, в ОС UNIX все субъекты-пользователи разделены на три группы (владелец, группа и остальные) и для членов каждой группы контролируются операции чтения, записи и исполнения (rwx). В итоге имеем ACL – 9-битный код, который является атрибутом разнообразных объектов UNIX.
Мандаты возможностей. Как отмечалось выше, если матрицу доступа хранить по строкам, то есть если каждый субъект хранит список объектов и для каждого объекта – список допустимых операций, то такой способ хранения называется мандатами возможностей, или перечнями возможностей. Каждый пользователь обладает несколькими мандатами и может иметь право передавать их другим. Мандаты могут быть рассеяны по системе и вследствие этого представлять большую угрозу для безопасности, чем списки контроля доступа. Их хранение должно быть тщательно продумано. Примерами систем, использующих перечни возможностей, являются Hydra, Cambridge CAP System.
Избирательное разграничение доступа является наиболее распространенным способом разграничения доступа. Это обусловлено его сравнительной простотой реализации и необременительностью правил такого разграничения доступа для пользователей. Главное достоинство избирательного разграничения доступа – гибкость; основные недостатки – рассредоточенность управления и сложность централизованного контроля.
Вместе с тем защищенность операционной системы, подсистема защиты которой реализует только избирательное разграничение доступа, в некоторых случаях может оказаться недостаточной.
В частности, в США запрещено хранить информацию, содержащую государственную тайну, в компьютерных системах, поддерживающих только избирательное разграничение доступа.
Система правил разграничения доступа для модели изолированной программной среды формулируется следующим образом:
Изолированная программная среда существенно повышает защищенность операционной системы от разрушающих программных воздействий, включая программные закладки и компьютерные вирусы. Кроме того, при использовании данной модели повышается защищенность целостности данных, хранящихся в системе. В то же время изолированная программная среда создает определенные сложности в администрировании операционной системы. Например, при установке нового программного продукта администратор должен изменить списки разрешенных программ для пользователей, которые должны иметь возможность работать с этим программным продуктом. Изолированная программная среда не защищает от утечки конфиденциальной информации.
Полномочное разграничение доступа с контролем информационных потоков
Полномочное, или мандатное, разграничение доступа (Mandatory Access Control) обычно применяется в совокупности с избирательным разграничением доступа. Рассмотрим именно такой случай.
Правила разграничения доступа в данной модели формулируются следующим образом:
– объект является объектом полномочного разграничения доступа;
– гриф секретности объекта строго выше уровня допуска
субъекта, обращающегося к нему;
– субъект открывает объект в режиме, допускающем чтение информации.
Это правило называют правилом NRU (Not Read Up – не читать выше).
– объект является объектом полномочного разграничения доступа;
– гриф секретности объекта строго ниже уровня конфиденциальности процесса, обращающегося к нему;
– субъект собирается записывать в объект информацию.
Это правило разграничения доступа предотвращает утечку секретной информации. Это так называемое правило NWD (Not Write Down – не записывать ниже).
– имеет доступ к объекту согласно правилу 7;
– обладает специальной привилегией, позволяющей ему понижать грифы секретности объектов.
При использовании данной модели разграничения доступа существенно страдает производительность операционной системы, поскольку права доступа к объекту должны проверяться не только при открытии объекта, но и при каждой операции чтения/записи.
Кроме того, данная модель разграничения доступа создает пользователям определенные неудобства, связанные с тем, что если уровень конфиденциальности процесса строго выше нуля, то вся информация в памяти процесса фактически является секретной и не может быть записана в несекретный объект.
Если процесс одновременно работает с двумя объектами, только один из которых является секретным, процесс не может записывать информацию из памяти во второй объект. Эта проблема решается посредством использования специального программного интерфейса API для работы с памятью. Области памяти, выделяемые процессам, могут быть описаны как объекты полномочного разграничения доступа, после чего им могут назначаться грифы секретности.
При чтении секретного файла процесс должен считать содержимое такого файла в секретную область памяти, используя для этого функции операционной системы, гарантирующие невозможность утечки информации. Для работы с секретной областью памяти процесс также должен использовать специальные функции. Поскольку утечка информации из секретных областей памяти в память процесса невозможна, считывание процессом секретной информации в секретные области памяти не отражается на уровне конфиденциальности процесса. Если же процесс считывает секретную информацию в область памяти, не описанную как объект полномочного разграничения доступа, повышается уровень конфиденциальности процесса.
Из вышеизложенного следует, что пользователи операционных систем, реализующих данную модель разграничения доступа, вынуждены использовать программное обеспечение, разработанное с учетом этой модели. В противном случае пользователи будут испытывать серьезные проблемы в процессе работы с объектами операционной системы, имеющими ненулевой гриф секретности.
Определенные проблемы вызывает также вопрос о назначении грифов секретности создаваемым объектам. Если пользователь создает новый объект с помощью процесса, имеющего ненулевой уровень конфиденциальности, пользователь вынужден присвоить новому объекту гриф секретности не ниже уровня конфиденциальности процесса. Во многих ситуациях это неудобно.
Сравнительный анализ моделей разграничения доступа
Каждая из рассмотренных моделей разграничения доступа имеет свои достоинства и недостатки. Таблица 2.2 позволяет провести их сравнительный анализ.
Таблица 2.2. Модели разграничения доступа.
Как видно из табл. 2.2, в большинстве ситуаций применение избирательного разграничения доступа наиболее эффективно.
Изолированную программную среду целесообразно использовать в случаях, когда важно обеспечить целостность программ и данных операционной системы. Полномочное разграничение доступа с контролем информационных потоков следует применять в теx случаях, когда для организации чрезвычайно важно обеспечение защищенности системы от несанкционированной утечки информации. В остальных ситуациях применение этой модели нецелесообразно из-за резкого ухудшения эксплуатационных качеств операционной системы.
2.4. Аудит
Процедура аудита применительно к ОС заключается в регистрации в специальном журнале, называемом журналом аудита, или журналом безопасности, событий, которые могут представлять опасность для операционной системы. Пользователи системы, обладающие правом чтения журнала аудита, называются аудиторами.
Необходимость включения в защищенную операционную систему функций аудита обусловлена следующими обстоятельствами:
К числу событий, которые могут представлять опасность для операционной системы, обычно относят следующие:
Если фиксировать в журнале аудита все события, объем регистрационной информации будет расти слишком быстро, что затруднит ее эффективный анализ. Необходимо предусмотреть выборочное протоколирование как в отношении пользователей, так и в отношении событий.
Требования к аудиту
Подсистема аудита операционной системы должна удовлетворять следующим требованиям:
Для ограничения доступа к журналу аудита должны применяться специальные средства защиты.
Политика аудита.
Политика аудита – это совокупность правил, определяющих то, какие события должны регистрироваться в журнале аудита. Для обеспечения надежной защиты операционной системы в журнале аудита должны обязательно регистрироваться следующие события:
Окончательный выбор того, какие события должны регистрироваться в журнале аудита, а какие не должны, возлагается на аудиторов. При выборе оптимальной политики аудита следует учитывать ожидаемую скорость заполнения журнала аудита. Политика аудита должна оперативно реагировать на изменения в конфигурации операционной системы, в характере хранимой и обрабатываемой информации, а особенно на выявленные попытки атаки операционной системы.
В некоторых ОС подсистема аудита, помимо записи информации о зарегистрированных событиях в специальный журнал, предусматривает возможность интерактивного оповещения аудиторов об этих событиях.