Azure Landing Zone Review
Ce que coûte une exception
Une landing zone est conçue une fois, puis étendue en production, et c'est précisément là que commence sa véritable histoire. Le premier projet soumis à une deadline serrée obtient sa subscription hors hiérarchie, parce que le policy review aurait duré plus longtemps que le sprint. Le prestataire bloqué un vendredi après-midi avec des droits Contributor se voit accorder Owner sur la Management Group et le conserve, parce qu'après le go-live, personne n'y repense. Et quand le pare-feu du hub bride le débit d'un spoke, ce spoke obtient son peering en direct, en contournant le hub. Chacune de ces décisions était sensée au moment où elle a été prise, et chacune est toujours en vigueur.
Les conséquences sont concrètes. Une subscription hors hiérarchie n'hérite d'aucune policy, donc aucune policy ne la protège. Un Owner au niveau de la Management Group se propage silencieusement à toutes les subscriptions situées en dessous, y compris celles qui n'existaient pas à l'époque. Un peering sans route vers le pare-feu est un chemin réseau que votre SOC ne voit pas. L'Azure Landing Zone Review superpose la conception initiale et l'état actuel selon les huit Design Areas du Cloud Adoption Framework, et classe les écarts par leurs conséquences, non par leur ancienneté.
Les huit Design Areas du Cloud Adoption Framework
Microsoft a structuré les décisions d'une landing zone en huit Design Areas, parce que la plupart des erreurs se cachent sinon dans les angles morts entre les équipes : l'équipe réseau construit le hub, l'équipe identity attribue les rôles, et celui qui a approuvé l'exception de policy n'apparaît dans aucun des deux journaux. Nous passons les huit en revue, chacune avec la même question : qu'est-ce qui était prévu, qu'est-ce qui a été construit, et que résulte-t-il de l'écart.
Azure Billing et Entra Tenant
Enrollment, hiérarchie de facturation et le tenant sur lequel tout repose. Un second tenant issu d'une acquisition pose rarement problème, jusqu'au moment où il faut consolider licences, identités et factures.
Identity et Access Management
Rôles au niveau plateforme, service principals et PIM. Un Owner sur la Root Management Group se propage silencieusement à toutes les subscriptions créées ultérieurement.
Resource Organization
Hiérarchie de Management Groups, conception des subscriptions, noms et tags. Les workloads placés dans la mauvaise Management Group héritent des mauvaises policies, et cela ne se remarque qu'au moment d'un audit.
Network Topology et Connectivity
Hub-and-spoke ou Virtual WAN, connectivité hybride, DNS, pare-feu, Private Endpoints. Un peering qui contourne le hub est techniquement correct et invisible pour le SOC.
Security
Defender for Cloud, chiffrement, Key Vaults et tout ce qui se trouve au niveau de la plateforme plutôt que dans le workload. Un plan Defender actif sur une partie des subscriptions protège exactement cette partie.
Management
Monitoring, logging, backup et recovery. Les Diagnostic Settings manquants ne se remarquent pas en exploitation, mais lors d'un incident, quand on a besoin des logs qui n'ont jamais été écrits.
Governance
Azure Policy, initiatives, exemptions et contrôle des coûts. Une exemption a une date d'expiration si quelqu'un en a défini une. La plupart n'en ont pas.
Platform Automation et DevOps
Infrastructure as Code, pipelines, Azure Verified Modules. Une plateforme modifiée via le portail a deux sources de vérité : le repository et Azure. C'est la seconde qui fait foi.
Comment ça se passe
- Interroger l'équipeInterroger l'équipeNous commençons par les personnes qui opèrent la plateforme, pas par l'outil : architecture, outillage, processus opérationnels, stratégie. La plupart des constats qu'un scan produit ensuite ont une histoire, et celui qui la connaît les évalue correctement. Une décision délibérée n'est pas la même chose qu'un arrangement oublié.
- Analyser l'environnementAnalyser l'environnementNous analysons ensuite l'environnement par outillage : Management Groups, policies et exemptions, attributions de rôles, chemins réseau, Diagnostic Settings, coûts. De façon automatisée, en regard de l'état actuel du Cloud Adoption Framework, pas de celui d'il y a trois ans.
- Classer les constatsClasser les constatsL'outil détecte l'écart, l'entretien l'explique, et ce n'est que la combinaison des deux qui donne une priorité. En tête figurent ce qui propage des droits ou empêche la collecte de logs, en bas, ce qui enfreint une convention de nommage. Un constat sans conséquence est une note, pas une tâche.
- Parcourir le rapport ensembleParcourir le rapport ensembleVous recevez le rapport avec le niveau de maturité par Design Area, les constats et les recommandations, et nous le parcourons ensemble. Non pas pour que vous connaissiez cent constats, mais pour que vous sachiez lundi par lequel commencer.
Un rapport avec un ordre de priorité
Vous recevez un rapport qui positionne votre landing zone selon les huit Design Areas : niveau de maturité par domaine, constats priorisés et recommandations qu'une équipe plateforme peut mettre en œuvre sans nous solliciter. S'y ajoute la distinction qu'aucun scanner ne fait : savoir si un écart par rapport au framework résulte d'une décision ou d'un oubli. Il s'adresse aux équipes plateforme et aux directions informatiques qui opèrent une landing zone depuis quelques années et veulent savoir ce qui a évolué depuis, tant dans l'environnement que dans le framework. Ceux qui s'apprêtent à migrer ont tout intérêt à vérifier les fondations avant de s'occuper du déménagement. Ceux qui ont repris la plateforme d'un prestataire ont besoin d'un regard extérieur, de quelqu'un qui n'a pas construit ce qu'il évalue. La mise en œuvre n'est pas incluse. Elle se déroule comme un projet à part entière, avec nous, avec un partenaire ou avec votre équipe.
Et ensuite
Ce qu'on nous demande en amont
Les questions issues des premiers échanges, avec les réponses que nous y donnons.
Faut-il avoir une landing zone de glueckkanja pour cela ?
Non. Nous analysons toute landing zone, qu'elle soit issue du template Enterprise Scale, d'un autre prestataire ou construite via le portail. La référence est le Cloud Adoption Framework, pas notre Azure Foundation. Que nous la recommandions si le rapport le justifie n'est pas une surprise, mais ce n'est pas non plus une condition.
Quelle est la différence entre le review et le Modul Azure der Preventive Services ?
La question posée. Le Modul Azure cherche comment un attaquant passe d'une subscription au plan de contrôle, et aboutit à une roadmap de durcissement. Le Landing Zone Review demande si la plateforme dans son ensemble est solide : organisation, réseau, governance, exploitation, automatisation, coûts. La security y est l'une des huit Design Areas. Ceux qui veulent les deux commencent par le review, car c'est lui qui fournit la carte sur laquelle le module trace les chemins.
De quels droits avez-vous besoin ?
En lecture seule. Pour l'analyse, un rôle Reader sur la Management Group racine suffit, complété par des droits de lecture sur Cost Management. Nous ne modifions rien, et les accès sont révoqués à l'issue du review. Le fait que le review puisse s'effectuer avec des droits Reader est déjà en soi un constat : une landing zone qui ne le permet pas a trouvé son premier sujet.
Analysez-vous aussi les coûts ?
Oui, parce que dans une landing zone, ils ont les mêmes causes que les constats de governance. Sans tags, une facture ne peut être attribuée à aucune équipe ; sans alertes budgétaires, une VM oubliée ne se remarque qu'en fin de mois ; et une réservation que personne ne gère paie de la capacité que personne n'utilise. Ce qui ressort de cet examen figure dans le rapport, chiffres à l'appui.
Combien de temps dure le review ?
L'entretien et l'analyse prennent quelques jours. De votre côté, cela représente un rendez-vous d'entretien, la mise à disposition des droits de lecture et la session de présentation du rapport. La partie la plus importante, c'est ce que vous faites ensuite avec la liste, et elle vous appartient.
La mise en œuvre est-elle incluse ?
Non, et c'est délibéré. Un review qui priorise ses propres missions de suivi n'en serait pas un. Vous recevez un ordre de priorité et des recommandations ; la mise en œuvre se déroule comme un projet distinct, avec nous, avec un partenaire ou avec votre équipe. Ceux qui souhaitent ensuite reconstruire la landing zone trouveront le chemin dans l'Azure Foundation.
