Политика безопасности и способы ее реализации

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

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

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

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

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

Компания могла бы усовершенствовать реализацию своей политики, усиливая механизмы безопасности или процедуры, или и то и другое вместе. Установка дополнительного турникета гарантировала бы проход в здание по каждой предъявленной карте только одного человека. Используя считыватель с дополнительной клавиатурой, компания могла бы требовать от сотрудников группы проектирования для прохода в здание не только пользоваться картой, но и вводить PIN-код. В этом случае задача злоумышленника усложняется: чтобы получить возможность пройти в здание, необходимо достать карту и узнать PIN-код пользователя. Следующим усовершенствованием может быть добавление к считывателю карт биометрического устройства, тогда злоумышленнику потребуется отпечаток пальца или рисунок сетчатки глаза сотрудника, имеющего право доступа.

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

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

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

* соответствие общей корпоративной политике безопасности ;

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

* доступность изложения;

* разграничение ответственности между субъектами PKI;

* адекватность ограничений и пределов ответственности требованиям сферы приложения сертификатов.

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

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

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

Как определено стандартом организации IETF RFC 2527 Certificate Policy and Certification Practices Framework , основными документами, описывающими политики и процедуры, связанные с PKI, являются политика применения сертификатов (ППС) и регламент УЦ. Эти документы имеют одинаковый формат, но разное назначение, и адресованы разным лицам. Документ о политике применения сертификатов можно сравнить с ответом на вопрос "что?", а регламент - с ответом на вопрос "как?" в отношении безопасного использования сертификатов. Они позволяют согласовывать политики разных организаций, хотя объем и сложность большинства документов, содержащих ППС и регламент, делают этот процесс достаточно трудоемким.

 

Политика применения сертификатов

В соответствии с международным стандартом ISO/IEC 9594-8/ITU-T Recommendation X.509 под политикой применения сертификатов понимается установленный набор правил, характеризующих возможность применения сертификатов определенным сообществом субъектов и/или классом приложений с определенными требованиями безопасности. Политика применения сертификатов (ППС) - это документ, описывающий политику безопасности в отношении выпуска сертификатов и распространения информации о статусе сертификатов. Эта политика безопасности регламентирует операционную работу УЦ, а также регулирует ответственность пользователей при получении и использовании сертификатов и ключей. ППС гарантирует защищенность всего жизненного цикла сертификатов, начиная от их генерации и заканчивая аннулированием или истечением срока действия.

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

ППС не содержит подробного описания того, как реализуется политика безопасности. Например, ППС может содержать следующее положение: "Каждый подписчик должен лично пройти процедуру идентификации в РЦ, прежде чем для него будет выпущен сертификат", не конкретизируя процедуру регистрации. ППС является долговременным документом и не описывает операции детально, поэтому с течением времени они могут меняться, а политика по-прежнему останется актуальной (на протяжении десяти лет и более).

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

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

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

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

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

 

Регламент удостоверяющего центра

Термин регламент удостоверяющего центра (Certification Practice Statement - CPS) был введен в 1995 году в проекте директив Американской ассоциации юристов (American Bar Association) как "заявление о практике выпуска сертификатов удостоверяющим центром". Регламент подробно описывает систему и практику работы УЦ с сертификатами. В регламенте могут фиксироваться положения договора между УЦ и подписчиками. Регламент четко формулирует обязанности УЦ перед доверяющей стороной. Лицо, полагающееся на сертификат при проверке цифровой подписи, должно знать или получать информацию о содержании сертификата. Этим обусловлено требование включения в сертификат ссылки на регламент УЦ, выпустившего данный сертификат. Регламент должен отражать соответствие практики УЦ общепризнанным стандартам: только в этом случае может быть оценена пригодность и принципиальная совместимость сертификатов, выпущенных УЦ, с другими системами применения сертификатов.

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

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

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

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

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

|Документ | Формулировка |

|ППС | Физический доступ к аппаратному обеспечению УЦ разрешен только лицам, ответственным за техническую поддержку системы |

|Регламент | Для гарантирования физической безопасности аппаратного обеспечения УЦ должны соблюдаться следующие меры контроля: вход в помещение, где размещается аппаратура УЦ, - только по два человека; контроль доступа в помещение - биометрический; наблюдение за помещением - 24 часа в сутки 7 дней в неделю (по системе 24/7) |

|Организационные процедуры | Аппаратное обеспечение УЦ размещается в помещении с IT-блокировкой на … этаже офиса … на улице …. Дверь защищается замком и устройством биометрической аутентификации. Ключи раздаются лицам, перечисленным в списке (приложение А ), биометрические профили создаются только для этих лиц. Камеры на северной стене над входом в помещение и на западной стене за огнетушителем выполняют наблюдение под управлением пульта безопасности 24 часа в сутки 7 дней в неделю |

Таблица 13.1.Сравнительная характеристика формулировок документов, описывающих одно положение политики PKI

 

