Книга: Инфраструктуры открытых ключей

Архитектура корпоративной PKI

В корпоративной PKI отношения доверия устанавливаются между удостоверяющими центрами одной и той же организации. Организация может быть компанией, государственным предприятием, федеральным агентством или сообществом пользователей. В примерах этого раздела предполагается, что пользователи А, B, C и D работают в одной большой компании. Компания слишком велика и сложна по структуре, чтобы иметь единственный УЦ, поэтому каждое подразделение получает сертификаты от своего УЦ.

Иерархическая PKI

Традиционная архитектура PKI - иерархическая, где многие удостоверяющие центры обеспечивают PKI-сервисы и связаны отношениями подчиненности. В этой архитектуре все пользователи доверяют одному и тому же центральному корневому, или головному, УЦ. Все удостоверяющие центры, за исключением головного, подчиняются одному вышестоящему УЦ. Удостоверяющие центры могут иметь подчиненные удостоверяющие центры или выпускать сертификаты непосредственно для пользователей. Каждое отношение доверия УЦ представлено отдельным сертификатом. Издателем сертификата является вышестоящий УЦ, субъектом - подчиненный УЦ >[10].

Включение в инфраструктуру нового УЦ происходит тогда, когда один из существующих удостоверяющих центров выпускает для него сертификат. Рис. 10.4 иллюстрирует иерархическую PKI и три способа добавления новых удостоверяющих центров >[70]. Иерархическая PKI изображена на рис. 10.4 а). На рис. 10.4 в) показано, как создается новый УЦ₃ непосредственно под головным УЦ существующей PKI, на рис. 10.4 c) новый УЦ становится подчиненным УЦ₂. Таким же способом могут быть объединены две иерархические PKI. На рис. 10.4 d) к существующей инфраструктуре добавляется целая иерархическая PKI. Добавляемые компоненты на рисунках обведены пунктирными линиями.

Рис. 10.4.  Расширение иерархической PKI

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

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

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

Построение пути в иерархической PKI

В иерархиях пути сертификации начинаются в корне (с головного УЦ) и заканчиваются конечными субъектами, однако строятся они в обратном направлении >[60]. Построение начинается с сертификата конечного субъекта. В сертификате указаны его издатель (УЦ) и дополнение Authority Key Identifier (идентификатор ключа УЦ). Эти атрибуты позволяют найти сертификат УЦ. Имя издателя используется для определения местонахождения сертификатов УЦ в репозитории. Репозиторий может содержать несколько сертификатов, выпущенных для УЦ. Идентификатор ключа УЦ в сертификате конечного субъекта сравнивается с идентификатором ключа субъекта только в одном сертификате - искомом сертификате УЦ. Этот процесс повторяется до тех пор, пока не будет найден сертификат, изданный головным УЦ, пунктом доверия иерархии.

На рис. 10.5 показаны пути сертификации для пользователей А, В, С и D в иерархической PKI. Каждый конечный субъект имеет единственный путь сертификации. Некоторые пути сертификации длиннее прочих, но все пути начинаются в корне иерархии. Запись [(ГУЦ -> УЦ₃); (УЦ₃ -> D)] означает, что путь от головного УЦ (ГУЦ) до пользователя D состоит из двух сертификатов.

Рис. 10.5.  Пути сертификации в иерархической PKI

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

Сетевая PKI

Сетевая архитектура PKI является альтернативой иерархической архитектуры >[10]. Сетевая PKI строится как сеть доверия, многочисленные удостоверяющие центры которой предоставляют PKI-сервисы и связаны одноранговыми, то есть равноправными, отношениями. Каждый пользователь доверяет одному УЦ, причем только тому, который издал его сертификаты. Удостоверяющие центры выпускают сертификаты друг для друга; пара сертификатов описывает двусторонние отношения доверия. В сетевую PKI легко добавляется новый УЦ, для этого ему нужно обменяться сертификатами, по крайней мере, с одним УЦ, который уже входит в сеть. Однако строить путь сертификации в сетевой PKI намного труднее, чем в иерархической инфраструктуре, где построениепути от сертификата пользователя до пункта доверия строго определено. Построитьпуть сертификации в сети достаточно сложно, поскольку этот процесс не детерминирован и имеются многочисленные варианты формирования цепи сертификатов. Одни из них приводят к построению правильного пути, другие - заводят в тупик. Длина пути может быть больше, чем в иерархической PKI, и даже может достигать общего числа удостоверяющих центров инфраструктуры. Более того, в сети можно построить бесконечную цепь сертификатов.

Рис. 10.6.  Пример сетевой PKI и построенных путей сертификации

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

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

Пример 10.3. На рис. 10.6 удостоверяющие центры объединены в сетевую PKI. Пользователи А и В доверяют УЦ₁. Пользователь С доверяет УЦ₂, а пользователь D - УЦ₃. Пользователю А гораздо труднее найти и проанализировать путь сертификации до пользователя С, чем в иерархической PKI. В том случае, если путь строится от УЦ₁ к УЦ₂, то он содержит два сертификата, а если путь к УЦ₂ проходит через УЦ₃, то - три сертификата. Пытаясь обнаружить один из нескольких правильных путей, пользователь может построить пути, которые ведут в тупик (например, путь через УЦ₄ ). Обработка большего количества сертификатов более сложна, поскольку сопровождается анализом ограничений, включаемых в дополнения сертификатов.

Построение пути в сетевой PKI

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

В сетевой архитектуре сертификаты конечных субъектов выпускаются непосредственно их пунктами доверия. Субъект, строящий путь, доверяет своему УЦ, который может не совпадать с пунктом доверия того конечного субъекта, к которому строится путь. Более того, для этого УЦ могут быть выпущены сертификаты другими удостоверяющими центрами из разных сегментов сети. По этой причине построение пути начинается в пункте доверия и продолжается в направлении издателя сертификата конечного субъекта. Идентификатор ключа УЦ в сертификате сравнивается с идентификатором ключа субъекта сертификатов удостоверяющих центров, включая сертификат искомого УЦ. Так как дополнения Authority Key Identifier (идентификатор ключа УЦ) недостаточно для построения пути, следует использовать другие атрибуты как эвристические. Это могут быть имена или любые другие атрибуты, помогающие выбрать, с какого из возможных сертификатов начинать построение пути. Если выбранный сертификат не ведет к завершенному пути сертификации, то просто пробуют следующий за ним сертификат и т.д. >[84].

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

На рис.10.6 показаны пути сертификации, которые можно построить от пользователя А к пользователям B, C и D. Для пользователей C и D показан не один путь. Каждый путь является валидным, но некоторые пути длиннее других. Нахождение наиболее короткого пути не требуется, решение этой задачи значительно усложняет процесс. Обычно используется первый найденный валидный путь. С иллюстративной целью третий путь сертификации для пользователя D имеет петлю.

Оглавление книги