Книга: Инфраструктуры открытых ключей
Механизмы, которые необходимы для сервисов, базирующихся на PKI
К механизмам, которые необходимы для сервисов на базе PKI, относятся:
* цифровые подписи, хэш-функции, коды аутентификации сообщений (MAC) и шифры;
* надежные источники времени;
* механизмы создания политики полномочий ;
* механизмы обработки политики полномочий ;
* механизмы инфраструктуры управления полномочиями ;
* архитектура приватности.
Цифровые подписи, хэш-функции, коды аутентификации сообщений и шифры
Так как сервис защищенной связи полагается на главные PKI-сервисы, то требует наличия механизмов, обеспечивающих их поддержку. К ним относятся цифровые подписи, криптографические хэш-функции, алгоритмы вычисления кодов аутентификации сообщений MAC и симметричные блочные шифры.
Надежные источники времени
Сервис защищенного датирования требует наличия одного или нескольких надежных источников времени, то есть способа получения надежного представления текущего времени (синхронного глобальному времени, с высоким уровнем точности) одного или нескольких устройств/субъектов в локальной среде >[120].
Как обсуждалось ранее, на практике получение надежного времени для небольшого количества устройств оказывается организовать легче, чем получение надежного времени для каждого устройства в сети. Однако получение надежного времени даже для одного устройства может быть нетривиальной задачей. Одним из вариантов ее решения является использование центра датирования: если каждый субъект в данной среде доверяет времени, установленному этим центром, то внутри данной закрытой среды не имеет значения, является ли время центра датирования точным. Однако точность проставления меток времени центром датирования и, следовательно, надежность доказательств очень актуальна при разрешении споров, касающихся отказа от действий одной из сторон.
Механизмы создания и обработки политики полномочий
Поддерживаемый PKI сервис управления полномочиями зависит от существования политик, которые описывают определенные полномочия отдельных индивидов, групп или ролей (должностей). Простой пример - список управления доступом, который перечисляет решения по предоставлению или лишению полномочий в соответствии с именами субъектов или ролями. В основном политики полномочий задаются при помощи логических выражений, определяющих точные условия, в соответствии с которыми предъявляющий права может их реализовать под контролем проверяющего. Эти выражения могут включать временные ограничения любой сложности (например, последний вторник каждого второго месяца от 900 до 1300), а также любые другие условия использования полномочий. Такие сложные выражения для политики полномочий требуют наличия соответствующих механизмов их формирования и редактирования.
Политика полномочий должна быть не только разработана и отредактирована, но и обработана и воспринята механизмом верификации некоторого вида (иногда называемым точкой принятия решений о политике ) в момент запроса субъектом доступа к некоторому ресурсу. То есть точка принятия решения о политике использует политику полномочий как закон, согласно которому принимается или отвергается запрос субъекта на доступ к ресурсу или сервису. Для восприятия политики полномочий компьютером необходим формальный язык спецификации политики (например, язык eXtensible Access Control Markup Language - XACML или Annex D стандарта X.509) >[44]. Важным требованием общих инфраструктур управления полномочиями являются механизмы, которые могут интерпретировать закодированные политики и действовать в соответствии с ними.
Механизмы инфраструктуры управления полномочиями
Существует ряд механизмов реализации инфраструктуры управления полномочиями (Privilege Management Infrastructure - PMI). Они делятся на три категории:
* механизмы на базе Kerberos >[135], такие как SESAME (a Secure European System for Applications in a Multi-vendor Environment) >[125] и DCE (Distributed Computing Environment) >[71];
* механизмы, базирующиеся на концепции сервера политики, то есть центрального сервера, который создает, поддерживает и проверяет политику полномочий для индивидов, групп и ролей;
* механизмы, основанные на атрибутных сертификатах, которые подобны сертификатам, определенным в стандарте X.509 и языке Security Assertion Markup Language (SAML) >[111]. Атрибутный сертификат аналогичен сертификату с открытым ключом, но связывает идентификационные данные субъекта не с открытым ключом, а с информацией о полномочиях или правах субъекта.
Все три механизма имеют своих сторонников и противников, так как обладают как определенными преимуществами, так и недостатками >[58]. Схемы Kerberos, основанные на симметричных ключах, характеризуются высокой производительностью, но в то же время более сложным управлением ключами и недублированной точкой возможного отказа. Схемы сервера политики сильно централизованы, имеют одну точку администрирования, но достаточно высокие издержки связи. Схемы атрибутных сертификатов могут быть полностью распределенными и поэтому обладают высокой устойчивостью к отказам, но их производительность невысока, особенно если для верификации сертификатов требуются операции с открытыми ключами.
Каждый механизм PMI может успешно применяться в одних условиях и быть неэффективным в других. Так, например, технология, основанная на Kerberos, может быть лучшим вариантом выбора в среде, где обрабатывается большое количество транзакций в режиме реального времени. Архитектура на базе сервера политики больше подходит для географически локализованных сред с сильным централизованным управлением. И, наконец, технологию атрибутных сертификатов следует предпочесть для межкорпоративной авторизации, которая необходима для поддержки сервиса неотказуемости. Иногда возможно использование двух механизмов, каждый из которых поддерживает определенный набор функций PMI.
Из всех перечисленных механизмов PMI технология атрибутных сертификатов теснее всего связана с использованием PKI, так как АС может быть подписан цифровым образом или содержать зашифрованные атрибуты. Все три механизма могут быть реализованы как дополнительные сервисы PKI, однако авторизация обычно связана с аутентификацией, и каждый механизм может работать с сервисом аутентификации PKI.
Архитектура приватности
Для реализации сервиса приватности необходимо создать архитектуру приватности, то есть организовать, по крайней мере, один УЦ по выпуску анонимных сертификатов или сертификатов, издаваемых под псевдонимом, и обеспечить, чтобы доверяющие стороны могли принимать и обрабатывать такие сертификаты >[105]. Архитектура приватности на базе сертификатов может быть двух типов:
1 УЦ знает подлинные идентификационные данные субъекта, но выпускает сертификаты, которые скрывают идентичность субъекта от всех остальных;
2 УЦ не знает подлинных идентификационных данных субъекта (они известны только самому субъекту), но, тем или иным способом, выпускает значимые сертификаты.
- Добавление списка необходимых предметов
- Как продолжить работать с данными, которые я сохранил вчера?
- Кризис – это возможность. 10 стратегий, которые позволят вам процветать в эпоху перемен Скотт Стейнберг
- Могу ли я изменить или отключить звуки, которые проигрываются при запуске Windows, щелчке кнопкой мыши на папке и т. д.?
- При завершении работы Windows сообщает, что некоторые процессы не отвечают, и компьютер не выключается. Как завершать та...
- Я установил Service Pack 2 для Windows XP, но с ним не хотят работать некоторые программы. Как его удалить из системы?
- Если я куплю 64-битный процессор, будут ли у меня работать программы, которые были разработаны специально для 32-битных ...
- Презентация: 30 минут, которые способны изменить ваш бизнес
- Можно ли сравнить файлы Microsoft Word, правки в которые вносили разные пользователи?
- Гибридная архитектура PKI
- 14.12.7. Перенаправление сервисов
- Некоторые полезные рекомендации по веб-сайту