Методы защиты информации

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

       описание аспекта (например, если рассмотреть применение пользователями неофициального программного обеспечения, последнее можно определить как ПО, которое не было одобрено и/или закуплено на уровне организации);

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

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

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

       законопослушность (политика должна содержать общее описание запрещенных действий и наказаний за них);

       точки контакта (куда следует обращаться за разъяснениями, помощью и дополнительной информацией).

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

       кто имеет право доступа к объектам, поддерживаемым сервисом?

       при каких условиях можно читать и модифицировать данные?

       как организован удаленный доступ к сервису?

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

2 Модели политики безопасности

После того, как сформулирована политика безопасности, можно приступать к составлению программы ее реализации и собственно к реализации.

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

2.1 Модели основных типов политики безопасности

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

Наиболее часто рассматриваются политики безопасности, связанные с понятием «доступ». Доступ – категория субъективно–объективной политики, описывающая процесс выполнения операций субъектов над объектами.

Политика безопасности включает:

       множество операций субъектов над объектами;

       для каждой пары «субъект – объект» (Si, Oi) множество разрешенных операций, из множества возможных операций.

Существуют следующие типы политик безопасности: дискреционная, мандатная и ролевая.

2.1.1 Дискреционная политика безопасности

Основой дискреционной (дискретной) политики безопасности является дискреционное управление доступом (Discretionary Access Control – DAC), которое определяется двумя свойствами:

       все субъекты и объекты должны быть идентифицированы;

       права доступа субъекта к объекту системы определяются на основании некоторого внешнего по отношению к системе правила.

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

В качестве примера реализаций дискреционной политики безопасности в AC можно привести матрицу доступов, строки которой соответствуют субъектам системы, а столбцы – объектам; элементы матрицы характеризуют права доступа.

К недостаткам относится статичность модели (данная политика безопасности не учитывает динамику изменений состояния AC, не накладывает ограничений на состояния системы.

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

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

2.1.2 Мандатная(полномочная) политика безопасности

Основу мандатной (полномочной) политики безопасности составляет мандатное управление доступом (Mandatory Access Control – МАС), которое подразумевает, что:

       все субъекты и объекты системы должны быть однозначно идентифицированы;

       задан линейно упорядоченный набор меток секретности;

       каждому объекту системы присвоена метка секретности, определяющая ценность содержащейся в нем информации – его уровень секретности в AC;

       каждому субъекту системы присвоена метка секретности, определяющая уровень доверия к нему в AC – максимальное значение метки секретности объектов, к которым субъект имеет доступ; метка секретности субъекта называется его уровнем доступа.

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

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

Кроме того, по сравнению с АС, построенными на основе дискреционной политики безопасности, для систем, реализующих мандатную политику, характерна более высокая степень надежности. Это связано с тем, что МБО такой системы должен отслеживать, не только правила доступа субъектов системы к объектам, но и состояния самой АС. Т.о. каналы утечки в системах данного типа не заложены в нее непосредственно, а могут появиться только при практической реализации системы.

2.1.3 Ролевое управление доступом

При большом количестве пользователей традиционные подсистемы управления доступом становятся крайне сложными для администрирования. Число связей в них пропорционально произведению количества пользователей на количество объектов. Необходимы решения в объектно-ориентированном стиле, способные эту сложность понизить.

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

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

В 2001 году Национальный институт стандартов и технологий США предложил проект стандарта ролевого управления доступом.

Ролевое управление доступом оперирует следующими понятиями:

       пользователь (человек, интеллектуальный автономный агент и т.п.);

       сеанс работы пользователя;

       роль (определяется в соответствии с организационной структурой);

       объект (сущность, доступ к которой разграничивается; например, файл ОС или таблица СУБД);

       операция (зависит от объекта; для файлов ОС – чтение, запись, выполнение и т.п.; для таблиц СУБД – вставка, удаление и т.п., для прикладных объектов операции могут быть более сложными);

       право доступа (разрешение выполнять определенные операции над определенными объектами).

Ролям приписываются пользователи и права доступа; можно считать, что они (роли) именуют отношения "многие ко многим" между пользователями и правами. Роли могут быть приписаны многие пользователи; один пользователь может быть приписан нескольким ролям. Во время сеанса работы пользователя активизируется подмножество ролей, которым он приписан, в результате чего он становится обладателем объединения прав, приписанных активным ролям. Одновременно пользователь может открыть несколько сеансов.

Между ролями может быть определено отношение частичного порядка, называемое наследованием. Если роль r2 является наследницей r1, то все права r1 приписываются r2, а все пользователи r2 приписываются r1. Очевидно, что наследование ролей соответствует наследованию классов в объектно-ориентированном программировании, только правам доступа соответствуют методы классов, а пользователям – объекты (экземпляры) классов.

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

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

Для реализации еще одного упоминавшегося ранее важного принципа информационной безопасности вводится понятие разделения обязанностей, причем в двух видах: статическом и динамическом.

Статическое разделение обязанностей налагает ограничения на приписывание пользователей ролям. В простейшем случае членство в некоторой роли запрещает приписывание пользователя определенному множеству других ролей. В общем случае данное ограничение задается как пара "множество ролей – число" (где множество состоит, по крайней мере, из двух ролей, а число должно быть больше 1), так что никакой пользователь не может быть приписан указанному (или большему) числу ролей из заданного множества. Например, может существовать пять бухгалтерских ролей, но политика безопасности допускает членство не более чем в двух таких ролях (здесь число = 3).

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

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

Рассматриваемый проект стандарта содержит спецификации трех категорий функций, необходимых для администрирования РУД:

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