Идентификаторы объектов

При принятии решения об использовании данного сертификата для конкретной цели и доверии к нему пользователь может ориентироваться на указатель ППС в сертификате формата X.509 версии 3. Таким указателем, характеризующим политику применения сертификатов, является уникальный зарегистрированный идентификатор объекта Object Identifier. Идентификаторы объектов - это один из простых типов данных, определяемых абстрактной синтаксической нотацией ASN.1. Идентификатор объекта задается последовательностью целочисленных компонентов (например, 1.3.6.1.4.1.6943 ), которая уникально идентифицирует объект (алгоритм, тип атрибута и т.п.) или центр регистрации идентификаторов.

Регистрация идентификаторов объектов выполняется в соответствии с процедурами, определенными стандартами Международной организации стандартизации (ISO), Международной электротехнической комиссии (IEC) и Международным союзом по телекоммуникациям (ITU). Сторона, регистрирующая Object Identifier, публикует текстовую спецификацию ППС для ознакомления с ней пользователей сертификатов. Каждый УЦ аккредитуется с учетом заявленных им политик, которые считаются базовыми. Перечень заявленных политик указывается в сертификате этого центра. Существует система международных, национальных и корпоративных центров регистрации. Во многих странах национальные организации стандартизации поддерживают регистр идентификаторов объектов. Центры регистрации идентификаторов создают иерархию идентификаторов объектов и гарантируют уникальность каждого идентификатора в общей системе. Каждый центр определяет смысл значений Object Identifier данной последовательности компонентов и несет ответственность за все последовательности компонентов, начиная с данной последовательности . Центр может делегировать полномочия другому подчиненному центру регистрации идентификаторов.

Идентификаторы объектов часто применяют в сертификатах X.509 для:

* отображения криптографических алгоритмов (например, алгоритм SHA-1 с RSA имеет идентификатор 1.2.840.113549.1.1.5.);

* задания атрибута имени в отличительном имени субъекта;

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

* указания расширенного назначения ключа;

* задания дополнений сертификатов и списков САС.

Модель доверия стандарта X.509 предполагает анализ идентификаторов ППС при обработке пути сертификации.

|Object Identifier 1.2.643.3.15.1 | Политика применения сертификатов ЗАО "Цифровая подпись" |

|1.2.643.3.15.1.1 | Общее использование в PKI без права заверения финансовых документов |

|1.2.643.3.15.1.2 | Оформление соглашений, договоров |

|1.2.643.3.15.1.3 | Организация внутрикорпоративного документооборота |

|1.2.643.3.15.1.5 | Закрепление авторских прав |

|1.2.643.3.15.1.7 | Использование в системах электронной коммерции |

Таблица 13.2.Примеры идентификаторов политик применения сертификата

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

 

Отображение политики в сертификатах

Конечно, большинство пользователей не изучают непосредственно ППС и регламент, а получают информацию о политиках PKI косвенно, из таких дополнений сертификатов, как Certificate Policies, Policy Mappings и Policy Constraints, характеризующих соответственно политики применения сертификатов, соответствие политик разных доменов PKI и ограничения на политики. Каждый идентификатор объекта (в данном случае в качестве объекта выступает политика), указанный в дополнении сертификата, соответствует одной ППС. При разработке ППС ей присваивается уникальный идентификатор объекта. В рамках присвоенного идентификатора допускается лишь незначительное изменение политики. Процедура изменения и способ получения последней информации о ППС содержится в самой политике. Регламенты привязываются к идентификаторам политики через ППС, которую они реализуют. ППС может быть реализована в нескольких регламентах, а один регламент может удовлетворять требованиям нескольких политик.

Рис. 13.1.  Реализация одной политики тремя центрами

Пример 13.2. Рассмотрим связи между ППС и регламентами трех разных удостоверяющих центров одной корпоративной PKI, которые выпускают сертификаты в соответствии с одной политикой (). Каждый УЦ выпускает свои сертификаты согласно политике компании "Альфа" (PАльфа). Все эти сертификаты содержат один и тот же идентификатор политики в дополнении Certificate Policies. Но каждый УЦ имеет свой собственный регламент, который описывает механизмы и процедуры безопасности, характерные именно для этого центра.

Механизмы безопасности удостоверяющих центров выбираются в зависимости от используемых подразделениями компании программных и аппаратных средств, что, в свою очередь, определяет выбор PKI-продуктов. Каждый УЦ может использовать выбранные независимо от других удостоверяющих центров средства физического контроля, программное обеспечение и процедуры идентификации, обеспечивая при этом необходимый уровень безопасности. Все пользователи компании "Альфа" на основании указанных в сертификатах идентификаторах политики будут принимать решения, подходят ли эти сертификаты для их целей.

Рис. 13.2.  Реализация двух политик тремя центрами

