Принципы построения защищенной операционной системы

Введение.
Проблема защиты от несанкционированных действий при взаимодействии с внешними сетями может быть успешно решена только на основе комплексной защиты информационных систем. Защищенные операционные системы относятся к базовым средствам многоуровневой комплексной защиты ИС.

Учебные вопросы (основная часть):

1.Проблемы обеспечения безопасности операционных систем.

Большинство программных средств защиты информации являются прикладными программами. Для их выполнения требуется поддержка операционной системы (ОС). Окружение, в котором функционирует ОС, называется доверенной вычислительной базой (ДВБ). ДВБ включает в себя полный набор элементов, обеспечивающих информационную безопасность: операционную систему, программы, сетевое оборудование, средства физической защиты и даже организационные процедуры. Краеугольным камнем этой пирамиды является защищенная операционная система. Без нее доверенная вычислительная база оказывается построенной на песке.

 

1.1. Угрозы безопасности операционной системы.

Организация эффективной и надежной защиты операционной системы невозможна без предварительного анализа возможных угроз ее безопасности. Угрозы безопасности операционной системы существенно зависят от условий эксплуатации системы, от того, какая информация хранится и обрабатывается в системе. Например, если операционная система используется для организации электронного документооборота, наиболее опасны угрозы, связанные с несанкционированным доступом (НСД) к файлам. Если же операционная система используется как платформа провайдера интернет-услуг, очень опасны атаки на сетевое программное обеспечение операционной системы.

Угрозы безопасности операционной системы можно классифицировать по различным аспектам их реализации.

Классификация угроз по цели атаки:

• несанкционированное чтение информации;
• несанкционированное изменение информации;
• несанкционированное уничтожение информации;
• полное или частичное разрушение операционной системы.

Классификация угроз по принципу воздействия на операционную систему:

• использование известных (легальных) каналов получения информации, например, угроза несанкционированного чтения файла, доступ пользователей к которому определен некорректно – разрешен доступ пользователю, которому, согласно политике безопасности, доступ должен быть запрещен;
• использование скрытых каналов получения информации, например, угроза использования злоумышленником недокументированных возможностей операционной системы;
• создание новых каналов получения информации с помощью программных закладок.

Классификация угроз по типу используемой злоумышленником уязвимости защиты:

• неадекватная политика безопасности, в том числе и ошибки администратора системы;
• ошибки и недокументированные возможности программного обеспечения операционной системы, в том числе и так называемые люки – случайно или преднамеренно встроенные
• в систему «служебные входы», позволяющие обходить систему защиты;
• ранее внедренная программная закладка.

Классификация угроз по характеру воздействия на ОС:

• активное воздействие – несанкционированные действия злоумышленника в системе;
• пассивное воздействие – несанкционированное наблюдение злоумышленника за процессами, происходящими в системе.

 

Угрозы безопасности ОС можно также классифицировать по таким признакам, как способ действий злоумышленника, используемые средства атаки, объект атаки, способ воздействия на объект атаки, состояние атакуемого объекта ОС на момент атаки.

 

Операционная система может подвергнуться следующим типичным атакам:

• сканирование файловой системы. Злоумышленник просматривает файловую систему компьютера и пытается прочесть (или скопировать) все файлы подряд. Рано или поздно обнаруживается хотя бы одна ошибка администратора. В результате злоумышленник получает доступ к информации, который должен быть ему запрещен;
• подбор пароля. Существует несколько методов подбора паролей пользователей:
  • тотальный перебор;
  • тотальный перебор, оптимизированный по статистике встречаемости символов или с помощью словарей;
  • подбор пароля с использованием знаний о пользователе (его имени, фамилии, даты рождения, номера телефона и т. д.);
• кража ключевой информации. Злоумышленник может подсмотреть пароль, набираемый пользователем, или восстановить набираемый пользователем пароль по движениям его рук на клавиатуре. Носитель с ключевой информацией (смарткарта, Touch Memory и т. д.) может быть просто украден;
• сборка мусора. Во многих операционных системах информация, уничтоженная пользователем, не уничтожается физически, а помечается как уничтоженная (так называемый мусор). Злоумышленник восстанавливает эту информацию, просматривает ее и копирует интересующие его фрагменты;
• превышение полномочий. Злоумышленник, используя ошибки в программном обеспечении ОС или политике безопасности, получает полномочия, превышающие те, которые ему предоставлены в соответствии с политикой безопасности. Обычно это достигается путем запуска программы от имени другого пользователя;
• программные закладки. Программные закладки, внедряемые в операционные системы, не имеют существенных отличий от других классов программных закладок;
• жадные программы – это программы, преднамеренно захватывающие значительную часть ресурсов компьютера, в результате чего другие программы не могут выполняться или выполняются крайне медленно. Запуск жадной программы может привести к краху операционной системы.

1.2. Понятие защищенной операционной системы.

Операционную систему называют защищенной, если она предусматривает средства защиты от основных классов угроз. Защищенная операционная система обязательно должна содержать средства разграничения доступа пользователей к своим ресурсам, а также средства проверки подлинности пользователя, начинающего работу с операционной системой. Кроме того, защищенная операционная система должна содержать средства противодействия случайному или преднамеренному выводу операционной системы из строя.

