Si tu cherches « réduire le blast radius d’un SaaS admin », tu es au bon endroit. On parle des outils qui ont des boutons dangereux : MDM (Intune), IdP/SSO, console cloud, CI/CD, EDR… Le scénario qui fait mal n’a rien d’exotique : des identifiants admin compromis, et ton outil “d’admin” devient une arme. Wipe des machines, lock des comptes, suppression de configs, rotation de clés, coupure d’accès. Rideau.
Je vais partir d’un cas autour de Microsoft Intune rapporté par Obsidian Security, et élargir au pattern. Le but n’est pas de te faire peur, c’est de te donner une façon praticable de modéliser le risque et de mettre des garde-fous qui tiennent en prod, avec des arbitrages réalistes.
Intune et le « kill switch » : quand l’admin IT devient une action destructrice à grande échelle
Un MDM comme Intune, c’est très puissant. Et c’est justement le problème. Ce n’est pas “un outil pour pousser des policies” : c’est aussi la capacité de retirer l’accès (Conditional Access, conformité), de révoquer, de réinitialiser, et dans certains cas d’effacer des devices. Donc quand un attaquant obtient des droits suffisants, il ne cherche pas forcément à rester discret. Il peut viser la disruption, vite, large, sale.
Ce que ce type d’incident met en lumière, c’est un angle qu’on sous-modélise côté dev/ops : on fait des threat models sur l’app, sur l’infra, sur la supply chain… mais on oublie souvent le SaaS d’admin comme composant critique. Pourtant, dans la vraie vie, il peut couper l’accès à la prod aussi sûrement qu’un rm -rf sur un cluster.
Sponsorisé par Le Scribouillard
Besoin de contenu optimisé SEO ?
Utilisez la meilleure plateforme française de création de contenu assistée par IA ! Et générez des articles pour moins de 1€ !
Le pattern commun : ce n’est pas un 0-day, c’est « des droits + des identifiants »
Le fantasme, c’est l’attaquant qui casse une crypto, trouve une vuln 0-day, escalade un kernel. La réalité la plus fréquente, surtout sur les SaaS, c’est plus bête : phishing, token volé, OAuth app douteuse, session hijack, mot de passe réutilisé, device compromis… et derrière, les permissions font le reste.
Une console d’admin, c’est un multiplicateur de dégâts. Si tes rôles sont trop larges, si tes comptes “pratiques” sont aussi des comptes à privilèges, si ton SSO est le seul point d’entrée sans filet, tu as créé un système où la compromission d’un seul compte peut devenir un incident entreprise.
Modéliser ton blast radius : la question n’est pas « peut-on être compromis ? », c’est « qu’est-ce qu’ils peuvent casser ? »
Je vois souvent des boîtes “bien” côté sécurité applicative, mais qui n’ont jamais écrit noir sur blanc la phrase suivante : « si ce compte est compromis, voilà ce que l’attaquant peut éteindre en 10 minutes ». Tant que tu ne fais pas cet exercice, tu navigues à l’instinct. Et l’instinct adore les raccourcis.
Concrètement, tu veux cartographier tes SaaS “à pouvoir destructeur” (MDM, IdP, CI, registry, observabilité, cloud provider, gestionnaire de secrets, support client si tu peux reset des emails…). Et pour chacun, tu identifies les actions irréversibles ou très coûteuses : wipe/retire, suppression de policies, rotation forcée de clés, désactivation d’un domaine, suppression de tenants/projets, modification de règles d’accès, suppression de logs, désactivation de MFA, création d’admins, etc.
Ce n’est pas un document de gouvernance à faire dormir. C’est une carte des boutons rouges. Une fois que tu l’as, tu peux enfin faire de l’ingénierie : réduire la portée, mettre des freins, créer du délai, améliorer la détection, préparer la restauration.
Least privilege qui marche en vrai : arrêter les rôles « fourre-tout » et les comptes “miroir de prod”
Le moindre privilège, tout le monde sait le réciter. Le faire, c’est une autre histoire, surtout dans les SaaS d’admin où les rôles sont parfois trop larges ou mal compris. Mon retour terrain : tant que tu n’as pas eu un incident ou un audit douloureux, tu as tendance à garder des rôles “comfort” parce que ça évite les tickets. Sauf que ce confort, tu le payes le jour où ça part.
Le levier le plus rentable, c’est de découper les identités. Un compte “normal” pour la vie quotidienne (mail, docs, chats), et un compte séparé pour l’admin. Pas pour faire joli : pour que le phishing du quotidien ne te donne pas les clés de la maison. Et quand tu dois administrer, tu montes en privilège de façon consciente, temporaire si possible (PIM/JIT), avec un signal dans les logs.
Autre point qui change tout : séparer les environnements quand c’est possible. Je sais, certains SaaS sont “one tenant to rule them all”. Mais là où tu peux avoir un staging, un tenant de test, un bac à sable, fais-le. Beaucoup d’erreurs destructrices ne sont pas malveillantes. Elles sont humaines. Et elles arrivent à 18h47 le vendredi.
Break-glass hors SSO : sinon ton IdP devient ton single point of failure
On adore centraliser via SSO, et c’est souvent une bonne décision. Mais si ton IdP est indisponible, mal configuré, ou compromis, et que tout passe par lui, tu peux te retrouver enfermé dehors au pire moment. Les comptes de secours (break-glass) servent à ça : garder une porte d’entrée indépendante pour reprendre la main.
Ce qui compte, ce n’est pas d’avoir “un compte break-glass dans un wiki”. Ce qui compte, c’est qu’il soit hors du flux habituel, très peu utilisé, très surveillé, protégé par une MFA résistante au phishing, avec des identifiants stockés dans un coffre et un rituel d’accès clair. Et surtout : tu testes. Le jour où tu en as besoin, tu n’as pas envie de découvrir que la policy l’a bloqué aussi.
MFA résistante au phishing : le mot de passe ne doit plus être une clé maître
Un SaaS d’admin avec MFA “app + code”, c’est mieux que rien. Mais face à du phishing bien fait et des attaques de session (token), ça ne suffit pas toujours. Sur les comptes à privilèges, je suis assez tranché : vise du phishing-resistant dès que tu peux. Passkeys, FIDO2/YubiKey, Conditional Access qui exige un device compliant, limitations par localisation, restrictions sur les navigateurs non gérés… L’idée n’est pas de rendre la vie impossible, c’est de rendre la compromission “à distance, en une fois” beaucoup moins probable.
Et oui, ça veut dire traiter les comptes d’admin comme des comptes d’admin. Pas comme le compte mail du quotidien qui traîne sur un laptop perso, sur un Wi-Fi d’hôtel, avec quinze extensions de navigateur.
Audit logs exploitables : si tu ne lis pas les logs, tu n’as pas de détection
Beaucoup d’équipes ont “des logs” parce que le SaaS en propose. Mais si personne ne les collecte, ne les normalise, et ne les alerte, ce sont juste des écrans de plus. Sur les SaaS d’admin, ce que tu veux détecter, ce n’est pas “un login suspect” uniquement. C’est surtout les actions destructrices et les changements de contrôle : création d’admins, modification des policies de sécurité, changements de règles de conformité, désactivation d’un mécanisme de MFA, suppression de policies, actions de wipe/retire, etc.
Un bon réflexe est de définir quelques signaux “impossibles à ignorer”. Exemple simple : une action de wipe sur plus de X devices en Y minutes, ou une modification de policy de conformité suivie d’un pic de devices non conformes, ou une création de nouvel admin en dehors des horaires habituels. Ce ne sont pas des preuves, ce sont des déclencheurs d’enquête. L’objectif est d’acheter du temps avant que l’attaquant ne termine le job.
// Exemple (à adapter) : détecter des actions destructrices Intune/Entra
// Idée : alerter sur des vagues d'actions de wipe/retire et sur la création d'admins.
AuditLogs
| where TimeGenerated > ago(1h)
| where OperationName has_any ("Wipe", "Retire", "Delete", "Add member to role")
| summarize count() by OperationName, bin(TimeGenerated, 5m), InitiatedBy
| where count_ > 3Ce bloc n’est pas là pour être copié-collé tel quel. Il est là pour te rappeler un truc : si tu n’as pas de requête d’alerte sur tes “boutons rouges”, tu es en mode post-mortem par défaut.
Change management : mettre du frottement là où c’est dangereux (et pas ailleurs)
Le piège classique, c’est de mettre des process partout, et de finir avec des équipes qui contournent. Ce que je préfère, c’est une approche ciblée : du frottement sur les actions irréversibles, et de la fluidité sur le reste.
Dans certains outils, tu peux exiger une approbation, du “four-eyes”, ou un groupe dédié pour exécuter des actions à impact. Quand ce n’est pas possible nativement, tu peux quand même créer du contrôle via l’organisation : actions destructrices réservées à un petit nombre de comptes, utilisation via un bastion, obligation de ticket, et surtout un réflexe d’annonce dans un canal visible. Ça n’arrêtera pas un attaquant déjà admin, mais ça réduit beaucoup les dégâts des erreurs humaines, et ça augmente les chances qu’un comportement anormal soit vu vite.
Backups et export de configuration : ton SaaS doit être restaurable, pas juste “configuré”
On parle souvent de backup de données. Mais dans un incident SaaS admin, ce qui part en fumée peut être la configuration : policies, groupes, assignments, règles d’accès, settings de conformité, apps enregistrées, certificats, intégrations. Et restaurer “à la main” sous stress, c’est comme refaire une infra sans Terraform en pleine panne : tu vas oublier un truc. Et tu ne sauras pas lequel.
Tu veux donc une stratégie d’export régulière des configurations critiques, versionnée, et idéalement diffable. Quand tu peux tout gérer en IaC (ou au moins en “configuration as code”), fais-le. Quand tu ne peux pas, fais au minimum des exports programmés, et documente ce qui n’est pas exportable. Le mot important ici, c’est rejouable. Pas “on a des screenshots”.
Le « recovery day » : répéter le scénario avant qu’il ne te tombe dessus
Les boîtes qui s’en sortent en incident ne sont pas magiquement meilleures. Elles ont répété. Un recovery day, c’est une journée où tu simules une perte d’accès à un SaaS critique, ou une action destructrice, et tu regardes ce qui casse : qui a accès à quoi, combien de temps pour reprendre la main, quelles dépendances inattendues (VPN, CA, certificats, tokens CI, accès aux consoles), et quelles actions sont impossibles faute d’un break-glass qui marche.
Si tu ne veux pas faire un exercice complet, fais au moins un test simple et utile : “nous perdons l’accès à notre IdP pendant 2 heures”. Qu’est-ce qui tombe, qui est bloqué, qui peut encore déployer, qui peut gérer les devices, comment on communique, et comment on récupère. Tu vas découvrir des surprises. C’est le but.
Erreurs fréquentes que je vois (et qui transforment un SaaS en bombe)
La plus courante, c’est le compte “super admin” utilisé au quotidien, parce que “c’est plus simple”. Le jour où il se fait phisher, tu as littéralement offert le kill switch. Juste derrière, il y a l’absence de séparation des rôles et l’absence de journaux exploités, ce combo est terrible : tu te fais compromettre, tu ne vois rien, et quand tu vois, c’est trop tard.
Autre mauvais arbitrage : croire que “le SSO = sécurité”. Le SSO, c’est de la centralisation. Bien fait, ça peut être très solide. Mal fait, c’est un point de défaillance unique. Sans break-glass, sans phishing-resistant MFA sur les comptes à privilèges, et sans politique conditionnelle sérieuse, tu as juste mis toutes tes clés sur le même porte-clés.
Mon avis : traite tes SaaS d’admin comme de la prod critique, pas comme des outils
Un SaaS d’admin, ce n’est pas “l’outil IT à côté”. C’est une brique d’architecture et de résilience. Tu dois pouvoir répondre, sans hésiter, à ces questions : qui peut faire quoi, comment on le détecte, et comment on récupère si ça tourne mal.
Tu n’auras jamais le risque zéro. Mais tu peux éviter le scénario humiliant où une compromission banale devient un arrêt de l’entreprise parce que personne n’avait modélisé le blast radius d’un bouton “wipe”.
