Лекция 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-систем существует режим настройки на автоматическое обновление сертификатов по истечении срока их действия, но часто сертификаты обновляются по запросам пользователей. Поэтому для обновления сертификата пользователю необходимо в определенный момент времени подтвердить УЦ свои идентификационные данные и отправить соответствующий запрос.
Некоторую проблему представляет обновление двойной пары ключей, когда пользователь для работы с одним приложением применяет два сертификата: сертификат ключа шифрования и сертификат ключа подписи. В этом случае в момент обновления пользователь должен получить два новых сертификата. При переходе от старых сертификатов к новым количество сертификатов, которыми оперирует пользователь, может увеличиваться до четырех (для одного приложения), в этот период одновременно действуют пара сертификатов с истекающим сроком действия и пара новых сертификатов. Если учитывать, что пользователь может работать с несколькими приложениями, становится ясно, что количество сертификатов, которые необходимо обновлять, постоянно растет. К сожалению, нет простого способа решения этой проблемы, кроме обучения пользователей,
технической поддержки и документирования процессов обновления ключей.
Ряд поставщиков PKI предлагают клиентское программное обеспечение с функциями управления процессом обновления сертификатов. В этом случае клиентское программное обеспечение формирует и отправляет УЦ подписанный запрос (соответствующий тому сертификату, который должен быть обновлен). Цифровая подпись на запросе верифицируется при помощи открытого ключа, содержащегося в копии сертификата отправителя запроса. Если подпись подтверждается, то считается, что пользователь, отправивший запрос, является законным владельцем исходного сертификата. В этом случае УЦ выпускает новый сертификат с теми же самыми данными пользователя и открытым ключом, но новым сроком действия.
Поиск информации о статусе сертификатов
Во время работы в системе PKI пользователям приходится идентифицировать других пользователей и использовать их сертификаты. Большинство организаций хранят сертификаты в общедоступном каталоге, в репозитории. Пользователи обращаются с запросами к репозиторию, чтобы найти сертификаты, принадлежащие определенному человеку или устройству. Проблема, связанная с поиском, заключается в том, что если доступ к каталогу может получить каждый желающий, то содержащаяся в каталоге информация о пользователях также доступна каждому. Очевидно, что многие организации не стремятся раскрывать информацию о своих служащих.
Приложение Microsoft Outlook автоматически прикрепляет сертификат пользователя к отправляемому заверенному цифровой подписью сообщению. Это позволяет получателю проверять электронную почту, имея необходимые сертификаты и не выполняя никаких лишних действий. Присланные по почте сертификаты других пользователей затем хранятся получателем локально и используются для будущих проверок. Пока не все приложения предоставляют подобный сервис, поэтому доверяющие стороны вынуждены выполнять поиск информации о статусе сертификатов самостоятельно (более подробно способы получения информации о статусе сертификатов изложены в лекции 12).
Выбор способа генерации пары ключей
Генерация ключей может осуществляться централизованно (УЦ или по его поручению РЦ) либо индивидуально (конечным субъектом). В большинстве случаев пары ключей создаются конечными субъектами, которые должны иметь программные или аппаратные средства для создания надежных ключей. Этот способ позволяет субъекту обеспечить большую конфиденциальность в отношениях с доверяющими сторонами, поскольку секретный ключ владелец хранит сам и никогда не предъявляет. К сожалению, большинство пользователей не принимает достаточных мер для защиты своих секретных ключей, увеличивая риск их компрометации.
К преимуществам централизованной генерации можно отнести быстроту создания ключей, использование специализированных средств генерации высококачественных ключей, контроль соответствия алгоритмов генерации установленным стандартам, а также хранение резервных копий секретных ключей на случай их утери пользователями. Если ключи генерируются централизованно, то политикой безопасности PKI должны быть предусмотрены средства их защищенной транспортировки другим компонентам PKI, а также гарантии того, что параллельно не будет осуществляться несанкционированное копирование секретных ключей.
Порядок обновления ключей
Политикой PKI должен быть определен порядок действий в случае обновления пар ключей. Пары ключей могут обновляться вручную и автоматически. При ручном обновлении ответственность за своевременное формирование запроса об обновлении возлагается на конечного субъекта, который должен помнить дату истечения срока действия сертификата. Если запрос об обновлении не будет вовремя направлен в УЦ, субъект лишится сервисов PKI. При автоматическом обновлении система PKI сама отслеживает дату истечения срока действия сертификата и инициирует запрос об обновлении ключа соответствующему УЦ.
Политика безопасности организации может предусматривать, например, чтобы все документы, зашифрованные старыми ключами, расшифровывались и вновь зашифровывались при помощи новых ключей или чтобы любые документы, подписанные ранее старым ключом, переподписывались при помощи нового ключа. Рациональная политика управления ключами допускает пятилетний (и даже более) срок действия пары ключей, но может ограничивать период действия ключей шифрования строго конфиденциальных данных несколькими месяцами. Иногда конкретный срок действия ключей не устанавливается, а ключи заменяются в случае необходимости, например, при утере секретного ключа. В этом случае следует повторно оценивать уровень защищенности используемой пары ключей по истечении пяти лет либо при появлении новых криптографических алгоритмов или других технологических достижений.
Выбор способа хранения секретных ключей
При проектировании PKI должен быть выбран способ хранения криптографических ключей - он, как правило, зависит от специфики деятельности конкретной организации. Для ограничения доступа к секретным ключам применяются следующие механизмы [2].
Защита с помощью пароля. Пароль или PIN-код используются для шифрования секретного ключа, который хранится на локальном жестком диске. Этот метод считается наименее безопасным, так как проблема доступа к ключу решается подбором пароля.
Карты PCMCIA. Ключ защищенно хранится на карте с микрочипом, но при вводе в систему "покидает" карту, следовательно, становится уязвимым для хищения.
Устройства хранения секрета. Секретный ключ хранится в зашифрованном виде в специальном устройстве и извлекается только с помощью одноразового кода доступа, предоставляемого устройством. Этот метод более безопасен, чем упомянутые выше, но требует доступности устройства хранения конечному субъекту и не исключает утери устройства.
Биометрические средства. Ключ защищается биометрическими средствами аутентификации владельца ключа, при этом обеспечивается тот же самый уровень защиты, что и в предыдущем случае, но субъект избавляется от необходимости иметь при себе устройство хранения секрета.
Смарт-карты. Ключ хранится на смарт-карте с чипом, который обеспечивает возможность выполнять операции шифрования и цифровой подписи. Ключ никогда не покидает карту, поэтому риск его компрометации низок. Однако владелец ключа должен носить смарт-карту с собой и заботиться о ее сохранности. При утере смарт-карты зашифрованные при помощи секретного ключа данные могут оказаться невосстановимыми.
Реагирование на инциденты во время функционирования 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, является компрометация ключа УЦ (или подозрение, что он скомпрометирован). Организации следует гарантировать, что предприняты соответствующие меры безопасности, чтобы минимизировать риск катастрофы, и что поставщик технологии понимает эту проблему и может предоставить рекомендации и средства, чтобы помочь ускорить восстановление, если такое событие действительно произойдет.
Хотя варианты реализации 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-систем существует режим настройки на автоматическое обновление сертификатов по истечении срока их действия, но часто сертификаты обновляются по запросам пользователей. Поэтому для обновления сертификата пользователю необходимо в определенный момент времени подтвердить УЦ свои идентификационные данные и отправить соответствующий запрос.
Некоторую проблему представляет обновление двойной пары ключей, когда пользователь для работы с одним приложением применяет два сертификата: сертификат ключа шифрования и сертификат ключа подписи. В этом случае в момент обновления пользователь должен получить два новых сертификата. При переходе от старых сертификатов к новым количество сертификатов, которыми оперирует пользователь, может увеличиваться до четырех (для одного приложения), в этот период одновременно действуют пара сертификатов с истекающим сроком действия и пара новых сертификатов. Если учитывать, что пользователь может работать с несколькими приложениями, становится ясно, что количество сертификатов, которые необходимо обновлять, постоянно растет. К сожалению, нет простого способа решения этой проблемы, кроме обучения пользователей, технической поддержки и документирования процессов обновления ключей.
Ряд поставщиков PKI предлагают клиентское программное обеспечение с функциями управления процессом обновления сертификатов. В этом случае клиентское программное обеспечение формирует и отправляет УЦ подписанный запрос (соответствующий тому сертификату, который должен быть обновлен). Цифровая подпись на запросе верифицируется при помощи открытого ключа, содержащегося в копии сертификата отправителя запроса. Если подпись подтверждается, то считается, что пользователь, отправивший запрос, является законным владельцем исходного сертификата. В этом случае УЦ выпускает новый сертификат с теми же самыми данными пользователя и открытым ключом, но новым сроком действия.
Поиск информации о статусе сертификатов
Во время работы в системе PKI пользователям приходится идентифицировать других пользователей и использовать их сертификаты. Большинство организаций хранят сертификаты в общедоступном каталоге, в репозитории. Пользователи обращаются с запросами к репозиторию, чтобы найти сертификаты, принадлежащие определенному человеку или устройству. Проблема, связанная с поиском, заключается в том, что если доступ к каталогу может получить каждый желающий, то содержащаяся в каталоге информация о пользователях также доступна каждому. Очевидно, что многие организации не стремятся раскрывать информацию о своих служащих.
Приложение Microsoft Outlook автоматически прикрепляет сертификат пользователя к отправляемому заверенному цифровой подписью сообщению. Это позволяет получателю проверять электронную почту, имея необходимые сертификаты и не выполняя никаких лишних действий. Присланные по почте сертификаты других пользователей затем хранятся получателем локально и используются для будущих проверок. Пока не все приложения предоставляют подобный сервис, поэтому доверяющие стороны вынуждены выполнять поиск информации о статусе сертификатов самостоятельно (более подробно способы получения информации о статусе сертификатов изложены в лекции 12).
Выбор способа генерации пары ключей
Генерация ключей может осуществляться централизованно (УЦ или по его поручению РЦ) либо индивидуально (конечным субъектом). В большинстве случаев пары ключей создаются конечными субъектами, которые должны иметь программные или аппаратные средства для создания надежных ключей. Этот способ позволяет субъекту обеспечить большую конфиденциальность в отношениях с доверяющими сторонами, поскольку секретный ключ владелец хранит сам и никогда не предъявляет. К сожалению, большинство пользователей не принимает достаточных мер для защиты своих секретных ключей, увеличивая риск их компрометации.
К преимуществам централизованной генерации можно отнести быстроту создания ключей, использование специализированных средств генерации высококачественных ключей, контроль соответствия алгоритмов генерации установленным стандартам, а также хранение резервных копий секретных ключей на случай их утери пользователями. Если ключи генерируются централизованно, то политикой безопасности PKI должны быть предусмотрены средства их защищенной транспортировки другим компонентам PKI, а также гарантии того, что параллельно не будет осуществляться несанкционированное копирование секретных ключей.
Порядок обновления ключей
Политикой PKI должен быть определен порядок действий в случае обновления пар ключей. Пары ключей могут обновляться вручную и автоматически. При ручном обновлении ответственность за своевременное формирование запроса об обновлении возлагается на конечного субъекта, который должен помнить дату истечения срока действия сертификата. Если запрос об обновлении не будет вовремя направлен в УЦ, субъект лишится сервисов PKI. При автоматическом обновлении система PKI сама отслеживает дату истечения срока действия сертификата и инициирует запрос об обновлении ключа соответствующему УЦ.
Политика безопасности организации может предусматривать, например, чтобы все документы, зашифрованные старыми ключами, расшифровывались и вновь зашифровывались при помощи новых ключей или чтобы любые документы, подписанные ранее старым ключом, переподписывались при помощи нового ключа. Рациональная политика управления ключами допускает пятилетний (и даже более) срок действия пары ключей, но может ограничивать период действия ключей шифрования строго конфиденциальных данных несколькими месяцами. Иногда конкретный срок действия ключей не устанавливается, а ключи заменяются в случае необходимости, например, при утере секретного ключа. В этом случае следует повторно оценивать уровень защищенности используемой пары ключей по истечении пяти лет либо при появлении новых криптографических алгоритмов или других технологических достижений.
Выбор способа хранения секретных ключей
При проектировании PKI должен быть выбран способ хранения криптографических ключей - он, как правило, зависит от специфики деятельности конкретной организации. Для ограничения доступа к секретным ключам применяются следующие механизмы [2].
Защита с помощью пароля. Пароль или PIN-код используются для шифрования секретного ключа, который хранится на локальном жестком диске. Этот метод считается наименее безопасным, так как проблема доступа к ключу решается подбором пароля.
Карты PCMCIA. Ключ защищенно хранится на карте с микрочипом, но при вводе в систему "покидает" карту, следовательно, становится уязвимым для хищения.
Устройства хранения секрета. Секретный ключ хранится в зашифрованном виде в специальном устройстве и извлекается только с помощью одноразового кода доступа, предоставляемого устройством. Этот метод более безопасен, чем упомянутые выше, но требует доступности устройства хранения конечному субъекту и не исключает утери устройства.
Биометрические средства. Ключ защищается биометрическими средствами аутентификации владельца ключа, при этом обеспечивается тот же самый уровень защиты, что и в предыдущем случае, но субъект избавляется от необходимости иметь при себе устройство хранения секрета.
Смарт-карты. Ключ хранится на смарт-карте с чипом, который обеспечивает возможность выполнять операции шифрования и цифровой подписи. Ключ никогда не покидает карту, поэтому риск его компрометации низок. Однако владелец ключа должен носить смарт-карту с собой и заботиться о ее сохранности. При утере смарт-карты зашифрованные при помощи секретного ключа данные могут оказаться невосстановимыми.
Реагирование на инциденты во время функционирования 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, является компрометация ключа УЦ (или подозрение, что он скомпрометирован). Организации следует гарантировать, что предприняты соответствующие меры безопасности, чтобы минимизировать риск катастрофы, и что поставщик технологии понимает эту проблему и может предоставить рекомендации и средства, чтобы помочь ускорить восстановление, если такое событие действительно произойдет.
Проблемы интеграции PKIВажным фактором адаптации PKI является решение проблем интеграции и обеспечения работы приложений. PKI может быть интегрирована несколькими способами:
* с приложениями (например, клиентскими приложениями электронной почты);
* с данными третьей стороны (например, с базой данных аутентификации);
* с системами более сильной аутентификации (биометрией или смарт-картами);
* с существующими системами организации [105].
Большие трудности при развертывании инфраструктуры открытых ключей вызывает интеграция соответствующих PKI-функций во вновь создаваемые приложения, а также в уже имеющиеся прикладные системы. PKI должна взаимодействовать с множеством разнообразных систем и приложений, в числе которых могут быть системы управления доступом, каталоги пользователей, виртуальные частные сети, операционные системы, сервисы безопасности, приложения защищенной электронной почты и web-приложения [36]. Налаживание связи между новой инфраструктурой и всеми этими приложениями и системами является сложной задачей, для ее решения важно наличие интерфейсов прикладного программирования, обеспечивающих взаимодействие существующих корпоративных приложений с PKI и использование ее сервисов. Некоторые программные средства поддержки PKI предоставляют интерфейсы прикладного программирования высокого уровня для распространенных приложений.
Выбор программного продукта такого типа облегчает интеграцию PKI и сокращает время развертывания инфраструктуры.
Интеграция с приложениями
Чтобы использовать PKI, программное обеспечение, оперирующее от имени конечных пользователей, процессов или устройств, должно поддерживать такие функции, как шифрование и расшифрование, генерацию и верификацию цифровых подписей, а также обеспечивать доступ к функциям управления жизненным циклом сертификатов и ключей, то есть быть PKI-совместимым.
Очевидно, что не все приложения совместимы с PKI, например, популярное приложение Microsoft Word не способно использовать возможности PKI. Для того чтобы заверить цифровой подписью договор, подготовленный в MS Word, и переслать его партнеру с гарантией соблюдения целостности, пользователю необходимо получить сертификат ключа подписи и воспользоваться дополнительным приложением, обеспечивающим выполнение криптографических функций.
Существует несколько способов придания приложению функций PKI. Чаще всего для этого используются инструментальные средства поставщика PKI. Инструментальный набор позволяет добавлять основные функции PKI, например, генерацию ключей. Разработчики должны затем адаптировать интерфейс пользователя для вызова специфических функций PKI, таких как формирование запроса на сертификат (см. рис. 21.1.).
Рис. 21.1.
Пример интегрированного запроса к web-серверу
Кроме того, последние версии большинства web-серверов существенно расширили возможности web-администратора создавать запросы на сертификаты с консоли администратора. Для интеграции PKI некоторые поставщики предлагают программное обеспечение промежуточного уровня.
В настоящее время список PKI-совместимых программных средств растет, и можно ожидать, что эта тенденция сохранится. Некоторые наиболее популярные системы электронной почты и электронного документооборота являются PKI-совместимыми. Многие поставщики рынка виртуальных частных сетей также реализуют технологию открытых ключей (например, те, которые ориентируются на стандарт IKE [147]), кроме того, web-технология может рассматриваться как частично PKI-совместимая.
Интеграция с данными третьей стороны
Основой модели развертывания качественной PKI является сильная аутентификация, которая, в свою очередь, зависит от интеграции с надежным источником данных. Системы PKI обычно обеспечивают доступ к ODBC- и LDAP-совместимым базам данных и интеграцию с этими данными, а также с данными на базе текстовых файлов. Во многих корпоративных системах выполняется интеграция с базой данных персонала. В системах PKI, предназначенных для массового рынка, часто необходима интеграция с данными третьей стороны, например, бюро кредитных историй. Некоторые поставщики данных предоставляют также и инструментальные средства интеграции.
Интеграция с системами более сильной аутентификации
Как только организация начинает осознавать необходимость сильной аутентификации, она переходит к использованию биометрии и смарт-карт. Обычно большая часть работы по интеграции с биометрическими устройствами возлагается на поставщика устройств, а не на поставщика PKI, поэтому важен правильный выбор поставщика, который поддерживает партнерские программы, или поставщика независимого программного обеспечения, предлагающего готовые решения.
Применение биометрических устройств требует установки клиентского программного обеспечения для контролирования доступа к среде хранения сертификатов на каждом персональном компьютере, а также регистрации и сохранения на компьютере биометрических характеристик пользователей для процедур сравнения.
Применение смарт-карт и управление их жизненным циклом также связано с использованием специального клиентского программного обеспечения и установки дополнительных драйверов. Поставщики смарт-карт могут использовать обычные стандарты типа CAPI (Cryptographic Application Programmer Interface) [112] и PKCS#11 [202]. Следует учитывать, что интеграция с системами более сильной аутентификации требует дополнительных финансовых затрат и затрат времени.
Интеграция с существующими системами
Поскольку любая организация использует существующую ИТ-инфраструктуру, часто возникают проблемы интеграции PKI с уже действующими системами. Обычно предполагается, что PKI будет обслуживать только системы на базе персональных компьютеров и PKI-совместимые приложения. Большинство программных продуктов для PKI не предназначено для работы в системах на базе UNIX или мейнфреймов. Для интеграции PKI с большими вычислительными системами необходимо программное обеспечение промежуточного слоя или передача данных вручную.
Интеграция с интерфейсом пользователя
Важным аспектом PKI, который часто упускается из виду, является удобство работы пользователя. Пользователь должен иметь простое и понятное средство формирования запросов на выдачу, обновление и аннулирование сертификатов. Большинство поставщиков PKI предлагают некоторый интерфейс пользователя, но, как правило, он является приложением, базирующимся на клиентском программном обеспечении, и не всегда приспособлен для работы на разных компьютерных платформах ( PC, UNIX, Mac ) или разных версиях.
Важным фактором адаптации PKI является решение проблем интеграции и обеспечения работы приложений. PKI может быть интегрирована несколькими способами:
* с приложениями (например, клиентскими приложениями электронной почты);
* с данными третьей стороны (например, с базой данных аутентификации);
* с системами более сильной аутентификации (биометрией или смарт-картами);
* с существующими системами организации [105].
Большие трудности при развертывании инфраструктуры открытых ключей вызывает интеграция соответствующих PKI-функций во вновь создаваемые приложения, а также в уже имеющиеся прикладные системы. PKI должна взаимодействовать с множеством разнообразных систем и приложений, в числе которых могут быть системы управления доступом, каталоги пользователей, виртуальные частные сети, операционные системы, сервисы безопасности, приложения защищенной электронной почты и web-приложения [36]. Налаживание связи между новой инфраструктурой и всеми этими приложениями и системами является сложной задачей, для ее решения важно наличие интерфейсов прикладного программирования, обеспечивающих взаимодействие существующих корпоративных приложений с PKI и использование ее сервисов. Некоторые программные средства поддержки PKI предоставляют интерфейсы прикладного программирования высокого уровня для распространенных приложений. Выбор программного продукта такого типа облегчает интеграцию PKI и сокращает время развертывания инфраструктуры.
Интеграция с приложениями
Чтобы использовать PKI, программное обеспечение, оперирующее от имени конечных пользователей, процессов или устройств, должно поддерживать такие функции, как шифрование и расшифрование, генерацию и верификацию цифровых подписей, а также обеспечивать доступ к функциям управления жизненным циклом сертификатов и ключей, то есть быть PKI-совместимым.
Очевидно, что не все приложения совместимы с PKI, например, популярное приложение Microsoft Word не способно использовать возможности PKI. Для того чтобы заверить цифровой подписью договор, подготовленный в MS Word, и переслать его партнеру с гарантией соблюдения целостности, пользователю необходимо получить сертификат ключа подписи и воспользоваться дополнительным приложением, обеспечивающим выполнение криптографических функций.
Существует несколько способов придания приложению функций PKI. Чаще всего для этого используются инструментальные средства поставщика PKI. Инструментальный набор позволяет добавлять основные функции PKI, например, генерацию ключей. Разработчики должны затем адаптировать интерфейс пользователя для вызова специфических функций PKI, таких как формирование запроса на сертификат (см. рис. 21.1.).
Рис. 21.1. Пример интегрированного запроса к web-серверу
Кроме того, последние версии большинства web-серверов существенно расширили возможности web-администратора создавать запросы на сертификаты с консоли администратора. Для интеграции PKI некоторые поставщики предлагают программное обеспечение промежуточного уровня.
В настоящее время список PKI-совместимых программных средств растет, и можно ожидать, что эта тенденция сохранится. Некоторые наиболее популярные системы электронной почты и электронного документооборота являются PKI-совместимыми. Многие поставщики рынка виртуальных частных сетей также реализуют технологию открытых ключей (например, те, которые ориентируются на стандарт IKE [147]), кроме того, web-технология может рассматриваться как частично PKI-совместимая.
Интеграция с данными третьей стороны
Основой модели развертывания качественной PKI является сильная аутентификация, которая, в свою очередь, зависит от интеграции с надежным источником данных. Системы PKI обычно обеспечивают доступ к ODBC- и LDAP-совместимым базам данных и интеграцию с этими данными, а также с данными на базе текстовых файлов. Во многих корпоративных системах выполняется интеграция с базой данных персонала. В системах PKI, предназначенных для массового рынка, часто необходима интеграция с данными третьей стороны, например, бюро кредитных историй. Некоторые поставщики данных предоставляют также и инструментальные средства интеграции.
Интеграция с системами более сильной аутентификации
Как только организация начинает осознавать необходимость сильной аутентификации, она переходит к использованию биометрии и смарт-карт. Обычно большая часть работы по интеграции с биометрическими устройствами возлагается на поставщика устройств, а не на поставщика PKI, поэтому важен правильный выбор поставщика, который поддерживает партнерские программы, или поставщика независимого программного обеспечения, предлагающего готовые решения.
Применение биометрических устройств требует установки клиентского программного обеспечения для контролирования доступа к среде хранения сертификатов на каждом персональном компьютере, а также регистрации и сохранения на компьютере биометрических характеристик пользователей для процедур сравнения.
Применение смарт-карт и управление их жизненным циклом также связано с использованием специального клиентского программного обеспечения и установки дополнительных драйверов. Поставщики смарт-карт могут использовать обычные стандарты типа CAPI (Cryptographic Application Programmer Interface) [112] и PKCS#11 [202]. Следует учитывать, что интеграция с системами более сильной аутентификации требует дополнительных финансовых затрат и затрат времени.
Интеграция с существующими системами
Поскольку любая организация использует существующую ИТ-инфраструктуру, часто возникают проблемы интеграции PKI с уже действующими системами. Обычно предполагается, что PKI будет обслуживать только системы на базе персональных компьютеров и PKI-совместимые приложения. Большинство программных продуктов для PKI не предназначено для работы в системах на базе UNIX или мейнфреймов. Для интеграции PKI с большими вычислительными системами необходимо программное обеспечение промежуточного слоя или передача данных вручную.
Интеграция с интерфейсом пользователя
Важным аспектом PKI, который часто упускается из виду, является удобство работы пользователя. Пользователь должен иметь простое и понятное средство формирования запросов на выдачу, обновление и аннулирование сертификатов. Большинство поставщиков PKI предлагают некоторый интерфейс пользователя, но, как правило, он является приложением, базирующимся на клиентском программном обеспечении, и не всегда приспособлен для работы на разных компьютерных платформах ( PC, UNIX, Mac ) или разных версиях.
Проблемы функциональной совместимости продуктов разных поставщиковПомимо проблемы стандартов, существует также проблема функциональной совместимости продуктов разных поставщиков [99]. Не все программные средства поддержки каталога имеют одинаковую функциональность, более того - одни и те же функции в разных продуктах реализуются по-разному, даже если и базируются на одних и тех же стандартах. Но проблема со временем будет решаться, поскольку поставщики каталогов стремятся к этому, работая вместе не только со своими технологическими партнерами и клиентами, но даже с конкурентами.
Анализ реальных возможностей функциональной совместимости
Поставщики программных средств могут законно заявлять о соответствии своих продуктов стандартам, но по ряду причин не всегда реально может достигаться функциональная совместимость продуктов нескольких поставщиков. Для организации очень существенны понимание этих причин и гарантии, что выбранные поставщики будут совместно решать проблемы функциональной совместимости.
Формат X.509 или альтернативные форматы сертификатов
Как известно (см. лекцию 6), помимо формата X.509 существуют и альтернативные форматы сертификатов. Неудивительно, что имеются сторонники каждого формата. Так, например, сторонники формата SPKI утверждают, что сертификаты SPKI позволяют фиксировать роли и права авторизации, не раскрывая идентичность субъектов. Сторонники формата PGP или Open PGP считают важным преимуществом большую гибкость сертификатов PGP по сравнению с сертификатами открытых ключей X.509 v3 и, следовательно, большую пригодность для установления отношений доверия между субъектами. Однако пока большинство поставщиков PKI поддерживают только сертификаты X.509.
В будущем, возможно, получат распространение форматы сертификатов, основанные на языке разметки XML (eXtensible Markup Language) [66], который все чаще применяется в качестве формата для обмена информацией между разными приложениями в Интернете [44]. Новые форматы сертификатов, определенные техническим комитетом по сервисам безопасности OASIS в спецификации языка Security Assertion Markup Language (SAML) [95], вероятно, будут использоваться сообществом разработчиков бизнес-приложений на базе XML. Такие форматы могут заменить сертификаты X.509 на уровне XML -приложений, но, скорее всего, будут сосуществовать вместе с ними на другом уровне, для того чтобы осуществлялось взаимодействие с другими действующими инфраструктурами.
Среда для такого взаимодействия может базироваться на спецификации управления ключами XML Key Management Specification [129], чтобы, как определено Консорциумом World Wide Web Consortium (W3C), скрывать от XML -приложения детали базовой PKI стандарта X.509.
Профили сертификатов и списки САС
Даже когда адаптируются технологии, основанные на стандартах, реализации PKI варьируются в зависимости от типа домена доверия. Это касается сертификатов и списков САС формата X.509. Для удовлетворения специфических требований разных доменов создаются разные профили сертификатов и списков САС. Для развертывания PKI важно выбрать поставщика технологии, который предлагает процедуру генерации сертификатов и списков САС, позволяющую учитывать требования многих профилей сертификатов и списков САС.
PKI-совместимые приложения
Чтобы приложение могло использовать необходимые сервисы безопасности и функции управления жизненным циклом ключей и сертификатов, оно должно быть PKI-совместимым. Поставщики технологии должны предлагать стандартные PKI-совместимые приложения, а также определенные инструментальные средства, предназначенные для интеграции в PKI других приложений.
Помимо проблемы стандартов, существует также проблема функциональной совместимости продуктов разных поставщиков [99]. Не все программные средства поддержки каталога имеют одинаковую функциональность, более того - одни и те же функции в разных продуктах реализуются по-разному, даже если и базируются на одних и тех же стандартах. Но проблема со временем будет решаться, поскольку поставщики каталогов стремятся к этому, работая вместе не только со своими технологическими партнерами и клиентами, но даже с конкурентами.
Анализ реальных возможностей функциональной совместимости
Поставщики программных средств могут законно заявлять о соответствии своих продуктов стандартам, но по ряду причин не всегда реально может достигаться функциональная совместимость продуктов нескольких поставщиков. Для организации очень существенны понимание этих причин и гарантии, что выбранные поставщики будут совместно решать проблемы функциональной совместимости.
Формат X.509 или альтернативные форматы сертификатов
Как известно (см. лекцию 6), помимо формата X.509 существуют и альтернативные форматы сертификатов. Неудивительно, что имеются сторонники каждого формата. Так, например, сторонники формата SPKI утверждают, что сертификаты SPKI позволяют фиксировать роли и права авторизации, не раскрывая идентичность субъектов. Сторонники формата PGP или Open PGP считают важным преимуществом большую гибкость сертификатов PGP по сравнению с сертификатами открытых ключей X.509 v3 и, следовательно, большую пригодность для установления отношений доверия между субъектами. Однако пока большинство поставщиков PKI поддерживают только сертификаты X.509.
В будущем, возможно, получат распространение форматы сертификатов, основанные на языке разметки XML (eXtensible Markup Language) [66], который все чаще применяется в качестве формата для обмена информацией между разными приложениями в Интернете [44]. Новые форматы сертификатов, определенные техническим комитетом по сервисам безопасности OASIS в спецификации языка Security Assertion Markup Language (SAML) [95], вероятно, будут использоваться сообществом разработчиков бизнес-приложений на базе XML. Такие форматы могут заменить сертификаты X.509 на уровне XML -приложений, но, скорее всего, будут сосуществовать вместе с ними на другом уровне, для того чтобы осуществлялось взаимодействие с другими действующими инфраструктурами. Среда для такого взаимодействия может базироваться на спецификации управления ключами XML Key Management Specification [129], чтобы, как определено Консорциумом World Wide Web Consortium (W3C), скрывать от XML -приложения детали базовой PKI стандарта X.509.
Профили сертификатов и списки САС
Даже когда адаптируются технологии, основанные на стандартах, реализации PKI варьируются в зависимости от типа домена доверия. Это касается сертификатов и списков САС формата X.509. Для удовлетворения специфических требований разных доменов создаются разные профили сертификатов и списков САС. Для развертывания PKI важно выбрать поставщика технологии, который предлагает процедуру генерации сертификатов и списков САС, позволяющую учитывать требования многих профилей сертификатов и списков САС.
PKI-совместимые приложения
Чтобы приложение могло использовать необходимые сервисы безопасности и функции управления жизненным циклом ключей и сертификатов, оно должно быть PKI-совместимым. Поставщики технологии должны предлагать стандартные PKI-совместимые приложения, а также определенные инструментальные средства, предназначенные для интеграции в PKI других приложений.
Проблемы репозиторияМногие корпоративные домены используют онлайновый репозиторий для своевременного и надежного распространения сертификатов, информации об их статусе, а также другой информации, имеющей отношение к PKI (например, информации о политике). Опыт развертывания PKI свидетельствует о том, что предоставление услуг репозитория не обходится без проблем, которые связаны с отсутствием единых стандартов, принятых в индустрии, и совместимостью продуктов PKI разных поставщиков [105].
Выбор репозитория
В PKI может быть реализовано несколько вариантов распространения сертификатов конечных субъектов, информации об их аннулировании и других релевантных данных; имеется ряд поставщиков, которые поддерживают один или несколько подобных сервисов. Как и в случае выбора поставщика технологии PKI, для организации важны гарантии, что поставщик репозитория предлагает гибкую функциональность и обеспечивает совместимость с продуктами многих поставщиков.
Отсутствие единых стандартов на сервисы каталога
Одна из проблем, связанных с сервисами каталога, заключается в отсутствии единого стандарта на эти услуги. Некоторые сегменты рынка адаптировали стандарты каталога X.500, но одновременно существует и разрабатывается большое количество стандартов, имеющих отношение к репозиторию. Например, известный упрощенный протокол доступа к каталогу LDAP, разработанный организацией IETF, с точки зрения технической перспективы находится в прямой конкуренции с протоколом DAP, базирующимся на стандарте X.500. Имеется еще ряд нерешенных проблем обмена информацией и взаимодействия "клиент-сервер" и "сервер-сервер". Рабочая группа LDAPext организации IETF разрабатывает ряд стандартов, таких как механизмы управления доступа и модели контроля доступа, в стадии разработки находится протокол LDUP [87], который,
вероятно, будет конкурировать со своим двойником - протоколом DISP (Directory Information Shadowing Protocol) стандарта X.500. Кроме того, распространение информации PKI выполняется и другими способами (см. лекцию 12).
Хотя любое из этих решений может вполне соответствовать требованиям конкретной организации, при взаимодействии систем PKI разных организаций могут возникнуть проблемы функциональной совместимости разных решений.
Масштабируемость и производительность
Наконец, с развертыванием сервиса репозитория связаны потенциальные проблемы масштабируемости и производительности. Очевидно, что необходимое количество серверов зависит от количества конечных пользователей, а также от срока действия списков САС (в предположении, что допускается кэширование) и других обстоятельств реализации (например, от того, поддерживаются ли дельта-списки САС). Также надо учитывать и дополнительную нагрузку на репозиторий, поскольку он часто используется не только для целей PKI, но и для других нужд организации.
Многие корпоративные домены используют онлайновый репозиторий для своевременного и надежного распространения сертификатов, информации об их статусе, а также другой информации, имеющей отношение к PKI (например, информации о политике). Опыт развертывания PKI свидетельствует о том, что предоставление услуг репозитория не обходится без проблем, которые связаны с отсутствием единых стандартов, принятых в индустрии, и совместимостью продуктов PKI разных поставщиков [105].
Выбор репозитория
В PKI может быть реализовано несколько вариантов распространения сертификатов конечных субъектов, информации об их аннулировании и других релевантных данных; имеется ряд поставщиков, которые поддерживают один или несколько подобных сервисов. Как и в случае выбора поставщика технологии PKI, для организации важны гарантии, что поставщик репозитория предлагает гибкую функциональность и обеспечивает совместимость с продуктами многих поставщиков.
Отсутствие единых стандартов на сервисы каталога
Одна из проблем, связанных с сервисами каталога, заключается в отсутствии единого стандарта на эти услуги. Некоторые сегменты рынка адаптировали стандарты каталога X.500, но одновременно существует и разрабатывается большое количество стандартов, имеющих отношение к репозиторию. Например, известный упрощенный протокол доступа к каталогу LDAP, разработанный организацией IETF, с точки зрения технической перспективы находится в прямой конкуренции с протоколом DAP, базирующимся на стандарте X.500. Имеется еще ряд нерешенных проблем обмена информацией и взаимодействия "клиент-сервер" и "сервер-сервер". Рабочая группа LDAPext организации IETF разрабатывает ряд стандартов, таких как механизмы управления доступа и модели контроля доступа, в стадии разработки находится протокол LDUP [87], который, вероятно, будет конкурировать со своим двойником - протоколом DISP (Directory Information Shadowing Protocol) стандарта X.500. Кроме того, распространение информации PKI выполняется и другими способами (см. лекцию 12).
Хотя любое из этих решений может вполне соответствовать требованиям конкретной организации, при взаимодействии систем PKI разных организаций могут возникнуть проблемы функциональной совместимости разных решений.
Масштабируемость и производительность
Наконец, с развертыванием сервиса репозитория связаны потенциальные проблемы масштабируемости и производительности. Очевидно, что необходимое количество серверов зависит от количества конечных пользователей, а также от срока действия списков САС (в предположении, что допускается кэширование) и других обстоятельств реализации (например, от того, поддерживаются ли дельта-списки САС). Также надо учитывать и дополнительную нагрузку на репозиторий, поскольку он часто используется не только для целей PKI, но и для других нужд организации.
Проблемы оценивания стоимости PKI
Во время развертывания и эксплуатации PKI необходимы первоначальные капиталовложения и средства на поддержание функционирования системы. Для инсорсингового варианта PKI и развертывания системы для массового рынка характерны достаточно высокие первоначальные издержки, но затем с ростом масштаба системы и переносом части затрат на пользователей происходит экономия средств. Менее масштабные проекты и аутсорсинговая модель требуют более значительных расходов на поддержание функционирования PKI.
|Компонент | Стоимость | Комментарий |
|Аппаратное обеспечение | Высокая | Компьютерное оборудование, включая системы резервирования и безопасности. Аппаратное обеспечение состоит, по крайней мере, из 2-3 серверов, сетевого оборудования и инфраструктуры безопасности, включая межсетевые экраны |
|Программное обеспечение | Высокая | Программное обеспечение PKI, в том числе стоимость начальной лицензии и расходы на техническую поддержку. Программное обеспечение состоит из программного обеспечения УЦ, консоли администратора РЦ, ОС и web-сервера |
|Услуги консультантов | Высокая | Предварительная экспертиза, консультации на начальном этапе перед физической установкой аппаратного и программного обеспечения. Анализ структуры бизнеса заказчика для построения иерархий удостоверяющих центров, интеграция с базами данных или клиентскими приложениями на персональных компьютерах пользователей |
Таблица 21.1.Структура стоимости установки типичной системы PKI (инсорсинг)
Развертывание систем PKI не требует таких больших капиталовложений и не занимает столько времени, как популярные недавно ERP-системы. Но все же немалые средства и время могут быть потрачены на неэффективную систему PKI. Таблицы 21.1, 21.2, 21.3 и 21.4 характеризуют, как примерно будет происходить амортизация капиталовложений в систему PKI в зависимости от варианта развертывания (инсорсинг или аутсорсинг) [105].
Расходы на установку и подготовку системы к работе складываются из расходов на аппаратное и программное обеспечение и квалифицированный персонал. Первоначальные капиталовложения в инсорсинговые системы PKI обычно значительно выше, чем в аутсорсинговые.
Поскольку система PKI является существенной частью инфраструктуры безопасности организации, она должна функционировать круглосуточно семь дней в неделю (24х7). Таблицы 21.3 и 21.4 иллюстрируют статьи расходов по поддержанию работы систем PKI для вариантов инсорсинга и аутсорсинга соответственно.
|Компонент | Стоимость | Комментарий |
|Аппаратное обеспечение | Низкая | Компьютерное оборудование, в том числе системы резервирования и безопасности. Базовое аппаратное обеспечение (web-серверов) для переадресации на аутсорсинговый УЦ, может быть включена консоль администратора (персональный компьютер). Резервное аппаратное обеспечение web-сервера, контролирующего функции управления жизненным циклом сертификатов |
|Программное обеспечение | Высокая | Программное обеспечение PKI, в том числе стоимость начальной лицензии и расходы на техническую поддержку. Программное обеспечение для локальной адаптации в соответствии с требованиями заказчика, могут быть включены программные компоненты для целей аутентификации |
|Услуги консультантов | Средняя | Предварительная экспертиза перед установкой и подготовкой к работе компонентов PKI. Анализ требований бизнеса заказчика для управления процессами аутентификации и подготовкой к работе УЦ. Настройка web-страниц и/или политик безопасности на требования заказчика |
Таблица 21.2.Структура стоимости установки типичной системы PKI (аутсорсинг)
|Компонент | Стоимость | Комментарий |
|Аппаратное обеспечение | Средняя | Компьютерное оборудование, в том числе системы резервирования и безопасности. Со временем аппаратное обеспечение необходимо заменять или модернизировать |
|Программное обеспечение | Низкая | Программное обеспечение PKI, включая стоимость начальной лицензии и расходы на техническую поддержку. Со временем происходит амортизация затрат на программное обеспечение, остаются только затраты на техническую поддержку |
|Услуги консультантов | Низкая | Экспертиза требуется только тогда, когда возникает необходимость интеграции или существенно меняются условия ведения бизнеса |
Таблица 21.3.Структура стоимости технической поддержки типичной системы PKI (инсорсинг)
|Компонент | Стоимость | Комментарий |
|Аппаратное обеспечение | Низкая | Компьютерное оборудование, включая системы резервирования и безопасности. Со временем необходимо заменять или модернизировать аппаратное обеспечение |
|Программное обеспечение | Средняя | Программное обеспечение PKI, в том числе стоимость начальной лицензии и расходы на техническую поддержку. Затраты на управление системой PKI |
|Услуги консультантов | Низкая | Экспертиза требуется только тогда, когда возникает необходимость интеграции или существенно меняются условия ведения бизнеса |
Таблица 21.4.Структура стоимости технической поддержки типичной системы PKI (аутсоросинг)
К сожалению, не существует единой, подходящей всем организациям формулы определения стоимости развертывания PKI. Многие организации могут использовать существующую ИТ-инфраструктуру и перераспределять свои инвестиции в информационные технологии с целью возмещения стоимости развертывания PKI - это относится и к персоналу, и к оборудованию. Например, если необходимо, чтобы УЦ был защищен средствами контроля несанкционированного доступа, то многие организации, особенно большие, могут воспользоваться уже имеющимися средствами управления доступом. Широко распространенный сервис репозитория также составляет важную часть крупномасштабной корпоративной PKI. Многие организации с этой целью могут не создавать отдельный репозиторий для поддержки PKI, а эксплуатировать уже имеющийся корпоративный репозиторий, тем самым экономя на приобретении нового сервера и оптимизируя операционные издержки. Кроме того, для развертывания и технической поддержки компонентов PKI организация может привлечь специалистов своего ИТ-подразделения. Ясно, что масштабы использования своей собственной ИТ-инфраструктуры будут варьироваться в зависимости от конкретной организации.
В любом случае для оценивания общей стоимости владения (Total Cost of Ownership - TCO) PKI организации необходимо определить:
* количество и состав аппаратного оборудования, соответствующего потребностям сообщества, для которого предназначается PKI;
* начальные расходы на программное обеспечение и стоимость сопровождения и технической поддержки системы PKI;
* масштабы использования существующей ИТ-инфраструктуры организации;
* требования к ресурсам, необходимым для проектирования, развертывания, функционирования и сопровождения системы PKI;
* стоимость дополнительных площадей (если недостаточно имеющихся у организации) для размещения компонентов инфраструктуры;
* требования к доступности компонентов PKI и потребности в полном резервировании каких-либо компонентов;
* стоимость обучения администраторов, обслуживающего персонала и конечных пользователей;
* уровень консультационной помощи, предоставляемой конечным субъектам PKI;
* юридическую ответственность УЦ перед конечными субъектами и доверяющими сторонами
* необходимость взаимодействия и функциональной совместимости PKI с другими PKI-доменами и внешними пользователями [44].
Последнее обстоятельство является критически важным, потому что основной риск, возникающий при использовании PKI, заключается в невозможности предоставить PKI-сервисы вследствие недостаточной функциональной совместимости программных и аппаратных продуктов различных производителей. Это относится и к взаимодействию субъектов внутри PKI-доменов, и к междоменным отношениям. Поэтому следование стандартам технологии цифровых сертификатов является необходимым условием успешного проектирования и развертывания эффективных инфраструктур открытых ключей.
Проведя тщательную оценку своих потребностей, некоторые организации вообще могут прийти к выводу, что инфраструктура открытых ключей им не нужна. PKI целесообразно развертывать в крупных территориально распределенных организациях, где необходимо наладить контролируемую защиту документов и серверов при использовании разнообразных приложений. Для решения менее масштабных задач пригоден другой инструментарий безопасности. Преимущество решения безопасности на базе PKI заключается в создании единой инфраструктуры, которая может поддерживать многочисленные сервисы безопасности в сложной, гетерогенной, крупномасштабной среде со многими приложениями.
ТЕЛЕГРАМКанал с обзорами, анонсами новинок и книжными подборками
Книжный Вестник
Бот для удобного поиска книг (если не нашлось на сайте)
Поиск книг
Свежие любовные романы в удобных форматах
Любовные романы
О психологии, саморазвитии и личностном росте
Саморазвитие
Детективы и триллеры, все новинки
Детективы
Фантастика и фэнтези, все новинки
Фантастика
Отборные классические книги
Классика
ВКОНТАКТЕБиблиотека с любовными романами, которая наверняка придётся по вкусу женской части аудитории
Любовные романы
Библиотека с фантастикой и фэнтези, а также смежных жанров
Фантастика
Самые популярные книги в формате фб2
Топ фб2
книги