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

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

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

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

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

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

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

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