Пароль устарел. Готова ли ваша сеть к его замене?
Ваша организация годами защищала свои «входные двери»: брандмауэры, VPN, многофакторная аутентификация, защита конечных точек. Но есть более тихий вопрос, на который многие ИТ-команды еще не дали полного ответа: когда устройство, сервер или служба пытаются доказать Это тот, за кого себя выдаёт.Что же на самом деле подтверждает это утверждение?
Для многих организаций честный ответ — «пароль» или «ключ API». И то, и другое может быть украдено, использовано в фишинге или скопировано любым, кто получит к ним доступ.
Есть более удачное решение, и теперь браузеры и программы с правами root фактически требуют его: выделенный сертификат аутентификации клиента.
Изучите варианты сертификатов аутентификации клиента.
Почему это внезапно стало срочно
Вот изменение, которое привело к возникновению проблемы. С 15 июня 2026 года для получения root-прав в Chrome требуется наличие недавно выданных общедоступных доверенных учетных записей. TLS Сертификаты серверов должны включать только расширение расширенной кодировки serverAuth. Mozilla, Apple и Microsoft приняли совместимые политики для корневых программ, прекратив использование расширений расширенной кодировки clientAuth в общедоступных доверенных системах. TLS сертификаты сервера.
Если ваша организация повторно использовала стандарт TLS сертификат для обработки аутентификации клиента или взаимное TLS (mTLS)Этот способ больше не работает. Любой сертификат двойного назначения, который служил одновременно и сервером, и клиентом, больше недействителен для аутентификации клиента и должен быть заменен сертификатом, специально разработанным для этой цели, что и обеспечивает SSL.
Любая организация, которая до сих пор использует старый сертификат двойного назначения, уже сегодня не соответствует требованиям, и чем дольше проблема остается без внимания, тем больше возрастает риск. Это затрагивает всех, кто использует аутентификацию на основе сертификатов.TLSДоступ по принципу «нулевого доверия», VPN, доступ к сетям Wi-Fi, устройства IoT, системы промышленного управления или платформы энергетического рынка.
Что на самом деле делает сертификат аутентификации клиента?
Подумайте о своем обычном TLS Сертификат используется в качестве идентификационного значка вашего сервера. Он подтверждает, что сервер является тем, за кого себя выдает, когда ваш браузер подключается к нему. Сертификат аутентификации клиента (CAT) меняет этот подход. Он позволяет устройству, пользователю, серверу или службе подтвердить свою личность тому, к чему они подключаются.
Здесь важны технические детали, но только потому, что они имеют значение для вашего бизнеса. Закрытый ключ генерируется на самом устройстве и никогда его не покидает. Общедоступный центр сертификации (например, SSL) подписывает только открытый ключ, связывая его с подтвержденной личностью. Это означает, что нет пароля, хранящегося где-то в базе данных и ожидающего фишинга, нет общего секрета, который может быть утечен при взломе, и нет ключа API, скопированного в скрипт, который кто-то забыл обновить.
Отзыв сертификатов также работает для каждого сертификата отдельно, а не для всего парка устройств. Если ноутбук потерян, доступ подрядчика прекращен или устройство скомпрометировано, вы отзываете этот один сертификат, и все остальные конечные точки продолжают работать без перебоев.
Основные преимущества вкратце
Вот что вы получаете, перейдя на выделенный сертификат аутентификации клиента:
- Идентификация, устойчивая к фишингу. Закрытый ключ никогда не покидает устройство, поэтому пароль невозможно украсть, скопировать или использовать для фишинга.
- Совместимо с Chrome и программами, имеющими права root. Выделенное расширение ключа аутентификации клиента (clientAuth EKU), соответствующее требованиям центра сертификации/форума браузера и хранилища корневых файлов, чтобы вы не столкнулись с проблемами, вызванными изменением политики, с которого все началось.
- Иерархия, пользующаяся общественным доверием. Опубликовано на основе общедоступных данных SSL, прошедших аудит WebTrust. PKIПри этом нет необходимости распределять частный корневой каталог по всему стеку зависимых сторон.
- Три уровня проверки. IV, OV и IV+OV (Спонсор), поэтому учетные данные соответствуют вашей политике идентификации и любым нормативным требованиям, в соответствии с которыми вы работаете.
- Гранулярная отмена. Отозывайте единый сертификат в момент потери, вывода из эксплуатации или компрометации устройства, не затрагивая остальную часть вашего парка устройств.
- Выдача API-ориентированного решения. Сегодня вы можете осуществлять масштабные эмиссии через REST API SSL, а в будущем планируется внедрение автоматизации ACME и SCEP/EST.
Сопоставление учетных данных с вариантом использования
Индивидуальная проверка (IV) подтверждает реальную личность конкретного человека, что делает её идеальным решением для устройств сотрудников, политик BYOD и индивидуального доступа к конечным точкам. Организационная проверка (OV) подтверждает юридическое существование компании, что необходимо для серверов, виртуальных машин, учетных записей служб и API-клиентов. А для ситуаций, когда требуется и то, и другое, например, для привилегированных пользователей, подрядчиков или регулируемых отраслей, существует IV+OV (проверка спонсора), которая одновременно связывает личность человека со спонсирующей организацией.
Такая гибкость важна, потому что аутентификация клиента используется гораздо чаще, чем многие думают:
|
Кейсы |
Уровень сертификата |
Совместимость с |
Заметки |
|
mTLS / Нулевое доверие |
Яйцеклетка / Внутривенное введение + Яйцеклетка |
Nginx, Envoy, Istio, Kong, AWS API GW |
Взаимный TLS; оба участника проходят аутентификацию с помощью X.509 |
|
VPN (на основе сертификатов) |
IV / OV / IV+OV |
Cisco ASA/FTD, Palo Alto, Fortinet, Juniper SRX |
Исключает использование VPN на основе паролей; устойчив к фишингу. |
|
Wi-Fi (802.1X / EAP-TLS) |
IV / OV |
Cisco ISE, Aruba ClearPass, Microsoft NPS |
Применение NAC; учетные данные находятся на устройстве, а не в пароле. |
|
Интернет вещей / Идентификация устройств |
OV |
AWS IoT Core, Azure IoT Hub, пользовательские брокеры |
Сертификат для каждого устройства; индивидуальная аннулирование без перепрошивки всего парка устройств. |
|
ОТ / SCADA / ICS |
OV |
Клароти, Нозоми, Драгос; стеки, поддерживающие стандарт IEC 62443. |
Проводит аутентификацию ПЛК, ЧМИ и узлов сбора данных в сетях операционных технологий. |
|
Энергетические рынки NAESB |
IV+ОВ |
Платформы, соответствующие NAESB WEQ-12 |
Необходимые учетные данные для OATI, PowerSecure и других платформ EIS. |
|
Аутентификация через API-шлюз |
Яйцеклетка / Внутривенное введение + Яйцеклетка |
Apigee, Kong, AWS API GW, Azure APIM |
Заменяет ключи API и JWT на идентификацию сервиса, привязанную к сертификату. |
Помимо этих конкретных сценариев использования, сертификаты работают практически во всей инфраструктуре, которую уже использует ваша команда:
- TLS стеки: OpenSSL, BoringSSL, NSS, SChannel, SecureTransport, wolfSSL и mbedTLS.
- VPN и удалённый доступ: Cisco AnyConnect/SecureClient, Palo Alto GlobalProtect, Fortinet FortiClient, OpenVPN и WireGuard (через внешнюю аутентификацию).
- NAC и 802.1X: Cisco ISE, Aruba ClearPass, Microsoft NPS/RADIUS, FreeRADIUS и Juniper Access Control.
- API-шлюзы: Kong, Nginx, Envoy, Istio, AWS API Gateway (mTLS), Azure API Management и Apigee.
- ICS и OT: Платформы, поддерживающие стандарт IEC 62443, включая уровни обнаружения активов и аутентификации в Claroty, Nozomi Networks и Dragos.
Выдача сертификатов
Независимо от того, какой способ выдачи сертификатов предпочитает ваша организация, SSL предлагает подходящий вариант:
|
Способ доставки |
Для кого это |
Как это работает |
|
Веб-интерфейс (панель управления ssl.com) |
ИТ-администраторы, небольшие развертывания, разовая выдача |
Войдите на сайт ssl.com, выберите «Аутентификация клиента», укажите уровень проверки, завершите проверку, сгенерируйте и загрузите сертификат. Программирование не требуется. |
|
REST API |
DevOps, конвейеры CI/CD, крупномасштабное обеспечение парка оборудования. |
Программный заказ сертификатов, CSR Отправка и загрузка данных осуществляется через документированный REST API SSL. Поддерживается массовая отправка и интеграция с платформами оркестрации. |
|
ACME / SCEP / EST |
Управление основными данными предприятия (MDM), автоматизация в соответствии со стандартами IETF (планируется) |
Автоматизация жизненного цикла на основе протоколов ACME (RFC 8555), SCEP и EST (RFC 7030). Разработка ведется — свяжитесь с отделом продаж для уточнения сроков и получения информации о раннем доступе. |
Как купить
Сертификаты аутентификации клиента можно получить напрямую от SSL без каких-либо минимальных обязательств:
- Самообслуживание. Настройте и приобретите онлайн..
- Корпоративный и массовый. Свяжитесь с отделом продаж SSL. для оптовых цен, выделенного управления учетными записями и НАЭСБ-специфическая процедура адаптации.
- Потребности в закрытой иерархии или одновременном обучении в двух университетах. Если вам нужна частная иерархия, пользовательский профиль сертификата или сертификат с двумя расширенными расширенными именованными цепями (EKU), SSL-частный PKI продукты (Частные сертификаты с высоким уровнем защиты, специализированные) PKIи Enterprise PKI) — это правильный путь. Свяжитесь с отделом продаж для получения рекомендации.
Выводы
Изменение расширенного ключа аутентификации клиента (clientAuth EKU) было не просто технической примечанием. Это стало фактором, подталкивающим организации к окончательному разделению идентификации сервера и идентификации клиента, а также к замене паролей и ключей API чем-то, что нельзя украсть или использовать повторно.
Компания SSL уже более 20 лет использует общедоступный центр сертификации, прошедший аудит WebTrust, и сертификат аутентификации клиента (Client Authentication Certificate, Client Authentication Certificate) — это прямой и соответствующий требованиям путь для любой организации, которой необходима выделенная идентификация клиента в масштабе предприятия, будь то защита сети с нулевым доверием, парка устройств IoT или торговой платформы, регулируемой NAESB.
Если вы не уверены, использует ли ваша текущая конфигурация сертификат двойного назначения, сейчас самое время это проверить. Срок действия сертификата уже истек, поэтому устранение этого пробела больше не является необязательным, но мы готовы помочь.
Ваш мTLS Вас затронуло удаление расширенного ключа аутентификации клиента (clientAuth EKU)? Проведите аудит ваших сертификатов на наличие расширенного ключа аутентификации клиента, а затем обсудите с SSL возможность перехода на выделенные сертификаты аутентификации клиента (или частные сертификаты). PKI (только для внутреннего использования / с поддержкой двух EKU) до истечения срока действия ваших текущих сертификатов:
