Файл: Федеральное государственное бюджетное образовательное учреждение высшего образования санктпетербургский.pdf

защищёнными элементами модели. Каждый объект уникально заражен именем объекта; M - матрица доступа. Значение элемента матрицы M [S, O] обеспечивает права доступа субъекта S к объекту O.
Права доступа регулируют доступ субъекта S к различным типам объектов доступа. В частности, права доступа субъектов к файловым объектам обычно определяются как чтение (R), запись (W) и выполнение (E).
Основой реализации управления доступом является анализ строки матрицы доступа при обращении субъекта к объекту. При этом проверяется строка матрицы, соответствующая объекту, и анализируется, разрешены ли ей права доступа для субъекта или нет. На основании этого принимается решение о предоставлении доступа.
При всей наглядности и гибкости возможных настроек разграничитель- ной политики доступа к ресурсам, матричным моделям присущи серьезные недостатки. Основной из них — это излишне детализированный уровень описания отношений субъектов и объектов. Из-за этого усложняется процедура администрирования системы защиты. Причем это происходит как при задании настроек, так и при поддержании их в актуальном состоянии при включении в схему разграничения доступа новых субъектов и объектов. Как следствие, усложнение администрирования может приводить к возникновению ошибок.
Многоуровневые (обязательные) модели. Для устранения недостатков матричных моделей были разработаны так называемые многоуровневые модели защиты, классическими примерами которых являются модель конечного состояния Белла и ЛаПадулы, а также модель решетки Д.
Демнинга. Многоуровневые модели предполагают формализацию процедуры присвоения прав доступа с помощью так называемых меток конфиденциальности или мандатов, назначенных субъектам и объектам доступа.
Таким образом, для объекта доступа, например, метки могут быть определены в соответствии с уровнем доступа человека к информации, а для объекта доступа (самих данных) признаки конфиденциальности информации.
Признаки конфиденциальности ИС регистрируются в метке объекта.
В связи с использованием терминов «мандат», «метка», «полномочия» многоуровневую защиту часто называют соответственно либо мандатной защитой, либо защитой с метками конфиденциальности, либо полномочной защитой.
Права доступа каждого объекта и характеристики конфиденциальности каждого объекта отображаются как набор уровней конфиденциальности и набор категорий конфиденциальности. Уровень последовательности может принимать одну из строго упорядоченных серий для ИК предприятия фиксированных значений, например, конфиденциальных, секретных, для служебного пользования, необеспеченных и т. д. Основой реализации контроля доступа являются:
1. Официальное сравнение метки субъекта, запросившего доступ, и метки объекта, к которому запрашивался доступ.

2. Решения о предоставлении доступа основываются на определенных правилах, которые основаны на противодействии снижению конфиденциальности защищаемой информации.
Таким образом, многоуровневая модель предотвращает возможность преднамеренного или случайного снижения уровня конфиденциальности рассматриваемой информации из-за её утечки (умышленной передачи), то есть эта модель предотвращает передачу информации от объектов с высоким уровнем конфиденциальности и узким набором категорий доступа к объектам с более низким уровнем конфиденциальности и более широким набором категорий доступа.
Практика показывает, что многоуровневые модели защиты гораздо ближе к потребностям реальной жизни, чем матричные модели, и обеспечивают хорошую основу для построения автоматизированных систем разграничения доступа. Кроме того, поскольку отдельные категории одного уровня равны, для их различения наряду с многоуровневой (мандатной) моделью требуется применение матричной модели.
С помощью многоуровневых моделей можно значительно упростить задачи администрирования (настройки). Кроме того, это касается как первоначальной установки политики доступа с делителями (такой высокий уровень и детализация установки отношения «предмет-объект» не требуется), так и последующего включения новых субъектов и объектов доступа в схему администрирования.
Подсистема защиты от НСД «закрытого» контура должна обеспечивать:
– однозначную идентификацию пользователей в ИС и в операционной системе (далее – ОС) АРМ (использование общих идентификаторов (ни в
СЗИ, ни в ОС) не допускается;
– идентификацию по логическим именам информационных ресурсов
(логических устройств, каталогов, файлов);
– исключение возможности удаленного подключения к локальным ресурсам «закрытого» контура и управление доступом к этим ресурсам за счет настроек ОС и СЗИ АРМ «закрытого» контура;
– управление доступом между «закрытым» контуром и «открытым» контуром на основе применения технологии межсетевых экранов (далее –
МЭ);
– мандатное (многоуровневое) разграничение доступа субъектов
«закрытого» контура к объектам с помощью маркеров доступа СЗИ ОС доменных пользователей и меток конфиденциальности объектов, хранящихся в их дескрипторах безопасности таблиц контроля доступа (далее – ТРД).
Мандатное разграничение доступа должно быть реализовано в соответствии с моделью Белла-ЛаПадула:
а) классификационные метки безопасности каждого субъекта и
каждого объекта должны соответствовать, отражая их место в
соответствующей иерархии. С помощью этих меток уровни классификации
должны присваиваться субъектам и объектам;

