Partage via


Sécurisation des principaux de service dans Microsoft Entra ID

Un principal de service Microsoft Entra est la représentation locale d’un objet d’application dans un locataire ou un annuaire. Il s’agit de l’identité de l’instance de l’application. Les principaux de service définissent l’accès à l’application et les ressources auxquelles l’application accède. Un principal de service est créé dans chaque locataire dans lequel l’application est utilisée, et fait référence à l’objet application global unique. Le locataire sécurise la connexion du principal du service et l’accès aux ressources.

En savoir plus : Objets d’application et de principal du service dans Microsoft Entra ID

Relations du principal du service et du locataire

Une application monolocataire dispose d’un seul principal de service dans son locataire de base. Une application web ou une API multi-locataire requiert un principal de service dans chaque locataire. Un principal de service est créé quand un utilisateur de ce locataire consent à l’utilisation de l’application ou de l’API. Ce consentement crée une relation un-à-plusieurs entre l’application multi-locataire et ses principaux de service associés.

Une application multilocataire est hébergée dans un locataire et dispose d’instances dans d’autres locataires. La plupart des applications SaaS (software as a service) conviennent à un environnement multilocataire. Utilisez des principaux de service pour garantir la posture de sécurité appropriée de l’application et de ses utilisateurs dans des scénarios impliquant un ou plusieurs locataires.

ApplicationID et ObjectID

Une instance d’application a deux propriétés : ApplicationID (ou ClientID) et ObjectID.

Notes

Les termes application et principal de service sont utilisés de manière interchangeable lorsqu’ils font référence à une application dans le contexte des tâches liées à l’authentification. Il existe cependant deux représentations des applications dans Microsoft Entra ID.

La propriété ApplicationID représente l’application globale et est la même pour les différentes instances d’application au sein des locataires. La propriété ObjectID est une valeur unique pour un objet d’application. Comme pour les utilisateurs, les groupes et d’autres ressources, l’élément ObjectID permet d’identifier une instance d’application dans Microsoft Entra ID.

Pour plus d’informations, consultez Relation entre l’application et le principal de service dans Microsoft Entra ID

Créer une application et son objet principal de service

Vous pouvez créer une application et son objet principal de service (ObjectID) dans un locataire à l’aide de :

  • Azure PowerShell
  • Microsoft Graph PowerShell
  • Interface de ligne de commande Azure (Azure CLI)
  • API Microsoft Graph
  • Le portail Azure
  • Autres outils

Capture d’écran de l’ID d’application ou de client et de l’ID d’objet dans la page Nouvelle application.

Authentification d’un principal du service

Il y a deux mécanismes d’authentification quand vous utilisez des principaux de service : les certificats clients et les secrets clients.

Capture d’écran des certificats et des secrets client sous Nouvelle application, Certificats et secrets.

Puisque les certificats sont plus sécurisés, il est recommandé de les utiliser dans la mesure du possible. Contrairement aux secrets clients, les certificats clients ne peuvent pas être incorporés par inadvertance dans le code. Si possible, utilisez Azure Key Vault afin de gérer les certificats et les secrets pour chiffrer les ressources à l’aide de clés protégées par des modules de sécurité matériels :

  • Clés d’authentification
  • Clés de compte de stockage
  • Clés de chiffrement des données
  • Fichiers .pfx
  • Mots de passe

Pour plus d’informations sur Azure Key Vault et son utilisation pour la gestion de certificats et de secrets, consultez :

Défis et atténuations

Quand vous utilisez des principaux de service, reportez-vous au tableau suivant pour relier les problématiques à des mesures d’atténuation.

Problème Limitation des risques
Révisions d’accès pour les principaux de service attribués aux rôles privilégiés Cette fonctionnalité est en préversion
Révisions d’accès aux principaux de service Vérification manuelle de la liste de contrôle d’accès de la ressource à l’aide du portail Azure
Sur les principaux de service avec des autorisations excessives Quand vous créez des principaux de service ou des comptes de service d’automatisation, accordez les autorisations pour la tâche. Évaluez les principaux de service pour réduire les privilèges.
Identifier les modifications apportées aux informations d’identification ou méthodes d’authentification des principaux de service - Consultez Classeur de rapport sur les opérations sensibles
- Consultez le billet de blog Microsoft Tech Community, Microsoft Entra workbook to help you assess Solorigate risk

Rechercher des comptes à l’aide de principaux de service

Pour rechercher des comptes, exécutez les commandes suivantes utilisant des principaux de service avec l’interface Azure CLI ou PowerShell.

  • Interface de ligne de commande Azure - az ad sp list
  • PowerShell - Get-MgServicePrincipal -All:$true

Pour plus d’informations, consultez Get-MgServicePrincipal

Évaluer la sécurité des principaux du service

Pour évaluer la sécurité, évaluez les privilèges et le stockage des informations d’identification. Utilisez le tableau suivant pour atténuer les problèmes :

Problème Limitation des risques
Détecter l’utilisateur qui a consenti à une application multilocataire ainsi que les octrois de consentement illicites à une application multilocataire - Exécutez la commande PowerShell suivante pour rechercher des applications multilocataire
Get-MgServicePrincipal -All:$true | ? {$_.Tags -eq "WindowsAzureActiveDirectoryIntegratedApp"}
- Désactivez le consentement de l’utilisateur
- Autorisez le consentement utilisateur des éditeurs vérifiés pour les autorisations sélectionnées (recommandé)
- Configurez-les dans le contexte utilisateur
- Utiliser leurs jetons pour déclencher le principal de service
Utiliser un secret partagé codé en dur dans un script à l’aide d’un principal de service Utilisez un certificat
Suivi des personnes qui utilisent le certificat ou le secret Superviser les connexions du principal de service en utilisant les journaux des connexions Microsoft Entra
Impossible de gérer la connexion du principal de service avec l’accès conditionnel Superviser les connexions en utilisant les journaux des connexions Microsoft Entra
Le rôle Contributeur est le rôle par défaut de contrôle d’accès en fonction du rôle (Azure RBAC) Évaluez les besoins et appliquez le moins d’autorisations possible

En savoir plus : Qu’est-ce que l’accès conditionnel ?

Passer d’un compte d’utilisateur à un principal de service

Si vous utilisez un compte d’utilisateur Azure en tant que principal de service, voyez s’il vous est possible de passer à une identité managée ou à un principal de service. Si vous ne pouvez pas utiliser d’identité managée, accordez au principal de service suffisamment d’autorisations et d’étendue pour exécuter les tâches requises. Vous pouvez créer un principal de service en inscrivant une application ou à l’aide de PowerShell.

Si vous utilisez Microsoft Graph, consultez la documentation de l’API. Veillez à ce que le type d’autorisation pour l’application soit pris en charge.
Consultez Créer un principal de service

En savoir plus :

Étapes suivantes

Apprenez-en davantage sur les principaux de service :

Sécurisez les comptes de service :

Accès conditionnel :

Utilisez l’accès conditionnel pour bloquer les principaux de service à partir d’emplacements non approuvés.

Consultez Créer une stratégie d’accès conditionnel basée sur l’emplacement