Sécurité réseau

Sécurité des communications entre services : TLS, mTLS, service mesh, politiques réseau et segmentation dans les architectures distribuées.

Pourquoi le réseau est un vecteur d’attaque

Dans une architecture monolithique, la communication entre composants se fait au sein du même processus — il n’y a pas de réseau en jeu. Dans les microservices, chaque appel entre services transite par le réseau, ce qui introduit de nouveaux vecteurs d’attaque :

Interception : un attaquant peut capturer le trafic entre services
Usurpation : un service malveillant peut se faire passer pour un autre
Man-in-the-middle : un attaquant peut modifier les données en transit
Mouvement latéral : si un service est compromis, l’attaquant peut accéder aux autres services du même réseau

La sécurité réseau dans les microservices n’est pas optionnelle — elle est fondamentale.

TLS (Transport Layer Security)

TLS chiffre la communication entre deux points, garantissant confidentialité et intégrité.

Comment fonctionne TLS

sequenceDiagram
    participant C as Cliente
    participant S as Servidor

    C->>S: ClientHello (versiones TLS, cipher suites)
    S->>C: ServerHello (versión elegida, cipher suite)
    S->>C: Certificado del servidor
    C->>C: Verificar certificado contra CA
    C->>S: Clave pre-master cifrada con clave pública del servidor
    Note over C,S: Ambos derivan la clave de sesión
    C->>S: Datos cifrados con clave de sesión
    S->>C: Datos cifrados con clave de sesión

Configuration recommandée

# Configuración TLS moderna
tls:
  min_version: TLSv1.2    # Mínimo TLS 1.2, preferir 1.3
  cipher_suites:
    - TLS_AES_256_GCM_SHA384
    - TLS_CHACHA20_POLY1305_SHA256
    - TLS_AES_128_GCM_SHA256
  certificate: /etc/certs/server.crt
  private_key: /etc/certs/server.key
  ca_certificate: /etc/certs/ca.crt

TLS en pratique

Terminaison TLS au niveau du Gateway : le trafic externe arrive chiffré à l’API Gateway, qui termine TLS et route en interne
TLS de bout en bout : le trafic reste chiffré depuis le client jusqu’au service final
Rechiffrement : le Gateway termine le TLS externe et établit une nouvelle connexion TLS interne

mTLS (Mutual TLS)

En TLS standard, seul le serveur présente un certificat. En mTLS, les deux parties s’authentifient mutuellement.

Pourquoi mTLS dans les microservices

Dans un réseau interne comptant des dizaines de services, vous devez garantir que :

Le service appelant est bien celui qu’il prétend être
Le service qui répond est bien celui qu’il prétend être
Personne ne peut intercepter ni modifier la communication

sequenceDiagram
    participant A as Servicio A
    participant B as Servicio B

    A->>B: ClientHello
    B->>A: ServerHello + Certificado de B
    A->>A: Verificar certificado de B
    B->>A: Solicitar certificado de A
    A->>B: Certificado de A
    B->>B: Verificar certificado de A
    Note over A,B: Ambos verificados, comunicación cifrada
    A->>B: Request cifrado
    B->>A: Response cifrado

Gestion des certificats

Le plus grand défi de mTLS est la gestion des certificats à grande échelle :

Chaque service a besoin de son propre certificat
Les certificats doivent être renouvelés avant leur expiration
Une Certificate Authority (CA) interne est nécessaire
La révocation des certificats doit être rapide

# Ejemplo: certificado por servicio
service: orders-service
certificate:
  common_name: orders-service.internal
  san:
    - orders-service.default.svc.cluster.local
    - orders-service.production.svc.cluster.local
  validity: 24h          # Certificados de corta duración
  auto_renewal: true      # Renovación automática
  issuer: internal-ca

Outils pour mTLS

cert-manager (Kubernetes) : automatise l’émission et le renouvellement des certificats
Vault (HashiCorp) : PKI en tant que service, génère des certificats à la demande
SPIFFE/SPIRE : framework d’identité pour les workloads, génère des SVID (identités vérifiables)

Service Mesh

Un service mesh est une couche d’infrastructure dédiée à la gestion de la communication entre services. Il implémente mTLS, l’observabilité et les politiques de trafic de manière transparente.

Comment ça fonctionne

Chaque service dispose d’un sidecar proxy qui intercepte tout le trafic réseau :

[Servicio A] ←→ [Proxy A] ←→ [Red] ←→ [Proxy B] ←→ [Servicio B]
                  (Envoy)                  (Envoy)

