Безопасность

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

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

Материал подготовлен на основе обобщения стандартов серии X.500, рекомендаций RFC 3039, 3280, 3647, требований Федерального закона 1-ФЗ от 10.01.2002 Об электронной цифровой подписи и опыта авторов, накопленного в ходе более чем 3-х летней практической эксплуатации удостоверяющих центров, в том числе мостового УЦ.

Политика сертификата

Политика сертификата это набор правил, определяющий использование сертификата некоторым сообществом и/или классом приложений с заданными требованиями безопасности. Политика сертификата представляется в сертификате объектным идентификатором, присвоенным этой политике. Согласно рекомендациям RFC 3647, каждый сертификат должен соответствовать хотя бы одной политике сертификата. Если в сертификате указано несколько политик, то это означает, что сертификат соответствует всем политикам списка. Для указания политик, которым соответствует сертификат, используется расширение Certificate Policies. Политики сертификата могут быть заявлены не только в конечных сертификатах, но и в сертификатах удостоверяющих центров. Такое заявление означает, что удостоверяющий центр издает сертификаты только в соответствии с этим набором политик.

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

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

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

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

Как видно из примера, политика сертификата для коммерческих целей выдвигает более жесткие требования, следовательно, и доверие к сертификату, изданному с такой политикой более высокое.

Расширения сертификатов X.509 связанные с политикой сертификата

В сертификатах предусмотрены следующие расширения, относящиеся к политикам сертификата: Certificate Policies, Policy Mappings и Policy Constraints.

Расширение Certificate Policies перечисляет политики сертификата, в соответствии с которыми издан и должен использоваться этот сертификат. Это расширение может содержать квалификатор политики, который содержит дополнительную информацию, относящуюся к политике сертификата. Возможно использование двух типов квалификаторов. Первый содержит URI, по которому доступен регламент УЦ (CPS ) или его краткое изложение (Summary CPS), соглашение с пользователем или документ, описывающий инфраструктуру открытых ключей (PDS ). Второй тип квалификатора содержит комментарий, который служит для уведомления пользователя о правилах и методах использования сертификата. Возможно использование как одного, так и квалификаторов двух типов одновременно.

Расширение Policy Mappings может использоваться только в сертификатах удостоверяющих центров. Это расширение позволяет отображать эквивалентность определенных политик сертификата одной инфраструктуры политикам сертификата другой инфраструктуры. Данное расширение применяется при установлении отношений доверия между двумя удостоверяющими центрами, использующими разные наборы политик сертификата, и позволяет определить соответствие политик разных удостоверяющих центров при кросссертификации или подчинении.

Расширение Policy Constraints предоставляет две дополнительные возможности. Первая позволяет удостоверяющему центру установить для подчиненных удостоверяющих центров требование явного указания политик сертификата. Вторая возможность позволяет удостоверяющему центру запретить подчиненным удостоверяющим центрам использование Policy Mappings. Этот запрет позволяет защитить удостоверяющий центр от транзитивных отношений доверия.

Регламент

Регламент удостоверяющего центра это документ, содержащий описание процедур и действий, которые удостоверяющий центр использует при издании и управлении сертификатами. Иными словами, это документ, описывающий весь перечень операций удостоверяющего центра. Необходимо заметить, что название регламент характерно для российской практики ИОК, зарубежные коллеги используют термин certification practice statement.

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

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

Третий подход предполагает использование в качестве регламента соглашения с владельцем сертификата и/или пользователем, либо комбинированное соглашение. Данный подход наиболее прост для понимания пользователем, однако наименее функционален с точки зрения удостоверяющего центра.

Сам регламент не является документом, создающим договорные отношения, однако он может использоваться как перечень условий при заключении соглашений.

Взаимосвязь между документами

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

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

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

Политика сертификата и регламент основные документы ИОК. Тем не менее, это не единственные документы. Например, соглашения с владельцем и пользователем сертификата определяют ответственность сторон. Как было сказано выше, в некоторых случаях эти документы могут использоваться как регламент. Кроме того, эти документы, в отличие от политики сертификата и регламента, являются элементами договорных отношений.

Правила построения дерева объектных идентификаторов

Прежде чем приступить к разработке документации организаторам ИОК необходимо определить правила построения дерева объектных идентификаторов.

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

Рекомендацией ITU-T X.660 введены понятия организация-координатор, регистрирующая организация и организацияэмитент. Организация-координатор организация, выполняющая надзор за исполнением требований рекомендаций и стандартов при регистрации объектов и осуществляющая взаимодействие между национальными и международными регистрационными организациями. Регистрирующая организация организация, выполняющая процедуру регистрации объектов. Организацияэмитент организация, инициирующая создание нового объекта с соответствующим ему уникальным идентификатором. ОАО Центральный Телеграф на инициативных условиях является организацией-координатором российского дерева объектных идентификаторов.

Российский корень дерева идентификаторов объектов имеет следующий вид:
{iso(1) member-body(2) ru(643)}.

Суффиксы следующего уровня:

