Балансировка нагрузки и отказоустойчивость при проверке статусов сертификатов в ИОК

ЭЦП

В современные информационные системы все шире внедряется технология электронной цифровой подписи (ЭЦП) на основе асимметричных криптографических алгоритмов. ЭЦП используется для обеспечения юридической значимости электронных документов, аутентификации, контроля целостности и т. д. Применение цифровой подписи подразумевает наличие соответствующей инфраструктуры, которая называется инфраструктурой открытых ключей (ИОК; Public Key Infrastructure, PKI). Для удостоверения факта принадлежности ключевой пары определенному субъекту (объекту) в ИОК служит сертификат открытого ключа - подписанный ЭЦП электронный документ, содержащий информацию о владельце ключевой пары и открытый ключ. В ИОК подпись сертификатов осуществляется доверенной третьей стороной - удостоверяющим центром (УЦ). Доверие к ключевой паре УЦ также основывается на его сертификате, который может быть подписан либо вышестоящим УЦ, либо самим УЦ*1.

_____

*1 Бернет С., Пейн С. Криптография. Официальное руководство RSA Security. М.: Бином-Пресс, 2002

Две точки распространения СОС в сертификате 

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

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

Ниже представлены общие соображения, которыми надо руководствоваться при решении проблем балансировки нагрузки и отказоустойчивости, даны рекомендации по организации безотказного обслуживания, а также приведены сравнительные характеристики методов распространения информации о статусах сертификатов применительно к этим проблемам. В работе рассмотрены наиболее распространенные методы предоставления информации об отзыве: списки отзыва сертификатов (СОС; Certificate Revocation List, CRL) и OCSP-серверы (Online Certificate Status Protocol - протокол определения статуса сертификата в режиме реального времени).

Списки отзыва сертификатов

Списки отзыва сертификатов являются самым распространенным методом предоставления клиентам информации о статусах сертификатов. Формат и применение СОС описаны в рекомендациях X.509*1 и RFC 3280 (www.ietf.org/rfc/rfc3280.txt), что обуславливает поддержку СОС во всех продуктах, работающих с сертификатами открытых ключей.

_____

*1 ITU-T Recommendation X.509 "Information technology - Open systems interconnection - The Directpry: Public-rey and attribute certificate frameworks". ITU-T, March 2000.

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

В СОС также обязательно указывается время его издания (thisUpdate) и, опционально, время, когда будет доступна более свежая информация (nextUpdate). Для указания адреса, по которому доступен СОС, в сертификаты включается дополнение CDP (CRL Distribution Point - точка распространения СОС). Таких адресов может быть несколько.

Доступ по протоколу LDAP

LDAP (Lightweight Directory Access - облегченный протокол доступа к службе каталогов) позволяет получать СОС из службы каталогов (директорий). Данный способ удобен в тех случаях, когда в информационной системе с ИОК уже применяется служба каталогов.

Из распространенных продуктов для этих целей можно использовать Active Directory на базе контроллера домена Microsoft Windows версии 2000 или 2003 или Active Directory Application Mode (ADAM) - бесплатный продукт, работающий под управлением Windows XP/2003.

Необходимо отметить, что не все клиенты ИОК из доступных на рынке поддерживают обращения за СОС по протоколу LDAP. Если в системе задействованы только программы на базе Microsoft CryptoAPI, то можно обратиться к LDAP-каталогам, в противном случае необходимо убедиться в наличии такой возможности в используемых продуктах. Microsoft, несмотря на реализованную поддержку протокола LDAP, рекомендует HTTP CDP для не-Windows-клиентов.

Доступ по протоколу HTTP

Распространение СОС по протоколу HTTP через веб-серверы имеет следующие преимущества по сравнению с LDAP:

- простота развертывания и администрирования;

- высокая вероятность поддержки во всех приложениях, проверяющих статус сертификатов;

- меньшее время выдачи ответа, поскольку веб-сервер при должной настройке просто читает файл СОС, лежащий на диске, а LDAP-сервер производит поиск СОС в своей базе данных*1;

_____

*1При выдаче ответа веб-сервером Microsoft IIS путем чтения файла с диска (в отличие от выполнения сценария) получен выигрыш по времени в два раза по сравнению с запросом свойства объекта из Active Directory

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

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

Балансировка нагрузки

