Книга: Инфраструктуры открытых ключей

Лекция 14. Описание политики PKI

Лекция 14. Описание политики PKI

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

Набор положений политики PKI

Общие положения

Набор положений - совокупность положений практики и/или политики PKI, охватывающих круг стандартных тем для формулирования политики применения сертификатов или регламента . Рис. 14.1 иллюстрирует ориентировочный перечень разделов, включаемых в описание ППС или регламента.

Стандарт RFC 2527 Certificate Policy and Certification Practices Framework >[152] не обязывает разработчиков политики или регламента называть разделы определенным образом и не устанавливает никаких правил раскрытия положений политики или регламента. Поэтому перечень разделов можно рассматривать как рекомендательный список, позволяющий эффективно сравнивать различные политики применения сертификатов и регламенты при принятии решений о формировании политики. В наборе положений требуется прямо или косвенно (по ссылке) задавать типы спецификаторов политики и их значения, используемые по умолчанию.

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

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

1обязательства УЦ и/или РЦ:

* уведомление о выпуске сертификата других лиц помимо субъекта сертификата;

* уведомление субъекта сертификата об аннулировании или приостановлении действия его сертификата;

* уведомление других лиц, помимо субъекта сертификата, об аннулировании или приостановлении действия сертификата данного субъекта;

* своевременная публикация сертификатов и информации об аннулировании;

2обязательства подписчика (владельца сертификата):

* точное информирование о цели использования сертификата при обращении к УЦ с запросом о выдаче сертификата;

* сохранение в тайне секретного ключа;

* использование секретного ключа и сертификата с учетом ограничений политики PKI;

* уведомление о компрометации секретного ключа;

3обязательства доверяющей стороны:

* использование сертификата только по назначению;

* соблюдение порядка верификации ЭЦП;

* проверка статуса сертификата перед его использованием;

* подтверждение соответствующих пределов ответственности и гарантий.

Раздел Ответственность содержит положения, позволяющие распределять ответственность между всеми субъектами PKI:

1 гарантии и ограничения на гарантии;

2 виды ущерба: случайный ущерб, ущерб по небрежности, убытки (фактические, косвенные, заранее оцененные, штрафные), мошенничество;

3 непризнание ущерба;

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

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

Рис. 14.1.  Набор положений политики PKI

Правовые положения и процедуры решения споров, имеющие отношение к интерпретации и исполнению ППС или регламента, содержатся в одноименном разделе Интерпретация и правоприменение.

В разделе Плата за услуги излагается политика компенсации и перечисляются виды услуг, за которые взимается плата с клиентов удостоверяющего и регистрационного центров (выпуск и повторный выпуск сертификата, доступ к сертификату и к информации о статусе сертификата, информирование о политике УЦ и др.).

Раздел Публикация и репозитории содержит обязательства УЦ публиковать информацию о ППС и регламенте, сертификатах и их статусе, а также контролировать доступ к объектам публикуемой информации, информацию о частоте публикации и требования к репозиториям, управляемым УЦ или другими независимыми сторонами.

В раздел Аудит деятельности субъектов включены следующие положения:

1 частота проверок для каждого субъекта PKI;

2 личность/квалификация аудитора;

3 отношение аудитора к субъекту;

4 действия, предпринимаемые после обнаружения нарушений в деятельности субъекта;

5 обеспечение и разделение ответственности за нарушения субъекта.

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

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

Специальные разделы

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

* начальная регистрация;

* обычное обновление ключа;

* повторный выпуск ключа после аннулирования;

* запрос об аннулировании ключа.

Подраздел Начальная регистрация содержит положения, относящиеся к процедурам идентификации и аутентификации во время регистрации субъекта или выпуска сертификата:

1 типы имен, присваиваемых субъекту;

2 регулирование многозначности имен;

3 правила интерпретации различных форм имени;

4 регулирование уникальности имен;

5 признание, аутентификация и роль торговых марок;

6 регулирование обязанности субъекта доказывать владение секретным ключом, составляющим пару с зарегистрированным открытым ключом;

7 требования аутентификации организационной принадлежности субъекта (УЦ, РЦ или конечный субъект);

8 требования аутентификации лица, действующего от имени субъекта, в том числе:

* необходимое количество составляющих идентификации;

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

* условия персонального представления физического лица при аутентификации в удостоверяющем или регистрационном центре;

* условия аутентификации юридического лица.

