Le guide complet des permissions Microsoft Graph API pour la sécurité

L'automatisation de la réponse aux incidents (SOAR) repose sur un équilibre délicat : donner à un logiciel tiers la capacité d'agir sur votre infrastructure cloud pour bloquer les cyberattaques, tout en respectant scrupuleusement les principes d'une architecture de sécurité Zero Trust. Dans l'écosystème cloud de Microsoft, cette gouvernance des accès s'articule autour d'un pilier central : l'API Microsoft Graph.

Pour connecter un orchestrateur SOC de manière sécurisée, il est hors de question d'accorder des privilèges d'Administrateur Global permanents. Vous devez appliquer le principe du moindre privilège (Least Privilege) en sélectionnant des permissions granulaires. Voici le guide complet des permissions indispensables pour automatiser vos remédiations de sécurité en toute sérénité.

L'importance de la granularité face aux attaques de chaîne d'approvisionnement

Historiquement, pour interconnecter un outil de sécurité avec le cloud Azure ou Microsoft 365, les administrateurs créaient un compte de service doté du rôle Global Administrator. Cette pratique est une vulnérabilité majeure : si la plateforme de sécurité tierce est compromise, l'attaquant hérite des pleins pouvoirs sur votre tenant Microsoft.

L'intégration moderne (comme celle d'Akuity SOC) utilise des applications enregistrées dans Microsoft Entra ID avec des permissions d'API spécifiques (Application Permissions). Les droits d'accès sont définis de manière chirurgicale. L'outil ne peut exécuter que les appels API explicitement autorisés, rendant l'infrastructure résiliente face aux attaques sur la chaîne d'approvisionnement (Supply Chain Attacks).

Les 4 piliers des permissions Microsoft Graph pour le SOC

Pour couvrir l'intégralité du cycle de vie d'une remédiation cyber (gérer l'identité, isoler le terminal, assainir la messagerie), un orchestrateur SOAR s'appuie sur quatre catégories de permissions majeures :

1. La gestion de la posture de sécurité (Audit et Posture)

Avant d'agir, le SOC doit collecter les métriques de sécurité pour alimenter ses tableaux de bord décisionnels.

• Permission : SecurityEvents.Read.All
• Pourquoi ? : Elle permet à l'orchestrateur de se connecter au flux d'alertes unifié de Microsoft 365 Defender pour lire les métadonnées des incidents. C'est également cette permission qui permet de récupérer automatiquement le Microsoft Secure Score du locataire pour afficher les indicateurs de couleur (Vert, Orange, Rouge) au sein de la gestion des tenants.

2. Le contrôle et le confinement des Identités (Entra ID)

Face à un vol de jeton de session (Token Theft) ou à une attaque par force brute, le SOAR doit pouvoir verrouiller le compte utilisateur compromis.

• Permissions : User.ReadWrite.All ou Directory.ReadWrite.All
• Pourquoi ? : Ces droits indispensables permettent d'exécuter la commande critique revokeSignInSessions pour forcer la déconnexion immédiate de l'utilisateur sur tous ses terminaux. Ils autorisent également l'action resetUserPassword : générer un mot de passe temporaire robuste affiché de manière sécurisée dans un modal persistant et forcer sa modification lors de la prochaine connexion. Enfin, ils permettent de déclarer l'utilisateur comme compromis (confirmUserCompromised) dans Entra ID Protection pour déclencher l'Accès Conditionnel.

3. La remédiation sur les terminaux (Microsoft Intune)

En cas d'infection par un malware ou un ransomware, le SOAR doit agir au niveau du système de fichiers et du réseau de la machine.

• Permission : DeviceManagementManagedDevices.ReadWrite.All
• Pourquoi ? : Cette autorisation permet à la plateforme de lister les appareils (Windows, macOS, serveurs) gérés par Intune et Defender for Endpoint pour identifier les machines non conformes ou soumises à des menaces. C'est ce droit qui autorise l'envoi de la commande de confinement réseau d'urgence (isolateDevice) via l'appel /microsoft.graph.isolate, ainsi que le déclenchement à distance d'un Scan Antivirus rapide Windows Defender.

4. L'assainissement de la messagerie et le blocage réseau

Pour stopper la propagation des attaques par e-mail ou bloquer les infrastructures d'attaque externes (Command & Control).

• Permission : SecurityActions.ReadWrite.All
• Pourquoi ? : Indispensable pour mener la purge globale de mail (soft-delete) via l'endpoint /beta/security/remediations en ciblant le networkMessageId. Elle permet également d'interagir avec l'API native de Microsoft Defender for Endpoint (/api/indicators) pour injecter des indicateurs de blocage d'IOCs (IP, Domaines ou Hashs SHA256) avec une validité stricte de 90 jours pour protéger automatiquement tout votre parc.

Une sécurité renforcée au niveau matériel (PostgreSQL RLS)

Accorder ces permissions à un outil multi-tenant impose de garantir qu'aucun client ne puisse exécuter une commande sur le locataire d'un autre client.

Dans Akuity SOC, cette étanchéité absolue est assurée directement par le moteur de base de données PostgreSQL via le mécanisme Row-Level Security (RLS). Chaque tentative d'appel API est validée par des index de performance spécifiques (idxtenantsworkspace, idxprofilsworkspace), assurant qu'un analyste ne peut solliciter les permissions Microsoft Graph que pour le périmètre exact de son espace de travail, après avoir validé son identité par son code MFA (session AAL2).

Conclusion : L'automatisation en toute confiance

Le respect scrupuleux du principe du moindre privilège via les permissions Microsoft Graph permet de déployer une stratégie SOAR puissante sans créer de faille architecturale dans votre cloud. C'est la clé d'une gouvernance cyber mature et conforme aux exigences des normes les plus strictes.

Sécurisez vos automatisations cyber avec une architecture Zero Trust. > Découvrez comment notre Orchestrateur SOAR Microsoft Security sans Agent met en œuvre les meilleures pratiques de gestion des privilèges API.