Zero trust¶

Ne jamais faire confiance par défaut — même à l'intérieur du réseau.

Le modèle traditionnel et ses limites¶

Le modèle traditionnel de sécurité périmètre repose sur l'hypothèse qu'un réseau interne est sur. Un attaquant qui franchit le pare-feu externe trouve des services internes ouverts et communicants sans restriction. Cette hypothèse s'est révélée fausse dans la quasi-totalité des breaches modernes.

Les raisons de cet échec sont structurelles : le périmètre n'existe plus dans un monde de cloud hybride, de SaaS, de travail distant et de supply chain logicielle étendue. Les employes accedent aux ressources depuis des réseaux non maîtrises. Les services communiquent à travers des frontieres organisationnelles. Les attaquants qui penetrent le périmètre se deplacent lateralement sans résistance.

graph TD
    subgraph "Modele perimetrique"
        A[Client externe] --text--> FW[Pare-feu]
        FW --text--> B[Zone interne]
        B --> C[Service A]
        B --> D[Service B]
        C --text--> D
    end

    subgraph "Zero trust"
        E[Client externe] --text--> GW[Gateway]
        GW --text--> F[Service A]
        F --text--> G[Service B]
        G --text--> H[Base de donnees]
    end

Dans le modèle perimetrique, la confiance est implicite à l'intérieur. Dans le zero trust, chaque fleche représenté une vérification d'identité et d'autorisation — il n'y a pas de zone de confiance implicite.

Les 3 piliers¶

Vérifier l'identité¶

Chaque service et chaque utilisateur doit prouver son identité. En pratique : mTLS entre services, JWT valides pour les utilisateurs, identités de workload (SPIFFE/SPIRE).

L'identité n'est jamais déduite de la position réseau. Une requête venant du réseau interne n'est pas considérée comme de confiance. Un pod Kubernetes dans le même namespace n'est pas automatiquement autorise.

Vérifier l'autorisation¶

L'identité ne suffit pas. Chaque requête est autorisee en fonction du rôle (RBAC), des attributs (ABAC) ou de la politique courante.

Un service authentifie ne peut accéder qu'aux ressources dont il a explicitement besoin. L'autorisation est évaluée à chaque requête, pas seulement à la connexion initiale. Le contexte compte : qui demande, quoi, quand, depuis ou, avec quel device.

# Politique OPA/Rego simplifiee
allow {
    input.method == "GET"
    input.path == "/api/orders"
    input.user.role == "order-reader"
    input.user.mfa_verified == true
    time.now_ns() < input.user.token_expiry
}

Minimiser l'accès¶

Le principe du moindre privilege s'applique partout :

• Un service ne reçoit que les permissions nécessaires a sa fonction
• Les tokens ont une durée de vie courte (minutes, pas jours)
• Les accès sont revokes des qu'ils ne sont plus nécessaires
• Les accès élevés sont obtenus par elevation temporaire (just-in-time), pas maintenus en permanence
• Les blast radius sont limites : si un composant est compromis, l'impact est contenu

BeyondCorp — zero trust en pratique¶

BeyondCorp est le modèle zero trust mis en œuvre par Google à partir de 2011. C'est une implémentation concrète des principes zero trust à l'échelle d'une organisation mondiale, documentee dans plusieurs publications academiques.

Principes BeyondCorp¶

L'accès ne dépend pas du réseau — qu'un employe soit au bureau, à la maison ou dans un cafe, l'accès aux ressources passe par le même chemin. Le VPN est supprimé.

L'accès dépend de l'identité et du contexte — chaque requête est évaluée en fonction de l'identité de l'utilisateur, de la posture de sécurité du device, et du niveau de sensibilité de la ressource demandee.

Toutes les ressources sont accessibles via Internet — mais protegees par un proxy d'accès qui vérifié l'identité et le contexte à chaque requête.

