Что такое PKI?

PKI — это аббревиатура «Public key infrastructure», что означает инфраструктуру открытых ключей, технологии, лежащей в основе цифровых сертификатов. Цифровой сертификат выполняет ту же цель, что и водительские права или паспорт — это документ, удостоверяющий вашу личность и предоставляющий определенные нормы. Цифровой сертификат позволяет его владельцу шифровать, подписывать и аутентифицировать. Соответственно, PKI — это технология, которая позволяет шифровать данные, подписывать документы в цифровой форме и аутентифицировать себя с помощью сертификатов.

Существует ряд требований, предъявляемых предприятиями к созданию эффективной инфраструктуры открытых ключей. Прежде всего, если пользователи не могут воспользоваться шифрованием и цифровыми подписями в приложениях, — PKI не эффективен. Следовательно, главное требование для PKI — это прозрачность. Термин «прозрачность» означает, что пользователи не должны понимать, как PKI управляет ключами и сертификатами открытых ключей, чтобы воспользоваться услугами шифрования и цифровой подписи. Эффективная PKI прозрачна. В дополнение к прозрачности пользователя, предприятие должно реализовать следующие элементы в PKI для предоставления необходимых услуг по управлению ключами и сертификатами:

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

Примечание. Термин «клиентский» относится к клиентам приложений и серверам приложений. Требования к PKI одинаковы как для клиентов приложений, так и для серверов. Оба — клиенты услуг инфраструктуры.

Все эти требования необходимо выполнить, чтобы получить автоматическую, прозрачную, пригодную для использования PKI.

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

Эти данные хранятся в стандартном формате сертификата цифрового открытого ключа X.509. Центры сертификации (CA) представляют людей, процессы и инструменты для создания цифровых сертификатов, которые безопасно связывают имена пользователей с их открытыми ключами. При создании сертификатов CA выступают в качестве доверенных лиц в PKI. Пока пользователи доверяют CA и его бизнес-политикам выдачи и управления сертификатами, они могут доверять сертификатам, выданным CA. Такие CA называются доверительными третьими сторонами.

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

1. Имя пользователя в формате уникального имени (DN). DN указывает имя пользователя и любые дополнительные атрибуты, необходимые для уникальной идентификации пользователя (например, DN может содержать номер сотрудника пользователя).
2. Открытый ключ пользователя. Открытый ключ необходим, чтобы другие могли зашифровать для пользователя информацию или проверить цифровую подпись пользователя.
3. Срок действия (или срок службы) сертификата (дата начала и дата окончания).
4. Конкретные операции, для которых должен использоваться открытый ключ (шифрование данных, проверка цифровых подписей или и то, и другое).

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

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

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

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

Что такое кража центра сертификации или корневого закрытого ключа?

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

Целостность закрытых ключей организации по всей инфраструктуре — от корневых центров сертификации до СА, выдающих сертификаты, обеспечивает основу доверия к ее PKI, поэтому так важно защищать ее. Признанной передовой практикой для защиты этих критических ключей является использование аппаратного модуля безопасности (HSM), сертифицированного по стандартам FIPS 140-2 уровня 3. Это защищенное от несанкционированного доступа устройство, которое соответствует самым высоким стандартам безопасности и надежности.

Инфраструктура открытых ключей PKI и SSL, хотя и отличаются друг от друга, но устроены на основе сертификатов, которые устанавливают «доверие» с сертификатами, выданными центром сертификации (CA) — будь то открытое доверие (SSL) или закрытое доверие (PKI).

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

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

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

Традиционные сценарии использования

Эти критически важные для бизнеса приложения ясно показывают, что PKI является стратегической частью ИТ-системы.

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

(См. подробную информацию в таблице ниже.)

Новые и развивающиеся сценарии использования

Была также отмечена новая волна сценариев использования PKI в связи с DevOps, которые способствуют более широкому внедрению.

• Облачные сервисы.
• Потребительский мобильный телефон.
• Интернет вещей (Internet of Things — IoT).
• Мобильные приложения, ориентированные на потребителя.
• Политика «принеси свое собственное устройство» (BYOD) и внутреннее управление мобильными устройствами.
• Электронная коммерция.

