Безпека мікросервісів і вебзастосунків

Що таке мікросервіс авторизації

Мікросервіс авторизації:

• перевіряє, хто ти (автентифікація)
• вирішує, що тобі можна робити (авторизація)
• видає та перевіряє токени доступу (JWT та ін.)
• часто працює як Identity Provider (IdP) або частина API Gateway

Популярні рішення

Keycloak (open-source, від Red Hat)

• Готовий сервер авторизації з власною адмінкою та користувачами.
• Підтримує OpenID Connect, OAuth2, SAML
• Видає JWT, керує сесіями
• Має UI для користувачів і адміністраторів
• Підтримує MFA, LDAP, Google Login тощо
• Часто використовується як SSO і центральний сервіс авторизації

Використовується як:

• /auth сервіс
• Підключається до frontend і backend
• Перевіряє токени через middleware або API Gateway

Auth0 (хмарний, комерційний)

• Готове хмарне рішення для автентифікації та авторизації.
• Легка інтеграція через SDK
• Підтримує соц. логіни, MFA, RBAC
• Видає JWT-токени
• Підходить для SaaS, мобільних і SPA
• Плюси: швидко, UI готовий
• Мінуси: платно, залежить від інтернету

OPA (Open Policy Agent) + Keto

• Для авторизації за політикою (ABAC) — хто, до чого, за яких умов.
• OPA = рушій правил (мова Rego)
• Keto = open-source аналог Google Zanzibar (ACL-сховище)
• Дозволяє перевіряти: "Чи може користувач X робити Y з ресурсом Z?"
• Використовуються разом з іншими сервісами
• OPA — виносить бізнес-правила з коду

ORY Stack (Hydra, Kratos, Keto, Oathkeeper)

• Open-source платформа для авторизації
• Hydra — OAuth2 / OIDC сервер (лише протоколи)
• Kratos — керування користувачами (логін, реєстрація, email)
• Keto — зберігання політик (RBAC/ABAC)
• Oathkeeper — API Gateway з авторизацією
• Гнучко, потужно, але потребує налаштування
• Ідеально під мікросервісну архітектуру

Що таке API Gateway

API Gateway — це єдина точка входу до всіх мікросервісів.
Він приймає запити від клієнтів і:

• перенаправляє їх у потрібний мікросервіс (routing)
• перевіряє авторизацію (наприклад, JWT)
• робить rate-limiting, логування, CORS тощо
• Клієнт спілкується лише з Gateway
• Gateway приховує внутрішню структуру
• Він може додати, прибрати, перейменувати заголовки, перевірити токен тощо

[Клієнт] → [API Gateway] ─→ [Мікросервіс A]
                        └→ [Мікросервіс B]
                        └→ [Auth Service]

Популярні рішення

NGINX

• Працює як зворотний проксі
• Можна додати валідацію JWT (через Lua, njs, etc.)
• Дуже швидкий, простий у налаштуванні
• Добрий для low-level налаштування (прямо через конфіг)

Kong

• Побудований на базі NGINX
• Плагінна архітектура (авторизація, ліміти, логери)
• Має UI, REST API, CLI
• Підтримує JWT, OAuth2, rate-limit, CORS, OpenID, gRPC тощо

Traefik

Простий у використанні, особливо з Docker/Kubernetes
Автоматичне виявлення сервісів (K8s ingress, Docker labels)
Підтримує TLS, Let’s Encrypt, JWT, middlewares

Envoy

Потужний проксі від Lyft
Використовується в Istio, gRPC, AWS App Mesh
Підтримка сервісної сітки (service mesh)
Висока продуктивність і гнучкість

AWS API Gateway (хмарний)

Повністю керований сервіс від AWS
Інтеграція з Lambda, IAM, Cognito, CloudWatch
Підтримує REST, WebSocket, HTTP APIs

Як працюють сертифікати

Сертифікат — це посвідчення особи для комп'ютерів і серверів.
Він підтверджує, що сервер — той, за кого себе видає, і містить його відкритий ключ.

Сертифікат — це файл у форматі .crt, .pem, .cer, .der тощо. Він містить:

Під час відкриття сайту браузер:
Отримує сертифікат сервера
Перевіряє, чи підписаний він довіреним центром (CA)
— наприклад, Let's Encrypt, DigiCert, Sectigo та ін.
Використовує публічний ключ із сертифіката, щоб:
перевірити справжність сервера
створити секретний ключ, за допомогою якого буде зашифровано весь трафік
Подальший обмін даними йде захищеним каналом (TLS)

Де використовуються сертифікати

