Все системы изменяются с течением времени. Установка новых версий, внедрение новых пользовательских приложений, увеличение производительности, мощности и учет новых требований, обновление аппаратной платформы, - все это требует соответствующего управления [20]. Для поддержки, сопровождения и модификации системы PKI формируется подразделение технической поддержки. Результатом этапа является функционирующая PKI, которая соответствует всем требованиям и ограничениям, сформированным в процессе анализа и проектирования системы.
Лекция 21. Проблемы реализации PKI
Описывается процесс подготовки PKI к работе, подробно рассматривается управление сертификатами и ключами, обсуждаются способы реагирования на инциденты во время функционирования PKI, описываются подходы к решению проблем интеграции и обеспечения работы приложений, дается представление о проблемах предоставления услуг репозитория, выполняется сравнительный анализ структуры стоимости установки и поддержки типичной системы PKI для вариантов инсорсинга и аутсорсинга.
Проблемы реализации
Хотя варианты реализации PKI могут отличаться компонентами и деталями, существуют некоторые главные критерии принятия решений:
* назначение PKI;
* время, необходимое для подготовки к функционированию PKI;
* возможность контроля среды пользователей;
* экспертиза во время и после развертывания;
* финансовые возможности.
Тремя ключевыми областями реализации PKI являются [105]:
1 подготовка системы PKI к работе;
2 управление сертификатами и ключами;
3 реагирование на инциденты во время функционирования PKI.
Подготовка системы PKI к работе
На этапе подготовки системы PKI к работе выполняется установка программного и аппаратного обеспечения УЦ/РЦ, клиентских средств пользователей, а также регистрация и идентификация пользователей для получения сертификатов.
Подготовка системы PKI к работе зависит от выбранной модели развертывания: аутсорсинга или инсорсинга. Как известно, в модели аутсорсинга главные функции УЦ контролируются третьей доверенной стороной. Простейшие аутсорсинговые сервисы обеспечивают доступ ко всем функциям управления жизненным циклом сертификатов через web-страницу и Интернет-соединение, не требуя от организации установки специального аппаратного и программного обеспечения.
В модели инсорсинга функции PKI выполняются под контролем организации, а корневой УЦ, подчиненные удостоверяющие центры и сертификаты создаются внутри корпоративного домена. Это обеспечивает большую гибкость, но предъявляет более строгие требования к уровню безопасности процедур выпуска и хранения корневого сертификата.
Частью процесса подготовки к работе является регистрация пользователей для получения сертификатов. Организация должна решить, какая информация достаточна для аутентификации пользователя. Существуют два основных метода аутентификации:
1 на основе персональной информации (известной только РЦ и пользователю);
2 через схему парольного кода, когда секретный код генерируется до начала регистрации и доставляется субъекту для выполнения процедуры регистрации.
В крупных организациях возникает проблема регистрации большого количества субъектов. Каждый пользователь может проходить регистрацию 2-3 раза в год, если ему необходимо иметь несколько сертификатов. Регистрация вручную, когда каждый запрос попадает в очередь к администратору РЦ, а затем принимается или отвергается, обеспечивает больший контроль, но достаточно трудоемка. Автоматизация процедур сравнения информации, предоставляемой пользователем в процессе регистрации, и информации, хранимой в надежной базе данных, упрощает регистрацию, поэтому для масштабных проектов рекомендуется автоматическая регистрация, хотя она является менее управляемой.
Процесс регистрации конечных субъектов включает два важных шага: обработку запроса на сертификат и аутентификацию субъекта. Для установления идентичности субъекта используются обычные вопросы об имени и адресе заявителя. Требования к персональным данным заявителя зависят от типа запрашиваемого сертификата. В одних случаях для принятия решения о выпуске сертификата открытого ключа достаточно информации, присланной субъектом по электронной почте, в других случаях, когда владелец сертификата наделяется особыми полномочиями, необходимо личное присутствие заявителя и предъявление документов, подтверждающих его личность. Если УЦ создается для служащих одной организации, то от заявителя может потребоваться только обоснование своего запроса на сертификат, так как персональные данные всех служащих имеются в отделе кадров.
Аутентификация субъекта сертификата предполагает подтверждение персональных данных, предоставляемых заявителем при обращении в регистрационный или удостоверяющий центр с запросом о выдаче сертификата. Тщательность проверки идентичности субъекта определяется типом запрашиваемого сертификата. Обычно взаимодействие между заявителем и центром строится на основе соглашения с подписчиком, закрепленного регламентом УЦ. Соглашение может содержать пункты, предусматривающие включение в цену сертификата или предоставление за отдельную плату больших гарантий защиты и дополнительного страхования ущерба.
Управление сертификатами и ключами
Управление сертификатами и ключами - существенный аспект успешной реализации PKI. Проблемы управления особенно актуальны для масштабных PKI с большим количеством владельцев сертификатов и пользователей [79]. К наиболее важным проблемам управления сертификатами и ключами относятся:
* выбор способа управления списками САС ;
* порядок обновления сертификатов ;
* поиск информации о статусе сертификатов;
* выбор способа генерации пары ключей ;
* порядок обновления ключей ;
* выбор способа хранения секретных ключей.
Выбор способа управления списками САС
Для функционирования PKI критически важно правильное управление списками САС: именно они обеспечивают проверку статуса используемого сертификата, так как дата окончания срока действия, указываемая в сертификате, не может служить подтверждением того, что данный сертификат является действительным.
В PKI может поддерживаться один центральный сервис каталогов, предоставляющий информацию о статусе сертификатов, или несколько пунктов распространения сертификатов и списков САС. Организация, использующая PKI, может отделить сервисы аутентификации от сервисов управления сертификатами - в этом случае она, действуя как РЦ, самостоятельно выполняет аутентификацию пользователей и поддерживает защищенность базы данных о своих служащих, а часть функций PKI по выдаче сертификатов, обновлению ключей и возобновлению сертификатов передает на аутсорсинг третьей стороне. В этом случае происходит передача ответственности за выполнение этих функций PKI, и также организация минимизирует свою активность по администрированию инфраструктуры.
Порядок обновления сертификатов
Поскольку большинство сертификатов действуют в течение ограниченного периода времени, система PKI должна поддерживать обновление сертификатов. Сертификат обычно обновляется одним из двух способов:
1 выпускается сертификат с новым сроком действия, но с теми же открытым ключом и регистрационной информацией, которые содержались в старом сертификате;
2 выпускается сертификат с новым сроком действия и новым открытым ключом, но с той же регистрационной информацией, которая содержалась в старом сертификате.
Стратегии обновления должны строиться таким образом, чтобы обеспечить непрерывную работу пользователей. Обычно сертификаты выпускаются с периодом перекрытия сроков их действия от 4 до 6 недель, чтобы обеспечить плавный переход от старого сертификата к новому. Своевременность обновления сертификатов часто зависит от подготовки и квалификации пользователей. Хотя в большинстве PKI-систем существует режим настройки на автоматическое обновление сертификатов по истечении срока их действия, но часто сертификаты обновляются по запросам пользователей. Поэтому для обновления сертификата пользователю необходимо в определенный момент времени подтвердить УЦ свои идентификационные данные и отправить соответствующий запрос.
Некоторую проблему представляет обновление двойной пары ключей, когда пользователь для работы с одним приложением применяет два сертификата: сертификат ключа шифрования и сертификат ключа подписи. В этом случае в момент обновления пользователь должен получить два новых сертификата. При переходе от старых сертификатов к новым количество сертификатов, которыми оперирует пользователь, может увеличиваться до четырех (для одного приложения), в этот период одновременно действуют пара сертификатов с истекающим сроком действия и пара новых сертификатов. Если учитывать, что пользователь может работать с несколькими приложениями, становится ясно, что количество сертификатов, которые необходимо обновлять, постоянно растет. К сожалению, нет простого способа решения этой проблемы, кроме обучения пользователей, технической поддержки и документирования процессов обновления ключей.
