Sept failles de sécurité Azure que les organisations négligent souvent

Les revues de sécurité d’environnements Microsoft produisent de longs rapports. Retirez le bruit, et les mêmes sept constats concentrent l’essentiel du risque réel — dans des tenants de cinquante utilisateurs comme dans des tenants de cinquante mille.

Aucun n’exige un attaquant sophistiqué. La plupart correspondent à l’état par défaut d’un tenant configuré rapidement, puis qui a grandi.

1. Des rôles privilégiés qui n’expirent jamais

Quelqu’un est administrateur général en permanence. En général plusieurs personnes : celle qui a créé le tenant, le prestataire qui a migré les boîtes aux lettres, un consultant d’il y a deux ans.

Le privilège permanent est le constat le plus grave, parce qu’il transforme tout hameçonnage réussi de l’un de ces comptes en prise de contrôle totale du tenant. Privileged Identity Management existe précisément pour rendre les rôles élevés temporaires et soumis à approbation : une personne devient administrateur pour deux heures, avec un motif consigné, et cesse de l’être ensuite.

L’oubli associé concerne le compte de secours. Chaque tenant en a besoin d’un, exclu des accès conditionnels pour fonctionner quand tout le reste est en panne. Bien moins de tenants déclenchent une alerte lorsqu’il se connecte. Un compte d’urgence utilisable en silence n’est pas un compte d’urgence : c’est une porte dérobée au nom sympathique.

2. Des accès conditionnels troués

La plupart des tenants ont des politiques d’accès conditionnel. La plupart de ces politiques ne couvrent pas tout ce qu’on leur suppose.

Trois lacunes reviennent. L’authentification héritée — des protocoles incapables de MFA — reste autorisée, si bien qu’un mot de passe seul suffit pour tout ce qui est assez ancien pour les utiliser. Les groupes d’exclusion créés pour un déploiement sont devenus permanents sans bruit, et se sont élargis à ceux qui se sont simplement plaints. Et les identités de charge de travail — principaux de service et identités managées — échappent entièrement aux politiques utilisateurs, ce qui ne pose aucun problème jusqu’au jour où l’une d’elles détient un secret qui fuit.

Le jeu de politiques n’est pas le contrôle. La couverture l’est. Rendez compte de ce qui n’est pas couvert, plutôt que de ce qui l’est.

3. Des applications plus autorisées que prévu

Deux variantes se présentent ensemble.

Les utilisateurs peuvent consentir à des applications tierces. Dans beaucoup de tenants, la valeur par défaut permet encore à n’importe quel utilisateur d’accorder à une application externe l’accès à sa messagerie, ses fichiers et son profil — ce qui est exactement le mécanisme de l’hameçonnage par consentement : aucun mot de passe volé, juste une permission accordée.

Pendant ce temps, les inscriptions d’applications de l’organisation accumulent des permissions applicatives — celles qui agissent en tant que l’application sur les données de tous les utilisateurs, et non au nom de la personne connectée. Elles ont été accordées en développement parce que les permissions déléguées étaient plus difficiles à faire fonctionner. Personne n’y est revenu.

Transformez le consentement utilisateur en processus d’approbation administrateur, et passez chaque permission applicative au filtre d’une question : doit-elle lire les données de tout le monde, ou seulement celles de l’utilisateur courant ?

4. Des secrets là où il faudrait des identités

Des chaînes de connexion dans les paramètres d’application. Une clé de compte de stockage dans une variable de pipeline. Un secret client de principal de service partagé entre quatre systèmes, fixé à l’expiration maximale, sans que personne sache exactement où il est utilisé.

Azure a passé des années à rendre cela inutile. Les identités managées donnent à une charge de travail une identité propre, sans secret à stocker, à renouveler ou à perdre. Key Vault conserve ce qui doit réellement rester un secret, avec un accès contrôlé par identité et chaque lecture journalisée.

Le problème n’est pas que les équipes l’ignorent. C’est que l’approche par secrets fonctionnait dès le premier jour, tandis que l’approche par identité exigeait une décision de conception. Deux ans plus tard, les secrets sont partout et l’inventaire de leurs emplacements est incomplet — ce qui constitue le véritable constat.

5. Un stockage plus public qu’on ne le croyait

Les comptes de stockage sont là où vivent les données, et leurs valeurs par défaut ont été conçues pour la commodité.

Accès anonyme aux blobs autorisé au niveau du compte, si bien qu’un seul conteneur mal configuré expose son contenu à Internet. Authentification par clé partagée activée, si bien que quiconque détient la clé contourne tous les contrôles d’identité. Accès réseau public autorisé, sans point de terminaison privé, si bien que le compte de stockage possède une adresse routable et que seule une clé le sépare du monde.

Chaque réglage a une valeur sûre. Désactivez l’accès anonyme, désactivez la clé partagée, exigez des points de terminaison privés — et imposez les trois par Azure Policy au niveau du groupe d’administration, pour que le prochain compte de stockage naisse conforme plutôt que d’être découvert plus tard.

6. Des journaux qui ne vont nulle part

C’est la faille qui transforme un incident d’un mauvais après-midi en mauvais trimestre.

Les paramètres de diagnostic ne sont configurés sur la plupart des ressources, si bien que la plateforme n’enregistre pas ce qu’elles ont fait. Les journaux de connexion et d’audit Entra ID sont conservés trente jours par défaut, alors qu’une investigation doit presque toujours remonter plus loin. Les plans Defender for Cloud sont activés pour certains types de ressources et pas pour d’autres. Et lorsque des alertes se déclenchent, elles arrivent dans une boîte aux lettres que personne n’est chargé de lire.

Le remède n’a rien de spectaculaire : acheminer les journaux Entra ID et d’activité Azure vers un espace Log Analytics doté d’une rétention significative, activer les plans Defender par politique plutôt qu’à la main, et — c’est l’étape que les organisations sautent — attribuer à chaque catégorie d’alerte un responsable nommé et un runbook de réponse. Une détection sur laquelle personne n’agit n’est qu’une ligne de journal.

7. Des accès accordés et jamais repris

Des comptes invités créés pour un projet il y a trois ans, toujours actifs. Des appartenances à des groupes qui reflètent d’anciens postes. Le rôle Propriétaire d’une souscription attribué à un individu plutôt qu’à un groupe — et cet individu est parti.

Rien ici n’est une erreur de configuration. Chacune de ces décisions était correcte au moment où elle a été prise. La faille tient à l’absence de cycle de vie : des revues d’accès qui obligent quelqu’un à reconfirmer que l’invité a toujours besoin d’accéder, une gestion des droits qui donne par défaut une date d’expiration à chaque accès, et une routine qui supprime ce qui n’a pas été reconfirmé.

Un accès sans expiration est un passif qui se compose en silence.

Le motif sous-jacent

Relisez les sept et observez ce qu’ils ont en commun. Aucun n’est un produit manquant. Chaque capacité mentionnée — PIM, accès conditionnel, consentement administrateur, identités managées, Key Vault, Azure Policy, Defender, Sentinel, revues d’accès — figure déjà dans la plateforme Microsoft que la plupart de ces organisations paient.

Ce qui manque, c’est la responsabilité. Quelqu’un doit décider que le privilège permanent n’est pas acceptable, que c’est la couverture qui est rapportée, que chaque alerte porte un nom, que l’accès expire par défaut. Ce sont des décisions, et elles se prennent en un après-midi.

Une revue en lecture seule du tenant fait apparaître les sept en quelques jours, sans rien modifier. Décider lesquels corriger en premier est alors une courte conversation — nettement plus courte que celle qui suit un incident.