• HTTPS на сайтах
• gRPC між мікросервісами
• mTLS (взаємна авторизація клієнта і сервера)
• OAuth2 / OpenID (підпис токенів через RSA/ECDSA)
• Kubernetes (kube-apiserver, kubelet, etcd)
• VPN (WireGuard, OpenVPN)

Які бувають типи сертифікатів

За призначенням:

За структурою:

Як зберігати паролі користувачів

Чого не можна робити

• зберігати пароль у відкритому вигляді (plain text)
• шифрувати паролі «щоб можна було розшифрувати»
• використовувати швидкі хеші (MD5, SHA-1, чистий SHA-256)

Як потрібно зберігати паролі

1. Хешуємо паролі, а не шифруємо<!-- wp:list -->

• Беремо пароль і пропускаємо через спеціальну повільну функцію (KDF).
• Вона робить підбір пароля дуже дорогим.
• Усі перевірки робити в одному auth-сервісі, а не в кожному мікросервісі.
• Мікросервіси працюють лише з токенами, а не з паролями.

2. Використовуємо KDF (ключові функції для паролів)<!-- wp:list -->

• Argon2id (найкращий сучасний варіант, рекомендований OWASP).
• Якщо його немає — bcrypt або scrypt.
• PBKDF2 можна використовувати лише для сумісності/держ. стандартів.
• Для кожного пароля генерувати власну сіль.

3. Додаємо сіль (salt)<!-- wp:list -->

• Унікальний випадковий рядок для кожного користувача.
• Зберігається разом із хешем (це нормально).
• Робить так, що два однакові паролі в різних людей матимуть різні хеші.

4. Можна додати перець (pepper)<!-- wp:list -->

• Це спільний секрет.
• Він не зберігається в базі.
• Якщо база витекла, а перець ні — хеші марні.
• Перець зберігати окремо (наприклад, у KMS або Vault).

5. Зберігаємо результат у форматі з параметрами Наприклад, рядок для bcrypt:

$2a$12$C6UzMDM.H6dfI/f/IKcEe.7WxoQ5y0CEajliV0z3yFNBPJzXeS.CW

Вона містить:

• алгоритм (2a)
• складність (12)
• сіль
• сам хеш

Де зберігати паролі

• У централізованому сервісі авторизації (наприклад, Keycloak, AWS Secrets Manager, власний Auth-сервіс).
• Інші мікросервіси не знають паролів, вони перевіряють токени (JWT).
• Це знижує ризик витоку: лише один сервіс працює з паролями.

Алгоритм для автентифікації

1. Користувач надсилає логін + пароль у сервіс авторизації.
2. Сервіс:<!-- wp:list -->

• знаходить хеш і сіль у базі
• хешує надісланий пароль тим самим алгоритмом
• порівнює зі збереженим значенням (constant-time порівняння)

3. Якщо збіглося → видається JWT токен.
4. Інші мікросервіси перевіряють лише токен, а не паролі.

Що таке KMS (Key Management Service)

Сервіс, який керує ключами шифрування.
Його завдання: ключі не лежать у тебе в коді чи базі, а зберігаються в захищеному місці.
Ти не забираєш ключ, а просто кажеш KMS:

• «Зашифруй ось це»
• «Розшифруй ось це»
• «Підпиши ось це»

Ключ при цьому не залишає сховища.

Як це працює покроково

1. Створення майстер-ключа

• У KMS створюється головний ключ (Master Key).
• Це може бути симетричний (AES) або асиметричний (RSA/ECC).
• Цей ключ не можна завантажити, він завжди залишається всередині KMS.

2. Шифрування даних

• Ти не шифруєш самі великі файли в KMS (це дорого й повільно).
• Замість цього:<!-- wp:list {"ordered":true} -->
  1. KMS генерує data key (тимчасовий ключ для шифрування).
  2. Data key використовується у твоєму застосунку для шифрування даних (наприклад, AES-256).
  3. Сам data key зберігається в тебе в базі, але в зашифрованому вигляді (через майстер-ключ KMS).

3. Розшифрування даних

• Коли треба прочитати дані:<!-- wp:list {"ordered":true} -->
  1. Ти надсилаєш у KMS зашифрований data key.
  2. KMS його розшифровує та повертає розшифрований data key.
  3. Ти використовуєш цей data key, щоб розшифрувати дані в себе.

Таким чином, KMS ніколи не бачить твоїх даних — лише ключі.

Чому це безпечно

• Ключі лежать у захищеному сховищі (HSM — залізо для криптографії).
• Ти не керуєш ключами вручну, ними керує KMS.
• Усі дії (хто, коли шифрував/розшифровував) логуються.
• Можна налаштувати політику: «цей ключ може використовувати лише сервіс А».
• Можна робити ротацію ключів (нова версія кожні N днів).

