zero-trust-architect

name

zero-trust-architect

description

Architecture Zero Trust — never trust always verify, micro-segmentation réseau, approche identity-centric et accès conditionnel. Se déclenche avec "Zero Trust", "zero trust architecture", "never trust", "micro-segmentation", "BeyondCorp". Couvre l'évaluation de maturité, le design ZTNA, la micro-segmentation, l'accès conditionnel, le device trust, et la feuille de route d'implémentation progressive.

Zero Trust Architect

Workflow

1. Évaluer la maturité actuelle

Avant tout design, auditer l'existant sur 5 axes :

Axe	Signe de confiance implicite (à corriger)
Réseau	VPN = accès total, réseau plat, pas de segmentation est-ouest
Identité	Pas de MFA, sessions longues, comptes de service partagés
Devices	Pas de vérification de conformité à la connexion
Données	Chiffrement absent ou partiel, accès en masse non audités
Visibilité	Logs insuffisants, pas de détection comportementale

Outil de référence : CISA Zero Trust Maturity Model v2 (5 piliers, 4 niveaux : Traditional → Initial → Advanced → Optimal).

---

2. Poser les fondations Identity-Centric

Objectif : L'identité remplace le réseau comme périmètre de confiance.

# Politique d'accès conditionnel — exemple Azure AD / Entra ID
conditions:
  users: [all]
  cloud_apps: [all]
  device_platforms: [all]
grant_controls:
  operator: AND
  built_in_controls:
    - mfa
    - compliant_device       # Intune enrollment + patch level
    - approved_client_app
session_controls:
  sign_in_frequency: 4h      # pas de session éternelle
  persistent_browser: never

Actions concrètes :

• Activer MFA sur tous les comptes (commencer par admins, 100% coverage obligatoire)
• Centraliser l'IdP (Azure AD Entra ID, Okta, PingFederate) — fédérer les apps legacy via SAML/OIDC
• Définir des groupes d'accès par rôle métier, pas par département réseau
• Implémenter RBAC + ABAC (attribute-based) pour les données sensibles

---

3. Micro-segmentation réseau

Règle : zéro communication implicite est-ouest ; chaque flux doit être déclaré.

# Kubernetes NetworkPolicy — isoler un namespace par workload
kubectl apply -f - <<EOF
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: deny-all-ingress
  namespace: payments
spec:
  podSelector: {}
  policyTypes: [Ingress, Egress]
---
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-api-to-db
  namespace: payments
spec:
  podSelector:
    matchLabels:
      app: postgres
  ingress:
  - from:
    - podSelector:
        matchLabels:
          app: payment-api
    ports:
    - port: 5432
EOF

Pour les environnements non-Kubernetes (VMs, bare metal) :

• Illumio / Guardicore / Akamai Guardicore : micro-segmentation agentless ou agent-based
• AWS : Security Groups + VPC endpoints + PrivateLink (pas de trafic public entre services internes)
• Azure : NSG + Azure Firewall Premium + Private Endpoints

Critère de décision segmentation :

• Workloads critiques (PCI-DSS, données santé) → segment dédié dès J1
• Workloads internes standard → macro-segmentation par BU puis affiner
• Legacy non-patchable → quarantaine réseau + accès par bastion uniquement

---

4. ZTNA — Remplacer le VPN

Zero Trust Network Access : accès granulaire par application, pas par réseau.

Comparatif rapide :

Solution	Usage typique	Notes
Cloudflare Access	SaaS/web apps, équipes distribuées	Simple, rapide à déployer
Zscaler ZPA	Enterprise, apps internes	Tunnel chiffré sans exposition IP
Tailscale	Infra devops, équipes techniques	WireGuard overlay, PKI automatique
Azure AD App Proxy	Apps on-prem exposées via Entra	Sans VPN, MFA intégré

# Tailscale — accès ZTNA en 3 commandes
curl -fsSL https://tailscale.com/install.sh | sh
tailscale up --auth-key=<tskey-auth-xxx> --advertise-tags=tag:prod-server
# Côté client : tailscale up → accès SSH direct sans VPN, avec MFA Tailscale

---

5. Device Trust & Endpoint Compliance

La décision d'accès doit inclure la santé du device, pas seulement l'identité.

Signaux à évaluer (en temps réel) :

• OS version + patch level (ex : Windows < 22H2 → blocage ou session restreinte)
• MDM enrollment (Intune, Jamf)
• Disk encryption actif (BitLocker, FileVault)
• EDR présent et actif (CrowdStrike, Defender for Endpoint)
• Certificat machine émis par la PKI interne

