Dans le chapitre précédent, vous avez réussi une étape cruciale : verrouiller la porte d'entrée de votre système d'information en faisant de l'Identité votre nouveau périmètre de défense (via un IdP central, le MFA et l'accès conditionnel). Votre direction vous fait désormais confiance, mais le chantier ne fait que commencer.
Votre SI au sein de cette ETI de 500 collaborateurs est fortement hétérogène. Au quotidien, les données de votre entreprise transitent entre de vieux serveurs internes (On-premise), des environnements Cloud modernes gérés par vos développeurs (Azure), et une multitude d'applications SaaS achetées directement par les directions métiers. L'analyse EBIOS RM est formelle : le risque d'accès SaaS non maîtrisé et de fuite de données est critique.
Dans ce chapitre, nous allons adapter vos exigences de sécurité générales à la réalité technique, hétérogène et hybride de vos infrastructures.
Votre système d'information historique, hébergé dans vos propres locaux (On-premise), constitue le socle de votre dette technique.
Bien que vous ayez acté la fin du modèle périmétrique, ces serveurs existent toujours physiquement et nécessitent une protection rigoureuse pour éviter qu'une simple compromission ne se transforme en un mouvement latéral dévastateur, l'un des risques majeurs de votre analyse de risques.

En tant que RSSI, vous devez collaborer avec les équipes réseau, architecture et exploitation pour imposer une micro-segmentation de votre réseau local (via des VLAN et des zones démilitarisées, ou DMZ). L'objectif est de créer des compartiments étanches : si un attaquant compromet le poste d'un collaborateur, il ne doit avoir aucune route réseau directe vers vos serveurs de production.
Concernant le contrôle des accès administratifs, travaillez avec les équipes systèmes pour imposer des bastions (PAM - Privileged Access Management). Comme le rappelle l'ANSSI dans ses recommandations sur les SI hybrides, l'administration doit se faire depuis un réseau dédié, via des serveurs de rebond, afin de rompre la session et d'enregistrer toutes les actions effectuées par les administrateurs sur les environnements hérités.

