Примеры 1) промежуточного УЦ в открытой иерархии доверия и 2) частной иерархии, которая изолирована от открытой иерархии, со своим собственным корневым УЦ
Инфраструктура открытых ключей (PKI) традиционно имеет иерархическую структуру. В ней удостоверяющие центры (УЦ) связаны отношениями подчинённости. Все пользователи доверяют одному и тому же корневому (головному) УЦ, а каждый нижестоящий УЦ подчиняется более высокому в иерархии.
Но что, если мы хотим создать частную инфраструктуру PKI со своим собственным УЦ? Действительно, в некоторых ситуациях такие промежуточные или частные иерархии очень удобны на практике.
Типичные причины для создания промежуточной или частной иерархии
- Аутентификация клиентов
Аутентификацию клиентов по сертификатам удобно сделать на основе промежуточного УЦ. При наличии эксклюзивного подчинённого УЦ можно ограничить число сертификатов, предоставляющих доступ к системе. В этих случаях обычно используются приватные иерархии доверия.
- Брендинг
Для компаний, которые предлагают сертификаты своим клиентам или включают их в комплект оказываемых услуг, наличие своего выделенного УЦ позволяет предложить некоторые дополнительные возможности брендинга.
- Инспекция/дешифрование SSL/TLS
Чтобы устройство проверки SSL могло дешифровать и заново шифровать контент, у него должна быть возможность выдавать сертификаты по мере необходимости. Это означает, что нужен собственный подчинённый УЦ вне публичной иерархии доверия. В этом случае корневой УЦ размещается у GlobalSign, а промежуточный УЦ — на устройстве проверки сертификатов у клиента.
- Сертификаты специального назачения
Сертификаты, выданные в рамках приватных иерархий, могут поддерживать устаревшие приложения и уникальные конфигурации, такие как более длительные периоды действия и меньшие размеры ключей, которые не разрешены в общедоступных доверенных сертификатах по базовым требованиям CA/Browser Forum. Впрочем, если нужны только приватные сертификаты SSL/TLS, без полноценного собственного УЦ, то можно воспользоваться услугой IntranetSSL.
- Настраиваемые профили
Вы можете настроить подчинённый УЦ на конкретные задачи, изменив под свои потребности политики расширенного использования ключей, политики сертификатов, точки распространения списков отзыва сертификатов (CRL), сделав краткосрочные сертификаты и др.
Размещение и поддержка
Хостинг и сопровождение собственного УЦ компания может осуществлять самостоятельно или отдать на аутсорсинг. Многие компании берутся за развёртывание крупномасштабных систем PKI своими силами (инсорсинг), не имея необходимых ресурсов на это. Поскольку процесс требует капиталовложений, то лучше заранее оценить свои материальные ресурсы и финансовые возможности на настоящий момент и в ближайшие годы, экономический эффект от использования новой технологии, начальных затрат и стоимости функционирования системы.
Проведя такую оценку, некоторые организации вообще могут прийти к выводу, что инфраструктура открытых ключей им не нужна, а в их случае лучше применить другой инструментарий безопасности: например, VPN или программы шифрования файлов. Вместо всей инфраструктуры PKI иногда проще запустить только сервер сертификатов, который решает проблемы несанкционированного доступа к веб-контенту (IntranetSSL, см. выше).
Промежуточная или частная иерархия
В открытой иерархии все УЦ подчиняются корневому УЦ, открытый ключ которого встроен в общедоступное приложение, например, веб-браузер. В этом случае браузер может автоматически проверять валидность сертификатов, изданных всеми УЦ во всей иерархии, а также их издателей, что является бесспорным преимуществом.
Открытые иерархии обычно используются в тех случаях, когда требуется обмен информацией с неаффилированными сторонами или их аутентификация. Третьей доверенной стороной в данном случае выступает аутсорсинговый УЦ.
В случае частной иерархии конечный пользователь вручную добавляет открытый ключ корпоративного корневого УЦ в список доверенных ключей, встроенных в приложение. В этом случае вся ответственность за использование ключа ложится на самого пользователя. Частные иерархии больше подходят для закрытых сообществ, например, пользователей корпоративного портала.
Типичные примеры промежуточной или частной иерархии
- Выделенный частный корневой УЦ и иерархия (Private PKI)
GlobalSign может создавать и размещать частные иерархии, включая корневые и промежуточные. Они построены на той же защищённой инфраструктуре, которая используется для поддержки собственных корневых УЦ в открытой иерархии.
- Фирменный частный промежуточный УЦ, центр выдачи сертификатов
Брендовые промежуточные УЦ создаются специально для конкретного клиента, с цепочкой доверия до корневого УЦ в открытой иерархии. Эти промежуточные узлы тоже могут размещаться и поддерживаться GlobalSign, что облегчает бремя управления PKI и экспертных знаний для внутренних команд.
- Общий открытый корневой УЦ (платформа Managed PKI)
Хотя в определённых ситуациях требуются выделенные корневые УЦ и иерархии, большинство организаций может выполнить нормативные требования к сертификатам с помощью специализированных сервисов на платформе управления PKI (Managed PKI). Портал для управления сертификатами «всё в одном» обеспечивает расширенные возможностями выставления счетов, управления пользователями, отчетность и т. д.
- Общий частный корневой УЦ (IntranetSSL)
Решение IntranetSSL, доступное через платформу управления PKI, обеспечивает экономичный способ выдачи и управления сертификатами SSL/TLS для внутренних серверов и приложений. Эти сертификаты выдаются от общего, непубличного Центра сертификации GlobalSign, поэтому могут включать конфигурации, которые форум CA/Browser запрещает использовать в публичных сертификатах (например, срок действия более трёх лет, внутренние имена серверов или зарезервированные IP-адреса).
- Корень доверия IoT
Корни доверия IoT обладают той же гибкостью, что и традиционные корни доверия, но настроены на специфические требования IoT. Выделенные частные иерархии, фирменные общедоступные промежуточные УЦ, корневые центры в открытой или частной иерархии могут использоваться для защиты устройств, платформ, шлюзов и сетей IoT в зависимости от требуемого уровня доверия.
- Особенная иерархия доверия
GlobalSign поддерживает практически любую конфигурацию иерархии. Если нужна модель, отличная от описанной выше, или сразу не совсем понятно, какая архитектура лучше всего подходит для специфической экосистемы, то это лучше обсудить со специалистом и консультантом, чтобы построить архитектуру доверия, которая соответствует конкретным потребностям.
Для любого из приведённых примеров сопровождение УЦ можно отдать на аутсорсинг. Сохраняется возможность брендирования, но иерархии размещаются и управляются GlobalSign в безопасных центрах обработки данных с проверенным оборудованием и программным обеспечением. С нестандартными сценариями помогут справиться инженеры сопровождения.
Кажется, что отдавая свою иерархию доверия на аутсорсинг, вы понижаете уровень безопасности, но на практике выходит наоборот. Это гарантирует, что все компоненты УЦ должным образом защищены и настроены в соответствии с последними передовыми отраслевыми практиками. Дополнительное преимущество — экономия затрат и ресурсной нагрузки на внутренние команды для поддержки PKI. Только в некоторых редких случаях (например, проверка/дешифрование SSL) промежуточное звено должно размещаться у клиента.
Комментарии (8)
rsashka
05.08.2019 11:47А не кажется, что понятия «удостоверяющий центр» и корневой сертификат для компании (читай: внутренний интранет), это понятия совершенно разного масштаба и соответственно разной стоимости?
Удостоверяющий центр, это в первую очередь реализация требований законодательства к УЦ, а корневой сертификат можно особо не заморачиваясь выпустить в ИТ отделе в соответствии с внутренним регламентам компании.
И разница в стоимости между этими решениями даже не на порядок, а несколько порядков.
KonstantinSpb
05.08.2019 11:54опен-сорсные системы в качестве примера забыли привести, например www.ejbca.org
ky0
05.08.2019 12:58Без порядка цен и принципа ценообразования пост чуть более, чем маркетингов.
GlobalSign_admin Автор
06.08.2019 11:18Расчёт стоимости обслуживания подчинённого УЦ зависит от типа сертификатов а также от числа сертификатов, которые вы планируете выпускать в год.
Для получения более подробной информации Вы можете связаться с менеджерами: sales-ru@globalsign.com
mwambanatanga
06.08.2019 03:56Для чего вы используете промежуточный или частный УЦ?
Для того, чтобы мой работодатель мог отслеживать мой сетевой трафик. Ничего он не отслеживает (только антивирус блочит «подозрительные» сайты), но инструмент имеется.
amarao
Поясните для непонимающих, пожалуйста, как публика (вне компании) защищена от сертификатов от этого "частного PKI"?
Т.е. если кто-то выпустит частный сертификат для сайта tor.org, то есть два варианта:
TheGodfather
Если случай (2), то отличается тем, что в рамках большой компании с огромным количеством таких «почти-self-signed» сертификатов (читай: внутренний интранет) можно настроить браузер, чтобы доверять корню компании. И будет некая уверенность, что maintainer сервиса получил нормальный сертификат по политикам компании, а не просто self-signed.
P.S. И да, в рамках большой компании IT отдел может преднастроить все используемые ОС (как минимум, основные операционки на рабочих компьютерах), чтобы добавить корневой сертификат компании в доверенные, так что сотрудникам вообще не нужно будет специальных манипуляций.
amarao
Я же специально сказал — self-signed CA, а не self-signed сертфикаты.
Нет никакой разницы — устанавливать (говоря "доверяю") корпоративный CA у которого самоподпись или устанавливать CA (говоря "доверяю") который пописан чужим CA, которому не доверяешь by-default?
… На самом деле вот что бы я реально хотел видеть — это возможность иметь автодоверительные (т.е. доверенные в браузерах) CA, у которых есть restriction по домену. Например, этот CA может выпускать любые сертификаты для поддоменов example.com. Автоматическое доверие, но только для поддоменов example.com.
Разница с wildcard в том, что компания может делать реальный CA, т.е. класть на фронт-энд сертификат front1.example.com, не рискуя при этом компрометацией critical.example.com.
Я не знаю, может ли такое быть сделано для intermediate CA в рамках текущих возможностей PKI или нет, но потребность в таком явно есть. Каждый раз, когда я звезду кладу на сервер, я понимаю, что я делаю что-то не так.