Транспорт бэкенда
Безопасность транспорта: mTLS, OAuth, API Keys
Peloton 2021: публичный API без аутентификации позволял получить данные о любом пользователе зная их username. Имена, тренировки, вес, местоположение - всё публично. Фундаментальная ошибка: BOLA, объект (user profile) не проверял принадлежность текущему пользователю. Правильный транспортный дизайн делает такие ошибки структурно невозможными.
- **Stripe** хранит API ключи только как SHA-256 hash. Даже сотрудники Stripe не могут восстановить ключ - только создать новый. Каждый ключ имеет scope (read-only, webhooks, full-access).
- **Istio** в Google GKE автоматически настраивает mTLS STRICT mode для всех pod-to-pod коммуникаций. Service identity через SPIFFE: spiffe://cluster.local/ns/production/sa/payment-service.
- **GitHub** Advanced Security автоматически сканирует коммиты на API ключи (секреты). При обнаружении - немедленно инвалидирует ключ и уведомляет владельца.
TLS Termination
TLS termination - расшифровка TLS трафика на прокси или load balancer, далее трафик идёт в plaintext внутри кластера. Снижает нагрузку на backend серверы и централизует управление сертификатами. Риск: трафик внутри кластера не зашифрован.
Let's Encrypt + cert-manager (Kubernetes) автоматизируют выпуск и обновление TLS сертификатов. HSTS (HTTP Strict Transport Security) заставляет браузер всегда использовать HTTPS - предотвращает downgrade атаки.
TLS termination на load balancer - какой главный security риск?
Mutual TLS (mTLS)
Обычный TLS: клиент проверяет сертификат сервера. mTLS: оба проверяют сертификат друг друга. Это аутентификация на уровне транспорта - сервис не может подключиться без валидного клиентского сертификата. Используется для service-to-service auth в Istio.
SPIFFE (Secure Production Identity Framework For Everyone) - стандарт для service identity в cloud. SPIRE - его reference implementation. Istio автоматически выдаёт SPIFFE сертификаты каждому pod'у через Envoy sidecar.
Чем mTLS отличается от обычного TLS с JWT аутентификацией?
JWT Propagation в микросервисах
JWT (JSON Web Token) - self-contained токен с claims, подписанный приватным ключом. Микросервисы проверяют подпись локально через публичный ключ без запроса к auth сервису. Токен propagate через Authorization заголовок между сервисами.
JWT exp (expiration) должен быть коротким: 15 минут для access token. Refresh token (долгоживущий) используется для обновления. Никогда не хранить sensitive данные в JWT payload - он только base64 encoded, не зашифрован.
Почему downstream микросервис не должен перепроверять JWT подпись если API Gateway уже проверил?
API Key Management и Rotation
API Keys - долгоживущие токены для machine-to-machine аутентификации. Главная проблема: утечка ключа даёт постоянный доступ. Best practices: короткое TTL, rotation, scoped permissions, audit log каждого использования.
GitHub, Stripe, AWS: никогда не показывают ключ повторно после создания. Если потерян - создать новый, старый инвалидировать. Это заставляет пользователей хранить ключ безопасно.
Почему API ключ хранится в БД как hash, а не в открытом виде?
OWASP уязвимости транспортного уровня
OWASP API Security Top 10 включает несколько transport-уровневых уязвимостей: Broken Object Level Authorization (BOLA), Injection, Security Misconfiguration. Правильный транспортный дизайн предотвращает большинство из них.
BOLA (OWASP #1) - самая распространённая API уязвимость. Пример: Uber 2016 - через API можно было получить данные любого водителя зная его ID. Исправление: проверять принадлежность объекта текущему пользователю в каждом endpoint.
HTTPS достаточно для безопасности API
HTTPS обеспечивает шифрование и аутентификацию сервера. Но не защищает от BOLA, Injection, broken auth, CORS misconfiguration - это application-level уязвимости.
Security - это слои: HTTPS (transport), API Gateway (rate limiting, auth), Application (BOLA check, input validation), Database (parameterized queries). Нельзя полагаться только на один уровень.
CORS заголовок Access-Control-Allow-Origin: * на API с аутентификацией - какой риск?
Итоги
- **TLS Termination** на LB - стандарт для public API. mTLS для service-to-service (Istio автоматизирует). Edge termination + mTLS внутри - лучший баланс.
- **JWT**: короткий TTL (15 мин), RS256 подпись, Gateway centralize validation, downstream доверяют заголовкам Gateway.
- **API Keys**: хранить только SHA-256 hash, scope-limited, rotation policy, audit log. Показать raw key только при создании.
Связанные темы
Безопасность транспорта пересекается с API Gateway и debugging инструментами:
- API Gateway и Service Mesh — API Gateway централизует JWT validation и rate limiting; Istio реализует mTLS автоматически через service mesh
- Отладка транспорта — SSLKEYLOGFILE + Wireshark для дешифрации TLS в dev; curl -v для диагностики TLS certificate errors
Вопросы для размышления
- Как реализовать немедленную инвалидацию JWT токена при logout, если JWT stateless по дизайну?
- При каких условиях стоит использовать JWT с коротким TTL вместо opaque session tokens хранящихся в Redis?
- Как автоматически ротировать API ключи во всех downstream сервисах без downtime?