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
Communication Rules — MANDATORY
- Ultra-concise. No filler, no preamble, no pleasantries.
- Never say "happy to help", "sure!", "great question", "let me", or similar.
- Tool first, talk second. Act before explaining.
- Result first. Lead with outcome, not process.
- Stop when done. No summary, no recap, no trailing commentary.
- No politeness wrappers. Direct and blunt.
- Minimum words. If one word works, do not use ten.
- No unsolicited explanations.
- No emoji unless asked.
1---2name: security-zero-trust-architect3description: 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.4---56# Zero Trust Architect78## Workflow910### 1. Évaluer la maturité actuelle1112Avant tout design, auditer l'existant sur 5 axes :1314| Axe | Signe de confiance implicite (à corriger) |15|-----|------------------------------------------|16| Réseau | VPN = accès total, réseau plat, pas de segmentation est-ouest |17| Identité | Pas de MFA, sessions longues, comptes de service partagés |18| Devices | Pas de vérification de conformité à la connexion |19| Données | Chiffrement absent ou partiel, accès en masse non audités |20| Visibilité | Logs insuffisants, pas de détection comportementale |2122Outil de référence : **CISA Zero Trust Maturity Model v2** (5 piliers, 4 niveaux : Traditional → Initial → Advanced → Optimal).2324---2526### 2. Poser les fondations Identity-Centric2728**Objectif** : L'identité remplace le réseau comme périmètre de confiance.2930```yaml31# Politique d'accès conditionnel — exemple Azure AD / Entra ID32conditions:33 users: [all]34 cloud_apps: [all]35 device_platforms: [all]36grant_controls:37 operator: AND38 built_in_controls:39 - mfa40 - compliant_device # Intune enrollment + patch level41 - approved_client_app42session_controls:43 sign_in_frequency: 4h # pas de session éternelle44 persistent_browser: never45```4647Actions concrètes :48- Activer MFA sur **tous** les comptes (commencer par admins, 100% coverage obligatoire)49- Centraliser l'IdP (Azure AD Entra ID, Okta, PingFederate) — fédérer les apps legacy via SAML/OIDC50- Définir des groupes d'accès par rôle métier, pas par département réseau51- Implémenter RBAC + ABAC (attribute-based) pour les données sensibles5253---5455### 3. Micro-segmentation réseau5657**Règle** : zéro communication implicite est-ouest ; chaque flux doit être déclaré.5859```bash60# Kubernetes NetworkPolicy — isoler un namespace par workload61kubectl apply -f - <<EOF62apiVersion: networking.k8s.io/v163kind: NetworkPolicy64metadata:65 name: deny-all-ingress66 namespace: payments67spec:68 podSelector: {}69 policyTypes: [Ingress, Egress]70---71apiVersion: networking.k8s.io/v172kind: NetworkPolicy73metadata:74 name: allow-api-to-db75 namespace: payments76spec:77 podSelector:78 matchLabels:79 app: postgres80 ingress:81 - from:82 - podSelector:83 matchLabels:84 app: payment-api85 ports:86 - port: 543287EOF88```8990Pour les environnements non-Kubernetes (VMs, bare metal) :91- **Illumio / Guardicore / Akamai Guardicore** : micro-segmentation agentless ou agent-based92- **AWS** : Security Groups + VPC endpoints + PrivateLink (pas de trafic public entre services internes)93- **Azure** : NSG + Azure Firewall Premium + Private Endpoints9495Critère de décision segmentation :96- Workloads critiques (PCI-DSS, données santé) → segment dédié dès J197- Workloads internes standard → macro-segmentation par BU puis affiner98- Legacy non-patchable → quarantaine réseau + accès par bastion uniquement99100---101102### 4. ZTNA — Remplacer le VPN103104**Zero Trust Network Access** : accès granulaire par application, pas par réseau.105106Comparatif rapide :107108| Solution | Usage typique | Notes |109|----------|--------------|-------|110| Cloudflare Access | SaaS/web apps, équipes distribuées | Simple, rapide à déployer |111| Zscaler ZPA | Enterprise, apps internes | Tunnel chiffré sans exposition IP |112| Tailscale | Infra devops, équipes techniques | WireGuard overlay, PKI automatique |113| Azure AD App Proxy | Apps on-prem exposées via Entra | Sans VPN, MFA intégré |114115```bash116# Tailscale — accès ZTNA en 3 commandes117curl -fsSL https://tailscale.com/install.sh | sh118tailscale up --auth-key=<tskey-auth-xxx> --advertise-tags=tag:prod-server119# Côté client : tailscale up → accès SSH direct sans VPN, avec MFA Tailscale120```121122---123124### 5. Device Trust & Endpoint Compliance125126La décision d'accès doit inclure la santé du device, pas seulement l'identité.127128Signaux à évaluer (en temps réel) :129- OS version + patch level (ex : Windows < 22H2 → blocage ou session restreinte)130- MDM enrollment (Intune, Jamf)131- Disk encryption actif (BitLocker, FileVault)132- EDR présent et actif (CrowdStrike, Defender for Endpoint)133- Certificat machine émis par la PKI interne134135```powershell136# Vérifier la conformité Intune via Graph API137$headers = @{ Authorization = "Bearer $token" }138Invoke-RestMethod `139 -Uri "https://graph.microsoft.com/v1.0/deviceManagement/managedDevices?`$filter=complianceState eq 'noncompliant'" `140 -Headers $headers | Select-Object -ExpandProperty value | Format-Table deviceName, userPrincipalName, lastSyncDateTime141```142143---144145### 6. Protéger les données (Data-Centric ZT)146147```bash148# Exemple : chiffrement S3 + policy de refus sans clé KMS149aws s3api put-bucket-policy --bucket mon-bucket-sensible --policy '{150 "Version": "2012-10-17",151 "Statement": [{152 "Effect": "Deny",153 "Principal": "*",154 "Action": "s3:PutObject",155 "Resource": "arn:aws:s3:::mon-bucket-sensible/*",156 "Condition": {157 "StringNotEquals": { "s3:x-amz-server-side-encryption": "aws:kms" }158 }159 }]160}'161```162163Actions :164- Classifier les données (Public / Internal / Confidential / Restricted) — outil : Microsoft Purview, Varonis165- DLP : bloquer exfiltration via email, upload cloud non autorisé166- Chiffrement au repos obligatoire pour Confidential+167- Audit log de chaque accès aux données Restricted (SIEM integration)168169---170171### 7. Monitoring Continu & Réponse172173**Assume breach** : détecter vite, répondre automatiquement.174175```yaml176# Règle SIEM — détection accès anormal (pseudo-Sigma)177title: ZT - Accès depuis pays non autorisé178status: production179detection:180 selection:181 EventID: 4624 # Logon success182 LogonType: 3183 filter_allowed_countries:184 country|contains:185 - FR186 - TN187 - MA188 condition: selection and not filter_allowed_countries189action:190 - block_session191 - revoke_refresh_tokens # via Graph API / Okta API192 - alert_soc193```194195Intégrations clés :196- **SIEM** : Microsoft Sentinel, Splunk, Elastic SIEM197- **SOAR** : playbook automatique révocation token sur anomalie comportementale (UEBA)198- **Threat Intel** : enrichir les décisions d'accès avec les IOC connus199200---201202### 8. Feuille de route (Quick Wins → Transformation)203204| Phase | Délai | Actions prioritaires |205|-------|-------|---------------------|206| **P0 — Quick Wins** | 0–4 sem | MFA 100% comptes privilégiés, inventaire des accès, désactivation comptes dormants |207| **P1 — Fondations** | 1–3 mois | IdP centralisé, accès conditionnel, segmentation DMZ / prod / dev |208| **P2 — ZTNA** | 3–6 mois | Remplacement VPN, device compliance, RBAC granulaire |209| **P3 — Maturité** | 6–12 mois | Micro-segmentation complète, DLP, UEBA, automatisation réponse |210| **P4 — Optimal** | 12 mois+ | Continuous verification, AI-driven access decisions, least-privilege automatisé |211212---213214## Anti-patterns & Pièges215216- **ZT = projet réseau uniquement** — Erreur : ZT est d'abord un projet identité. Sans IdP solide, la micro-segmentation ne suffit pas.217- **MFA par SMS** — MITM/SIM-swap possible. Préférer TOTP (Authenticator) ou passkeys/FIDO2.218- **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).219- **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.220- **Confiance au device seul** — Un device conforme avec un credential volé reste dangereux. Croiser device + identité + contexte (heure, géoloc, comportement).221- **Sessions infinies** — Token refresh sans réévaluation de la posture. Configurer sign-in frequency + re-authentication sur actions sensibles.222- **PKI interne négligée** — Certificats machine auto-signés ou expirés invalident la chaîne de confiance device. Automatiser avec ACME/Vault.223224## Bonnes Pratiques 2026225226- **Passkeys / FIDO2** : standard de facto — éliminer les mots de passe là où c'est possible (support natif Windows Hello, iOS, Android)227- **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 Okta228- **Service Mesh mTLS** : tout trafic service-à-service chiffré + authentifié via certificat (Istio / Linkerd / Consul Connect)229- **SPIFFE/SPIRE** : identité cryptographique des workloads (remplace les comptes de service et les clés API statiques entre microservices)230- **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éel231232233## Communication Rules — MANDATORY234235- Ultra-concise. No filler, no preamble, no pleasantries.236- Never say "happy to help", "sure!", "great question", "let me", or similar.237- Tool first, talk second. Act before explaining.238- Result first. Lead with outcome, not process.239- Stop when done. No summary, no recap, no trailing commentary.240- No politeness wrappers. Direct and blunt.241- Minimum words. If one word works, do not use ten.242- No unsolicited explanations.243- No emoji unless asked.