Architecture
Diagramme d'architecture de sécurité zero trust avec vérifications de posture des appareils, vérification d'identité MFA, décisions de politique basées sur le risque, jetons JWT à courte durée de vie, micro-segmentation, chiffrement mTLS, application du moindre privilège et surveillance continue. Ce modèle représente le paradigme de sécurité « ne jamais faire confiance, toujours vérifier » où chaque requête est authentifiée et autorisée indépendamment de l'emplacement réseau. Essentiel pour les architectes sécurité implémentant des frameworks zero-trust modernes dans des environnements cloud-native.
Code FlowZap complet
User { # User / Device
n1: circle label:"Access Request"
n2: rectangle label:"Device Posture Check"
n3: rectangle label:"Identity Verification (MFA)"
n4: rectangle label:"Receive Access Decision"
n5: circle label:"Access Granted or Denied"
n1.handle(right) -> n2.handle(left)
n2.handle(right) -> n3.handle(left) [label="Device Compliant"]
n3.handle(bottom) -> PolicyEngine.n6.handle(top) [label="Authenticate"]
n4.handle(right) -> n5.handle(left)
}
PolicyEngine { # Policy Decision Point
n6: rectangle label:"Evaluate Identity Context"
n7: rectangle label:"Check Risk Score"
n8: diamond label:"Trust Level Sufficient?"
n9: rectangle label:"Issue Short-Lived Token"
n10: rectangle label:"Deny and Log"
n11: rectangle label:"Step-Up Authentication"
n6.handle(right) -> n7.handle(left) [label="Context"]
n7.handle(right) -> n8.handle(left)
n8.handle(right) -> n9.handle(left) [label="Trusted"]
n8.handle(bottom) -> n10.handle(top) [label="Denied"]
n8.handle(left) -> n11.handle(right) [label="Elevated"]
n9.handle(bottom) -> Enforcement.n12.handle(top) [label="JWT (5 min TTL)"]
n10.handle(top) -> User.n4.handle(bottom) [label="403"]
n11.handle(top) -> User.n3.handle(bottom) [label="Re-Verify"]
}
Enforcement { # Policy Enforcement Points
n12: rectangle label:"Micro-Segmentation Gateway"
n13: rectangle label:"Encrypt All Traffic (mTLS)"
n14: rectangle label:"Least-Privilege Access"
n15: rectangle label:"Continuous Monitoring"
n12.handle(right) -> n13.handle(left) [label="Segment"]
n13.handle(right) -> n14.handle(left) [label="Encrypted"]
n14.handle(bottom) -> Resources.n16.handle(top) [label="Scoped Access"]
n15.handle(top) -> PolicyEngine.n7.handle(bottom) [label="Risk Signal"]
}
Resources { # Protected Resources
n16: rectangle label:"Application Service"
n17: rectangle label:"Database"
n18: rectangle label:"API Endpoint"
n19: rectangle label:"Audit Log"
n16.handle(right) -> n17.handle(left) [label="Query"]
n16.handle(right) -> n18.handle(left) [label="Call"]
n16.handle(bottom) -> n19.handle(top) [label="Log Access"]
n16.handle(top) -> User.n4.handle(bottom) [label="Response"]
}
Pourquoi ce workflow ?
Traditional perimeter-based security assumes everything inside the network is trusted—a dangerous assumption when attackers can breach the perimeter or insiders can be compromised. Zero trust verifies every request regardless of network location, using device posture, identity, and risk signals to make continuous access decisions.
Comment ça fonctionne
- Step 1: The user device undergoes a posture check (OS version, encryption, compliance).
- Step 2: Multi-factor authentication verifies the user identity.
- Step 3: The policy engine evaluates identity context, risk score, and access requirements.
- Step 4: If trust level is sufficient, a short-lived JWT token (5-minute TTL) is issued.
- Step 5: Micro-segmentation and mTLS encryption protect all service-to-service communication.
- Step 6: Continuous monitoring feeds risk signals back to the policy engine for real-time re-evaluation.
Alternatives
VPN-based perimeter security is simpler but assumes internal trust. Identity-aware proxies (BeyondCorp) implement zero trust at the network level. This template shows the complete zero trust architecture from device to resource.
Key Facts
| Template Name | Architecture de sécurité Zero Trust |
| Category | Architecture |
| Steps | 6 workflow steps |
| Format | FlowZap Code (.fz file) |
Modèles associés
Architecture
Diagramme d'architecture de maillage de services avec proxys sidecar Istio ou Linkerd gérant le chiffrement mTLS, les politiques de trafic, le disjoncteur et le traçage distribué à travers les microservices. Ce modèle visualise comment un maillage de services abstrait les préoccupations réseau du code applicatif, permettant une communication zero-trust entre les services. Essentiel pour les équipes adoptant une infrastructure de maillage de services pour améliorer l'observabilité et la sécurité.
Architecture
Diagramme d'architecture de passerelle API pour microservices montrant le routage des requêtes, l'authentification JWT, la limitation de débit, la découverte de services et l'agrégation des réponses à travers des services backend distribués. Ce modèle représente le point d'entrée de tout le trafic client dans un écosystème de microservices, appliquant les politiques de sécurité avant que les requêtes n'atteignent les services internes. Idéal pour les ingénieurs plateforme concevant une infrastructure API évolutive avec des préoccupations transversales centralisées.
Architecture
Diagramme d'architecture base de données par service où chaque microservice possède son propre magasin de données dédié, avec synchronisation événementielle via Kafka pour la cohérence des données inter-services. Ce modèle démontre le principe fondamental d'isolation des données des microservices, montrant comment PostgreSQL et MongoDB coexistent dans une stratégie de persistance polyglotte. Critique pour les architectes imposant l'autonomie des services tout en maintenant la cohérence à terme.
Architecture
Diagramme d'architecture de décomposition de microservices organisé par capacités métier : Identité, Catalogue produits, Tarification et Exécution des commandes, chacun avec des magasins de données et des API indépendants. Ce modèle montre comment découper un monolithe en services alignés sur les domaines métier, en utilisant un pattern Backend-for-Frontend (BFF) pour l'agrégation spécifique au client. Utile pour les architectes planifiant les frontières de microservices orientées domaine.
Architecture
Diagramme d'architecture de migration Strangler Fig montrant le remplacement incrémental d'un monolithe legacy par de nouveaux microservices, utilisant une couche de routage pour répartir le trafic entre l'ancien et le nouveau système. Ce modèle représente la stratégie de migration éprouvée où les nouvelles fonctionnalités sont construites en microservices tandis que les endpoints legacy sont progressivement retirés. Essentiel pour les équipes modernisant des systèmes legacy sans réécriture risquée en big-bang.
Architecture
Diagramme d'architecture de découverte de services avec registre Consul ou Eureka, équilibrage de charge côté client, heartbeats de vérification de santé, et enregistrement/désenregistrement automatique des instances. Ce modèle visualise comment les microservices se localisent dynamiquement sans endpoints codés en dur, permettant une mise à l'échelle élastique et une infrastructure auto-réparatrice. Clé pour les équipes plateforme construisant une communication inter-services résiliente.