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
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.
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 Workbook de rapport sur les opérations sensibles - Consultez le billet de blog de la communauté technique, Workbook Microsoft Entra pour vous aider à évaluer les risques liés à Solorigate |
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 :
- Guide pratique pour utiliser des identités managées avec App Service et Azure Functions
- Créez une application Microsoft Entra et un principal de service ayant accès aux ressources
- Utiliser Azure PowerShell pour créer un principal du service avec un certificat
Étapes suivantes
Apprenez-en davantage sur les principaux de service :
- Créez une application Microsoft Entra et un principal de service ayant accès aux ressources
- Journaux de connexion dans Microsoft Entra ID
Sécurisez les comptes de service :
- Sécurisation des comptes de service basés sur le cloud
- Sécurisation des identités managées dans Microsoft Entra ID
- Gouverner les comptes de service Microsoft Entra
- Sécurisation des comptes de service locaux
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