Если операционная система предусматривает защиту не от всех основных классов угроз, а только от некоторых, такую ОС называют частично защищенной.

Подходы к построению защищенных операционных систем

Существует два основных подхода к созданию защищенных операционных систем – фрагментарный и комплексный. При фрагментарном подходе вначале организуется защита от одной угрозы, затем от другой.

Примером фрагментарного подхода может служить ситуация, когда за основу берется незащищенная операционная система (например, Windows 98), на нее устанавливают антивирусный пакет, систему шифрования, систему регистрации действий пользователей и т. д.

При применении фрагментарного подхода подсистема защиты операционной системы представляет собой набор разрозненных программных продуктов, как правило, от разных производителей. Эти программные средства работают независимо друг от друга, при этом практически невозможно организовать их тесное взаимодействие. Кроме того, отдельные элементы такой подсистемы защиты могут некорректно работать в присутствии друг друга, что приводит к резкому снижению надежности системы.

При комплексном подходе защитные функции вносятся в операционную систему на этапе проектирования архитектуры операционной системы и являются ее неотъемлемой частью. Отдельные элементы подсистемы защиты, созданной на основе комплексного подхода, тесно взаимодействуют друг с другом при решении различных задач, связанных с организацией защиты информации, поэтому конфликты между ее отдельными компонентами практически невозможны. Подсистема защиты, созданная на основе комплексного подхода, может быть устроена так, что при фатальных сбоях в функционировании ее ключевых элементов она вызывает крах операционной системы, что не позволяет злоумышленнику отключать защитные функции системы. При фрагментарном подходе такая организация подсистемы защиты невозможна.

Как правило, подсистему защиты операционной системы, созданную на основе комплексного подхода, проектируют так, чтобы отдельные ее элементы были заменяемы. Соответствующие программные модули могут быть заменены другими модулями.

Административные меры защиты.

Программно-аппаратные средства защиты операционной системы обязательно должны дополняться административными мерами защиты. Без постоянной квалифицированной поддержки со стороны администратора даже надежная программно-аппаратная защита может давать сбои. Перечислим основные административные меры защиты.

1. Постоянный контроль корректности функционирования операционной системы, особенно ее подсистемы защиты. Такой контроль удобно организовать, если операционная система поддерживает автоматическую регистрацию наиболее важных событий (event logging) в специальном журнале.
2. Организация и поддержание адекватной политики безопасности. Политика безопасности ОС должна постоянно корректироваться, оперативно реагируя на попытки злоумышленников преодолеть защиту операционной системы, а также на изменения в конфигурации операционной системы, установку и удаление прикладных программ.
3. Осведомление пользователей операционной системы о необходимости соблюдения мер безопасности при работе с ОС и контроль за соблюдением этих мер.
4. Регулярное создание и обновление резервных копий программ и данных ОС.
5. Постоянный контроль изменений в конфигурационных данных и политике безопасности ОС.

Адекватная политика безопасности.

Выбор и поддержание адекватной политики безопасности являются одной из наиболее важных задач администратора операционной системы. Если принятая в ОС политика безопасности неадекватна, это может привести к несанкционированному доступу злоумышленника к ресурсам системы и к снижению надежности функционирования ОС.

Известно утверждение: чем лучше защищена ОС, тем труднее с ней работать пользователям и администраторам. Это обусловлено следующими факторами:

• система защиты не всегда способна определить, является ли некоторое действие пользователя злонамеренным. Поэтому система защиты либо не пресекает некоторых видов несанкционированного доступа, либо запрещает некоторые вполне легальные действия пользователей. Чем выше защищенность системы, тем шире класс тех легальных действий пользователей, которые рассматриваются подсистемой защиты как несанкционированные;
• любая система, в которой предусмотрены функции защиты информации, требует от администраторов определенных усилий, направленных на поддержание адекватной политики безопасности. Чем больше в операционной системе защитных функций, тем больше времени и средств нужно тратить на поддержание защиты;
• подсистема защиты операционной системы, как и любой другой программный пакет, потребляет аппаратные ресурсы компьютера. Чем сложнее устроены защитные функции операционной системы, тем больше ресурсов компьютера (процессорного времени, оперативной памяти и др.) затрачивается на поддержание функционирования подсистемы защиты и тем меньше ресурсов остается на долю прикладных программ;
• поддержание слишком жесткой политики безопасности может негативно сказаться на надежности функционирования операционной системы. Чрезмерно жесткая политика безопасности может привести к трудно выявляемым ошибкам и сбоям в процессе функционирования операционной системы и даже к краху ОС.

Оптимальная адекватная политика безопасности – это такая политика безопасности, которая не только не позволяет злоумышленникам выполнять несанкционированные действия, но и не приводит к описанным выше негативным эффектам.

Адекватная политика безопасности определяется не только архитектурой ОС, но и ее конфигурацией, установленными прикладными программами и т. д. Формирование и поддержание адекватной политики безопасности ОС можно разделить на ряд этапов.

