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

Гибридная архитектура PKI

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

Пример 10.4. Рассмотрим сценарий, проиллюстрированный рис. 10.7 >[70]. Три компании сотрудничают друг с другом, но используют корпоративные PKI разных типов. Пользователи А и В получили свои сертификаты от головного УЦ компании "Альфа". Пользователь С получил свой сертификат от УЦ подразделения 1 в иерархической PKI компании "Бета". Пользователь D получил сертификат от УЦ подразделения 3 в сетевой PKI компании "Гамма". Пользователь А может использовать один из трех вариантов гибридной архитектуры PKI для установления защищенных коммуникаций с пользователями C и D.

Рис. 10.7.  Три корпоративные PKI

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

Архитектура расширенного списка доверия

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

Пример 10.5. Чтобы защищенно связываться с пользователями B, C и D, пользователь А должен включить в свой расширенный список доверия три удостоверяющих центра: по одному УЦ от каждой доверенной PKI (см. рис. 10.7). Пользователь А доверяет своему собственному УЦ "Альфа", головному УЦ иерархической PKI компании "Бета" и одному УЦ в сетевой PKI компании "Гамма". Внутри каждой корпоративной PKI удостоверяющие центры могут быть связаны одноранговыми или иерархическими связями. Пользователь А может легко добавить новый УЦ или целую корпоративную PKI в свой список доверия. Сложность сертификатов зависит от связей в каждой корпоративной PKI.

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

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

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

Построение пути для расширенного списка доверия

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

Часто используется достаточно простой метод построенияпути сертификации в иерархической PKI >[84]. Если путь сертификации ведет к одному из доверенных пунктов, то считается, что построенвалидный путь ; если нет, то проверяется, был ли выпущен верхний сертификат данного пути сертификации любым пунктом доверия. Если это так, то этот сертификат завершает путь ; если нет, то делается попытка построить путь от каждого пункта доверия к верхнему сертификату данного пути сертификации. Для повышения эффективности построения пути используется кэширование: в кэш-памяти компьютера сохраняются все возможные пути сертификации, каждый из которых помечается признаком качества. Простые иерархические пути считаются более качественными, чем сложные, в итоге выбираются пути с признаком более высокого качества, то есть наиболее короткие. Этот метод можно использовать и в сложных топологиях.

Кросс-сертифицированные корпоративные PKI

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

Рис. 10.8.  Кросс-сертифицированные корпоративные PKI и пути сертификации пользователя А

Пример 10.6. На рис. 10.8 УЦ пользователя А кросс-сертифицирован с головным УЦ иерархической PKI компании "Бета" и УЦ подразделения 2 в сетевой PKI компании "Гамма". Кроме того, удостоверяющие центры компаний "Бета" и "Гамма" кросс-сертифицированы друг с другом. Каждый пользователь поддерживает один пункт доверия. Пользователи A, B и D доверяют удостоверяющим центрам, которые выпустили их сертификаты, а пользователь С доверяет своему головному УЦ. Межкорпоративные отношения являются одноранговыми, а внутри корпоративных инфраструктур установлены или одноранговые, или иерархические связи. Имея свой список доверия, пользователь А не может добавлять в него новый УЦ внешней PKI по своему усмотрению, а должен полагаться на действия администратора своего пункта доверия. А дминистраторы УЦ обычно имеют более высокую квалификацию, чем пользователи, и способны определить надежность УЦ или PKI. Прежде чем устанавливать отношения кросс-сертификации, администраторы УЦ анализируют политику и практику применения сертификатов другого УЦ. После кросс-сертификации удостоверяющих центров пользователь В получает возможность проверять валидность сертификатов пользователей С и D из других PKI. В соответствии с принципами архитектуры расширенного списка доверия пользователям необходимо обновлять свои собственные списки доверия.

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

Построение пути для кросс-сертифицированных PKI

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

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

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

