Gouvernance Azure : ce que l'inventaire a révélé après l'évaluation

Refaire l'inventaire avant de gouverner

Un manufacturier nous a confié la gouvernance de son environnement Azure. Une évaluation datait de quelques mois. Elle donnait un portrait global et une liste de recommandations. Avant de bâtir le cadre, on a repris l'inventaire ressource par ressource. Sur plusieurs points, la réalité racontait autre chose.

D'autres constats se sont confirmés : une gouvernance à documenter au complet, des étiquettes appliquées de façon inégale et plus d'une trentaine d'espaces de supervision séparés.

Ce que l'évaluation annonçait, ce que l'inventaire a trouvé

Ces écarts ont changé l'ordre des priorités :

• Stockage : l'évaluation annonçait zéro accès anonyme. L'inventaire a trouvé plus d'une quinzaine de comptes de stockage ouverts en accès anonyme, et presque tous ouverts à tous les réseaux.
• Adressage réseau : l'évaluation annonçait zéro conflit. L'inventaire a relevé des dizaines de plages d'adresses qui se chevauchent.
• Économies : l'évaluation promettait 20 à 30 % de réduction. Le pourcentage viendra une fois la dépense de référence établie.
• Disponibilité : un service présenté comme absent du Canada est offert en région Canada Centre.

Des droits d'administrateur juste-à-temps

Le constat le plus sérieux touchait les accès. Tous les administrateurs gardaient leurs droits en continu, et la plupart des rôles Propriétaire étaient attribués sans condition. Un seul compte compromis donnait donc accès à tout, en tout temps.

Le modèle retenu repose sur l'accès juste-à-temps avec Privileged Identity Management (PIM) :

• Tous les rôles privilégiés deviennent admissibles et s'activent au besoin.
• Rôles critiques (Propriétaire, gestion des accès, gestion des politiques) : activation de 4 heures, avec approbation.
• Autres rôles : activation de 8 heures, sans approbation.
• À chaque activation : authentification multifacteur et justification.
• Au moins deux comptes d'urgence, protégés de préférence par une clé physique, pour garder la main en cas de panne.
• Transition groupe par groupe : chaque attribution est retirée une fois le groupe qui la remplace en place et testé.

L'audit avant le refus

Bloquer d'un coup les ressources non conformes peut arrêter une application en production. Le cadre prévoit donc un premier lot d'une douzaine de politiques Azure Policy, assigné en mode « ne pas appliquer ». Ce mode mesure la conformité et laisse tout fonctionner. Microsoft le recommande justement pour évaluer l'impact d'une politique avant de l'appliquer.

Le premier lot couvre les bases : régions autorisées, étiquettes obligatoires, journal d'activité centralisé, HTTPS et TLS récent, accès public aux bases SQL et identité gérée.

La séquence : assigner en mode audit, observer au moins 30 jours, traiter chaque exception par une exemption datée, puis passer en mode appliqué, une politique à la fois. L'assignation reste en place pendant toute la démarche.

Chaque exemption a une durée maximale. À l'échéance, elle reste au dossier et cesse de s'appliquer.

« L'audit avant le refus. »

- Architecte cloud Azure, io4

Région Canada et Loi 25

Des ressources tournaient aux États-Unis. La première politique du lot limite donc les déploiements aux régions canadiennes. Petite précision qui compte : Canada Centre est à Toronto, Canada Est à Québec. Une vague de la feuille de route est réservée au rapatriement des ressources hors Canada.

Héberger à Toronto reste possible. La Loi 25 demande alors une évaluation des facteurs relatifs à la vie privée avant de communiquer des renseignements personnels à l'extérieur du Québec. Le choix de région devient donc aussi une décision de conformité.

Ce qu'on retient pour toute organisation

• Refaire l'inventaire avant de bâtir un cadre de gouvernance, même quand une évaluation existe.
• Rendre les accès administrateurs juste-à-temps en premier : c'est le risque le plus large.
• Mettre les garde-fous en mode audit, observer, puis appliquer un par un.
• Établir la dépense de référence avant d'annoncer des économies.
• Traiter le choix de région Azure comme une question de Loi 25.