1. Анализ угроз. Администратор операционной системы рассматривает возможные угрозы безопасности данного экземпляра ОС. Среди возможных угроз выделяются наиболее опасные, защите от которых нужно уделять максимум средств.
2. Формирование требований к политике безопасности. Администратор определяет, какие средства и методы будут применяться для защиты от тех или иных угроз. Например, защиту от несанкционированного доступа к некоторому объекту ОС можно решать либо средствами разграничения доступа, либо криптографическими средствами, либо используя некоторую комбинацию этих средств.
3. Формальное определение политики безопасности. Администратор определяет, как конкретно должны выполняться требования, сформулированные на предыдущем этапе. Формулируются необходимые требования к конфигурации ОС, а также требования к конфигурации дополнительных пакетов защиты, если установка таких пакетов необходима. Результатом данного этапа является развернутый перечень настроек конфигурации ОС и дополнительных пакетов защиты с указанием того, в каких ситуациях какие настройки должны быть установлены.
4. Претворение в жизнь политики безопасности. Задачей данного этапа является приведение конфигурации ОС и дополнительных пакетов защиты в соответствие с политикой безопасности, формально определенной на предыдущем этапе.
5. Поддержание и коррекция политики безопасности. В задачу администратора на данном этапе входят контроль соблюдения политики безопасности и внесение в нее необходимых изменений по мере появления изменений в функционировании ОС.

Специальных стандартов защищенности операционных систем не существует. Для оценки защищенности операционных систем используются стандарты, разработанные для компьютерных систем вообще. Как правило, сертификация операционной системы по некоторому классу защиты сопровождается составлением требований к адекватной политике безопасности, при безусловном выполнении которой защищенность конкретного экземпляра операционной системы будет соответствовать требованиям соответствующего класса защиты.

Определяя адекватную политику безопасности, администратор операционной системы должен в первую очередь ориентироваться на защиту ОС от конкретных угроз ее безопасности .

2. Архитектура подсистемы защиты операционной системы.

2.1. Основные функции подсистемы защиты операционной системы

Подсистема защиты ОС выполняет следующие основные функции:

1. Идентификация и аутентификация. Ни один пользователь не может начать работу с операционной системой, не идентифицировав себя и не предоставив системе аутентифицирующую информацию, подтверждающую, что пользователь действительно является тем, кем он себя заявляет.
2. Разграничение доступа. Каждый пользователь системы имеет доступ только к тем объектам ОС, к которым ему предоставлен доступ в соответствии с текущей политикой безопасности.
3. Аудит. Операционная система регистрирует в специальном журнале события, потенциально опасные для поддержания безопасности системы.
4. Управление политикой безопасности. Политика безопасности должна постоянно поддерживаться в адекватном состоянии, то есть должна гибко реагировать на изменения условий функционирования ОС. Управление политикой безопасности осуществляется администраторами системы с использованием соответствующих средств, встроенных в операционную систему.
5. Криптографические функции. Защита информации немыслима без использования криптографических средств защиты. Шифрование используется в ОС при хранении и передаче по каналам связи паролей пользователей и некоторых других данных, критичных для безопасности системы.
6. Сетевые функции. Современные ОС, как правило, работают не изолированно, а в составе локальных и/или глобальных компьютерных сетей. ОС компьютеров, входящих в одну сеть, взаимодействуют между собой для решения различных задач, в том числе имеющих прямое отношение к защите информации.

Подсистема защиты обычно не представляет собой единый программный модуль. Как правило, каждая из перечисленных функций подсистемы защиты решается одним или несколькими программными модулями. Некоторые функции встраиваются непосредственно в ядро ОС. Между различными модулями подсистемы защиты должен существовать четко определенный интерфейс, используемый при взаимодействии модулей для решения общих задач.

2.2. Идентификация, аутентификация и авторизация субъектов доступа.

В защищенной ОС любой пользователь (субъект доступа), перед тем как начать работу с системой, должен пройти идентификацию, аутентификацию и авторизацию.

Идентификация субъекта доступа заключается в том, что пользователь (субъект) сообщает операционной системе идентифицирующую информацию о себе (имя, учетный номер) и таким образом идентифицирует себя.

Для того чтобы установить, что пользователь именно тот, за кого себя выдает, в информационных системах предусмотрена процедура аутентификации, задача которой – предотвращение доступа к системе нежелательных лиц.

Аутентификация субъекта доступа заключается в том, что субъект предоставляет операционной системе, помимо идентифицирующей информации, еще и аутентифицирующую информацию, подтверждающую, что он действительно является тем субъектом доступа, к которому относится идентифицирующая информация.

Авторизация субъекта доступа происходит после успешной идентификации и аутентификации. При авторизации субъекта ОС выполняет действия, необходимые для того, чтобы субъект мог начать работу в системе.

Авторизация субъекта не относится напрямую к подсистеме защиты операционной системы. В процессе авторизации решаются технические задачи, связанные с организацией начала работы в системе уже идентифицированного и аутентифицированного субъекта доступа.

