Modèle de diagramme d'architecture réseau zero trust

Beaucoup de diagrammes étiquetés « zero trust » sont des diagrammes de périmètre avec un nouveau titre : un pare-feu en bordure, une DMZ et un intérieur de confiance. Un diagramme d'architecture zero trust utile répond à trois questions d'un coup d'œil : où chaque décision d'accès est-elle prise, quels signaux alimentent cette décision, et où est-elle appliquée ? Si l'image ne répond pas à ces questions, elle décrit un emplacement réseau, pas la confiance.

Au programme : le modèle logique du NIST SP 800-207, des règles de dessin qu'un relecteur peut vérifier, les erreurs fréquentes et un modèle gratuit à copier dans Archboard.

Le modèle du NIST SP 800-207

Le NIST SP 800-207 définit l'architecture zero trust (ZTA) autour d'une idée : aucune confiance implicite fondée sur l'emplacement réseau ou la propriété d'un actif. L'accès à chaque ressource est accordé par session, décidé par une politique dynamique et appliqué avant que le sujet n'atteigne la ressource.

Les trois composants logiques

Ensemble, le PE et le PA forment le Policy Decision Point (PDP). Dans les systèmes réels, le PE peut vivre dans un proxy sensible à l'identité ou dans le plan de contrôle d'un service mesh, et les PEP sont des passerelles, des sidecars, des agents ou des proxys. Le diagramme doit tout de même rendre chaque rôle visible, même si un seul produit en joue deux.

Les sources de données derrière la décision

Le SP 800-207 liste les entrées qu'un PE peut utiliser. Celles qui ont leur place sur presque tous les diagrammes :

• Fournisseur d'identité / gestion des identités : utilisateurs, identités de services, groupes, niveau d'authentification.
• État des appareils (CDM) : données de diagnostic et d'atténuation continus ; l'appareil est-il connu, géré, à jour ?
• Threat intelligence : flux sur les nouvelles attaques, les comptes compromis et les vulnérabilités.
• Journaux d'activité et SIEM : activité réseau et système collectée et analysée ; c'est là que commence la boucle de rétroaction.
• PKI d'entreprise : certificats pour les utilisateurs, les appareils et les workloads.

La norme cite aussi les politiques d'accès aux données et les exigences de conformité ; dessinez-les si elles influencent réellement les décisions.

Comment dessiner un diagramme d'architecture zero trust

1. Placez un PEP sur chaque chemin d'accès

Suivez chaque flèche d'un sujet (utilisateur, appareil, service) vers une ressource. Chacune doit d'abord traverser un point d'application. Si une flèche contourne le PEP, soit le diagramme est faux, soit l'architecture a une faille. Incluez les chemins d'administration, de CI/CD et d'accès d'urgence (break-glass), pas seulement le chemin utilisateur.

2. Montrez les signaux d'identité et d'appareil qui alimentent la décision

Dessinez le fournisseur d'identité, l'état des appareils, la threat intel et le SIEM comme des nœuds reliés au Policy Engine. Étiquetez les liens avec ce qui circule : « utilisateur + groupes (OIDC) », « conformité de l'appareil », « signaux de risque ».

3. Rendez explicites l'authN et l'authZ par session

Le NIST décrit un accès accordé par session ; beaucoup d'implémentations réévaluent à chaque requête. Dans les deux cas, montrez la séquence : le sujet demande l'accès, le PEP interroge le PDP, le PE évalue, le PA configure le PEP, et le PEP autorise ou bloque la session. Des étiquettes numérotées sur les liens suffisent ; ajoutez un petit diagramme de séquence pour plus de détail.

4. Séparez le plan de contrôle du plan de données

Placez le PE, le PA et les sources de données dans une zone, et les sujets, les PEP et les ressources dans une autre. Seuls le canal de contrôle PA vers PEP, les flux de signaux et le flux de journaux traversent la frontière.

5. Montrez la micro-segmentation et le trafic est-ouest

Le zero trust ne concerne pas seulement les utilisateurs qui accèdent aux applications. Pour le trafic de service à service, dessinez :

• l'identité des workloads (par exemple des certificats liés à un service account),
• le mTLS entre services, et la CA ou la PKI qui émet ces certificats,
• la politique de segmentation entre workloads, par exemple une NetworkPolicy Kubernetes.

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: orders-allow-from-checkout
  namespace: orders
spec:
  podSelector:
    matchLabels:
      app: orders
  policyTypes:
    - Ingress
  ingress:
    - from:
        - namespaceSelector:
            matchLabels:
              kubernetes.io/metadata.name: checkout
          podSelector:
            matchLabels:
              app: checkout
      ports:
        - protocol: TCP
          port: 8443

Une NetworkPolicy agit aux couches 3 et 4 et ne s'applique que si votre plugin CNI la prend en charge. C'est de la segmentation, pas de l'authentification : associez-la dans le diagramme au mTLS et à une autorisation au niveau d'un PEP.

6. Traitez les secrets et les certificats comme des éléments à part entière

Représentez le vault (gestionnaire de secrets) et la PKI comme des nœuds distincts. Dessinez quels workloads récupèrent quels secrets, et avec quelle identité. Dans le modèle du NIST, les identifiants propres à la session viennent du PA : reliez-les au flux de décision.

7. Gardez le WAF et les pare-feu, au bon endroit

Le zero trust ne supprime ni le WAF ni les pare-feu. Ils filtrent toujours en bordure et entre segments, mais ils ne prennent pas la décision de confiance. Dessinez-les comme des filtres sur le chemin, pas comme le mur d'une zone de confiance.

8. Fermez la boucle avec la journalisation

