Gouvernance des propriétaires de groupes Entra ID : expiration

Qu’est-ce que la gouvernance des propriétaires de groupes Entra ID ?

La gouvernance des propriétaires de groupes Entra ID commence par une question d’accès : qui peut modifier la liste des personnes admises par un groupe, et qui reste responsable lorsque sa finalité évolue ? Microsoft distingue la propriété d’un objet des rôles d’annuaire. Un propriétaire de groupe peut gérer les propriétés, les propriétaires et les membres de son propre groupe ; l’ajout et le retrait manuels de membres concernent l’appartenance Assigned. La propriété ne lui donne pas de droits de gestion sur tous les groupes. Microsoft Learn : autorisations utilisateur par défaut.

Cette autorité compte lorsqu’un groupe contrôle une ressource réelle. Microsoft documente l’affectation d’applications d’entreprise par groupes : les utilisateurs du groupe affecté obtiennent l’accès, sans propagation aux groupes imbriqués. L’affectation d’applications par groupes nécessite Entra ID P1 ou P2. La déduction opérationnelle est simple : une personne capable de modifier les membres de ce groupe peut modifier la population qui bénéficie de l’accès à l’application affectée. Établissez d’abord l’affectation réelle de l’application ; la propriété d’un groupe sans rapport ne prouve aucun accès de ce type. Microsoft Learn : affecter des utilisateurs et des groupes aux applications.

Pour un groupe Microsoft 365 connecté à un site d’équipe SharePoint, les propriétaires deviennent propriétaires du site et les membres deviennent membres du site. SharePoint peut aussi conserver des autorisations distinctes de celles du groupe connecté. Votre revue doit donc consigner à la fois la relation au groupe et les autres droits accordés sur le site. Retirer un membre du groupe ne suffit pas à prouver que toutes les voies d’accès indépendantes au site ont disparu. Microsoft Learn : partage et autorisations SharePoint.

Ce guide distingue six signaux de revue : un propriétaire invité, l’absence de propriétaire, l’absence de membres et de parent, la visibilité Public, l’absence de couverture d’expiration à l’échelle du tenant et un effectif collecté important. Ils répondent à des questions différentes. Aucun ne démontre une compromission, un rôle d’administration à l’échelle du tenant ou une décision métier de supprimer un groupe. Les prédicats exacts d’EtcSec figurent plus bas avec leurs emplacements sources.

Fonctionnement de la propriété, des réglages invités et de l’expiration

La propriété par un invité est conditionnelle

Pour les groupes Microsoft 365, le réglage Group.Unified AllowGuestsToBeGroupOwner détermine si un invité peut être propriétaire. AllowGuestsToAccessGroups concerne l’accès aux groupes et à leurs données ; AllowToAddGuests concerne l’appartenance des invités. Traitez ces décisions séparément, sans interpréter un réglage comme une autorisation pour les trois opérations. La présentation des réglages précise le périmètre Microsoft 365 et l’exigence de licence P1 pour le réglage de propriété. Microsoft Learn : réglages des groupes.

La référence de configuration Microsoft donne à AllowGuestsToBeGroupOwner la valeur par défaut False. Un tenant n’autorise pas automatiquement les invités à posséder des groupes Microsoft 365 simplement parce qu’il permet la collaboration. Examinez ensemble la configuration effective et l’affectation réelle de propriété. En l’absence d’objet de réglages personnalisé, consultez les valeurs par défaut du modèle plutôt que d’interpréter l’absence d’objet comme une autorisation. Microsoft Learn : configurer les réglages des groupes.

N’étendez pas ce contrôle Group.Unified à une règle générale pour tous les groupes de sécurité. Graph documente séparément l’ajout d’utilisateurs ou de principaux de service comme propriétaires de groupes Microsoft 365 ou de sécurité. Pour un groupe associé à Teams, la synchronisation des propriétaires peut prendre jusqu’à deux heures, et certaines modifications d’équipe exigent aussi que le propriétaire soit membre. Microsoft Learn : ajouter des propriétaires de groupe.

