Однако функциональная совместимость является проблемой. Немногие программные продукты, реализующие работу удостоверяющих центров, имеют функции автоматического наполнения HTTP- репозитория сертификатами и списками САС.
Электронная почта
Документ RFC 822 задает формат другого широко распространенного протокола передачи данных: протокола электронной почты [130]. Почти каждая компания имеет серверы электронной почты. Практически каждая клиентская система поддерживает электронную почту. Клиент может запросить сертификат или список САС через субъект или тело почтового сообщения. Сертификаты и списки САС могут быть возвращены как вложения в ответе на почтовое сообщение типа MIME, определенном в документе RFC 2585. Подобное решение привлекает своей простотой, однако почтовый репозиторий не обладает необходимыми свойствами.
Местонахождение репозитория не является прозрачным, поскольку доверяющие стороны всегда будут запрашивать информацию от одних и тех же почтовых серверов, указанных в сертификатах. Это не способствует решению проблем доступности или производительности. Функциональная совместимость также является проблемой, так как протокол электронной почты не интегрирован в качестве поддерживающего протокола в клиентские приложения PKI.
Удостоверяющие центры могут наполнять почтовый репозиторий за два шага. Источник каждого запроса достаточно легко аутентифицировать. Если запросы к репозиторию передаются в виде подписанных цифровой подписью сообщений электронной почты (например, S/MIME), репозиторий может аутентифицировать и лицо, обращающееся с запросом. Аутентификация позволяет поддерживать бизнес-модель оплаты за обслуживание запросов.
Пока не существует улучшенного стандарта распространения сертификатов и списков САС по электронной почте. В отсутствие правил образования имен и утвержденного протокола электронная почта не может использоваться в качестве основного механизма распространения сертификатов и списков САС. Однако передача последних версий списков САС по электронной почте очень удобна для пользователей.
Поддержка системы доменных имен
Одной из наиболее удачных распределенных информационно-поисковых систем является система доменных имен (DNS) Интернета. Система DNS описывается в документах RFC 1034 [132] и RFC 1035 [133]. Документ RFC 1035 утверждает, что целью доменных имен является обеспечение такого механизма именования, чтобы имена могли использоваться разными хостами, локальными и глобальными сетями, семействами протоколов и организациями. Система DNS обеспечила реализацию этих целей, и исследователи постоянно ищут новые способы совершенствования ее возможностей.
Ведется много дискуссий о возможном использовании системы DNS для унификации многих разрозненных каталогов и разработке соответствующих протоколов доступа в помощь клиентам. Эта концепция требует новых типов данных, идентифицирующих репозиторий некоторого домена, а не предполагает использования системы DNS для транспортировки сертификатов и списков САС. Пусть, например, клиент обрабатывает сообщение электронной почты от домена alpha.com. Он должен создать запрос к системе DNS. Если бы в ответе указывался общий репозиторий для PKI компании "Альфа", это позволило бы упростить сертификаты, исключив из них указатели на местонахождение репозитория. Тогда можно было бы менять протоколы доступа к репозиторию PKI без повторного выпуска сертификатов. Эта идея пока не реализована, но организация IETF в качестве эксперимента начала процесс стандартизации данного подхода.
Рекомендации по выбору типа репозитория
Поскольку не существует универсального решения для любой ситуации, при развертывании PKI и выборе типа репозитория каждая организация должна ориентироваться на собственные потребности и возможности. Очевидно, что должно поддерживаться столько протоколов, сколько необходимо для обслуживания всех имеющихся клиентов и приложений, и использоваться столько репозиториев, сколько требуется для удовлетворения потребностей всех сообществ пользователей данного домена.
Пока наиболее практичным решением для организации репозитория PKI является каталог. Каталог X.500 с LDAP обеспечивает максимум масштабируемости и функциональной совместимости. Прозрачность местонахождения упрощает работу клиентов. В случае усложнения PKI и появления необходимости обмениваться кросс-сертификатами с другими PKI, которые поддерживают стандарт X.500, клиенты непрерывно будут иметь доступ ко всем необходимым сертификатам. Каталог X.500 поддерживает аутентифицируемый доступ, обеспечивая бизнес-модель возмещения затрат при обслуживании запросов доверяющих сторон к репозиторию. Но следует учитывать, что процесс аутентификации доступа к общедоступным данным снижает производительность системы. Небольшие изолированные PKI могут применять каталог LDAP v2. В настоящее время используются каталоги LDAP v3, предоставляющие более гибкие возможности для крупномасштабных PKI.
Если организация развертывает частную PKI, разумным решением может быть использование отдельно HTTP- или FTP- репозитория. Но пока большинство программных продуктов PKI не поддерживают доступ к корпоративным репозитория м по протоколам HTTP или FTP, функциональная совместимость с внешними пользователями будет ограничена. Эта проблема может быть решена путем организации пограничного каталога. Лучшая стратегия заключается в реализации частного каталога как начального шага в двухшаговом процессе публикации. Этот каталог может использоваться и как пограничный каталог для достижения функциональной совместимости с внешними PKI. Пограничный каталог - это наиболее простой механизм разделения корпоративной информации с внешним миром при защите необходимых ресурсов.
Наконец, можно дать две самых общих рекомендации относительно репозитория вне зависимости от поддерживаемых протоколов доступа к нему. Во-первых, организации не следует создавать отдельный репозиторий для поддержки PKI помимо уже имеющегося корпоративного репозитория, а во-вторых, не следует использовать мощные средства защиты репозитория, если в этом нет реальной необходимости, поскольку поддержка функционирования защищенной системы всегда более сложна.
Итак, мы проанализировали различные методы распространения сертификатов и информации об аннулированных сертификатах и варианты использования репозитория, обсудили ряд альтернатив развертывания, когда PKI-информация разделяется между двумя или более взаимодействующими доменами PKI. В связи с быстрым ростом количества пользователей PKI до десятков тысяч, сотен тысяч и даже миллионов существенно возрастает важность своевременного и надежного распространения PKI-информации. Это одно из наиболее фундаментальных требований успешного развертывания любой крупномасштабной PKI.
Лекция 13. Политики, регламент и процедуры PKI
Дается определение политики безопасности, рассматриваются способы реализации политики безопасности, приводится список основных требований к политике PKI, дается характеристика политике применения сертификатов и регламента удостоверяющего центра, обсуждаются отличия политики применения сертификатов, регламента и организационных процедур удостоверяющего центра, дается представление об идентификаторах объектов и краткой характеристике политики PKI, подробно рассматриваются способы отображения политики в сертификатах.
Политика безопасности и способы ее реализации
Политика - это набор установленных правил для управления определенными аспектами функционирования организации. Политика определяет, что должно быть сделано для обеспечения целей бизнеса, юридических требований или корпоративных норм организации. Политика безопасности описывает цели, ответственность и общие требования к защите определенных ресурсов (например, важных компьютерных систем или данных), но сама по себе не способна обеспечить выполнение требований организации. Политика безопасности должна быть реализована при помощи комплекса механизмов безопасности и процедур. Организация может выбрать самые разные инструментальные средства в качестве механизмов безопасности (замки, системы видео-наблюдения, межсетевые экраны и т.п.), но они только тогда гарантируют ожидаемый результат, когда правильно конфигурируются и поддерживаются. Процедуры являются, по существу, теми шагами, которые выполняют администраторы и пользователи системы в целях правильного функционирования механизмов безопасности. Процедуры зависят от того, какие механизмы используются, и определяют, как обеспечить требования, заданные политикой безопасности.