graph LR
    USER[Utilisateur] --text--> AP[Access Proxy]
    AP --text--> IDP[Identity Provider]
    AP --text--> DT[Device Trust\nPosture check]
    AP --text--> POL[Policy Engine\nRegles d'acces]
    POL --text--> ALLOW["Autoriser / Refuser"]
    ALLOW --text--> APP[Application interne]

Composants clés¶

ZTNA — Zero Trust Network Access¶

Le ZTNA (Zero Trust Network Access) est l'application du zero trust à l'accès réseau. Il remplacé le VPN traditionnel par un accès applicatif granulaire.

VPN vs ZTNA¶

Architectures ZTNA¶

ZTNA agent-based — un agent sur le device de l'utilisateur etablit un tunnel chiffre vers un broker qui vérifié l'identité et le contexte avant de router vers l'application. Le device ne voit jamais le réseau interne.

ZTNA service-based — pas d'agent nécessaire. L'accès se fait via un proxy web (reverse proxy avec authentification). Adapté aux applications web, moins flexible pour les protocoles non-HTTP.

Mise en œuvre progressive¶

Le zero trust n'est pas un produit que l'on active — c'est une transformation architecturale. Une migration typique se fait par phases.

Phase 1 — Inventaire et visibilité¶

Cartographier tous les services, flux de données et niveaux de confiance actuels. Sans visibilité, on ne peut pas sécuriser.

• Lister tous les services et leurs dépendances
• Identifier les flux de données sensibles
• Documenter les mécanismes d'authentification existants (ou leur absence)
• Déployer du monitoring sur les communications inter-services

Phase 2 — Identités de workload¶

Déployer mTLS et des identités de workload pour tous les services critiques.

• Déployer une PKI interne (cert-manager, Vault PKI)
• Attribuer une identité SPIFFE à chaque service
• Activer mTLS en mode permissif (accepte les connexions non-mTLS pendant la migration)

Phase 3 — Micro-segmentation¶

Remplacer les règles réseau larges par des politiques fine-grained.

• Network Policies Kubernetes pour limiter les communications pod-to-pod
• Security groups par service (pas par sous-réseau)
• Default deny — tout est bloque sauf ce qui est explicitement autorise

Phase 4 — Autorisation contextuelle¶

Introduire des politiques d'autorisation qui prennent en compte le contexte.

• Déployer OPA ou Cedar comme policy engine
• Définir des politiques basées sur l'identité, le rôle, l'heure, la localisation
• Implémenter le just-in-time access pour les accès privilegies

Phase 5 — Monitoring continu¶

Logger et analyser tous les accès pour détecter les anomalies.

• Centraliser les logs d'accès dans un SIEM
• Configurer des alertes sur les patterns anormaux
• Implémenter l'UEBA (User and Entity Behavior Analytics)

Erreurs courantes¶

Zero trust et Kubernetes¶

Kubernetes est un environnement ou le zero trust prend tout son sens. Par défaut, un cluster Kubernetes est un réseau plat — tous les pods peuvent communiquer entre eux sans restriction. C'est un modèle de confiance implicite qui doit être corrige.

Network Policies¶

La première étape : déployer des Network Policies pour limiter les communications pod-to-pod. La politique par défaut doit être "deny all", avec des exceptions explicites pour chaque flux autorise.

# Default deny all ingress dans un namespace
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny-all
  namespace: production
spec:
  podSelector: {}
  policyTypes:
    - Ingress
    - Egress

Service mesh et zero trust¶

Le service mesh (Istio, Linkerd) est l'outil le plus complet pour implémenter le zero trust dans Kubernetes. Il fournit :

• mTLS automatique entre tous les services (sans modifier le code)
• Politiques d'autorisation au niveau L7 (qui peut appeler quel endpoint)
• Observabilité de tous les flux inter-services
• Rate limiting par service et par endpoint

Service accounts et RBAC¶

Chaque pod doit utiliser un service account dédié avec des permissions minimales. Le service account par défaut du namespace ne doit jamais être utilisé en production — il hérité souvent de permissions trop larges.

Mesurer la maturité zero trust¶

Le zero trust est une transformation continue. Un modèle de maturité aide à évaluer la progression et a prioriser les efforts.

La plupart des organisations démarrent au niveau 0 ou 1. L'objectif realiste pour un système en production est d'atteindre le niveau 3 en 6 a 12 mois, puis de progresser vers les niveaux 4 et 5 selon la criticite du système.

Chapitre suivant : Defense en profondeur — empiler les couches de protection pour qu'aucune défaillance unique ne compromette le système.