Исследование моделей и средств обеспечения информационной безопасности на предприятии

Правило запрета по записи является большим упрощением некоторых реализаций БЛМ. Так, некоторые описания включают более детальное понятие типа доступа (например такие, как добавление и выполнение). Помимо этого многие модели БЛМ включают понятие дискретной защиты с целью обеспечения хорошо гранулированной защиты при сохранении всех преимуществ БЛМ.

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

Несмотря на достоинства модели Белла–Лападула, при ее строгой реализации в реальных АС возникает ряд проблем.

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

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

3. Проблема удаленного чтения-записи. В распределенных системах при удаленном чтении файла создаются два потока: от субъекта к объекту (запросы на чтение, подтверждения, прочая служебная информация) и от объекта к субъекту (сами запрашиваемые данные). При этом, например, если F(s)>F(o), то первый поток будет противоречить свойству безопасности по записи. На практике для решения этой проблемы надо разделять служебные потоки (запросы, подтверждения) и собственно передачу информации.

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

2.3 Информационные модели

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

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

2.4 Ролевые модели

Ролевая модель управления доступом содержит ряд особенностей, которые не позволяют отнести  её ни к категории дискреционных, ни к категории мандатных моделей. Основная идея реализуемого в данной модели подхода состоит в том, что понятие «субъект» заменяется двумя новыми понятиями:

− пользователь – человек, работающий в системе;

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

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

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

Управление доступом при использовании ролевой модели осуществляется следующим образом:

1. Для каждой роли  указывается набор полномочий, представляющий  собой набор прав доступа к  объектам АС.

2. Каждому пользователю  назначается список доступных  ему ролей.

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

Перейдём к формальному  описанию системы. Введём следующие  обозначения:

− U – множество пользователей;

− R – множество ролей;

− P – совокупность полномочий на доступ к объектам (реализованная,

например, в виде матрицы  доступа);

− S – множество сеансов работы пользователей с системой

Управление доступом реализуется с использованием следующих  отображений:

− PA ⊆ P × R - отображение множества полномочий на множество ролей, задающее для каждой роли установленный набор полномочий;

− UA ⊆U × R - отображение множества пользователей на множество ролей, определяющее набор ролей, доступных данному пользователю;

− user : S →U - функция, определяющая для сеанса s∈ S текущего пользователя u ∈U :

user(s) = u ;

− roles : S →{R} - функция, определяющая для сеанса s∈ S набор ролей из множества R , доступных в данном сеансе:

− permissions : S →{P} - функция, задающая для сеанса s∈ S набор доступных в нём полномочий (иначе говоря, совокупность полномочий всех ролей, доступных в данном сеансе):

Взаимосвязь пользователей, ролей, полномочий и сеансов показана на рисунке 2.4:

Рисунок 2 - Взаимосвязь ролей, полномочий, пользователей и сеансов

Критерий безопасности системы при использовании ролевой модели звучит следующим образом: система считается безопасной, если любой пользователь в системе, работающий в сеансе s∈ S , может осуществлять действия, требующие полномочий p∈ P , только в том случае, если p∈ permissions(s) .

На практике управление доступом в АС при использовании  ролевой модели осуществляется главным  образом не с помощью назначения новых полномочий ролям, а путём  задания отношения UA – т.е. путём определения ролей, доступных данному пользователю.

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

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

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

Одной из моделей, которую можно  отнести к ролевым, является модель системы военных сообщений MMS.

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

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

Классификация - обозначение, накладываемое на информацию, отражающее ущерб, который может быть причинен неавторизованным доступом; включающее уровни: TOP SECRET, SECRET и т.д. и множество меток ("CRYPTO", "NUCLEAR" и т.д.). Множество классификаций и отношение между ними образуют решетку.

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

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

Пользователь - персона, уполномоченная для использования системы.

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

Объект - одноуровневый блок информации. Это минимальный блок информации в системе, который имеет классификацию. Объект не содержит других объектов, он не многоуровневый.

Контейнер - многоуровневая информационная структура. Имеет классификацию и может содержать объекты (каждый со своей классификацией) и (или) другие контейнеры. Файл - это контейнер. Некоторые структуры файла могут быть контейнерами. Различие между объектом и контейнером базируется на типе, а не на текущем содержимом: если один из файлов данного типа является контейнером, то все остальные файлы данного типа являются контейнерами, даже если некоторые из них содержат только объекты или пусты. Устройства такие, как диски, принтеры, ленты, сетевые интерфейсы и пользовательские терминалы - контейнеры.

Сущность - объект или контейнер.

Требование степени доверия контейнеров - атрибут некоторых контейнеров. Для некоторых контейнеров важно требовать минимум степени доверия, то есть пользователь, не имеющий соответствующего уровня благонадежности, не может просматривать содержимое контейнера. Такие контейнеры помечаются соответствующим атрибутом (CCR). Например, пользователь, имеющий степень доверия «CONFIDENTAL», не может просматривать «CONFIDENTAL» параграф сообщения, помеченного «TOP SECRET», если оно содержится в CCR-контейнере. Если пользователь должен иметь возможность просматривать данное сообщение, контейнер не должен быть помечен как CCR.

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

Ссылка на сущность прямая, если это идентификатор сущности.

Ссылка на сущность косвенная, если это последовательность двух или более имен сущностей (из которых только первая - идентификатор). Пример - "текущее сообщение, первый абзац, вторая строка".

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

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

Сообщение - особый тип, реализуемый в MMS. Сообщение является контейнером. Сообщение включает поля «Куда», «Откуда», «Время», «Предмет», «Текст», «Автор».