PKI: Как это работает

Роджер Янглав

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

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

IPSec, протокол туннелирования Уровня 3 (сетевого уровня), сегодня обычно используется для шифрования и выделения данных для защищенной передачи по VPN корпоративных сетей. Ряд методов аутентификации, служащих для проверки идентичности допущенных пользователей, может реализовываться через IPSec, включая пароли, известные серверу и клиенту, доступ с передачей маркера и цифровые сертификаты. Для широкой реализации в экстранет самым простым методом является Инфраструктура Открытых Ключей (Public Key Infrastructure, PKI), использующая технологию цифровых сертификатов. Эта статья расскажет о том, как PKI работает в среде VPN.

Определение PKI

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

Простая PKI начинается с Certificate Authority (CA), программного пакета, используемого в защищенном режиме доверенной третьей стороной для выпуска цифровых сертификатов X.509v3. Цифровой сертификат представляет собой структуру электронных данных, связывающую значения открытого ключа с идентифицирующей информацией о конкретном предмете. Цифровой сертификат подписывается цифровым методом (авторизуется) с помощью выпуска Certificate Authority. Цифровой сертификат гарантирует любой сертифицированной организации, использующей открытый ключ, что соответствующий закрытый ключ хранится соответствующим удаленным предметом. Разъяснение полей информации в сертификате можно найти в RFC 2459 (Internet X.509 Public Key Infrastructure Certificate and CRL profile), опубликованном в Январе 1999 года. В сильнозащищенной области Certificate Authority также имеется как минимум X.509v3-совместимая база данных. CA-оператор выпускает цифровой сертификат к End Entity (конечной сущности; в данном случае - конечным точкам EE-IPSec) и сохраняет копию сертификата в базе данных для последующего обращения. Языком, используемым для любых запросов к базе данных X.509v3, является Lightweight Data Access Protocol v3 (LDAP v3).

Обслуживание недействительных сертификатов

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

В этом случае CA-оператор может пойти двумя путями. Сертификат может быть внесен в Certificate Revocation List (CRL-X.509v2) и выпущен на определенный срок. CRL остается в v2, так как было оговорено, что при переходе других компонентов на v3 в него не было внесено никаких изменений. Либо аннулирование сертификата осуществляется с помощью Online Certificate Status Protocol (OCSP) на онлайновом сервере, представляющим собой, например, сервер базы данных X.509 v3, обеспечивающий сервис такого рода.

Каждый раз, как конечная точка IPSec проверяет допустимость сертификата, предоставленного для аутентификации, она проверяет последний кэшированный CRL или использует OCSP для определения, включен ли данный сертификат в соответствующий список. Если он в списке, это означает, что сертификат больше не действителен и конечная точка IPSec его отклонит.

Как работает сложная PKI

Сложная PKI может использовать множество различных CA с Root CA (корневыми CA). Root CA хранит "собственноручно" подписанный сертификат и выпускает сертификаты для подчиненных CA (т.е. относящихся к более низкому уровню), которые, в свою очередь, могут выпускать сертификаты для различных RA (Registration Authorities) или LRA (Local Registry Authorities). В процессе работы RA или LRA получает исходный запрос на сертификат от запрашивающей стороны и передает аутентифицированный запрос своему CA, выпускающему этот сертификат. Иерархия различных CA напоминает дерево, именно поэтому исходный CA назван Root CA (см. Рис. 1).

К этому моменту между всеми EE (в данном случае - конечными точками IPSec) всех подчиненных СА устанавливается "цепь взаимного доверия" (chain of trust). Однако как EE-1, Relying Party (полагающаяся на сертификат сторона, RP), чей сертификат выпущен CA-1, узнает, что сертификат EE-5, выпущенный CA-2, заслуживает доверия? Это происходит следующим образом: Сначала EE-1 проверяет либо все CRL либо использует OCSP, чтобы определить допустимость сертификата EE-5. Затем EE-1 проверяет, кто подписал сертификат EE-5, и обнаруживает, что авторизующей стороной является CA-2. Теперь EE-1 необходимо узнать, кто такой CA-2, поэтому она проверяет, кто подписал сертификат CA-2. EE-1 обнаруживает, что это был CA-0, корневой сертификат, подписавший и сертификат CA-1. CA-1 выпускает и подписывает сертификат EE-1.

Эта информация обеспечивает проверку допустимости EE - 5, так как они находятся в рамках одной PKI. Такая процедура называется "проход по цепи доверия" или просто "проход по цепи". Это основные элементы работы отдельной PKI. Далее в этой статье будут рассмотрены множественные реализации PKI. Сертификационная политика (Certificate Policy) устанавливает основные правила. Независимо от того, сама ли компания, реализующая PKI, использует CA, или поручает это делать кому-то еще, она все равно должна определить для себя Сертификационную политику (Certificate Policy, CP). CP очерчивает требования, необходимые в процессе аутентификации для получения сертификата от CA, а также может определять уровень полномочий (например, "этот сертификат имеет право подписи информации по сделкам, не превышающим один миллион долларов ").

В случае конечной точки IPSec CP определяет, какая информация должна быть предъявлена CA для аутентификации до выпуска сертификата для этой конечной точки. Он также определяет, какую информацию будет содержать индивидуальный сертификат и как он будет выглядеть. CP определяет обновление CRL или требования размещения уведомления об аннулированном сертификате на сервере OCSP. Кроме того, CP может также определять требования физической безопасности, которым должен соответствовать CA.

Присвоение и регистрация Объектного Идентификатора (Object Identifier)

Когда CP уже сформулирована, ее следует разместить на сайте компании. Компания, составляющая CP, должна быть зарегистрирована через IANA (Internet Assigned Numbers Association), чтобы ее CP был присвоен Объектный идентификатор (Object Identifier, OID). OID представляет собой представление компании в численной форме. Этот OID следует поместить в сертификат, чтобы RP (лицо, получающее данный сертификат) могло найти и ознакомиться с CP сертификата на сайте идентифицируемой компании. Прочитав CP, RP самостоятельно решает, заслуживает ли данный сертификат доверия.

Написание Положения об использовании сертификата (Certificate Practice Statement)

Для успешной реализации CA, в зависимости от уровня необходимой авторизации, оператор CA должен либо написать специальное Положение об использовании сертификата (Certificate Practice Statement, CPS) либо составить общее CPS. CPS представляет собой документ, описывающий подробности реализации CP и объясняющий порядок соотнесения CA с требованиями CP. По правилам American Bar Association, идентификатор CPS (OID) также должен включаться в сертификат. Эта информация в дальнейшем позволит RP проверять квалификацию Certificate Authority.

Создание собственного CA

Если компания реализует собственный CA, она должна создать также и CP и CPS. Лучшим справочным материалом при написании CP и CPS является RFC 2527 (Internet X.509 Public Key Infrastructure Certificate Policy and Certification Practices Framework), увидевшая свет в марте 1999 года. Прежде, чем публиковать CP и CPS, необходимо также проконсультироваться с юристами компании. Тем не менее, не следует ждать от них особой помощи ни в вопросе создания CP, ни CPS - к сожалению, очень немногие корпоративные юристы способны разбираться в таких вещах.

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

Взаимная сертификация означает, что сертификат, выпущенный одной PKI, становится применим в другой PKI. И CP и CPS каждой из PKI будет проверен другой PKI с целью убедиться, что их сертификаты можно рассматривать как равнозначные относительно важных для них аспектов (не совсем верно было бы называть их полностью "равнозначными", так как юридически это означало бы и словесное совпадение). Взаимная сертификация представляет собой простое физическое действие: каждый CA выпускает для другого сертификат, содержащий Policy Mappings Extension (Расширенное отображение политики), закрепляющий вышеуказанное соглашение. Сложность состоит в согласовании соглашений CP и CPS между двумя PKI.

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

Отдельный Bridge CA обменивается взаимными сертификатами со всеми Root CA имеющихся PKI. Это уменьшает длину цепочки, которую необходимо пройти EE, чтобы провести аутентификацию сертификата, предъявленного ей извне ее PKI. Это основная причина реализации Bridged PKI, однако такая технология выгодна потому, что она упрощает аннулирование взаимной сертификации. Вместо размещения 12 сертификатов необходимо будет разместить только один - тот, что выпущен Bridge CA для взаимной сертификации. Итак, мы разобрались с основными понятиями технологии PKI. А теперь самое сложное…

Реализация PKI: заказывать или делать самим?

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

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