Santé, ~500 employés · Landing Zone cloud sécurisée

Sommaire

1. Business Problem
2. Requirements
3. Constraints & Risks
4. As-Is / To-Be
5. Reference Architecture
6. Architecture Decision Record
7. Business Case
8. Roadmap
9. Governance / Policies
10. Executive Summary

Grille d’entretien & pièges à éviter

MediSecure

Besoin : Landing Zone cloud sécurisée avant migration de données patients

Contexte

MediSecure gère des dossiers patients et des données de facturation santé. L’entreprise a commencé son adoption cloud de façon non structurée : plusieurs équipes ont créé leurs propres souscriptions Azure sans standard commun. La direction veut désormais poser une fondation cloud gouvernée avant de migrer des charges sensibles (données patients).

1. Business Problem

Pourquoi cette architecture existe

2. Requirements Exigences métier
Pouvoir démontrer la conformité à un auditeur externe à tout moment (traçabilité complète des accès aux données patients)

MediSecure doit héberger des données de santé sur Azure en respectant des obligations réglementaires (type RGPD / hébergement de données de santé), tout en évitant la prolifération de souscriptions non gouvernées (“shadow IT cloud”). Sans fondation commune, chaque nouvelle application recrée sa propre sécurité, avec un risque d’incohérence, d’audit impossible, et de non-conformité.

• Onboarder de nouvelles équipes/applications sans réinventer la sécurité à chaque fois
• Ne pas ralentir excessivement les équipes déjà matures sur le cloud

Exigences techniques

• Chiffrement au repos et en transit sur toute donnée patient, sans exception
• Aucune ressource de données accessible depuis une IP publique
• Journalisation immuable, centralisée, non désactivable par les équipes applicatives Exigences de sécurité / conformité
• Séparation des environnements par niveau de criticité (données patients vs applications internes non sensibles)
• Accès aux rôles à privilèges limité dans le temps (JIT — Just-In-Time)

3. Constraints & Risks

Contraintes

• Existant : ~15 souscriptions Azure déjà créées de façon disparate par différentes équipes, impossible de tout arrêter et repartir de zéro
• Budget de la phase de fondation limité (pas de reconstruction complète immédiate de l’existant)
• Équipe cloud interne réduite (2 personnes), pas de capacité à opérer une gouvernance très complexe au quotidien

Risques identifiés

• Risque réglementaire : amende ou interdiction d’exploitation en cas de fuite de données patients
• Risque opérationnel : blocage des équipes si la gouvernance est trop rigide dès le départ (rejet interne du projet)
• Risque de dérive : sans automatisation (Policy), la gouvernance décidée sur le papier n’est jamais appliquée dans la durée

4. As-Is / To-Be

As-Is (état actuel)

• ~15 souscriptions Azure créées sans convention commune, ownership flou
• Pas de Management Groups, pas d’Azure Policy transverse
• Accès aux ressources attribués individuellement (pas de groupes), pas de PIM
• Certaines bases de données accessibles avec IP publique (héritage d’anciens projets pilotes)
• Aucune centralisation des logs — chaque équipe gère (ou pas) sa propre supervision

To-Be (état cible)

• Structure de Management Groups par criticité (Platform / Landing Zones confidentiel / Landing Zones standard / Sandbox)
• Azure Policy en mode Deny sur les contrôles critiques (chiffrement, régions, IP publiques interdites sur les données)
• RBAC par groupes Entra ID + PIM pour les rôles à privilèges

Log Analytics centralisé, non modifiable par les équipes applicatives

• Defender for Cloud actif à l’échelle du Management Group Gaps identifiés
• Absence totale de gouvernance transverse aujourd’hui → nécessité d’une migration progressive des souscriptions existantes vers la nouvelle structure, sans interrompre les applications en production

5. Reference Architecture — Secure Cloud Landing Zone Architecture proposée

• Management Groups hiérarchisés : Root → Platform (identité, gestion, connectivité) / Landing Zones (par criticité : confidentiel, standard) / Sandbox (expérimentation, isolée)
• Souscriptions dédiées : une souscription “Identity”, une “Connectivity” (hub réseau), une ou plusieurs souscriptions “Workload” par domaine applicatif
• Azure Policy appliqué au niveau Management Group : chiffrement obligatoire, régions autorisées, tags obligatoires, interdiction des IP publiques sur les ressources de données
• Identité : RBAC basé sur des groupes Entra ID (pas d’attribution individuelle), Privileged Identity Management (PIM) pour les rôles à privilèges
• Réseau : Private Endpoints obligatoires pour tout service PaaS manipulant des données patients
• Logging : Log Analytics centralisé dans la souscription “Platform”, non modifiable par les équipes applicatives (garantie d’intégrité pour l’audit)

