Comment sécuriser la communication entre services (mTLS, zero-trust) ?

Question

Accepted Answer

Au sein d'un réseau de microservices, vous ne pouvez pas faire confiance au réseau simplement parce qu'il est « interne ». **Zero-trust** suppose que le réseau est hostile, donc chaque appel est authentifié et autorisé, et le trafic est chiffré avec **mTLS**.

## Mutual TLS (mTLS)

Contrairement à TLS normal, **les deux** côtés présentent des certificats. Chaque service prouve son identité, et le trafic est chiffré en transit.

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

Une service mesh peut fournir mTLS automatiquement sans modifications du code applicatif.

## Autorisation entre services

Identité (qui appelle) plus politique (ce qu'ils peuvent faire). Les jetons (JWT) ou les identités SPIFFE véhiculent l'identité de l'appelant.

```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
```

## Défense en profondeur

```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
```

## Piège

Faire confiance au réseau interne (« c'est derrière le pare-feu ») est la façon dont un seul service compromis devient une compromission complète.

## Pourquoi c'est important

Dans un réseau interne plat, un service compromis pourrait sinon atteindre tout ; zero-trust contient ce rayon de souffle.

mTLS plus autorisation par appel signifie qu'un attaquant qui s'y introduit ne peut toujours pas usurper l'identité des services ou se déplacer latéralement, ce qui est la promesse de sécurité centrale d'une plateforme moderne de microservices.