Пример 13.3. Для поддержки широкого круга приложений корпоративная PKI может выпускать сертификаты в соответствии с несколькими политиками. Рассмотрим ситуацию, когда компания "Альфа" использует две политики . УЦ подразделения 1 выпускает сертификаты согласно политике P 1 , УЦ подразделения 2 - согласно политике P 2 , а УЦ подразделения 3 - в соответствии с одной из политик ( P 1 или P 2 ) или согласно обеим политикам P 1 и P 2 (). Выпуск сертификата для каждой из двух политик целесообразен в том случае, когда каждая политика соответствует приложению определенного типа (например, защищенная электронная почта или подписание электронных договоров). Кроме того, политики могут быть ориентированы на разный уровень гарантий, то есть политика P 1 может иметь низкий уровень гарантий, а политика P 2 - высокий. В этом случае сертификат пользователя должен содержать идентификатор либо политики P 1 , либо P 2 , но не обеих политик. Приложения для сферы с низкими рисками могут принимать сертификаты, выпущенные в соответствии с политикой P 1 или P 2 , а приложения для сферы с высокими рисками могут требовать сертификаты, изданные согласно политике P 2 .

Ни один пользователь не может знать все существующие идентификаторы политик. Пользователь обычно знаком с ограниченным набором политик, которые используются его локальным УЦ или корпоративной PKI. Этот набор политик называют доменом политик пользователя.

Пример 13.4. Для пользователей А и B компании "Альфа" их домен политик образуют политики P 1 и P 2 . Другие корпоративные PKI могут придерживаться политик, которые эквивалентны политикам домена политик пользователей А и B. Допустим, компания "Бета" имеет один УЦ, который выпускает сертификаты в соответствии с тремя политиками P выс , P ср и P низ , соответствующими разным уровням безопасности (высокому, среднему и низкому). Если пользователи А и B при работе сталкиваются с сертификатами стороннего УЦ, то не способны интерпретировать соответствующие идентификаторы политик и, следовательно, определить, какие сертификаты применимы к их приложениям .

Рис. 13.3.  Соответствие политик двух компаний

УЦ "Альфа" может перевести информацию о политиках других доменов в информацию, понятную своим пользователям, при помощи дополнения Policy Mappings (соответствие политик) в своем сертификате. Компания "Альфа" может установить следующее соответствие политик: политика P выс ( "Бета" ) эквивалентна политике P 2 ( "Альфа" ), а политики P ср и P низ ( "Бета" ) эквивалентны политике P 1 ( "Альфа" ). Компания "Бета", в свою очередь, может признать политику P 1 ( "Альфа" ) соответствующей политике P низ ( "Бета" ), политику P 2 ( "Альфа" ) соответствующей политике P ср ( "Бета" ), но считать, что ни одна из политик компании "Альфа" не соответствует требованиям политики P выс ( "Бета" ). В результате приложения, для которых подходят сертификаты компании "Бета" с указанием политики P выс , не смогут работать с сертификатами компании "Альфа".

демонстрирует одно из ключевых свойств соответствия политик: взаимное отображение политик разных компаний может быть несимметричным. Компании "Альфа" и "Бета" не должны согласовывать соответствие политик. Пользователи сертификатов каждой компании будут обрабатывать дополнение Policy Mappings в сертификате их собственного УЦ и полагаться на информацию о соответствии политик, предоставляемую удостоверяющими центрами их собственного домена политик.

 

Краткая характеристика политики PKI

Реальной альтернативой объемным документам, подробно описывающим политику PKI, может стать краткая характеристика политики - документ PDS (PKI Disclosure Statement) . Документ PDS возник как проект группы инженерной поддержки Интернета IETF, затем Американская ассоциация юристов (American Bar Association - ABA) воплотила его идею в соответствующее приложение к своему руководству по оценке инфраструктур открытых ключей - PKI Evaluation Guidelines. Аналогичный документ был разработан также техническим комитетом по безопасности Европейского института стандартов связи (European Telecommunications Standards Institute - ETSI).

Документ, кратко раскрывающий политику PKI, должен занимать не более 2 страниц, в отличие от ППС и регламента, которые обычно излагаются на 8-10 и 40-80 страницах соответственно. PDS описывает самые существенные аспекты деятельности PKI: гарантии, ограничения и юридическую ответственность сторон, он может служить контрольным списком для проверки соответствия практик безопасности двух удостоверяющих центров до вступления их в доверительные отношения. В целом документ PDS больше похож на соглашение с конечным пользователем или владельцем пластиковой карты, чем на обычный документ о политике. Действительно, пользователя среднего уровня подготовки обычно интересует его ответственность в различных ситуациях, а отнюдь не используемые криптографические методы или специфические меры безопасности PKI. Например, тот факт, что для хранения секретного ключа УЦ используется аппаратный ключ (токен), скорее всего, привлечет внимание лишь ограниченного круга лиц, а вот положение об ответственности доверяющей стороны за проверку валидности используемых сертификатов до проведения транзакции заинтересует всех субъектов PKI.

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

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

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