Аудит и учет использования системы защиты

Авторизация и разграничение доступа к объектам операционной системы

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

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

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

Очевидно, что процессу может быть разрешен доступ только к тем ресурсам, к которым он имеет авторизованный доступ. Желательно добиться того, чтобы он имел доступ только к тем ресурсам, которые ему нужны для выполнения его задачи. Это требование имеет отношение только к принципу минимизации привилегий, полезному с точки зрения ограничения количества повреждений, которые процесс может нанести системе. Hапример, когда процесс P вызывает процедуру А, ей должен быть разрешен доступ только к переменным и формальным параметрам, переданным ей, она должна быть не в состоянии влиять на другие переменные процесса. Аналогично компилятор не должен оказывать влияния на произвольные файлы, а только на их хорошо определенное подмножество (типа исходных файлов, листингов и др.), имеющих отношение к компиляции. С другой стороны, компилятор может иметь личные файлы, используемые для оптимизационных целей, к которым процесс Р не имеет доступа.

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

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

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

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

Таблица 1. Специфицирование прав доступа к ресурсам

№ п/п	Объект Домен	F1	F2	F3	Printer
1.	D1	Read
2.	D2				Print
3.	D3		Read	Execute
4.	D4	Read Write		Read Write

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

Заметим, что домен может быть реализован различными способами:

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

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

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

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

Например, в ОС семейства Unix домен связан с пользователем. Переключение доменов соответствует смене пользователя. Это изменение реализуется через файловую систему.

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

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

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

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

Дата добавления: 2014-12-08