Ольга Полянская - Инфраструктуры открытых ключей

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

Карты PCMCIA. Ключ защищенно хранится на карте с микрочипом, но при вводе в систему "покидает" карту, следовательно, становится уязвимым для хищения.

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

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

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

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

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

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

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

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

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

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