Gérer un parc de tenants Microsoft 365 hérité d'acquisitions, de projets pilotes ou de shadow IT relève vite du casse-tête pour les équipes IT. Le modèle Tenant Governance propose une architecture qui centralise le pilotage sans dupliquer les identités ni sacrifier le principe de moindre privilège. Cet article détaille son fonctionnement technique, ses deux plans — contrôle et données — et comment exploiter le journal d'audit qui en découle.
Une architecture bâtie sur une relation de gouvernance unique
Le principe de Tenant Governance tient en une phrase : tout ce que fait la plateforme se résume à une relation de gouvernance (le contrôle) couplée aux API Microsoft Graph TCM (les données). Cette dualité structure toute l'architecture et détermine ce que chaque tenant peut faire — ou non.
Le modèle distingue deux rôles :
- Le Governing Tenant (tenant gouvernant), qui joue le rôle de hub central pour piloter l'ensemble du parc.
- Le ou les Governed Tenant (tenant gouverné), qu'il s'agisse d'environnements de test, de tenants issus d'acquisitions, de shadow IT découvert, ou de nouveaux tenants add-on créés de façon sécurisée.
Entre ces deux entités coexistent un plan de contrôle et un plan de données, chacun avec ses propres mécanismes.
Le tenant gouvernant : le hub central de votre stratégie
Le hub concentre les capacités de pilotage. Deux rôles y sont définis : Tenant Governance Administrator et Tenant Governance Reader, qui permettent de séparer les responsabilités entre ceux qui définissent les politiques et ceux qui les consultent.
Le hub embarque également :
- des modèles de politiques de gouvernance réutilisables sur l'ensemble du parc ;
- une baseline au format JSON, conservée dans votre propre système de gestion de version (Git, Azure DevOps, etc.) ;
- un job d'export de snapshots, couplé à un evidence store ;
- un flux de détection de dérive (drift feed) qui alimente vos outils de ticketing ou votre SIEM (Security Information and Event Management).
Configuration as code
La baseline JSON versionnée dans votre propre dépôt transforme vos règles de conformité en artefacts revus, testés et déployés comme du code applicatif. La plateforme fournit le mécanisme ; le dépôt, le pipeline et le magasin de preuves restent de votre responsabilité.
Plan de contrôle et plan de données : deux flux complémentaires
Le plan de contrôle établit une relation de gouvernance à sens unique, fondée sur un GDAP (Granular Delegated Admin Privileges) configuré en moindre privilège, activée via un mécanisme d'invitation et d'approbation entre les deux tenants. Le snapshot de politique est figé au moment de la création de la relation, ce qui garantit un état de référence stable et auditable dans le temps.
Le plan de données, lui, repose entièrement sur les API Microsoft Graph TCM, désormais en disponibilité générale (GA) dans la version v1.0. Ces API assurent trois fonctions : le snapshot, le monitoring continu et la détection de dérive, avec des moniteurs exécutés selon un cycle fixe de 6 heures.
| Caractéristique | Plan de contrôle | Plan de données |
|---|---|---|
| Fondation technique | GDAP en moindre privilège + invitation/approbation | API Microsoft Graph TCM (GA en v1.0) |
| Fonction principale | Établit la relation de gouvernance à sens unique | Snapshot, monitoring et détection de dérive |
| État de référence | Snapshot de politique figé à la création | Cycle de moniteurs fixe de 6 heures |
| Identité | Rôles délégués sans seconde identité | Application multi-tenant injectée en option |
| Couverture | Plus de 200 types de ressources | 6 services couverts |
Pour les nouveaux tenants add-on créés via le flux sécurisé, la relation de gouvernance est attachée dès la création, le chemin de récupération administrateur est préservé, et la baseline s'applique dès le premier jour — sans fenêtre de non-conformité.
Découverte et prévention : Related Tenants et Secure Tenant Creation
Deux briques complémentaires renforcent le dispositif, avec des modèles de licence différents.
Related Tenants, réservée à l'offre Premium, exploite des signaux de découverte pour révéler l'existence de tenants liés à votre organisation : trafic de collaboration B2B (Business to Business), permissions d'applications multi-tenant, et comptes de facturation partagés. La limite est logique : un tenant qui n'émet aucun de ces signaux reste invisible au système de découverte.
Secure Tenant Creation, proposée gratuitement, agit en amont : elle permet de contrôler qui a le droit de créer des tenants add-on, d'attacher automatiquement une relation de gouvernance dès la création, et de conserver la récupération administrateur via le compte de facturation.
| Capacité | Related Tenants | Secure Tenant Creation |
|---|---|---|
| Licence | Premium | Gratuite |
| Objectif | Découvrir les tenants liés existants | Contrôler la création de nouveaux tenants |
| Mécanisme | Signaux B2B, permissions d’applications multi-tenant, comptes de facturation partagés | Attache automatiquement une relation de gouvernance et applique la baseline dès le jour 1 |
| Limite connue | Un tenant sans signal détectable reste invisible | Ne couvre pas les tenants déjà existants hors périmètre |
Pour les organisations confrontées à une prolifération de tenants — acquisitions, projets pilotes non déclarés, filiales autonomes — Secure Tenant Creation constitue le point de départ le plus pragmatique : il agit sur le flux entrant avant même que le shadow IT ne s'installe.
Traçabilité : l'audit Entra bidirectionnel
Chaque action de gouvernance — création de relation, application de politique, détection de dérive — est écrite dans le journal d'audit Microsoft Entra, à la fois côté tenant gouvernant et côté tenant gouverné. Cette double écriture garantit une traçabilité complète, exploitable en cas d'audit de conformité ou d'investigation de sécurité.
C'est ce journal d'audit qui devient le point d'ancrage naturel pour construire votre propre pipeline de preuves (evidence store), puisque la plateforme n'impose ni format ni outil de stockage particulier.
Mise en œuvre : exploiter le journal d'audit des actions de gouvernance
Le module requis est le Microsoft Graph PowerShell SDK. Installez-le si nécessaire :
1Install-Module Microsoft.Graph -Scope CurrentUserLa permission minimale à consentir (principe du moindre privilège) est AuditLog.Read.All en délégué — suffisante pour lire le journal d'audit sans droit d'écriture.
Le script suivant se connecte au tenant gouvernant, récupère les événements d'audit des dernières 24 heures et isole ceux susceptibles de correspondre à des actions de gouvernance de tenant, avant de les exporter vers un fichier CSV réutilisable comme point de départ de votre evidence store.
1# Connexion avec le scope en lecture seule sur le journal d'audit2Connect-MgGraph -Scopes "AuditLog.Read.All"3 4# Fenêtre d'observation : les dernières 24 heures5$dateDebut = (Get-Date).AddHours(-24).ToString("yyyy-MM-ddTHH:mm:ssZ")6 7# Récupération des entrées du journal d'audit Entra sur la période choisie8$evenements = Get-MgAuditLogDirectoryAudit -Filter "activityDateTime ge $dateDebut" -All9 10# Isolation des événements potentiellement liés à la gouvernance de tenants11# Les libellés exacts (ActivityDisplayName, Category) dépendent des événements12# réellement journalisés par votre déploiement : vérifiez-les avant de figer ce filtre13$evenementsGouvernance = $evenements | Where-Object {14 $_.ActivityDisplayName -match "Tenant|Governance|GDAP|Baseline" -or15 $_.Category -match "Tenant|Governance"16}17 18# Export vers un fichier réutilisable comme point de départ de votre evidence store19$evenementsGouvernance |20 Select-Object ActivityDateTime, ActivityDisplayName, Category, Result, InitiatedBy |21 Export-Csv -Path ".\audit-gouvernance-tenant.csv" -NoTypeInformation -Encoding UTF822 23Write-Host "Export terminé : $($evenementsGouvernance.Count) événement(s) de gouvernance identifié(s)."Pour vérifier la traçabilité bidirectionnelle, répétez cette collecte côté tenant gouverné en reconnectant avec Connect-MgGraph -Scopes "AuditLog.Read.All" -TenantId "<id-du-tenant-gouverne>". Les mêmes actions doivent apparaître, horodatées à quelques minutes près, dans les deux journaux.
Impact tenant-wide
L'application d'une baseline de gouvernance ou la validation d'une relation GDAP touche l'ensemble d'un tenant gouverné. Avant tout déploiement à grande échelle, testez la baseline sur un tenant de test isolé et vérifiez le contenu du snapshot figé avant d'étendre la relation aux tenants de production.
Dépannage : erreurs courantes
- « Insufficient privileges to complete the operation » : le compte connecté ne dispose pas du consentement pour le scope AuditLog.Read.All. Reconnectez-vous avec
Connect-MgGraph -Scopes "AuditLog.Read.All"et validez le consentement administrateur si demandé. - Résultat vide côté tenant gouverné : vérifiez que vous êtes bien connecté sur le bon tenant via le paramètre
-TenantIddeConnect-MgGraph, et non resté sur le tenant gouvernant. - Dérive non détectée immédiatement : les moniteurs du plan de données s'exécutent sur un cycle fixe de 6 heures — un changement récent peut ne pas encore apparaître dans le drift feed.
- Tenant invisible dans Related Tenants : un tenant sans trafic B2B, sans application multi-tenant partagée et sans compte de facturation commun n'émet aucun signal détectable par cette fonctionnalité Premium.
Limites à connaître avant de déployer
- Related Tenants dépend uniquement de signaux indirects : elle ne garantit pas une découverte exhaustive du parc de tenants.
- Le GDAP en moindre privilège limite volontairement la portée d'action sur les tenants gouvernés — une garantie de sécurité, mais qui peut nécessiter des ajustements si vos politiques couvrent des ressources hors des 200+ types déjà pris en charge.
- Le cycle de moniteur fixe de 6 heures introduit un délai de propagation à intégrer dans vos objectifs internes de détection de dérive.
Conclusion : gouverner sans multiplier les identités
Ce modèle démontre qu'il est possible de piloter un environnement multi-tenant sans créer de secondes identités ni sacrifier le principe de moindre privilège. En séparant clairement le plan de contrôle du plan de données, et en s'appuyant sur des baselines versionnées ainsi que sur les API Graph TCM en v1.0, l'organisation gagne en visibilité, en réactivité face aux dérives, et en conformité auditable.
Si votre organisation cumule les tenants issus d'acquisitions, de projets pilotes non déclarés ou de shadow IT, commencez par activer Secure Tenant Creation — c'est le levier gratuit le plus rapide pour stopper la prolifération incontrôlée. Complétez ensuite avec Related Tenants si votre licence Premium le permet, puis outillez votre pipeline d'evidence store à partir du journal d'audit Entra, comme illustré dans le script ci-dessus.
