Partager via


Réduire les autorisations et les applications surprivilégiées

En tant que développeur visant à concevoir et à implémenter des applications qui suivent les principes fondamentaux de Confiance Zéro, vous souhaitez augmenter la sécurité des applications avec des privilèges minimum. Il est impératif de réduire la surface d’attaque de votre application et l’effet d’une violation de sécurité.

Cet article explique pourquoi les applications ne doivent pas demander plus d’autorisations qu’elles n’en ont besoin. Il définit le terme surprivilégié et présente les recommandations et meilleures pratiques à suivre pour limiter les privilèges dans vos applications afin de gérer les accès et d’améliorer la sécurité.

Qu'est-ce qu'un surprivilège ?

Il y a surprivilège lorsqu'une application demande ou reçoit plus d'autorisations qu'elle n'en a besoin pour fonctionner correctement. Pour améliorer votre compréhension de l’accès surprivilégié, consultez les exemples d’autorisations inutilisées et réductibles dans le reste de cet article.

Autorisations non utilisées

Pour cet exemple de clés inutilisées, imaginez trois portes verrouillées (bleue, jaune et verte), illustrées dans le diagramme suivant.

Diagramme montrant trois portes avec les clés correspondantes pour illustrer les autorisations inutilisées.

Vos ressources sont derrière les portes. Vous avez trois touches (bleu, jaune et vert) qui vous permettent d’ouvrir sa porte correspondante. Par exemple, la touche bleue peut ouvrir la porte bleue. Lorsque vous n’avez besoin que d’accéder à la porte jaune, vous n’avez qu’à porter la clé jaune.

Pour mieux protéger vos ressources, vous ne transportez que les clés dont vous avez besoin lorsque vous en avez besoin et conservez les clés inutilisées dans un emplacement sûr.

Autorisations réductibles

L’exemple de clés réductibles est plus compliqué que l’exemple de clés inutilisées auquel nous ajoutons à présent deux clés spéciales, comme illustré dans le diagramme suivant.

Diagramme montrant trois portes avec les clés correspondantes pour illustrer les autorisations réductibles.

La première clé noire est une clé de passe qui peut ouvrir toutes les portes. La deuxième touche noire peut ouvrir le jaune et les portes vertes. Lorsque vous avez seulement besoin d’accéder au jaune et aux portes vertes, vous ne portez que la deuxième clé noire. Vous conservez votre clé de passe dans un emplacement sûr avec la clé verte redondante.

Dans le monde des identités Microsoft, les clés sont des autorisations d’accès. Vos ressources et vous, le titulaire de clé, sont des applications. Si vous comprenez le risque de porter des clés inutiles, vous savez que vos applications ont des autorisations inutiles.

Écart d’autorisation et risque

Comment les portes et les clés peuvent-elles aider à comprendre comment se produisent les surprivilèges ? Pourquoi votre application peut-elle disposer des autorisations nécessaires pour effectuer une tâche, mais être néanmoins surprivilégiée ? Examinons l’écart d’autorisation qui peut entraîner la différence dans le diagramme suivant.

Graphique à droite : axe Y - Autorisations, axe X - Durée ; courbe supérieure - Autorisations accordées, courbe inférieure - Autorisations utilisées ; statistiques sur la droite décrites dans le contenu de l’article.

L’axe X représente l’axe Time et l’axe Y représente les autorisations. Au début du temps mesuré, vous demandez et recevez l’autorisation pour votre application. À mesure que l’entreprise augmente et change au fil du temps, vous ajoutez de nouvelles autorisations pour prendre en charge vos besoins et la pente des autorisations accordées augmente. Les autorisations utilisées peuvent être inférieures aux autorisations accordées lorsque vous oubliez de supprimer les autorisations inutiles (par exemple, si l’application ne s’arrête pas), entraînant ainsi un écart d’autorisation.

Voici des observations intéressantes dans le Plateforme d'identités Microsoft.

  • Nous avons plus de 4 000 API dans Microsoft Graph.
  • Plus de 200 autorisations Microsoft Graph sont disponibles sur Plateforme d'identités Microsoft.
  • Les développeurs ont accès à un large éventail de données et à la possibilité d’appliquer une granularité aux autorisations demandées par leurs applications.
  • Dans nos enquêtes, nous avons constaté que les applications n’ont que 10 % des autorisations entièrement utilisées pour leurs scénarios.

Réfléchissez soigneusement aux autorisations dont votre application a réellement besoin. Méfiez-vous de l’écart d’autorisation et case activée régulièrement vos autorisations d’application.

Sécurité compromise pour les surpriviléges

Examinons plus en détail les risques résultant des lacunes d’autorisation avec un exemple. Ce scénario de compromis comprend deux rôles : l’administrateur informatique et le développeur.

  • Administrateur informatique : Jeff est un administrateur client qui garantit que les applications dans Microsoft Entra ID sont fiables et sécurisées. Une partie du travail de Jeff consiste à accorder le consentement aux autorisations requises par les développeurs d’applications.
  • Développeur : Kelly est un développeur d’applications qui utilise Plateforme d'identités Microsoft et possède des applications. Le travail de Kelly est de s’assurer que les applications disposent des autorisations appropriées pour effectuer les tâches requises.

Le scénario courant suivant de compromission de la sécurité pour les cas surprivilégiés compte généralement quatre phases.

