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

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

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

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-сертификатов продавцов, может быть гораздо менее строгой. Рассматриваемая компания не сможет хорошо обслуживаться одной политикой. Если ППС адекватно регулирует использование сертификатов продавцов, то будет подвергаться риску работа бухгалтеров, отвечающих за финансовые транзакции. Если же ППС обеспечивает гарантии безопасного выполнения финансовых транзакций, то выпуск сертификатов для продавцов становится сложным и дорогостоящим. Компания может либо реализовать две разные политики для удовлетворения требований каждого сообщества, либо поддерживать обе в соответствии с более высоким уровнем безопасности. Компании следует проанализировать издержки и доход от реализации каждой стратегии и решить, нужны ли ей две разные политики. Эта информация также может быть полезна для анализа издержек и дохода при страховании ответственности. Оператор УЦ может поддерживать политику страхования в отношении ошибок и оплошности персонала УЦ. Если ценность данных высока или приложения пересекают границы организации, то страхование ответственности должно быть соответствующим.