ГОСТ ISO/TS 22600-3—2013
е) подписанные атрибуты, которые могут быть приложены к документу, включая:
- дату и время подписи;
- цель подписи;
- выполняемые роли.
- идентификаторы подписывающего сертификата и политики;
- причину подписи (текстовое описание).
- аннотацию.
- идентификатор устройства использованного криптографического модуля.
Подпись, заверяющая другую подпись, передается какнеподписанный атрибут, который подписывает значе
ние подписи, содержащейся в структуре Slgnerlnfo.
А.11.6 Модель ролевого доступа ANSI RBAC
В стандарте ANSI RBAC разрешения определены какдействия над защищенным обьектом. однако этотстан
дарт не описывает ни специфические действия, ни специфические объекты. Объекты могут существовать на раз
ныхлогических уровнях. Например, конкретные объекты могут быть определены как отдельные элементы данных,
таблицы либо агрегаты элементов данных и таблиц. К более абстрактным объектам относятся профили работ,
задачи, сценарии или шаги.
В стандарте ISO/TS 22600-2:2006 на рисунке 9 представлена схема ролевого контроля доступа, адаптирую
щая стандарт ANSI RBAC. На этом рисунке показано, что связь функциональных ролей с сеансом представляет
собой сеансовую роль, активированную в этом сеансе пользователя, а связь пользователя с сеансом
описывает сеанс пользователя. Разрешения, которые доступны пользователю, суть разрешения, присвоенные
ролям, кото рые в настоящий момент активны во всех сеансах пользователя.
Каждый компонент модели состоит из субкомпонентов.
- совокупность базовых множеств элементов:
- совокупность отношений ролевого контроля доступа, ассоциированных с этими множествами элементов
(содержащие подмножества декартова произведения, обозначающие допустимые присваивания);
- совокупность отображающих функций, которые связывают члены одного множества элементов с данным
членом другого множества.
А.12 Эквивалентность политик
Обмен информацией опривилегиимежду зонами безопасности возможен по соглашению сторон. Такое взаи
модействие между зонами подлежит координации как на техническом, так и на документальном уровне.
При передаче информации о привилегии необходимо обеспечить одинаковую интерпретации привилегии в
каждой зоне безопасности. Этого можнодостичь, создав стандартный комплекс привилегий. Такой комплексможет
включать в себя взаимно однозначное отображение эквивалентных процедур междузонами. Чтобы достичь требу
емой степени безопасности, необходимо выполнять техническую проверкуэквивалентности передаваемых приви
легий.
Информация опривилегии, передаваемая междузонами безопасности, можетсодержатьсведенияо различ
ных административных субъектах, например, деловых партнерах или организациях. Соглашение о передаче при
вилегий и их интерпретации должно документироваться, обычно — в «соглашении деловых партнеров».
Это необходимодляразграничения юридической, этической ипрактическойответственности сторон в инфраструк
туре управления привилегиями. Кроме того, такое соглашение может быть расширено на другие стороны, взаимо
действующие с инфраструктурой управления привилегиями. Эквивалентная процедура выполняется в
инфраструктуре открытых ключей с помощью объявления о практике сертификации и политик сертификации.
Альтернативным вариантом является использование «объявлений политики» в спецификации политик веб-серви
сов WS-policy.
47