ГОСТ Р ИСО/ТС 22600-2—2009
4.6 Модель авторизации — назначение ролей и полномочий
Авторизация, проверка свидетельств и полномочий выполняются путем связывания ролей с полити
ками.
Роли представляют собой средство косвенного назначения полномочий отдельным лицам. Лицам
выдаются сертификаты назначения роли, у которых ватрибутах роли указаны одна или несколько ролей.
Полномочия назначаются не лицам, а ролям, для чего используются сертификаты спецификации роли.
Такое косвенное назначение полномочий позволяет изменять полномочия, назначенные данной роли, не
затрагивая сертификаты, назначающие роли отдельным лицам. Сертификаты назначения ролей могут быть
сертификатами атрибутов или сертификатами открытого ключа. Сертификаты спецификации ролей не мо
гут быть сертификатами открытого ключа, но должны быть сертификатами атрибутов. Если сертификаты
спецификации ролей не используются, то назначение полномочий роли может быть выполнено другими
средствами (например, может быть локально сконфигурировано контролером полномочий).
Возможны все следующие сценарии:
- любое число ролей может быть задано уполномоченным лицом по атрибутам (УЛА);
- сама роль и члены роли могут задаваться и администрироваться отдельно, разными УЛА: при этом
подразумевается, что роли могут быть локальными в рамках зоны, например на уровне организации, реги
она или страны:
- членство в роли, как и любое другое полномочие, можетделегироваться;
- роли и членству в роли может быть назначен любой требуемый срокдействия.
Если сертификат назначения роли является сертификатом атрибута, то атрибут «rote» содержится
в компоненте «attributes» сертификата атрибута. Если сертификат назначения роли является серти
фикатом открытого ключа, то атрибут «role» содержится в расширении «subjectDirectoryAttributes». В
последнем случае любыедополнительные полномочия, содержащиеся в сертификате открытого ключа,
являются полномочиями, непосредственно назначаемыми держателю сертификата. Таким образом,
заявитель полномочий может предъявить контролеру полномочий сертификат назначения роли,
подтверждающий, что ему назначена данная роль (например, «менеджер» или «покупатель»). Контролер
полномочий может знать заранее или установить каким-либо способом, какие полномочия связаны с
заявленной ролью, и. соответственно, принять, отклонить или модифицировать запрос на предоставление
полномочий. Информацию о полномочиях, назначенных для роли, можно взять из сертификата специ
фикации роли.
Контролер полномочий должен знать о полномочиях, назначенных роли. Назначение полномочий
роли может осуществляться внутри инфраструктуры управления полномочиями (ИУП) посредством серти
фиката спецификации роли или вне ИУП (например, конфигурируемое локально). Для варианта заявления
полномочий в сертификате спецификации роли в настоящем стандарте определены механизмы, позволя
ющие связатьданный сертификат с релевантным сертификатом назначения роли заявителя полномочий.
Издатель сертификата назначения роли может отличаться от издателя сертификата спецификации роли,
который выдает приписывающий рольсертификат, и эти сертификаты администрируются (например, соз
даются. заканчиваются, отзываются) совершенно отдельно. Один и тот же сертификат
(сертификататрибу та или сертификат открытого ключа) может содержать сертификат назначения роли,
атакже прямое назна чение лицудругих полномочий. Однако сертификат спецификации роли должен быть
отдельным сертифи катом.
П р и м е ч а н и е — Использование ролей в системе авторизации может усложнить процесс обработки пути,
поскольку такая функциональность существенным образом задает другой путь делегирования, которому надо
следовать. Путь делегирования для сертификата назначения роли может быть связан с разными УЛА и может не
зависеть от УЛА. выдавшего сертификат спецификации роли.
Общая модель управления полномочиями описывает три сущности: объект, заявителя полномочий и
контролера полномочий. Запрос на предоставление полномочий может быть авторизован, отклонен или
модифицирован.
4.7 Модель контроля
Контрольдоступа — это процесс определения того, позволяют ли полномочия заявителя получить
ему доступ к сервису, предоставляемому целевым компонентом. В данном контексте понятие доступа
шире, чем просто получение некоторых данных. Доступ может относиться к любому сервису, предостав
ляемому целевым компонентом (например, удалениеданных, выполнение вычислений, передача инфор
мации).
12