Sécurité du cloud hybride : architecture et bonnes pratiques
- La sécurité du cloud hybride protège les utilisateurs, les données et les charges de travail, tant dans les environnements sur site que dans le cloud, au sein d'un système unique.
- Les risques les plus importants se situent aux points de jonction : l'identité, les chemins de trafic, les mouvements de données et la dérive des politiques.
- Centralisez les décisions relatives aux politiques et décentralisez leur mise en œuvre là où le trafic prend sa source et où les données doivent être conservées.
- Choisissez un déploiement dans le cloud, sur site ou hybride pour chaque charge de travail, en fonction de la latence, de la souveraineté, de la résilience et du coût.
- SSE sécurise l'accès des utilisateurs aux applications Web, SaaS et privées, et peut fonctionner dans le cloud ou sur site.
L'architecture de sécurité du cloud hybride est la conception qui détermine où se situent les contrôles de sécurité, comment les politiques sont définies une seule fois et appliquées de manière cohérente, et comment les données sont protégées lors de leur transfert entre les systèmes sur site et les services cloud. Une architecture solide considère l'environnement hybride comme un environnement unique comportant de nombreux points d'application, et non comme un centre de données auquel un cloud aurait été ajouté.
La plupart des entreprises fonctionnent désormais de cette manière. Le rapport « State of the Cloud 2026 » de Flexera a révélé que 73 % des organisations exploitent des environnements hybrides. Ce guide explique les risques liés à ce modèle, l’architecture permettant d’y remédier, les décisions à prendre en matière de déploiement et de protection des données, la place qu’occupe l’ Security Service Edge (SSE), ainsi que les meilleures pratiques et les considérations de conformité qui viennent compléter le tout. Chaque section renvoie vers un article complémentaire plus détaillé. Pour une vue d’ensemble de l’infrastructure, y compris les composants, les modèles de déploiement et les modèles d’architecture, consultez « Architecture du cloud hybride : composants et modèles de déploiement ».
Qu'est-ce que la sécurité du cloud hybride ?
La sécurité du cloud hybride consiste à protéger les utilisateurs, les applications et les données au sein d'un environnement combinant une infrastructure sur site, un cloud privé et un cloud public, en appliquant de manière cohérente des principes d'identité, de politique de sécurité, de protection des données et de surveillance à l'ensemble de ces environnements.
Elle couvre quatre aspects que la sécurité en environnement unique ne couvre pas :
- Les liaisons entre les environnements, notamment les interconnexions, les tunnels et le trafic qui les traverse.
- Cohérence de la politique, de sorte qu'un utilisateur, un appareil ou un type de données soit traité de la même manière, quel que soit l'endroit où le trafic est géré.
- Répartissez les responsabilités, car chaque service cloud répartit différemment les tâches de sécurité entre le fournisseur et le client.
- Les décisions relatives à l'emplacement, car l'organisation doit choisir où s'effectuent l'inspection, le déchiffrement et la journalisation pour chaque chemin de trafic.
On confond souvent le « cloud hybride » avec le « multi-cloud », qui désigne le recours à plusieurs fournisseurs de cloud public. La plupart des grandes entreprises ont recours aux deux. Voir « Sécurité du cloud hybride vs. sécurité du multi-cloud ».
Avantages de la sécurité du cloud hybride
Un programme de sécurité dans le cloud hybride bien conçu offre aux organisations davantage de contrôle qu'une approche exclusivement axée sur le cloud et davantage de flexibilité qu'une approche exclusivement sur site.
Contrôle du lieu de traitement des données. Le trafic soumis à une réglementation peut être déchiffré et inspecté sur l’infrastructure propre à l’organisation, tandis que le trafic moins sensible est acheminé via des services cloud. Cela simplifie les évaluations en matière de souveraineté et de confidentialité. Voir la section « Souveraineté des données » dans « Sécurité du cloud hybride ».
Résilience opérationnelle. L’application locale des politiques relatives au Web et aux applications privées continue de fonctionner en cas de défaillance d’un fournisseur de cloud, d’une liaison WAN ou d’une connexion Internet. Les services mis en œuvre dans le cloud du fournisseur, notamment la protection des données, l’ 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, dépendent de l’accessibilité du cloud et reprennent dès que la liaison est rétablie. La sécurité ne devient pas un point de défaillance unique échappant au contrôle de l’organisation pour le trafic soumis à des politiques appliquées localement. Voir « Résilience du SSE hybride ».
Des performances là où cela compte. Les utilisateurs sur site, les systèmes d'usine et le trafic interne à haut débit évitent un aller-retour inutile vers un point de présence dans le cloud, tandis que les utilisateurs distants bénéficient d'une protection directe vers le cloud sans passer par un réseau VPN.
Une stratégie de migration sans basculement forcé. Les entreprises peuvent moderniser leurs passerelles existantes, étendre leurs services au cloud et adopter le modèle « zero trust » à leur propre rythme, au lieu de transférer l'ensemble du trafic d'un seul coup.
Maîtrise des coûts à grande échelle. Il peut s'avérer plus économique de traiter localement des volumes de trafic interne très élevés plutôt que de tout acheminer via un service cloud facturé au volume, tandis que le trafic distant et SaaS bénéficie de l'élasticité du cloud.
Une protection homogène pour un personnel dispersé. Grâce à un moteur de politiques unique, les mêmes règles s'appliquent aux utilisateurs, qu'ils se trouvent au siège, en succursale ou à domicile.
Risques et défis liés à la sécurité du cloud hybride
Le cloud hybride est plus difficile à sécuriser qu'un environnement unique, car il multiplie les endroits où les mesures de contrôle doivent fonctionner de la même manière.
Le NIST décrit cette évolution fondamentale dans la publication SP 800-215, intitulée « Guide to a Secure Enterprise Network Landscape » (Guide pour un environnement réseau d'entreprise sécurisé). Il identifie trois conséquences en matière de sécurité liées à l'accès multi-cloud, à la dispersion géographique des centres de données et des succursales, ainsi qu'aux applications distribuées : la disparition du périmètre réseau traditionnel, l'élargissement de la surface d'attaque à chaque nouveau composant de calcul, de réseau et de stockage, et la multiplication des moyens dont disposent les attaquants pour franchir les frontières du réseau.
Les données relatives aux violations de données reflètent la même tendance. Le rapport 2025 d’IBM intitulé « Le coût d’une violation de données » a révélé que 30 % des violations concernaient des données réparties sur plusieurs environnements (cloud public, cloud privé et sur site). Ces violations constituaient la catégorie la plus coûteuse, avec un coût moyen de 5,05 millions de dollars, et c’est celle qui a nécessité le plus de temps pour être identifiée et maîtrisée, soit 276 jours. Les violations de données stockées uniquement sur site ont coûté en moyenne 4,01 millions de dollars. Le rapport 2026 d’IBM estime le coût moyen mondial d’une violation à un montant record de 4,99 millions de dollars, ce chiffre étant inférieur à celui des violations multi-environnements mentionné ci-dessus, car il couvre tous les types de violations et non pas uniquement la catégorie la plus coûteuse.
Les risques de sécurité les plus courants liés au cloud hybride sont les suivants :
- Manque de cohérence dans la politique. Un même utilisateur ou type de données est traité d'une manière par un proxy sur site et d'une autre par un service cloud, et cette divergence passe inaperçue jusqu'à ce qu'un audit ou un incident survienne.
- Manques de visibilité. Les journaux, les alertes et les inventaires de données sont dispersés dans différents outils, ce qui fait que personne ne détecte une attaque qui touche plusieurs environnements.
- Prolifération des identités. Les annuaires, les comptes de service, les clés API et, désormais, les agents IA s'accumulent plus rapidement que les contrôles d'accès, et chaque environnement peut disposer de son propre silo d'identités.
- Mauvaise configuration. Les services cloud dotés de paramètres par défaut trop permissifs, de modifications non vérifiées et de modèles de prestation variés créent des vulnérabilités auxquelles les contrôles sur site ne sont jamais confrontés.
- Responsabilité mal définie. Les équipes partent du principe qu’un prestataire s’occupe d’une tâche qui incombe en réalité au client.
- Prolifération des données. Les données sensibles sont copiées d'un environnement à l'autre, vers des solutions SaaS et vers des outils d'IA à un rythme que la classification et la gouvernance ne parviennent pas à suivre.
- Risque de concentration et de disponibilité. Si la mise en œuvre de la sécurité dépend entièrement d'un seul service externe, toute interruption de ce dernier entraîne l'arrêt des activités ou la suppression de la protection.
L'Agence nationale de sécurité américaine (NSA) considère la complexité des environnements hybrides comme un problème à part entière. Son document intitulé « Les dix principales stratégies d'atténuation des risques liés à la sécurité du cloud », publié en collaboration avec la CISA en mars 2024, comprend une stratégie spécifique dédiée aux complexités engendrées par les environnements hybrides et multicloud, aux côtés de la gestion des identités, de la gestion des clés, de la segmentation, de la sécurité des données et de la journalisation.
Responsabilité partagée dans un parc immobilier hybride
Dans un environnement hybride, l'organisation gère simultanément plusieurs modèles de responsabilité partagée, mais la protection des identités et des données relève toujours de sa propre responsabilité.
Les recommandations de la NSA concernant le modèle de responsabilité partagée soulignent que les clients partent souvent du principe que le fournisseur prend en charge certains aspects de la sécurité qui relèvent en réalité de leur propre responsabilité, et que les erreurs de configuration et l'absence de contrôles constituent toujours des risques importants liés au cloud.
| Couche | Sur site | IaaS | SaaS |
|---|---|---|---|
| Installations physiques et matériel informatique | Client | Prestataire | Prestataire |
| Réseau et hyperviseur | Client | Prestataire | Prestataire |
| Système d'exploitation et environnement d'exécution | Client | Client | Prestataire |
| Configuration de l'application | Client | Client | Partagé |
| Politique d'identité et d'accès | Client | Client | Client |
| Classification et protection des données | Client | Client | Client |
Deux éléments restent immuables : l'identité et les données. Une architecture de sécurité hybride doit s'articuler autour de ces deux constantes.
Quel est le niveau de sécurité d'une architecture cloud hybride ?
Une architecture cloud hybride peut être aussi sécurisée qu'une architecture à environnement unique, et plus résiliente, lorsque la gestion des identités, les politiques, la protection des données et la visibilité sont harmonisées entre tous les environnements.
Ce qui rend les environnements hybrides risqués, c’est le manque d’uniformité : des politiques, des outils et des équipes différents pour chaque environnement. Les données d’IBM relatives aux violations de sécurité montrent le coût de ce manque d’uniformité : les violations touchant plusieurs environnements sont plus coûteuses et durent plus longtemps que celles qui ne concernent que les infrastructures sur site. Les organisations qui unifient ces couches éliminent la majeure partie du risque supplémentaire et acquièrent la capacité de maintenir localement les mesures de sécurité essentielles en cas de défaillance d’un service externe.
Architecture de sécurité du cloud hybride : les couches de contrôle
Une architecture de sécurité dans le cloud hybride s'articule idéalement autour de six couches de contrôle qui s'appliquent à tous les environnements, en accord avec les piliers du modèle de maturité « Zero Trust » de la CISA.
1. Identité et accès. Un fournisseur d’identité de référence, une authentification multifactorielle (MFA) résistante au phishing et un accès conditionnel en fonction de l’utilisateur, de l’appareil, de la localisation et du niveau de risque. Cela inclut les identités non humaines : comptes de service, identités de charges de travail, jetons API et agents d’IA agissant avec des droits d’accès au niveau de l’utilisateur.
2. Appareils. L'état des appareils (gérés ou non, mis à jour, protégés) devrait influencer les décisions d'accès partout, et pas seulement pour les utilisateurs à distance.
3. Réseau et trafic. Segmentation, inspection par un groupe de filtrage de sécurité ( secure web gateway , SWG) du trafic à destination d’Internet, accès zéro confiance ( zero trust network access , ZTNA) pour les applications privées, et contrôles par pare-feu entre les segments. Cette couche détermine également où le trafic TLS est déchiffré et inspecté.
4. Applications et charges de travail. Configurations renforcées, gestion de la posture de sécurité des infrastructures cloud, sécurité des API et gestion des vulnérabilités couvrant à la fois les serveurs des centres de données et les instances cloud.
5. Données. Identification et classification (y compris la gestion de la sécurité des données, ou DSPM), prévention des fuites de données ( data loss prevention , DLP) sur le Web, les solutions SaaS, les applications privées, les terminaux et les outils d'IA, chiffrement et gestion des clés.
6. Visibilité et opérations. Journalisation centralisée, analyse comportementale, réponse automatisée et « policy-as-code » afin que les modifications soient gérées par versions et cohérentes.

Pour obtenir une vue schématique des composants, des flux de trafic, des périmètres de contrôle et des exemples de déploiement, veuillez consulter l'architecture de référence en matière de sécurité du cloud hybride.
Plan de contrôle et plan de données
Le principe fondamental de l'architecture hybride consiste à centraliser les décisions relatives aux politiques et à répartir leur mise en œuvre là où le trafic circule effectivement.
Le guide du NIST sur le modèle « zero trust », la norme SP 800-207, distingue le point de décision de politique (PDP), qui détermine si un sujet peut accéder à une ressource, du point d'application de la politique (PEP), qui se situe sur le chemin du trafic et permet, surveille ou interrompt la connexion.
Cette séparation est la clé de la conception hybride. Les décisions doivent être centralisées afin qu’un ensemble unique de règles s’applique partout. La mise en œuvre doit quant à elle être décentralisée, de sorte que l’inspection s’effectue au niveau d’un point de présence dans le cloud pour un utilisateur distant accédant à un service SaaS, au niveau d’une passerelle de succursale pour un utilisateur en bureau, et au sein du centre de données pour le trafic interne qui ne passe jamais par Internet.
Lorsque la prise de décision et l'application sont regroupées dans des produits distincts selon l'environnement, les organisations gèrent deux ou trois ensembles de politiques. Ces ensembles finissent par diverger, et cette divergence peut donner lieu à une constatation d'audit ou constituer une voie d'accès aux données. Voir « Politiques de sécurité cohérentes entre le cloud et les infrastructures sur site ».
Décisions de déploiement : mise en œuvre dans le cloud, sur site ou en mode hybride
Il n'existe pas d'emplacement unique idéal pour les contrôles de sécurité ; la réponse appropriée dépend du trafic et des données, et doit être déterminée en fonction de chaque charge de travail, site ou groupe d'utilisateurs.
| Facteur | Privilégie la mise en œuvre via le cloud | Privilégie une mise en œuvre sur site ou locale |
|---|---|---|
| Localisation de l'utilisateur | Utilisateurs à distance et mobiles | Les utilisateurs dans les bureaux, les usines et les centres de données |
| Destination | SaaS et Internet | Demandes internes et privées |
| Sensibilité à la latence | Compatible avec un changement de cloud | Trafic en temps réel, à haut débit ou OT |
| Souveraineté des données | Les régions prestataires satisfont aux critères de résidence ; la souveraineté dépend en outre de l'identité de l'exploitant de l'infrastructure | Les charges utiles, les clés ou les journaux doivent rester sur le territoire d'une juridiction ou dans un établissement |
| Résilience | Le contrat de niveau de service (SLA) du prestataire est acceptable | Les opérations doivent se poursuivre en cas de panne du cloud ou du réseau étendu (WAN) |
| Coût unitaire en fonction du volume | Volume d'inspection modéré | Un volume de trafic interne très élevé |
| Systèmes hérités et OT | Peu de dépendances héritées | Protocoles hérités ou réseaux exploités localement ; veuillez vérifier la prise en charge du fonctionnement hors ligne |
La plupart des entreprises optent pour une solution mixte. La question architecturale consiste alors à déterminer si les mesures de sécurité dans le cloud et sur site partagent un même moteur de politiques ou fonctionnent comme des piles parallèles. Voir « Passerelles Web sécurisées : cloud ou sur site » et « Déploiement d'une SSE privée ».
Le placement de l'inspection TLS mérite une attention particulière. Les recommandations de la NSA concernant la gestion des risques liés à l'inspection TLS préconisent de déchiffrer le trafic une seule fois, au sein du réseau d'entreprise, et d'éviter toute inspection redondante par des proxys en chaîne. Dans les architectures hybrides, cela implique de déterminer de manière réfléchie où le déchiffrement doit avoir lieu pour chaque chemin de trafic. Voir « Inspection TLS locale ou dans le cloud ».

Protection des données dans le cloud et sur site
La protection des données dans un environnement hybride repose sur la classification des données, effectuée une seule fois, et sur l'application de cette classification à chaque point de sortie des données.
- Identifiez les données. Repérez les données sensibles stockées dans le cloud, les solutions SaaS, les bases de données et les partages de fichiers, et veillez à ce que cet inventaire soit toujours à jour.
- Effectuez une seule classification. Utilisez un seul schéma de classification afin qu'un document confidentiel soit traité de la même manière, qu'il soit mis en ligne sur le Web, partagé via un service SaaS, collé dans une invite d'IA générative ou copié sur une clé USB.
- Appliquez cette politique sur l'ensemble des canaux pris en charge. Appliquez une politique DLP commune à l'ensemble des canaux pris en charge (Web, cloud, applications privées, terminaux et IA), et documentez toutes les intégrations spécifiques à chaque canal. Consultez la section « DLP dans les environnements cloud et sur site ».
- Établissez un lien entre la politique et sa mise en œuvre. Utilisez les résultats du DSPM pour déterminer quels référentiels et ensembles de données nécessitent les contrôles les plus stricts. Consultez la section « Comment le DSPM et le SSE fonctionnent ensemble ».
- Contrôlez le lieu de traitement des données. Déterminez où s'effectue le contrôle, quelles données quittent l'environnement, où les journaux sont stockés et qui peut accéder au contenu déchiffré.

Le rôle de SSE dans la sécurité du cloud hybride
Security Service Edge sécurise l'accès des utilisateurs au Web, aux applications SaaS et aux applications privées ; dans une architecture hybride, elle peut assurer cette sécurité aussi bien dans le cloud que sur site.
Gartner définit la «security service edge » (SSE) comme la sécurisation de l'accès au Web, aux services cloud et aux applications privées, grâce à des fonctionnalités comprenant notamment le contrôle d'accès, la protection contre les menaces, la sécurité des données et la surveillance de la sécurité. Gartner décrit la SSE comme une solution principalement fournie dans le cloud, tout en précisant qu'elle peut inclure des composants sur site ou basés sur des agents.
La SSE regroupe généralement les technologies SWG, CASB ( cloud access security broker ), ZTNA, DLP et RBI ( remote browser isolation ). Elle intervient au niveau de la couche utilisateur-application d’une architecture hybride. Elle ne remplace pas la gestion de la posture des charges de travail, la protection des terminaux ni la gouvernance des identités.
Les premiers déploiements de SSE partaient du principe que l’ensemble du trafic passerait par le cloud d’un fournisseur. Cela convient bien aux utilisateurs distants et aux solutions SaaS, mais pose des problèmes pour les données réglementées, le trafic interne, les opérations sensibles à la latence et les organisations qui doivent continuer à fonctionner en cas de panne du cloud. L’analyse du marché SSE à l’horizon 2026 réalisée par Gartner souligne que les fournisseurs proposent de plus en plus d’appareils virtuels ou matériels qui étendent le plan de données SSE sur site afin d’assurer le traitement du trafic local et la résilience face aux interruptions de service du cloud, comme l’indique l’annonce d’Skyhigh Securityconcernant les résultats de son rapport « Critical Capabilities » pour 2026.
Il s'agit d'une solution SSE hybride : des points de présence dans le cloud et une mise en œuvre sur site ou en succursale fonctionnant sous un seul moteur de politiques et une seule console. Skyhigh Hybrid SSE Mesh est la mise en œuvre de ce modèle par Skyhigh Security, avec un plan de données sur site pour l'inspection TLS locale et le ZTNA, complétée par des fonctionnalités CASB, DSPM, DLP et RBI dans le cloud.
Solutions de sécurité pour le cloud hybride
Les solutions de sécurité pour le cloud hybride se répartissent en plusieurs catégories, et la plupart des entreprises ont besoin de plusieurs d'entre elles.
| Catégorie | Ce qu'elle protège | Sa place dans l'architecture |
|---|---|---|
| Plateformes SSE et SASE | Accès des utilisateurs aux applications Web, SaaS et privées | Couches réseau et données ; points de contrôle |
| Sécurité des données (DSPM, DLP, chiffrement) | Données sensibles au repos et en transit | Couche de données |
| Protection des applications natives du cloud (CNAPP) | Charges de travail dans le cloud et configuration de l'infrastructure | Couche des applications et des charges de travail |
| Sécurité des réseaux | Trafic entre les zones, les sites et les segments | Couche réseau |
| Sécurité de l'identité | Utilisateurs, appareils, comptes de service et agents | Couche d'identité |
| Opérations de sécurité (SIEM, analyse) | Détection et réaction dans tous les environnements | Couche de visibilité et d'exploitation |
Lorsque vous comparez des fournisseurs de solutions de sécurité pour le cloud hybride, la question la plus importante est de savoir si l'application des règles sur site et dans le cloud repose sur un même moteur de règles ou s'il s'agit de produits distincts regroupés sous une même marque. Évaluez la flexibilité de déploiement, la protection des données, le contrôle des règles, l'intégration, la migration et la résilience, puis vérifiez la validité des affirmations dans le cadre d'une démonstration de faisabilité utilisant votre propre trafic. Consultez l'article « Solutions de sécurité pour le cloud hybride : comment comparer les fournisseurs ».
Considérations relatives à la conformité et à la réglementation
La plupart des cadres de conformité ne mentionnent pas directement le cloud hybride, mais chacun d'entre eux prévoit des contrôles qui s'appliquent de manière cohérente, quel que soit l'endroit où se trouvent les données réglementées et les utilisateurs.
| Cadre | Ce qu'elle attend d'une architecture hybride |
|---|---|
| Cadre de cybersécurité 2.0 du NIST | Gouvernance, visibilité des actifs, protection, détection, réaction et reprise, appliquées à tous les environnements |
| NIST SP 800-53, révision 5 | Les familles de contrôles, telles que le contrôle d'accès, la protection des périmètres, l'audit et la gestion de la configuration, mises en œuvre à chaque point d'application |
| ISO/IEC 27001:2022 | Un système de gestion de la sécurité de l'information dont le champ d'application couvre les services cloud et les actifs sur site, avec des responsabilités clairement définies pour les fournisseurs |
| PCI DSS v4.0.1 | Segmentation des environnements de données des titulaires de cartes, cryptographie forte lors du transfert de données et journalisation, y compris les exigences obligatoires à compter du 31 mars 2025 |
| Règle de sécurité HIPAA | Mesures de sécurité administratives, physiques et techniques visant à protéger les informations de santé électroniques, quel que soit leur lieu de stockage ou de transmission |
| GDPR | Traitement licite et transferts contrôlés des données à caractère personnel, y compris celles figurant dans les journaux de sécurité et les rapports d'inspection |
| DORA | Gestion des risques liés aux TIC, tests de résilience et gestion des risques liés aux tiers pour les entités financières de l'UE, applicables à compter du 17 janvier 2025 |
Il en découle deux implications pratiques. Premièrement, les auditeurs vérifieront si les contrôles sont cohérents d’un environnement à l’autre, ce qui est plus facile à démontrer lorsqu’on dispose d’un seul moteur de politiques et d’un seul pipeline de journaux. Deuxièmement, les outils de sécurité traitent eux-mêmes des données réglementées ; par conséquent, leur emplacement d’inspection, leurs journaux et l’accès des fournisseurs relèvent du champ d’application. Veuillez consulter la cartographie des contrôles dans l’architecture de référence pour la sécurité du cloud hybride.
Meilleures pratiques en matière de sécurité du cloud hybride
Les bonnes pratiques présentées ci-dessous permettent de transformer l'architecture en un programme opérationnel.
- Faites le point avant de vous lancer. Recensez les utilisateurs, les appareils, les applications, les référentiels de données et les chemins de trafic dans tous les environnements, y compris le SaaS et l'informatique parallèle.
- Consignez la répartition des responsabilités. Pour chaque service, précisez ce qui relève de la responsabilité du fournisseur et ce qui relève de celle de votre équipe. Réexaminez cette répartition lorsque les services changent de niveau.
- Faites de l'identité le principal levier de contrôle. Regroupez les fournisseurs d'identité, imposez une authentification multifactorielle (MFA) résistante au phishing et soumettez les comptes de service, les identités des charges de travail et les agents d'IA à la même gouvernance que celle applicable aux personnes.
- Centralisez la gestion des politiques, décentralisez leur application. Définissez les règles une seule fois et diffusez-les vers tous les points d'application, aussi bien dans le cloud que sur site.
- Supprimez la confiance implicite au niveau du réseau. Remplacez l'accès VPN général par un accès ZTNA par application, y compris pour les utilisateurs sur site, et segmentez les réseaux internes. Consultez la section « ZTNA sur site pour les applications privées ».
- Classez les données une seule fois et appliquez cette classification partout. Un seul schéma de classification, un seul ensemble de règles DLP, appliqués à la fois au Web, aux solutions SaaS, aux applications privées, aux outils d'IA et aux terminaux.
- Mettez en place l'inspection TLS de manière réfléchie. Procédez à un seul déchiffrement, aussi près que possible de la source du trafic, et consignez les exceptions pour les catégories sensibles en matière de confidentialité.
- Prévoyez les défaillances. Déterminez ce qu'il advient de l'accès et de l'inspection en cas d'indisponibilité d'un service cloud, d'une liaison WAN ou d'un fournisseur d'identité, puis testez ces scénarios.
- Centralisez la visibilité sans pour autant négliger la question de la localisation. Regroupez les journaux à des fins de détection, mais déterminez quels journaux peuvent quitter quelle juridiction.
- Surveillez en permanence les écarts. Traitez la politique de sécurité et la configuration du cloud comme du code, gérez-en les versions et signalez les divergences entre l'état prévu et l'état déployé.
- Modernisez les passerelles existantes de manière réfléchie. Remplacez les proxys en fin de vie en recourant à un déploiement parallèle et à une transition progressive, plutôt qu’à une migration radicale. Consultez la page « Migration deSecure Web Gateway ». Les clients utilisant Symantec Edge SWG (Blue Coat ProxySG) doivent respecter la date butoir de décembre 2026 pour la version SGOS 7.3 ; consultez les pages « Blue Coat » et « Fin de vie de ProxySG », « Alternatives àBlue Coat » ainsi que le programme de modernisation «Blue Coat ».
Sources
- Flexera. Rapport 2026 sur l'état du cloud. https://info.flexera.com/CM-REPORT-State-of-the-Cloud
- 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
- NIST. SP 800-207 : Architecture « Zero Trust » (août 2020). https://csrc.nist.gov/pubs/sp/800/207/final
- CISA. Modèle de maturité « Zero Trust », version 2.0. https://www.cisa.gov/zero-trust-maturity-model
- NSA et CISA. Les dix principales stratégies de prévention en matière de sécurité du cloud (7 mars 2024). https://www.nsa.gov/Press-Room/Press-Releases-Statements/Press-Release-View/Article/3699169/nsa-releases-top-ten-cloud-security-mitigation-strategies/
- 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
- IBM et l'Institut Ponemon. Rapport sur le coût d'une violation de données 2025. https://www-api.ibm.com/adobe/assets/urn:aaid:aem:607b9590-38e0-4c91-b433-aa8a17f5b5e8/original/as/cost-of-a-data-breach-2025-full-report.pdf
- IBM et Ponemon Institute. Rapport sur le coût d'une fuite de données 2026. https://www.ibm.com/reports/data-breach
- Gartner. « Security Service Edge » (SSE), Glossaire des technologies de l'information. https://www.gartner.com/en/information-technology/glossary/security-service-edge-sse
- Skyhigh Security. «Skyhigh Security classé n° 1 dans la catégorie « Cas d’utilisation avancés du SSE » dans le rapport Gartner de 2026 intitulé « Critical Capabilities for Security Service Edge» (5 août 2026). https://www.globenewswire.com/news-release/2026/08/05/3339504/0/en/skyhigh-security-ranked-1-in-advanced-sse-use-case-in-2026-gartner-critical-capabilities-for-security-service-edge.html
- NIST. Cadre de cybersécurité 2.0. https://www.nist.gov/cyberframework
- 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
- ISO. ISO/IEC 27001:2022 Systèmes de gestion de la sécurité de l'information. https://www.iso.org/standard/27001
- Conseil des normes de sécurité PCI. PCI DSS v4.0.1 (bibliothèque de documents). https://www.pcisecuritystandards.org/document_library/
- 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
- Union européenne. Règlement (UE) 2016/679 (RGPD). https://eur-lex.europa.eu/eli/reg/2016/679/oj
- Union européenne. Règlement (UE) n° 2022/2554 (DORA). https://eur-lex.europa.eu/eli/reg/2022/2554/oj