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

Реагирование на инциденты во время функционирования PKI

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

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

Аннулирование

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

В PKI имеется несколько возможностей выявления и проверки аннулированных сертификатов:

* валидация в режиме реального времени (по протоколу OCSP), которая необходима при выполнении наиболее важных транзакций, например финансовых;

* проверка с запаздыванием, которая подходит для менее важных транзакций, таких как доступ к корпоративным порталам интрасети или экстрасети (в этом случае САС обновляется в течение суток).

Порядок обработки запросов об аннулировании

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

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

Выбор способа публикации САС

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

Публикация САС с опросом наличия изменений ("pull") выполняется в определенные запланированные моменты времени и может привести к ситуации, когда аннулированный сертификат некоторое время не включается в САС, а пользователи продолжают полагаться на него. Данный способ пригоден в большинстве случаев, но подвергает серьезному риску клиентов, которые используют критически важные для ведения бизнеса приложения, даже если планируемые обновления выполняются достаточно часто.

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

Важным преимуществом способа онлайновой верификации является своевременность доставки (в реальном времени) информации об аннулировании сертификатов. Этот способ предпочтителен для обслуживания приложений, требующих обязательной проверки сертификатов до выполнения транзакции. Способ онлайновой верификации устанавливает жесткие требования постоянной защищенности OCSP-сервера и заверения всех запросов к УЦ цифровыми подписями, что может создать "узкие места" при обработке запросов.

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

Восстановление, резервное копирование и хранение ключей в архиве

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

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

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

Депонирование

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

Любая организация, использующая PKI для критически важных целей бизнеса, должна обеспечивать выпуск двойных сертификатов (шифрования и подписи) и депонирование ключей шифрования >[10]. Большинство систем PKI (даже аутсорсинговых) поддерживают депонирование секретных ключей шифрования и их хранение в собственной сети организации. Типичным способом поддержки неотказуемости является использование симметричного ключа для шифрования секретного ключа, а затем шифрование симметричного ключа при помощи открытого ключа УЦ. Если РЦ обращается с запросом о восстановлении депонированного ключа, то УЦ должен расшифровать симметричный ключ и отправить его РЦ. Только в этом случае РЦ может восстановить необходимый секретный ключ. Сам УЦ не может восстанавливать депонированные ключи, так как не имеет доступа к базе данных ключей шифрования и способен только расшифровать симметричный ключ.

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

Выбор способа и агента депонирования ключей

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

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

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

Планы реагирования на катастрофы и восстановления работы системы

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

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

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