Ролевое управление доступом
Ролевое управление доступом (Role-Based Access Control, RBAC) представляет собой универсальный каркас, нейтральный по отношению к конкретной дисциплине разграничения доступа и предназначенный в первую очередь для упрощения администрирования ИС с большим числом пользователей и различных ресурсов.
Ниже рассматриваются специфические требования для профиля RBAC [77], [75], основанного на версии 2.0 "Общих критериев".
Разделение обязанностей - существенная и специфичная для ролевого управления доступом цель безопасности. Возможность ее достижения - важное достоинство ролевого доступа.
Еще одна особая и методологически важная цель безопасности - организация иерархии ролей с наследованием прав доступа. Применение идей и методов объектно-ориентированного подхода необходимо для успешной работы с большими системами.
Для ролевого управления доступом характерны следующие функции:
- создание и удаление ролей; создание, удаление и модификация атрибутов ролей и отношений между ролями;
- формирование и поддержка ассоциаций между пользователями и ролями;
- формирование и поддержка ассоциаций между правами доступа и ролями.
Эти функции обслуживаются тремя классами функциональных требований, на которых мы и остановимся:
- ограниченное управление доступом (FDP_ACC.1.1). По крайней мере для части операций субъектов над объектами должно действовать ролевое управление доступом, которое в общем случае может существовать с другими дисциплинами разграничения доступа;
- управление доступом, основанное на атрибутах безопасности (FDP_ACF.1.1). В число учитываемых атрибутов безопасности следует включить, помимо прочих, присвоенные субъекту роли и права доступа этих ролей;
- управление данными функций безопасности (FMT_MTD). Только администратор должен иметь возможность определения и изменения ролей, их атрибутов, связей между ними и ограничений на подобные связи (FMT_MTD.1.1). Необходимы и другие требования класса FMT, но они в данном случае носят прямолинейный характер и рассматриваться не будут.
Требования безопасности при сбое (семейство FPT_FLS) имеют технический характер. Должно сохраняться безопасное состояние в ситуациях, когда база данных ролей недоступна или повреждена (FPT_FLS.1.1). Как и в случае управления безопасностью, другие требования этого класса необходимы, но не нуждаются в детальном рассмотрении.
Можно видеть, что функциональные требования "Общих критериев" полезны для достижения тактических целей безопасности. Стратегические цели, носящие концептуальный или архитектурный характер, - организация иерархии ролей с небольшим числом сущностей на каждом уровне или следование принципу разделения обязанностей - приходится формулировать отдельно, без стандартизованной понятийной базы.
