ГОСТ ISO/TS 22600-3—2013
Профиль XACML RBAC поддерживает также иерархический ролевой контрольдоступа, позволяя описывать
наследование свойств ролей. Для поддержки системных функций и функций пересмотра, описанных в стандарте
ANSI RBAC. в этом профиле описаны дополнительные политики, и именно, роль RPS (Role PollcySet) ассоциирует
владельцаданного атрибута роли с набором разрешений PPS (Permission PollcySet). который описывает разреше
ния. назначенные данной роли. Объекты RPS и PPS эквивалентны сертификатам атрибута назначения роли и сер
тификатам атрибута спецификации роли в ролевой модели, основанной на стандарте Х.509.
Интегрированное описание свойств ролевой инфраструктуры управления привилегиями на языке XACML
предоставляет богатые и расширяемые средства описания политик. Понятия структурных и функциональных
ролей обеспечиваются спомощью двухслойной системы, охватывающей атрибуты ролей, и именно, пользователи
могут иметь роли, назначенные им в контексте запроса. Компонент, отделенныйот точки принятия решений, может
использовать политику назначения ролей XACML или PolicySet, чтобы активировать атрибуты в сеансе пользо
вателя.
А.4.2 Другие сервисы инфраструктуры управления привилегиями
В А.5 приведены примеры других сервисов инфраструктуры управления привилегиями, описанных на языке
XML.
А.5 Примеры управления привилегиями, сценариев контроля доступа и сервисов
А.5.1 Назначение привилегий на основе структуры организации
Когда привилегииназначаются наоснове структуры организации, тоструктурные роли, определенные в соот
ветствии со стандартом ISO/TS 21298. отражают отношения между физическим лицом и структурной единицей,
включающие всебя назначение привилегий. В этомслучае привилегия основана на принадлежностикорганизации.
Этот подход распространяется не только на лица, но и на такие типы субъектов как системы, компоненты,
устройства. Назначенные привилегии могут использоваться как внутри данной организации, так и во внешнихорга
низациях (например, принадлежность к уполномоченным органам).
А.5.2 Назначение привилегий на основе рабочих процессов
Чтобы обеспечить реализацию процесса, привилегии могут назначаться на его выполнение. Привилегии
могут быть назначены на выполнение всего процесса, определенных действий или даже определенных транзак
ций. Этотподходсостоит в назначении привилегий в соответствии с функциональной ролью субъекта,следуя стан
дарту ISO.’TS 21298. Он отражает связь между отдельным субъектом и действием.
А.5.3 Управление привилегиями на основе политик
Привилегии могут назначаться в соответствии с ограничениями на время, условия среды, функции, опера
ции. установленные законодательством, нормативными актами, спецификациями и т. д.
А.5.4 Назначение роли и разрешений
Ограничения.задающие привилегии иобязанности, обычно указаны в политиках. Вслучаепростых политик и
взаимосвязей привилегии и обязанности могут быть преобразованы вроли, какэто делается а простых реализаци ях
ролевого контроля доступа, например, в стандарте HL7 RBAC (15). Недостаток такого упрощенного подхода
состоит втом.что число создаваемыхролей растетпри появлении новых политик. Кроме того, такие существенные
аспекты какконтекст доступа идругие переменные (см. стандарт ISO/TS 22600-2) не могут быть подходящим обра
зом рассмотрены. Дополнительные сведения см. в стандарте ISO/TS 21298.
А.5.5 Спецификация авторизации
Орган по присвоению атрибутов (ОА)и центр сертификации (ЦС) логически (и во многих случаях физически)
совершенно независимы. Создание и эксплуатация «идентичности» могут (и часто должны) быть отдельными от
инфраструктуры управления привилегиями. Таким образом, вся инфраструктура открытых ключей, включая ЦС.
могут существовать и действовать до создания инфраструктуры управления привилегиями. Хотя ЦС и является
уполномоченным органом идентификации в своей зоне безопасности, он автоматически не становится уполномо
ченным органов по присвоению привилегий. Следовательно. ЦС не обязательно выполняет функции ОА. Отсюда
можно сделать вывод, что ЦС не обязан нести ответственность за решение, что другие субъекты могут функциони
ровать в качестве ОА (например, не обязан включать такое назначение в их сертификаты идентификации).
Источником полномочий является субъект, которому контролер привилегий доверяет как органу, всецело
отвечающему за назначение комплекса привилегий. Ресурс может ограничить сферу ответственности источника
полномочий, доверяя определенным источникам разные функции (например, один источник отвечает за назначе
ние привилегий чтения, а другой — привилегий записи). Любой источник полномочий в то же время является ОА.
поскольку он выпускает для других субъектов сертификаты, идентифицирующие привилегии, назначенные этим
субъектам. Источник полномочий аналогичен «корневому» ЦС или «доверенной привязке* в инфраструктуре
открытых ключей в том отношении, что контролер привилегий доверяет сертификатам, выпущенным источником
полномочий. В некоторых реализациях необходимы ЦС.тщательно контролирующие субъектов,действующих как
источники полномочий. В настоящем приложении предусмотрен механизм обеспечения такого требования. В дру
гих реализациях такой контроль не является необходимым, и механизмы удостоверения того, что субъект может
выступать в качестве источника полномочий, могут оказаться вне рамок данной части настоящего стандарта.
Предложения, сформулированные в настоящем приложении, являются гибкими и могут удовлетворить тре
бования. предъявляемые во многих реализациях.
30