С точки зрения обеспечения безопасности ОС, процедуры идентификации и аутентификации являются весьма ответственными. Действительно, если злоумышленник сумел войти в систему от имени другого пользователя, он легко получает доступ ко всем объектам ОС, к которым имеет доступ этот пользователь. Если при этом подсистема аудита генерирует сообщения о событиях, потенциально опасных для безопасности ОС, то в журнал аудита записывается не имя злоумышленника, а имя пользователя, от имени которого злоумышленник работает в системе.

Наиболее распространенными методами идентификации и аутентификации являются следующие:

• идентификация и аутентификация с помощью имени и пароля;
• идентификация и аутентификация с помощью внешних носителей ключевой информации;
• идентификация и аутентификация с помощью биометрических характеристик пользователей.

2.3. Разграничение доступа к объектам операционной системы.

Основными понятиями процесса разграничения доступа к объектам операционной системы являются объект доступа, метод доступа к объекту и субъект доступа.

Объектом доступа (или просто объектом) называют любой элемент операционной системы, доступ к которому пользователей и других субъектов доступа может быть произвольно ограничен. Возможность доступа к объектам ОС определяется не только архитектурой операционной системы, но и текущей политикой безопасности. Под объектами доступа понимают, как ресурсы оборудования, так и программные ресурсы. В качестве примера ресурсов оборудования можно привести процессор, принтер, жесткие диски и ленты. Каждый объект имеет уникальное имя, отличающее его от других объектов в системе, и может быть доступен через хорошо определенные и значимые операции.

Методом доступа к объекту называется операция, определенная для объекта. Тип операции зависит от объектов. Например, процессор может только выполнять команды, сегменты памяти могут быть записаны и прочитаны, считыватель магнитных карт может только читать, а для файлов могут быть определены методы доступа «чтение», «запись » и «добавление» (дописывание информации в конец файла).

Субъектом доступа называют любую сущность, способную инициировать выполнение операций над объектами (обращаться к объектам по некоторым методам доступа). Обычно полагают, что множество субъектов доступа и множество объектов доступа не пересекаются.

Иногда к субъектам доступа относят процессы, выполняющиеся в системе. Однако логичнее считать субъектом доступа именно пользователя, от имени которого выполняется процесс. Естественно, под субъектом доступа подразумевают не физического пользователя, работающего с компьютером, а «логического», от имени которого выполняются процессы операционной системы.

Таким образом, объект доступа – это то, к чему осуществляется доступ, субъект доступа – это тот, кто осуществляет доступ, и метод доступа – это то, как осуществляется доступ.

Для объекта доступа может быть определен владелец – субъект, которому принадлежит данный объект и который несет ответственность за конфиденциальность содержащейся в объекте информации, а также за целостность и доступность объекта.

Обычно владельцем объекта автоматически назначается субъект, создавший данный объект; в дальнейшем владелец объекта может быть изменен с использованием соответствующего метода доступа к объекту. На владельца, как правило, возлагается ответственность за корректное ограничение прав доступа к данному объекту других субъектов.

Правом доступа к объекту называют право на получение доступа к объекту по некоторому методу или группе методов. Например, если пользователь имеет возможность читать файл, говорят, что он имеет право на чтение этого файла. Говорят, что субъект имеет некоторую привилегию, если он имеет право на доступ по некоторому методу или группе методов ко всем объектам ОС, поддерживающим данный метод доступа.

Разграничением доступа субъектов к объектам является совокупность правил, определяющая для каждой тройки субъект–объект–метод, разрешен ли доступ данного субъекта к данному объекту по данному методу. При избирательном разграничении доступа возможность доступа определена однозначно для каждой тройки субъект–объект–метод, при полномочном разграничении доступа ситуация несколько сложнее.

Субъекта доступа называют суперпользователем, если он имеет возможность игнорировать правила разграничения доступа к объектам.

 

Правила разграничения доступа

Правила разграничения доступа, действующие в операционной системе, устанавливаются администраторами системы при определении текущей политики безопасности. За соблюдением этих правил субъектами доступа следит монитор ссылок – часть подсистемы защиты операционной системы.

Правила разграничения доступа должны удовлетворять следующим требованиям:

1. Правила разграничения доступа, принятые в операционной системе, должны соответствовать аналогичным правилам, принятым в организации, в которой установлена эта ОС.

Иными словами, если согласно правилам организации, доступ пользователя к некоторой информации считается несанкционированным, этот доступ должен быть ему запрещен.

2. Правила разграничения доступа не должны допускать разрушающие воздействия субъектов доступа на ОС, выражающиеся в несанкционированном изменении, удалении или другом воздействии на объекты, жизненно важные для нормальной работы ОС.
3. Любой объект доступа должен иметь владельца. Недопустимо присутствие ничейных объектов – объектов, не имеющих владельца.
4. Недопустимо присутствие недоступных объектов – объектов, к которым не может обратиться ни один субъект доступа ни по одному методу доступа.
5. Недопустима утечка конфиденциальной информации.

Основные модели разграничения доступа

