Лекция 20. Проектирование и внедрение PKI
Подробно рассматривается процесс проектирования PKI, приводится краткая характеристика основных правовых документов PKI, описываются соглашения между участниками PKI, даются рекомендации по выбору основных средств и оборудования, приводятся примерные требования к персоналу, обслуживающему PKI, обсуждается создание прототипа, пилотный проект и внедрение PKI.
ПроектированиеКлючевым аспектом развертывания PKI является выбор архитектуры и проектирование. PKI допускает гибкость проектирования независимо от выбранной технологии. Этап проектирования занимает длительное время, так как на этом этапе должна быть сформирована политика PKI и регламент, задана архитектура PKI, определены аппаратные и программные средства поддержки инфраструктуры, выбраны ее компоненты, сервисы, режимы работы, протоколы и базовые стандарты [20].
Формирование правовой политики PKI
Проектирование PKI невозможно без рассмотрения правовых аспектов ее функционирования: ППС и регламента, ответственности, страхования и др. Многие приложения PKI так или иначе нуждаются в правовой поддержке, поскольку работают с документами, заверенными цифровой подписью, или, например, требуют восстановления секретных ключей через процесс депонирования. Организации необходимо оценить необходимость разработки собственных юридических документов; если в штате имеются юристы, то им может быть поручена разработка таких документов, в противном случае организация может позаимствовать политику известного УЦ, предоставляющего услуги аутсорсинга. Хотя этот способ и не обеспечивает большой гибкости в разработке юридических документов заказчика, но он прост и экономичен.
Изучение политик PKI и стандартов
Проектирование PKI должно начинаться со сбора эталонных политик и использования их в качестве шаблонов для разработки политики данной PKI [84]. Цифровые сертификаты служат базисом доверия при коммуникации между сторонами. Политика должна разрабатываться с учетом всех возможных проблем безопасности в данной среде, неадекватность и нечеткость политики ведет к ошибкам при реализации системы безопасности и может угрожать целостности всей PKI. При формировании политики необходимо ориентироваться на стандарты в области PKI, позволяющие обеспечить функциональную совместимость разных инфраструктур открытых ключей.
Основные правовые документы
Если организация решает самостоятельно сформировать правовую политику, то должна разработать следующие документы:
* политику применения сертификатов и регламент УЦ;
* политику аутентификации;
* политику конфиденциальности (в отношении сведений, предоставляемых пользователями в целях аутентификации).
Организация, эксплуатирующая PKI, должна заключить со своими внутренними и внешними пользователями соглашения, закрепляющие ответственность сторон. Правовое регулирование PKI предполагает заключение трех видов соглашений:
* cоглашение УЦ с РЦ ;
* cоглашение между конечными субъектами и РЦ ;
* cоглашение между подписчиками/конечными субъектами и УЦ (причем в качестве конечного субъекта может выступать человек или устройство).
Политика применения сертификатов и регламент УЦ
Как правило, архитектура PKI эволюционирует от одиночных изолированных удостоверяющих центров к более сложным формам, устанавливающим отношения доверия между разнородными центрами. Эти отношения закрепляются сертификатами. Каждой политике применения сертификатов в своем домене доверия присваивается идентификатор объекта. Идентификатор политики - это уникальный зарегистрированный идентификатор объекта ( политики применения сертификатов ), который анализируется при принятии решения о доверии данному сертификату и возможности его использования для определенной цели. Идентификаторы политик характеризуют набор приложений, для которых пригоден данный сертификат. Сертификат формата X.509 v.3 в дополнении certificatePolicy может содержать один или более идентификаторов политики в зависимости от числа политик применения сертификатов данного УЦ.
В том случае, если удостоверяющие центры выпускают сертификаты в соответствии с общими политиками, в дополнении certificatePolicy указываются идентификаторы этих политик, и нет необходимости использовать другие дополнения и ограничения. Когда удостоверяющие центры работают в разных доменах политики, то процедуры согласования политик становятся более сложными [84] и требуется тщательный анализ соответствия политики каждого УЦ политикам других удостоверяющих центров. Отношения между политиками фиксируются в дополнении соответствия политик policyMappings. Это дополнение сертификата позволяет удостоверяющим центрам задавать ограниченный набор приемлемых политик и отклонять сертификаты, выпущенные в соответствии с неприемлемой для данного УЦ политикой.
Кроме того, функциональная совместимость доменов может достигаться в результате заключения формальных соглашений между корпоративными доменами, желающими взаимодействовать в соответствии с одной или несколькими междоменными политиками.
ППС обеспечивает определенный уровень доверия доверяющей стороны к сертификату, изданному на условиях, описанных в этой политике. Если, например, организация передает функции УЦ на аутсорсинг и ей необходим очень надежный сертификат, то она может запросить от УЦ сертификат высокого уровня безопасности. В этом случае УЦ, прежде чем выпустить сертификат, будет выполнять огромное число проверок. Другой крайностью может быть выдача сертификатов, перед выпуском которых выполняется минимальная проверка, например, правильности адреса электронной почты будущего владельца сертификата.
Регламент описывает процессы и процедуры выполнения УЦ операций с сертификатами. ППС характеризует надежность конкретного сертификата, а регламент - надежность самого УЦ. ППС разрабатывается на достаточно длительный срок и должна удовлетворять строгим требованиям, обычно она излагается в соответствии с форматом описания политики, который задает документ RFC 2527 Certificate Policy and Certification Practices Framework [152]. Этот документ содержит стандартный иерархический набор положений, сгруппированный в 8 основных разделов и 185 подразделов второго и третьего уровней (подробное описание формата ППС и регламента УЦ см. в лекции 14).
Примерный перечень положений служит ориентиром при описании политики применения сертификатов и разработке регламента УЦ и помогает разработчикам политики и регламента не упустить важные моменты.
Соглашение между УЦ и РЦ
Это соглашение охватывает все стороны отношений между УЦ и РЦ. Если УЦ и РЦ являются компонентами модели инсорсинга, то соглашение между ними упрощается и приобретает статус внутреннего юридического соглашения между УЦ (обычно работающим под управлением ИТ-штата) и РЦ (обычно функционирующим под управлением штата, занимающегося административной и операционной работой). В любом случае это соглашение обязательно должно проходить процедуру утверждения и содержать следующие положения:
* размере компенсации РЦ удостоверяющему центру;
* финансовых гарантиях непрерывности функционирования УЦ;
* размере компенсации УЦ доверяющей стороне в случае выпуска фальшивого сертификата.
Соглашение между конечным субъектом и РЦ
Это соглашение описывает отношения между пользователем сертификата и РЦ той организации, которая выпустила данный сертификат. Соглашение должно включать обязательства пользователя:
* предоставлять правдивую информацию, которая используется при выпуске сертификата;
* использовать сертификат в соответствии с регламентом УЦ;
* обращаться с заявлением об аннулировании сертификатов, если соответствующие секретные ключи потеряны или скомпрометированы;
* прекращать использование всех пар ключей (открытый/секретный), срок действия которых истек, и не стараться выдать их за действующие ключи.
Соглашение между конечным субъектом и УЦ
Это соглашение можно назвать соглашением с доверяющей стороной. Оно содержит следующие положения:
* обязательство доверяющей стороны проверять статус сертификата перед его использованием, то есть убеждаться в том, что сертификат не просрочен и не аннулирован;
* обязательство доверяющей стороны использовать сертификат только по назначению, то есть в целях, установленных ППС и регламентом УЦ;
* размеры компенсации РЦ или УЦ в случае причинения ущерба доверяющей стороне.
В моделях аутсорсинга все эти соглашения уже существуют. В моделях инсорсинга требуется тщательное составление таких соглашений.
Модель доверия и архитектура 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 целесообразно использовать такие портативные криптографические устройства, как смарт-карты или токены безопасности. В некоторых средах необходима многофакторная аутентификация, когда может потребоваться хранение секретных ключей в периферийном модуле, а не на персональных компьютерах конечных пользователей, - с этой целью иногда используются биометрические устройства либо в дополнение к аппаратным токенам или смарт-картам, либо вместо них.
Компактность смарт-карт делает удобным их применение в персональных и сетевых компьютерах, киосках, считывателях жетонов доступа и т.д. в зависимости от конкретных PKI-приложений, но при этом возникает необходимость в дополнительных периферийных устройствах - считывателях смарт-карт. В ряде PKI-продуктов для хранения ключей и сертификатов реализованы виртуальные смарт-карты, имитирующие поведение физических аналогов и обеспечивающие доступ пользователей без считывателей смарт-карт.
Не все поставщики технологии поддерживают периферийные устройства в одинаковой степени. Но если поставщики предлагают поддержку периферийных устройств, то должны придерживаться стандартных интерфейсов прикладного программирования.
Безопасность компонентов PKI
Многие организации полагают, что PKI сама по себе создает защищенную инфраструктуру. Это, конечно, не так - помимо PKI, необходимы такие средства безопасности, как межсетевые экраны, антивирусное программное обеспечение и т.п. (см. лекцию 1). Все критически важные компоненты PKI должны быть адекватно защищены. Наиболее строгие требования предъявляются к физической безопасности систем УЦ, иногда требуется в той же мере предотвращать несанкционированный доступ и к системе РЦ. Рекомендуется физически разделять функции УЦ и РЦ при помощи межсетевых экранов.
Система РЦ должна быть хорошо защищена физически и логически от атак внешних и внутренних нарушителей. Поскольку доступ к серверу регистрации должен поддерживаться для большой группы пользователей (неважно, внутренних или внешних для организации), целесообразно его устанавливать в демилитаризованной зоне с системой обнаружения вторжений и возможностями контроля доступа. В связи с тем, что регистрация обычно выполняется посредством web-сервера (ведущие поставщики PKI обеспечивают такую функциональность), организация должна иметь соответствующий компьютер для размещения на нем web-сервера регистрации.
Функции любого РЦ должны быть защищены внешними устройствами типа смарт-карт, требующими двухфакторной аутентификации. В целях минимизации лазеек безопасности следует применять устройства безопасности - простые аппаратные модули с одной или двумя функциями. Межсетевые экраны и антивирусные средства имеют устройства безопасности, которые позволяют быстро развертывать и приводить в состояние готовности защищенные системы.
Серверы PKI должны размещаться в отдельном закрытом помещении, доступ в которое разрешен только обслуживающему персоналу, тщательно контролируется и регистрируется. Серверы должны быть подключены к источнику бесперебойного питания, а на время его отключения серверы должны автоматически создавать резервные копии данных и завершать работу в штатном режиме. Сегмент сети с серверами PKI должен быть защищен по крайней мере при помощи межсетевого экрана, прозрачного только для трафика PKI.
Каждой организации следует определить, где компоненты PKI будут размещаться и каким образом защищаться. Если организация не имеет средств адекватной защиты, то либо должна их приобрести, либо прибегнуть к услугам доверенной третьей стороны. Очевидно, что приобретение потребует значительных капиталовложений, поэтому вариант аутсорсинга может в ряде случаев оказаться экономически более выгодным.
Выбор персонала для обслуживания PKI
Персонал, обслуживающий PKI, составляет часть инфраструктуры. Несмотря на то, что криптография с открытыми ключами появилась два десятилетия назад, она стала широко применяться только недавно. Так как, с точки зрения реализации и внедрения, эта технология достаточно нова, пока явно не хватает знающих специалистов в этой области, более того - их трудно привлечь к работе и удержать.
Для развертывания PKI необходимы не только администраторы со знанием технологии цифровых сертификатов, но и специалисты, способные участвовать в разработке правовых документов и соглашений, таких как политики применения сертификатов и соглашения о кросс-сертификации (по сути, о функциональной совместимости между доменами PKI). Более того, важно, чтобы сама стратегия развертывания PKI была хорошо продумана и оформлена в виде документа, что также невозможно осуществить без опытного и знающего персонала. Конечно, в случае использования аутсорсинговой модели эти функции могут быть переданы поставщику услуг,
но при самостоятельном развертывании PKI организации необходим квалифицированный и обученный персонал. Организации следует определить количество и уровень квалификации необходимого персонала, которые зависят от масштаба PKI, а также от того, в какой мере инфраструктура поддерживается собственными силами организации [44].
Для успешной реализации проекта необходимы разработчики программного обеспечения, которые способны выполнить интеграцию системы с действующими системами и PKI-совместимыми приложениями и настройку системы на конкретные требования заказчика. Подразделение информационных технологий обеспечивает работу по следующим направлениям:
* инсталляция программного продукта;
* конфигурирование системы;
* системное администрирование;
* теория и практика PKI;
* криптография с открытыми ключами;
* информационная безопасность.
Персонал подразделения поддержки операционной работы системы должен иметь базовые знания технологии PKI, заниматься постановкой задач и эксплуатацией системы. Сотрудники подразделения авторизации должны иметь представление о концепции PKI и системном администрировании. Подразделение аудита отвечает за правовое обеспечение системы PKI (политика, ответственность), его персонал должен обладать знаниями в области права и информационной безопасности.
Одна из наиболее трудных проблем развертывания и успешного использования PKI заключается в привлечении к этой работе на постоянной основе квалифицированного штата профессионалов в этой области. При найме специалиста на работу (постоянную или временную - для консультаций) важно учитывать:
* наличие сертификата авторитетной организации, подтверждающего квалификацию в сфере ИТ-безопасности;
* подготовку в области информационной безопасности;
* опыт разработки программного обеспечения (если необходима интеграция);
* возможность быть доступным или по крайней мере оперативно взаимодействовать с ИТ-штатом, чтобы гарантировалась ежедневная круглосуточная работа PKI-системы.
При развертывании PKI должны быть определены и оформлены в виде инструкций должностные обязанности персонала, занимающегося управлением и администрированием системы PKI, а при необходимости организовано дополнительное обучение служащих, обеспечивающих безопасность системы. В зависимости от масштаба PKI и конкретных условий допускается совмещение должностей. В список должностей, необходимых для поддержки системы PKI, входят:
* системный администратор;
* системный оператор;
* администратор УЦ;
* администратор РЦ;
* администратор каталога;
* специалист службы помощи;
* менеджер по политике безопасности;
* аудитор безопасности или главный администратор.
Системный администратор отвечает за функционирование системы безопасности в целом и обычно привлекается к работе по развертыванию PKI на самых ранних стадиях. Особенно важно участие системного администратора в составлении плана проекта, так как он способен оценить, сколько времени потребуют различные виды активности системы. Если организация планирует работу своего собственного УЦ, то системный администратор отвечает за подбор, инсталляцию и конфигурирование необходимого программного обеспечения, а также за его поддержку и внесение изменений. Кроме того, обязанности системного администратора состоят в присвоении полномочий и профилей пользователям системы и поддержке паролей.
Системный оператор должен следить за операционной работой системы PKI, реагировать на ошибки и соблюдать установленные регламентом процедуры. К дополнительным функциям операторов можно отнести восстановление прежнего состояния системы и поддержку относящихся к PKI электронных документов. В зависимости от масштаба PKI к ежедневной работе привлекаются от одного до нескольких операторов.
Администратор УЦ отвечает за поддержку всех функций удостоверяющего центра: генерацию ключей, выпуск и подписание сертификатов, а также обработку запросов на кросс-сертификацию и авторизацию услуг по восстановлению ключей. Если в состав PKI входит регистрационный центр, то на администратора РЦ возлагаются обязанности обработки заявок на сертификаты и принятия решения о выдаче сертификата заявителю.
Администратор каталога отвечает за создание структуры, организацию и поддержку каталога (LDAP), содержащего информацию о сертификатах, а также управление правами доступа к каталогу внутренних и внешних для PKI пользователей. Администратор каталога обеспечивает реализацию соглашения об используемых в каталоге именах в соответствии с требованиями промышленных или корпоративных стандартов, а также хранение данных аутентификации и сертификации в репозитории.
Специалисты службы помощи должны реагировать на обращения клиентов системы, руководствуясь соответствующими документами, описывающими процедуры обслуживания пользователей.
Для поддержки защищенного и эффективного функционирования PKI должна регулярно пересматриваться политика безопасности, за ее обновление отвечает менеджер по политике безопасности.
Функции аудита системы в целом и подготовки отчетов для руководства возлагаются на аудитора безопасности или главного администратора. Аудитор безопасности должен иметь специальную подготовку в области информационной безопасности и криптографии и отвечать за реализацию корпоративной политики безопасности, в том числе политики применения сертификатов, регламента и политики управления ключами, и документальное оформление всех политик и процедур. На аудитора безопасности возлагается ответственность за разработку и совершенствование процедур управления и администрирования системой безопасности,
процедур восстановления прежнего состояния системы и восстановления после аварии, а также процедур, которым должны следовать третьи стороны при их обслуживании PKI-системой. Аудитор обязан выполнять регулярные и незапланированные проверки контрольных журналов и отслеживать соответствие всех компонентов и процедур системы безопасности PKI промышленным и корпоративным стандартам.
В процессе развертывания PKI также могут потребоваться услуги опытных консультантов и юрисконсультов для разработки и/или анализа ППС и регламента УЦ. Расходы на оплату труда персонала могут существенно повлиять на совокупную стоимость владения PKI и должны рассматриваться наряду с другими затратными факторами.
Завершение этапа проектирования
После документального оформления политики применения сертификатов, выбора программного продукта или поставщика услуг, аппаратных средств поддержки PKI и физической среды, формулировки требований по управлению и администрированию системой, должен быть разработан регламент УЦ. На этом же шаге определяются процедуры оперирования и управления, которые необходимы для проверки эффективности системы безопасности на базе PKI, и разрабатывается методика сопровождения и поддержки готовой системы [20].
Ключевым аспектом развертывания PKI является выбор архитектуры и проектирование. PKI допускает гибкость проектирования независимо от выбранной технологии. Этап проектирования занимает длительное время, так как на этом этапе должна быть сформирована политика PKI и регламент, задана архитектура PKI, определены аппаратные и программные средства поддержки инфраструктуры, выбраны ее компоненты, сервисы, режимы работы, протоколы и базовые стандарты [20].
Формирование правовой политики PKI
Проектирование PKI невозможно без рассмотрения правовых аспектов ее функционирования: ППС и регламента, ответственности, страхования и др. Многие приложения PKI так или иначе нуждаются в правовой поддержке, поскольку работают с документами, заверенными цифровой подписью, или, например, требуют восстановления секретных ключей через процесс депонирования. Организации необходимо оценить необходимость разработки собственных юридических документов; если в штате имеются юристы, то им может быть поручена разработка таких документов, в противном случае организация может позаимствовать политику известного УЦ, предоставляющего услуги аутсорсинга. Хотя этот способ и не обеспечивает большой гибкости в разработке юридических документов заказчика, но он прост и экономичен.
Изучение политик PKI и стандартов
Проектирование PKI должно начинаться со сбора эталонных политик и использования их в качестве шаблонов для разработки политики данной PKI [84]. Цифровые сертификаты служат базисом доверия при коммуникации между сторонами. Политика должна разрабатываться с учетом всех возможных проблем безопасности в данной среде, неадекватность и нечеткость политики ведет к ошибкам при реализации системы безопасности и может угрожать целостности всей PKI. При формировании политики необходимо ориентироваться на стандарты в области PKI, позволяющие обеспечить функциональную совместимость разных инфраструктур открытых ключей.
Основные правовые документы
Если организация решает самостоятельно сформировать правовую политику, то должна разработать следующие документы:
* политику применения сертификатов и регламент УЦ;
* политику аутентификации;
* политику конфиденциальности (в отношении сведений, предоставляемых пользователями в целях аутентификации).
Организация, эксплуатирующая PKI, должна заключить со своими внутренними и внешними пользователями соглашения, закрепляющие ответственность сторон. Правовое регулирование PKI предполагает заключение трех видов соглашений:
* cоглашение УЦ с РЦ ;
* cоглашение между конечными субъектами и РЦ ;
* cоглашение между подписчиками/конечными субъектами и УЦ (причем в качестве конечного субъекта может выступать человек или устройство).
Политика применения сертификатов и регламент УЦ
Как правило, архитектура PKI эволюционирует от одиночных изолированных удостоверяющих центров к более сложным формам, устанавливающим отношения доверия между разнородными центрами. Эти отношения закрепляются сертификатами. Каждой политике применения сертификатов в своем домене доверия присваивается идентификатор объекта. Идентификатор политики - это уникальный зарегистрированный идентификатор объекта ( политики применения сертификатов ), который анализируется при принятии решения о доверии данному сертификату и возможности его использования для определенной цели. Идентификаторы политик характеризуют набор приложений, для которых пригоден данный сертификат. Сертификат формата X.509 v.3 в дополнении certificatePolicy может содержать один или более идентификаторов политики в зависимости от числа политик применения сертификатов данного УЦ.
В том случае, если удостоверяющие центры выпускают сертификаты в соответствии с общими политиками, в дополнении certificatePolicy указываются идентификаторы этих политик, и нет необходимости использовать другие дополнения и ограничения. Когда удостоверяющие центры работают в разных доменах политики, то процедуры согласования политик становятся более сложными [84] и требуется тщательный анализ соответствия политики каждого УЦ политикам других удостоверяющих центров. Отношения между политиками фиксируются в дополнении соответствия политик policyMappings. Это дополнение сертификата позволяет удостоверяющим центрам задавать ограниченный набор приемлемых политик и отклонять сертификаты, выпущенные в соответствии с неприемлемой для данного УЦ политикой. Кроме того, функциональная совместимость доменов может достигаться в результате заключения формальных соглашений между корпоративными доменами, желающими взаимодействовать в соответствии с одной или несколькими междоменными политиками.
ППС обеспечивает определенный уровень доверия доверяющей стороны к сертификату, изданному на условиях, описанных в этой политике. Если, например, организация передает функции УЦ на аутсорсинг и ей необходим очень надежный сертификат, то она может запросить от УЦ сертификат высокого уровня безопасности. В этом случае УЦ, прежде чем выпустить сертификат, будет выполнять огромное число проверок. Другой крайностью может быть выдача сертификатов, перед выпуском которых выполняется минимальная проверка, например, правильности адреса электронной почты будущего владельца сертификата.
Регламент описывает процессы и процедуры выполнения УЦ операций с сертификатами. ППС характеризует надежность конкретного сертификата, а регламент - надежность самого УЦ. ППС разрабатывается на достаточно длительный срок и должна удовлетворять строгим требованиям, обычно она излагается в соответствии с форматом описания политики, который задает документ RFC 2527 Certificate Policy and Certification Practices Framework [152]. Этот документ содержит стандартный иерархический набор положений, сгруппированный в 8 основных разделов и 185 подразделов второго и третьего уровней (подробное описание формата ППС и регламента УЦ см. в лекции 14). Примерный перечень положений служит ориентиром при описании политики применения сертификатов и разработке регламента УЦ и помогает разработчикам политики и регламента не упустить важные моменты.
Соглашение между УЦ и РЦ
Это соглашение охватывает все стороны отношений между УЦ и РЦ. Если УЦ и РЦ являются компонентами модели инсорсинга, то соглашение между ними упрощается и приобретает статус внутреннего юридического соглашения между УЦ (обычно работающим под управлением ИТ-штата) и РЦ (обычно функционирующим под управлением штата, занимающегося административной и операционной работой). В любом случае это соглашение обязательно должно проходить процедуру утверждения и содержать следующие положения:
* размере компенсации РЦ удостоверяющему центру;
* финансовых гарантиях непрерывности функционирования УЦ;
* размере компенсации УЦ доверяющей стороне в случае выпуска фальшивого сертификата.
Соглашение между конечным субъектом и РЦ
Это соглашение описывает отношения между пользователем сертификата и РЦ той организации, которая выпустила данный сертификат. Соглашение должно включать обязательства пользователя:
* предоставлять правдивую информацию, которая используется при выпуске сертификата;
* использовать сертификат в соответствии с регламентом УЦ;
* обращаться с заявлением об аннулировании сертификатов, если соответствующие секретные ключи потеряны или скомпрометированы;
* прекращать использование всех пар ключей (открытый/секретный), срок действия которых истек, и не стараться выдать их за действующие ключи.
Соглашение между конечным субъектом и УЦ
Это соглашение можно назвать соглашением с доверяющей стороной. Оно содержит следующие положения:
* обязательство доверяющей стороны проверять статус сертификата перед его использованием, то есть убеждаться в том, что сертификат не просрочен и не аннулирован;
* обязательство доверяющей стороны использовать сертификат только по назначению, то есть в целях, установленных ППС и регламентом УЦ;
* размеры компенсации РЦ или УЦ в случае причинения ущерба доверяющей стороне.
В моделях аутсорсинга все эти соглашения уже существуют. В моделях инсорсинга требуется тщательное составление таких соглашений.
Модель доверия и архитектура 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 целесообразно использовать такие портативные криптографические устройства, как смарт-карты или токены безопасности. В некоторых средах необходима многофакторная аутентификация, когда может потребоваться хранение секретных ключей в периферийном модуле, а не на персональных компьютерах конечных пользователей, - с этой целью иногда используются биометрические устройства либо в дополнение к аппаратным токенам или смарт-картам, либо вместо них.
Компактность смарт-карт делает удобным их применение в персональных и сетевых компьютерах, киосках, считывателях жетонов доступа и т.д. в зависимости от конкретных PKI-приложений, но при этом возникает необходимость в дополнительных периферийных устройствах - считывателях смарт-карт. В ряде PKI-продуктов для хранения ключей и сертификатов реализованы виртуальные смарт-карты, имитирующие поведение физических аналогов и обеспечивающие доступ пользователей без считывателей смарт-карт.
Не все поставщики технологии поддерживают периферийные устройства в одинаковой степени. Но если поставщики предлагают поддержку периферийных устройств, то должны придерживаться стандартных интерфейсов прикладного программирования.
Безопасность компонентов PKI
Многие организации полагают, что PKI сама по себе создает защищенную инфраструктуру. Это, конечно, не так - помимо PKI, необходимы такие средства безопасности, как межсетевые экраны, антивирусное программное обеспечение и т.п. (см. лекцию 1). Все критически важные компоненты PKI должны быть адекватно защищены. Наиболее строгие требования предъявляются к физической безопасности систем УЦ, иногда требуется в той же мере предотвращать несанкционированный доступ и к системе РЦ. Рекомендуется физически разделять функции УЦ и РЦ при помощи межсетевых экранов.
Система РЦ должна быть хорошо защищена физически и логически от атак внешних и внутренних нарушителей. Поскольку доступ к серверу регистрации должен поддерживаться для большой группы пользователей (неважно, внутренних или внешних для организации), целесообразно его устанавливать в демилитаризованной зоне с системой обнаружения вторжений и возможностями контроля доступа. В связи с тем, что регистрация обычно выполняется посредством web-сервера (ведущие поставщики PKI обеспечивают такую функциональность), организация должна иметь соответствующий компьютер для размещения на нем web-сервера регистрации.
Функции любого РЦ должны быть защищены внешними устройствами типа смарт-карт, требующими двухфакторной аутентификации. В целях минимизации лазеек безопасности следует применять устройства безопасности - простые аппаратные модули с одной или двумя функциями. Межсетевые экраны и антивирусные средства имеют устройства безопасности, которые позволяют быстро развертывать и приводить в состояние готовности защищенные системы.
Серверы PKI должны размещаться в отдельном закрытом помещении, доступ в которое разрешен только обслуживающему персоналу, тщательно контролируется и регистрируется. Серверы должны быть подключены к источнику бесперебойного питания, а на время его отключения серверы должны автоматически создавать резервные копии данных и завершать работу в штатном режиме. Сегмент сети с серверами PKI должен быть защищен по крайней мере при помощи межсетевого экрана, прозрачного только для трафика PKI.
Каждой организации следует определить, где компоненты PKI будут размещаться и каким образом защищаться. Если организация не имеет средств адекватной защиты, то либо должна их приобрести, либо прибегнуть к услугам доверенной третьей стороны. Очевидно, что приобретение потребует значительных капиталовложений, поэтому вариант аутсорсинга может в ряде случаев оказаться экономически более выгодным.
Выбор персонала для обслуживания PKI
Персонал, обслуживающий PKI, составляет часть инфраструктуры. Несмотря на то, что криптография с открытыми ключами появилась два десятилетия назад, она стала широко применяться только недавно. Так как, с точки зрения реализации и внедрения, эта технология достаточно нова, пока явно не хватает знающих специалистов в этой области, более того - их трудно привлечь к работе и удержать.
Для развертывания PKI необходимы не только администраторы со знанием технологии цифровых сертификатов, но и специалисты, способные участвовать в разработке правовых документов и соглашений, таких как политики применения сертификатов и соглашения о кросс-сертификации (по сути, о функциональной совместимости между доменами PKI). Более того, важно, чтобы сама стратегия развертывания PKI была хорошо продумана и оформлена в виде документа, что также невозможно осуществить без опытного и знающего персонала. Конечно, в случае использования аутсорсинговой модели эти функции могут быть переданы поставщику услуг, но при самостоятельном развертывании PKI организации необходим квалифицированный и обученный персонал. Организации следует определить количество и уровень квалификации необходимого персонала, которые зависят от масштаба PKI, а также от того, в какой мере инфраструктура поддерживается собственными силами организации [44].
Для успешной реализации проекта необходимы разработчики программного обеспечения, которые способны выполнить интеграцию системы с действующими системами и PKI-совместимыми приложениями и настройку системы на конкретные требования заказчика. Подразделение информационных технологий обеспечивает работу по следующим направлениям:
* инсталляция программного продукта;
* конфигурирование системы;
* системное администрирование;
* теория и практика PKI;
* криптография с открытыми ключами;
* информационная безопасность.
Персонал подразделения поддержки операционной работы системы должен иметь базовые знания технологии PKI, заниматься постановкой задач и эксплуатацией системы. Сотрудники подразделения авторизации должны иметь представление о концепции PKI и системном администрировании. Подразделение аудита отвечает за правовое обеспечение системы PKI (политика, ответственность), его персонал должен обладать знаниями в области права и информационной безопасности.
Одна из наиболее трудных проблем развертывания и успешного использования PKI заключается в привлечении к этой работе на постоянной основе квалифицированного штата профессионалов в этой области. При найме специалиста на работу (постоянную или временную - для консультаций) важно учитывать:
* наличие сертификата авторитетной организации, подтверждающего квалификацию в сфере ИТ-безопасности;
* подготовку в области информационной безопасности;
* опыт разработки программного обеспечения (если необходима интеграция);
* возможность быть доступным или по крайней мере оперативно взаимодействовать с ИТ-штатом, чтобы гарантировалась ежедневная круглосуточная работа PKI-системы.
При развертывании PKI должны быть определены и оформлены в виде инструкций должностные обязанности персонала, занимающегося управлением и администрированием системы PKI, а при необходимости организовано дополнительное обучение служащих, обеспечивающих безопасность системы. В зависимости от масштаба PKI и конкретных условий допускается совмещение должностей. В список должностей, необходимых для поддержки системы PKI, входят:
* системный администратор;
* системный оператор;
* администратор УЦ;
* администратор РЦ;
* администратор каталога;
* специалист службы помощи;
* менеджер по политике безопасности;
* аудитор безопасности или главный администратор.
Системный администратор отвечает за функционирование системы безопасности в целом и обычно привлекается к работе по развертыванию PKI на самых ранних стадиях. Особенно важно участие системного администратора в составлении плана проекта, так как он способен оценить, сколько времени потребуют различные виды активности системы. Если организация планирует работу своего собственного УЦ, то системный администратор отвечает за подбор, инсталляцию и конфигурирование необходимого программного обеспечения, а также за его поддержку и внесение изменений. Кроме того, обязанности системного администратора состоят в присвоении полномочий и профилей пользователям системы и поддержке паролей.
Системный оператор должен следить за операционной работой системы PKI, реагировать на ошибки и соблюдать установленные регламентом процедуры. К дополнительным функциям операторов можно отнести восстановление прежнего состояния системы и поддержку относящихся к PKI электронных документов. В зависимости от масштаба PKI к ежедневной работе привлекаются от одного до нескольких операторов.
Администратор УЦ отвечает за поддержку всех функций удостоверяющего центра: генерацию ключей, выпуск и подписание сертификатов, а также обработку запросов на кросс-сертификацию и авторизацию услуг по восстановлению ключей. Если в состав PKI входит регистрационный центр, то на администратора РЦ возлагаются обязанности обработки заявок на сертификаты и принятия решения о выдаче сертификата заявителю.
Администратор каталога отвечает за создание структуры, организацию и поддержку каталога (LDAP), содержащего информацию о сертификатах, а также управление правами доступа к каталогу внутренних и внешних для PKI пользователей. Администратор каталога обеспечивает реализацию соглашения об используемых в каталоге именах в соответствии с требованиями промышленных или корпоративных стандартов, а также хранение данных аутентификации и сертификации в репозитории.
Специалисты службы помощи должны реагировать на обращения клиентов системы, руководствуясь соответствующими документами, описывающими процедуры обслуживания пользователей.
Для поддержки защищенного и эффективного функционирования PKI должна регулярно пересматриваться политика безопасности, за ее обновление отвечает менеджер по политике безопасности.
Функции аудита системы в целом и подготовки отчетов для руководства возлагаются на аудитора безопасности или главного администратора. Аудитор безопасности должен иметь специальную подготовку в области информационной безопасности и криптографии и отвечать за реализацию корпоративной политики безопасности, в том числе политики применения сертификатов, регламента и политики управления ключами, и документальное оформление всех политик и процедур. На аудитора безопасности возлагается ответственность за разработку и совершенствование процедур управления и администрирования системой безопасности, процедур восстановления прежнего состояния системы и восстановления после аварии, а также процедур, которым должны следовать третьи стороны при их обслуживании PKI-системой. Аудитор обязан выполнять регулярные и незапланированные проверки контрольных журналов и отслеживать соответствие всех компонентов и процедур системы безопасности PKI промышленным и корпоративным стандартам.
В процессе развертывания PKI также могут потребоваться услуги опытных консультантов и юрисконсультов для разработки и/или анализа ППС и регламента УЦ. Расходы на оплату труда персонала могут существенно повлиять на совокупную стоимость владения PKI и должны рассматриваться наряду с другими затратными факторами.
Завершение этапа проектирования
После документального оформления политики применения сертификатов, выбора программного продукта или поставщика услуг, аппаратных средств поддержки PKI и физической среды, формулировки требований по управлению и администрированию системой, должен быть разработан регламент УЦ. На этом же шаге определяются процедуры оперирования и управления, которые необходимы для проверки эффективности системы безопасности на базе PKI, и разрабатывается методика сопровождения и поддержки готовой системы [20].
Создание прототипа, пилотный проект и внедрение
Создание прототипа
Прежде чем начнутся работы по развертыванию системы PKI, требуется, чтобы организация и поставщик технологии договорились о деталях реализации проекта. На этом этапе происходит приобретение и доставка программного и аппаратного обеспечения, конфигурирование сервера УЦ, проводится предварительное совещание между представителями заказчика и группой развертывания и заключается соглашение о выполняемой работе.
Для подтверждения избранной концепции PKI и подготовки пилотного проекта целесообразно создание прототипа системы на базе выбранного программного продукта. Модификация готовых программных приложений, а также проектирование и разработка новых приложений, необходимых для поддержки PKI, должны выполняться с учетом требований пользователей системы. На этом этапе проводится независимый аудит и анализ источников рисков и уязвимости системы для принятия соответствующих решений.
Пилотный проект
На этом этапе создается иерархия удостоверяющих центров PKI, система их именования и выполняется генерация корневого УЦ. Затем происходит инсталляция базового программного обеспечения и его подготовка к развертыванию PKI. Для этого регистрируется и инсталлируется сертификат администратора РЦ, загружается программное обеспечение УЦ и настраивается на работу в онлайновом режиме.
В процессе реализации пилотного проекта происходит установка и настройка программного обеспечения для регистрации, тестирование процесса регистрации; кроме того, может быть выполнено подключение или настройка web-сервера, конфигурирование web-страниц регистрации, загрузка и инсталляция файла политики. В зависимости от требований заказчика могут быть установлены дополнительные опциональные модули, например для сервисов депонирования ключей или роуминга сертификатов.
После завершения инсталляции программного обеспечения системы PKI и успешного прохождения тестов всех устройств, тестов интеграции системы и проверки возможностей работы с ней пользователей, осуществляется тестирование пилотной системы. Очень важно сразу же определить ее масштабы и круг обслуживаемых пользователей. Рекомендуется, чтобы работа системы начиналась с обслуживания ограниченного числа пользователей и внутренних приложений, но ошибочно ограничивать пилотную систему пределами ИТ-подразделения - желательно сразу подключать к ней тех пользователей, которым предстоит активно работать с инфраструктурой после ее полного развертывания [36].
Запуск пилотной системы обычно выполняется в условиях реальной деятельности, но в определенных временных рамках и ограниченной среде (например, на базе нескольких подразделений, отделов или групп пользователей). При этом в выпуске и подписании сертификатов в онлайновом режиме участвует не производственный, а тестовый корневой УЦ. Работа пилотной системы должна быть организована параллельно работе старой системы, возможности и уровень безопасности последней должны поддерживаться на прежнем уровне.
На базе пилотной системы выполняется:
* тестирование всех функциональных требований, производительности и операционных регламентов, а также всех наиболее важных приложений защиты [20];
* процедура пробного завершения работы системы, восстановление ее работы и проверка функционирования системы после этих операций;
* проверка физического и кадрового контроля безопасности в PKI.
Внедрение
После успешной апробации пилотной системы начинается ее внедрение. На этом этапе происходит замена сертификатов тестового корневого УЦ на сертификаты рабочего УЦ и выполняется проверка работоспособности системы PKI с последующими приемными испытаниями. Система оценивается пользователями и соответствующими специалистами на предмет защищенности. Отчет о соответствии всем требованиям безопасности с описаниями тестов атак на систему является одним из главных результатов этого этапа.
Далее проводится юридическая экспертиза и утверждение регламента PKI, положений ППС и установленных форм контрактов. Последним этапом по порядку, но не по значимости, является этап передачи знаний от группы консультантов персоналу, который будет обслуживать систему PKI, без этого практически невозможна поддержка правильного функционирования инфраструктуры. Кроме того, организуется обучение пользователей PKI и создается служба помощи.
Большинство ИТ-проектов терпят неудачу на этапе внедрения в результате превышения стоимости и неправильного планирования времени развертывания. Чаще всего развертывание PKI является частью более крупного проекта и связано с реализацией других решений, например виртуальных частных сетей. Наибольшее влияние на стоимость и успех развертывания оказывают имеющиеся в распоряжении ресурсы и эффективное управление проектом.
Перечислим некоторые характерные ошибки при развертывании PKI:
* отсутствие планирования управления конфигурацией сети в случае изменений (в частности, размещения и связывания друг с другом отдельных компонентов PKI, а также их защиты и организации доступа к ним через маршрутизаторы и межсетевые экраны);
* отсутствие планирования "окон простоя";
* позднее обучение и привлечение к реализации проекта ИТ-персонала, который в дальнейшем будет обслуживать системы PKI;
* составление руководств пользователей без инструкций, объясняющих пользователям, как управлять изменениями в работе своих приложений после развертывания PKI;
* несвоевременное назначение администраторов УЦ и РЦ (их следует назначать до начала развертывания PKI).
Все системы изменяются с течением времени. Установка новых версий, внедрение новых пользовательских приложений, увеличение производительности, мощности и учет новых требований, обновление аппаратной платформы, - все это требует соответствующего управления [20]. Для поддержки, сопровождения и модификации системы PKI формируется подразделение технической поддержки. Результатом этапа является функционирующая PKI, которая соответствует всем требованиям и ограничениям, сформированным в процессе анализа и проектирования системы.
Создание прототипа
Прежде чем начнутся работы по развертыванию системы PKI, требуется, чтобы организация и поставщик технологии договорились о деталях реализации проекта. На этом этапе происходит приобретение и доставка программного и аппаратного обеспечения, конфигурирование сервера УЦ, проводится предварительное совещание между представителями заказчика и группой развертывания и заключается соглашение о выполняемой работе.
Для подтверждения избранной концепции PKI и подготовки пилотного проекта целесообразно создание прототипа системы на базе выбранного программного продукта. Модификация готовых программных приложений, а также проектирование и разработка новых приложений, необходимых для поддержки PKI, должны выполняться с учетом требований пользователей системы. На этом этапе проводится независимый аудит и анализ источников рисков и уязвимости системы для принятия соответствующих решений.
Пилотный проект
На этом этапе создается иерархия удостоверяющих центров PKI, система их именования и выполняется генерация корневого УЦ. Затем происходит инсталляция базового программного обеспечения и его подготовка к развертыванию PKI. Для этого регистрируется и инсталлируется сертификат администратора РЦ, загружается программное обеспечение УЦ и настраивается на работу в онлайновом режиме.
В процессе реализации пилотного проекта происходит установка и настройка программного обеспечения для регистрации, тестирование процесса регистрации; кроме того, может быть выполнено подключение или настройка web-сервера, конфигурирование web-страниц регистрации, загрузка и инсталляция файла политики. В зависимости от требований заказчика могут быть установлены дополнительные опциональные модули, например для сервисов депонирования ключей или роуминга сертификатов.
После завершения инсталляции программного обеспечения системы PKI и успешного прохождения тестов всех устройств, тестов интеграции системы и проверки возможностей работы с ней пользователей, осуществляется тестирование пилотной системы. Очень важно сразу же определить ее масштабы и круг обслуживаемых пользователей. Рекомендуется, чтобы работа системы начиналась с обслуживания ограниченного числа пользователей и внутренних приложений, но ошибочно ограничивать пилотную систему пределами ИТ-подразделения - желательно сразу подключать к ней тех пользователей, которым предстоит активно работать с инфраструктурой после ее полного развертывания [36].
Запуск пилотной системы обычно выполняется в условиях реальной деятельности, но в определенных временных рамках и ограниченной среде (например, на базе нескольких подразделений, отделов или групп пользователей). При этом в выпуске и подписании сертификатов в онлайновом режиме участвует не производственный, а тестовый корневой УЦ. Работа пилотной системы должна быть организована параллельно работе старой системы, возможности и уровень безопасности последней должны поддерживаться на прежнем уровне.
На базе пилотной системы выполняется:
* тестирование всех функциональных требований, производительности и операционных регламентов, а также всех наиболее важных приложений защиты [20];
* процедура пробного завершения работы системы, восстановление ее работы и проверка функционирования системы после этих операций;
* проверка физического и кадрового контроля безопасности в PKI.
Внедрение
После успешной апробации пилотной системы начинается ее внедрение. На этом этапе происходит замена сертификатов тестового корневого УЦ на сертификаты рабочего УЦ и выполняется проверка работоспособности системы PKI с последующими приемными испытаниями. Система оценивается пользователями и соответствующими специалистами на предмет защищенности. Отчет о соответствии всем требованиям безопасности с описаниями тестов атак на систему является одним из главных результатов этого этапа.
Далее проводится юридическая экспертиза и утверждение регламента PKI, положений ППС и установленных форм контрактов. Последним этапом по порядку, но не по значимости, является этап передачи знаний от группы консультантов персоналу, который будет обслуживать систему PKI, без этого практически невозможна поддержка правильного функционирования инфраструктуры. Кроме того, организуется обучение пользователей PKI и создается служба помощи.
Большинство ИТ-проектов терпят неудачу на этапе внедрения в результате превышения стоимости и неправильного планирования времени развертывания. Чаще всего развертывание PKI является частью более крупного проекта и связано с реализацией других решений, например виртуальных частных сетей. Наибольшее влияние на стоимость и успех развертывания оказывают имеющиеся в распоряжении ресурсы и эффективное управление проектом.
Перечислим некоторые характерные ошибки при развертывании PKI:
* отсутствие планирования управления конфигурацией сети в случае изменений (в частности, размещения и связывания друг с другом отдельных компонентов PKI, а также их защиты и организации доступа к ним через маршрутизаторы и межсетевые экраны);
* отсутствие планирования "окон простоя";
* позднее обучение и привлечение к реализации проекта ИТ-персонала, который в дальнейшем будет обслуживать системы PKI;
* составление руководств пользователей без инструкций, объясняющих пользователям, как управлять изменениями в работе своих приложений после развертывания PKI;
* несвоевременное назначение администраторов УЦ и РЦ (их следует назначать до начала развертывания PKI).
Все системы изменяются с течением времени. Установка новых версий, внедрение новых пользовательских приложений, увеличение производительности, мощности и учет новых требований, обновление аппаратной платформы, - все это требует соответствующего управления [20]. Для поддержки, сопровождения и модификации системы PKI формируется подразделение технической поддержки. Результатом этапа является функционирующая PKI, которая соответствует всем требованиям и ограничениям, сформированным в процессе анализа и проектирования системы.
ТЕЛЕГРАМКанал с обзорами, анонсами новинок и книжными подборками
Книжный Вестник
Бот для удобного поиска книг (если не нашлось на сайте)
Поиск книг
Свежие любовные романы в удобных форматах
Любовные романы
О психологии, саморазвитии и личностном росте
Саморазвитие
Детективы и триллеры, все новинки
Детективы
Фантастика и фэнтези, все новинки
Фантастика
Отборные классические книги
Классика
ВКОНТАКТЕБиблиотека с любовными романами, которая наверняка придётся по вкусу женской части аудитории
Любовные романы
Библиотека с фантастикой и фэнтези, а также смежных жанров
Фантастика
Самые популярные книги в формате фб2
Топ фб2
книги