Le service n’a pas besoin d’implémenter TLS, les retries, le circuit breaking ni les métriques — le proxy s’en charge à sa place.

Bénéfices en matière de sécurité

mTLS automatique : le mesh gère les certificats et chiffre tout le trafic entre services
Politiques d’accès : définissent quels services peuvent communiquer entre eux
Observabilité : visibilité complète du trafic entre services
Chiffrement transparent : les services n’ont pas besoin de code de sécurité additionnel

Exemple : politique d’accès dans Istio

# Solo el BFF puede llamar al servicio de órdenes
apiVersion: security.istio.io/v1
kind: AuthorizationPolicy
metadata:
  name: orders-service-policy
  namespace: production
spec:
  selector:
    matchLabels:
      app: orders-service
  rules:
    - from:
        - source:
            principals: ["cluster.local/ns/production/sa/bff-service"]
      to:
        - operation:
            methods: ["GET", "POST"]
            paths: ["/api/orders/*"]

Service meshes populaires

Mesh	Caractéristiques
Istio	Le plus complet, basé sur Envoy, large communauté
Linkerd	Plus léger, axé sur la simplicité et la performance
Consul Connect	Intégré à HashiCorp Consul, adapté aux environnements hybrides

Politiques réseau (Network Policies)

Dans Kubernetes, les Network Policies contrôlent quels pods peuvent communiquer entre eux au niveau réseau.

Par défaut : tout est ouvert

Sans Network Policies, n’importe quel pod peut communiquer avec n’importe quel autre pod du cluster. C’est dangereux : si un pod est compromis, l’attaquant a accès à tout le réseau interne.

Exemple : restreindre l’accès au service de base de données

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: db-access-policy
  namespace: production
spec:
  podSelector:
    matchLabels:
      app: postgres
  policyTypes:
    - Ingress
  ingress:
    - from:
        - podSelector:
            matchLabels:
              app: orders-service
        - podSelector:
            matchLabels:
              app: users-service
      ports:
        - protocol: TCP
          port: 5432

Cette politique signifie : seuls les pods orders-service et users-service peuvent se connecter au pod postgres sur le port 5432. Tout le reste est bloqué.

Stratégie de segmentation

Zona pública:     [API Gateway]
                       ↓
Zona de aplicación: [BFF] [Auth Service]
                       ↓
Zona de servicios:  [Orders] [Users] [Payments]
                       ↓
Zona de datos:      [PostgreSQL] [Redis] [Kafka]

Chaque zone dispose de politiques qui restreignent l’accès :

La zone publique ne peut communiquer qu’avec la zone d’application
La zone d’application peut communiquer avec la zone de services
Seule la zone de services peut communiquer avec la zone de données
La zone de données n’initie aucune connexion vers l’extérieur

DNS et découverte sécurisée des services

Dans les microservices, les services sont découverts dynamiquement. Ce mécanisme doit lui aussi être sécurisé :

DNS interne : utiliser un DNS privé au sein du cluster, sans exposer les noms des services internes
Découverte de services chiffrée : les requêtes de découverte doivent être authentifiées
Validation des endpoints : vérifier que le service découvert est légitime avant d’envoyer des données

# Kubernetes: los servicios se resuelven por DNS interno
# orders-service.production.svc.cluster.local
# Este DNS no es accesible desde fuera del cluster

Bonnes pratiques de sécurité réseau

Chiffrez tout le trafic : utilisez TLS ou mTLS pour toute communication, même interne
Appliquez le principe du moindre accès : chaque service ne doit communiquer qu’avec les services dont il a besoin
Segmentez le réseau : séparez les services en zones avec différents niveaux de confiance
Surveillez le trafic : détectez les schémas anormaux pouvant indiquer une attaque
Faites tourner les certificats fréquemment : privilégiez des certificats de courte durée (heures, pas années)
Utilisez un service mesh : simplifie l’implémentation de la sécurité réseau à grande échelle
Bloquez par défaut : les Network Policies doivent tout refuser et n’autoriser qu’explicitement

Résumé

La sécurité réseau dans les architectures distribuées nécessite de chiffrer toute la communication (TLS/mTLS), d’authentifier chaque service, de segmenter le réseau en zones de confiance et de surveiller le trafic. Un service mesh simplifie considérablement cette tâche en gérant mTLS, les politiques d’accès et l’observabilité de manière transparente. Les Network Policies de Kubernetes complètent le mesh en contrôlant l’accès au niveau réseau. La règle fondamentale est : ne faites jamais confiance au réseau, même s’il est « interne ».