Architecture Zero Trust

Résumé succinct

Zero Trust (ZT) est un modèle de sécurité dans lequel le périmètre réseau n'est plus considéré comme une zone de confiance. Chaque requête (user→app, service→service, device→network) fait l'objet d'une authentification, d'une autorisation et d'un chiffrement explicites tenant compte des signaux contextuels (identité, état du dispositif, emplacement, risque, comportement). L'objectif est de minimiser le rayon blast, de réduire le risque de mouvement lateral et de simplifier la conformité.

Principes de base de Zero Trust

1. Il n'y a pas de confiance évidente : la confiance n'est pas héritée du réseau/VPN/ASN.
2. L'accès est minimum nécessaire : la politique de « fournir seulement ce dont vous avez besoin maintenant ».
3. Vérification continue : les sessions et les jetons sont régulièrement réévalués en fonction du risque et du contexte.
4. Hypothèse de compromission : segmentation, observabilité, containment rapide et rotation des clés.
5. Cryptage partout : TLS 1. 2+/1. 3 et mTLS à l'intérieur des plans de données, protégé par DNS, secrets dans KMS/HSM.

Paysage cible et domaines de contrôle

Identité : personnes (IdP : SSO, MFA, passkeys/FIDO2), machines (SPIFFE/S...., x509/mTLS).
Périphériques : conformité aux règles (MDM/EDR, disque crypté, patchs, jailbreak/root - non autorisé).
Réseau : micro-segmentation des L3/L7, passerelles ZTNA/SDP, service-mesh (Envoy/Istio/Linkerd).
Applications/API : mTLS, OIDC/JWT, signatures de requête (HMAC), limites de taux, DLP/masquage.
Données : classification (Public/Confidentiel/Restreint), tokenization/cryptage au niveau des champs.
Observabilité : Logs d'authentification/autorisation centralisés, analyse comportementale, SLO/SLA.

Architecture de référence (en coupe des plans)

Plan de contrôle : IdP/CIAM, PDP/PEP (OPA/Envoy), catalogues de politiques, PKI/CA, attestation des appareils.
Data Plane : accès proxy (ZTNA), proxy sidecar (Envoy) pour mTLS et politique L7, passerelles de service/API GW.
Plan de gestion : annuaire de services, CMDB, CI/CD, gestion des secrets (Vault/KMS), audit centralisé.

1. L'identification (SSO + phishing-resistant MFA) → 2) l'Estimation de l'installation (MDM posture) → 3) ZTNA-proxy établit mTLS vers l'application → 4) PDP (la politique) prend la décision à la base des attributs (ABAC/RBAC) → 5) la réévaluation continue du risque (le temps, гео, les anomalies).

Identité et autorisation