Существуют две основные модели разграничения доступа:

• избирательное (дискреционное) разграничение доступа;
• полномочное (мандатное) разграничение доступа.

При избирательном разграничении доступа (Discretionary Access Control) определенные операции над конкретным ресурсом запрещаются или разрешаются субъектам или группам субъектов.

Большинство операционных систем реализуют именно избирательное разграничение доступа.

Полномочное разграничение доступа заключается в том, что все объекты могут иметь уровни секретности, а все субъекты делятся на группы, образующие иерархию в соответствии с уровнем допуска к информации. Иногда эту модель называют моделью многоуровневой безопасности, предназначенной для хранения секретов.

 

Избирательное разграничение доступа.

Система правил избирательного разграничения доступа формулируется следующим образом.

1. Для любого объекта операционной системы существует владелец.
2. Владелец объекта может произвольно ограничивать доступ других субъектов к данному объекту.
3. Для каждой тройки субъект–объект–метод возможность доступа определена однозначно.
4. Существует хотя бы один привилегированный пользователь (администратор), имеющий возможность обратиться к любому объекту по любому методу доступа.

Этот привилегированный пользователь не может игнорировать разграничение доступа к объектам. Например, в ОС типа Windows администратор для обращения к чужому объекту (принадлежащему другому субъекту) должен вначале объявить себя владельцем этого объекта, используя привилегию администратора объявлять себя владельцем любого объекта, затем дать себе необходимые права, и только после этого администратор может обратиться к объекту. Последнее требование введено для реализации механизма удаления потенциально недоступных объектов.

При создании объекта его владельцем назначается субъект, создавший данный объект. В дальнейшем субъект, обладающий необходимыми правами, может назначить объекту нового владельца.

При этом субъект, изменяющий владельца объекта, может назначить новым владельцем объекта только себя. Такое ограничение вводится для того, чтобы владелец объекта не мог отдать владение объектом другому субъекту и тем самым снять с себя ответственность за некорректные действия с объектом.

Для определения прав доступа субъектов к объектам при избирательном разграничении доступа используются такие понятия, как матрица доступа и домен безопасности.

С концептуальной точки зрения текущее состояние прав доступа при избирательном разграничении доступа описывается матрицей, в строках которой перечислены субъекты доступа, в столбцах – объекты доступа, а в ячейках – операции, которые субъект может выполнить над объектом.

Домен безопасности определяет набор объектов и типов операций, которые могут производиться над каждым объектом операционной системы.

В ГОСТ Р ИСО/МЭК ТО 19791-2008 дано следующее определение: Домен безопасности (security domain)  —  часть автоматизированной системы, которая реализует одни и те же политики безопасности.

Термин домен (Domain) часто связывают с Microsoft, когда люди слышат этот термин, они представляют себе группу компьютеров и устройств в сетевом сегменте, управляемых сервером, на котором запущена служба каталогов Active Directory корпорации Microsoft для операционных систем семейства Windows Server, называемом контроллером домена.

В действительности, домен – это просто набор ресурсов, доступных субъекту. Помните, что субъект может быть пользователем, процессом или приложением. В рамках операционной системы, процесс имеет домен, который является набором системных ресурсов, доступных процессу для выполнения им своих задач. Этими ресурсами могут быть сегменты памяти, пространство на жестком диске, службы операционной системы и другие процессы. В сетевой среде, домен является набором доступных физических и логических ресурсов, которыми могут быть маршрутизаторы, файловые серверы, службы FTP, веб-серверы и т.д.

Термин домен безопасности (security domain) основывается на определении домена, добавляя к нему факт, что ресурсы в рамках этой логической структуры (домена) работают c одной и той же политикой безопасности и управляются одной группой. Таким образом, администратор может поместить компьютеры, учетные записи и сетевые ресурсы сотрудников бухгалтерии в Домен 1, а компьютеры, учетные записи и сетевые ресурсы руководства в Домен 2. Все эти элементы попадут в эти два контейнера, поскольку они (элементы) не только выполняют однотипные задачи, но также, что более важно, имеют один и тот же уровень доверия. Общий уровень доверия позволяет управлять этими элементами одной (отдельной) политикой безопасности.

Возможность выполнять операции над объектом есть право доступа, представляющее собой упорядоченную пару <object-name, rights-set>. Таким образом, домен есть набор прав доступа. Hапример, если домен D имеет право доступа <file F, {read, write}>, это означает, что процесс, выполняемый в домене D, может читать или писать в файл F, но не может выполнять других операций над этим объектом.

Пример доменов показан в табл. 2.1.

Связь конкретных субъектов, функционирующих в операционных системах, может быть организована следующим образом:

• каждый пользователь может быть доменом. В этом случае набор объектов, к которым может быть организован доступ, зависит от идентификации пользователя;
• каждый процесс может быть доменом. В этом случае набор доступных объектов определяется идентификацией процесса;
• каждая процедура может быть доменом. В этом случае набор доступных объектов соответствует локальным переменным, определенным внутри процедуры. Заметим, что, когда процедура выполнена, происходит смена домена.

