Информация. ИНФОРМАЦИОННАЯ БЕЗОПАСНОСТЬ. В. Ф. Шаньгининформационная безопасность компьютерных систем
 Скачать 5.69 Mb.
|
|
Глава 8 ОБЕСПЕЧЕНИЕ БЕЗОПАСНОСТИ ОПЕРАЦИОННЫХ СИСТЕМ 8.1. Проблемы обеспечения безопасности ОС Большинство программных средств защиты информации яв ляются прикладными программами. Для их выполнения требует ся поддержка ОС. Окружение, в котором функционирует ОС, называется доверенной вычислительной базой (ДВБ). ДВБ включа ет в себя полный набор элементов, обеспечивающих информа ционную безопасность: ОС, программы, сетевое оборудование, средства физической защиты и даже организационные процеду ры. Краеугольным камнем этой пирамиды является защищен ная ОС. 8 .1 .1 . У грозы безопасности О С Организация эффективной и надежной защиты ОС невоз можна без предварительного анализа возможных угроз ее безо пасности. Угрозы безопасности ОС существенно зависят от усло вий эксплуатации системы, от того, какая информация хранится и обрабатывается в системе, и т. д. Например, если ОС использу ется для организации электронного документооборота, наиболее опасны угрозы, связанные с несанкционированным доступом (НСД) к файлам. Если же ОС используется как платформа про вайдера Internet-услуг, очень опасны атаки на сетевое программ ное обеспечение ОС. Угрозы безопасности ОС можно классифицировать по раз личным аспектам их реализации [56]. 1. По цели атаки: • несанкционированное чтение информации; • несанкционированное изменение информации; • несанкционированное уничтожение информации; • полное или частичное разрушение ОС. 2. По принципу воздействия на операционную систему: • использование известных (легальных) каналов получе ния информации; например угроза несанкционирован ного чтения файла, доступ пользователей к которому оп ределен некорректно, т. е. разрешен доступ пользовате лю, которому согласно политике безопасности доступ должен быть запрещен; • использование скрытых каналов получения информации; например угроза использования злоумышленником не документированных возможностей ОС; • создание новых каналов получения информации с помо щью программных закладок. 3. По типу используемой злоумышленником уязвимости защиты: • неадекватная политика безопасности, в том числе и ошибки администратора системы; • ошибки и недокументированные возможности программ ного обеспечения ОС, в том числе и так называемые люки — случайно или преднамеренно встроенные в систе му «служебные входы», позволяющие обходить систему защиты; • ранее внедренная программная закладка. 4. По характеру воздействия на операционную систему: • активное воздействие — несанкционированные действия злоумышленника в системе; • пассивное воздействие — несанкционированное наблю дение злоумышленника за процессами, происходящими в системе. Угрозы безопасности ОС можно также классифицировать по таким признакам, как: способ действий злоумышленника, ис пользуемые средства атаки, объект атаки, способ воздействия на объект атаки, состояние атакуемого объекта ОС на момент атаки. ОС может подвергнуться следующим типичным атакам: • сканированию файловой системы. Злоумышленник просмат ривает файловую систему компьютера и пытается прочесть (или скопировать) все файлы подряд. Рано или поздно об- наруживается хотя бы одна ошибка администратора. В ре зультате злоумышленник получает доступ к информации, который должен быть ему запрещен; • подбору пароля. Существуют несколько методов подбора па ролей пользователей: — тотальный перебор; — тотальный перебор, оптимизированный по статистике встречаемости символов или с помощью словарей; — подбор пароля с использованием знаний о пользователе (его имени, фамилии, даты рождения, номера телефона и т. д.); • краже ключевой информации. Злоумышленник может подсмот реть пароль, набираемый пользователем, или восстановить на бираемый пользователем пароль по движениям его рук на клавиатуре. Носитель с ключевой информацией (смарт-карта, Touch Memory и т. д.) может быть просто украден; • сборке мусора. Во многих ОС информация, уничтоженная пользователем, не уничтожается физически, а помечается как уничтоженная (так называемый мусор). Злоумышлен ник восстанавливает эту информацию, просматривает ее и копирует интересующие его фрагменты; • превышению полномочий. Злоумышленник, используя ошиб ки в программном обеспечении ОС или политике безопас ности, получает полномочия, превышающие те, которые ему предоставлены в соответствии с политикой безопасно сти. Обычно это достигается путем запуска программы от имени другого пользователя; • программным закладкам. Программные закладки, внедряе мые в ОС, не имеют существенных отличий от других классов программных закладок; • жадным программам — это программы, преднамеренно за хватывающие значительную часть ресурсов компьютера, в результате чего другие программы не могут выполняться или выполняются крайне медленно. Запуск жадной про граммы может привести к краху ОС [56]. 8 - / . 2 . Понятие защ ищ енной О С Операционную систему называют защищенной, если она пре дусматривает средства защиты от основных классов угроз. Защи щенная ОС обязательно должна содержать средства разграниче ния доступа пользователей к своим ресурсам, а также средства проверки подлинности пользователя, начинающего работу с ОС. Кроме того, защищенная ОС должна содержать средства проти водействия случайному или преднамеренному выводу ОС из строя. Если ОС предусматривает защиту не от всех основных клас сов угроз, а только от некоторых, такую ОС называют частично защищенной [56, 88]. Подходы к построению защищенных ОС Существуют два основных подхода к созданию защищенных ОС — фрагментарный и комплексный. При фрагментарном подходе вначале организуется защита от одной угрозы, затем от другой и т. д. Примером фрагментарного подхода может слу жить ситуация, когда за основу берется незащищенная ОС (на пример, Windows 98), на нее устанавливаются антивирусный па кет, система шифрования, система регистрации действий поль зователей и т. д. При применении фрагментарного подхода подсистема защи ты ОС представляет собой набор разрозненных программных продуктов, как правило, от разных производителей. Эти про граммные средства работают независимо друг от друга, при этом практически невозможно организовать их тесное взаимодейст вие. Кроме того, отдельные элементы такой подсистемы защиты могут некорректно работать в присутствии друг друга, что при водит к резкому снижению надежности системы. При комплексном подходе защитные функции вносятся в ОС на этапе проектирования архитектуры ОС и являются ее неотъ емлемой частью. Отдельные элементы подсистемы защиты, соз данной на основе комплексного подхода, тесно взаимодействуют друг с другом при решении различных задач, связанных с орга низацией защиты информации, поэтому конфликты между ее отдельными компонентами практически невозможны. Подсисте ма защиты, созданная на основе комплексного подхода, может быть устроена так, что при фатальных сбоях в функционирова нии ее ключевых элементов она вызывает крах ОС, что не по зволяет злоумышленнику отключать защитные функции систе мы. При фрагментарном подходе такая организация подсистемы защиты невозможна. Как правило, подсистему защиты ОС, созданную на основе комплексного подхода, проектируют так, чтобы отдельные ее элементы были заменяемы. Соответствующие программные мо дули могут быть заменены другими модулями. Административные меры защиты Программно-аппаратные средства защиты ОС обязательно должны дополняться административными мерами зашиты. Без постоянной квалифицированной поддержки со стороны адми нистратора даже надежная программно-аппаратная защита мо жет давать сбои. Перечислим основные административные меры защиты. 1. Постоянный контроль корректности функционирования ОС, особенно ее подсистемы защиты. Такой контроль удобно орга низовать, если ОС поддерживает автоматическую регистрацию наиболее важных событий {event logging) в специальном журнале. 2. Организация и поддержание адекватной политики безопас ности. Политика безопасности ОС должна постоянно корректи роваться, оперативно реагируя на попытки злоумышленников преодолеть защиту ОС, а также на изменения в конфигурации ОС, установку и удаление прикладных программ. 3. Инструктирование пользователей операционной системы о необходимости соблюдения мер безопасности при работе с ОС и контроль за соблюдением этих мер. 4. Регулярное создание и обновление резервных копий программ и данных ОС. 5. Постоянный контроль изменений в конфигурационных данных и политике безопасности ОС. Информацию об этих изменениях целесообразно хранить на неэлектронных носителях информа ции, для того чтобы злоумышленнику, преодолевшему защиту ОС, было труднее замаскировать свои несанкционированные действия. В конкретных ОС могут потребоваться и другие администра тивные меры защиты информации [56]. Адекватная политика безопасности Выбор и поддержание адекватной политики безопасности являются одной из наиболее важных задач администратора ОС. Если принятая в ОС политика безопасности неадекватна, то это может привести к НСД злоумышленника к ресурсам системы и к снижению надежности функционирования ОС. Известно утверждение: чем лучше защищена ОС, тем труд нее с ней работать пользователям и администраторам. Это обу словлено следующими факторами: • система защиты не всегда способна определить, является ли некоторое действие пользователя злонамеренным. По этому система защиты либо не пресекает некоторые виды НСД, либо запрещает некоторые вполне легальные дейст вия пользователей. Чем выше защищенность системы, тем шире класс тех легальных действий пользователей, которые рассматриваются подсистемой защиты как несанкциониро ванные; • любая система, в которой предусмотрены функции защиты информации, требует от администраторов определенных усилий, направленных на поддержание адекватной полити ки безопасности. Чем больше в ОС защитных функций, тем больше времени и средств нужно тратить на поддержа ние защиты; • подсистема защиты ОС, как и любой другой программный пакет, потребляет аппаратные ресурсы компьютера. Чем сложнее устроены защитные функции ОС, тем больше ре сурсов компьютера (процессорного времени, оперативной памяти и др.) затрачивается на поддержание функциониро вания подсистемы защиты и тем меньше ресурсов остается на долю прикладных программ; • поддержание слишком жесткой политики безопасности может негативно сказаться на надежности функционирова ния ОС. Чрезмерно жесткая политика безопасности может привести к трудно выявляемым ошибкам и сбоям в про цессе функционирования ОС и даже к ее краху [56, 88]. Оптимальная адекватная политика безопасности — это такая политика безопасности, которая не только не позволяет зло умышленникам выполнять несанкционированные действия, но и не приводит к описанным выше негативным эффектам. Адекватная политика безопасности определяется не только архитектурой ОС, но и ее конфигурацией, установленными при кладными программами и т. д. Формирование и поддержание адекватной политики безопасности ОС можно разделить на ряд этапов. 1. Анализ угроз. Администратор ОС рассматривает возможные угрозы безопасности данного экземпляра ОС. Среди возможных угроз выделяются наиболее опасные, защите от которых нужно уделять максимум средств. 2. Формирование требований к политике безопасности. Адми нистратор определяет, какие средства и методы будут приме няться для защиты от тех или иных угроз. Например, защиту от НСД к некоторому объекту ОС можно решать либо средствами разграничения доступа, либо криптографическими средствами, либо используя некоторую комбинацию этих средств. 3. Формальное определение политики безопасности. Админист ратор определяет, как конкретно должны выполняться требова ния, сформулированные на предыдущем этапе. Формулируются необходимые требования к конфигурации ОС, а также требова ния к конфигурации дополнительных пакетов зашиты, если ус тановка таких пакетов необходима. Результатом данного этапа является развернутый перечень настроек конфигурации ОС и дополнительных пакетов защиты с указанием того, в каких си туациях, какие настройки должны быть установлены. 4. Претворение в жизнь политики безопасности. Задачей дан ного этапа является приведение конфигурации ОС и дополни тельных пакетов защиты в соответствие с политикой безопасно сти, формально определенной на предыдущем этапе. 5. Поддержание и коррекция политики безопасности. В за дачу администратора на данном этапе входит контроль со блюдения политики безопасности и внесение в нее необходи мых изменений по мере появления изменений в функциони ровании ОС. Специальных стандартов защищенности ОС не существует. Для оценки защищенности ОС используются стандарты, разра ботанные для компьютерных систем вообще. Как правило, сер тификация ОС по некоторому классу защиты сопровождается составлением требований к адекватной политике безопасности, при безусловном выполнении которой защищенность конкрет ного экземпляра ОС будет соответствовать требованиям соответ ствующего класса защиты. Определяя адекватную политику безопасности, администра тор ОС должен в первую очередь ориентироваться на защиту ОС от конкретных угроз ее безопасности [56, 88]. 8.2. Архитектура подсистемы защиты ОС 8 .2 . U О сновны е ф ункции подсистемы защиты О С Подсистема защиты ОС выполняет следующие основные функции. 1. Идентификация и аутентификация. Ни один пользователь не может начать работу с ОС, не идентифицировав себя и не предоставив системе аутентифицирующую информацию, под тверждающую, что пользователь действительно является тем, кем он себя заявляет. 2. Разграничение доступа. Каждый пользователь системы име ет доступ только к тем объектам ОС, к которым ему предоставлен доступ в соответствии с текущей политикой безопасности. 3. Аудит. ОС регистрирует в специальном журнале события, потенциально опасные для поддержания безопасности системы. 4. Управление политикой безопасности. Политика безопасно сти должна постоянно поддерживаться в адекватном состоянии, т. е. должна гибко реагировать на изменения условий функцио нирования ОС. Управление политикой безопасности осуществ ляется администраторами системы с использованием соответст вующих средств, встроенных в ОС. 5. Криптографические функции. Защита информации немыс лима без использования криптографических средств защиты. Шифрование используется в ОС при хранении и передаче по ка налам связи паролей пользователей и некоторых других данных, критичных для безопасности системы. 6. Сетевые функции. Современные ОС, как правило, работа ют не изолированно, а в составе локальных и/или глобальных компьютерных сетей. ОС компьютеров, входящих в одну сеть, взаимодействуют между собой для решения различных задач, в том числе и задач, имеющих прямое отношение к защите инфор мации. Подсистема защиты обычно не представляет собой единый программный модуль. Как правило, каждая из перечисленных функций подсистемы защиты решается одним или несколькими программными модулями. Некоторые функции встраиваются непосредственно в ядро ОС. Между различными модулями под системы защиты должен существовать четко определенный ин терфейс, используемый при взаимодействии модулей для реше ния общих задач. В таких ОС, как Windows ХР, подсистема защиты четко вы деляется в общей архитектуре ОС, в других, как UNIX, защит ные функции распределены практически по всем элементам ОС. Однако любая ОС, удовлетворяющая стандарту защищенности, должна содержать подсистему защиты, выполняющую все выше перечисленные функции. Обычно подсистема защиты ОС до пускает расширение дополнительными программными модуля ми [56, 88]. 8 .2 .2 . Идентификация, аутентификация и авторизация субъектов доступа В защищенной ОС любой пользователь (субъект доступа), перед тем как начать работу с системой, должен пройти иденти фикацию, аутентификацию и авторизацию. Субъектом доступа (или просто субъектом) называют любую сущность, способную инициировать выполнение операций над элементами ОС. В ча стности, пользователи являются субъектами доступа. Идентификация субъекта доступа заключается в том, что субъект сообщает ОС идентифицирующую информацию о себе (имя, учетный номер и т. д.) и таким образом идентифицирует себя. Для того чтобы установить, что пользователь именно тот, за кого себя выдает, в информационных системах предусмотрена процедура аутентификации, задача которой — предотвращение доступа к системе нежелательных лиц. Аутентификация субъекта доступа заключается в том, что субъект предоставляет ОС помимо идентифицирующей инфор мации еще и аутентифицирующую информацию, подтверждаю щую, что он действительно является тем субъектом доступа, к которому относится идентифицирующая информация (см. гл. 7). Авторизация субъекта доступа происходит после успешной идентификации и аутентификации. При авторизации субъекта ОС выполняет действия, необходимые для того, чтобы субъект мог начать работу в системе. Например, авторизация пользовате ля в операционной системе UNIX включает в себя порождение процесса, являющегося операционной оболочкой, с которой в дальнейшем будет работать пользователь. В ОС Windows NT ав торизация пользователя включает в себя создание маркера досту па пользователя, создание рабочего стола и запуск на нем от име ни авторизуемого пользователя процесса Userinit, инициализи рующего индивидуальную программную среду пользователя. Авторизация субъекта не относится напрямую к подсистеме за щиты ОС. В процессе авторизации решаются технические зада чи, связанные с организацией начала работы в системе уже иден тифицированного и аутентифицированного субъекта доступа. С точки зрения обеспечения безопасности ОС процедуры идентификации и аутентификации являются весьма ответствен ными. Действительно, если злоумышленник сумел войти в систе му от имени другого пользователя, он легко получает доступ ко всем объектам ОС, к которым имеет доступ этот пользователь. Если при этом подсистема аудита генерирует сообщения о собы тиях, потенциально опасных для безопасности ОС, то в журнал аудита записывается не имя злоумышленника, а имя пользовате ля, от имени которого злоумышленник работает в системе. Методы идентификации и аутентификации с помощью име ни и пароля, внешних носителей ключевой информации, био метрических характеристик пользователей подробно рассмотре ны в гл. 7. 8 .2 . 3 . Р азграничени е доступа к объектам О С Основными понятиями процесса разграничения доступа к объектам ОС являются объект доступа, метод доступа к объекту и субъект доступа. Объектом доступа (или просто объектом) называют любой элемент ОС, доступ к которому пользователей и других субъек тов доступа может быть произвольно ограничен. Возможность доступа к объектам ОС определяется не только архитектурой ОС, но и текущей политикой безопасности. Под объектами дос тупа понимают как ресурсы оборудования (процессор, сегменты памяти, принтер, диски и ленты), так и программные ресурсы (файлы, программы, семафоры), т. е. все то, доступ к чему кон тролируется. Каждый объект имеет уникальное имя, отличающее его от других объектов в системе, и каждый из них может быть доступен через хорошо определенные и значимые операции. Методом доступа к объекту называется операция, определен ная для объекта. Тип операции зависит от объектов. Например, процессор может только выполнять команды, сегменты памяти могут быть записаны и прочитаны, считыватель магнитных карт может только читать, а для файлов могут быть определены мето ды доступа «чтение», «запись» и «добавление» (дописывание ин формации в конец файла). Субъектом доступа называют любую сущность, способную инициировать выполнение операций над объектами (обращаться к объектам по некоторым методам доступа). Обычно полагают, что множество субъектов доступа и множество объектов доступа не пересекаются. Иногда к субъектам доступа относят процессы, выполняющиеся в системе. Однако логичнее считать субъектом доступа именно пользователя, от имени которого выполняется процесс. Естественно, под субъектом доступа подразумевают не физического пользователя, работающего с компьютером, а «ло гического» пользователя, от имени которого выполняются про цессы ОС. Таким образом, объект доступа — это то, к чему осуществля ется доступ, субъект доступа — это тот, кто осуществляет дос туп, и метод доступа — это то, как осуществляется доступ. Для объекта доступа может быть определен владелец — субъ ект, которому принадлежит данный объект и который несет от ветственность за конфиденциальность содержащейся в объекте информации, а также за целостность и доступность объекта. Обычно владельцем объекта автоматически назначается субъ ект, создавший данный объект, в дальнейшем владелец объекта может быть изменен с использованием соответствующего метода доступа к объекту. На владельца, как правило, возлагается ответ ственность за корректное ограничение прав доступа к данному объекту других субъектов. Правом доступа к объекту называют право на выполнение доступа к объекту по некоторому методу или группе методов. Например, если пользователь имеет возможность читать файл, говорят, что он имеет право на чтение этого файла. Говорят, что субъект имеет некоторую привилегию, если он имеет право на доступ по некоторому методу или группе методов ко всем объек там ОС, поддерживающим данный метод доступа. Разграничением доступа субъектов к объектам является сово купность правил, определяющая для каждой тройки субъ ект—объект—метод, разрешен ли доступ данного субъекта к дан ному объекту по данному методу. При избирательном разграни чении доступа возможность доступа определена однозначно для каждой тройки субъект—объект—метод, при полномочном раз граничении доступа ситуация несколько сложнее. Субъекта доступа называют суперпользователем, если он име ет возможность игнорировать правила разграничения доступа к объектам. Правила разграничения доступа, действующие в ОС, уста навливаются администраторами системы при определении те кущей политики безопасности. За соблюдением этих правил субъектами доступа следит монитор ссылок — часть подсистемы защиты ОС. Правила разграничения доступа должны удовлетворять сле дующим требованиям. 1. Соответствовать аналогичным правилам, принятым в орга низации, в которой установлена ОС. Иными словами, если со гласно правилам организации доступ пользователя к некоторой информации считается несанкционированным, этот доступ дол жен быть ему запрещен. 2. Не должны допускать разрушающие воздействия субъек тов доступа на ОС, выражающиеся в несанкционированном из менении, удалении или другом воздействии на объекты, жизнен но важные для нормальной работы ОС. 3. Любой объект доступа должен иметь владельца. Недопус тимо присутствие ничейных объектов — объектов, не имеющих владельца. 4. Не допускать присутствия недоступных объектов — объек тов, к которым не может обратиться ни один субъект доступа ни по одному методу доступа. 5. Не допускать утечки конфиденциальной информации. Существуют две основные модели разграничения доступа: • избирательное (дискреционное) разграничение доступа; • полномочное (мандатное) разграничение доступа. При избирательном разграничении доступа определенные опе рации над конкретным ресурсом запрещаются или разрешаются субъектам или группам субъектов. Большинство ОС реализуют именно избирательное разграничение доступа (discretionary access control). Полномочное разграничение доступа заключается в том, что все объекты могут иметь уровни секретности, а все субъекты де лятся на группы, образующие иерархию в соответствии с уров нем допуска к информации. Иногда эту модель называют моде лью многоуровневой безопасности, предназначенной для хране ния секретов. Избирательное разграничение доступа Система правил избирательного разграничения доступа фор мулируется следующим образом. 1. Для любого объекта ОС существует владелец. 2. Владелец объекта может произвольно ограничивать доступ других субъектов к данному объекту. 3.Для каждой тройки субъект—объект—метод возможность доступа определена однозначно. 4. Существует хотя бы один привилегированный пользова тель (администратор), имеющий возможность обратиться к лю бому объекту по любому методу доступа. Привилегированный пользователь не может игнорировать разграничение доступа к объектам. Например, в Windows NT ад министратор для обращения к чужому объекту (принадлежащему другому субъекту) должен сначала объявить себя владельцем этого объекта, использовав привилегию администратора объяв лять себя владельцем любого объекта, затем дать себе необходи мые права и только после этого может обратиться к объекту. По следнее требование введено для реализации механизма удаления потенциально недоступных объектов. При создании объекта его владельцем назначается субъект, создавший данный объект. В дальнейшем субъект, обладающий необходимыми правами, может назначить объекту нового вла дельца. При этом субъект, изменяющий владельца объекта, мо жет назначить новым владельцем объекта только себя. Такое ог раничение вводится для того, чтобы владелец объекта не мог от дать «владение» объектом другому субъекту и тем самым снять с себя ответственность за некорректные действия с объектом. Для определения прав доступа субъектов к объектам при из бирательном разграничении доступа используются такие поня тия, как матрица доступа и домен безопасности. С концептуальной точки зрения текущее состояние прав доступа при избирательном разграничении доступа описывается матрицей, в строках которой перечислены субъекты доступа, в столбцах — объекты доступа, а в ячейках — операции, которые субъект может выполнить над объектом. Домен безопасности (protection domain) определяет набор объектов и типов операций, которые могут производиться над каждым объектом ОС. Возможность в ы п о л н я т ь операции над объектом есть право доступа, каждое из которых есть упорядоченная пара доступа. Например, если домен D имеет право доступа {read, write}>, это означает, что процесс, выполняемый в доме не D, может читать или писать в файл F, но не может выполнять других операций над этим объектом (рис. 8.1). Рис. 8.1. Специфицирование прав доступа к ресурсам Связь конкретных субъектов, функционирующих в ОС, мо жет быть организована следующим образом: • каждый пользователь может быть доменом. В этом случае набор объектов, к которым может быть организован дос туп, зависит от идентификации пользователя; • каждый процесс может быть доменом. В этом случае на бор доступных объектов определяется идентификацией процесса; • каждая процедура может быть доменом. В этом случае на бор доступных объектов соответствует локальным перемен ным, определенным внутри процедуры. Заметим, что, ко гда процедура выполнена, происходит смена домена. Модель безопасности, специфицированная выше (см. рис. 8.1), имеет вид матрицы и называется матрицей доступа. Столбцы этой матрицы представляют собой объекты, строки — субъекты. В каждой ячейке матрицы хранится совокупность прав доступа, предоставленных данному субъекту на данный объект. Поскольку реальная матрица доступа очень велика (типичный объем для современной ОС составляет несколько десятков мега байтов), матрицу доступа никогда не хранят в системе в явном виде. В общем случае эта матрица будет разреженной, т. е. боль шинство ее клеток будут пустыми. Матрицу доступа можно раз ложить по столбцам, в результате чего получаются списки прав доступа ACL (access control list). В результате разложения матри цы по строкам получаются мандаты возможностей (capability list, или capability tickets). Список прав доступа ACL. Каждая колонка в матрице может быть реализована как список доступа для одного объекта. Оче видно, что пустые клетки могут не учитываться. В результате для каждого объекта имеем список упорядоченных пар ми прав для данного объекта. Элементами списка прав доступа ACL могут быть процессы, пользователи или группы пользователей. При реализации широ ко применяется предоставление доступа по умолчанию для пользователей, права которых не указаны. Например, в ОС Unix все субъекты-пользователи разделены на три группы (владелец, группа и остальные), и для членов каждой группы контролиру ются операции чтения, записи и исполнения (rwx). В итоге име ем ACL — 9-битный код, который является атрибутом разнооб разных объектов Unix. Мандаты возможностей. Как отмечалось выше, если матрицу доступа хранить по строкам, т. е. если каждый субъект хранит список объектов и для каждого объекта — список допустимых операций, то такой способ хранения называется «мандаты воз можностей» или «перечни возможностей» (capability list). Каждый пользователь обладает несколькими мандатами и может иметь право передавать их другим. Мандаты могут быть рассеяны по системе и вследствие этого представлять большую угрозу для безопасности, чем списки контроля доступа. Их хранение долж но быть тщательно продумано. Избирательное разграничение доступа — наиболее распро страненный способ разграничения доступа. Это обусловлено сравнительной простотой его реализации и необременительно стью правил такого разграничения доступа для пользователей. Главное достоинство избирательного разграничения доступа — гибкость; основные недостатки — рассредоточенность управле ния и сложность централизованного контроля. Вместе с тем, защищенность ОС, подсистема защиты кото рой реализует только избирательное разграничение доступа, в некоторых случаях может оказаться недостаточной. В частности, в США запрещено хранить информацию, содержащую государ ственную тайну, в компьютерных системах, поддерживающих только избирательное разграничение доступа. Расширением модели избирательного разграничения доступа является изолированная (или замкнутая) программная среда. При использовании изолированной программной среды пра ва субъекта на доступ к объекту определяются не только правами и привилегиями субъекта, но и процессом, с помощью которого субъект обращается к объекту. Можно, например, разрешить об ращаться к файлам с расширением .doc только программам Word, Word Viewer и WPview. Изолированная программная среда существенно повышает защищенность операционной системы от разрушающих про граммных воздействий, включая программные закладки и ком пьютерные вирусы. Кроме того, при использовании данной мо дели повышается защищенность целостности данных, храня щихся в системе. Полномочное разграничение доступа с контролем информационных потоков Полномочное, или мандатное, разграничение доступа (man datory access control) обычно применяется в совокупности с из бирательным разграничением доступа. Рассмотрим именно та кой случай [56]. Правила разграничения доступа в данной моде ли формулируются следующим образом. 1. Для любого объекта ОС существует владелец. 2. Владелец объекта может произвольно ограничивать доступ других субъектов к данному объекту. 3. Для каждой четверки субъект—объект—метод—процесс возможность доступа определена однозначно в каждый момент времени. При изменении состояния процесса со временем воз можность предоставления доступа также может измениться. Вместе с тем, в каждый момент времени возможность доступа определена однозначно. Поскольку права процесса на доступ к объекту меняются с течением времени, они должны проверяться не только при открытии объекта, но и перед выполнением над объектом таких операций, как чтение и запись. 4. Существует хотя бы один привилегированный пользова тель (администратор), имеющий возможность удалить любой объект. 5. В множестве объектов выделяется множество объектов полномочного разграничения доступа. Каждый объект полномоч ного разграничения доступа имеет гриф секретности. Чем выше числовое значение грифа секретности, тем секретнее объект. Ну левое значение грифа секретности означает, что объект несекре тен. Если объект не является объектом полномочного разграни чения доступа или если объект несекретен, администратор мо жет обратиться к нему по любому методу, как и в предыдущей модели разграничения доступа. 6. Каждый субъект доступа имеет уровень допуска. Чем выше числовое значение уровня допуска, тем больший допуск имеет субъект. Нулевое значение уровня допуска означает, что субъект не имеет допуска. Обычно ненулевое значение допуска назнача ется только субъектам-пользователям и не назначается субъек там, от имени которых выполняются системные процессы. 7. Доступ субъекта к объекту должен быть запрещен незави симо от состояния матрицы доступа, если: • объект является объектом полномочного разграничения доступа; • гриф секретности объекта строго выше уровня допуска субъекта, обращающегося к нему; • субъект открывает объект в режиме, допускающем чтение информации. Это правило называют правилом NRU (Not Read Up — не чи тать выше). 8. Каждый процесс ОС имеет уровень конфиденциальности, равный максимуму из грифов секретности объектов, открытых процессом на протяжении своего существования. Уровень кон фиденциальности фактически представляет собой гриф секрет ности информации, хранящейся в оперативной памяти процесса. 9. Доступ субъекта к объекту должен быть запрещен незави симо от состояния матрицы доступа, если: • объект является объектом полномочного разграничения доступа; • гриф секретности объекта строго ниже уровня конфиден циальности процесса, обращающегося к нему; • субъект собирается записывать в объект информацию, Это правило предотвращает утечку секретной информации; его называют правило NWD (Not Write Down — не записывать ниже). 10. Понизить гриф секретности объекта полномочного раз граничения доступа может только субъект, который: • имеет доступ к объекту согласно правилу 7; • обладает специальной привилегией, позволяющей ему по нижать грифы секретности объектов. При использовании данной модели разграничения доступа существенно страдает производительность ОС, поскольку права доступа к объекту должны проверяться не только при открытии объекта, но и при каждой операции чтение/запись. Кроме того, эта модель создает пользователям определенные неудобства: если уровень конфиденциальности процесса строго выше нуля, то вся информация в памяти процесса фактически является сек ретной и не может быть записана в несекретный объект. Если процесс одновременно работает с двумя объектами, только один из которых является секретным, то он не может за писывать информацию из памяти во второй объект. Эта пробле ма решается посредством использования специального про граммного интерфейса API для работы с памятью. Области па мяти, выделяемые процессам, могут быть описаны как объекты полномочного разграничения доступа, после чего им могут на значаться грифы секретности. При чтении секретного файла процесс должен считать со держимое такого файла в секретную область памяти, используя для этого функции ОС, гарантирующие невозможность утечки информации. Для работы с секретной областью памяти процесс также должен использовать специальные функции. Поскольку утечка информации из секретных областей памяти в память про цесса невозможна, считывание процессом секретной информа ции в секретные области памяти не отражается на уровне кон фиденциальности процесса. Если же процесс считывает секрет ную информацию в область памяти, не описанную как объект полномочного разграничения доступа, повышается уровень кон фиденциальности процесса. Из вышеизложенного следует, что пользователи ОС, реали зующих данную модель разграничения доступа, вынуждены использовать ПО, разработанное с учетом этой модели. В про тивном случае они будут испытывать серьезные проблемы в процессе работы с объектами ОС, имеющими ненулевой гриф секретности. Каждая из рассмотренных моделей разграничения доступа имеет свои достоинства и недостатки. В большинстве ситуаций применение избирательного разгра ничения доступа наиболее эффективно. Изолированную про граммную среду целесообразно использовать в случаях, когда важно обеспечить целостность программ и данных ОС. Полно мочное разграничение доступа с контролем информационных потоков следует применять в тех случаях, когда для организации чрезвычайно важно обеспечение защищенности системы от не санкционированной утечки информации. В остальных ситуаци ях применение этой модели нецелесообразно из-за резкого ухуд шения эксплуатационных качеств ОС. 8 .2 .4 . Аудит Процедура аудита применительно к ОС заключается в реги страции в специальном журнале, называемом журналом аудита или журналом безопасности, событий, которые могут представ лять опасность для ОС. Пользователи системы, обладающие правом чтения журнала аудита, называются аудиторами. Необходимость включения в защищенную ОС функций ау дита обусловлена следующими обстоятельствами: • обнаружение попыток вторжения является важнейшей зада чей системы защиты, поскольку ее решение позволяет ми нимизировать ущерб от взлома и собирать информацию о методах вторжения; • подсистема защиты ОС может не отличить случайные ошибки пользователей от злонамеренных действий. Адми нистратор, просматривая журнал аудита, сможет устано вить, что произошло при вводе пользователем неправильно го пароля — ошибка легального пользователя или атака зло умышленника. Если пользователь пытался угадать пароль 20—30 раз, то это явная попытка подбора пароля; • администраторы ОС должны иметь возможность получать информацию не только о текущем состоянии системы, но и о том, как ОС функционировала в недавнем прошлом. Такую возможность обеспечивает журнал аудита; • если администратор ОС обнаружил, что против системы проведена успешная атака, ему важно выяснить, когда была начата атака и каким образом она осуществлялась. Журнал аудита может содержать всю необходимую информацию. К числу событий, которые могут представлять опасность для ОС, обычно относят следующие: • вход или выход из системы; • операции с файлами (открыть, закрыть, переименовать, удалить); • обращение к удаленной системе; • смену привилегий или иных атрибутов безопасности (режи ма доступа, уровня благонадежности пользователя и т. п.). Если фиксировать в журнале аудита все события, объем ре гистрационной информации будет расти слишком быстро, что затруднит ее эффективный анализ. Необходимо предусмотреть выборочное протоколирование как в отношении пользователей, так и в отношении событий. Требования к аудиту. Подсистема аудита ОС должна удовле творять следующим требованиям. 1. Добавлять записи в журнал аудита может только ОС. Если предоставить это право какому-то физическому пользователю, этот пользователь получит возможность компрометировать дру гих пользователей, добавляя в журнал аудита соответствующие записи. 2. Редактировать или удалять отдельные записи в журнале ау дита не может ни один субъект доступа, в том числе и сама ОС. 3. Просматривать журнал аудита могут только пользователи, обладающие соответствующей привилегией. 4. Очищать журнал аудита могут только пользователи-ауди торы. После очистки журнала в него автоматически вносится за пись о том, что журнал аудита был очищен, с указанием времени очистки журнала и имени пользователя, очистившего журнал. ОС должна поддерживать возможность сохранения журнала ау дита перед очисткой в другом файле. 5. При переполнении журнала аудита ОС аварийно заверша ет работу («зависает»). После перезагрузки работать с системой могут только аудиторы. ОС переходит к обычному режиму рабо ты только после очистки журнала аудита. Для ограничения доступа к журналу аудита должны приме няться специальные средства защиты. Политика аудита — это совокупность правил, определяющих, какие события должны регистрироваться в журнале аудита. Для обеспечения надежной защиты ОС в журнале аудита должны обязательно регистрироваться следующие события: • попытки входа/выхода пользователей из системы; • попытки изменения списка пользователей; • попытки изменения политики безопасности, в том числе и политики аудита. Окончательный выбор событий, которые должны регистри роваться в журнале аудита, возлагается на аудиторов. При выбо ре оптимальной политики аудита следует учитывать ожидаемую скорость заполнения журнала аудита. Политика аудита должна оперативно реагировать на изменения в конфигурации ОС, в ха рактере хранимой и обрабатываемой информации и особенно на выявленные попытки атаки ОС. В некоторых ОС подсистема аудита помимо записи инфор мации о зарегистрированных событиях в специальный журнал предусматривает возможность интерактивного оповещения ау диторов об этих событиях. |