(См. подробную информацию в таблице ниже.)

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

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

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

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

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

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

Существует две причины, по которым резервное копирование и восстановление ключей так важны для бизнеса.

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

Различие между резервным копированием и депонированием ключей

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

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

Для каких ключей требуется резервное копирование?

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

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

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

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

Закрытый ключ подписи

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

Необходимость в двух парах ключей

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

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

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

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

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

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

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

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

Эту единогласную позицию определяют несколько факторов.

• Хранение сертификатов открытого ключа в каталогах и получение сертификатов открытого ключа приложениями от имени пользователей обеспечивает прозрачность, необходимую для использования в большинстве сфер деятельности.
• Многие технологии каталогов, поддерживающие LDAP, можно масштабировать до:
  • поддержки очень большого количества записей;
  • эффективного реагирования на поисковые запросы благодаря хранению и поиску информации;
  • распространения по всей сети для соответствия требованиям даже самых сильно распределенных организаций.

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

Помимо проверки подписи CA на сертификате (как обсуждалось ранее в разделе «Какова роль сертификатов и центров сертификации?»), прикладное программное обеспечение также должно знать, что сертификат все еще заслуживает доверия во время использования. Сертификаты, которые больше не заслуживают доверия, должны быть отозваны центром сертификации. Существует множество причин, по которым сертификат отзывается до истечения срока его действия. Например, закрытый ключ (ключ подписи или ключ расшифровки), соответствующий публичному ключу в сертификате, может быть скомпрометирован. В качестве альтернативы политика безопасности организации может предписывать отзыв сертификатов сотрудников, покидающих организацию.

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

Сочетание публикации и последовательного использования информации об отзыве сертификатов представляет собой полную систему аннулирования. Наиболее популярным способом распространения информации об отзыве сертификатов служит создание списков безопасных отзывов сертификатов (CRL) и публикация этих CRL в системе каталогов. CRL указывают уникальные серийные номера всех отозванных сертификатов.

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

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

Термин перекрестная сертификация относится к двум операциям:

1. Установление доверительных отношений между двумя CA (выполняется не часто). В случае двусторонней перекрестной сертификации два CA безопасно обмениваются ключами проверки. Это ключи, используемые для проверки подписей CA на сертификатах. Для завершения операции каждый CA подписывает проверочный ключ другого CA в сертификате, называемом «перекрестным сертификатом».
2. Проверка надежности пользовательского сертификата, подписанного перекрестно сертифицированным CA (выполняется часто). Вот он. Операцию, выполняемую клиентским программным обеспечением, часто называют прохождением цепи доверия. Цепь относится к списку проверок перекрестных сертификатов, которые прошли (или отслеживаются) от ключа CA проверяющего пользователя до ключа CA, необходимого для проверки сертификата другого пользователя. При прохождении цепочки перекрестных сертификатов каждый перекрестный сертификат должен быть проверен, чтобы убедиться, что ему все еще доверяют. Сертификаты пользователей должны быть отозваны, как и перекрестные сертификаты. Это требование часто игнорируется при обсуждении вопроса о перекрестной сертификации.

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

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

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

Поддержка новых приложений

Часто трудно использовать PKI для приложений. Неспособность существующего PKI поддерживать новые приложения и изменять устаревшие — это две наиболее значительные проблемы, с которыми организации будут по-прежнему сталкиваться, пытаясь предоставить приложениям возможности PKI, согласно отчету 2019 PKI and IoT Trends Report (Отчет о тенденциях PKI и интернета вещей 2019 года) от Ponemon Institute.

(См. подробную информацию в таблице ниже.)

Отсутствие четкой ответственности

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

• Инфраструктура распределена, много сертификатов выдано многим людям, местам и вещам.
• Сейчас нам нужно обезопасить больше «вещей», чем когда-либо, и иметь дело с более короткими сроками действия сертификатов.
• Сертификаты обеспечивают безопасность критически важных бизнес-приложений, а простои могут дорого стоить и трудно диагностироваться.

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

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

• общие критерии EAL уровень 4+;
• стандарты FIPS 140-2, уровень 3.