Les restrictions appliquées aux invités influencent aussi les possibilités de gestion. Avec des autorisations invité restreintes, My Apps n’expose pas la liste des groupes dont un invité est propriétaire ou membre. SharePoint et Teams conservent leurs propres contrôles invités. Une relation de propriété observée constitue donc un signal de revue, sans prouver que toutes les actions de gestion réussissent dans toutes les interfaces. Validez l’opération et le service précis dans un environnement de test autorisé. Microsoft Learn : restreindre les autorisations invité.

Considérons une exposition illustrative : un groupe Assigned donne accès à une application de projet et un invité en est propriétaire autorisé. Une modification des membres pourrait modifier l’accès à cette application si l’opération concernée est permise. Il s’agit d’une déduction tirée de la propriété et de l’affectation d’applications documentées, et non d’un incident observé ou d’une élévation démontrée vers Global Administrator. Documentez la ressource et les restrictions applicables avant de considérer ce scénario comme un chemin d’accès sur lequel agir. Autorisations de propriété, affectation d’applications.

Sans propriétaire, vide et inutilisé sont des états différents

Un groupe peut avoir des membres sans propriétaire. Un autre peut avoir un propriétaire sans membres. Un troisième peut être vide mais rester nécessaire à un processus prévu. Conservez la propriété, l’appartenance, les relations parentes et la finalité métier dans des champs de revue distincts. Le fichier group-no-owner.go:37 du collecteur examine les propriétaires ; group-orphaned.go:39 examine les membres et les parents. Aucune de ces fonctions ne mesure le besoin métier.

La stratégie Microsoft pour les groupes sans propriétaire s’applique aux groupes Microsoft 365 et n’est disponible que dans les clouds publics. Elle envoie aux membres éligibles des invitations leur permettant d’accepter la propriété, avec une durée de notification configurable et une éligibilité définie par des groupes de sécurité. C’est un processus de récupération qui exige l’acceptation d’un membre, pas une affectation automatique de responsabilité. Microsoft Learn : ressource ownerlessGroupPolicy.

Si personne n’accepte pendant la période de notification, les notifications cessent et les administrateurs doivent trouver puis affecter un propriétaire. Le guide d’administration Microsoft documente aussi les prérequis de licence et de boîte aux lettres pour les notifications. Intégrez cette file de cas non résolus à la procédure opérationnelle ; l’activation de la stratégie ne prouve pas à elle seule que tous les groupes sans propriétaire ont acquis des propriétaires responsables. Microsoft Learn : gérer les groupes et équipes sans propriétaire.

L’expiration couvre les groupes Microsoft 365

Une stratégie d’expiration s’applique aux groupes Microsoft 365, pas à tous les groupes de sécurité. Les groupes actifs peuvent être renouvelés automatiquement à l’approche de l’échéance grâce aux activités Outlook, SharePoint, Teams ou Viva Engage documentées. Les groupes non renouvelés sont supprimés, avec un délai de restauration de 30 jours. Un groupe ancien peut donc être renouvelé à plusieurs reprises sous une stratégie valide. Son âge ne prouve pas à lui seul l’absence de couverture d’expiration. Microsoft Learn : expiration des groupes Microsoft 365.

La ressource groupLifecyclePolicy distingue durée de vie et couverture : groupLifetimeInDays définit l’intervalle renouvelable, tandis que managedGroupTypes vaut All, Selected ou None. Selected exige de vérifier l’inclusion du groupe concerné. alternateNotificationEmails fournit les adresses de notification pour les groupes sans propriétaire. Considérez une date d’expiration renouvelée comme une preuve de cycle de vie, pas comme une attestation métier. Microsoft Learn : ressource de stratégie de cycle de vie.

La visibilité Public mérite une revue des ressources

