Ольга Полянская - Инфраструктуры открытых ключей

Организации необходимо не только изучить информацию, предоставленную заказчиком о реализованных им проектах PKI того же масштаба (скорее всего, это будут примеры успешных проектов), но и самостоятельно связаться с бывшими и настоящими клиентами данного поставщика и выяснить их мнение об опыте взаимодействия с поставщиком.

Подробно рассматривается процесс проектирования PKI, приводится краткая характеристика основных правовых документов PKI, описываются соглашения между участниками PKI, даются рекомендации по выбору основных средств и оборудования, приводятся примерные требования к персоналу, обслуживающему PKI, обсуждается создание прототипа, пилотный проект и внедрение PKI.

Ключевым аспектом развертывания PKI является выбор архитектуры и проектирование . PKI допускает гибкость проектирования независимо от выбранной технологии. Этап проектирования занимает длительное время, так как на этом этапе должна быть сформирована политика PKI и регламент , задана архитектура PKI, определены аппаратные и программные средства поддержки инфраструктуры, выбраны ее компоненты, сервисы, режимы работы, протоколы и базовые стандарты [20].

Проектирование PKI невозможно без рассмотрения правовых аспектов ее функционирования: ППС и регламента , ответственности, страхования и др. Многие приложения PKI так или иначе нуждаются в правовой поддержке, поскольку работают с документами, заверенными цифровой подписью, или, например, требуют восстановления секретных ключей через процесс депонирования. Организации необходимо оценить необходимость разработки собственных юридических документов; если в штате имеются юристы, то им может быть поручена разработка таких документов, в противном случае организация может позаимствовать политику известного УЦ, предоставляющего услуги аутсорсинга. Хотя этот способ и не обеспечивает большой гибкости в разработке юридических документов заказчика, но он прост и экономичен.

Проектирование PKI должно начинаться со сбора эталонных политик и использования их в качестве шаблонов для разработки политики данной PKI [84]. Цифровые сертификаты служат базисом доверия при коммуникации между сторонами. Политика должна разрабатываться с учетом всех возможных проблем безопасности в данной среде, неадекватность и нечеткость политики ведет к ошибкам при реализации системы безопасности и может угрожать целостности всей PKI. При формировании политики необходимо ориентироваться на стандарты в области PKI, позволяющие обеспечить функциональную совместимость разных инфраструктур открытых ключей.

Если организация решает самостоятельно сформировать правовую политику , то должна разработать следующие документы:

* политику применения сертификатов и регламент УЦ;

*политику аутентификации;

* политику конфиденциальности(в отношении сведений, предоставляемых пользователями в целях аутентификации).

Организация, эксплуатирующая PKI, должна заключить со своими внутренними и внешними пользователями соглашения, закрепляющие ответственность сторон. Правовое регулирование PKI предполагает заключение трех видов соглашений:

* cоглашение УЦ с РЦ ;

* cоглашение между конечными субъектами и РЦ ;

*cоглашение между подписчиками/конечными субъектами и УЦ (причем в качестве конечного субъекта может выступать человек или устройство).

Как правило, архитектура PKI эволюционирует от одиночных изолированных удостоверяющих центров к более сложным формам, устанавливающим отношения доверия между разнородными центрами. Эти отношения закрепляются сертификатами. Каждой политике применения сертификатов в своем домене доверия присваивается идентификатор объекта. Идентификатор политики- это уникальный зарегистрированный идентификатор объекта ( политики применения сертификатов ), который анализируется при принятии решения о доверии данному сертификату и возможности его использования для определенной цели. Идентификаторы политик характеризуют набор приложений, для которых пригоден данный сертификат. Сертификат формата X.509 v.3 в дополнении certificatePolicy может содержать один или более идентификаторов политики в зависимости от числа политик применения сертификатов данного УЦ.

В том случае, если удостоверяющие центры выпускают сертификаты в соответствии с общими политиками, в дополнении certificatePolicy указываются идентификаторы этих политик , и нет необходимости использовать другие дополнения и ограничения. Когда удостоверяющие центры работают в разных доменах политики, то процедуры согласования политик становятся более сложными [84]и требуется тщательный анализ соответствия политики каждого УЦ политикам других удостоверяющих центров. Отношения между политиками фиксируются в дополнении соответствия политик policyMappings . Это дополнение сертификата позволяет удостоверяющим центрам задавать ограниченный набор приемлемых политик и отклонять сертификаты, выпущенные в соответствии с неприемлемой для данного УЦ политикой. Кроме того, функциональная совместимость доменов может достигаться в результате заключения формальных соглашений между корпоративными доменами, желающими взаимодействовать в соответствии с одной или несколькими междоменными политиками.

ППС обеспечивает определенный уровень доверия доверяющей стороны к сертификату, изданному на условиях, описанных в этой политике. Если, например, организация передает функции УЦ на аутсорсинг и ей необходим очень надежный сертификат, то она может запросить от УЦ сертификат высокого уровня безопасности. В этом случае УЦ, прежде чем выпустить сертификат, будет выполнять огромное число проверок. Другой крайностью может быть выдача сертификатов, перед выпуском которых выполняется минимальная проверка, например, правильности адреса электронной почты будущего владельца сертификата.

Регламентописывает процессы и процедуры выполнения УЦ операций с сертификатами. ППС характеризует надежность конкретного сертификата, а регламент - надежность самого УЦ. ППС разрабатывается на достаточно длительный срок и должна удовлетворять строгим требованиям, обычно она излагается в соответствии с форматом описания политики, который задает документ RFC 2527 Certificate Policy and Certification Practices Framework [152]. Этот документ содержит стандартный иерархический набор положений, сгруппированный в 8 основных разделов и 185 подразделов второго и третьего уровней (подробное описание формата ППС и регламента УЦ см. в лекции 14). Примерный перечень положений служит ориентиром при описании политики применения сертификатов и разработке регламента УЦ и помогает разработчикам политики и регламента не упустить важные моменты.