# Vérifier la conformité Intune via Graph API
$headers = @{ Authorization = "Bearer $token" }
Invoke-RestMethod `
  -Uri "https://graph.microsoft.com/v1.0/deviceManagement/managedDevices?`$filter=complianceState eq 'noncompliant'" `
  -Headers $headers | Select-Object -ExpandProperty value | Format-Table deviceName, userPrincipalName, lastSyncDateTime

---

6. Protéger les données (Data-Centric ZT)

# Exemple : chiffrement S3 + policy de refus sans clé KMS
aws s3api put-bucket-policy --bucket mon-bucket-sensible --policy '{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Deny",
    "Principal": "*",
    "Action": "s3:PutObject",
    "Resource": "arn:aws:s3:::mon-bucket-sensible/*",
    "Condition": {
      "StringNotEquals": { "s3:x-amz-server-side-encryption": "aws:kms" }
    }
  }]
}'

Actions :

• Classifier les données (Public / Internal / Confidential / Restricted) — outil : Microsoft Purview, Varonis
• DLP : bloquer exfiltration via email, upload cloud non autorisé
• Chiffrement au repos obligatoire pour Confidential+
• Audit log de chaque accès aux données Restricted (SIEM integration)

---

7. Monitoring Continu & Réponse

Assume breach : détecter vite, répondre automatiquement.

# Règle SIEM — détection accès anormal (pseudo-Sigma)
title: ZT - Accès depuis pays non autorisé
status: production
detection:
  selection:
    EventID: 4624          # Logon success
    LogonType: 3
  filter_allowed_countries:
    country|contains:
      - FR
      - TN
      - MA
  condition: selection and not filter_allowed_countries
action:
  - block_session
  - revoke_refresh_tokens  # via Graph API / Okta API
  - alert_soc

Intégrations clés :

• SIEM : Microsoft Sentinel, Splunk, Elastic SIEM
• SOAR : playbook automatique révocation token sur anomalie comportementale (UEBA)
• Threat Intel : enrichir les décisions d'accès avec les IOC connus

---

8. Feuille de route (Quick Wins → Transformation)

Phase	Délai	Actions prioritaires
P0 — Quick Wins	0–4 sem	MFA 100% comptes privilégiés, inventaire des accès, désactivation comptes dormants
P1 — Fondations	1–3 mois	IdP centralisé, accès conditionnel, segmentation DMZ / prod / dev
P2 — ZTNA	3–6 mois	Remplacement VPN, device compliance, RBAC granulaire
P3 — Maturité	6–12 mois	Micro-segmentation complète, DLP, UEBA, automatisation réponse
P4 — Optimal	12 mois+	Continuous verification, AI-driven access decisions, least-privilege automatisé

---

Anti-patterns & Pièges

• ZT = projet réseau uniquement — Erreur : ZT est d'abord un projet identité. Sans IdP solide, la micro-segmentation ne suffit pas.
• MFA par SMS — MITM/SIM-swap possible. Préférer TOTP (Authenticator) ou passkeys/FIDO2.
• Segmentation sans inventaire complet — Segmenter sans connaître tous les flux crée des coupures en production. Toujours commencer par un mode observe-only (audit mode).
• Politique trop restrictive dès le départ — Génère du shadow IT et du contournement. Déployer en mode report-only, analyser, puis enforcer.
• Confiance au device seul — Un device conforme avec un credential volé reste dangereux. Croiser device + identité + contexte (heure, géoloc, comportement).
• Sessions infinies — Token refresh sans réévaluation de la posture. Configurer sign-in frequency + re-authentication sur actions sensibles.
• PKI interne négligée — Certificats machine auto-signés ou expirés invalident la chaîne de confiance device. Automatiser avec ACME/Vault.

Bonnes Pratiques 2026

• Passkeys / FIDO2 : standard de facto — éliminer les mots de passe là où c'est possible (support natif Windows Hello, iOS, Android)
• Continuous Access Evaluation (CAE) : révocation de token quasi-temps-réel sur événement (changement de localisation, révocation admin) — activer dans Entra ID et Okta
• Service Mesh mTLS : tout trafic service-à-service chiffré + authentifié via certificat (Istio / Linkerd / Consul Connect)
• SPIFFE/SPIRE : identité cryptographique des workloads (remplace les comptes de service et les clés API statiques entre microservices)
• AI-assisted policy : Entra ID Identity Protection + Defender XDR pour décisions d'accès adaptatives basées sur le risque calculé en temps réel