Как вы защищаете обмен данными между сервисами (mTLS, zero-trust)?

Question

Accepted Answer

В сети микросервисов вы не можете полагаться на сеть просто потому, что она "внутренняя". **Zero-trust** предполагает, что сеть враждебна, поэтому каждый вызов аутентифицируется и авторизируется, а трафик шифруется с помощью **mTLS**.

## Взаимный TLS (mTLS)

В отличие от обычного TLS, **обе** стороны представляют сертификаты. Каждый сервис доказывает свою личность, а трафик зашифрован при передаче.

```text
Service A ──cert──▶ Service B
Service A ◀─cert── Service B   (both verify each other's identity)
→ caller is authenticated AND data is encrypted
```

Сетка сервисов может автоматически обеспечивать mTLS без каких-либо изменений кода приложения.

## Авторизация между сервисами

Идентичность (кто звонит) плюс политика (что они могут делать). Токены (JWT) или идентификаторы SPIFFE несут идентификацию вызывающего абонента.

```yaml
# allow only the orders service to call payments
policy:
  from: { service: orders }
  to:   { service: payments, path: /charge }
  action: ALLOW            # everything else denied by default
```

## Защита в глубину

```text
✓ Authenticate every request (no implicit network trust)
✓ Least privilege — a service can call only what it needs
✓ Short-lived, rotated credentials/certs
✓ Validate tokens at the edge AND between services
✓ Encrypt in transit (mTLS) and at rest
```

## Подводный камень

Доверие внутренней сети ("это за брандмауэром") - это то, как один скомпрометированный сервис становится полным компромиссом.

## Почему это важно

В плоской внутренней сети один скомпрометированный сервис может в противном случае получить доступ ко всему; zero-trust содержит этот радиус взрыва.

mTLS плюс авторизация для каждого вызова означает, что злоумышленник, который попадает внутрь, все еще не может выдавать себя за сервисы или перемещаться боком, что является основным обещанием безопасности современной платформы микросервисов.