Архитектура кросс-сертифицированных PKI - подходящее решение в том случае, когда отношения доверия устанавливаются между несколькими корпоративными PKI (их не должно быть много). Рис. 10.8 показывает, что для установления отношений, описанных в примере, потребовались три одноранговые связи и шесть сертификатов удостоверяющих центров. С увеличением числа корпоративных PKI количество связей и сертификатов быстро растет. Кросс-сертификация n-корпоративных PKI требует (n² - n)/2 - одноранговых связей и (n² - n) - сертификатов >[70].

Рис. 10.9.  Восемь кросс-сертифицированных PKI

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

Архитектура мостового УЦ

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

В отличие от сетевого центра, мостовой УЦ не выпускает сертификаты непосредственно для пользователей, а, в отличие от головного УЦ, в иерархии мостовой УЦ не является пунктом доверия. Все пользователи PKI рассматривают мостовой УЦ в качестве посредника. Мостовой УЦ устанавливает одноранговые отношения с разными корпоративными PKI. Эти отношения принимают вид моста доверия, который связывает пользователей разных PKI >[10]. Если домен доверия реализован как иерархическая PKI, мостовой УЦ устанавливает связь с головным УЦ иерархии. Если домен реализован как сетевая PKI, мостовой УЦ устанавливает связь только с одним из удостоверяющих центров сети. Удостоверяющий центр, который вступает в отношения с мостовым УЦ, называется главным УЦ .

Пример 10.7. На рис. 10.10 мостовой УЦ связан с тремя корпоративными PKI. Первая PKI - это УЦ пользователей А и В, вторая - иерархическая PKI пользователя С, и третья - сетевая PKI пользователя D. Никто из пользователей не доверяет непосредственно мостовому УЦ. Пользователи А и В доверяют УЦ "Альфа", который является издателем их сертификатов, они доверяют мостовому УЦ постольку, поскольку их собственный УЦ выпустил для него сертификат. Пункт доверия пользователя С - головной УЦ в его иерархии; пользователь С доверяет мостовому УЦ косвенно, потому что данный головной УЦ выпустил для того сертификат. Пользователь D доверяет издателю своего сертификата - УЦ₃ компании "Гамма" и косвенно доверяет мостовому УЦ, потому что существует правильный путь сертификации от УЦ₃ до мостового УЦ. Пользователи А и В могут использовать мост доверия для установления отношений с пользователями С и D.

Рис. 10.10.  Связывание трех корпоративных PKI при помощи мостового УЦ и построение путей сертификации

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

В связанные мостом инфраструктуры легко добавляются новые удостоверяющие центры или даже целые корпоративные PKI >[100]. Изменения остаются прозрачными для пользователей, пока они не касаются пунктов доверия. По мере роста PKI число отношений доверия, которые должны быть установлены, начинает превышать разумное и поддающееся управлению. На рис. 10.10 для трех корпоративных PKI были установлены три отношения доверия, как и в примере кросс-сертификации (рис. 10.8). Рис. 10.11 иллюстрирует связывание восьми корпоративных PKI при помощи мостового УЦ. Это требует установления восьми отношений доверия, а не двадцати восьми, как требовалось в варианте кросс-сертификации (рис. 10.8).

Рис. 10.11.  Связывание восьми корпоративных PKI при помощи мостового УЦ

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

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

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

Мостовой УЦ имеет ряд преимуществ по сравнению с кросс-сертифицированными PKI. Разные пользователи по-прежнему строят разные пути сертификации для одного и того же сертификата конечного субъекта, и путь сертификации начинается с пункта доверия пользователя, который желает построитьпуть до данного сертификата. Однако существует только один кросс-сертификат, связывающий данную PKI со всеми сторонними PKI. Это существенно упрощает построениепути сертификации. На рис. 10.10 показаны пути сертификации, которые связывают пользователя А и пользователей B, C и D. Пользователь D может построить не один путь, так как является участником сетевой PKI.

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

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