Распространение СОС в территориально распределенных системах или в системах с большим количеством пользователей вводит дополнительные требования.

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

Балансировка нагрузки при помощи дублирования серверов подразумевает репликацию распространяемых данных (в нашем случае - СОС) от источника (УЦ) на все серверы. Разумеется, процедура репликации вносит задержку в распространение СОС. При этом возможна ситуация, когда разные клиенты в один и тот же момент обращаются за СОС и получают разные списки. Необходимо учитывать данную ситуацию и величину задержки при проектировании ИОК и соответственно корректировать расписание публикации СОС и требования к процедуре их репликации.

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

Репликация СОС по нескольким веб-серверам может потребовать дополнительных усилий, но также может быть более гибко настроена под нужды системы. Подобное распространение СОС поддерживается в продукте удостоверяющего центра "КриптоПро УЦ".

Отказоустойчивость

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

Далее описан способ организации доступа к СОС для территориально распределенной системы с большим количеством пользователей.

Поскольку клиенты определяют местоположение СОС по CDP в сертификате, предлагается включать в сертификаты две CDP в следующем порядке (тип CDP - LDAP или HTTP - определяется исходя из нужд системы):

- локальный адрес;

- глобальный адрес.

Под локальными и глобальными адресами здесь подразумевается использование DNS-имен, которые будут разрешаться в IP-адреса следующим образом. В локальном адресе будет содержаться имя сервера, подобное local.cdp.myis.ru, а в глобальном - global.cdp.myis.ru. При этом DNS-серверы распределенной системы настраиваются так, что имя glo-bal.cdp.myis.ru имеет одинаковые IP-адреса для всех клиентов и ссылается на центральный сервер распространения СОС - максимально надежный, а имя local.cdp.myis.ru имеет разные IP-адреса для разных клиентов, тем самым обеспечивая обращение клиента за СОС на ближайший сервер (см. рисунок).

Подобную настройку DNS можно осуществить, например, одним из следующих способов:

- создать зону cdp.myis.ru на всех DNS-серверах системы как первичную и настроить два указанных имени на каждом сервере: local.cdp.myis.ru - на ближайший(е) сервер(ы), global.cdp.myis.ru - на центральный(е) сервер(ы). В этом случае управление адресами будет распределенным;

- сопоставить два указанных имени с множеством всех адресов серверов распространения СОС: global.cdp.myis.ru - один или несколько центральных серверов, local.cdp.myis.ru - все региональные серверы. Такую настройку необходимо осуществить на первичном DNS-сервере системы, с которого адреса будут автоматически получены всеми вторичными серверами. При запросе адреса сервера local.cdp.myis.ru служба DNS в ответ упорядочит все известные ей адреса по принципу близости к подсети клиента, и в результате первый адрес будет указывать на ближайший сервер. Возможность автоматического упорядочивания на основе адреса подсети клиента присутствует в наиболее распространенных продуктах - службе DNS в ОС Microsoft и BIND в ОС UNIX. В этом случае управление адресами будет централизованным.

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

В некоторых особых случаях имеет смысл использовать одну HTTP-точку и одну LDAP-точку. Необязательно также устанавливать вторую точку пары в условном центре системы с одинаковым для всех клиентов IP-адресом. Это может быть такая же, как и первая точка с разными IP-адресами для разных клиентов. Конкретный набор CDP и стратегия резервирования определяются исходя из нужд конкретной системы.

Балансировку нагрузки при обращении клиентов по этим адресам можно осуществлять любыми подходящими методами.

Управление размером СОС

Одним из методов балансировки нагрузки является управление размером СОС. Проблема размера СОС может стать актуальной в системе с большим числом пользователей. В СОС присутствует информация обо всех отозванных или приостановленных сертификатах из числа действующих в данный момент. Из расчета 16-байтного серийного номера на каждый сертификат будет приходиться в среднем 35 байт информации. При использовании дополнений в записи СОС, например причины отзыва, даты предполагаемой компрометации ключа и т. п., объем информации, очевидно, еще увеличится. Предполагая, что каждый 20-й сертификат отзывается до окончания срока его действия, размер СОС достигнет 100 Кб в системе уже с 60 000 пользователей. На момент написания статьи СОС одного из УЦ VeriSign достигал объема 700 000 байт(!) при 22 000 отозванных сертификатах.

