Aller au contenu principal
Expert Cybersécurité & IAv9.0
Centres de ressources conformité
Besoin d'un accompagnement expert ?
Devis personnalisé sous 24h — audit, conformité, incident
Checklists Sécurité — Audit & Durcissement
Formats disponibles
📄 PDF 📊 Excel 🌐 Web

11 checklists professionnelles couvrant 2 200+ points de contrôle. Téléchargement gratuit, aucune inscription.

Service Principal

ad

Définition

Un Service Principal, dans Azure AD / Microsoft Entra ID, est l'identité opérationnelle locale à un tenant représentant une application, permettant à celle-ci de s'authentifier et d'accéder à des ressources sans intervention utilisateur, distincte de l'objet Application Registration qui définit quant à lui la configuration globale de l'application au niveau de son éditeur, potentiellement partagée entre plusieurs tenants. Chaque application enregistrée génère automatiquement un Service Principal correspondant dans le tenant où elle est utilisée, et une même Application Registration multi-tenant peut ainsi donner naissance à plusieurs Service Principals distincts, un par tenant client l'ayant consentie. L'authentification d'un Service Principal s'effectue via un secret client (client secret), un certificat X.509, ou, pratique désormais recommandée par Microsoft, une Managed Identity fédérée évitant tout stockage de secret. Les permissions accordées à un Service Principal, qu'elles soient de type délégué (au nom d'un utilisateur) ou d'application (autonomes, sans utilisateur), déterminent son périmètre d'accès à Microsoft Graph ou à d'autres API. Sur le plan sécurité, un Service Principal disposant de permissions d'application excessives, notamment RoleManagement.ReadWrite.Directory ou Application.ReadWrite.All, constitue une cible privilégiée d'escalade de privilèges cloud, un attaquant compromettant son secret pouvant s'octroyer des rôles Entra ID supplémentaires sans jamais interagir avec un compte utilisateur surveillé.

Fonctionnement technique

Un Service Principal s'authentifie avec client_id + client_secret (ou certificat) vers l'endpoint OAuth 2.0 de l'tenant. Il obtient un Access Token avec les permissions accordées (application permissions) ou au nom d'un utilisateur (delegated permissions). Les permissions application sont permanentes sans consentement utilisateur requis.

Attaques ciblant les Service Principals

  • Client Secret Theft : Extraction depuis code source, Key Vault, variables CI/CD
  • Illicit Consent Grant : App malveillante obtenant permissions étendues
  • Service Principal Backdoor : Ajout d'un secret à un SP existant pour persistance

Audit et mitigation

  • Audit des SP avec permissions application élevées (mail.read, directory.readwrite)
  • Rotation régulière des client secrets
  • Préférer les Managed Identities aux client secrets

Articles liés

Un projet cybersécurité ?

Expert dispo · Réponse 24h

Devis