Microsoft décrit Public comme permettant aux utilisateurs de rejoindre un groupe sans autorisation du propriétaire, tandis que Private l’exige. L’appartenance privée n’est pas automatiquement masquée ; HiddenMembership est une valeur distincte. La visibilité publique d’un groupe doit déclencher une revue des conditions d’admission prévues et des ressources connectées. Elle ne prouve pas à elle seule un accès Internet anonyme ni une récupération réussie de données. Microsoft Learn : options de visibilité des groupes.

Détection : mesurer l’annuaire avant d’interpréter les résultats

Les blocs suivants reprennent la syntaxe de requêtes ou des exemples de Microsoft Learn. Les chemins relatifs relèvent de la documentation Graph v1.0. Les identifiants entre accolades doivent être remplacés par ceux des objets réels ; l’identifiant fixe de l’exemple de comptage est l’exemple Microsoft. Aucune requête présentée ici n’a été exécutée sur un tenant. Conservez le périmètre des requêtes, les échecs de collecte et la pagination avec l’inventaire obtenu.

1. Établir le type de groupe et le périmètre de collecte

La page Microsoft de liste des groupes fournit ce filtre Microsoft 365, reproduit à l’identique :

GET https://graph.microsoft.com/v1.0/groups?$filter=groupTypes/any(c:c+eq+'Unified')

Utilisez-le pour l’inventaire Microsoft 365, pas comme l’intégralité de la revue des groupes de sécurité. La même page documente des tailles de page par défaut et maximales de 100 et 999, ainsi que des délais de réplication après modification. Suivez chaque @odata.nextLink renvoyé ; une page unique ou un résultat récemment devenu obsolète ne doit pas permettre de clôturer un constat. Microsoft Learn : lister les groupes.

Pour chaque groupe sélectionné, la syntaxe documentée de Get group est :

GET /groups/{id}

L’API prend en charge $select pour des propriétés spécifiques. Conservez l’ID du groupe, le type d’appartenance et l’état de synchronisation dans le dossier de revue, ainsi que la réponse brute, afin de distinguer les attributs absents des réponses négatives. Microsoft Learn : obtenir un groupe.

La ressource group v1.0 actuelle documente groupTypes contenant Unified pour les groupes Microsoft 365 et expirationDateTime comme leur horodatage d’expiration défini par la stratégie. Cette date est nulle pour les groupes de sécurité. Ne présentez pas la date nulle d’un groupe de sécurité comme un constat de cycle de vie Microsoft 365 non couvert. Microsoft Learn : propriétés des groupes.

2. Examiner les propriétaires et résoudre leur type d’identité

Lisez la relation de propriété avec la syntaxe Learn :

GET /groups/{id}/owners

Cette relation peut contenir des utilisateurs ou des principaux de service. Graph n’expose pas les propriétaires des groupes créés dans Exchange, des groupes de distribution ni des groupes synchronisés depuis l’environnement local. La page v1.0 documente aussi l’absence de propriétaires principaux de service et des objets à informations limitées lorsque l’appelant ne peut pas lire un type de ressource. Dans ces objets, les attributs peuvent être nuls alors que l’ID et le type restent disponibles. Suivez la pagination et conservez les identités non résolues ; des attributs manquants ne permettent pas d’établir qu’un groupe n’a pas de propriétaires ou qu’un propriétaire est invité. Microsoft Learn : lister les propriétaires.

Résolvez explicitement les propriétaires utilisateurs et examinez le userType collecté. L’API Get user de Microsoft permet de sélectionner des propriétés non renvoyées par défaut ; la référence des autorisations par défaut distingue les utilisateurs Member et Guest. Ne remplacez pas l’attribut d’identité par des domaines de messagerie ou des chaînes #EXT#, et ne déduisez pas une compromission d’une classification Guest. Microsoft Learn : obtenir un utilisateur, types d’utilisateur.

