Читать онлайн «Инфраструктуры открытых ключей». Страница 83

Проектирование

Ключевым аспектом развертывания 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). Примерный перечень положений служит ориентиром при описании политики применения сертификатов и разработке регламента УЦ и помогает разработчикам политики и регламента не упустить важные моменты.

Это соглашение охватывает все стороны отношений между УЦ и РЦ. Если УЦ и РЦ являются компонентами модели инсорсинга, то соглашение между ними упрощается и приобретает статус внутреннего юридического соглашения между УЦ (обычно работающим под управлением ИТ-штата) и РЦ (обычно функционирующим под управлением штата, занимающегося административной и операционной работой). В любом случае это соглашение обязательно должно проходить процедуру утверждения и содержать следующие положения:

* размере компенсации РЦ удостоверяющему центру;

* финансовых гарантиях непрерывности функционирования УЦ;

* размере компенсации УЦ доверяющей стороне в случае выпуска фальшивого сертификата.

Это соглашение описывает отношения между пользователем сертификата и РЦ той организации, которая выпустила данный сертификат. Соглашение должно включать обязательства пользователя:

* предоставлять правдивую информацию, которая используется при выпуске сертификата;

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

* обращаться с заявлением об аннулировании сертификатов, если соответствующие секретные ключи потеряны или скомпрометированы;

* прекращать использование всех пар ключей (открытый/секретный), срок действия которых истек, и не стараться выдать их за действующие ключи.

Это соглашение можно назвать соглашением с доверяющей стороной. Оно содержит следующие положения:

* обязательство доверяющей стороны проверять статус сертификата перед его использованием, то есть убеждаться в том, что сертификат не просрочен и не аннулирован;

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

* размеры компенсации РЦ или УЦ в случае причинения ущерба доверяющей стороне.