• {Операторы связи (1)} регистрирующая организация REG1;
• {Производители ПО (2)} регистрирующая организация REG2;
• {Удостоверяющие центры (3)} регистрирующая организация REG3;
• {Банки (4)} регистрирующая организация REG4;

Соответственно, какаялибо организация, предоставляющая услуги удостоверяющего центра в России, может иметь OID 1.2.643.3.ХХХ. Зарегистрировавшись, организация получает статус организацииэмитента и может инициировать создание новых объектных идентификаторов.

Порядок инициирования нового OID определяется организациейэмитентом. То есть, организация разрабатывает свой порядок и принципы инициализации объектных идентификаторов. Можно при этом воспользоваться понятиями объектный класс и подкласс. Например, введем объектный класс документ. Уточним его подклассом тип документа. В этом контексте типами документов могут являться политики сертификатов, регламенты и т. п. Теперь мы можем определить конкретный объект регламент корневого удостоверяющего центра, принадлежащий классу документов и подклассу регламентов.

Определение состава сертификатов

Так же при разработке документации необходимо определить состав выдаваемых и используемых в ИОК сертификатов. В рамках данного раздела под словом организация следует понимать предприятие, ответственное за выпуск сертификатов. Кроме того, важно различать понятия владелец и пользователь сертификата. Владельцем сертификата является физическое лицо, которому принадлежит сертификат. Пользователь сертификата это субъект, какимлибо образом использующий сертификат.

Сертификат удостоверяющего центра, как и любой другой, содержит поля issuer (издатель) и subject (субъект). Поле subject сертификата удостоверяющего центра должно однозначно идентифицировать организацию и содержать официальную информацию о ней. В случае корневого сертификата, поля subject и issuer совпадают. Если же сертификат выдан другим удостоверяющим центром, в случае подчинения или кросссертификации, поле issuer будет содержать информацию об удостоверяющем центре, выдавшем сертификат, а поле subject информацию об удостоверяющем центревладельце сертификата.

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

• organizationName (O) официально зарегистрированное название организации;
• organizationalUnitName (OU) организационная единица;
• countryName (C) двухбуквенный код страны местонахождения организации в соответствии с ISO 3166;
• stateOrProvinceName (S или ST) для обозначения региона;
• localityName (L) обозначает город;
• streetAddress (STREET) почтовый адрес организации;
• e-mailM (E или EA) адрес электронной почты удостоверяющего центра.

При издании сертификата абоненту, удостоверяющий центр включает в него определенную информацию. Рассмотрим ее состав и назначение. Информация, содержащаяся в сертификате, должна однозначно идентифицировать организацию, ответственную за выпуск данного сертификата, и владельца сертификата. Для указания владельца сертификата используется поле subject, в котором содержится отличительное имя (Distinguished Name, DN), включающее следующий набор атрибутов:

• commonName (CN) ФИО или псевдоним, например Уполномоченное лицо. В случае указания псевдонима в соответствии с Федеральным Законом Об ЭЦП, запись об этом вносится в сертификат;
• organizationName (O) и organizationalUnitName (OU) содержат название организации и организационной единицы (например подразделение или должность);
• title (T) атрибут для указания должности;
• countryName (C) название страны. Данный атрибут определяет контекст, в рамках которого следует понимать остальные атрибуты (например, страна, в соответствии с законодательством которой используется данный сертификат) и содержит международный двухбуквенный код страны в соответствии с [ISO 3166];
• stateOrProvinceName (S, ST) обозначает регион;
• streetAddress (STREET) почтовый адрес владельца;
• e-mail (E, EA) адрес электронной почты владельца сертификата.

Кроме того, каждый сертификат должен содержать поле serialNumber, которое используется для предотвращения случаев совпадения имен. Серийный номер любого сертификата должен быть уникальным для всех сертификатов, выданных одним удостоверяющим центром.

Разработка политики сертификата и регламента

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

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

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

1. Введение
   Данный раздел идентифицирует и описывает содержание документа и области его применения.
2. Публикация и репозиторий

Раздел определяет публикуемую информацию, требования к организации хранения и доступа к ней.

3. Идентификация и аутентификация
   Данный раздел определяет правила и требования к аутентификации и идентификации участников при проведении каких-либо операций.
4. Функциональные требования жизненного цикла сертификата
   Данный раздел определяет требования и правила издания, управления и использования сертификата.
5. Организационные, эксплуатационные и физические меры обеспечения безопасности
   Данный раздел определяет не технические методы управления действиями участников ИОК.

Технические меры обеспечения безопасности
Данный раздел определяет технические меры обеспечения безопасности, предписываемые участникам ИОК.

6. Профили сертификатов и списков отозванных сертификатов
   Данный раздел должен содержать профили сертификатов и CRL, а так же иных методов проверки статуса сертификата, если таковые используются.
7. Аудит
   Данный раздел определяет требования и методы проведения аудита соответствия участников ИОК положениям руководящих документов.
8. Иные юридические и экономические аспекты
   Данный раздел определяет оплату услуг, финансовую ответственность, гарантии, права на интеллектуальную собственность и прочее.

Практическое применение данных рекомендаций позволит организовать инфраструктуру открытых ключей, регламентировать работу и обезопасить ее участников.