* размеры компенсации РЦ или УЦ в случае причинения ущерба доверяющей стороне.
В моделях аутсорсинга все эти соглашения уже существуют. В моделях инсорсинга требуется тщательное составление таких соглашений.
Модель доверия и архитектура PKI
Фундаментом доверия PKI являются надежные сертификаты открытых ключей. Надежность сертификатов открытых ключей зависит от надежности удостоверяющих центров, которые их подписывают. Это допущение формирует отношения доверия между различными сторонами - участниками системы PKI и позволяет конечным субъектам считать свои транзакции надежными.
Широкомасштабное развертывание PKI может вовлекать в инфраструктуру многие удостоверяющие центры, которые выпускают разнообразные сертификаты, создавая множественные отношения доверия в зависимости от области применения сертификатов, типов используемых приложений, пользователей сертификатов и видов деловых операций. Для обеспечения функциональной совместимости компонентов PKI должны быть определены отношения между этими удостоверяющими центрами и задана архитектура PKI.
Отношения между взаимодействующими удостоверяющими центрами формируют один или несколько путей сертификации, в результате верификации которых принимается решение о доверии к сертификату участника системы PKI. Организации, развертывающей PKI, необходимо определить, как строить пути сертификации и подтверждать надежность сертификатов. В PKI закрытой корпоративной системы все владельцы сертификатов работают в одной организации, доверяют одному и тому же УЦ, и путь сертификации строится на базе корневого сертификата этого центра.
При развертывании PKI сложной структуры организация должна определить, будет ли она доверять сертификатам пользователей и приложений только своего домена доверия или других доменов тоже. Как уже упоминалось ранее, домен доверия, или домен политик, характеризуется набором политик, в соответствии с которыми выпускает сертификаты данный УЦ. Если принимается решение о доверии ограниченному набору доменов, то должны быть выпущены кросс-сертификаты и тем самым внедрена в другие домены модель доверия данной организации. Если организация планирует использовать, например, приложение глобальной защищенной электронной почты, то потребуется более сложная структура кросс-сертификации всех входящих в состав PKI удостоверяющих центров, способная обеспечить построение путей сертификации между любыми двумя владельцами сертификатов из любых доменов доверия.
Модель доверия важна для определения отношений не только с внешними сторонами, но и между участниками PKI внутри организации. Так, некоторым организациям свойственна сложная корпоративная иерархия, поэтому в составе их PKI могут быть один головной УЦ и множество подчиненных ему удостоверяющих центров отделов и подразделений, то есть модель доверия будет базироваться на традиционных для конкретной компании правилах ведения бизнеса и отношениях между подразделениями. В других случаях модель доверия PKI организации может строиться на основе подписанных соглашений о политике применения сертификатов и ответственности удостоверяющих центров, связанных отношениями доверия, - тогда должны быть рассмотрены вопросы о степени ответственности организации и пользователей сертификатов в условиях кросс-сертификации.
В настоящее время крупномасштабные корпоративные PKI базируются как на иерархиях, так и на распределенных моделях доверия. Распределенная модель является более гибкой, потому что позволяет присоединять и удалять удостоверяющие центры, минимально вмешиваясь в систему взаимодействия с другими удостоверяющими центрами, как внутри организации, так и вовне.
В иерархической PKI ущерб от выхода из строя конкретного УЦ (например, из-за компрометации секретного ключа подписи УЦ) зависит от того, на каком уровне иерархии он находится. Чем ближе УЦ к верху иерархии, тем более разрушительны для всей PKI последствия его выхода из строя. Очевидно, что для защиты более высоких уровней иерархии, особенно головного УЦ, необходимы дополнительные меры безопасности, например, использование ключа подписи большей длины и/или хранение материала секретных ключей при помощи аппаратного модуля.
В настоящее время иерархическая модель, как правило, используется в web-среде, некоторые корпоративные домены также адаптируют ее. Считается, что иерархическая модель является хорошим механизмом контроля политики подчиненных удостоверяющих центров, но на самом деле аналогичные возможности контроля существуют и у кросс-сертифицированных удостоверяющих центров [44].
Выбор программного продукта или поставщика сервисов PKI
Следующий шаг - выбор программного продукта или поставщика сервисов PKI. При выборе должны быть учтены возможности функциональной совместимости с другими программными продуктами / поставщиками услуг, легкость адаптации к открытым стандартам, удобство разработки, гибкость администрирования, масштабируемость и переносимость инсталляции [84]. Кроме того, важным критерием является наличие интерфейсов прикладного программирования (Application Program Interface - API) и поддержка распространенных приложений (например, виртуальных частных сетей, управления доступом, защищенной электронной коммерции, управления смарт-картами, сервисов каталогов, защищенной электронной почты и др.). Более подробно этот вопрос обсуждался в лекции 19, целиком посвященной проблемам выбора поставщика технологии или сервисов PKI.
Выбор основных средств и оборудования
Успех развертывания PKI во многом зависит от окружающей и поддерживающей инфраструктуры. Под инфраструктурой понимаются основные средства, оборудование и персонал, необходимые для функционирования PKI.
Аппаратное и программное обеспечение УЦ и РЦ
При проектировании PKI прежде всего необходимо выбрать программное и аппаратное обеспечение УЦ и РЦ. Выбор в большей степени зависит от поставщиков программных и аппаратных средств, а также от намерения организации создать собственный УЦ или передать эти функции на аутсорсинг, но можно выделить некоторые основные моменты, не связанные с поставщиком или вариантом развертывания, которые должна гарантировать организация:
* аппаратное обеспечение для защиты ключа подписи, предназначенного для функций РЦ, должно соответствовать требованиям по крайней мере минимального уровня безопасности, который способен обеспечить криптографический модуль, используемый внутри системы безопасности для защиты несекретной информации;
* аппаратное обеспечение защиты ключа подписи, предназначенного для функций УЦ, должно соответствовать требованиям более высокого уровня безопасности, предполагающего аутентификацию субъектов на основе ролей;
* компоненты РЦ должны быть отделены от компонентов УЦ, находиться на разных серверах и, возможно, в разных центрах обработки данных. Поскольку в PKI постоянно поддерживается взаимодействие многих пользователей с УЦ, физическое разделение функций УЦ и РЦ обеспечивает защиту от потенциальных угроз со стороны нарушителей внутри организации [44].
Серверы, предназначенные для PKI, должны обладать высокой производительностью, значительными системными ресурсами и возможностями. При выборе серверов должны оцениваться точный объем оперативной памяти и дискового пространства. Масштабируемость системы PKI может обеспечить аппаратное обеспечение типа SMP-систем (с симметричной мультипроцессорной обработкой).
Такие компоненты PKI, как УЦ, РЦ и репозиторий сертификатов, теоретически могут размещаться на одном сервере, но для распределения рабочей нагрузки и в целях безопасности рекомендуется использовать несколько серверов. Разделение функций немного снижает производительность системы, но повышает защищенность компонентов и позволяет распределить обязанности по их поддержке между несколькими подразделениями. Для защиты и хранения секретного ключа УЦ, который чаще всего является объектом внутренних и внешних атак, должно использоваться криптографическое аппаратное обеспечение.
Для хранения секретных ключей и сертификатов конечных субъектов PKI целесообразно использовать такие портативные криптографические устройства, как смарт-карты или токены безопасности. В некоторых средах необходима многофакторная аутентификация, когда может потребоваться хранение секретных ключей в периферийном модуле, а не на персональных компьютерах конечных пользователей, - с этой целью иногда используются биометрические устройства либо в дополнение к аппаратным токенам или смарт-картам, либо вместо них.
