Ольга Полянская - Инфраструктуры открытых ключей

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

Управление проектом

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

Архитектура безопасности

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

* способы контроля хранения ключей подписи корневого УЦ на аппаратных устройствах в соответствии с высшим уровнем безопасности, предусмотренным стандартами для аппаратного устройства коммерческого назначения;

* способы защиты коммуникаций между разными компонентами решения, поскольку многие PKI-решения строятся по модульному принципу;

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

Политика безопасности

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

* способы делегирования полномочий администраторов УЦ или РЦ;

* методы управления паролями (длина пароля; поддержка истории паролей; подсчет неудачных попыток ввода пароля), поскольку некоторые поставщики, прежде чем пользователь получит сертификат, используют пароли для защиты секретного ключа сертификата или в качестве временного метода контроля доступа;

* методы аутентификации и контроля доступа для защиты ресурсов администраторов PKI;

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

Стандарты и руководства по проектированию безопасности

В комплексных приложениях бывает необходимо сопоставлять условия фактического проекта и спецификации безопасности аппаратного или программного обеспечения поставщика. Этот раздел может быть опущен, если достаточно раздела " Архитектура безопасности ". С другой стороны, для оценки уровня квалификации поставщика могут изучаться процессы разработки программного обеспечения, схемы классификации информации и выполняться аудит кодов. Организация обычно предъявляет требования функциональной совместимости с рядом стандартов. Чем больше технология поставщика соответствует стандартам, тем легче выполняется интеграция и настройка на требования заказчика. В предложениях поставщик должен указать, поддерживает ли его решение такие открытые стандарты, как PKIX, X.509.v2, X.509.v3, OCSP, X.500, PKCS и криптографические алгоритмы RSA, ECC, DES, 3DES, RC4, AES, MD5, SHA-1 и др.

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

Операционная работа УЦ

Этот раздел необходим в том случае, если организация планирует передать функции УЦ на аутсорсинг. Для оценки надежности и безопасности функционирования УЦ потенциальным поставщикам предлагается описать:

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

* порядок регистрации всех событий в системе, включая вход и выход администраторов и пользователей, системные процессы и способ формирования отчета;

* порядок составления расписания (планирование периодов операционной работы и простоя) и информирования об этом заказчика; в ином случае организация не способна поддерживать непрерывность бизнеса;

* средства и процессы по поддержанию круглосуточной надежности (24 часа в сутки 7 дней в неделю) и доступности (99,9%) системы УЦ. Поставщик должен доказать, что способен поддерживать работу с данными клиента на самом высоком уровне надежности и доступности.

Аудит

В этом разделе описываются требования к внешнему аудиту, что касается не только внешних для организации удостоверяющих центров, но и внутренних, поскольку в последнем случае могут контролироваться процессы разработки программного обеспечения. Поставщик должен описать любые виды аудита, выполняемые регулярно внешними сторонами в соответствии со стандартами Международной организации стандартизации ISO. Внешний аудит позволяет гарантировать, что мониторинг операций и процессов выполняется объективно.

Обучение персонала

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

* предоставить рекомендуемые программы обучения системных администраторов и конечных пользователей; это характеризует комплексность решения поставщика и способствует более точному планированию расходов на обучение ;

* описать объем и содержание курса обучения, который может обеспечить поставщик;

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

Требования к консультантам

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

Информация о реализованных поставщиком проектах

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

Лекция 20. Проектирование и внедрение PKI

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

Проектирование