---
title: "Безпека мікросервісів і вебзастосунків"
url: "https://romankryvolapov.com/uk/microservices-security/"
description: "Мікросервіс авторизації, API Gateway, mTLS і сертифікати: як безпечно зберігати паролі, захищатися від brute-force і які алгоритми шифрування обрати."
language: uk
updated: 2026-01-21
---
## Що таке мікросервіс авторизації

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

- перевіряє, хто ти (автентифікація)
- вирішує, що тобі можна робити (авторизація)
- видає та перевіряє токени доступу (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 з авторизацією
- Гнучко, потужно, але потребує налаштування
- Ідеально під мікросервісну архітектуру

| Назва | Валідація | Автентифікація | Політики (ABAC) | UI / Адмінка | Open-source |
| --- | --- | --- | --- | --- | --- |
| **Keycloak** | ✅ JWT | ✅ Так | ⚠️ Обмежено | ✅ Так | ✅ Так |
| **Auth0** | ✅ JWT | ✅ Так | ⚠️ Обмежено | ✅ Так | ❌ Ні |
| **OPA + Keto** | ⚠️ Через API | ❌ Ні | ✅ Дуже гнучко | ❌ Ні | ✅ Так |
| **ORY Stack** | ✅ Так | ✅ Так | ✅ Так | ✅ Так | ✅ Так |
| **Firebase** | ✅ Так | ✅ Так | ❌ Ні | ✅ Так | ❌ Ні |

## Що таке API Gateway

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

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

```text
[Клієнт] → [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 тощо. Він містить:

| Поле | Значення |
| --- | --- |
| Subject | Кому видано (домен, ім'я сервера тощо) |
| Issuer | Хто видав (CA — засвідчувальний центр) |
| Public Key | Відкритий ключ сервера |
| Valid From / To | Строк дії |
| Signature | Підпис засвідчувального центру |
| Serial Number | Унікальний ID сертифіката |

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

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

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

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

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

| Тип | Для чого використовується |
| --- | --- |
| **Сертифікат сервера (SSL/TLS)** | Для HTTPS, захищає сайти та API |
| **Сертифікат клієнта** | Для перевірки особи клієнта (наприклад, mTLS) |
| **Сертифікат підпису коду** | Для підпису програм (наприклад, .exe, .apk) |
| **Сертифікат email (S/MIME)** | Для підпису та шифрування email-повідомлень |
| **Сертифікат PKI в AD** | Для Windows/LDAP авторизації |

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

| Тип | Опис |
| --- | --- |
| **Root Certificate** | Кореневий, встановлюється в системі (Windows, браузер) |
| **Intermediate CA** | Проміжний, підписує користувацькі сертифікати |
| **Leaf / End-entity** | Сам сертифікат сайту/сервісу/користувача |

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

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

- зберігати пароль у відкритому вигляді (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:

```kotlin
$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). Нижче — систематизований огляд.

| Підхід | Рівень | Стисло |
| --- | --- | --- |
| **Rate limiting** | Gateway / Service | Обмеження кількості запитів за період часу |
| **CAPTCHA / Proof-of-work** | UI / Backend | Захист від ботів, збільшує вартість атаки |
| **Account lockout** | Backend / DB | Блокування після X невдалих спроб |
| **Exponential backoff** | Backend | Збільшення паузи між спробами |
| **IP blacklist / geo-fencing** | Gateway | Блокування підозрілих джерел |
| **Device fingerprinting** | Backend / Frontend | Контекстна оцінка (новий пристрій → challenge) |
| **Behavioral analysis** | Security service | Аналіз аномалій |
| **WAF (Web Application Firewall)** | Infra | Захист від автоматичних атак |

## Що таке 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](https://t.me/RomanKryvolapov)