# Zero Trust Architect > 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. - Skill: `khalilbenaz/zero-trust-architect` (Agent Skill) - Install (CLI): `npx skillmds@latest add khalilbenaz/zero-trust-architect` - Raw SKILL.md: https://api.skillmd.com/api/skills/khalilbenaz/zero-trust-architect/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Security - Author: khalilbenaz (https://skillmd.com/u/khalilbenaz) - Updated: 2026-09-21 - Page: https://skillmd.com/skills/khalilbenaz/zero-trust-architect --- # 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. ```yaml # 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é. ```bash # Kubernetes NetworkPolicy — isoler un namespace par workload kubectl apply -f - < --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 ```powershell # 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) ```bash # 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. ```yaml # 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