Architecture de référence pour la sécurité du cloud hybride

Une architecture de référence en matière de sécurité du cloud hybride est un schéma indépendant des fournisseurs qui illustre la manière dont les contrôles de sécurité s'articulent entre l'infrastructure sur site, le cloud privé, le SaaS et le cloud public. Elle sert à planifier les déploiements, à comparer les fournisseurs, à expliquer la conception de la sécurité aux auditeurs et à mesurer les progrès accomplis vers le modèle « zero trust ».

Cet article présente un modèle de référence complet : les principes de conception qui le sous-tendent, les schémas logiques et de déploiement, un répertoire des composants, six flux de trafic, les limites de contrôle, les considérations de conception relatives à l'identité, à la journalisation, à la capacité et à la résilience, une mise en correspondance avec les contrôles de la CISA et du NIST, cinq exemples de déploiement, ainsi qu'un parcours de maturité assorti de tests de validation.

Cet article fait partie du guide consacré à la sécurité du cloud hybride. Pour obtenir une vue d'ensemble de l'infrastructure des environnements hybrides, consultez la section « Architecture du cloud hybride : composants et modèles de déploiement ».

Principes de conception qui sous-tendent le modèle de référence

Le modèle de référence repose sur quatre principes tirés des recommandations du NIST et de la CISA en matière de « zero trust ».

1. Distinguez les décisions de l'application. La norme NIST SP 800-207 établit une distinction entre le point de décision de politique (PDP), qui détermine si l'accès est autorisé, et le point d'application de la politique (PEP), qui établit, surveille ou interrompt la connexion. Un seul PDP, plusieurs PEP.
2. Ne confiez pas de manière aveugle en fonction de l'emplacement sur le réseau. Le fait de se trouver sur le réseau local de l'entreprise ne justifie pas de faire l'impasse sur l'authentification ou l'inspection. La norme NIST SP 800-215 décrit la disparition d'un périmètre significatif comme une caractéristique déterminante des réseaux d'entreprise actuels.
3. Protégez les données en fonction de leur classification, et non de leur emplacement. Les contrôles suivent la classe de données où qu'elle se trouve.
4. Partons du principe que n'importe quelle dépendance peut tomber en panne. Les fournisseurs d'identité, les services cloud et les liaisons WAN peuvent tous cesser de fonctionner. L'architecture définit ce qui se passe dans ce cas.

Le guide pratique SP 1800-35 du NIST , intitulé « Mise en œuvre d’une architecture Zero Trust », publié en juin 2025 en collaboration avec 24 fournisseurs, présente 19 exemples de mise en œuvre de ces principes dans des environnements sur site et dans le cloud ; il constitue un complément utile à ce modèle.

Schémas d'architecture

L'architecture de référence est décrite à travers deux perspectives : une perspective logique de ses niveaux et une perspective de déploiement indiquant où s'exécutent les composants.

Architecture logique

L'architecture logique comporte trois plans : un plan de contrôle centralisé, un plan d'application distribué et un plan de visibilité partagé.

Le plan de contrôle définit la politique une seule fois. Le plan d'application la met en œuvre partout où le trafic circule. Le plan de visibilité recueille les données télémétriques provenant de chaque point d'application et réinjecte les signaux de risque dans la politique.

Topologie de déploiement

La vue « Déploiement » indique l'emplacement physique de chaque point de contrôle au sein du siège social, des succursales, des régions cloud et chez les utilisateurs distants.

Référence des composants

Chaque composant a un rôle, un emplacement et un ensemble d'exigences spécifiques aux systèmes hybrides qui lui sont propres.

Flux de circulation

Six flux de trafic couvrent la plupart des environnements hybrides, et chacun d'entre eux doit comporter un point de contrôle documenté et un point de décryptage.

Flux n° 1 : Connexion d'un utilisateur de bureau à Internet ou à un service SaaS

L'utilisateur s'authentifie via le fournisseur d'identité. Le trafic est acheminé vers la passerelle locale, qui le déchiffre, le soumet à une analyse de détection des menaces et applique la politique d'accès et de sécurité Web, puis transfère les sessions soumises à la protection des données vers le cloud du fournisseur afin qu'elles y soient inspectées conformément à cette même politique. Documentez la terminaison TLS et le rechiffrement tout au long de ce parcours et évitez toute inspection redondante, conformément aux recommandations de la NSA relatives à la gestion des risques liés à l'inspection TLS.

Flux n° 2 : Utilisateur distant vers un service SaaS

