PKI за семью печатями

Реализация PKI требует принятия строгих мер защиты для обеспечения ее целостности и полезности. Тому, как этого добиться, и посвящена данная статья.

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

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

В данной статье описываются связанные с планированием и реализацией PKI вопросы защиты, в том числе идентификационные сертификаты, сертификационные центры (Certificate Authority, CA), регистрационные центры (Registration Authority, RA) и каталоги. Кроме того, в ней рассматривается, как эти системы влияют на общий баланс защиты сети и как свести к минимуму ошибки при такой крупномасштабной реализации за счет тщательного планирования и следования ряду рекомендаций. Здесь мы не касаемся вопроса пригодности PKI в качестве потенциального решения любой данной проблемы.

ПОВТОРЕНИЕ ОСНОВ

PKI — это общий термин, относящийся к оборудованию, программному обеспечению и правилам, необходимым для идентификации анонимного субъекта. Мозаику PKI составляют четыре элемента: сертификаты, представляющие собой идентификационные маркеры; CA, принимающие собой окончательное решение об идентификации субъекта; RA, получающие и обрабатывающие запросы о подписи сертификатов со стороны конечных пользователей, и, наконец, каталоги LDAP, содержащие общедоступную информацию о сертификатах. Ниже мы рассмотрим каждый из этих элементов по очереди.

Сертификаты X.509v3. Сертификат — это основное средство обращения экономики PKI. В соответствии с форматом, определяемым в стандарте X.509 (теперь в его третьей версии), сертификат является криптографическим свидетельством того, что открытый ключ, который он содержит, действительно принадлежит тому, кто указан в том же сертификате. Эта связь удостоверяется сертификационным центром, где перед выдачей конечному пользователю сертификат подписывается личным ключом центра.

Поле имени субъекта (Subject Name) сертификата X.509v3 должно быть стандартизовано, чтобы оно имело одинаковый вид в рамках предприятия. Это поле содержит как имена конечных пользователей, так и имена машин (хостов). Для хранения имен субъектов формат X.509 использует исходную спецификацию X.500 на «отличительное имя».

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

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

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

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

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

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

Для ликвидации последствий компрометации ключа пару из открытого и личного ключей CA придется генерировать заново. Затем его главный сертификат (root certificate) необходимо будет заново разослать. Кроме того, все выданные CA сертификаты придется немедленно аннулировать (подробнее об этом несколько ниже). Это весьма дорогостоящая и длительная процедура, поэтому последствия компрометации могут быть самые плачевные.

Адекватная политика защиты в отношении системы, где находится CA, должна предусматривать как физические, так и системные меры обеспечения безопасности.

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

При необходимости получить подпись CA оператор может представить нуждающийся в подписи сертификат с помощью вторичного устройства хранения (диска или ленты) и записать результирующий подписанный сертификат на тот же самый носитель.

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

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

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

Регистрационный центр. В отличие от системы, где располагается CA, пользователи сети должны иметь доступ к RA, чтобы они могли запросить подписанные сертификаты для надежной идентификации своей личности при взаимодействии с коллегами по сети. Такие запросы на получение сертификатов могут быть переданы разными способами — в виде PEM-форматированного текстового блока или запроса на подпись сертификата в формате PKCS#10.

В рекомендуемой архитектуре CA/RA регистрационный сервер принимает и кэширует запросы на подпись сертификата с определенным сроком действия, после чего оператор загружает запросы (вместе с другой относящейся к ним информацией) и передает их с помощью вторичного носителя в CA. Результирующие подписанные сертификаты можно затем вручную загрузить в «исходящую» область RA, откуда запросившие сертификаты пользователи могут их забрать.

Даже при отсутствии требования соблюдения конфиденциальности RA должны быть устойчивы к атакам по типу «отказ в обслуживании», так как они могут повлиять на их доступность, особенно в случае электронной коммерции. В тех случаях, когда запросы на получение сертификата могут подаваться через браузер Web, меры защиты необходимо предусмотреть как для целевой аппаратной/программной платформы, так и для сервера Web, где обычно выполняется RA.

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