Подразделы Обычное обновление ключа, Повторный выпуск ключа после аннулирования и Запрос об аннулировании описывают процедуры идентификации и аутентификации каждого субъекта (УЦ, РЦ и конечный субъект) при обычном обновлении ключа, повторном выпуске сертификата и обработке запроса об аннулировании сертификата.

Структура раздела Операционные требования представлена на рис. 14.2. В каждом подразделе формулируются требования ко всем субъектам PKI по различным видам операционной активности.

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

Рис. 14.2.  Структура раздела "Операционные требования"

Подраздел Прекращение деятельности УЦ описывает порядок прекращения деятельности удостоверяющего и регистрационного центров и уведомления об этом всех заинтересованных сторон.

Подраздел Приостановление и аннулирование сертификата определяет:

1 условия аннулирования сертификата;

2 круг лиц, имеющих право подавать запрос об аннулировании сертификата субъекта;

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

4 условия приостановления действия сертификата;

5 круг лиц, имеющих право подавать запрос о приостановлении сертификата субъекта;

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

7 срок приостановления;

8 частоту выпуска САС;

9 требования к доверяющим сторонам по проверке САС;

10 другие формы объявления об аннулировании сертификата;

11 требования к доверяющим сторонам по проверке других форм объявления об аннулировании сертификата;

12 любые варианты перечисленных выше условий, если приостановление или аннулирование вызваны компрометацией секретного ключа.

Подраздел Контроль безопасности используется для описания систем контроля и регистрации событий, обеспечивающих безопасность среды, и включает следующие элементы:

1 типы регистрируемых событий;

2 частота обработки или проверки контрольных журналов;

3 срок хранения контрольных журналов;

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

5 процедуры создания резервных копий контрольных журналов;

6 характеристика системы накопления данных контрольного журнала (внутренняя или внешняя по отношению к субъекту);

7 уведомление об акции контроля субъекта, виновного в нарушении;

8 оценки уязвимости.

Подраздел Архивные записи регламентирует порядок хранения записей в архиве и описывает:

1 типы фиксируемых событий;

2 срок хранения в архиве;

3 защита архива (лица, имеющие доступ к архиву; защита от модификации и уничтожения);

4 процедуры создания резервной копии архива;

5 требования проставления метки времени записей;

6 характеристика системы сбора архива (внутренняя или внешняя);

7 процедуры получения и проверки архивной информации.

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

Подраздел Прекращение деятельности УЦ описывает порядок прекращения деятельности удостоверяющего и регистрационного центров и уведомления об этом всех заинтересованных сторон.

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

Подраздел Контроль физической безопасности задает требования к физической безопасности оборудования систем субъектов PKI:

1 местонахождение и конструкция узла;

2 физический доступ;

3 электропитание и кондиционирование;

4 контроль риска затопления;

5 пожарная охрана и защита;

6 защита среды хранения системы;

7 размещение отходов.

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

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

2 процедуры проверки уровня благонадежности и компетентности другого персонала, включая штат охраны;

3 требования и процедуры подготовки для каждой должности;

4 срок и процедуры переподготовки для каждой должности;

5 частота и последовательность смены деятельности внутри должностей;

6 санкции, применяемые к персоналу за несанкционированные действия, превышение полномочий и несанкционированное использование систем субъектов;

7 управление персоналом, работающим по контракту (подписание контракта, требования контракта, аудит и мониторинг деятельности, другие виды контроля);

8 инструкции по работе персонала.

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

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

Рис. 14.3.  Структура раздела "Контроль технической безопасности"

Подраздел Контроль компьютерной безопасности описывает элементы управления компьютерной безопасностью: использование концепции надежной компьютерной базы, дискреционное и мандатное управление доступом, метки, повторное использование объекта, достоверный маршрут, аудит, идентификацию и аутентификацию, тестирование безопасности и вторжений.

Подраздел Генерация и инсталляция пар ключей раскрывает для всех типов субъектов PKI следующие положения:

1 генерация открытого и секретного ключей субъекта;

2 способы доставки:

* секретного ключа субъекту,

* открытого ключа субъекта издателю сертификата,

* открытого ключа УЦ пользователям;

3 размеры ключа;

4 генерация параметров открытого ключа и проверка качества параметров;

5 способ генерации ключа (аппаратный или программный);

6 назначение ключа и ограничения на его использование.

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