L'agent de terminal ou les contrôles du navigateur orientent le trafic vers le point de présence cloud agréé le plus proche. Le même ensemble de règles s'applique que dans le flux 1. Le CASB ajoute des contrôles spécifiques au SaaS, tels que les restrictions par locataire et la prévention des fuites de données (DLP) au niveau des activités.

Processus n° 3 : De l'utilisateur à l'application privée

L'accès s'effectue via le protocole ZTNA, et non via un VPN au niveau du réseau. Le service d'accès vérifie l'identité, l'état de sécurité du terminal et la conformité aux politiques, puis connecte l'utilisateur uniquement à une application autorisée. Un déploiement peut recourir à un courtier cloud pour les utilisateurs distants et à une passerelle locale pour les sessions sur site prises en charge. Vérifiez l'emplacement du courtier, les protocoles d'application, la visibilité des sessions et le chemin de données effectif. Reportez-vous à la section « ZTNA sur site pour les applications privées ».

Flux n° 4 : D'une charge de travail à une autre

Le trafic de service à service entre le centre de données et les charges de travail IaaS s'appuie sur l'identité des charges de travail, le protocole TLS mutuel et des règles de segmentation. C'est la même source de politique qui définit quels services sont autorisés à communiquer entre eux.

Flux n° 5 : Données au repos dans les services cloud

L'intégration de l'API CASB et l'analyse DSPM inspectent les solutions de stockage dans le cloud et les services SaaS autorisés afin de détecter la présence de données sensibles, de partages à risque et d'autorisations excessives, puis corrigent ces problèmes en appliquant la même classification en temps réel. Découvrez comment le DSPM et le SSE fonctionnent ensemble.

Processus n° 6 : Agents IA et comptes de service

Les agents d'IA et les systèmes d'automatisation disposent souvent d'un accès au niveau utilisateur et appellent des API internes via des connexions de longue durée, notamment des WebSockets, qui proviennent de l'intérieur du réseau. Attribuez à chaque agent sa propre identité et des droits spécifiques à chaque application, acheminez son trafic via un point de contrôle local et appliquez une politique de prévention des fuites de données (DLP) aux données qu'il envoie vers des services d'IA externes.

Limites de contrôle

Les limites de contrôle doivent être définies en fonction de ce qui doit être protégé, et non en fonction de l'emplacement des équipements.

La limite de juridiction est souvent négligée. Si du trafic déchiffré, des journaux d’inspection ou des copies d’incidents DLP sortent d’une juridiction, l’architecture risque de ne plus respecter les engagements en matière de résidence des données, même si les données stockées ne sont jamais transférées. Voir la section « Souveraineté des données » dans « Sécurité du cloud hybride ».

Sécurité réseau pour le cloud hybride

Dans un environnement hybride, la sécurité réseau passe de la protection du périmètre à celle des connexions individuelles.

• Remplacez les relations de confiance « site à site » simples par une segmentation et un accès par application.
• Maintenez des tunnels chiffrés (IPsec, GRE ou interconnexions privées) entre les sites et les régions cloud, mais ne considérez pas l'appartenance à un tunnel comme une autorisation.
• Orientez le trafic de manière ciblée : proxy explicite ou fichiers PAC pour les réseaux d'entreprise gérés, agents ou contrôles de navigateur pour les utilisateurs en itinérance, tunnels pour les succursales.
• Déterminez quel composant déchiffre chaque flux, afin qu'aucun flux ne soit déchiffré deux fois.
• Enregistrez les données à chaque point de contrôle et effectuez une mise en correspondance de manière centralisée.

Le document NIST SP 800-215 passe en revue ces options, notamment le ZTNA, la microsegmentation, les périmètres définis par logiciel et les modèles SASE (Secure Access Service Edge) qui combinent des services réseau et de sécurité.

Considérations relatives à la conception

Quatre domaines de conception déterminent si l'architecture fonctionne dans la pratique : l'identité, la journalisation, la capacité et le comportement en cas de défaillance.

Architecture d'identité

L'identité constitue le premier critère pris en compte dans toute décision d'accès ; c'est pourquoi l'architecture de référence considère quatre types d'identité comme des éléments essentiels.

