« Comment savoir qui, en dehors de mon entreprise, a des droits d’administrateur sur ma messagerie et mes fichiers ? » C’est la question d’un client, et la réponse tient en une règle : un prestataire informatique qui administre votre Microsoft 365 doit pouvoir vous remettre par écrit, sur simple demande, la liste de ses accès, avec leurs rôles et leur date de fin. Ce qu’il ne sait pas lister, personne ne le surveille.

Pourquoi les accès de votre prestataire ne se voient-ils pas ?

Parce que Microsoft fait passer l’administration par les prestataires par une relation partenaire, l’administration déléguée granulaire (GDAP). Le prestataire demande des rôles précis, l’administrateur général de votre entreprise les approuve, et la relation dure au plus 730 jours (Microsoft Learn). Les rôles sont attribués à des groupes qui vivent dans le tenant du prestataire.

La semaine dernière, notre contrôle continu de la configuration Microsoft 365 a signalé chez plusieurs clients un nouveau titulaire sur des rôles sensibles, administrateur général ou administrateur Exchange par exemple, sans nom, affiché comme « objet supprimé ou non résolu ». Le premier jour, l’équipe l’a pris pour un artefact de collecte. Le lendemain, en lisant directement les attributions de rôles, elle a corrigé sa conclusion : ce titulaire était notre propre groupe d’administration déléguée, qui portait une centaine d’attributions sur deux tenants, et chez l’un des clients un autre partenaire détenait lui aussi des accès délégués. Rien n’avait bougé. Chaque attribution a été déclarée au registre des changements.

Le détail qui gêne tient au journal. Quand un prestataire ajoute un technicien dans son groupe, l’opération se fait chez lui, et le journal d’audit de votre tenant n’en garde rien. Le 5 novembre, en pleine campagne visant les prestataires et leurs clients, Microsoft leur a demandé de revoir ces relations (Microsoft).

Tout se joue dans votre navigateur : rien n'est envoyé, rien n'est conservé.

Combien de temps dure au plus une relation d'administration déléguée (GDAP) entre votre tenant et un prestataire ?

La relation dure au plus 730 jours, et c'est l'administrateur général de votre entreprise qui l'approuve.

Dans Microsoft Entra, un titulaire de rôle sensible affiché « objet supprimé ou non résolu » désigne souvent :

Les rôles d'une relation partenaire sont attribués à des groupes qui vivent dans le tenant du prestataire, d'où l'absence de nom lisible chez vous.

Quand un prestataire ajoute un technicien dans son groupe d'administration déléguée, où l'opération laisse-t-elle une trace ?

L'opération se fait chez le prestataire : d'où l'intérêt d'exiger par écrit la liste de ses accès.

Qui a les clés de votre Microsoft 365 ? À gauche, le tenant Microsoft 365 du client et trois portes par lesquelles un tiers détient des droits : 1, la relation partenaire (GDAP), dont le titulaire s'affiche « objet non résolu » et désigne en réalité un groupe qui vit chez le prestataire ; 2, les applications d'entreprise, identité laissée par chaque outil posé ; 3, les comptes de techniciens extérieurs, souvent oubliés après la mission. Les portes s'éclairent l'une après l'autre, le titulaire sans nom prend son nom de groupe partenaire, puis trois flèches convergent à droite vers la liste des clés : qui détient l'accès, par quel canal, avec quels rôles, jusqu'à quelle date. PRESTATAIRE INFORMATIQUE · MICROSOFT 365 Qui a les clés de votre Microsoft 365 ? VOTRE TENANT MICROSOFT 365 1 Relation partenaire (GDAP) Titulaire affiché : « objet non résolu » = groupe chez le prestataire 2 Applications d'entreprise identité laissée par chaque outil posé 3 Comptes de techniciens extérieurs souvent oubliés après la mission La liste des clés À DEMANDER PAR ÉCRIT Qui détient l'accès Par quel canal Avec quels rôles Jusqu'à quelle date

Où voir qui a les clés de votre Microsoft 365 ?

Quatre endroits suffisent, sans rien installer, avec un compte d’administrateur de votre entreprise. Le centre d’administration Microsoft 365, à la rubrique des relations partenaires dans les paramètres, montre chaque prestataire relié à votre tenant et les rôles qu’il détient. Dans Microsoft Entra, la page Rôles et administrateurs donne les titulaires de chaque rôle, où un titulaire sans nom désigne souvent un groupe partenaire. La page Applications d’entreprise garde l’identité laissée par chaque outil qu’un prestataire a posé, et qui se connecte sans personne derrière l’écran. Restent les comptes nominatifs créés pour des techniciens extérieurs, souvent oubliés après la mission.

Les droits d’administration ne sont pas les seules clés confiées à des tiers. Votre configuration publique autorise aussi des services à envoyer des e-mails en votre nom, et notre pré-diagnostic cybersécurité les déduit en 30 secondes de votre nom de domaine.

La liste des clés, à demander par écrit

Nous appelons la liste des clés le document qu’un prestataire doit vous remettre : pour chaque accès, qui le détient (lui ou un partenaire qu’il fait intervenir), par quel canal, avec quels rôles, et jusqu’à quelle date. Demandez-la à la signature, puis le jour où le prestataire part : ses relations et ses applications doivent disparaître avec lui.

Un dirigeant nous dira : « si je réduis ses droits, mon prestataire ne pourra plus intervenir ». Personne ne vous demande de les retirer. Il s’agit de les dater et de les ajuster au besoin réel, comme le recommande le guide d’hygiène informatique de l’ANSSI avec ses comptes d’administration dédiés ; un rôle d’administrateur général permanent se justifie rarement pour intervenir sur une boîte aux lettres.

Nous préférons montrer nos propres accès, première qualification erronée comprise, plutôt que de laisser un client découvrir un titulaire sans nom. Ce contrôle continu fait partie de notre maintenance informatique, pour les entreprises que nous suivons en infogérance à Paris comme ailleurs.

Evan vous reçoit 30 minutes pour ouvrir avec vous les relations partenaires de votre tenant et dresser votre liste des clés : choisir un créneau. État des lieux offert, sans engagement, aucune relance.

Evan Blaise, ingénieur systèmes et réseaux chez ITAIA

Sources