Diagramme décrit dans le contenu de l’article : quatre phases d’un scénario de compromission de la sécurité.

  1. Tout d’abord, le développeur commence à configurer l’application et à ajouter des autorisations requises.
  2. Deuxièmement, l’administrateur informatique examine les autorisations requises et accorde le consentement.
  3. Troisièmement, l'acteur malveillant commence à pirater les informations d’identification d’utilisateur et réussit à s'emparer de l'identité de l'utilisateur.
  4. Si l'utilisateur possède plusieurs applications, il est également surprivilégié. L’acteur incorrect peut rapidement utiliser le jeton de l’autorisation accordée pour récupérer des données sensibles.

Applications avec des privilèges excessifs

Une entité est surprivilégiée lorsqu’elle demande ou reçoit plus d’autorisations qu’elle n’en a besoin. La définition d’une application surprivilégiée dans la plateforme d’identité Microsoft est « toute application avec des autorisations inutilisées ou réductibles ».

Utilisons Microsoft Graph dans le cadre de l’Plateforme d'identités Microsoft dans un exemple réel pour mieux comprendre les autorisations inutilisées et les autorisations réductibles.

Colonne de gauche : Inutilisée - Octroi d’une ou plusieurs autorisations qui ne sont pas nécessaires du tout pour l’appel d’API en cours. Colonne de droite : Réductible - Autorisation disposant d’une alternative avec des privilèges inférieurs qui donne quand même l’accès aux tâches requises.

L’autorisation inutilisée se produit lorsque votre application reçoit des autorisations qui ne sont pas nécessaires pour les tâches souhaitées. Par exemple, vous créez une application de calendrier. Votre application de calendrier demande et reçoit l’autorisation Files.ReadWrite.All . Votre application ne s’intègre pas aux API des fichiers. Par conséquent, votre application dispose d’une autorisation inutilisée Files.ReadWrite.All .

L’autorisation réductible est plus difficile à découvrir. Il se produit lorsque votre application reçoit peu d’autorisations, mais dispose d’une alternative avec privilèges inférieurs qui fournirait un accès suffisant pour les tâches requises. Dans l’exemple d’application de calendrier, votre application demande et reçoit l’autorisation Files.ReadWrite.All . Toutefois, il doit uniquement lire des fichiers à partir de OneDrive de l’utilisateur connecté et n’a jamais besoin de créer de nouveaux fichiers ou de modifier des fichiers existants. Dans ce cas, votre application utilise uniquement partiellement Files.ReadWrite.All pour que vous deviez passer à une version antérieure vers Files.Read.All.

Recommandations pour réduire les scénarios de surprivilège

La sécurité est un voyage, pas une destination. Il existe trois phases distinctes dans le cycle de vie de la sécurité :

  • Prévention
  • Audit
  • Correction

Le diagramme suivant illustre les recommandations à suivre pour réduire les scénarios de surprivilège.

Diagramme décrit dans le contenu de l’article : recommandations pour empêcher, auditer et corriger les scénarios avec trop de privilèges.

  • Empêcher : lors de la création d’une application, vous devez comprendre entièrement l’autorisation requise pour les appels d’API que votre application doit effectuer, et demander uniquement ce qui est nécessaire pour activer votre scénario. La documentation De Microsoft Graph contient des références claires pour les autorisations de privilège minimum à la plupart des autorisations privilégiées pour tous les points de terminaison. Soyez attentif aux scénarios de surprivilège lorsque vous déterminez les autorisations dont vous avez besoin.
  • Audit : vous et les administrateurs informatiques devez régulièrement passer en revue les privilèges précédemment accordés aux applications existantes.
  • Correction : si vous ou les administrateurs informatiques remarquent une application surprivilégiée dans l'écosystème, vous devez cesser de demander des jetons pour l'autorisation surprivilégiée. Les administrateurs informatiques doivent révoquer les consentements accordés. Cette étape nécessite généralement une modification du code.

Meilleures pratiques pour la gestion des autorisations de privilège minimum

L’adoption de l’application et l’arrêt de la propagation sont deux motivations majeures pour maintenir l’octroi de privilèges minimum avec vos applications.

Colonne de gauche : Stimuler l’adoption – Créer une application digne de confiance pour les clients en évitant les demandes d’autorisation excessives. Colonne de droite : Arrêter la propagation - Les attaquants ne peuvent pas utiliser de privilèges excessifs pour obtenir d’autres accès.

  • Stimulez l’adoption en créant une application digne de confiance pour les clients qui évite les demandes d’autorisation excessives. Limitez les autorisations de votre application uniquement à ce qu’elle doit effectuer pour effectuer sa tâche. Cette pratique réduit le rayon potentiel d’attaques et augmente l’adoption par les clients de vos applications. Appliquez un examen plus approfondi lorsque vous examinez les autorisations demandées par les applications et décidez s’il faut accorder des autorisations d’application.
  • Arrêtez la propagation en veillant à ce que les attaquants ne puissent pas utiliser des privilèges excessifs pour obtenir un accès supplémentaire. Lorsque vous créez une application qui demande des autorisations inutiles, elle est moins susceptible d’être approuvée et peut même être refusée complètement. La meilleure façon de contrôler les dommages consiste à empêcher les attaquants d’obtenir des privilèges élevés qui augmentent l’étendue de la compromission. Par exemple, si votre application doit User.ReadBasic.All uniquement lire les informations de base de l’utilisateur, votre OneDrive, Outlook, Teams et toutes les données confidentielles sont sécurisées si une application est compromise.

Étapes suivantes