Подраздел Другие аспекты управления ключами определяет порядок хранения в архиве открытых ключей всех субъектов PKI, агента хранения в архиве, меры контроля безопасности системы хранения ключей в архиве, а также сроки использования (период активного жизненного цикла) открытого и секретного ключей. В подразделе Данные активации для всех субъектов PKI описывается жизненный цикл данных активации - от генерации до хранения в архиве. К данным активации относятся данные (кроме ключей), необходимые для работы криптографических модулей.

Подраздел Контроль безопасности жизненного цикла посвящен управлению разработкой систем и безопасностью среды. Управление разработкой систем включает безопасность среды разработки, безопасность персонала, занимающегося разработкой, безопасность управления конфигурацией во время технической поддержки продукта, практику инженерии и методологию разработки программного обеспечения, модульность, разбиение на слои, использование определенных методов реализации (оборонительное программирование), безопасность средств разработки. Управление безопасностью среды заключается в выполнении процедур, гарантирующих поддержание заданной безопасности операционных систем и сетей. Эти процедуры реализуют проверку программного, программно-аппаратного и аппаратного обеспечения безопасности.

Подраздел Контроль сетевой безопасности регулирует управление сетевой безопасностью среды.

Подраздел Управление прикладным криптографическим модулем описывает следующие аспекты разработки криптографического модуля: идентификацию границ криптографического модуля, ввод/вывод, функции и сервисы, конечный автомат, физическую безопасность, безопасность программного обеспечения и операционной системы, согласованность алгоритма. Требования могут быть выражены ссылкой на определенный стандарт.

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

Раздел Администрирование спецификации регламентирует порядок описания конкретной политики или регламента и задает процедуры изменения спецификации, публикации и уведомления, а также утверждения регламента.

Подраздел Процедуры изменения спецификации содержит следующие элементы:

1 список компонентов, подкомпонентов спецификации и/или их элементов, которые можно изменять без уведомления об этом заинтересованных сторон, не меняя идентификатор объекта ППС ( Object Identifier ) или указатель регламента ;

2 список компонентов, подкомпонентов спецификации и/или их элементов, которые можно изменять после уведомления об этом заинтересованных сторон, не меняя идентификатор объекта ППС ( Object Identifier ) или указатель регламента ;

3 список компонентов, подкомпонентов спецификации и/или их элементов, для которых требуется внесение изменений в идентификатор объекта ППС ( Object Identifier ) или указатель регламента.

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

Перечень набора положений может служить контрольным списком или стандартным образцом для разработчиков ППС или регламента. Такой перечень можно использовать при сравнении:

* двух регламентов ;

* двух политик применения сертификатов на предмет их соответствия во время кросс-сертификации;

* регламента и описания политики для подтверждения того, что регламентов полностью реализует политику.

Трудности разработки политики и регламента

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

В результате документы, описывающие политику PKI, создаются людьми, которые не представляют целостной картины функционирования PKI и опираются на свои предположения и допущения. Встречающиеся в тексте документов неточности и положения, которые можно толковать двояко, подвергают серьезному риску всех субъектов PKI. Например, недооценка важности правильного выбора предельных сумм транзакций может иметь радикальные последствия: если предел установлен слишком низким, необходимые для ведения бизнеса транзакции могут быть отвергнуты, если предел слишком высок, PKI подвергается риску. Лучшим решением при отсутствии специалистов необходимой квалификации является привлечение центра утверждения политики (Policy Approval Authority) - организации, интегрирующей все составляющие политики и руководства в процессе выработки политики PKI (в России такая организация пока не создана).

Среди разработчиков политики PKI широко распространено мнение, что полезность описывающих политику документов напрямую зависит от их объема и степени подробности содержания. Например, политика применения сертификатов, разработанная компанией VeriSign для PKI Trust Network, излагается на 115 страницах, а регламентов занимает 119 страниц >[10]. Более того, эти документы изобилуют юридической лексикой. Совершенно ясно, что документы такого объема и сложности находятся за пределами возможностей понимания среднего человека (субъекта или доверяющей стороны) и затрудняют разбор конфликтных ситуаций в суде. Некоторые компании, предоставляющие услуги PKI, поняли это и ищут альтернативные пути разработки более жизнеспособных документов. Так, например, компания VeriSign для сопровождения больших документов предлагает CPS Quick Summary - краткое изложение регламента. Краткое изложение делает документ более понятным для среднего человека, что повышает шансы компании выиграть в суде в случае конфликта между сторонами - субъектами PKI.

Этапы разработки политики применения сертификатов

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

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

