Aller au contenu
William EinsargueixLe carnet d'un admin
← Retour au carnet

Sécurité · Identités

Comptes de service Microsoft 365 : savoir à quoi ils servent encore

Un compte nommé « service » ne dit pas grand-chose sur ce qu'il fait. Avant de changer son mot de passe ou de le désactiver, je voudrais savoir quel traitement en dépend. Sinon, on risque de découvrir son utilité au prochain échec d'une tâche planifiée.

De quelle identité parle-t-on ?

Il peut s'agir d'un compte utilisateur utilisé par un script, d'une application avec un principal de service ou d'une identité managée. Ces cas ne se sécurisent pas tous de la même manière.

Le MFA d'un utilisateur et l'authentification d'un traitement sans intervention humaine répondent à des besoins différents. Ajouter une exception MFA à un compte ne règle pas à lui seul la question de son usage.

Ce qui mérite une vérification

Je regarderais surtout les droits trop larges, les secrets stockés dans les scripts et l'absence de propriétaire. Un traitement peut fonctionner depuis longtemps tout en dépendant d'un accès dont personne ne connaît plus les limites.

Retrouver les dépendances

Partez des tâches planifiées, des serveurs d'automatisation et des inscriptions d'applications. Rapprochez-les des journaux disponibles, des certificats et des secrets utilisés. Le nom du compte est une piste ; ce n'est pas une preuve de son rôle.

Pour chaque identité, essayez de répondre à ces questions : quel traitement l'utilise, depuis quel système, sur quelles ressources et sous la responsabilité de qui ?

Préparer le changement

Lorsqu'une application le permet, examinez une authentification adaptée à l'automatisation : une identité managée dans les environnements compatibles, ou une application avec les seules permissions nécessaires.

Un principal de service peut lui aussi avoir trop de droits. Vérifiez ses permissions et le stockage de ses moyens d'authentification. Prévoyez le renouvellement d'un certificat ou d'un secret avant son expiration.

Pour un compte utilisateur technique existant, préparez une migration avec un test et une possibilité de retour. Ne le désactivez pas sur la seule base d'une date de connexion ancienne.

Laisser une trace utile

Une fiche courte suffit pour commencer : usage, propriétaire, droits, emplacement du traitement, date de renouvellement et procédure de reprise. N'y recopiez pas le secret lui-même.

AuditMS peut faire ressortir des comptes à examiner. Il ne sait pas quel outil interne dépend de chacun : cette partie se vérifie avec les personnes qui exploitent le service.

Documentation Microsoft