Identités de charge de travail : les comptes que personne ne surveille
Les applications et scripts connectés à votre tenant disposent souvent de plus de droits que vos administrateurs, sans MFA ni revue. Voici comment les identifier, réduire leurs privilèges et remplacer les secrets qui traînent.
Des comptes sans visage
Chaque intégration ajoutée au tenant — un outil de sauvegarde, un connecteur RH, un script d'automatisation, une application SaaS — crée une identité : un principal de service. Ces identités ne se connectent pas avec un mot de passe et un téléphone, ne passent pas par le MFA et ne partent jamais en congés. Dans beaucoup de tenants, elles sont plus nombreuses que les utilisateurs, et bien moins surveillées.
Application, principal de service, identité managée
L'inscription d'application est la définition de l'application dans son tenant d'origine. Le principal de service est son instance dans votre tenant : c'est lui qui reçoit les permissions. Les identités managées sont des principaux de service dont Azure gère lui-même les identifiants, pour les ressources hébergées dans Azure. Quand c'est possible, c'est la meilleure option : aucun secret à stocker ni à renouveler.
Les permissions qui donnent les clés
Les permissions d'application s'exercent sans utilisateur connecté, sur tout le tenant. Certaines équivalent de fait à l'administration globale :
RoleManagement.ReadWrite.Directory: s'attribuer n'importe quel rôle Entra ID.AppRoleAssignment.ReadWrite.All: s'accorder n'importe quelle permission d'application.Application.ReadWrite.All: ajouter des identifiants à d'autres applications, donc emprunter leurs droits.Mail.ReadWriteouFiles.ReadWrite.Allen permission d'application : lire toutes les boîtes ou tous les fichiers.
Une application qui détient l'une d'elles est un actif Tier 0, au même titre qu'un administrateur global.
Secrets, certificats, fédération
Un secret client est un mot de passe : il se copie, se retrouve dans un dépôt de code ou un fichier de configuration, et reste souvent valide deux ans. Un certificat est préférable, surtout si la clé privée est protégée. La fédération d'identité de charge de travail va plus loin : un pipeline GitHub Actions ou une charge Kubernetes échange un jeton de son propre fournisseur contre un jeton Entra ID, sans aucun secret stocké.
Attention aux propriétaires. Le propriétaire d'une inscription d'application peut lui ajouter des identifiants. Si une application très privilégiée a pour propriétaire un simple utilisateur, ce compte devient un chemin direct vers ses privilèges.
Gouverner le consentement
Laisser chaque utilisateur consentir à n'importe quelle application, c'est ouvrir la porte au phishing par consentement. Restreindre le consentement utilisateur aux éditeurs vérifiés et aux permissions à faible impact, et activer le flux de demande de consentement administrateur, permet de garder la collaboration fluide sans signer de chèque en blanc.
Ce qu'un audit vérifie
- Les principaux de service détenant des permissions d'application sensibles.
- Les secrets et certificats expirés, ou valides sur des durées excessives.
- Les applications sans propriétaire, ou dont le propriétaire n'est pas un administrateur.
- Les paramètres de consentement utilisateur et le flux de demande administrateur.
- Les applications inactives depuis des mois, qui conservent pourtant leurs droits.
Pour les tenants disposant de la licence Workload Identities Premium, l'accès conditionnel peut aussi s'appliquer aux principaux de service, par exemple pour limiter leurs connexions à des adresses IP connues.