Chaque PEP et chaque pare-feu doit envoyer ses journaux au SIEM, et l'analyse doit revenir vers le Policy Engine. Sans ce lien, le « continu » de la vérification continue manque sur l'image.

Erreurs fréquentes

• Château fort et douves, renommés. Un gros pare-feu extérieur, un « réseau interne de confiance » et aucun contrôle entre les services internes.
• Pas de flux de décision. L'IdP et une passerelle sont sur le canevas, mais rien ne montre où la décision est prise ni ce qu'elle consomme.
• Pas de boucle de rétroaction. Les journaux ne vont nulle part, ou le SIEM est une impasse sans lien vers la politique.
• Uniquement nord-sud. Le chemin utilisateur vers application est couvert ; les chemins de service à service et d'administration vers l'infrastructure ne le sont pas.
• Des zones dessinées comme de la confiance. Des Frames pour les segments, c'est très bien, mais nommez-les segments ou domaines d'application, pas « de confiance ».

Le construire dans Archboard

Les packs intégrés couvrent toutes les pièces. Le pack Security contient des nœuds pour le fournisseur d'identité, le WAF, le pare-feu, la passerelle zero trust, le vault et les certificats. Le pack Network propose Internet, DNS, load balancer, ainsi que VPC et subnet sous forme de frames. Le pack Kubernetes ajoute Namespace (dessiné comme un frame), Service, Pod et NetworkPolicy. Les nœuds ont des ports : chaque lien s'attache à un côté précis d'un nœud au lieu de flotter sur une forme.

1. Posez les plans avec des Frames. Ajoutez deux Frames du pack Core, « Control plane » et « Data plane ». Dans le plan de données, ajoutez un Frame par segment, par exemple « Edge », « App segment » et « Data segment ». Pour les workloads Kubernetes, utilisez le nœud Namespace.
2. Ajoutez les sujets et la bordure. Placez un nœud Internet du pack Network pour les utilisateurs, puis un nœud WAF du pack Security, puis le nœud de passerelle zero trust comme PEP de l'accès utilisateur.
3. Ajoutez la décision et ses entrées. Dans le frame du plan de contrôle, placez le nœud fournisseur d'identité et des nœuds Box du pack Core étiquetés « Policy Engine », « Policy Administrator », « Device posture (CDM) », « Threat intel » et « SIEM ».
4. Câblez le flux de décision. Reliez les sources de signaux au Policy Engine, le Policy Engine au Policy Administrator, et le Policy Administrator à chaque PEP. Étiquetez les liens.
5. Ajoutez les chemins est-ouest. Dans chaque Namespace, ajoutez des nœuds Service et Pod ainsi qu'un nœud NetworkPolicy. Ajoutez un nœud certificat pour l'émetteur mTLS et un nœud vault pour les secrets, reliés aux workloads qui les utilisent.
6. Placez des pare-feu entre les segments. Utilisez le nœud pare-feu du pack Security là où le trafic traverse les frames de segments.
7. Fermez la boucle. Tracez des liens de chaque PEP et pare-feu vers le SIEM, puis du SIEM vers le Policy Engine.
8. Écrivez les hypothèses sur le canevas. Utilisez un bloc Markdown pour les règles de politique et la durée des sessions, avec un bloc de code YAML délimité à l'intérieur pour la NetworkPolicy.

Un diagramme aussi complet peut dépasser la limite de 15 nœuds de diagramme par diagramme du plan Free ; les notes et les textes sont comptés à part, jusqu'à 150. En Free, découpez-le en une vue d'ensemble et un diagramme de détail Kubernetes ; Pro supprime la limite de nœuds. Vous pouvez exporter en SVG ou PNG (avec filigrane en Free), partager un lien public et exporter le JSON structuré pour le garder à côté de votre code d'infrastructure.

Le modèle gratuit

L'exemple Zero Trust Perimeter montre des utilisateurs qui entrent par un WAF en bordure, un nœud IdP / SSO connecté en OIDC, une passerelle zero trust, un pare-feu de segment, un vault de secrets et une PKI mTLS autour d'une application privée. Ouvrez-le et copiez-le dans votre espace de travail avec Utiliser cet exemple. Complétez-le ensuite avec le frame du plan de contrôle, les sources de signaux et la boucle de journalisation décrits ici. Pour le réseau sous-jacent, consultez l'exemple de réseau de datacenter et le cas d'usage des diagrammes réseau.

Checklist et FAQ

Avant de partager le diagramme, vérifiez que :

• chaque chemin du sujet vers la ressource traverse un PEP,
• les signaux d'identité, d'appareil, de menace et de journaux alimentent le Policy Engine,
• plan de contrôle et plan de données sont visiblement séparés,
• le trafic est-ouest montre le mTLS et la segmentation,
• les secrets et la PKI montrent qui récupère quoi,
• les journaux des PEP et des pare-feu vont au SIEM et reviennent vers la politique.

Un diagramme d'architecture zero trust est-il un simple diagramme réseau ? Non. Un diagramme réseau montre où vont les paquets. Un diagramme ZTA ajoute où l'accès est décidé, sur quels signaux, et où il est appliqué.

Ai-je encore besoin de pare-feu dans une conception zero trust ? Oui. Les pare-feu et les WAF réduisent toujours l'exposition ; ils cessent simplement d'être la raison pour laquelle quelque chose est considéré comme fiable.

Une NetworkPolicy Kubernetes suffit-elle pour faire du zero trust ? Pas à elle seule. Elle apporte une segmentation L3/L4. Il vous faut encore une identité de workload, du mTLS, une autorisation au niveau d'un PEP et de la journalisation.

Commencez gratuitement — un siège, sans carte bancaire.