Добавил:
ivanov666
Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз:
Предмет:
Файл:Теоретические основы защиты информации. Учебное пособие
.pdf
на одном из верхних уровней, он никогда не сможет исказить системные файлы за счет правила NWD. Таким образом, осуществляется защита целостности от троянских коней. Очевидно, такое
объединение моделей осуществляет защиту секретности для верхних уровней определенной иерархии и защиту целостности для
нижних уровней.
9.3.2. Объединение моделей Кларка–Вилсона и Биба
Дополнительным преимуществом модели Кларка–Вилсона
является возможность ее объединения с другими моделями безопасности.
Первый тип защиты в объединенной модели основан на мандатной модели целостности Биба. За счет этого целостность высокоуровневых данных будет защищена от несанкционированных
модификаций со стороны низкоуровневых субъектов.
Модель Биба эффективно защищает целостность объектов от
несанкционированной модификации со стороны субъектов, находящихся на другом уровне целостности, но не предоставляется никакой защиты программного обеспечения от атак в пределах уровня целостности. Иными словами, если злоумышленник находится
на высоком уровне целостности (возможно, в результате ошибки
при определении уровня целостности для данного субъекта), то
этот субъект может стать причиной различных проблем с целостностью программ и данных.
В результате модель целесообразно дополнить механизмами
защиты, которые связаны с моделью Кларка–Вилсона. Каждый
уровень целостности можно рассматривать как состоящий из множества субъектов и множества объектов, которые мы будем интерпретировать как набор CDI. Тогда для субъектов в модели должны
быть определены отношения КВМ-троек, ТР (которые осуществляют чтение и запись программного обеспечения) и CDI в пределах каждого из уровней целостности.
9.3.3. Модель Липнера
Липнер, объединив модель Белла и Лападула с моделью Биба,
создал модель, предназначенную для реализации требований к разработке программного обеспечения с последующим его использованием. При этом в модели были описаны следующие требования.
131
1. Пользователи не имеют права на разработку программ,
а используют существующее прикладное программное обеспечение.
2. Программисты разрабатывают и тестируют программы
в системе, не обрабатывающей критичные данные (тестовой системе). Если в процессе тестирования программ необходим доступ
к «настоящим» данным, они предоставляются тестовой системе с
использованием специального механизма.
3. Для внесения разработанных программ в систему исполь-
зуется специально разработанный механизм.
4. Механизм, описанный в предыдущем пункте, должен кон-
тролироваться, а результаты его работы фиксироваться в журнале
аудита.
5. Администраторы системы должны иметь возможность до-
ступа к данным аудита и функциям администрирования системы.
Для начала рассмотрим элементы модели Белла и Лападула,
включенные в модель Липнера.
В модели определены два уровня безопасности:
управление и аудит (Audit management, AM) – на данном
уровне находятся функции управления системой и аудит системы;
низший уровень (System Low, SL) – информацию на дан-
ном уровне может читать любой процесс.
В модели определено пять категорий:
разработка (Development, D) – к данной категории относят-
ся разрабатываемые и тестируемые прикладные программы;
прикладные программы (Production Code, PC) – к данной
категории относятся прикладные программы, используемые в системе;
критичные данные (Production Data, PD) – к данной катего-
рии относятся данные, целостность которых контролируется;
разрабатываемые системные программы (System Develop-
ment, SD) – к данной категории относятся разрабатываемые и те-
стируемые системные программы;
средства разработки (Software Tools, 7) – к данной категории
относятся прикладные программы, используемые для разработки
приложений и не участвующие в обработке критичных данных.
В данной модели уровни секретности присвоены пользователям на основании выполняемых ими заданий. Обычные пользова-
132
тели используют прикладные программы (PC) для обработки кри-
Пользователи/Объекты
Степень доверия/Классификация
Обычный пользователь
(SL,{PC, PD})
Разработчик прикладных программ
(SL, {D, T})
Системный программист
(SL, {SD, T})
Администратор системы
(AM, {D, PC, PD, SD, T})
Верификатор кода
(SL, {D, PC, PD, SD, T})
Разрабатываемые прикладные
программы, данные тестирования
(SL, {D, T})
Коды прикладных программ
(SL,{PC})
тичных данных; степень доверия обычных пользователей определяется как (SL, {PC, PD}). Разработчики приложений используют
средства разработки для создания прикладных программ и имеют
доступ к программам в процессе разработки и тестирования; степень доверия к разработчикам приложений определяется как (SL,
{D, 7}). Системные программисты используют средства разработки для разработки системных программ; степень доверия к разработчикам приложений определяется как (SL, {SD, Т)). Администраторам системы требуется наивысший уровень привилегий; как
следствие их степень доверия определяется как (AM, {D, PC, PD,
SD, I}). И наконец, верификаторы кода должны иметь возможность
понижать классификацию кода после его проверки и сертификации
(за счет этого ни один пользователь не имеет возможности модифицировать программный код); степень доверия к верификатору
кода определяется как (SL, {D, PC, PD, SD, Т}).
Объекты в модели представлены как данные и код программ
(пользователь, выполняющий программу, должен иметь возможность прочитать код программы). Таким образом, код программы
должен иметь классификацию (SL, {PC}), а критичные данные –
(SL, {PC, PD}). Все журналы аудита являются доступными только
для записи. В соответствии со свойством * их классификация
должна доминировать над всеми субъектами. Как следствие данного положения каждый журнал аудита должен иметь собственный
набор категорий и находится на высшем уровне безопасности.
На основании вышеизложенного можно составить таблицу,
отражающую степень доверия к пользователям и классификацию
объектов.
Таблица 9.1
Модель Липнера на основе модели Белла и Лападула
133
Рассмотрим модель в соответствии с выдвинутыми к ней требованиями.
1. Пользователи не имеют возможности выполнить програм-
мы из категории Т, как следствие этого они не могут разрабатывать
программы.
2. Системные программисты и разработчики прикладных
программ не имеют доступа по чтению и записи к категории PD
(категории критичных данных). Если в процессе тестирования такой доступ необходим, то классификация критичных данных понижается от PD до D и не может быть повышена обратно (вследствие того, что в модели не описаны соответствующие привилегии). Понижение классификации данных выполняется верификаторами кода.
3. Процесс внесения разработанных программ требует приви-
легии понижения категории программ от D до PC. Данной привилегией обладает верификатор кода.
4. Процессом внесения разработанных программ обладает
только верификатор кода. Аудит данной процедуры должен осуществляться в обязательном порядке.
5. Администраторы системы действуют на высшем уровне
привилегий.
Таким образом, все требования, предъявляемые к модели,
удовлетворены. Однако в реальных системах может потребоваться
использование процессов восстановления критичных данных, не
являющихся прикладным программным обеспечением.
Для придания модели большей гибкости Липнер объединил
описанную выше модель с моделью Биба.
В модели введено три уровня целостности:
уровень системных программ (System program, ISP);
операционный (Operational, IO) – уровень прикладных про-
грамм и разрабатываемого программного обеспечения;
низший уровень (System Low, ISL) – уровень, получаемый
пользователями при входе в систему.
В модели определены две категории целостности:
разработка (Development, ID) – программы и данные, отно-
сящиеся к разработке;
134
прикладная (Production, IP) • – прикладные программы и
1
2
Критичные данные
(SL,{PC, PD})
Средства разработки
(SL, {T})
Системные программы
(SL, {})
Разрабатываемые системные программы
(SL, {SD, T})
Данные аудита
(AM, {соответствующие
категории})
критичные данные.
Категория безопасности Т (средства разработки) позволяют
разработчикам прикладного и системного программного обеспечения использовать одни и те же программы, не имея возможности
изменять их.
Определенные выше категории целостности проводят различие между разработкой и использованием программ, что позволяет
удалить из модели категорию безопасности программ, относящихся к разработке. Кроме того, критичные данные и прикладные программы могут быть объединены в единую категорию. Все это позволяет уточнить описанные выше категории безопасности следующим образом:
обработка (Production, SP) – к данной категории относятся
прикладные программы и данные;
разработка (Development, D) – к данной категории относят-
ся разрабатываемые и тестируемые прикладные программы;
разрабатываемые системные программы (System Develop-
ment, SD) – к данной категории относятся разрабатываемые и те-
стируемые системные программы.
Уровни целостности пользователей выбираются так, чтобы
доступ пользователей к программам и данным был организован
соответствующим образом так, как это показано в табл. 9.2.
Таблица 9.2
Уровни целостности пользователей
9.3.4. Модель Липнера на основе модели Белла
и Лападула и Биба
Как видно из таблицы 9.3, класс пользователей, имеющих воз-
можность восстановления данных, имеет тот же уровень целостности
135
и степень доверия, что и критичные данные (следовательно, эти поль-
Пользователи/Объекты
Степень доверия /
Классификация
Уровень
целостности 1 2
3
Обычный пользователь
(SL,{SP})
(ISL,{IP})
Разработчик прикладных
программ
(SL, {SD})
(ISL, {ID})
Системный программист
(SL, {SSD})
(ISL, {ID})
Администратор системы
(AM, {SP, SD, SSD})
(ISL, { IP,
ID})
Верификатор кода
(SL, {SL, SD}) привилегия
понижения классификации
(SP, { IP,
ID})
Восстановление
(SL, {SP})
(ISL,{IP})
Разрабатываемые
прикладные программы,
данные тестирования
(SL, {SD})
(ISL,{IP})
Коды прикладных программ
(SL, {SP})
(IO,{IP})
Критичные данные
(SL, {SP})
(ISL,{IP})
Средства разработки
(SL, {})
(IO,{ID})
Системные программы
(SL, {})
(IO,{ID, IP })
Разрабатываемые
системные программы
(SL, {SSD})
(ISL, {ID})
Данные аудита
(AM, {соответствующие
категории})
(ISL,{ })
Восстановление
(SL, {SP})
(ISL,{IP})
зователи могут читать и писать критичные данные).
Таблица 9.3
Классы пользователей и их возможности
Также пользователи, восстанавливающие данные, могут выполнять прикладные и системные программы, писать данные
в журналы аудита (но не читать); они не имеют доступа к разрабатываемым программам и средствам разработки.
1. Почему модель Биба называют инверсией модели Белла и
Лападула?
2. В чем сущность правил «нет чтения снизу» и «нет записи
наверх»?
Контрольные вопросы
136
3. Изобразите и поясните потоки информации в модели Биба.
4. Каковы достоинства и недостатки модели Биба?
5. Каким образом представлены субъекты и объекты в модели
Кларка–Вилсона?
6. Какие правила входят в модель Кларка–Вилсона?
7. Оцените последствия объединения модели понижения
уровня целостности субъектов и модели понижения уровня целостности объектов.
8. Оцените проблему удаленного чтения и проблему системы
Z для модели Биба.
9. Сравните модель Биба и модель Кларка–Вилсона.
10. Какие подходы используются при объединении двух моделей?
11. В каких системах целесообразно объединять модели Белла
и Лападула и Биба?
12. Изобразите и поясните потоки информации в объединен-
ной модели Белла и Лападула и Биба на основе модели Белла и Лападула.
13. Какие характеристики системы могут быть улучшены при
объединении модели Белла и Лападула и Биба на основе модели
Белла и Лападула?
14. В каких случаях целесообразно объединение моделей
Кларка–Вилсона и Биба?
15. Поясните основные требования модели Липнера.
137
10. РОЛЕВЫЕ МОДЕЛИ ДОСТУПА
В данной главе рассмотрим основные ролевые модели доступа. Контроль доступа, базирующийся на ролях (role based access
control) (КДБР), рассматривает всю информацию, обрабатывающуюся в вычислительной системе организации, как принадлежащую данной организации.
В системах КДБР пользователи не могут передавать права на
доступ к информации другим пользователям, что является фундаментальным отличием КДБР от дискреционного доступа.
КДБР принимает решение о доступе на основе информации
о функции, которую пользователь выполняет внутри данной организации, – роли этого пользователя. Например, в госпитале роли
могут быть следующими: доктор, хирург, медсестра, фармацевт и
т. д. При этом фармацевт (пользователь, выполняющий роль фармацевта) может получать доступ к информации о количестве выданного лекарства, но тип лекарства назначается доктором.
Присвоение роли пользователю и распределение полномочий
роли в КДБР зависит от политики безопасности, принятой в системе. Роль можно понимать как множество действий, которые пользователь или группа пользователей может исполнять в контексте
вычислительной системы организации. Понятие роли включает
описание обязанностей, ответственности и квалификации субъекта. Функции распределяются по ролям администратором системы.
Доступ пользователя к роли также определяется администратором
системы.
КДБР подразумевает непосредственное описание сущностей
системы и правил контроля доступа в терминах, соответствующих
представлению операций в вычислительной системе конкретной
организации. Таким образом, КДБР оперирует с абстракциями более высокого уровня, чем дискреционный или мандатный контроль
доступа. С одной стороны, это лишает его некоторой универсальности, присущей другим механизмам контроля доступа. С другой
стороны, если КДБР для организации однажды реализован, то его
корректировка путем добавления и удаления ролей становится несложным процессом.
138
Политики безопасности, основанные на КДБР, описываются
Пользователи Роли Операции
в терминах пользователей, ролей, операций и защищаемых объектов. Для того чтобы применить некоторую операцию к защищаемому КДБР объекту, пользователь должен выполнять некоторую
роль. До того, как пользователь может выполнять данную роль, он
должен быть авторизован для данной роли системным администратором. КДБР наделяет администратора способностью устанавливать ограничения на авторизацию в роли, активацию роли, выполнение операций. Данные ограничения могут иметь различную
форму.
Обычно КДБР реализуется на уровне приложений, а не на
уровне операционной системы. Трудность поддержки на уровне
операционной системы заключается в практической невозможности выявления достаточно общих базовых конструкций КДБР, независимых от области применения и легко реализуемых.
10.1. Пользователи, роли и операции
КДБР обеспечивает отображение «многие ко многим» между
элементами множеств пользователей, ролей и операций, приведенное на рис. 10.1.
Рис. 10.1. Соотношение множеств пользователей, ролей и операций
Определим основные используемые понятия. В КДБР пользователь – это некоторое лицо, сотрудник организации; роль – список выполняемых в вычислительной системе функций; субъект –
активная сущность вычислительной системы; операция – некоторое действие, для выполнения которого требуются права доступа к
одному или нескольким защищаемым КДБР объектам. Можно ввести отображение «один ко многим» между пользователем и эле-
139
ментами множества субъектов вычислительной системы, показан-
Пользователь Субъекты
ное на рис. 10.2.
Рис. 10.2. Соотношение множеств пользователей и субъектов
Опишем отношения между пользователями, субъектами и ролями с использованием следующих многозначных выражений:
subject-user (s : subject) = пользователь, ассоциированный
с субъектом s
authorized-roles (s : subject) = {множество ролей, ассоциированных с субъектом s}
role-members (r : role) = {множество пользователей, авторизованных для роли r}
user-authorized-roles (и : user) = {множество ролей, ассоциированных с пользователем и).
Отметим, что пользователь, ассоциированный с субъектом системы, определяется по уникальному пользовательскому идентификатору. Каждый субъект системы отображается в одного пользователя и, возможно, во множество ролей. КДБР требует: «Если authorized-
roles(s) = R и subject-user(s) = и, то пользователь и должен быть ассо-
циирован со множеством ролей R». Другими словами:
Предположение 1. Непротиворечивый субъект.
s : subject, и: user, R, r: roles : subject-user(s) = и & authorized-
roles(s) = =R и role-members(r) r R.
Типы операций и объектов, доступ к которым контролируется,
зависят от системы, для которой реализуется КДБР. Например, для
операционной системы операции включают чтение, запись, исполнение; для системы управления базами данных – вставку, обновление, удаление. Множество объектов, доступ к которым ограничивает КДБР, включает все объекты, доступ к которым возможен под
управлением КДБР.
140
Соседние файлы в предмете [НЕСОРТИРОВАННОЕ]