Регистрация обращений к защищаемой информации.

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

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

1) контроль использования защищаемой информации;

2) выявление попыток несанкционированного доступа к защищае­мой информации;

3) накопление статистических данных о функционировании систем защиты.

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

1. Требования к учету определяют следующие показатели защищенности, которые должны поддерживаться СВТ:

- регистрация

- маркировка документов.

2. КСЗ должен осуществлять регистрацию следующих событий:

а) использование идентификационного и аутентификационного механизма

б) запрос на доступ к защищаемому ресурсу (например, открытие файла, запуск программы);

в) создание и уничтожение объекта;

г) действия, связанные с изменением ПРД.

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

- дата и время;

- субъект, осуществляющий регистрируемое действие;

- тип события (если регистрируется запрос на доступ, то отмечают объект и тип доступа);

- успешно ли осуществилось событие (обслужен запрос на доступ или нет).

КСЗ должен содержать средства выборочного ознакомления с регистрационной информацией.

Для высоких классов защищенности СВТ должна быть предусмотрена РЕГИСТРАЦИЯ всех попыток доступа, всех действий оператора и выделенных субъектов (например, администраторов защиты).

3. КСЗ должен обеспечивать вывод защищаемой информации на документ вместе с ее классификационной меткой.

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

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

Аудит

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

• вход в систему (успешный или нет);

• выход из системы;

• обращение к удаленной системе;

• операции с файлами (открыть, закрыть, переименовать, удалить);

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

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

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

С помощью этого метода можно держать под контролем пользователей, имеющих специфическую репутацию, и реконструировать прошедшие события. «Слежка» важна, в первую очередь, как профилактическое сред­ство. Можно надеяться, что многие злоумышленники воздержатся от нарушений режима безопасности, поскольку знают, что их действия фиксируются. Реконструкция событий позволяет проанализировать слу­чаи нарушений, понять, почему они произошли, оценить размеры ущер­ба и принять меры по недопущению подобных нарушений в будущем.

При протоколировании события необходимо, по крайней мере, записы­вать информацию такого рода:

• дату и время события;

• уникальный идентификатор;

• отмечать пользователя, являющегося инициатором действия;

• тип события;

• результат действия (успех или неудача);

• источник запроса (например, имя терминала);

• имена затронутых объектов (например, открываемых или удаляемых файлов).

• описание изменений, внесенных в базы данных защиты (например, новая метка безопасности объекта);

• метки безопасности субъектов и объектов события.

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

Рис. 3. Местоположение подсистемы аудита в архитектуре ОС

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

Общая схема архитектуры построения системы аудита представлена на рис. 4.

Рис. 4. Архитектура системы аудита

Необходимо подчеркнуть важность не только сбора информации, но и ее регулярного и целенаправленного анализа. В этом плане выгодное положение занимают средства аудита СУБД, поскольку к регистрацион­ной информации могут естественным образом применяться произволь­ные SQL-запросы.