Quand une organisation migre vers Azure, sécuriser le premier environnement ne fait jamais vraiment de doute. Quelques abonnements se configurent soigneusement à la main, quelqu’un y consacre le temps nécessaire, et le résultat est bon.
Le risque se situe à la quinzième.
Un parc infonuagique croît par abonnement. Chaque nouvelle équipe, chaque nouveau projet, chaque preuve de concept qui survit plus longtemps que prévu en ajoute un. Et les contrôles appliqués manuellement se dégradent dès que le rythme de provisionnement dépasse la capacité des personnes qui les appliquent — ce qui arrive plus vite qu’on ne le croit.
La zone d’atterrissage est l’endroit où l’on décide, une fois, de ce dont hérite chaque environnement futur.
Une structure qui reflète la gouvernance réelle
Avant les politiques, la hiérarchie.
Les groupes d’administration et les abonnements doivent refléter la manière dont l’organisation gouverne réellement — qui répond de quoi, quelles unités ont des exigences distinctes, où passent les frontières budgétaires et réglementaires. Une politique appliquée au bon niveau atteint exactement les environnements visés ; appliquée à une structure qui ne correspond à rien, elle produit soit des exceptions permanentes, soit des contournements.
C’est l’étape la moins technique et la plus déterminante. Elle exige des conversations avec des gens qui ne travaillent pas en TI.
Des garde-fous exprimés sous forme de code
Azure Policy est le mécanisme par lequel un abonnement hérite de sa posture au lieu de la recevoir manuellement. Les contrôles qui reviennent systématiquement :
Restrictions régionales — pour beaucoup d’organisations québécoises, notamment dans le secteur public, la localisation des données n’est pas une préférence. La politique est le seul moyen fiable de garantir qu’un abonnement créé un vendredi soir ne déploie pas ailleurs.
Limitation des SKU — autant une mesure de coût qu’une mesure de sécurité, mais elle évite aussi les configurations exotiques que personne ne sait auditer.
Étiquetage obligatoire — sans propriétaire ni classification, une ressource devient orpheline, et une ressource orpheline n’est corrigée par personne.
Conformité aux référentiels — NIST SP 800-53 et, pour les organismes soumis au cadre fédéral, PBMM.
L’essentiel est que ces contrôles soient définis dans le code source et révisés comme tout autre changement. Une politique configurée une fois dans le portail diverge silencieusement ; une politique versionnée se relit, se discute et s’applique uniformément.
Une topologie qui sépare par conception
Une architecture Hub & Spoke place chaque charge de travail dans son propre spoke, le trafic inter-zones transitant par le hub. La segmentation devient une propriété de l’architecture plutôt qu’une règle de pare-feu ajoutée après coup par quelqu’un qui réagissait à un incident.
L’avantage pratique se révèle au moment d’ajouter le vingtième spoke : la question « ce nouvel environnement peut-il joindre celui-là ? » possède déjà une réponse structurelle, et personne n’a besoin de l’inventer sous pression.
Supprimer les privilèges permanents
C’est le contrôle qui rencontre le plus de résistance et qui change le plus de choses.
Un RBAC au moindre privilège limite ce qu’une personne peut faire. Le Privileged Identity Management ajoute la dimension qui compte réellement : quand. Les rôles privilégiés sont accordés en juste-à-temps, pour une durée déterminée, avec une justification — plutôt qu’attachés en permanence à un compte parce que la personne en a eu besoin une fois, en 2023.
Attendez-vous à des objections. La réponse honnête est que l’élévation juste-à-temps ajoute quelques secondes à une opération privilégiée, et supprime une catégorie entière de risque : le compte administrateur dormant que personne ne surveille et que personne ne se rappelle avoir créé.
Savoir ce que vous portez
Deux chantiers accompagnent la zone d’atterrissage et sont systématiquement reportés :
Un registre de risques infonuagiques fondé sur le Cloud Adoption Framework, couvrant conformité, sécurité, coûts, opérations, données et IA. L’intérêt n’est pas le document — c’est que le risque devienne une liste suivie avec des responsables, plutôt qu’une mémoire institutionnelle qui part avec les gens.
Une sauvegarde qui survit à l’incident : chiffrement, rétention à long terme, géo-redondance et immuabilité. Une sauvegarde accessible et modifiable depuis le compte compromis n’est pas une sauvegarde — c’est une copie.
Le changement de sens de la marche
L’effet concret est un renversement.
Auparavant, chaque nouvel abonnement partait d’un état inconnu et était ramené vers la conformité — si quelqu’un y pensait, et si le temps le permettait. Il démarre désormais à l’intérieur d’une structure qui porte déjà les contrôles.
Le travail passe de la remédiation au traitement des exceptions. C’est une tâche bien plus réduite, et surtout bien plus tenable pour l’équipe qui devra la maintenir pendant des années.
Besoin d’aide pour mettre cela en œuvre ?
Nous travaillons avec votre équipe pour concevoir, construire et exploiter les contrôles décrits ci-dessus.