Де це використовується

• AWS KMS (Amazon)
• Google Cloud KMS
• Azure Key Vault (KMS частина)
• HashiCorp Vault (self-hosted альтернатива)

Які є рішення для захисту від brute-force атак

Для захисту мікросервісів і API від brute-force атак (перебір паролів, токенів, логінів тощо) застосовуються стандартизовані рішення, як на рівні коду, так і на рівні інфраструктури (API Gateway, firewall, reverse proxy, etc). Нижче — систематизований огляд.

Що таке mTLS

mTLS = Mutual TLS, або «взаємний TLS».

Звичайний TLS (HTTPS) працює так:

• Клієнт (браузер, сервіс) перевіряє сертифікат сервера, щоб переконатися, що це саме той сайт/сервіс.
• Сервер не перевіряє клієнта, йому достатньо, що клієнт знає пароль/токен.

У mTLS перевірка двостороння:

• Сервер пред'являє свій сертифікат клієнту.
• Клієнт теж пред'являє свій сертифікат серверу.
• Обидва перевіряють один одного і переконуються, що спілкуються з довіреним співрозмовником.

Як це працює покроково

1. Клієнт підключається до сервера і починає TLS-рукостискання.
2. Сервер надсилає свій сертифікат → клієнт перевіряє його (підпис CA, строк дії, CN/SAN).
3. Сервер у відповідь просить у клієнта сертифікат.
4. Клієнт надсилає свій сертифікат → сервер перевіряє його за довіреним CA.
5. Якщо обидва сертифікати валідні → встановлюється захищене з'єднання.

Де використовується mTLS

• Між мікросервісами — щоб один сервіс точно знав, що до нього звертається саме довірений сервіс, а не зловмисник.
• В API для B2B — коли компанії обмінюються даними, і треба довіряти не лише паролю/токену, а й сертифікату пристрою/сервісу.
• В IoT — пристрої автентифікуються за сертифікатами.
• У банківських системах — обов'язкова вимога для захисту каналів.

Чим корисний mTLS

• Двостороння автентифікація (і сервер, і клієнт перевірені).
• Ключі ніколи не передаються, а лише підтверджуються сертифікатами.
• Зручно для «machine-to-machine» сценаріїв (мікросервіси, API, IoT).
• Можна замінити паролі/токени на сертифікати (або використовувати разом).

Які є популярні алгоритми шифрування та хешування

Алгоритми шифрування (encryption)

Симетричні (один ключ для шифрування і дешифрування)

• AES (Advanced Encryption Standard) — найпопулярніший, стандарт де-факто<!-- wp:list -->
  • Режими: AES-GCM (часто в TLS), AES-CBC, AES-CTR
  • Довжина ключа: 128 / 192 / 256 біт
• ChaCha20-Poly1305 — сучасний алгоритм, альтернатива AES<!-- wp:list -->
  • Швидший на мобільних і ARM
  • Використовується в TLS 1.3, WireGuard, сервісах Google

Асиметричні (різні ключі: публічний і приватний)

• RSA — класика, широко використовується для TLS, підписів, обміну ключами<!-- wp:list -->
  • Надійність залежить від довжини ключа (2048+ біт)
• Elliptic Curve Cryptography (ECC) — сучасніший і легший<!-- wp:list -->
  • ECDSA (цифровий підпис)
  • ECDH / ECDHE (обмін ключами, використовується в TLS 1.3)
  • Ed25519, Ed448 (підписи, швидкі та безпечні)

Алгоритми хешування (hashing)

Загальні (для даних)

• SHA-2 (SHA-256, SHA-512) — стандарт у більшості систем
• SHA-3 (Keccak) — новіший стандарт від NIST
• BLAKE2 / BLAKE3 — швидкі, сучасна альтернатива SHA

Для зберігання паролів (спеціальні KDF)

• Argon2id — сучасний переможець Password Hashing Competition, найкращий варіант зараз
• bcrypt — старий, але все ще широко використовується
• scrypt — кращий за bcrypt, але рідше використовується
• PBKDF2 — стандартний, але вважається застарілим (використовується для сумісності, FIPS)

Використання

• Для шифрування даних: AES-GCM або ChaCha20-Poly1305
• Для обміну ключами: ECDHE (в TLS 1.3)
• Для підписів: ECDSA або Ed25519
• Для хешування файлів: SHA-256 або BLAKE3
• Для паролів: Argon2id (найкращий вибір), або bcrypt/scrypt

Copyright: Roman Kryvolapov