Затем выполняется анализ данных и приложений организации, которые нуждаются в защите, оценка угроз этим данным и рисков. Рассматриваются возможные последствия компрометации безопасности: компрометация секретных данных клиентов, разглашение информации, дающее преимущества конкурентам, ущерб в результате раскрытия информации о финансовых транзакциях. Разработка ППС невозможна без обсуждения этих моментов.

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

Рис. 14.4.  Этапы разработки политики применения сертификатов

Если спектр задач и требований конфиденциальности организации слишком велик, то целесообразно разрабатывать несколько политик. Рассмотрим случай, когда компании необходимо осуществлять финансовые платежи на сумму свыше 1 млн долларов и одновременно поддерживать виртуальную частную сеть для оформления сделок, которые заключаются служащими компании, занимающимися продажами >[70]. Конкурентам могут быть интересны полные данные об обороте этой компании, но полезность информации о сделках, заключенных одним продавцом, относительно мала. Политика, которая регулирует применение VPN-сертификатов продавцов, может быть гораздо менее строгой. Рассматриваемая компания не сможет хорошо обслуживаться одной политикой. Если ППС адекватно регулирует использование сертификатов продавцов, то будет подвергаться риску работа бухгалтеров, отвечающих за финансовые транзакции. Если же ППС обеспечивает гарантии безопасного выполнения финансовых транзакций, то выпуск сертификатов для продавцов становится сложным и дорогостоящим. Компания может либо реализовать две разные политики для удовлетворения требований каждого сообщества, либо поддерживать обе в соответствии с более высоким уровнем безопасности. Компании следует проанализировать издержки и доход от реализации каждой стратегии и решить, нужны ли ей две разные политики. Эта информация также может быть полезна для анализа издержек и дохода при страховании ответственности. Оператор УЦ может поддерживать политику страхования в отношении ошибок и оплошности персонала УЦ. Если ценность данных высока или приложения пересекают границы организации, то страхование ответственности должно быть соответствующим.

Второй этап разработки ППС - ознакомление с документом RFC 2527 >[152], задающим структуру ППС, и несколькими образцами используемых политик, отвечающих аналогичным (проектируемой политике) требованиям. Если ожидается, что проектируемая PKI будет устанавливать отношения кросс-сертификации с другими PKI, то необходимо изучить профили сертификатов и списков САС этих инфраструктур. Разрабатывая новый профиль сертификатов с учетом профилей сертификатов будущих партнеров, можно избежать проблем функциональной совместимости в дальнейшем. Ключевыми моментами согласования являются криптографические алгоритмы, критичные дополнения и способы распространения информации об аннулировании сертификатов.

Третий этап - разработка проекта одной или нескольких политик применения сертификатов, релевантных требованиям организации. В примере, приведенном выше, имеет смысл для обеспечения безопасности работы бухгалтеров компании использовать сильные аппаратные криптографические модули, а для защиты операций продавцов - программные криптографические модули. Кроме того, ППС может содержать требование выдавать сертификаты бухгалтерам через службу безопасности компании в их личном присутствии, но при этом допускать рассылку сертификатов продавцам по почте (если, например, организация имеет филиалы).

Четвертый этап - это принятие решения об организации собственного УЦ или использовании услуг стороннего УЦ. Организация инсорсингового УЦ требует гораздо больших затрат, чем аутсорсинг. Экономически более выгодным решением может быть передача одних функций стороннему УЦ и выполнение других функций, например, РЦ или репозитория, своими силами.

Если организация принимает решение о создании собственного УЦ, то необходимо выбрать такие продукты PKI, которые пригодны для реализации конкретной политики. Выбранный продукт должен удовлетворять всем требованиям, изложенным в таких разделах ППС, как Идентификация и аутентификация, Операционные требования и Технический контроль безопасности. Если не все требования будут учтены, то персоналу УЦ впоследствии придется реализовывать сложные процедуры для преодоления "узких" мест PKI-продукта. Дополнительная сложность регламента повлечет за собой большие затраты на поддержание функционирования.

Завершающим этапом разработки ППС является составление регламента. Если организация создает свой собственный УЦ, то регламент идентифицирует сайты, которые будут использоваться PKI, и устанавливает соответствие между ролями, описанными ППС, и ролями и процедурами, поддерживаемыми PKI-продуктом и средствами физического контроля. Если используется аутсорсинг, то поставщик услуг должен продемонстрировать, что средства контроля и процедуры регламента его УЦ удовлетворяют требованиям ППС данной организации.

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

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

Оглавление книги