- •7.5.2. Трехфазное подтверждение
- •7.6. Восстановление
- •7.6.1. Основные понятия
- •7.6.2. Создание контрольных точек
- •7.6.3. Протоколирование сообщений
- •7.7. Итоги
- •Глава 8
- •8.1. Общие вопросы защиты
- •8.1.1. Угрозы, правила и механизмы
- •8.1.2. Вопросы разработки
- •8.1.3. Криптография
- •8.2. Защищенные каналы
- •8.2.1. Аутентификация
- •8.2.2. Целостность и конфиденциальность сообщений
- •8.2.3. Защищенное групповое взаимодействие
- •8.3. Контроль доступа
- •8.3.1. Общие вопросы контроля доступа
- •8.3.2. Брандмауэры
- •8.3.3. Защита мобильного кода
- •8.4. Управление защитой
- •8.4.1. Управление ключами
- •8.4.2. Управление защищенными группами
- •8.4.3. Управление авторизацией
- •8.5. Пример — Kerberos
- •8.6. Пример — sesame
- •8.6.1. Компоненты системы sesame
- •8.6.2. Сертификаты атрибутов привилегий
- •8.7. Пример — электронные платежные системы
- •8.7.1. Электронные платежные системы
- •8.7.2. Защита в электронных платежных системах
- •8.7.3. Примеры протоколов
- •8.8. Итоги
- •Глава 9
- •9.1. Corba
- •9.1.1. Обзор
- •9.1.2. Связь
- •9.1.3. Процессы
- •9.1.4. Именование
- •9.1.5. Синхронизация
- •9.1.6. Кэширование и репликация
- •9.1.7. Отказоустойчивость
- •9.1.8. Защита
- •9.2. Dcom
- •9.2.1. Обзор
- •9.2.2. Связь
- •9.2.3. Процессы
- •9.2.4. Именование
- •Синхронизация
- •Репликация
- •Отказоустойчивость
- •9.2.8. Защита
- •9.3. Globe
- •9.3.1. Обзор
- •9.3.2. Связь
- •9.3.3. Процессы
- •9.3.4. Именование
- •9.3.5. Синхронизация
- •9.3.6. Репликация
- •Отказоустойчивость
- •9.4. Сравнение систем corba, dcom и Globe
- •9.4.1. Философия
- •Процессы
- •9.4.4. Именование
- •Синхронизация
- •Кэширование и репликация
- •Отказоустойчивость
8.6.2. Сертификаты атрибутов привилегий
SESAME осуществляет не только аутентификацию клиентов и серверов, но и обеспечивает авторизацию. Для этих целей используются сертификаты атрибутов, которые, как уже говорилось ранее, выдаются сервером PAS. Чтобы получить представление о том, как выглядят сертификаты атрибутов, рассмотрим РАС системы SESAME детальнее.Каждый сертификат РАС содержит несколько полей (табл. 8.2). Первые два оля идентифицируют место, откуда передан сертификат. Имя сервера PAS может определяться именем домена. Далее в РАС включен уникальный серийный номер, который может быть использован для проверки.
Следующие три поля относятся к сроку жизни сертификата. Значение времени создания РАС по UTC хранится в отдельном поле. Это время, определяемое сервером PAS, создавшим РАС. Кроме того, сохраняется время начала и конца периода годности РАС. Возможно, РАС можно использовать в течение нескольких временных отрезков. Это поле РАС может не использоваться. Временные отрезки определяются в других полях.
Существует несколько способов подписать РАС. Конкретный метод определяется специфическим для SESAME идентификатором алгоритма. Сама подпись сохраняется в другом поле. Вместе с идентификатором алгоритма годность РАС может быть впоследствии проверена получателем.
Поле привилегий содержит список пар (атрибут, значение), определяющих права доступа, полученные владельцем РАС. Каждая привилегия ассоциирована с набором полномочий. По определению эти полномочия относятся к домену защиты, который вызвал РАС, в частности домен, в котором расположен сервер
PAS, создавший этот сертификат РАС. Однако можно также ассоциировать с привилегией другой защищенный домен.
При необходимости можно предоставить дополнительную информацию, которая поможет принимающей системе PVF подтвердить подпись РАС. В частности, в поле информации о сертификате может храниться сертификат, содержащий открытый ключ PAS, которым был подписан сертификат РАС. И наконец, имеется поле для дополнительной информации, используемое в настоящее время только с целью аудита.
Сертификат атрибута может быть, а может и не быть делегируемым. В любом случае можно определить, для какой цели (делегирование или использование на месте) пригоден данный сертификат РАС. Эта информация хранится в отдельном поле методов защиты РАС.
8.7. Пример — электронные платежные системы
Ранее мы в основном рассматривали вопросы защиты традиционных распределенных систем — клиент и сервер создавали защищенный канал связи, после чего клиент обращался к службам сервера. В основном вся защита ограничивалась двухсторонним взаимодействием.
Однако в реальном мире использование распределенных систем постепенно перестало сводиться к взаимодействию клиента с сервером. Мы видим, в частности, что по мере распространения Интернета распределенные системы находят применение в различных типах приложений, связанных с электронной коммерцией. Другими словами, люди покупают или продают через Интернет. В этом разделе мы кратко рассмотрим важнейший аспект электронной коммерции, а именно, вопрос о том, как происходит оплата товаров. Мы покажем, что электронные платежные системы основаны на методиках, разработанных для распределенных систем, особенно в части их надежности и защиты. Описания электронных платежных систем можно найти в [19, 350].