Первый способ уменьшения трафика - использование так называемых разностных СОС (Delta CRL). Выигрыш получается из-за того, что между выпусками полного СОС, которые настраиваются с большими промежутками, УЦ издает разностные СОС, содержащие только сертификаты, отозванные с момента выпуска последнего полного СОС. Клиенты при этом редко откачивают с УЦ и кэшируют у себя полный СОС и часто обращаются только за маленькими по объему разностными СОС.

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

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

Протокол OCSP

Протокол OCSP (Online Certificate Status Protocol) описан в RFC 2560 (www.ietf.org/rfc/rfc2560.txt). Хотя этот документ опубликован в 1999 г., получение информации об отзыве по данному протоколу менее распространено в доступных на рынке продуктах.

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

Адрес для доступа к серверам OCSP указывается в дополнении AIA (Authority Information Access - точка доступа к информации УЦ) сертификатов. Таких адресов может быть несколько. К количеству и последовательности их указания применимы те же рассуждения, что и к адресам CDP, за исключением того, что для совместимости с доступными продуктами здесь следует указывать только HTTP-адреса.

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

Классический протокол OCSP имеет следующие преимущества по сравнению с СОС:

- меньший объем пересылаемой клиенту информации, так как размер ответа фиксирован и составляет порядка 300 байт при минимальном наполнении OCSP-ответа (при вложении, например, сертификата, на котором ответ подписан, объем ответа увеличится на размер сертификата - на 1-2 Кб);

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

Недостатки протокола по сравнению с СОС:

- по каждому запросу статуса необходимо вычисление ЭЦП, а это процедура не быстрая, накладывающая ограничения на используемые средства криптографической защиты информации (СКЗИ). Если для подписи сертификатов и СОС возможно использовать медленное, но более защищенное аппаратное СКЗИ, то для OCSP-сервера это скорее всего неприемлемо;

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

Протокол OCSP с кэшированием имеет следующие преимущества по сравнению с классическим протоколом:

- не надо вычислять ЭЦП при каждом ответе, что ускоряет поиск по базе данных;

- нет необходимости управления ключами и сертификатами множества серверов.

Для работы сервера по данному протоколу потребуется передать ему подписанные OCSP-ответы для всех выпущенных УЦ сертификатов. Может понадобиться и распространение OCSP-ответов для вновь выпущенных сертификатов.

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

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

Протокол с кэшированием имеет следующие недостатки по сравнению с классическим:

- отсутствие поддержки поля nonce, что делает возможными атаки типа "повтор сообщения", которые исключены в случае классического протокола OCSP;

- отсутствие возможности запроса статуса нескольких сертификатов с помощью одного обращения. Этим и предыдущим пунктом определяются различия протокола OCSP с кэшированием RFC 2560;

- необходимость передачи кэширующим серверам сравнительно большого объема информации. Например, для 60 000 сертификатов объем сгенерированных OCSP-ответов будет порядка 18 Мб, тогда как СОС, в котором присутствует каждый 20-й сертификат, занимает около 100 Кб.

Следует отметить, что СОС также не защищены от подобных атак. Успешное использование атак повтора ограничено временами thisUpdate - nextUpdate СОС или OCSP-ответа, что позволяет управлять уровнем риска атаки.

Подробнее о протоколе OCSP с кэшированием см. работу Deacon A., Hurst R., Lightweight OCSP Profile for High Volume Environments. - IETF, Internet Draft, November 2003 и www.corestreet.com/whitepapers/w02_07v2_distributed_ocsp.pdf.

Актуальность информации в OCSP-ответе

OCSP-сервер, работающий по СОС, создает ответы, актуальность которых соответствует СОС. Чтобы клиенты могли получать наиболее актуальную информацию, необходимо дополнительное распространение информации от УЦ к OCSP-серверам. Это можно обеспечить, настроив УЦ на рассылку сообщений при изменении статуса сертификата в режиме реального времени. В случае генерирующих OCSP-серверов сообщением может служить анонс отзыва, описанный в RFC 2510 (www.ietf.org/rfc/rfc2510.txt), для кэширующих серверов это должен быть непосредственно OCSP-ответ. При рассылке подобных сообщений также возможна гибридная схема с генерирующими и кэширующими серверами.

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

Заключение

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

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

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

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

     С автором можно связаться по адресу: spv@cryptopro.ru.