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

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

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

Архитектура мостового УЦ разрабатывалась для преодоления недостатков архитектуры расширенного списка доверия и корпоративных 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.

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