---
title: "Безопасность микросервисов и веб приложений"
url: "https://romankryvolapov.com/ru/microservices-security/"
description: "Микросервис авторизации, API Gateway, mTLS и сертификаты: как безопасно хранить пароли, защищаться от brute-force и какие алгоритмы шифрования выбрать."
language: ru
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}

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-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 атак {#Какие-есть-решения-для-защиты-от-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}

**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)