б) при вводе новых данных в систему метка этих данных
запрашивается и принимается от уполномоченного пользователя;
в) при наличии полномочий на перечисление пользователей новой
организации она сравнивается с классификационными метками;
г) Предписанный принцип контроля доступа должен быть реализован
для всех объектов с явным и скрытым доступом любого из субъектов.
"Явный" здесь относится к доступу, сделанному с помощью системных
инструментов - системных макросов, высокоуровневых языковых
инструкций и т. д., в то время как "скрытый" относится к другому
доступу, в том числе с использованием собственных программ устройств;
д) субъект может читать объект только в том случае, если
иерархическая классификация на уровне классификации субъекта не меньше
иерархической классификации на уровне классификации объекта;
е) субъект записывает объект только в том случае, если уровень
классификации субъекта в иерархической классификации не превышает
уровень классификации объекта в иерархической классификации;
ж) должна быть возможность изменения уровней классификации
субъектов и объектов специально выделенными субъектами.
Для реализации дискреционного разграничения полномочий доступа отдельных категорий пользователей одного уровня в «закрытом» контуре должна применяться матричная модель контроля доступа субъектов к защищаемым объектам ТРД. Она должна:
– храниться в отдельном файле отдельного каталога. Полное имя и путь данного файла должны задаваться в консоли АИБ «закрытого» контура;
– содержать перечисление санкционированных (разрешенных) операций для каждой пары «субъект–объект» системы защиты. Должно быть задано явное и недвусмысленное перечисление допустимых типов доступа: читать, писать, удалять, запускать, переименовывать, т. е. тех типов доступа, которые являются санкционированными для данного субъекта к данному ресурсу (объекту).
Управление мандатным и дискреционным доступом субъектов в
«закрытом» контуре к объектам контура – через доверенного диспетчера доступа (далее – доверенный диспетчер). При этом доверенный диспетчер должен обеспечить выполнение следующих задач:
а) присваивают пользователям домена и группам любые встроенные
функциональные роли или роли безопасности в прикладном программном
обеспечении "замкнутого" цикла или лишают их перечисленных ролей;
б) устанавливает права разграничения доступа субъектов «закрытого»
контура к объектам, контролируемым прикладным программным
обеспечением;
в) аудит успешных/или неудачных попыток идентификации,
аутентификации и авторизации пользователей в специальном программном
обеспечении «закрытого» контура, а также включение/отключение аудита
событий выхода или прерывания сеанса пользователей прикладного
программного обеспечения «закрытого» контура;

