Операционная работа УЦ
Этот раздел необходим в том случае, если организация планирует передать функции УЦ на аутсорсинг. Для оценки надежности и безопасности функционирования УЦ потенциальным поставщикам предлагается описать:
* способы резервного копирования всех данных, включая файлы данных, программное обеспечение приложений и операционную систему. Чтобы система была надежной, критически важно понимание поставщиком требования непрерывности бизнеса, поскольку сложные и интегрированные компоненты PKI некоторых поставщиков усложняют стратегии резервирования;
* порядок регистрации всех событий в системе, включая вход и выход администраторов и пользователей, системные процессы и способ формирования отчета;
* порядок составления расписания (планирование периодов операционной работы и простоя) и информирования об этом заказчика; в ином случае организация не способна поддерживать непрерывность бизнеса;
* средства и процессы по поддержанию круглосуточной надежности (24 часа в сутки 7 дней в неделю) и доступности (99,9%) системы УЦ. Поставщик должен доказать, что способен поддерживать работу с данными клиента на самом высоком уровне надежности и доступности.
Аудит
В этом разделе описываются требования к внешнему аудиту, что касается не только внешних для организации удостоверяющих центров, но и внутренних, поскольку в последнем случае могут контролироваться процессы разработки программного обеспечения. Поставщик должен описать любые виды аудита, выполняемые регулярно внешними сторонами в соответствии со стандартами Международной организации стандартизации ISO. Внешний аудит позволяет гарантировать, что мониторинг операций и процессов выполняется объективно.
Обучение персонала
Этот раздел содержит требования к перечню услуг поставщика, касающиеся помощи в подготовке и обучении персонала организации. Учитывая сложность технологии PKI, поставщик должен:
* предоставить рекомендуемые программы обучения системных администраторов и конечных пользователей; это характеризует комплексность решения поставщика и способствует более точному планированию расходов на обучение ;
* описать объем и содержание курса обучения, который может обеспечить поставщик;
* подготовить руководства по системному администрированию для обучения персонала, документацию на программное обеспечение систем и приложений, чтобы после развертывания инфраструктуры собственный ИТ-штат организации мог самостоятельно, без помощи поставщика, поддерживать систему PKI.
Требования к консультантам
В этом разделе перечисляются требования к отбору консультантов, которые будут выполнять реализацию PKI-решения и/или работу по интеграции с системами заказчика. Поставщик должен предоставить список консультантов, которые будут участвовать в реализации PKI-решения, с указанием должностей и опыта работы. Организации не следует полагаться на то, что любой консультант, присланный поставщиком, может выполнить эту работу. Отбор консультантов должен выполняться на основании тщательного анализа их резюме.
Информация о реализованных поставщиком проектах
Организации необходимо не только изучить информацию, предоставленную заказчиком о реализованных им проектах PKI того же масштаба (скорее всего, это будут примеры успешных проектов), но и самостоятельно связаться с бывшими и настоящими клиентами данного поставщика и выяснить их мнение об опыте взаимодействия с поставщиком.
Лекция 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 может содержать один или более идентификаторов политики в зависимости от числа политик применения сертификатов данного УЦ.