IdP/SSO : OIDC/SAML, MFA par défaut, de préférence FIDO2 (passkeys).
RBAC/ABAC : rôles + attributs de contexte (statut de l'appareil, département, profil de risque).
Accès Just-In-Time (JIT) : privilèges temporaires avec révocation automatique ; break-glass - strictement réglementé.
mTLS pour machines : SPIFFE/S....ou PKI interne avec certificats à courte durée de vie ; Sortie rotative automatique.

Périphériques et contexte

Vérification de conformité (posture) : version OS/EDR, disque encript inclus, firewall ; non-compliant → accès minimum ou bloc.
Attestation : identité de périphérique + attestations signées (MDM/Endpoint).
Contraintes réseau : bloc de tunnels tiers, DNS d'entreprise forcé, protection contre les fuites DNS/WebRTC.

Réseau et microsegmentation

Refus des VLAN « plats » : au lieu de cela - segments/VRF et la politique sur L7.
Service Mesh : le proxy sidecar fournit mTLS, l'autorisation de politique (OPA/EnvoyFilter), la télémétrie.
ZTNA/SDP : accès à une application spécifique et non à un réseau ; kliyent↔broker↔app, la politique dans le PDP.
Remote Access : Remplacement d'un VPN « épais » par un proxy d'app ; les tunnels de chute sont limités le long des routes/ports.

Politiques et moteur de décision

PDP/PEP: Policy Decision Point (OPA/Styra, Cedar и пр.) + Policy Enforcement Point (Envoy/Istio/Gateway).
Modèle de politique : règles déclaratives (Rego/Cedar), attributs statiques et contextuels, évaluation des risques.

rego package access. http

default allow = false

allow {
input. user. role == "support"
input. request. path == "/admin/tickets"
input. device. compliant == true time. now_hh >= 8 time. now_hh <= 20
}

Trace des solutions : Loger 'input '/' result '/' explain' pour l'audit.

Cryptage et approbation par défaut

TLS 1. 2+/1. 3 partout, chiffrements stricts, HSTS, stapling OCSP.
mTLS à l'intérieur : servis↔servis uniquement sur certificats mutuels ; les clés sont à courte vie (heures/jours).
Secrets : KMS/HSM, dynamic secrets (Vault), court TTL, least-privilège pour les applications.

Observabilité, SLO et réponse

• Succès de l'authentification et de l'autorisation (%), p95 temps de décision PDP, p95 TLS-handshake.
• Pourcentage de demandes bloquées par la politique (anomalies/fausses).
• Disponibilité des courtiers ZTNA et du contrôleur Mesh.
• Proportion d'appareils compliants et tendances.

• "Disponibilité ZTNA ≥ 99. 95 %/mois ; p95 authZ decision ≤ 50 мс».
• Proportion de requêtes avec mTLS ≥ 99. 9%».
• "Pas plus de 0. 1 % de faux refus d'accès/24 heures ".

Alarting : surtensions de deny, dégradation de la poignée de main p95, chaînes non valides, chute de la proportion de dispositifs compliants, anomalies géographiques/ASN.

Passer du périmètre au Zero Trust : une feuille de route

1. Inventaire : applications, flux de données, consommateurs, sensibilité (PII/cartes/paiements).
2. Identité et MFA : Le SSO et le pishing-resistant MFA pour tous.
3. Contexte des périphériques : MDM/EDR, règles de conformité de base, bloc non-compliant.
4. Micro-segmentation des voies prioritaires : paiements, back office, administration ; Entrez mTLS.
5. ZTNA pour l'accès utilisateur : publier des applications via un proxy, supprimer le « VPN large ».
6. Politiques ABAC : PDP centralisé, règles déclaratives, audit.
7. Extension au service mesh : S2S mTLS, politique L7, télémétrie.
8. Automatisation et SLO : alerting, tests politiques (CI politique), jours de jeu "et si l'IdP n'est pas disponible ? ».

Spécificité pour iGaming/fintech

Segmentation rigide des domaines : paiements/PII/antifrod/contenu - périmètres et politiques distincts ; accès uniquement par ZTNA.
Interaction avec les PSP/banques : allow-list sur ASN/gammes, mTLS aux endpoints PSP, surveillance Time-to-Wallet et défaillances sur authZ.
Fournisseurs de contenu et partenaires : accès JIT temporaires à l'API, jetons TTL courts, audit d'intégration.
Conformité : PCI DSS/GDPR - minimisation des données, DLP/pseudonymisation, journal des accès aux tables sensibles.

Sécurité des chaînes d'approvisionnement et CI/CD

Signatures d'artefacts (SLSA/Provence) : signatures de conteneurs (cosign), politique d'admission en K8s.
SBOM et vulnérabilités : génération SBOM (CycloneDX), policy-gate en pipline.
Secrets en CI : la fédération OIDC vers le cloud KMS ; interdiction des clés statiques.
Rotations : fréquentes, automatiques ; revoke forcé dans les incidents.

Erreurs typiques et anti-modèles

« ZTNA = nouveau VPN » : publier le réseau au lieu des applications n'est pas Zero Trust.
Pas de vérification des appareils : Il y a MFA, mais les appareils infectés/ruthed accèdent.
Un seul super utilisateur : pas de JIT et de rôles séparés.
Politiques dans le code de service : impossibilité d'audit/mise à jour centralisée.
mTLS partiel : partie des services sans mTLS → boucle « percée ».
UX nul : Demandes MFA redondantes, absence de SSO ; le résultat est la résistance aux commandes.

Mini-hyde de choix technologique

Accès utilisateur : courtier ZTNA/SDP + IdP (OIDC, FIDO2 MFA).
Sécurité intraservice : service-mesh (Istio/Linkerd) + OPA/Envoy authZ.
PKI : SPIFFE/S....ou Vault PKI avec TTL courts.
Politiques : OPA/Rego ou Cedar ; stocker dans Git, vérifier dans CI (policy-tests).
Logs et télémétrie : OpenTelemetry → analyse centralisée, détail des anomalies.

Exemples de configurations (fragments)

Envoy (mutual-TLS entre les services)

yaml static_resources:
listeners:
- name: listener_https filter_chains:
- filters:
- name: envoy. filters. network. http_connection_manager typed_config:
"@type": type. googleapis. com/envoy. extensions. filters. network. http_connection_manager. v3. HttpConnectionManager route_config: { name: local_route, virtual_hosts: [] }
transport_socket:
name: envoy. transport_sockets. tls typed_config:
"@type": type. googleapis. com/envoy. extensions. transport_sockets. tls. v3. DownstreamTlsContext common_tls_context:
tls_params: { tls_minimum_protocol_version: TLSv1_2 }
tls_certificates:
- certificate_chain: { filename: /certs/tls. crt }
private_key: { filename: /certs/tls. key }
validation_context:
trusted_ca: { filename: /certs/ca. crt }
require_signed_certificate: true

OPA/Rego : accès aux rapports uniquement à partir des « finances », des appareils compliants, pendant les heures de travail

rego package policy. reports

default allow = false

allow {
input. user. dept == "finance"
input. device. compliant == true input. resource == "reports/profit"
time. now_hh >= 8 time. now_hh <= 21
}

Chèque d'implémentation Zero Trust

1. Activer le SSO et le FIDO2 MFA pour tous les utilisateurs et les amiraux.
2. Entrez device posture (MDM/EDR) avec le verrouillage non-compliant.
3. Transférez l'accès utilisateur à ZTNA (per-app), laissez le VPN uniquement pour les canaux S2S étroits.
4. L'intérieur est mTLS par défaut + certificats à courte durée de vie.
5. Centraliser les politiques (PDP/OPA), stocker dans Git, tester dans CI.
6. Segmenter les domaines sensibles (paiements/PII/back office) et limiter l'est-ouest.
7. Configurez la télémétrie, le SLO et l'alerting sur auth/authZ, mTLS parts, posture signaux.
8. Effectuer « game days » (panne d'IdP, fuite de clés, chute du courtier) et enregistrer les SOP/reculs.

FAQ

Zero Trust remplace-t-il complètement un VPN ?
Pour l'accès utilisateur - oui, en faveur de ZTNA. Pour les autoroutes S2S, VPN/IPsec peut rester, mais avec mTLS au-dessus et des politiques strictes.

ZT peut-il aggraver l'UX ?
Si c'est irréfléchi. Avec le SSO + FIDO2, le MFA adaptatif et l'accès per-app, l'UX est généralement amélioré.

Est-il nécessaire de mettre en œuvre un service mesh ?
Pas toujours. Mais pour un grand environnement microservices, mesh simplifie radicalement mTLS/politique/télémétrie.

Résultat

Zero Trust n'est pas un produit, mais une discipline architecturale : identité en tant que nouveau périmètre, contexte des dispositifs, accès applicatif (ZTNA), microsegmentation et mTLS partout, politiques centralisées et fiabilité mesurable. En suivant la feuille de route et la feuille de vérification, vous réduirez la surface d'attaque, accélérerez l'audit et obtiendrez une sécurité durable sans « confiance par défaut ».