Модель Биба (модификация модели Белла-Лападулы)

Модификация модели Белла-ЛаПадулы, ориентированная на обеспечение целостности данных.

Цели

● Предотвратить модификацию данных неавторизованным субъектом

● Предотвратить неавторизованную модификацию данных авторизованным субъектом

● Поддерживать уровень достоверности информации объекта

Формальное описание системы

● S–множество субъектов

● O–множество объектов

● Q –решетка классов целостности

● L –уровни допуска (доверия) субъекта

● Q U L –метки безопасности

● P ={r, w}–множество прав доступа, r–доступ на чтение,w–доступ на запись

Особенности

● Инверсия модели Bell-LaPadule

● Блокирует некоторые скрытые каналы утечки

● Создает нисходящий (от более достоверных объектов к менее достоверным) поток информации

Ролевая модель управления доступом. Математическая модель. Достоинства и недостатки

Развитие политики DAC, права субъектов системы на объекты группируются, образуя роли. Ролевая модель управления доступом отличается тем, что управление доступом базируется не на разрешениях собственника как в DAC и не на метках безопасности (как в MAC), а на основе функций субъекта. Понятие «роль» в этой модели –это совокупность действий и обязанностей, связанных с определенным видом деятельности.

Предполагается, что все данные системы принадлежат некоторой организации, а не пользователю, как в случае моделей DAC и MAC

Базовая модель RBAC

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

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

3. Пользователь может быть ассоциирован с несколькими ролями

Формальное описание

● 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 , доступных в данном сеансе:

Требование безопасности:

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

Достоинства:

● Многие пользователи имеют одинаковые права, их можно описать один раз и постоянно переиспользовать

● Если всем пользователям необходимо добавить одно право – есть единое место изменения

● Легко отозвать ненужные права и предоставить актуальные просто сменив роль пользователя

Недостатки:

● Ролевая модель должна быть создана при старте проекта и поддерживаться на протяжении всего жизненного цикла

● Любой пользователь должен быть назначен хотя бы на одну роль

● Любые отклонения между правами в рамках ролевой модели и текущими правами пользователя должны постоянно пересматриваться и подтверждаться.

Дополнительно. (не очень относится к вопросу, но есть в презентациях)

Отличие от ACL

● Управление доступом к данным самим пользователем (в том числе и с помощью передачи привилегий) не предусмотрено.

● Может давать привилегии на сложные операции с составными данными, а не только на атомарные операции с низкоуровневыми объектами данных