Si vous utilisez un filtre avancé sur le nombre de propriétaires pendant l’investigation, appliquez les exigences documentées de ConsistencyLevel: eventual et de comptage. Les requêtes avancées utilisent un index distinct et ne permettent pas de combiner ces filtres de relation avec $expand. Conservez une liste de candidats sans propriétaire distincte des lectures de propriétaires confirmées pour chaque groupe. Microsoft Learn : fonctionnalités de requête avancées.

3. Vérifier séparément les membres, la taille et les parents directs

Learn fournit la requête des membres directs :

GET /groups/{id}/members

Son exemple de comptage est :

GET https://graph.microsoft.com/v1.0/groups/02bd9fd6-8f93-4758-87c3-1fb73740a315/members/$count
ConsistencyLevel: eventual

Ce sont des objets d’annuaire directs, pas un décompte transitif de personnes distinctes. L’API members documente une omission des principaux de service en v1.0, et l’appartenance masquée exige Member.Read.Hidden. Pour valider, énumérez toutes les pages et dédupliquez les ID ; consignez les restrictions plutôt que de présenter une liste incomplète comme un effectif total exhaustif. Microsoft Learn : lister les membres.

Lisez la relation parente dans une requête distincte :

GET /groups/{id}/memberOf

L’API renvoie les appartenances directes plutôt qu’un graphe transitif. Sa réponse peut inclure des groupes, des unités administratives ou des rôles d’administration selon le type de groupe. Identifiez les types d’objets renvoyés pour confirmer les groupes parents. Une lecture de relation qui échoue n’est pas un résultat nul obtenu avec succès. Microsoft Learn : lister memberOf.

4. Lire les stratégies de cycle de vie et de propriété

Reprenez l’exemple de liste des stratégies de cycle de vie :

GET https://graph.microsoft.com/v1.0/groupLifecyclePolicies

L’API documente Directory.Read.All pour l’accès délégué ou applicatif. Conservez le mode de couverture renvoyé et comparez-le à la stratégie prévue. Une réponse Selected impose de vérifier l’ensemble des groupes sélectionnés ; l’existence d’un objet de stratégie ne prouve pas à elle seule la couverture de chaque groupe. Microsoft Learn : lister les stratégies de cycle de vie, propriétés de couverture.

Lisez les réglages du tenant avec l’exemple documenté :

GET https://graph.microsoft.com/v1.0/groupSettings

Examinez Group.Unified et ses valeurs plutôt que de traiter toute la réponse comme un booléen. Learn indique GroupSettings.Read.All comme autorisation de lecture de moindre privilège et explique les exigences supplémentaires de rôle utilisateur pour les appels délégués, notamment le comportement différent avec des autorisations déléguées de lecture à l’échelle de l’annuaire. Microsoft Learn : lister les réglages des groupes.

Lorsque les réglages personnalisés sont absents, la présentation des réglages fournit cette requête de modèle :

GET https://graph.microsoft.com/v1.0/groupSettingTemplates

Utilisez les valeurs par défaut documentées du modèle pour interpréter l’absence d’objet personnalisé. Ne lisez pas cette absence comme une activation de la propriété par les invités. Microsoft Learn : modèles et valeurs par défaut des réglages de groupe.

Enfin, lisez la stratégie des groupes sans propriétaire avec son exemple Learn :

GET https://graph.microsoft.com/v1.0/policies/ownerlessGroupPolicy

Ce point de terminaison prend en charge Group.Read.All en mode délégué, avec un utilisateur appelant affecté au rôle Groups Administrator ou Exchange Administrator. Les autorisations applicatives ne sont pas prises en charge. Un 404 documenté indique que la stratégie n’existe pas ; un échec d’autorisation exige une autre interprétation. Ne promettez pas qu’un collecteur fonctionnant uniquement avec des autorisations applicatives puisse examiner cette stratégie par ce même point de terminaison. Microsoft Learn : obtenir ownerlessGroupPolicy.

Comment EtcSec détecte ces situations