Enfin, clarifiez systématiquement les interlocuteurs. L'alignement et la gouvernance sont la clé de la réussite. Formalisez les responsabilités via le RACI pour chaque mesure de sécurité afin d'assurer une mise en œuvre cohérente, suivie et auditable.
Le Cloud public offre une flexibilité immense, mais il expose également vos ressources à des attaques exploitant de mauvaises configurations de votre Cloud. Les infrastructures en tant que service (IaaS), telles que les machines virtuelles hébergées sur Azure, exigent une posture de sécurité stricte, car la sécurisation de l'OS et du réseau virtuel relève de votre responsabilité.
En tant que RSSI, travaillez avec les équipes Cloud et DevOps pour interdire cette exposition publique. Imposez des accès sécurisés via des bastions (comme Azure Bastion), des VPN ou, idéalement, des solutions d'accès réseau Zero Trust (ZTNA). Le RACI ici positionne la Sécurité en (R) et les équipes IT/Cloud en (A).
Concernant le filtrage réseau, collaborez avec les architectes Cloud pour définir des Network Security Groups (NSG) stricts.
Enfin, vous devez contrôler les flux entre votre SI historique et vous SI Cloud. Imposez un routage contrôlé et inspecté (à l'aide de pare-feu de nouvelle génération ou de proxys) pour tous les flux transitant entre votre espace Cloud et votre réseau interne On-premise. Assurez-vous que cette gouvernance soit formalisée pour que chaque équipe (réseau, cloud, métiers) comprenne son rôle dans la prévention des mouvements latéraux, notamment par une matrice de flux interenvironnements claire, permettant aux équipes réseaux et Cloud de partager une vision commune de la segmentation, évitant ainsi que le Cloud ne devienne une porte dérobée vers votre cœur de réseau.
Les services PaaS (Platform as a Service), comme les bases de données managées (Azure SQL) ou les services de stockage (Azure Blob Storage), vous déchargent de la gestion du système d'exploitation. Cependant, vous restez entièrement responsable de la configuration réseau, du code déployé et de la protection des données.
La première urgence est l'isolation du PaaS. Par défaut, de nombreux services PaaS disposent d'un point de terminaison public accessible depuis Internet, ce qui constitue un risque de fuite de données majeur. Collaborez avec les équipes Cloud et DevOps pour imposer l'usage de Private Endpoints (points de terminaison privés).
Parallèlement, travaillez avec les architectes pour imposer le chiffrement systématique des données, qu'elles soient au repos (stockées) ou en transit. Prescrivez une gestion rigoureuse des secrets et des clés de chiffrement via des coffres-forts numériques dédiés (comme Azure Key Vault). Ne tolérez plus aucun mot de passe inscrit en clair dans les codes sources.
Mais comment s'assurer que le code déployé sur ces plateformes n'introduit pas de failles de sécurité ?
C'est là qu'intervient la sécurité des déploiements CI/CD (Intégration et Déploiement Continus). Exigez des équipes DevOps une validation systématique du code avant son exécution. Cela inclut des revues de code (par ex. peer review), des scans de vulnérabilités (par ex. SAST/DAST) et des contrôles de conformité automatisés au sein même des pipelines de déploiement. Sur ce point, le RACI identifie clairement les DevOps et l'IT comme garants (A) de l'intégration de ces outils, tandis que la Sécurité (R) en définit les seuils d'exigence.
Dans le modèle SaaS (Software as a Service), le fournisseur gère l'infrastructure, l'application et la plateforme. Votre zone de responsabilité se réduit, mais elle se concentre sur les éléments les plus critiques : les données et les identités. Comme souligné par l'analyse de risques EBIOS RM, l'accès SaaS non maîtrisé est l'une de vos trois menaces prioritaires.
Pour reprendre le contrôle, votre posture de RSSI doit être intransigeante sur l'intégration des identités. Travaillez avec les équipes IAM (Identity and Access Management) et les responsables métiers pour imposer l'intégration systématique de tout nouveau logiciel SaaS à votre Fournisseur d'Identité (IdP) central (celui que vous avez mis en place au chapitre précédent). Cela permet de bénéficier du Single Sign-On (SSO) et de forcer l'usage du MFA robuste pour l'ensemble du parc logiciel. Si un SaaS n'est pas compatible avec votre IdP, il ne doit pas être déployé. (RACI : Sécurité en R, IT/IAM en A).
Dans un modèle SaaS, le rôle du RSSI évolue : il ne s’agit plus uniquement de déployer des mesures techniques en interne, mais de garantir un niveau de sécurité cohérent sur l’ensemble du système d’information, y compris chez les fournisseurs externes. Cela implique de travailler étroitement avec les équipes achats et juridiques afin d’intégrer des exigences de sécurité dans les contrats et les engagements de service.
Dans ce contexte, les mesures techniques deviennent en grande partie des mesures contractuelles : exigences de conformité, garanties de sécurité, capacités de supervision, réversibilité des données ou encore droit d’audit permettant de vérifier le niveau réel de sécurité du fournisseur.
Il est également essentiel de s’assurer que les solutions SaaS retenues permettent l’export des journaux d’audit et d’activité vers les outils de supervision de l’entreprise, afin de conserver une visibilité centralisée sur les événements de sécurité du SI. Cette exigence s’inscrit pleinement dans l’approche Zero Trust — Never Trust, Always Verify — qui reste tout aussi pertinente dans les environnements Cloud, où chaque action et chaque accès doivent pouvoir être vérifiés et tracés en continu.
Enfin, assurez le pilotage global du risque SaaS avec les équipes de conformité. Organisez des revues régulières pour vérifier que les fournisseurs maintiennent leurs certifications (ISO 27001, SecNumCloud, etc.) et qu'ils respectent les règles de localisation de vos données stratégiques. Identifiez clairement les rôles (Achats, Juridique, IT, Métiers) pour assurer une traçabilité parfaite des contrats en cours.
Même avec des contrats validés et un SSO configuré, il reste un angle mort majeur dans votre SI hybride : le Shadow IT. Vos collaborateurs, par souci de rapidité, utilisent voire souscrivent souvent à des services Cloud gratuits (partage de fichiers, conversion de PDF, IA générative) sans en informer la DSI, exposant ainsi l'entreprise à des fuites de données invisibles.
Pour contrer ce phénomène, vous devez prescrire l'usage d'un CASB (Cloud Access Security Broker). En collaborant avec les équipes IT et métiers, imposez la cartographie et l'audit en continu des applications Cloud non autorisées afin d'obtenir une visibilité exhaustive sur la réalité des usages. (RACI : Sécurité en R, IT en A).
Une fois la visibilité obtenue, travaillez avec les équipes sécurité pour déployer des politiques de blocage et des politiques de prévention des fuites de données (DLP - Data Loss Prevention). Par exemple, le CASB peut vous permettre de bloquer les systèmes de partage de fichiers non officiels..
Enfin, imposez des mécanismes de détection automatisée des comportements à risque, connus sous le nom d'UEBA (User and Entity Behavior Analytics). Implémentable au niveau de votre CASB et/ou de votre IdP, l'UEBA modélise le comportement normal d'un utilisateur et détecte les anomalies instantanément : connexions géographiquement impossibles, exfiltration massive de fichiers ou suppressions suspectes. Assurez-vous que l'équipe du SOC (Security Operations Center) soit intégrée dans le RACI (en A) pour traiter ces alertes de façon opérationnelle.

Votre stratégie porte ses fruits. Pour accélérer la digitalisation de l'entreprise, l'équipe d'infrastructure et les directions métiers déploient simultanément deux nouveaux projets :
Une application de gestion de production spécifique, qui pour des raisons matérielles, doit être déployée sur un vieux serveur On-premise.
Un nouvel outil de gestion de la relation client (CRM) hébergé 100% en SaaS par un éditeur américain.
Ces deux environnements impliquent des responsabilités différentes entre votre organisation et le fournisseur Cloud. Face à cette double livraison, le DSI vous demande de formaliser les exigences de sécurité à intégrer avant la mise en production.
Pour chacun de ces deux environnements (On-premise et SaaS), identifiez une exigence de sécurité Zero Trust incontournable. Pour chaque exigence, précisez :
La preuve de vérification attendue (comment auditer concrètement que l'exigence est respectée).
La répartition des rôles selon un modèle RACI simplifié (Responsable de l'exigence / Accountable de la mise en œuvre technique).
Le risque de mouvement latéral impose une microsegmentation stricte des réseaux et l'utilisation de bastions pour sécuriser les accès à la dette technique.
L'exposition directe sur Internet doit être bannie au profit de Network Security Groups (NSG) restrictifs et de flux hybrides étroitement inspectés.
La surface d'attaque est réduite en isolant les flux via des Private Endpoints et en imposant le chiffrement via des gestionnaires de clés (Key Vaults).
L'identité devient le seul périmètre contrôlable ; l'intégration au Fournisseur d'Identité (IdP) central pour le SSO et le MFA est donc une obligation absolue.
La maîtrise du Shadow IT et la prévention des fuites de données s'obtiennent par le déploiement d'un CASB, appuyé par une clarification systématique des responsabilités (RACI) pour chaque modèle de service.
Maintenant que vous êtes capable de décliner vos exigences de sécurité Zero Trust à travers chaque modèle de service de votre système d'information hybride, votre prochaine étape consistera à défendre ces choix stratégiques auprès de votre direction et à planifier leur déploiement. C’est ce que nous allons voir dans le dernier chapitre de ce cours.