• Utilisateurs de l'entreprise. Un fournisseur d'identité de référence, fédéré à tous les fournisseurs de services cloud et à toutes les applications SaaS, doté d'une authentification multifactorielle (MFA) résistante au phishing et d'un accès conditionnel. Les données relatives aux groupes et aux rôles doivent provenir d'une source unique afin d'éviter toute divergence des droits d'accès entre les environnements.
• Appareils. L'identité et l'état de sécurité des appareils (statut de gestion, niveau de correctifs, chiffrement du disque, protection des terminaux) doivent être évalués tant pour les utilisateurs sur site que pour ceux travaillant à distance.
• Charges de travail et services. Les applications et les services s'authentifient mutuellement à l'aide d'identités de charge de travail et d'un protocole TLS réciproque, plutôt que par le biais de secrets partagés ou d'une localisation réseau.
• Agents IA et automatisation. Chaque agent dispose de sa propre identité, de droits d'accès bien délimités et d'un responsable humain, ce qui permet d'autoriser, d'enregistrer et de révoquer ses actions de manière indépendante.

Deux détails de conception peuvent facilement passer inaperçus. Premièrement, les sessions doivent être réévaluées lorsque le contexte change, par exemple lorsqu’un appareil n’est plus conforme, plutôt que d’être considérées comme fiables jusqu’à leur expiration. Deuxièmement, définissez un accès d’urgence pour les administrateurs qui fonctionne lorsque le fournisseur d’identité n’est pas disponible, avec des contrôles rigoureux et des alertes en cas d’utilisation.

Enregistrement et télémétrie

Dans une architecture hybride, la journalisation doit permettre la détection, l'analyse et la conformité, tout en respectant les restrictions relatives à la diffusion des données.

