Паролата е мъртва. Готова ли е вашата мрежа за нейната подмяна?
Вашата организация е прекарала години в заключване на входната врата: защитни стени, VPN мрежи, многофакторно удостоверяване, защита на крайните точки. Но има един по-тих въпрос, на който много ИТ екипи все още не са отговорили напълно: кога устройство, сървър или услуга се опитва да докаже... това е, което твърди, че е, какво всъщност подкрепя това твърдение?
За много организации честният отговор е „парола“ или „API ключ“. И двете могат да бъдат откраднати, фиширани или възпроизведени от всеки, който се добере до тях.
Има по-добър отговор и той е такъв, който браузърите и root програмите вече ефективно изискват: специален сертификат за удостоверяване на клиента.
Разгледайте опциите за сертификат за удостоверяване на клиента
Защо това е изведнъж спешно
Ето промяната, която предизвика проблема. От 15 юни 2026 г. програмата Root на Chrome изисква новоиздадени публично доверени права. TLS сертификатите на сървъра да включват само serverAuth EKU. Mozilla, Apple и Microsoft са приели съвместими правила за root програми, с което прекратяват използването на clientAuth EKU в публично доверени TLS сървърни сертификати.
Ако вашата организация е използвала повторно стандарт TLS сертификат, който да обработва и удостоверяване на клиента или взаимен TLS (mTLS), този пряк път вече не работи. Всеки сертификат с двойно предназначение, който е служил едновременно за самоличност на сървър и клиент, вече не е валиден за удостоверяване на клиента и трябва да бъде заменен със сертификат, създаден специално за тази цел, който SSL предоставя.
Всяка организация, която все още разчита на стар сертификат с двойно предназначение, вече не е в съответствие с изискванията и колкото по-дълго не се обръща внимание на проблема, той само нараства. Той засяга всеки, който използва удостоверяване, базирано на сертификати, за...TLS, достъп с нулево доверие, VPN, достъп до Wi-Fi мрежа, IoT устройства, системи за промишлен контрол или платформи за енергиен пазар.
Какво всъщност прави сертификатът за удостоверяване на клиента
Помислете за обичайното си TLS сертификат като идентификационен номер на вашия сървър. Той доказва, че сървърът е този, за когото се представя, когато браузърът ви се свърже с него. Сертификатът за удостоверяване на клиент обръща този разговор. Той позволява на устройство, потребител, сървър или услуга да докаже собствената си идентичност обратно на това, към което се свързва.
Механиката е важна тук, но само заради това, което означава за вашия бизнес. Частният ключ се генерира на самото устройство и никога не го напуска. Публично доверен сертифициращ орган (като SSL) подписва само публичния ключ, като го свързва с потвърдена самоличност. Това означава, че няма парола, която да се намира някъде в база данни и да чака да бъде фиширана, няма споделена тайна, която да изтече при нарушение, и няма API ключ, копиран в скрипт, който някой е забравил да завърти.
Анулирането работи и за всеки сертификат, а не за всеки автопарк. Ако лаптоп бъде изгубен, достъпът на изпълнител прекрати или устройство бъде компрометирано, анулирате този сертификат и всички останали крайни точки продължават да работят без прекъсване.
Основните предимства, накратко
Ето какво всъщност ви осигурява преминаването към специален сертификат за удостоверяване на клиент:
- Идентичност, устойчива на фишинг. Частният ключ никога не напуска устройството, така че няма парола за кражба, възпроизвеждане или фишинг.
- Съвместим с Chrome и root програми. Специализиран EKU за clientAuth, който отговаря на изискванията на CA/Browser Forum и root store, така че да не бъдете изненадани от промяната в политиката, която е причинила всичко това.
- Йерархия, ползваща се с обществено доверие. Издадено от публичен сертификат, одитиран от WebTrust на SSL PKI, без да е необходимо да разпространявате частен корен в стека на разчитащата страна.
- Три нива на валидиране. IV, OV и IV+OV (Спонсор), така че идентификационните данни да съответстват на вашата политика за самоличност и всички регулаторни изисквания, по които работите.
- Гранулирано отменяне. Анулирайте един сертификат в момента, в който дадено устройство бъде изгубено, изведено от експлоатация или компрометирано, без да докосвате останалата част от вашия парк от сертификати.
- Издаване, първо базирано на API. Проблем в голям мащаб днес чрез REST API на SSL, с автоматизация на ACME и SCEP/EST в процес на разработка.
Съпоставяне на идентификационните данни със случая на употреба
Индивидуалната валидация (IV) потвърждава истинската самоличност на дадено лице, което я прави естествено подходяща за устройства на служители, BYOD политики и индивидуален достъп до крайни точки. Валидацията на организацията (OV) потвърждава правното съществуване на компания, което е необходимо за сървъри, виртуални машини, сервизни акаунти и API клиенти. А за ситуации, в които са ви необходими и двете, като например привилегировани потребители, изпълнители или регулирани индустрии, има IV+OV (Sponsor Validation), която едновременно обвързва самоличността на дадено лице със спонсориращата организация.
Тази гъвкавост е важна, защото удостоверяването на клиента се появява на повече места, отколкото повечето хора осъзнават:
|
Използвайте делото |
Ниво на сертификат |
Съвместим с |
бележки |
|
mTLS / Нулево доверие |
ОВ / IV+ОВ |
Nginx, Envoy, Istio, Kong, AWS API GW |
Взаимен TLSи двамата партньори се удостоверяват с X.509 |
|
VPN (базирана на сертификат) |
IV / ОВ / IV+ОВ |
Cisco ASA/FTD, Пало Алто, 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 |
Удостоверява PLC, HMI, исторически възли в OT мрежи |
|
Енергийни пазари на NAESB |
IV+OV |
NAESB WEQ-12 съвместими платформи |
Необходими идентификационни данни за OATI, PowerSecure и други EIS платформи |
|
API шлюз за удостоверяване |
ОВ / IV+ОВ |
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 и Apigee.
- ИКС и ОТ: Платформи, съобразени с IEC 62443, включително слоевете за откриване и удостоверяване на активи в Claroty, Nozomi Networks и Dragos.
Извличане на сертификати от вратата
Независимо как вашата организация предпочита да издава сертификати, SSL има подходящ път:
|
Начин на доставка |
За кого е предназначено |
Как работи |
|
Уеб потребителски интерфейс (табло за управление на ssl.com) |
ИТ администратори, по-малки внедрявания, еднократно издаване |
Влезте в ssl.com, изберете „Удостоверяване на клиента“, изберете ниво на валидиране, завършете проверката, генерирайте и изтеглете сертификата. Не се изисква кодиране. |
|
REST API |
DevOps, CI/CD конвейери, осигуряване на голям флот |
Поръчка на програмни сертификати, CSR подаване и изтегляне чрез документирания REST API на SSL. Поддържа групово издаване и интеграция с платформи за оркестрация. |
|
ACME / SCEP / EST |
Enterprise MDM, автоматизация по стандарта IETF (планирано) |
Автоматизация на жизнения цикъл, базирана на протоколи, чрез ACME (RFC 8555), SCEP и EST (RFC 7030). В процес на разработка — свържете се с отдела по продажбите за времева рамка и подробности за ранен достъп. |
Как да купя
Сертификатите за удостоверяване на клиента са достъпни директно от SSL без минимален ангажимент:
- Самообслужване. Конфигурирайте и купете онлайн.
- Предприятие и обем. Свържете се с екипа по продажбите на SSL за ценообразуване на едро, специално управление на акаунти и NAESB-специфично адаптиране.
- Частна йерархия или нужди от двоен EKU. Ако имате нужда от частна йерархия, персонализиран профил на сертификат или сертификат с двоен EKU, Частни SSL сертификати PKI продукти (Частни сертификати с висока степен на сигурност, специализирани PKIи Enterprise PKI) са правилният път. Свържете се с отдела по продажбите за препоръка.
Долната линия
Промяната в clientAuth EKU не беше просто техническа бележка под линия. Това беше принудителна функция, която подтиква организациите най-накрая да отделят идентичността на сървъра от идентичността на клиента и да заменят паролите и API ключовете с нещо, което не може да бъде фиширано или възпроизведено.
SSL управлява публичен сертифициращ орган, одитиран от WebTrust, повече от 20 години, а сертификатът за удостоверяване на клиента е директният и съвместим път напред за всяка организация, която се нуждае от специализирана клиентска идентичност в голям мащаб, независимо дали става въпрос за осигуряване на мрежа с нулево доверие, парк от IoT устройства или регулирана от NAESB платформа за търговия.
Ако не сте сигурни дали текущата ви настройка все още разчита на сертификат с двойно предназначение, сега е моментът да проверите. Датата на влизане в сила вече е отминала, така че запълването на тази празнина вече не е по избор, но ние сме готови да ви помогнем.
Твоят м ли еTLS засегнати от премахването на clientAuth EKU? Одитирайте сертификатите си за clientAuth EKU, след което говорете със SSL за мигриране към специални сертификати за удостоверяване на клиента (или частни PKI само за вътрешни / с двойни EKU нужди) преди изтичането на текущите ви сертификати:
