V1.4.5 Access Control Architecture
Requirement:#
Verify that attribute or feature-based access control is used whereby the code checks the user's authorization for a feature/data item rather than just their role. Permissions should still be allocated using roles. (C7)
Explanation:#
Требование направлено на архитектуру управления доступом и рекомендует использовать управление доступом на основе атрибутов или характеристик в дополнение к управлению доступом на основе ролей (RBAC).
1 Role-Based Access Control (RBAC):
- RBAC - это широко используемая модель управления доступом, в которой права присваиваются ролям, а пользователям назначаются роли. Пользователи наследуют права, связанные с их ролями. Например, можно иметь такие роли, как "Администратор", "Пользователь" и "Менеджер", каждая из которых обладает определенными правами.
2 Limitations of RBAC:
- RBAC эффективна для многих сценариев, но у нее есть и ограничения, особенно в приложениях со сложными требованиями к управлению доступом. К таким ограничениям относятся:
- Coarse-Grained Control: RBAC часто обеспечивает строгий контроль, когда пользователи с одинаковой ролью имеют одинаковый уровень доступа независимо от конкретных потребностей.
- Inflexibility: RBAC может быть негибкой, когда необходимо предоставить или ограничить доступ к определенным функциям или элементам данных на основе различных критериев.
3 Attribute or Feature-Based Access Control:
- Управление доступом на основе атрибутов или характеристик расширяет возможности RBAC, позволяя осуществлять контроль доступа к функциям или элементам данных на более детальном уровне. При таком подходе:
- Решения по управлению доступом принимаются на основе атрибутов или характеристик ресурсов, а не только ролей пользователей.
- Пользователи могут иметь различные уровни доступа к различным экземплярам ресурса в зависимости от их атрибутов или контекста.
На пример, у вас есть HR-приложение, в котором менеджеры могут получать доступ к записям о сотрудниках. В чистой модели RBAC все менеджеры будут иметь одинаковый уровень доступа ко всем записям сотрудников. При управлении доступом на основе атрибутов или характеристик можно предоставить менеджерам доступ к записям сотрудников на основе атрибута отдела. Это означает, что менеджер отдела кадров может получить доступ к записям сотрудников конкретного отдела кадров, но не к записям сотрудников других отделов.
Реализовав наряду с RBAC управление доступом на основе атрибутов или характеристик, можно добиться более точного и гибкого управления доступом, адаптируя доступ к конкретным атрибутам пользователя, ресурса или контекста, но при этом используя роли для распределения прав.
Remediation:#
Для выполнения требования и реализации в приложении контроля доступа на основе атрибутов или функций необходимо выполнить следующие действия:
1 Access Control Review:
- Провести комплексный анализ требований к управлению доступом в приложении. Определить ресурсы (функции, данные, конечные точки), требующие контроля доступа.
2 Attribute Identification:
- Определить атрибуты или характерист ики, которые должны влиять на принятие решений по управлению доступом. Эти атрибуты могут включать атрибуты пользователя, атрибуты ресурса или контекстные атрибуты.
3 Role Definition:
- Определить и задокументировать роли, как это делается в традиционной модели RBAC. Роли представляют собой группы пользователей со схожими обязанностями.
4 Permission Assignment:
- Присвоение прав доступа к ролям осуществляется так же, как и в модели RBAC. Права должны быть связаны с ролями для обеспечения управляемости и согласованности.
5 Attribute-Based Rules:
Реализовать в коде приложения правила управления доступом на основе атрибутов. Эти правила должны быть дополнительными критериями, определяющими доступ наряду с ролью пользователя.
Для каждого ресурса или функции, требующей контроля на основе атрибутов, указать, какие атрибуты или функции должны проверяться и какие условия разрешают или запрещают доступ.
6 Access Control Logic:
Изменить логику управления доступом, включив в нее правила, основанные на атрибутах. Когда пользователь запрашивает доступ к ресурсу, система должна проверять как его роль, так и соответствующие атрибуты или характеристики.
Убедиться, что логика учитывает все соответствующие атрибуты и обеспечивает выполнение необходимых решений по управлению доступом.
7 Testing and Validation:
Провести тестирование механизмов управления доступом, включая новые правила, основанные на атрибутах.
Протестировать различные сценарии, чтобы убедиться в том, что пользователям предоставляется или отказывается доступ на основе их ролей и атрибутов.
8 Documentation:
- Задокументировать правила управления доступом, включая правила, основанные на атрибутах.
9 Error Handling and Logging:
- Обеспечить надлежащую обработку ошибок и логирование при возникновении проблем, связанных с контролем доступа.
- Регистрировать неудачные попытки авторизации и регулярно просматривать логи на предмет подозрительной активности.
10 Auditing and Monitoring:
- Внедрить аудит и мониторинг для отслеживания решений по управлению доступом и обнаружения попыток несанкционированного доступа.
11 Regular Review and Maintenance:
- С течением времени требования к управлению доступом могут меняться. Регулярно пересматривайть и обновляйть политики контроля доступа, включая правила, основанные на атрибутах, чтобы адаптировать их к изменениям в функциональности приложения и требованиям безопасности.