Рассмотрим стандартную двухрежимную модель выполнения ОС. Когда процесс выполняется в режиме ядра (Kernel Mode), он может вызывать привилегированные инструкции и иметь полный контроль над компьютерной системой. С другой стороны, если процесс выполняется в пользовательском режиме (User Domain), он может вызывать только непривилегированные инструкции. Следовательно, он может выполняться лишь внутри предопределенного пространства памяти. Наличие этих двух режимов позволяет защитить ОС (Kernel Domain) от пользовательских процессов (выполняющихся в режиме User Domain). В мультипрограммных системах двух доменов недостаточно, так как появляется необходимость защиты пользователей друг от друга.

В ОС UNIX домен безопасности связан с пользователем. Каждый пользователь обычно работает со своим набором объектов.

Модель безопасности, специфицированная выше (см. табл. 2.1), имеет вид матрицы и называется матрицей доступа. Столбцы этой матрицы представляют собой объекты, строки – субъекты. В каждой ячейке матрицы хранится совокупность прав доступа, предоставленных данному субъекту на данный объект. Поскольку реальная матрица доступа очень велика (типичный объем матрицы для современной операционной системы составляет несколько десятков мегабайтов), ее никогда не хранят в системе в явном виде. В общем случае эта матрица будет разреженной, то есть большинство ее клеток будут пустыми. Матрицу доступа можно разложить по столбцам, в результате чего получаются списки прав доступа ACL (Access Control List).

Access Control List или ACL — список контроля доступа, который определяет, кто или что может получать доступ к конкретному объекту, и какие именно операции разрешено или запрещено этому субъекту проводить над объектом.

 

Списки контроля доступа являются основой систем с избирательным управлением доступа.

В результате разложения матрицы по строкам получаются мандаты возможностей (Capability List или Capability Tickets).

Список прав доступа ACL. Каждая колонка в матрице может быть реализована как список доступа для одного объекта. Очевидно, что пустые клетки могут не учитываться. В результате для каждого объекта имеем список упорядоченных пар <domain, rights-set>, который определяет все домены с непустыми наборами прав для данного объекта.

Элементами списка прав доступа ACL могут быть процессы, пользователи или группы пользователей. При реализации широко применяется предоставление доступа по умолчанию для пользователей, права которых не указаны. Например, в ОС UNIX все субъекты-пользователи разделены на три группы (владелец, группа и остальные) и для членов каждой группы контролируются операции чтения, записи и исполнения (rwx). В итоге имеем ACL – 9-битный код, который является атрибутом разнообразных объектов UNIX.

Мандаты возможностей. Как отмечалось выше, если матрицу доступа хранить по строкам, то есть если каждый субъект хранит список объектов и для каждого объекта – список допустимых операций, то такой способ хранения называется мандатами возможностей, или перечнями возможностей. Каждый пользователь обладает несколькими мандатами и может иметь право передавать их другим. Мандаты могут быть рассеяны по системе и вследствие этого представлять большую угрозу для безопасности, чем списки контроля доступа. Их хранение должно быть тщательно продумано. Примерами систем, использующих перечни возможностей, являются Hydra, Cambridge CAP System.

Избирательное разграничение доступа является наиболее распространенным способом разграничения доступа. Это обусловлено его сравнительной простотой реализации и необременительностью правил такого разграничения доступа для пользователей. Главное достоинство избирательного разграничения доступа – гибкость; основные недостатки – рассредоточенность управления и сложность централизованного контроля.

Вместе с тем защищенность операционной системы, подсистема защиты которой реализует только избирательное разграничение доступа, в некоторых случаях может оказаться недостаточной.

В частности, в США запрещено хранить информацию, содержащую государственную тайну, в компьютерных системах, поддерживающих только избирательное разграничение доступа.

Расширением модели избирательного разграничения доступа является изолированная (или замкнутая) программная среда. Изолированная программная среда. При использовании изолированной программной среды права субъекта на доступ к объекту определяются не только правами и привилегиями субъекта, но и процессом, с помощью которого субъект обращается к объекту. Можно, например, разрешить обращаться к файлам с расширением .doc только программам Word, Word Viewer и WPview.

Система правил разграничения доступа для модели изолированной программной среды формулируется следующим образом:

1. Для любого объекта операционной системы существует владелец.
2. Владелец объекта может произвольно ограничивать доступ других субъектов к данному объекту.
3. Для каждой четверки субъект–объект–метод–процесс возможность доступа определена однозначно.
4. Существует хотя бы один привилегированный пользователь (администратор), имеющий возможность обратиться к любому объекту по любому методу.
5. Для каждого субъекта определен список программ, которые этот субъект может запускать.

Изолированная программная среда существенно повышает защищенность операционной системы от разрушающих программных воздействий, включая программные закладки и компьютерные вирусы. Кроме того, при использовании данной модели повышается защищенность целостности данных, хранящихся в системе. В то же время изолированная программная среда создает определенные сложности в администрировании операционной системы. Например, при установке нового программного продукта администратор должен изменить списки разрешенных программ для пользователей, которые должны иметь возможность работать с этим программным продуктом. Изолированная программная среда не защищает от утечки конфиденциальной информации.

 

