Основная аксиома. Проблема построения защищенной КС.

Аксиома 1.1 (основная аксиома компьютерной безопасности).

Все вопросы безопасности информации в компьютерной системе описываются доступами субъектов к сущностям.

Информационный поток (information flow) от сущности-источника к сущности-приемнику – преобразование данных в сущности- приемнике, реализуемое субъектами КС и зависящее от данных, содержащихся в сущности-источнике.

Аксиома 1.2.

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

Аксиома 1.3.

Все информационные потоки в КС порождены доступами субъектов к сущностям.

 

Понятие политики безопасности.

Политика безопасности КС – совокупность правил, регулирующих управление ресурсами, их защиту и распределение в пределах КС.

Основные виды политик управления доступом:

- Дискреционная;

- Мандатная;

- Ролевого управления.

Кроме того, политики безопасности информационных потоков, системы военных сообщений и изолированной программной среды.

 

Основные виды политик управления доступом и информационными потоками.

Дискреционная политика управления доступом – политика, соответствующая следующим требованиям:

l все сущности идентифицированы (т.е. каждой сущности присвоен уникальный идентификатор);

l задана матрица доступов, каждая строка которой соот-ветствует субъекту, а столбец – сущности КС, ячейка содержит список прав доступа субъекта к сущности;

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

(+) простая реализация.

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

Мандатная политика управления доступом – политика, соответствующая следующим требованиям:

• все сущности идентифицированы;

• задана решетка уровней конфиденциальности информации;

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

• каждому субъекту присвоен уровень доступа, задающий уровень полномочий данного субъекта в КС;

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

(+) правила ясны для разработчика и пользователя, есть механизмы проверки безопасности.

(–) сложная реализация

Политика ролевого управления доступом - политика, соответствующая следующим требованиям:

l все сущности идентифицированы;

l задано множество ролей, каждой из которых ставится в соответствие некоторое множество прав доступа к сущностям;

l каждый субъект обладает некоторым множеством ролей;

l субъект обладает правом доступа к сущности КС тогда, когда он обладает ролью, которой соответствует множество прав доступа, содержащее право доступа к данной сущности.

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

Политика безопасности информационных потоков основана на разделении всех возможных информационных потоков (ИП) между сущностями КС на два непересекающихся множества: множество разрешенных ИП и множество запрещенных ИП.

Цель – обеспечить невозможность возникновения в КС запрещенных ИП.

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

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

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

Модель матрицы доступов Харрисона-Руззо-Ульмана (ХРУ).

В модели Харрисона-Руззо-Ульмана (ХРУ) используются следующие обозначения:

O – множество объектов системы (сущности – контейнеры в ХРУ не рассматриваются);

S – множество субъектов системы (SÎO);

R – множество видов прав доступа субъектов к объектам (read, write, own);

M – матрица доступов, строки в которой соответствуют субъектам, столбцы – объектам. M[s,o] ÎR – права доступа субъекта s к объекту o.

Автомат, построенный согласно описанию модели ХРУ, назовем системой ХРУ.

Функционирование системы рассматривается только с точки зрения изменений в матрице доступа, определяющиеся 6-ю видами примитивных операторов.

Примитивные операторы модели ХРУ:

• Enter r into (s,o) - ввести право r в ячейку (s,o)

• Delete r from (s,o) - удалить право r из ячейки (s,o)

• Create subject s - создать субъект s (т.е.новую строку матрицы A) Create object o - создать объект o (т.е. новый столбец матрицы A)

• Destroy subject s - уничтожить субъект s

• Destroy object o - уничтожить объект o

Состояние системы Q изменяется при выполнении команд C(a1, a2, …), изменяющих состояние матрицы доступа A.

 

Анализ безопасности систем ХРУ. Монооперационные системы ХРУ.

Будем считать, что в состоянии q системы ХРУ возможна утечка права доступа r ÎR в результате выполнения команды c (x 1,..., xk), если при переходе q ├_{c ( x 1,…, xk )} q’ выполняется примитивный оператор, вносящий право r в ячейку матрицы доступов M, до этого r не содержавшую.

Начальное состояние q0 системы ХРУ называется безопасным относи-тельно некоторого права доступа r ÎR, если невозможен переход системы в такое состояние q, в кот. возможна утечка права доступа r.

Система ХРУ называется монооперационной, если каждая ее команда содержит один примитивный оператор.

Теорема.

Существует алгоритм, проверяющий, является ли начальное состояние произвольной монооперационной ХРУ безопасным относительно некоторого права доступа r ÎR.

Следствие.

Алгоритм проверки безопасности монооперационных систем ХРУ имеет экспоненциальную сложность.

Экспоненциальные алгоритмы считаются НЕЭФФЕКТИВНЫМИ.

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

 

 

Модель типизированной матрицы доступов (ТМД).

Модель типизированной матрицы доступов (ТМД) есть развитие моде-ли ХРУ, дополненной концепцией типов. Формальное описание модели ТМД включает в себя следующие элементы:

O – множество объектов системы;

S – множество субъектов системы (SÍO);

R – множество видов прав доступа субъектов к объектам;

M – матрица доступов;

С – множество команд;

T – множество типов объектов;

t: O®T – функция, ставящая в соответствие объекту его тип;

q=(S, O, t, M) – состояние системы;

Q – множество состояний системы.

Система ТМД переходит из состояния в состояние в результате выполнения команд из множества C.

Формат команд определяется аналогично ХРУ, при этом для всех параметров команд указывается их тип.

• Enter r into (s,o) - ввести право r в ячейку (s,o)

• Delete r from (s,o) - удалить право r из ячейки (s,o)

• Create subject s’ - создать субъект s’ с типом ts (т.е.новую строку матрицы A)

• Create object o’ - создать объект О’ с типом t_o(т.е. новый столбец матрицы A)

• Destroy subject s’ - уничтожить субъект s ‘

• Destroy object o’ - уничтожить объект o ‘

Пусть c(x1: t1,…, xk: tk) – некоторая команда системы ТМД. Будем говорить, что xi является дочерним параметром, а ti – дочерним типом (iÎ{1,…,k}) в с, если с содержит один из следующих примитивных операторов:

- «создать» субъект xi c типом ti;

- «создать» объект xi c типом ti.

В противном случае будем говорить, что xi является родительским пара-метром, а ti – родительским типом в с.