Архитектура корпоративной PKI
В корпоративной PKI отношения доверия устанавливаются между удостоверяющими центрами одной и той же организации. Организация может быть компанией, государственным предприятием, федеральным агентством или сообществом пользователей. В примерах этого раздела предполагается, что пользователи А, B, C и D работают в одной большой компании. Компания слишком велика и сложна по структуре, чтобы иметь единственный УЦ, поэтому каждое подразделение получает сертификаты от своего УЦ.
Иерархическая PKI
Традиционная архитектура PKI - иерархическая, где многие удостоверяющие центры обеспечивают PKI-сервисы и связаны отношениями подчиненности. В этой архитектуре все пользователи доверяют одному и тому же центральному корневому, или головному, УЦ. Все удостоверяющие центры, за исключением головного, подчиняются одному вышестоящему УЦ. Удостоверяющие центры могут иметь подчиненные удостоверяющие центры или выпускать сертификаты непосредственно для пользователей. Каждое отношение доверия УЦ представлено отдельным сертификатом. Издателем сертификата является вышестоящий УЦ, субъектом - подчиненный УЦ [10].
Включение в инфраструктуру нового УЦ происходит тогда, когда один из существующих удостоверяющих центров выпускает для него сертификат. Рис. 10.4 иллюстрирует иерархическую PKI и три способа добавления новых удостоверяющих центров [70]. Иерархическая PKI изображена на рис. 10.4 а). На рис. 10.4 в) показано, как создается новый УЦ3 непосредственно под головным УЦ существующей PKI, на рис. 10.4 c) новый УЦ становится подчиненным УЦ2. Таким же способом могут быть объединены две иерархические PKI. На рис. 10.4 d) к существующей инфраструктуре добавляется целая иерархическая PKI. Добавляемые компоненты на рисунках обведены пунктирными линиями.
Рис. 10.4. Расширение иерархической PKI
В иерархии легко строить пути сертификации, так как каждый УЦ подчиняется только одному вышестоящему УЦ. Очевидно, что существует простой и вполне определенный путь от сертификата пользователя к единственному пункту доверия в корне иерархии. Пути сертификации относительно коротки. Самый длинный путь равен числу уровней иерархии и складывается из сертификатов всех субъектов в цепочке головного УЦ, подчиненных центров и пользователя. Вышестоящие удостоверяющие центры могут устанавливать ограничения на действия подчиненных удостоверяющих центров. Эти ограничения поддерживаются процедурными механизмами или задаются посредством самих сертификатов. В последнем случае сертификат УЦ содержит дополнительную информацию об ограничениях.
Иерархические PKI способны быстро реагировать на компрометацию отдельного УЦ внутри инфраструктуры. Если УЦ скомпрометирован, вышестоящий УЦ просто аннулирует его сертификат. Как только работа УЦ восстанавливается, он выпускает новые сертификаты для всех своих пользователей. Вышестоящий УЦ выпускает для скомпрометированного УЦ новый сертификат с новым открытым ключом, что позволяет вернуть этот центр обратно в иерархию. Во время восстановления работы скомпрометированного УЦ продолжает поддерживаться защищенная связь между двумя пользователями, находящимися вне скомпрометированного сегмента PKI. Безусловно, пользователи, находящиеся в скомпрометированном сегменте иерархии, теряют возможность пользоваться сервисами PKI.
Что касается компрометации головного УЦ, то она имеет те же последствия, что и компрометация одиночного УЦ. Критически важным является своевременное информирование всех пользователей иерархической PKI о компрометации головного УЦ. Пользователи не могут полагаться на PKI для установления защищенных коммуникаций, пока не восстановлена работа головного УЦ, не выпущены новые сертификаты для подчиненных удостоверяющих центров и не распространена информация о новом пункте доверия. Преимущество иерархической архитектуры по сравнению с одиночным УЦ заключается в том, что в случае компрометации головного центра требуется выпустить существенно меньшее количество новых сертификатов. Кроме того головной УЦ может оперировать автономно, значительно сокращая вероятность компрометации своего ключа.
Построение пути в иерархической PKI
В иерархиях пути сертификации начинаются в корне (с головного УЦ) и заканчиваются конечными субъектами, однако строятся они в обратном направлении [60]. Построение начинается с сертификата конечного субъекта. В сертификате указаны его издатель (УЦ) и дополнение Authority Key Identifier (идентификатор ключа УЦ). Эти атрибуты позволяют найти сертификат УЦ. Имя издателя используется для определения местонахождения сертификатов УЦ в репозитории. Репозиторий может содержать несколько сертификатов, выпущенных для УЦ. Идентификатор ключа УЦ в сертификате конечного субъекта сравнивается с идентификатором ключа субъекта только в одном сертификате - искомом сертификате УЦ. Этот процесс повторяется до тех пор, пока не будет найден сертификат, изданный головным УЦ, пунктом доверия иерархии.
На рис. 10.5 показаны пути сертификации для пользователей А, В, С и D в иерархической PKI. Каждый конечный субъект имеет единственный путь сертификации. Некоторые пути сертификации длиннее прочих, но все пути начинаются в корне иерархии. Запись [(ГУЦ -> УЦ3); (УЦ3 -> D)] означает, что путь от головного УЦ (ГУЦ) до пользователя D состоит из двух сертификатов.
Рис. 10.5. Пути сертификации в иерархической PKI
В иерархиях совершенно предсказуемы те пути, которые можно построить. Поэтому конечным субъектам следовало бы защищать пути сертификации протоколом безопасности, чтобы пути нельзя было реконструировать. В архитектурах, отличных от иерархий, PKI-субъекты имеют разные пункты доверия, поэтому построение каждого пути неоднозначно.
Сетевая PKI
Сетевая архитектура PKI является альтернативой иерархической архитектуры [10]. Сетевая PKI строится как сеть доверия, многочисленные удостоверяющие центры которой предоставляют PKI-сервисы и связаны одноранговыми, то есть равноправными, отношениями. Каждый пользователь доверяет одному УЦ, причем только тому, который издал его сертификаты. Удостоверяющие центры выпускают сертификаты друг для друга; пара сертификатов описывает двусторонние отношения доверия. В сетевую PKI легко добавляется новый УЦ, для этого ему нужно обменяться сертификатами, по крайней мере, с одним УЦ, который уже входит в сеть. Однако строить путь сертификации в сетевой PKI намного труднее, чем в иерархической инфраструктуре, где построение пути от сертификата пользователя до пункта доверия строго определено. Построить путь сертификации в сети достаточно сложно, поскольку этот процесс не детерминирован и имеются многочисленные варианты формирования цепи сертификатов. Одни из них приводят к построению правильного пути, другие - заводят в тупик. Длина пути может быть больше, чем в иерархической PKI, и даже может достигать общего числа удостоверяющих центров инфраструктуры. Более того, в сети можно построить бесконечную цепь сертификатов.
Рис. 10.6. Пример сетевой PKI и построенных путей сертификации
Сертификаты, выпускаемые в сетевой PKI, содержат больше дополнительной информации. В силу того, что между удостоверяющими центрами устанавливаются равноправные отношения, одни центры не могут влиять на типы сертификатов, которые выпускают другие центры. Если УЦ желает ограничить доверие, то должен задать эти ограничения в дополнениях сертификатов, изданных для всех других удостоверяющих центров, с которыми он связан.
Сетевые PKI обладают большой гибкостью, так как имеют многочисленные пункты доверия. Компрометация одного УЦ не отражается на сетевой PKI в целом: удостоверяющие центры, которые выпустили сертификаты для скомпрометированного УЦ, просто аннулируют их, тем самым удаляя из инфраструктуры ненадежный УЦ. В результате не нарушается работа пользователей, связанных с другими удостоверяющими центрами, - они по-прежнему могут полагаться на надежные пункты доверия и защищенно связываться с остальными пользователями своей PKI. Компрометация сетевой PKI приводит либо к тому, что сворачивается работа одного УЦ вместе с его сообществом пользователей, либо, если стали ненадежными несколько удостоверяющих центров, к тому, что PKI распадается на несколько меньших инфраструктур. Восстановление после компрометации сетевой PKI происходит проще, чем иерархической, прежде всего, потому что компрометация затрагивает меньше пользователей.