Security Controls

Comment le risque est réduit

• Séparation stricte identité / connectivité / workloads (principe de moindre privilège au niveau souscription)
• Azure Policy en mode “Deny” (pas seulement “Audit”) pour les contrôles critiques (chiffrement, régions)
• Diagnostic settings forcés par policy vers le Log Analytics central — aucune équipe ne peut désactiver le logging
• Azure Defender for Cloud activé au niveau Management Group

Cost & Tradeoffs

Quels choix ont été arbitrés

• Tradeoff principal : gouvernance centralisée (Platform team) vs autonomie des équipes applicatives

— MediSecure choisit la gouvernance centralisée car le risque réglementaire prime sur la vitesse

• Une souscription “Connectivity” dédiée ajoute un coût fixe (Azure Firewall, ExpressRoute/VPN Gateway) même à faible échelle — justifié ici par l’exigence de traçabilité réseau en environnement de santé
• Alternative écartée : une gouvernance “légère” par simple convention de nommage sans Azure Policy contraignant — rejetée car non auditable et non opposable en cas de contrôle

Use / Do Not Use

•        À utiliser : toute organisation qui va héberger des données réglementées ou sensibles, avec plusieurs équipes/applications à onboarder dans la durée

À ne pas utiliser tel quel : une startup avec une seule application et une équipe unique — la charge de gouvernance (Management Groups, Policy, souscriptions séparées) serait disproportionnée ; une version allégée (une souscription, Policy en mode Audit) suffit à ce stade

Ce que cet artefact prouve

Tu sais concevoir une fondation cloud gouvernée en anticipant la croissance et la conformité, pas seulement sécuriser une application isolée.

Diagramme d’architecture

Landing Zone — Hiérarchie des Management Groups

6. Architecture Decision Record — “Migration progressive vs Big Bang de la gouvernance”

Contexte métier : 15 souscriptions existantes doivent rejoindre la nouvelle structure de gouvernance sans interrompre les applications en production.

Options considérées

1. Big Bang : rattacher toutes les souscriptions aux Management Groups et activer les Policy en mode Deny en une seule fois
2. Migration progressive : rattacher les souscriptions aux Management Groups, activer les Policy en mode Audit d’abord, puis basculer en Deny souscription par souscription selon la criticité
3. Statu quo temporaire : ne gouverner que les nouvelles souscriptions, laisser l’existant tel quel

Option	Avantages	Inconvénients
Big Bang	Conformité atteinte rapidement	Risque élevé de casser des applications en prod ; rejet probable des équipes
Migration progressive	Risque maîtrisé, adoption facilitée	Délai plus long avant conformité complète
Statu quo	Aucun risque de rupture immédiat	Ne résout jamais le risque réglementaire sur l’existant — inacceptable pour des données patients

Pros & Cons

Risques & impact coût : la migration progressive nécessite un suivi manuel temporaire (tableau de bord de conformité par souscription) — effort humain mais pas de coût Azure additionnel significatif.

Recommandation finale : Migration progressive, priorisée par criticité (souscriptions contenant des données patients traitées en premier). Le statu quo est écarté car incompatible avec l’exigence réglementaire ; le Big Bang est écarté car le risque opérationnel (interruption de service) dépasse le bénéfice du temps gagné.

7. Business Case — Cloud Migration / Mise en conformité

Problème métier : absence de gouvernance cloud commune exposant MediSecure à un risque réglementaire sur des données de santé.

Coût de l’inaction : risque de sanction réglementaire, risque réputationnel (perte de confiance des établissements de santé partenaires), risque de blocage d’un futur audit ou d’une certification nécessaire pour signer de nouveaux contrats.

Investissement recommandé : mise en place de la Landing Zone (Management Groups, Policy, PIM, Log Analytics centralisé) + effort de migration progressive des souscriptions existantes sur 2 trimestres.

Bénéfices attendus : conformité démontrable à tout moment, réduction du temps d’onboarding des nouvelles applications (fondation déjà prête), réduction de la surface d’attaque (suppression des IP publiques sur les données).

Impact business : condition nécessaire pour signer des contrats avec de nouveaux établissements de santé exigeant une preuve de conformité en amont.

8. Roadmap

• Phase 1 (M1-M2) : mise en place des Management Groups, Azure Policy en mode Audit, Log Analytics centralisé, PIM pour les comptes à privilèges
• Phase 2 (M2-M4) : migration des souscriptions contenant des données patients (priorité haute), bascule Policy Audit → Deny sur ce périmètre
• Phase 3 (M4-M6) : migration des souscriptions restantes (applications internes non sensibles)
• Phase 4 (M6+) : durcissement continu (revue trimestrielle des exceptions de policy, extension du modèle aux nouvelles acquisitions/filiales)