г) аудит успешных и/или неудачных попыток доступа отдельных
субъектов «закрытого» контура (пользователей домена, групп или всех) к
отдельным объектам, управляемым прикладным программным обеспечением
на дискретной основе;
д) аудит успешных и/или неудачных попыток доступа к объектам,
управляемым прикладным программным обеспечением пользователями в
соответствии с мандатом, а также запрашиваемых прав доступа к
объекту;
е) аудит успешных и/или неудачных попыток пользователей
реализовать права в процессе работы с прикладным программным
обеспечением;
ж) включение/отключение аудита событий блокировки/разблокировки
операций прикладного ПО, а также изменений пользователей домена или
полномочий
групп
в
прикладном
программном
обеспечении
(их
включение/исключение из определённых функциональных ролей и/или ролей
безопасности прикладного ПО);
з) задавать полное имя и путь к файлу, содержащему ТРД субъектов
«закрытого» контура к объектам, управляемым прикладным ПО;
и) выполнять операции блокировки/разблокировки работы специального
ПО.
Доверенный диспетчер должен регистрировать в журнале безопасности
ОС следующие события, которые должны быть доступны для аудита:
– успешные и/или неудачные попытки идентификации, аутентификации и авторизации пользователей в прикладном ПО;
– выход или прерывание сеанса работы пользователя в прикладном ПО;
– успешные и/или неудачные попытки доступа к объектам, управляемым прикладным ПО, со стороны пользователей по дискреционному принципу;
– успешные и/или неудачные попытки верификации пользователей при выполнении тех или иных действий в системе;
– успешные и/или неудачные попытки назначение доменным пользователям или группам тех или иных встроенных функциональных ролей безопасности в прикладном ПО с консоли администрирования
«закрытого» контура;
– события блокировки/разблокировки работы прикладного ПО;
– критические и фатальные ошибки, возникающие в программном коде доверенного диспетчера без возможности его отключения;
– успешные и/или неудачные попытки доступа к объектам со стороны пользователей по мандатному признаку;
– запрашиваемые права доступа к объекту.
При записи событий в журнале должны фиксироваться
– код (ID) события;
– тип события (успех, неудача);
– категория события («начало сеанса работы», «прекращение сеанса работы», «доступ к объектам», «применение полномочий», «изменение

полномочий», «блокировка работы прикладного ПО», «разблокировка работы прикладного ПО», «критическая ошибка», «фатальная ошибка»);
– дата и время события;
– источник события;
– пользователь, инициировавший данное событие;
– компьютер, на котором инициировано данное событие; описание события.
Администрирование доступом субъектов «закрытого» контура к защищенным объектам должно быть реализовано с помощью отдельной оснастки, консоли либо утилиты администрирования «закрытого» контура, представляющая собой отдельный файл, в котором должны быть реализованы возможности:
– разграничения доступа доменных пользователей и групп к объектам
«закрытого» контура с учетом явного или косвенного (через несколько вложений в группы) включения пользователя во все группы, которым разрешен или явно запрещен доступ к указанному объекту с возможностью блокировки доступа в случае его запрета (дискреционный принцип);
– выдачи мандатных меток объектов, управляемых прикладным ПО
«закрытого» контура;
– назначения отдельным пользователям или группам пользователей встроенных ролей прикладного ПО;
– регламентации доступа пользователей к физическим устройствам АРМ
(дискам, портам ввода-вывода);
– разграничения доступа к маршрутизаторам и к серверам «закрытого» контура на уровне сетевых служб и процессов, обеспечивающих доступ к сетевым ресурсам по следующим параметрам:
а) пользователям;
б) процессам;
в) времени доступа;
г) по службам доступа (портам);
д) политике безопасности (запрещенные/разрешенные сервера и
службы).
– создания замкнутой программной среды разрешенных для запуска программ, расположенных как на локальных, так и на сетевых дисках АРМ
«закрытого» контура. Управление замкнутой программной средой должно осуществляться централизованно;
– контроля целостности модулей системы защиты, системных областей диска и произвольных списков файлов в автоматическом режиме и по командам АИБ «закрытого» контура:
а) контроль целостности должен выполняться по контрольным
суммам, как в процессе загрузки, так и динамически;
б) механизм верификации контрольных сумм должен использовать
аттестованный алгоритм;
в) анализ контрольных сумм должен проводиться как в процессе
загрузки, так и динамически.