Полномочное разграничение доступа с контролем информационных потоков

Полномочное, или мандатное, разграничение доступа (Mandatory Access Control) обычно применяется в совокупности с избирательным разграничением доступа. Рассмотрим именно такой случай.

Правила разграничения доступа в данной модели формулируются следующим образом:

1. Для любого объекта операционной системы существует владелец.
2. Владелец объекта может произвольно ограничивать доступ других субъектов к данному объекту.
3. Для каждой четверки субъект–объект–метод–процесс возможность доступа определена однозначно в каждый момент времени. При изменении состояния процесса со временем возможность предоставления доступа также может измениться. Вместе с тем в каждый момент времени возможность доступа определена однозначно. Поскольку права процесса на доступ к объекту меняются с течением времени, они должны проверяться не только при открытии объекта, но и перед выполнением над объектом таких операций, как чтение и запись.
4. Существует хотя бы один привилегированный пользователь (администратор), имеющий возможность удалить любой объект.
5. В множестве объектов выделяется множество объектов полномочного разграничения доступа. Каждый объект полномочного разграничения доступа имеет гриф секретности. Чем выше числовое значение грифа секретности, тем секретнее объект. Нулевое значение грифа секретности означает, что объект несекретен. Если объект не является объектом полномочного разграничения доступа или несекретен, администратор может обратиться к нему по любому методу, как и в предыдущей модели разграничения доступа.
6. Каждый субъект доступа имеет уровень допуска. Чем выше числовое значение уровня допуска, тем больший допуск имеет субъект. Нулевое значение уровня допуска означает, что субъект не имеет допуска. Обычно ненулевое значение допуска назначается только субъектам-пользователям и не назначается субъектам, от имени которых выполняются системные процессы.
7. Доступ субъекта к объекту должен быть запрещен независимо от состояния матрицы доступа, если:

– объект является объектом полномочного разграничения доступа;

– гриф секретности объекта строго выше уровня допуска

субъекта, обращающегося к нему;

– субъект открывает объект в режиме, допускающем чтение информации.

Это правило называют правилом NRU (Not Read Up – не читать выше).

8. Каждый процесс операционной системы имеет уровень конфиденциальности, равный максимуму из грифов секретности объектов, открытых процессом на протяжении своего существования. Уровень конфиденциальности фактически представляет собой гриф секретности информации, хранящейся в оперативной памяти процесса.
9. Доступ субъекта к объекту должен быть запрещен независимо от состояния матрицы доступа, если:

– объект является объектом полномочного разграничения доступа;

– гриф секретности объекта строго ниже уровня конфиденциальности процесса, обращающегося к нему;

– субъект собирается записывать в объект информацию.

Это правило разграничения доступа предотвращает утечку секретной информации. Это так называемое правило NWD (Not Write Down – не записывать ниже).

10. Понизить гриф секретности объекта полномочного разграничения доступа может только субъект, который:

– имеет доступ к объекту согласно правилу 7;

– обладает специальной привилегией, позволяющей ему понижать грифы секретности объектов.

При использовании данной модели разграничения доступа существенно страдает производительность операционной системы, поскольку права доступа к объекту должны проверяться не только при открытии объекта, но и при каждой операции чтения/записи.

Кроме того, данная модель разграничения доступа создает пользователям определенные неудобства, связанные с тем, что если уровень конфиденциальности процесса строго выше нуля, то вся информация в памяти процесса фактически является секретной и не может быть записана в несекретный объект.

Если процесс одновременно работает с двумя объектами, только один из которых является секретным, процесс не может записывать информацию из памяти во второй объект. Эта проблема решается посредством использования специального программного интерфейса API для работы с памятью. Области памяти, выделяемые процессам, могут быть описаны как объекты полномочного разграничения доступа, после чего им могут назначаться грифы секретности.

При чтении секретного файла процесс должен считать содержимое такого файла в секретную область памяти, используя для этого функции операционной системы, гарантирующие невозможность утечки информации. Для работы с секретной областью памяти процесс также должен использовать специальные функции. Поскольку утечка информации из секретных областей памяти в память процесса невозможна, считывание процессом секретной информации в секретные области памяти не отражается на уровне конфиденциальности процесса. Если же процесс считывает секретную информацию в область памяти, не описанную как объект полномочного разграничения доступа, повышается уровень конфиденциальности процесса.

Из вышеизложенного следует, что пользователи операционных систем, реализующих данную модель разграничения доступа, вынуждены использовать программное обеспечение, разработанное с учетом этой модели. В противном случае пользователи будут испытывать серьезные проблемы в процессе работы с объектами операционной системы, имеющими ненулевой гриф секретности.

Определенные проблемы вызывает также вопрос о назначении грифов секретности создаваемым объектам. Если пользователь создает новый объект с помощью процесса, имеющего ненулевой уровень конфиденциальности, пользователь вынужден присвоить новому объекту гриф секретности не ниже уровня конфиденциальности процесса. Во многих ситуациях это неудобно.

