ГОСТ ISO/TS 22600-3—2013
Составной частью таких политик регистрации являются политики идентификации и паролей. Политики иден
тификации описывают, каким образом создаются различные атрибуты различныхучетных записей на основе иден
тифицирующей информации пользователя и корпоративных правил безопасности.
Вданном примере политика идентификации можетсостоятьв создании имени учетной записи.которое состо
ит из первой буквы имени и букв фамилии пользователя (например, jsmrth для Joey Smith). Политика идентифика
ции может распространяться и на другие атрибуты, например, на адреса электронной почты.
Политики паролей могут применятьсядля контролирования способов создания и управления паролями. Нап
ример. а политике может быть указана минимально допустимая длина пароля, обязательно использование бука и
специальныхсимволов, атакже срокдейстаия. вынуждающий пользователейменятьсвоипароли каждые три меся
ца. Выполнение этих требований усиливает безопасность системы, поскольку слабость паролей создает извест
ные риски.
Федеративные политики образуют другой базовый уровень сценария. Они позволяют осуществлять провер
ку. отображение и передачу различных используемых токенов безопасности между зонами безопасности или сис
темами.
Предприятия должны обеспечивать возможность предоставления доступа к защищаемой медицинской
информации на основе наименьшей необходимой привилегии и необходимости знания, определяемой ролями
пользователя а организации и порученными ему заданиями.
Поэтому предприятиям необходим интегрированный подход к безопасности, предполагающий создание
инфраструктуры, удовлетворяющей следующим требованиям.
-согласованным образом аутентифицировать пользователей при пересечении периметра безопасности
предприятия и периметра федерации или внешней сети;
- согласованным образом авторизовать пользователей или предоставлять им разрешения доступа к защи
щаемым информационным активам;
- регистрировать доступ к чувствительной информации и к чувствительным функциям, а также их использо
вание;
- удовлетворять релевантным методическим указаниям и требованиям информационной безопасности.
Для аутентификации на своем портале пользователям могут требоваться ввод имени своей учетной записи
(например, homejoe. jsmlth или joe) или средства усиленной аутентификации.
Если пользователь запрашивает сервис как внешний потребитель, то для его аутентификации может потре
боваться объявление на языке SAML, а то время как для доступа к приложению ао внутренней сети от него будет
достаточно токена с именем учетной записи. Представляемый им токен сименем учетной записи может отличаться
от того, который необходим для аутентификации на местном портале (например, joesmith). Наконец, приложение
может проверить действительность удостоверения пользователя и отобразить его на местную учетную запись.
В сценарии с прямым воздействием потребители внутреннего сервиса должны использовать доверенный
сервис, чтобы передать идентифицирующую информацию, свидетельствующую, чтопользователь имеетдействи
тельное удостоверение. Например, местные имена учетных записей jsmlth или joe передаются с удостоверением,
сгенерированным для учетной записиjoe1234. Затем вызванное приложение проверяет это удостоверение. Служ бу
доверенных токенов безопасности STS (security token service) надо сконфигурировать таким образом, чтобы
токены безопасности правильно отображались на те. что воспринимаются получающими их субъектами в данном
сценарии.
А.З Описание сервисов инфраструктуры управления привилегиями на языке ASN.1
А.3.1 Спецификации сертификатов, основанных на стандарте X.S09
А.3.1.1 Общие сведения
Ролевая модель инфраструктуры управления привилегиями, основанная на стандарте Х.509. использует
сертификаты атрибута, описанные в стандарте ISO/IEC 9594-8. Примером использования такой инфраструктуры
может служитьпроект PermIs(13J. Сертификаты атрибута выпускаются органами по присвоению атрибутов. Серти
фикат атрибута привязан к идентификации субъекта с помощью поля владельца (holder) а сертификате идентифи
кации Х.509. Такое объединение обеспечивает возможность раздельного управления инфраструктурой
управления привилегиями и инфраструктурой открытых ключей [13). Это позволяет обеспечить конфиденциаль
ность чувствительной информации контроля доступа, если сертификаты идентичности могут управляться третьей
стороной. Спецификации ролей в инфраструктуре управления привилегиями, основанной на стандарте Х.509,
используют, по крайней мере, три типа сертификатов атрибута: сертификаты атрибута спецификации роли, серти
фикаты атрибутаназначения роли и сертификаты атрибута политик. Всеони заверены электронной подписью орга на
по присвоению атрибутов и тем самым защищены от подделки.
Сертификаты атрибута спецификации роли содержат разрешения, назначенные этой роли. Сертификаты
атрибута назначения роли содержат список ролей, назначенных субъекту сертификата. Сертификаты атрибута
политик указывают корневой узел доверия для инфраструктуры управления привилегиями и в качестве значения
атрибута содержат ссылку на файл политики. Сертификаты атрибута обычно хранятся в каталоге, управляемом
сервисом LDAP. Контролер находит а каталоге все сертификаты атрибута назначения роли, выпущенные для дан
ного пользователя, проверяет электронную подпись каждого сертификата ипроверяет,чтосертификаты не отозва-
22