Les descriptions suivantes proviennent de l’inspection statique d’etc-collector au commit b767fc1ef7ea4cf52d797d5aea1dd4c2d3d07d7c. Les emplacements de fichiers sont relatifs à public/internal/audit/detectors/. Il s’agit de critères d’implémentation, pas de mesures sur un tenant.

Les limites de collecte modifient l’étape de validation suivante

Pour NO_EXPIRY, une configuration non sondée renvoie un constat Info libellé non déterminable, avec Count=1. Cette valeur ne représente pas un groupe non couvert. La fonction n’examine ni l’activité, ni expirationDateTime, ni un seuil de durée de vie. Une stratégie Selected peut être légitime alors que cette implémentation signale ses groupes Unified ; confirmez la couverture réelle avant de décrire ces groupes comme n’expirant jamais. Source : unified-group-no-expiry.go:43 et :56.

Le fournisseur Azure actuel affecte la même liste d’ID de membres à Members et à Member. LARGE additionne ensuite les deux longueurs. Sur ce chemin réussi, avec une collecte complète et sans ID dupliqués, 2 × n > 500 devient n > 250 : 250 ne satisfait pas la condition, 251 la satisfait. C’est un calcul tiré du code, pas un résultat de tenant ou de test Go. 500 est le seuil écrit du détecteur, pas une limite Microsoft de taille des groupes. Sources : public/internal/providers/azure/client.go:1115, group-large-membership.go:29.

Le fournisseur renseigne bien MemberOf, malgré un commentaire obsolète d’ORPHANED affirmant le contraire. Il stocke les ID de la réponse directe memberOf sans filtrer leur type d’objet ; un parent enregistré n’est donc pas nécessairement un autre groupe. Microsoft Learn : types d’objets memberOf.

Les échecs de lecture des membres et des parents n’ont pas la distinction explicite succès/échec du marqueur de sondage des propriétaires. Ce marqueur ne garantit pas l’exhaustivité des propriétaires : l’enrichissement conserve l’UPN ou le nom d’affichage et écarte un objet lorsque les deux sont absents, même après une réponse réussie. Il dispose d’un budget de cinq minutes et ne suit pas la pagination des propriétaires dans ce chemin de code. Une limite de groupes peut aussi provoquer un retour avant l’enrichissement. Examinez les avertissements de collecte et les relations brutes avant de faire confiance à des décomptes nuls. Sources : public/internal/providers/azure/client.go:1142, :1158, :1170, :1184, :1235, :1253, :1264, :1345.

Remédiation : rétablir la responsabilité et vérifier l’accès (Remediation)

1. Attester la propriété avant de modifier les droits

Nous recommandons de commencer par une revue fondée sur les ressources : consignez la finalité, le sponsor interne responsable, les applications affectées ou les sites connectés, les propriétaires actuels, les exceptions approuvées et l’autorité responsable de l’appartenance. Demandez au responsable de la ressource de confirmer si le groupe reste nécessaire. Pour les groupes maintenus, affectez des propriétaires responsables avant de retirer les propriétés devenues obsolètes.

Microsoft documente le chemin du centre d’administration Entra ID → Groupes → Tous les groupes → sélectionner le groupe → Propriétaires → Ajouter, ainsi que le retrait depuis la liste des propriétaires. Respectez les exigences de rôle documentées et conservez les relations avant/après. Pour les groupes associés à Teams, incluez dans les critères de validation les exigences d’appartenance et de synchronisation décrites plus haut. Microsoft Learn : gérer les propriétaires, ajout de propriétaires avec Graph.

2. Restreindre délibérément la propriété par les invités

Pour les groupes Microsoft 365 dont la stratégie exige une propriété interne, conservez ou rétablissez AllowGuestsToBeGroupOwner=False dans Group.Unified. Examinez séparément les propriétaires invités existants, sans supposer qu’une modification de configuration prouve la disparition de toutes les relations existantes. Préservez les autres réglages lors de la mise à jour de l’objet ; le guide de configuration Microsoft demande expressément de lire les valeurs actuelles pour éviter d’écraser une configuration sans rapport. Relisez les réglages et les propriétaires après la modification. Microsoft Learn : configurer les réglages des groupes.

