З розширенням спектра цифрових векторів атак цифрова ідентичність замінила традиційний мережевий периметр як основну межу безпеки. Організації більше не покладаються лише на фізичні міжмережеві екрани — натомість кожен запит на доступ, чи то від віддаленого працівника, хмарного сервісу або IoT-пристрою, має постійно перевірятися.
Протоколи автентифікації — це базові набори правил, що визначають, як облікові дані передаються й перевіряються та як встановлюється довіра в мережах. Вибір правильного стеку протоколів — не просто технічна деталь: він безпосередньо впливає на вразливість організації до загроз, повʼязаних з ідентичністю, на продуктивність користувачів і на відповідність регуляторним вимогам.
Чому мережеві протоколи автентифікації важливі?
Ідентичність — основний вектор сучасних витоків даних. Згідно зі звітом Verizon Data Breach Investigations Report (DBIR), понад 80% витоків даних через вебзастосунки спричинені викраденими, слабкими або підібраними методом повного перебору обліковими даними. Зловмисники активно використовують застарілі механізми автентифікації, застосовуючи складні техніки:
- Фішинг і атаки Adversary-in-the-Middle (AiTM): зловмисники розгортають проксі-сервери, щоб у реальному часі перехоплювати одноразові коди, паролі та традиційні сесійні токени з обмеженим терміном дії.
- Підстановка облікових даних (credential stuffing) і атаки повного перебору: автоматизовані боти перевіряють мільярди злитих комбінацій імені користувача та пароля на корпоративних порталах.
- Pass-the-Hash і Pass-the-Ticket: атаки латерального переміщення всередині корпоративного середовища використовують архітектурні вразливості старіших доменних протоколів, як-от NTLM і Kerberos.
Впровадження сучасних захищених протоколів автентифікації усуває ці вектори атак: статичні секрети зникають, а ідентичність підтверджується криптографічно. Крім того, стандартизація автентифікації в усій Вашій екосистемі спрощує видачу доступів, знижує витрати служби підтримки на скидання паролів і полегшує звітність щодо відповідності вимогам.
Що таке протокол автентифікації?
Протокол автентифікації — це криптографічна послідовність, призначена для перевірки ідентичності субʼєкта (користувача, пристрою чи застосунку), який запитує доступ до системи, мережі або ресурсу. На відміну від авторизації, яка визначає, які дії користувач може виконувати після входу, автентифікація відповідає лише на одне запитання: «Чи Ви справді той, за кого себе видаєте?»
Ці протоколи спираються на три основні фактори ідентичності:
- Те, що Ви знаєте: паролі, PIN-коди або спільні секрети.
- Те, що Ви маєте: апаратні ключі безпеки, смарт-картки або застосунки-автентифікатори.
- Те, ким Ви є: біометричні дані, як-от відбиток пальця, сканування обличчя або розпізнавання райдужної оболонки ока.
Технічно протоколи автентифікації визначають точні схеми обміну повідомленнями, математичні алгоритми (як-от RSA, ECC або HMAC) і структури корисного навантаження, що використовуються між трьома основними ролями:
- Клієнт / запитувач (supplicant): субʼєкт, що запитує доступ.
- Довірена сторона (RP) / постачальник послуг (SP): застосунок або ресурс, на якому розміщена точка контролю доступу.
- Постачальник ідентифікації (IdP) / сервер автентифікації: центральний механізм, що перевіряє облікові дані та видає токени авторизації.
Основні типи протоколів автентифікації
Протоколи автентифікації еволюціонували разом зі зміною архітектури: сучасні протоколи автентифікації підтримують розподілені вебсервіси, федеративні хмарні ідентичності та безпарольну автентифікацію поряд із традиційними доменними системами.
Ці протоколи та стандарти мають різне призначення: одні перевіряють ідентичність користувача чи пристрою (автентифікація), інші надають делегований доступ до ресурсів (авторизація), а стандарти федерації дають змогу обмінюватися даними про ідентичність між довіреними системами. На практиці вони часто працюють разом, забезпечуючи захищений доступ у корпоративних середовищах.
FIDO2 / WebAuthn і CTAP
- Що це: FIDO2 — це набір стандартів безпарольної та багатофакторної автентифікації (MFA) на основі криптографії з відкритим ключем. Він поєднує Web Authentication API (WebAuthn), що дає змогу вебзастосункам створювати й використовувати облікові дані з відкритим ключем, із протоколом Client to Authenticator Protocol (CTAP), що забезпечує звʼязок між клієнтським пристроєм і зовнішнім автентифікатором, наприклад апаратним ключем безпеки.
- Ключові переваги:
- Стійкість до фішингу: привʼязки суворо обмежені конкретними доменними іменами (привʼязка до джерела, origin binding). Зловмисники, що використовують проксі-сайти, не можуть повторно застосувати перехоплені криптографічні підписи на справжніх доменах.
- Безпарольність: усуває статичні спільні секрети, що зберігаються на центральних серверах; закриті ключі ніколи не залишають захищеного анклаву апаратного пристрою користувача.
- Збереження конфіденційності: біометрична перевірка відбувається повністю локально на автентифікаторі кінцевого пристрою користувача й ніколи не передається мережею.
- Основні сценарії використання: корпоративний безпарольний вхід на робочі станції, керування привілейованим доступом (PAM), вебпортали з високим рівнем захисту та споживчі банківські застосунки.
SAML 2.0 (Security Assertion Markup Language)
- Що це: відкритий стандарт на основі XML для обміну даними автентифікації та авторизації між постачальником ідентифікації (IdP) і постачальником послуг (SP). Докладніше читайте в нашому огляді що таке SAML і як він працює.
- Ключові переваги: забезпечує корпоративний єдиний вхід (SSO), що дає змогу користувачам один раз увійти з єдиним набором облікових даних і отримати доступ до багатьох незалежних вебзастосунків.
- Основні сценарії використання: корпоративний доступ до SaaS-застосунків (наприклад, Salesforce, Google Workspace, Microsoft 365), інтегрованих із централізованими системами ідентифікації.
OAuth 2.0 і OpenID Connect (OIDC)
- Що це: OAuth 2.0 — це фреймворк авторизації, що надає стороннім застосункам обмежений доступ до ресурсів користувача. OpenID Connect (OIDC) доповнює OAuth 2.0 рівнем ідентифікації: він видає криптографічно підписаний ID-токен (зазвичай у форматі JSON Web Token, або JWT), який підтверджує застосунку ідентичність автентифікованого користувача.
- Ключові переваги: легка, зручна для API структура JSON; оптимізовано для мобільних застосунків, односторінкових застосунків (SPA) і мікросервісів.
- Основні сценарії використання: сучасні веб- і мобільні застосунки, захист RESTful API та федеративний вхід для споживачів («Увійти через Google/Apple»).
Kerberos
- Що це: мережевий протокол автентифікації, розроблений у MIT, що працює на основі механізму видачі квитків (тікетів) і використовує симетричну криптографію.
- Ключові переваги: паролі не передаються мережею; підтримується взаємна автентифікація клієнта та сервера.
- Основні сценарії використання: домени Active Directory у локальній інфраструктурі, автентифікація в інтранеті та доступ до корпоративних файлових ресурсів.
HOTP / TOTP (RFC 4226 / RFC 6238)
- Що це: HMAC-Based One-Time Password (HOTP) генерує динамічні одноразові коди на основі лічильника. Time-Based One-Time Password (TOTP) генерує коди, обчислені зі спільного секретного ключа та поточного часу (зазвичай вони змінюються кожні 30 секунд).
- Чому популярність знижується: хоча TOTP став значним кроком уперед порівняно зі статичними паролями, він не стійкий до фішингу. Зловмисники, що використовують автоматизовані AiTM-проксі (як-от Evilginx), можуть змусити користувачів ввести 6-значний код TOTP на шахрайському сайті та перехопити і пароль, і активний сесійний файл cookie, повністю обійшовши захист MFA.
Застарілі мережеві протоколи (RADIUS, TACACS+, NTLM)
- RADIUS / TACACS+: протоколи для централізації автентифікації, авторизації та обліку (AAA) для пристроїв мережевого доступу, як-от VPN-шлюзи, комутатори й маршрутизатори.
- NTLM (NT LAN Manager): застарілий набір протоколів автентифікації Microsoft за схемою «виклик — відповідь», що працює поверх зʼєднань SMB, RPC і HTTP.
- Обмеження безпеки: NTLM дуже вразливий до атак ретрансляції (relay), pass-the-hash та офлайн-атак повного перебору. Microsoft активно рекомендує відмовитися від NTLM на користь Kerberos і сучасних процесів FIDO2/WebAuthn. Сучасні фреймворки безпеки прямо вимагають поступово виводити з експлуатації протоколи, що передають дані відкритим текстом або використовують слабкі хеші.
Протоколи автентифікації за сценаріями використання
Різні операційні контексти потребують різного вибору протоколів, щоб збалансувати високий рівень захисту ідентичності, технічну сумісність і зручність для користувачів.
| Сценарій використання | Рекомендовані протоколи | Основні цілі безпеки |
|---|---|---|
| Корпоративний SSO і хмара | OIDC, SAML 2.0, FIDO2 | Централізоване керування ідентичністю, відкликання сесій, стійкість до фішингу |
| Вхід на робочий стіл і в домен | FIDO2, Kerberos, смарт-картка (X.509) | Захист від pass-the-ticket/hash, підтримка входу в офлайні |
| Мережевий і VPN-доступ | EAP-TLS, RADIUS із MFA, IPsec | Довіра до пристроїв на основі сертифікатів, зашифроване тунелювання |
| Привілейований доступ (PAM) | FIDO2 (апаратні ключі), взаємний TLS | Сувора апаратна привʼязка, нульова толерантність до викрадення облікових даних |
Корпоративний єдиний вхід (SSO) і хмарні застосунки
- Сценарій: працівникові щодня потрібен доступ до десятків вебзастосунків (SaaS, внутрішніх інструментів розробників, HR-порталів) без постійного введення різних облікових даних.
- Протоколи: OpenID Connect (OIDC), SAML 2.0, FIDO2/WebAuthn.
- Галузева тенденція: перехід від традиційної багатофакторної автентифікації «пароль + TOTP» до безпарольного SSO на основі FIDO2 у процесах входу. Це знижує ризик AiTM-фішингу й водночас усуває втому від паролів.
Вхід на робочий стіл, робочу станцію та в домен (Windows / macOS / Linux)
- Сценарій: захист локального та віддаленого доступу до ОС на корпоративних кінцевих пристроях — як онлайн, так і офлайн — з відмовою від вразливих локальних паролів.
- Протоколи: FIDO2 / CTAP2, Kerberos, смарт-картка / PKI (X.509).
- Галузева тенденція: відмова від NTLM і доменних облікових даних на основі паролів на користь безпарольного Windows Hello for Business або спеціалізованих апаратних токенів безпеки, які нативно інтегруються в архітектуру ідентифікації кінцевого пристрою.
Віддалений доступ і мережева інфраструктура (VPN, Zero Trust Network Access)
- Сценарій: захист доступу до інфраструктури для віддалених працівників, які підключаються через корпоративні VPN, мережі Wi-Fi (802.1X) та адміністративні сесії SSH.
- Протоколи: EAP-TLS, RADIUS, IPsec, SSH з відкритими ключами.
- Галузева тенденція: заміна статичних паролів VPN і push-сповіщень автентифікацією клієнтів на основі сертифікатів (EAP-TLS), інтегрованою з рішеннями Zero Trust Network Access (ZTNA).
Порівняльна таблиця протоколів автентифікації
Порівняйте поширені протоколи автентифікації за роллю та рівнем безпеки.
| Протокол або метод | Стійкість до фішингу | Основне застосування | Підтримка безпарольності | Впровадження та супровід |
|---|---|---|---|---|
| FIDO2 / WebAuthn | Вбудована за умови коректної перевірки автентифікації | Веб, IdP, вхід у підтримувані ОС | Так | Середня складність: реєстрація та відновлення |
| SAML 2.0 | Залежить від методу IdP та інтеграції | Веб-SSO | Через IdP | Середня складність: довіра та сертифікати |
| OAuth 2.0 / OIDC | OAuth — це авторизація; для OIDC залежить від IdP і процесу | API; вхід у веб- і мобільні застосунки через OIDC | Через IdP або облікові дані робочих навантажень | Середня складність: процеси та перевірка токенів |
| Kerberos | Залежить від первинної автентифікації та розгортання | Вхід у домен, внутрішні сервіси | Так (через PKINIT / розширення для сертифікатів смарт-карток X.509) | Вища складність: KDC, ключі, квитки |
| LDAP / LDAPS | Прості паролі вразливі до фішингу; для SASL залежить від механізму | Доступ до каталогу, привʼязки (bind) застосунків | Можлива з відповідними механізмами SASL | Залежить від методу привʼязки та клієнтів |
| RADIUS | Залежить від EAP або іншого методу автентифікації | Wi-Fi, дротовий доступ, VPN | З методами на основі сертифікатів | Від середньої до вищої складності з PKI |
| TACACS+ | Немає вбудованої стійкості до фішингу користувачів | Адміністрування мережі | Залежить від реалізації | Середня складність: політики пристроїв і транспорт |
| HOTP / TOTP | Не стійкі до фішингу | MFA для вебу та VPN | Можна використовувати без пароля; рівень надійності різний | Від низької до середньої складності: початкові значення (seed) і відновлення |
Як обрати протокол автентифікації для Вашого підприємства
Вибір правильного набору засобів автентифікації потребує оцінки Вашого поточного технічного боргу, регуляторного середовища та цільової архітектури. Керівникам з інженерії безпеки та інфраструктури варто застосовувати структуровану оцінку з трьох кроків.
1. Аналіз інфраструктури
- Складіть перелік застарілих застосунків і хмарних (cloud-native) застосунків. Сучасні застосунки зазвичай підтримують OIDC або SAML, тоді як застарілим застосункам і товстим клієнтам можуть знадобитися проксі автентифікації чи інші механізми інтеграції.
- Оцініть екосистему кінцевих пристроїв (Windows, macOS, Linux, тонкі клієнти), щоб переконатися, що ОС нативно підтримують сучасні постачальники облікових даних, як-от WebAuthn або FIDO2 через апаратні автентифікатори.
2. Перехід до Zero Trust і стійкої до фішингу MFA
- Узгодьте вибір протоколів із настановами CISA (Cybersecurity and Infrastructure Security Agency — Агентства з кібербезпеки та захисту інфраструктури США) щодо стійкої до фішингу MFA. Надавайте пріоритет FIDO/WebAuthn у підтримуваних сценаріях автентифікації користувачів, а для відповідних сценаріїв доступу до мережі та пристроїв розгляньте автентифікацію на основі сертифікатів.
- Відмовтеся від залежності від SMS, push-сповіщень (вразливих до атак на основі втоми від MFA) і кодів TOTP у критичних системах.
3. Зіставлення з вимогами відповідності та стандартами
Протоколи автентифікації — це ключовий механізм виконання суворих вимог фреймворків відповідності у сфері кібербезпеки. Замість того щоб сприймати відповідність як формальність, оцініть, як конкретний вибір протоколу реалізує чіткі технічні засоби контролю безпеки:
| Нормативний акт | Обовʼязковий засіб контролю безпеки | Технічна реалізація на рівні протоколу |
|---|---|---|
| NIST SP 800-63B | Вимоги рівня надійності автентифікатора 3 (AAL3) | Впровадження апаратно привʼязаних автентифікаторів зі стійкістю до підміни верифікатора (наприклад, FIDO2/WebAuthn) у межах архітектури, що відповідає AAL3 |
| PCI DSS 4.0 | Вимога 8.3 — багатофакторна автентифікація (MFA) для доступу до CDE | Розгортання стійких до фішингу процесів MFA (наприклад, FIDO2/WebAuthn) для запобігання викраденню облікових даних і перехопленню сесій |
| HIPAA / GDPR | Технічні запобіжні заходи для контролю доступу та захисту даних | Використання надійної криптографічної автентифікації (наприклад, WebAuthn, mTLS) для зниження ризику несанкціонованого доступу до чутливих середовищ |
| Директива NIS2 | Заходи з управління ризиками кібербезпеки та гігієна контролю доступу | Стандартизація на сучасних відкритих протоколах (SAML 2.0, OIDC, FIDO2) у межах централізованого постачальника ідентифікації для застосування узгоджених політик автентифікації |
- NIST SP 800-63B: AAL3 вимагає апаратної автентифікації, стійкості до підміни верифікатора, двох різних факторів автентифікації та відповідності чинним вимогам до криптографії й автентифікаторів. FIDO2/WebAuthn може забезпечити стійкість до підміни верифікатора, але використання лише цього протоколу не гарантує відповідності AAL3. Уся реалізація автентифікації має відповідати всім чинним вимогам NIST.
- PCI DSS 4.0: вимога 8.3 передбачає надійну реалізацію MFA для будь-якого доступу до середовища даних власників карток (CDE). Стійкість до фішингу на рівні протоколу допомагає запобігти викраденню токенів і знижує ризики, повʼязані з атаками adversary-in-the-middle (AiTM).
- HIPAA і GDPR: обидва нормативні акти вимагають технічних запобіжних заходів, контролю доступу та захисту від несанкціонованого розкриття даних. Архітектури протоколів на основі криптографії з відкритим ключем (як-от WebAuthn або mTLS) є надійними технічними заходами, що допомагають захистити доступ із кінцевих пристроїв і запобігти передаванню облікових даних відкритим текстом.
- Директива NIS2: відповідно до NIS2 європейські організації мають впроваджувати суворі політики управління ризиками кібербезпеки та контролю доступу. Стандартизація автентифікації за допомогою федеративних протоколів (SAML 2.0, OIDC) і сучасних стандартів (FIDO2) у межах централізованої архітектури ідентифікації сприяє узгодженому застосуванню політик і контролю доступу, придатному для аудиту, в усіх IT-середовищах.
Стратегічне впровадження з Hideez
Перехід корпоративної інфраструктури від застарілих протоколів на основі паролів або TOTP до сучасних стандартів, стійких до фішингу, може бути складним — особливо коли потрібно поєднати застарілі доменні середовища із сучасними хмарними робочими навантаженнями. Платформа Hideez Workforce Identity усуває цей архітектурний розрив, пропонуючи уніфіковану інфраструктуру для безпарольної, стійкої до фішингу автентифікації в різноманітних середовищах:
- Апаратно привʼязаний захист FIDO2: Hideez пропонує спеціалізовані апаратні ключі безпеки (Hideez Key) і програмне забезпечення безпеки, які нативно працюють зі стандартами WebAuthn/FIDO2 та захищають робочі станції, SaaS-застосунки й привілейовану інфраструктуру від AiTM-фішингу.
- Модернізація застарілих систем: Hideez забезпечує безпарольний вхід у домен Windows і доступ до робочого столу без потреби повністю перебудовувати наявну інфраструктуру Active Directory. Рішення поєднує застарілу локальну автентифікацію із сучасними хмарними постачальниками ідентифікації. Дізнайтеся більше про Hideez AuthShield.
- Централізоване керування ключами: для IT-адміністраторів і CISO Hideez Enterprise Server забезпечує централізоване керування фізичними ключами безпеки, операції життєвого циклу ідентичностей, віддалену видачу облікових даних і автоматичне відкликання сесій, спрощуючи звітність щодо відповідності для аудитів за NIST, PCI DSS та ISO 27001.
Ключові висновки
- Обирайте протоколи відповідно до вимог безпеки та сценаріїв використання. FIDO2/WebAuthn — надійний варіант для стійкої до фішингу безпарольної автентифікації користувачів, тоді як Kerberos залишається важливим для доменних середовищ Windows. OIDC і SAML 2.0 підтримують федеративну ідентифікацію та корпоративний єдиний вхід (SSO).
- Надавайте пріоритет автентифікації, стійкій до фішингу. Паролі та коди TOTP можна скомпрометувати за допомогою фішингу й атак adversary-in-the-middle (AiTM). FIDO2/WebAuthn і правильно реалізована автентифікація на основі сертифікатів надійніше захищають від викрадення облікових даних.
- Враховуйте всю архітектуру автентифікації. Вибір протоколу має враховувати сумісність застосунків, можливості кінцевих пристроїв, інтеграцію з постачальником ідентифікації, безпеку сесій, відновлення облікових даних і постійний супровід.
- Модернізуйте застарілу автентифікацію поступово. Організації можуть зменшити залежність від застарілих протоколів, як-от NTLM, запроваджуючи надійніші методи автентифікації та зберігаючи сумісність із наявною інфраструктурою й сервісами.
- Узгоджуйте засоби контролю автентифікації з бізнес-вимогами та вимогами відповідності. Оцініть потреби безпеки кожного середовища, зокрема хмарних застосунків, доменних сервісів, VPN, API та привілейованих облікових записів. Обирайте протоколи й конфігурації, що забезпечують потрібний контроль доступу та рівень гарантій безпеки.
- Використовуйте централізоване управління ідентичністю там, де це доречно. Інтеграція сучасних стандартів автентифікації з корпоративною інфраструктурою ідентифікації може спростити керування доступом, покращити видимість і забезпечити узгоджені політики безпеки для всіх застосунків і пристроїв.
- Плануйте впровадження та керування життєвим циклом. Захищена автентифікація потребує належного налаштування, керування ключами та сертифікатами, процедур відновлення облікових записів, моніторингу та своєчасної відмови від вразливих методів.
Поширені запитання
Який протокол автентифікації найбезпечніший?
FIDO2/WebAuthn — надійний вибір для стійкого до фішингу входу користувачів. Методи на основі сертифікатів також підходять для автентифікації в мережі та робочих навантажень. Оптимальний вибір залежить від ресурсу, а в оцінку варто включити відновлення доступу й захист сесій.
Чи може FIDO2 повністю замінити Kerberos?
Ні, не безпосередньо. FIDO2 може автентифікувати користувача під час входу, тоді як Kerberos надає квитки для доменних сервісів. Підтримувані розгортання Windows можуть поєднувати безпарольний вхід із доступом через Kerberos. Щоб відмовитися від Kerberos, потрібно змінити залежності автентифікації сервісів, які на нього спираються.
Який протокол використовувати для корпоративної VPN?
Для VPN із підтримкою федерації використовуйте SAML або OIDC зі стійкою до фішингу MFA на боці IdP. Ще один надійний варіант — автентифікація на основі сертифікатів. У разі RADIUS оцініть базовий метод автентифікації та захист транспорту.
Hideez поєднує апаратні ключі FIDO2, безпарольний вхід у домен Windows і централізоване керування ключами, тож Ви можете відмовитися від NTLM, TOTP і статичних паролів без перебудови стеку ідентифікації. Замовте демонстрацію, щоб підібрати протоколи для Вашого середовища, або приєднайтеся до партнерської програми, щоб пропонувати своїм клієнтам стійку до фішингу автентифікацію.