Серверы каталогов LDAP. Появление PKI привело к необходимости обеспечить оперативный доступ к большому числу сертификатов, необходимых для идентификации других лиц. Благодаря эффективному масштабируемому интерфейсу LDAP обеспечивает стандартный формат для обращения сетевых объектов к каталогу сертификатов. Типичная реализация PKI опирается на распределенные по всей сети серверы LDAP, где находятся открытые ключи и сертификаты X.509 для всех объектов на предприятии.

Для данных на сервере каталогов LDAP конфиденциальность обычно не требуется (все находящиеся на нем данные общедоступны по своей природе), однако для них необходимо обеспечить доступность и целостность.

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

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

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

ХРАНЕНИЕ КЛЮЧЕЙ И ОТЗЫВ СЕРТИФИКАТОВ

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

При выборе последнего метода особую заботу следует проявить к защите содержимого секретных ключей при их передаче из помещения конечного пользователя в CA/RA. Кроме того, конечные пользователи должны проинформировать администраторов защиты о парольных фразах, которые они выбрали для защиты ключей. В качестве варианта конечным пользователям может быть рекомендовано использовать при создании ключа «типовую» парольную фразу, которую они могут изменить после сохранения ключа на депоненте.

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

Вне зависимости от депонирования ключей даже самая элементарная реализация PKI должна предусматривать политику (и соответствующий набор механизмов) в отношении отзыва сертификатов. Это необходимо на случай, если главный секретный ключ CA окажется скомпрометирован или если субъект сертификата перестанет заслуживать доверия в контексте предприятия (например, при увольнении сотрудника до истечения срока действия его сертификата). Несмотря на отсутствие единого мнения по поводу их полезности и масштабируемости, списки аннулированных сертификатов (Certificate Revocation List, CRL) по-прежнему остаются наиболее широко используемым инструментом обеспечения своевременного отзыва сертификатов открытых ключей.

Такие списки периодически публикуются CA и состоят из цепочки всех идентификаторов скомпрометированных сертификатов, а также даты выпуска CRL. Это полезное содержимое подписывается с использованием секретного ключа CA и сообщается всем участникам PKI посредством общедоступного сервера каталога LDAP.

Главной слабостью CRL с точки зрения защиты является сервер каталога LDAP, где они находятся. Блокировав сервер CRL посредством атаки DoS, злоумышленник может добиться того, что скомпрометированный сертификат будет по-прежнему приниматься приложением PKI. Однако этот риск можно свести к минимуму посредством модификации приложений таким образом, что сертификаты не будут идентифицироваться при отсутствии «свежего» списка CRL. К серверам CRL необходимо применять те же меры предосторожности, что и к серверам сертификатов LDAP.

ПЛАН ДЕЙСТВИЙ ПО РАЗВЕРТЫВАНИЮ ЗАЩИЩЕННОЙ PKI

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

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

Во-вторых, это создание иерархии доверительных отношений. Будете вы использовать один централизованный центр по выдаче сертификатов (я бы не советовал этого) или же делегируете некоторые из прав сертификационным центрам меньшего размера? Намерены ли вы реализовать CA второго уровня в соответствии с корпоративной иерархией или географическим местонахождением? (Более подробно смотрите врезку «Создание иерархии сертификационных центров».)

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

В-четвертых, это составление политики распространения CRL. Все ли CRL будут храниться централизованно или же клиенты смогут получать их с распределенных серверов LDAP? Как часто будут публиковаться CRL? Все ли приложения должны будут их использовать?

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

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

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

СОСТАВЛЕНИЕ ГОЛОВОЛОМКИ

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

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

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

Создание иерархии сертификационных центров

Сертификация модуля шифрования

Стандарты шифрования Американского национального института стандартов и технологий (NIST)

Ресурсы Internet