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

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

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

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

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