Безопасность микросервисов и веб приложений

Что такое микросервис авторизации

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

• проверяет кто ты (аутентификация)
• решает, что тебе можно делать (авторизация)
• выдает и проверяет токены доступа (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