9. Governance / Policies

• Identity and Access Management Policy : accès par groupes Entra ID uniquement, PIM obligatoire pour tout rôle Owner/Contributor sur les souscriptions Landing Zone confidentiel
• Encryption Standard : chiffrement au repos obligatoire (Customer Managed Keys sur les souscriptions données patients), TLS 1.2+ en transit
• Cloud Tagging Policy : tag data-classification obligatoire sur toute ressource (patientdata, internal, public), utilisé à la fois pour la gouvernance et le FinOps
• Architecture Review Procedure : toute nouvelle application doit passer une revue avant d’obtenir sa souscription Landing Zone, vérifiant conformité aux standards ci-dessus

10. Executive Summary

MediSecure doit sécuriser l’hébergement de ses données patients sur Azure et démontrer sa conformité réglementaire, alors que son adoption cloud actuelle est fragmentée entre 15 souscriptions sans gouvernance commune. Ce projet met en place une Landing Zone structurée (Management Groups, Azure Policy, identité centralisée, logging immuable) et migre progressivement l’existant sur 6 mois, en priorisant les charges les plus sensibles. Le résultat : une conformité démontrable à tout moment, une réduction du risque de fuite de données, et une fondation réutilisable pour accélérer l’onboarding des futures applications — condition désormais nécessaire pour signer de nouveaux contrats avec des établissements de santé partenaires.

Question posée	Ce qu’on évalue	Angle de réponse
“Pourquoi des souscriptions séparées plutôt qu’une seule avec des resource groups ?”	Compréhension des limites d’isolation Azure	Isolation de facturation, limites de quotas par souscription, blast radius en cas de compromission, granularité RBAC au niveau souscription
“Que se passe-t-il si une équipe a besoin d’une exception à une Azure Policy ?”	Gestion de la gouvernance dans le réel, pas en théorie	Processus d’exception documenté (Architecture Review), policy exemption temporaire tracée et review à date
“Comment gères-tu la transition d’une entreprise qui a déjà 50 souscriptions non gouvernées vers ce modèle ?”	Capacité à gérer une migration, pas seulement un design greenfield	Approche progressive : inventaire, rattachement aux Management Groups sans bloquer l’existant, Policy en mode Audit avant Deny, priorisation par criticité
“Pourquoi PIM plutôt que RBAC standard pour les admins ?”	Profondeur technique sur l’identité	Accès juste-à-temps, réduction de la fenêtre d’exposition des comptes à privilèges, exigé par les référentiels d’audit
“Quel est le coût de cette architecture pour une petite structure ?”	Sens du pragmatisme / antisurdimensionnement	Reconnaître le tradeoff : Azure Firewall + Gateway ont un coût fixe non négligeable ; proposer une version allégée pour un contexte moins critique
“Pourquoi ne pas avoir fait un Big Bang pour aller plus vite en conformité ?”	Capacité à équilibrer risque opérationnel vs risque réglementaire	Le risque d’interrompre des applications en production dépasse le bénéfice du temps gagné ; la conformité progressive priorisée par criticité reste défendable devant un auditeur
“Comment tu justifies cet investissement auprès d’un CFO qui ne voit pas le risque réglementaire concrètement ?”	Capacité à traduire un risque technique en langage business	Relier au coût de l’inaction (sanction, perte de contrats, réputation) plutôt qu’à la technique ; chiffrer si possible le coût d’un incident comparable

🎯 Grille d’entretien — questions probables sur ce scénario

“Que fais-tu si une équipe applicative refuse la migration

Gestion du changement, pas seulement design

dans le secteur Impliquer l’équipe en amont via l’Architecture Review, prioriser

⚠️ Pièges à éviter en entretien

• Ne pas réciter la liste des Management Groups sans être capable d’expliquer pourquoi cette hiérarchie précise plutôt qu’une autre
• Ne pas présenter la gouvernance comme statique — un recruteur cherchera à tester si tu sais gérer une exception ou une évolution

Question posée	Ce qu’on évalue	Angle de réponse
vers la nouvelle gouvernance ?”		par criticité réelle plutôt que d’imposer un calendrier uniforme, escalader si le refus persiste sur un périmètre à risque réglementaire

Éviter de dire “c’est la best practice Microsoft” comme seule justification — toujours relier au contexte métier (ici : santé + réglementation)

• Ne pas traiter l’ADR comme un simple choix technique : toujours revenir au risque métier

(interruption de service vs conformité) qui a motivé la décision

• Ne pas oublier de savoir chiffrer, même grossièrement, le “coût de l’inaction” du Business Case — un chiffre approximatif mais justifié vaut mieux qu’un silence