Сравнительный анализ моделей разграничения доступа

Каждая из рассмотренных моделей разграничения доступа имеет свои достоинства и недостатки. Таблица 2.2 позволяет провести их сравнительный анализ.

Как видно из табл. 2.2, в большинстве ситуаций применение избирательного разграничения доступа наиболее эффективно.

Изолированную программную среду целесообразно использовать в случаях, когда важно обеспечить целостность программ и данных операционной системы. Полномочное разграничение доступа с контролем информационных потоков следует применять в теx случаях, когда для организации чрезвычайно важно обеспечение защищенности системы от несанкционированной утечки информации. В остальных ситуациях применение этой модели нецелесообразно из-за резкого ухудшения эксплуатационных качеств операционной системы.

2.4. Аудит

Процедура аудита применительно к ОС заключается в регистрации в специальном журнале, называемом журналом аудита, или журналом безопасности, событий, которые могут представлять опасность для операционной системы. Пользователи системы, обладающие правом чтения журнала аудита, называются аудиторами.

Необходимость включения в защищенную операционную систему функций аудита обусловлена следующими обстоятельствами:

• обнаружение попыток вторжения является важнейшей задачей системы защиты, поскольку ее решение позволяет минимизировать ущерб от взлома и собирать информацию о методах вторжения;
• подсистема защиты ОС может не отличить случайные ошибки пользователей от злонамеренных действий. Администратор, просматривая журнал аудита, сможет установить, что произошло при вводе пользователем неправильного пароля – ошибка легального пользователя или атака злоумышленника. Если пользователь пытался угадать пароль 20–30 раз – это явная попытка подбора пароля;
• администраторы ОС должны иметь возможность получать информацию не только о текущем состоянии системы, но и о том, как ОС функционировала в недавнем прошлом. Такую возможность обеспечивает журнал аудита;
• если администратор ОС обнаружил, что против системы проведена успешная атака, ему важно выяснить, когда была начата атака и каким образом она осуществлялась. Журнал аудита может содержать всю необходимую информацию.

К числу событий, которые могут представлять опасность для операционной системы, обычно относят следующие:

• вход или выход из системы;
• операции с файлами (открыть, закрыть, переименовать, удалить);
• обращение к удаленной системе;
• смена привилегий или иных атрибутов безопасности (режима доступа, уровня благонадежности пользователя и т. п.).

Если фиксировать в журнале аудита все события, объем регистрационной информации будет расти слишком быстро, что затруднит ее эффективный анализ. Необходимо предусмотреть выборочное протоколирование как в отношении пользователей, так и в отношении событий.

Требования к аудиту

Подсистема аудита операционной системы должна удовлетворять следующим требованиям:

1. Добавлять записи в журнал аудита может только операционная система. Если предоставить это право какому-то физическому пользователю, этот пользователь получит возможность компрометировать других пользователей, добавляя в журнал аудита соответствующие записи.
2. Редактировать или удалять отдельные записи в журнале аудита не может ни один субъект доступа, в том числе и сама ОС.
3. Просматривать журнал аудита могут только пользователи, обладающие соответствующей привилегией.
4. Очищать журнал аудита могут только пользователи-аудиторы. После очистки журнала в него автоматически вносится запись о том, что журнал аудита был очищен, с указанием времени очистки журнала и имени пользователя, очистившего журнал. Операционная система должна поддерживать возможность сохранения журнала аудита перед очисткой в другом файле.
5. При переполнении журнала аудита ОС аварийно завершает работу («зависает»). После перезагрузки работать с системой могут только аудиторы. Операционная система переходит к обычному режиму работы только после очистки журнала аудита.

Для ограничения доступа к журналу аудита должны применяться специальные средства защиты.

Политика аудита.

Политика аудита – это совокупность правил, определяющих то, какие события должны регистрироваться в журнале аудита. Для обеспечения надежной защиты операционной системы в журнале аудита должны обязательно регистрироваться следующие события:

• попытки входа/выхода пользователей из системы;
• попытки изменения списка пользователей;
• попытки изменения политики безопасности, в том числе и политики аудита.

Окончательный выбор того, какие события должны регистрироваться в журнале аудита, а какие не должны, возлагается на аудиторов. При выборе оптимальной политики аудита следует учитывать ожидаемую скорость заполнения журнала аудита. Политика аудита должна оперативно реагировать на изменения в конфигурации операционной системы, в характере хранимой и обрабатываемой информации, а особенно на выявленные попытки атаки операционной системы.

В некоторых ОС подсистема аудита, помимо записи информации о зарегистрированных событиях в специальный журнал, предусматривает возможность интерактивного оповещения аудиторов об этих событиях.

 

Задание для самостоятельной работы:
1. Шаньгин В. Ф. Информационная безопасность. – М.: ДМК Пресс, 2014. , стр. 165-188
2. Владимир Карпов, Константин Коньков. Лекция 15. Основные понятия информационной безопасности. Адрес:
http://www.intuit.ru/studies/courses/2192/31/lecture/996