• Éléments à collecter. Chaque point d'application doit consigner l'utilisateur, l'appareil, l'application ou la destination, la décision relative à la politique, la règle à laquelle il a été associé et la classification des données concernées. Utilisez des clés de corrélation courantes (identifiant utilisateur, identifiant de l'appareil, identifiant de session) afin de pouvoir regrouper les événements provenant de l'application locale et de l'application dans le cloud.
• Où les collecter. Les collecteurs locaux présents sur chaque site principal stockent d'abord les événements, puis les transmettent au SIEM central. Cela permet de préserver les journaux en cas de panne du réseau étendu (WAN) et d'effectuer une transmission sélective.
• Éléments à transmettre. Transmettez les métadonnées nécessaires à la détection. Conservez l'intégralité des preuves DLP et des extraits de contenu dans la juridiction où ils ont été recueillis, en limitant l'accès aux enquêteurs habilités.
• Conservation. Veillez à ce que les délais de conservation soient conformes aux exigences réglementaires applicables à chaque catégorie de données et à chaque juridiction, et consignez-les par écrit.
• Intégrité. Protégez les journaux contre toute altération et signalez les lacunes, qui peuvent être le signe tant de défaillances que d'attaques.

Capacité et dimensionnement

Les points de contrôle locaux doivent être dimensionnés pour prendre en charge le trafic déchiffré aux heures de pointe, ce qui constitue la source la plus courante de problèmes de performances dans les déploiements hybrides.

• Mesurez le débit maximal et les taux de connexion par site, ainsi que la part du trafic qui sera déchiffrée. Le déchiffrement TLS est une opération très gourmande en ressources informatiques.
• Dimensionnez les clusters en prévoyant une marge suffisante pour le basculement, afin que la perte d'un nœud ne surcharge pas les autres.
• Tenez compte de l'augmentation du trafic chiffré, des transferts de fichiers plus volumineux et des sessions d'IA et de collaboration de longue durée.
• Prévoyez comment augmenter la capacité. Les appliances virtuelles et conteneurisées peuvent évoluer plus rapidement que le matériel dédié.
• En ce qui concerne les points de présence dans le cloud, veuillez vérifier auprès du fournisseur la capacité régionale et les options de basculement, en particulier lorsque des contraintes de localisation limitent les régions que vous pouvez utiliser.

Résilience et comportement en cas de défaillance

Une architecture de référence n'est pas complète tant qu'elle ne définit pas ce qui se passe en cas de défaillance de chaque dépendance.

• Cloud du fournisseur indisponible : l'application locale de la politique relative au Web et aux applications privées se poursuit à l'aide de la politique mise en cache, tandis que les services fournis depuis le cloud, notamment la protection des données, remote browser isolation, les contrôles de sécurité basés sur l'IA, le CASB et la gestion de la posture de sécurité des données, ne sont pas appliqués tant que la connexion n'est pas rétablie ; les utilisateurs distants basculent vers d'autres points de présence.
• Fournisseur d'identité indisponible : indiquez si les sessions existantes doivent se poursuivre et s'il existe une solution de secours locale.
• En cas de panne de la connexion WAN du site ou de la connexion Internet : le ZTNA local permet de continuer à accéder aux applications locales depuis le site.
• Défaillance d'une passerelle locale : un nœud du cluster ou un point de présence dans le cloud prend le relais selon la même politique.
• « Fail-open » ou « fail-closed » : déterminez ce paramètre pour chaque classe de trafic et rendez cet état visible pour les équipes d'exploitation.

Pour consulter un plan de test, veuillez vous reporter à la section « Résilience du SSE hybride : basculement et reprise ».

Mise en correspondance des contrôles avec les normes CISA et NIST

Le fait de mettre en correspondance chaque composant avec des référentiels reconnus permet de transformer l'architecture de référence en élément probant pour les auditeurs et en liste de contrôle pour les responsables de la mise en œuvre.

Le tableau établit une correspondance entre les composants et les piliers du modèle de maturité « Zero Trust » de la CISA, ainsi qu'avec les familles de contrôles représentatives de la norme NIST SP 800-53, révision 5.

Cette correspondance constitue un point de départ. Chaque organisation doit vérifier l'applicabilité des contrôles au regard de ses propres critères de référence et de son champ d'application réglementaire.

Exemples de déploiement

Ce même modèle de référence s'adapte à différents secteurs d'activité en modifiant les points d'application, et non en redéfinissant la politique.

Exemple n° 1 : Banque régionale

Le siège social et les centres de données exploitent des passerelles SWG et ZTNA locales afin que les données des clients ne soient déchiffrées et inspectées que sur une infrastructure contrôlée par la banque. Le trafic des agences passe par des appareils locaux ou par des tunnels vers le centre de données le plus proche. Le personnel à distance utilise des points de présence dans le cloud limités aux sites situés dans la même région. Les journaux d’inspection restent sur le territoire national. Ce modèle répond aux exigences de la directive DORA en matière de risques informatiques et aux exigences relatives aux tiers applicables aux institutions de l’UE, tout en permettant l’utilisation d’une solution CASB dans le cloud pour les services SaaS.

Exemple n° 2 : Fabricant disposant de réseaux OT

Un pare-feu de segmentation sépare les réseaux OT de l'usine des réseaux informatiques de l'entreprise. Les systèmes OT ne peuvent accéder qu'aux destinations approuvées pour les mises à jour et la télémétrie via un SWG local. Les ingénieurs accèdent aux systèmes de l'usine via un ZTNA local, avec des contrôles de l'état de sécurité des appareils. En cas de défaillance du réseau étendu (WAN) ou d'un service cloud, l'accès à l'usine et les opérations d'inspection se poursuivent en local.

Exemple n° 3 : organisme du secteur public

Les réseaux classifiés ou déconnectés nécessitent des composants explicitement pris en charge pour fonctionner sans services externes. Les réseaux non classifiés peuvent recourir à des services cloud dûment autorisés pour les télétravailleurs. Veuillez documenter la synchronisation des politiques, l’identité, les mises à jour et les dépendances en matière de licences, et soumettre les exceptions spécifiques à l’environnement à un contrôle des modifications.

Exemple n° 4 : Système de santé régional

Le dossier médical électronique et les systèmes d’imagerie fonctionnent dans les centres de données du système de santé. Les postes de travail cliniques des hôpitaux utilisent des passerelles locales ; ainsi, les données des patients circulant via le Web et les services SaaS sont inspectées sur site. Les dispositifs médicaux sont situés dans des zones segmentées dont l’accès sortant est strictement limité. Les cliniciens travaillant à distance accèdent au dossier médical électronique via le courtier ZTNA dans le cloud, soumis à des exigences en matière de gestion des appareils, et les règles DLP relatives aux informations de santé protégées s’appliquent de manière identique dans les deux cas, conformément aux mesures de protection prévues par la règle de sécurité HIPAA.

Exemple n° 5 : enseigne de distribution internationale

Les magasins utilisent de petites passerelles ou des tunnels vers des hubs régionaux, avec des systèmes de point de vente intégrés dans un environnement segmenté de données des titulaires de cartes dont l’accès est limité aux seuls prestataires de paiement. La navigation du personnel de l’entreprise et des magasins est contrôlée au niveau des hubs régionaux ou des points de présence dans le cloud, le trafic européen étant limité aux régions de l’UE et les journaux d’activité étant stockés au sein de la région. Les systèmes des magasins continuent de fonctionner en cas de panne du réseau étendu (WAN), car la segmentation locale et les règles d’accès ne dépendent pas du cloud. Cela permet de respecter les exigences de la norme PCI DSS en matière de segmentation et de journalisation.

Parcours de maturation et validation

Utilisez les niveaux de maturité définis par la CISA pour organiser le déploiement par étapes, et recourez à des tests reproductibles pour vérifier le bon fonctionnement de chaque étape.

Parcours de maturité

Les organisations mettent rarement en œuvre l'architecture de référence dans son intégralité d'un seul coup ; le modèle de la CISA décrit quatre étapes (traditionnelle, initiale, avancée et optimale) qui constituent une feuille de route utile.

Utilisez l'écart entre l'étape actuelle et la suivante comme base pour établir un plan par étapes.

Validation de l'architecture

La qualité d'une architecture dépend entièrement de la fiabilité de son comportement lors des tests ; veillez donc à valider chaque flux et chaque limite à l'aide de tests reproductibles.

• Envoyez une URL connue pour être malveillante, un fichier malveillant de test et un document de test DLP via chaque point de contrôle, puis vérifiez que les résultats obtenus sont identiques lorsque le chemin d'accès au cloud est disponible. Enregistrez le comportement attendu des contrôles appliqués dans le cloud lorsque ce chemin d'accès est interrompu.
• Vérifiez que chaque flux est déchiffré exactement une fois.
• Essayez d'accéder à une application privée depuis le site, à distance et à partir d'un appareil non géré, puis vérifiez que les résultats correspondent à vos attentes.
• Bloquez l'accès depuis un site au cloud du fournisseur et assurez-vous que les mesures de sécurité locales continuent d'être appliquées.
• Vérifiez que les journaux provenant de chaque point de contrôle parviennent bien au SIEM et que les règles de conservation sont respectées.

Comment Skyhigh s'inscrit dans l'architecture de référence

Skyhigh Hybrid SSE Mesh couvre le plan de contrôle (une console et un moteur de politiques avec les politiques déployées sous forme de code), l'application locale (appareils SWG sur site avec inspection TLS locale et ZTNA local), l'application dans le cloud (SWG, CASB, ZTNA et RBI dans le cloud), les contrôles au niveau du navigateur et le DSPM (Skyhigh Security).

Pour la protection des clés d'inspection et le sandboxing sur site, veuillez vérifier auprès de Skyhigh les intégrations prises en charge, les versions des produits et les exigences de déploiement. Ne partez pas du principe que la passerelle ou le service choisi prend en charge les HSM.

Sources

1. NIST. SP 800-207 : Architecture « Zero Trust » (août 2020). https://csrc.nist.gov/pubs/sp/800/207/final
2. NIST. SP 800-215 : Guide pour un environnement réseau d'entreprise sécurisé (novembre 2022). https://csrc.nist.gov/pubs/sp/800/215/final
3. NIST NCCoE. SP 1800-35 : Mise en œuvre d'une architecture « Zero Trust » (juin 2025). https://csrc.nist.gov/pubs/sp/1800/35/final
4. NIST. SP 800-53, rév. 5 : Mesures de sécurité et de protection de la vie privée pour les systèmes d'information et les organisations. https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final
5. CISA. Modèle de maturité « Zero Trust », version 2.0. https://www.cisa.gov/zero-trust-maturity-model
6. NSA. Gestion des risques liés à l'inspection du protocole SSL (novembre 2019). https://media.defense.gov/2019/Nov/18/2002212783/-1/-1/0/MANAGING%20RISK%20FROM%20TLS%20INSPECTION_20191106.PDF
7. Union européenne. Règlement (UE) n° 2022/2554 (loi sur la résilience opérationnelle numérique). https://eur-lex.europa.eu/eli/reg/2022/2554/oj
8. Ministère américain de la Santé et des Services sociaux (HHS) . Règle de sécurité HIPAA. https://www.hhs.gov/hipaa/for-professionals/security/index.html
9. Conseil des normes de sécurité PCI. PCI DSS v4.0.1 (bibliothèque de documents). https://www.pcisecuritystandards.org/document_library/
10. Skyhigh Security. « Moderniser votre infrastructure Symantec Edge Secure Web Gateway , grâce à Skyhigh Hybrid SSE Mesh » (15 juillet 2026). https://www.skyhighsecurity.com/industry-perspectives/modernizing-your-symantec-edge-secure-web-gateway-with-skyhigh-hybrid-sse-mesh.html
11. Skyhigh Security. « L'adoption de l'hybride est désormais plus simple grâce à la plateforme Skyhigh SSE » (3 octobre 2024). https://www.skyhighsecurity.com/cloud-security/adopting-hybrid-just-got-easier-with-skyhigh-sse-platform.html