Documentez les exceptions avec un sponsor et une date de revue. Examinez séparément l’invitation, l’authentification et le cycle de vie de l’identité invitée à l’aide du guide de la surface d’attaque des comptes invités, qui couvre les autorisations d’invitation, le MFA et les comptes inactifs. Ces contrôles d’identité complètent la revue de propriété ; ils ne remplacent pas la stratégie de cycle de vie des groupes.

3. Gérer la file de récupération des groupes sans propriétaire

Dans le centre d’administration Microsoft 365, activez le processus des groupes sans propriétaire sous Paramètres → Paramètres de l’organisation → Groupes Microsoft 365, puis configurez les destinataires éligibles, l’expéditeur, la période de notification et les groupes cibles. Vérifiez les licences prises en charge et les boîtes aux lettres Exchange Online : l’expéditeur doit disposer d’une boîte utilisateur ou de groupe, les boîtes partagées d’expéditeur ne sont pas prises en charge, et les destinataires doivent disposer de boîtes utilisateur. Suivez les acceptations de propriété et escaladez les groupes encore non résolus à la fin des notifications. Le processus documenté laisse l’affectation manuelle finale aux administrateurs lorsque personne n’accepte. Microsoft Learn : configuration de la stratégie des groupes sans propriétaire.

4. Configurer l’expiration selon les dépendances réelles

Choisissez la durée de vie et la couverture All ou Selected après examen des dépendances applicatives et collaboratives. Les réglages d’expiration Entra prennent aussi en charge une adresse de notification alternative pour les groupes sans propriétaire. Les exigences de licence imposent de posséder des licences P1 ou P2 pour les membres des groupes auxquels l’expiration s’applique. Confirmez le traitement du renouvellement avant de considérer la suppression comme un résultat souhaité. Microsoft Learn : configuration de l’expiration.

Relisez la stratégie de cycle de vie et les preuves d’expiration de chaque groupe. Pour la couverture Selected, conservez la preuve des groupes inclus. Traitez séparément l’expiration des groupes, la rétention des contenus et le retrait des comptes invités ; une stratégie de cycle de vie décrit une durée de vie renouvelable du groupe, pas ces trois résultats. Microsoft Learn : définition de la stratégie de cycle de vie.

5. Examiner l’admission et les effectifs importants

Pour les groupes Public, demandez si l’admission sans autorisation du propriétaire correspond au public visé par la ressource. Lorsque l’approbation est requise, examinez la visibilité Private et vérifiez séparément les autorisations effectives du service. Pour les constats LARGE, obtenez d’abord un inventaire dédupliqué des membres directs, puis examinez pourquoi chaque population a besoin d’accès. Séparez les responsabilités ou les groupes d’accès lorsque la revue métier le justifie ; ne retirez pas des membres simplement pour effacer le prédicat numérique de l’implémentation.

Conservez la structure des groupes privilégiés comme une investigation distincte. L’article sur les groupes privilégiés imbriqués et attribuables à un rôle traite de ce sujet. Respectez son périmètre sans importer d’affirmation d’élévation de rôle dans cette revue de propriété.

6. Faire aboutir les revues d’appartenance à une décision

Créez des revues avec des réviseurs nommés, des réviseurs de secours lorsque les propriétaires de groupe sont sélectionnés, un résultat explicite en cas de non-réponse et une décision sur l’application automatique des résultats. Learn documente le recours aux réviseurs de secours pour les groupes sans propriétaire et avertit que le retrait pour non-réponse avec application automatique peut révoquer l’accès aux ressources. Les membres d’un groupe sans propriétaire ne conservent pas inévitablement l’accès après une revue : le résultat dépend de ces réglages et de l’application des décisions. Vérifiez les exigences actuelles de licence Governance ou Suite pour la revue choisie. Microsoft Learn : créer des revues d’accès.