Ольга Полянская - Инфраструктуры открытых ключей
Если спектр задач и требований конфиденциальности организации слишком велик, то целесообразно разрабатывать несколько политик. Рассмотрим случай, когда компании необходимо осуществлять финансовые платежи на сумму свыше 1 млн долларов и одновременно поддерживать виртуальную частную сеть для оформления сделок, которые заключаются служащими компании, занимающимися продажами [70]. Конкурентам могут быть интересны полные данные об обороте этой компании, но полезность информации о сделках, заключенных одним продавцом, относительно мала. Политика, которая регулирует применение VPN-сертификатов продавцов, может быть гораздо менее строгой. Рассматриваемая компания не сможет хорошо обслуживаться одной политикой. Если ППС адекватно регулирует использование сертификатов продавцов, то будет подвергаться риску работа бухгалтеров, отвечающих за финансовые транзакции. Если же ППС обеспечивает гарантии безопасного выполнения финансовых транзакций, то выпуск сертификатов для продавцов становится сложным и дорогостоящим. Компания может либо реализовать две разные политики для удовлетворения требований каждого сообщества, либо поддерживать обе в соответствии с более высоким уровнем безопасности. Компании следует проанализировать издержки и доход от реализации каждой стратегии и решить, нужны ли ей две разные политики. Эта информация также может быть полезна для анализа издержек и дохода при страховании ответственности. Оператор УЦ может поддерживать политику страхования в отношении ошибок и оплошности персонала УЦ. Если ценность данных высока или приложения пересекают границы организации, то страхование ответственности должно быть соответствующим.
Второй этап разработки ППС - ознакомление с документом RFC 2527 [152], задающим структуру ППС, и несколькими образцами используемых политик, отвечающих аналогичным (проектируемой политике) требованиям. Если ожидается, что проектируемая PKI будет устанавливать отношения кросс-сертификации с другими PKI, то необходимо изучить профили сертификатов и списков САС этих инфраструктур. Разрабатывая новый профиль сертификатов с учетом профилей сертификатов будущих партнеров, можно избежать проблем функциональной совместимости в дальнейшем. Ключевыми моментами согласования являются криптографические алгоритмы, критичные дополнения и способы распространения информации об аннулировании сертификатов.
Третий этап - разработка проекта одной или нескольких политик применения сертификатов, релевантных требованиям организации. В примере, приведенном выше, имеет смысл для обеспечения безопасности работы бухгалтеров компании использовать сильные аппаратные криптографические модули, а для защиты операций продавцов - программные криптографические модули. Кроме того, ППС может содержать требование выдавать сертификаты бухгалтерам через службу безопасности компании в их личном присутствии, но при этом допускать рассылку сертификатов продавцам по почте (если, например, организация имеет филиалы).
Четвертый этап - это принятие решения об организации собственного УЦ или использовании услуг стороннего УЦ. Организация инсорсингового УЦ требует гораздо больших затрат, чем аутсорсинг. Экономически более выгодным решением может быть передача одних функций стороннему УЦ и выполнение других функций, например, РЦ или репозитория, своими силами.
Если организация принимает решение о создании собственного УЦ, то необходимо выбрать такие продукты PKI, которые пригодны для реализации конкретной политики. Выбранный продукт должен удовлетворять всем требованиям, изложенным в таких разделах ППС, как Идентификация и аутентификация, Операционные требования и Технический контроль безопасности. Если не все требования будут учтены, то персоналу УЦ впоследствии придется реализовывать сложные процедуры для преодоления "узких" мест PKI-продукта. Дополнительная сложность регламента повлечет за собой большие затраты на поддержание функционирования.
Завершающим этапом разработки ППС является составление регламента. Если организация создает свой собственный УЦ, то регламент идентифицирует сайты, которые будут использоваться PKI, и устанавливает соответствие между ролями, описанными ППС, и ролями и процедурами, поддерживаемыми PKI-продуктом и средствами физического контроля. Если используется аутсорсинг, то поставщик услуг должен продемонстрировать, что средства контроля и процедуры регламента его УЦ удовлетворяют требованиям ППС данной организации.
Эксплуатацию корпоративной PKI следует начинать с обучения персонала и апробации PKI в рамках небольшого сообщества. Это предполагает, что соответствующие пользователи имеют необходимую документацию (части ППС и регламента ) и понимают, как ее использовать. Особенно важно понимание своих обязанностей операторами УЦ, РЦ и системными администраторами.
Часто начальный опыт эксплуатации PKI приводит к пересмотру отдельных положений ППС, это подтверждает целесообразность предварительной апробации политики на небольшом числе пользователей PKI. После окончательного формирования ППС требуется ее аккредитация доверенной третьей стороной. Именно аккредитация являются решающим аргументом в пользу доверия к данной PKI со стороны пользователей и других удостоверяющих центров.
Лекция 15. Стандарты и спецификации PKI
Приводится классификация стандартов в области PKI, дается краткая характеристика каждой группы стандартов, подробно рассматриваются стандарты Internet X.509 PKI (PKIX), обсуждается терминология и концепции PKIX, дается представление о направлениях стандартизации в области PKI, приводятся примеры национальных и международных инициатив по обеспечению функциональной совместимости PKI-продуктов.
Стандарты в области PKI
Стандарты играют существенную роль в развертывании и использовании PKI. Стандартизация в этой сфере позволяет разным приложениям взаимодействовать между собой с использованием единой PKI [219]. Стандарты в области PKI можно разбить на четыре группы, каждая из которых относится к определенному технологическому сегменту, необходимому для создания PKI.
К первой группе (см. табл. 15.1) можно отнести стандарты серии X, подготовленные Международным Союзом по телекоммуникациям - ITU (International Telecommunications Union), и стандарты Международной организации стандартизации - ISO (International Organization for Standardization), относящиеся к PKI [10]. Они признаны в международном масштабе, содержат описания концепций, моделей и сервиса каталога (X.500) и формализуют процедуру аутентификации (X.509). Стандарт X.509 первоначально предназначался для спецификации аутентификации при использовании в составе сервисов каталога X.500. С течением времени X.509 претерпел ряд изменений, и его последняя (третья) версия была стандартизована группой инженерной поддержки Интернета - Internet Engineering Task Force (IETF). Документ X.509 регулирует хранение информации в каталоге и получение данных аутентификации. Он характеризует криптосистему с открытым ключом как метод сильной аутентификации, который базируется на создании, управлении и свободном доступе к сертификату, связывающему субъекта (пользователя) с его открытым ключом. Синтаксис сертификатов формата Х.509 выражается с помощью особой нотации, так называемой абстрактной синтаксической нотации версии 1 (Abstract Syntax Notation One - ASN.1), которая была предложена комитетом разработчиков стандартов взаимодействия открытых систем OSI (Open System Interconnection) для использования с протоколами X.500. ASN.1 описывает синтаксис различных структур данных, вводя примитивные объекты и средства описания их комбинаций [2]. Форматы электронного сертификата и САС, предложенные X.509, фактически признаны стандартом и получили всеобщее распространение независимо от X.500. Как показало время, наиболее ценной в стандарте X.509 оказалась не сама процедура, а ее служебный элемент - структура сертификата, содержащая имя пользователя, криптографические ключи и сопутствующую информацию [6].
|Номер и название стандарта | Содержание стандарта |
|X.500 | Каталог: обзор концепций, моделей и услуг |
|X.509 | Каталог: структура аутентификации |
|X.509a | Проект изменений и дополнений для продления срока действия сертификатов (расширение версии 3) |
|X.208 (ISO/IEC 8825)
Abstract Syntax Notation (ASN.1)
| Абстрактная синтаксическая нотация |
|X.209 | Основные правила кодирования для ASN.1 |
|ISO/IEC 8824
Object Identifiers (OIDs)
| Идентификаторы объектов |
|ISO/IEC 9594/8
Directory Services (X.509)
| Сервисы каталога (X.509) |
