Читать онлайн «Инфраструктуры открытых ключей». Страница 50

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

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

Иногда можно избежать распространения сертификатов и списков САС с конфиденциальной информацией. В относительно простой иерархии для предотвращения нежелательного раскрытия информации о корпоративной инфраструктуре может использоваться дерево информации каталога Directory Information Tree (DIT) [127], организованное на основе информационной базы объектов организации и знаний об их иерархии. В некоторых случаях также можно указывать в поле сертификата Distinguished Name ( отличительное имя ) локально уникальный идентификатор, имеющий значение в иерархии определенного УЦ, который по существу является отдельной доверяющей стороной. Тогда отличительное имя теряет смысл для стороннего наблюдателя, который может перехватить сертификат.

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

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

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

Междоменная репликация означает копирование сертификатов и информации об аннулированных сертификатах из одного домена в другой и наоборот. Способность автоматически выполнять междоменную репликацию зависит от используемых протоколов. Если оба домена поддерживают сервисы каталога стандарта X.500, то репликация выполняется на базе существующих протоколов, в частности, протокола для создания "теневой" копии данных каталога Directory Information Shadowing Protocol (DISP) [37]. Для случая, когда единственным общим протоколом доступа двух доменов к данным друг друга является упрощенный протокол доступа к каталогу LDAP, пока не существует стандартного протокола репликации. Рабочая группа LDUP (LDAP Duplication/ Replication/ Update Protocol) организации инженерной поддержки Интернета IETF (Internet Engineering Task Force) в настоящее время работает над этой проблемой, и можно ожидать введения нового протокола репликации на базе LDAP [44]. Другой временной альтернативой может быть передача файлов на базе формата обмена данными LDAP (LDIF - LDAP Data Interchange Format) [161]. В любом случае должен быть защищен базовый сеанс копирования данных из одного корпоративного домена в другой.

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

Пограничный репозиторий может быть развернут для поддержки всей PKI или для отдельных подразделений или организаций внутри данной PKI. Иногда пограничный и внутренний репозитории связываются при помощи соответствующего механизма или протокола системы каталога X.500 Directory System Protocol (DSP). Спецификации упрощенного протокола доступа к репозиторию LDAP не поддерживают связывание явным образом.

Управление внешним доступом к пограничному репозиторию зависит от политики PKI и уровня конфиденциальности хранимой информации. В любом случае удаленные клиенты должны иметь возможность получать доступ к необходимым сертификатам и информации об аннулированных сертификатах без "блуждания" по корпоративной сети и, соответственно, без прямого доступа к конфиденциальной информации корпоративной базы данных. Рис. 12.1 иллюстрирует ряд возможных конфигураций сети, связанных с развертыванием междоменного репозитория [44].

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

Рис. 12.1.  Варианты развертывания междоменного репозитория

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