Développement d’une stratégie d’autorisations d’application

  • Article

À mesure que vous apprenez à développer à l’aide de Confiance Zéro principes, reportez-vous à cet article après avoir examiné l’acquisition de l’autorisation d’accès aux ressources et le développement d’une stratégie de permissions déléguées. Définissez l’approche des autorisations d’application pour le gestionnaire d'informations d'identification lorsque vous utilisez la Plateforme d’identités Microsoft pour authentifier et autoriser vos applications et gérer les autorisations et le consentement.

Lorsqu’aucun utilisateur n’est impliqué, vous n’aurez pas de modèle d’autorisation efficace, car votre application reçoit toujours les mêmes autorisations que l’utilisateur spécifique de votre application.

  • L’application prouve que c’est l’application qui demande l’autorisation. Votre application prouvera sa propre identité avec l’une des méthodes suivantes :

  • L’application requiert toujours le consentement préalable de l’administrateur. Votre application demande cette autorisation avec l’étendue .default . Il demandera les autorisations que l'administrateur a attribuées à l'application. Quel que soit le nommage d’une étendue particulière, ces autorisations s’appliquent par défaut à tous les utilisateurs.

  • Fonctionnalités trans-utilisateur. Par défaut, User.ReadWrite.All permet à votre application de mettre à jour le profil de chaque utilisateur, même Calendar.Read. En tant qu’autorisation d’application, elle permet à votre application de lire le calendrier de chaque utilisateur dans le locataire.

  • Les autorisations accordées à l’application sont toujours les autorisations utilisées. Contrairement à une permission déléguée, les autorisations d’application ne sont pas limitées par ce que n’importe quel utilisateur particulier peut faire.

Limiter les autorisations d'utilisation des applications

Il existe trois façons de limiter l’accès global à une application.

  • Les applications Microsoft Teams ont un consentement spécifique aux ressources (RSC) qui permet à une application d’accéder à une équipe spécifique plutôt qu’à accéder à toutes les équipes de l’entreprise. RSC est une intégration d’API Microsoft Teams et Microsoft Graph qui permet à votre application d’utiliser des points de terminaison d’API et de gérer des ressources spécifiques. Son modèle d’autorisations permet aux propriétaires Teams et Chat d’accorder le consentement de votre application pour accéder à leurs données Teams et Chat et les modifier.

  • Les administrateurs Microsoft Exchange peuvent créer des stratégies d’application Exchange pour limiter l’accès aux applications à des boîtes aux lettres spécifiques avec un script PowerShell. Ils peuvent limiter une application particulière à des boîtes aux lettres spécifiques avec Calendar.Read ou Mail.Read accès. Cela vous permet, par exemple, de créer une automatisation qui ne peut lire qu’une seule boîte aux lettres ou envoyer du courrier à partir d’une boîte aux lettres et non de tous les membres de l’entreprise.

  • SharePoint a Sites.Selected comme étendue spécifique pour autoriser des autorisations granulaires pour accéder à SharePoint avec une application. Le choix Sites.Selected de votre application au lieu de l’une des autres autorisations entraîne, par défaut, que votre application n’ait pas accès à des collections de sites SharePoint. L’administrateur utilise le point de terminaison d’autorisations de site pour accorder des autorisations lecture, écriture ou lecture-écriture à votre application.

Gestion des informations d’identification des applications

L’hygiène des informations d’identification peut s’assurer que votre application récupère rapidement à partir d’une violation potentielle. Les meilleures pratiques suivantes vous guideront dans le développement d’applications qui effectuent la détection et la correction tout en évitant les temps d’arrêt et affectant les utilisateurs légitimes. Ces recommandations prennent en charge le principe Confiance Zéro de présupposer une violation lors de la préparation à la réponse à un incident de sécurité.

  • Supprimez tous les secrets du code et de la configuration. Lorsque vous utilisez la plateforme Azure, placez des secrets dans le coffre de clés et accédez-y via des identités managées pour les ressources Azure. Rendre votre code résilient pour gérer les rotations de secrets si une compromission se produit. Les administrateurs informatiques peuvent supprimer et faire pivoter des secrets et des certificats sans supprimer votre application ou affecter des utilisateurs légitimes.

  • Utilisez des certificats au lieu des secrets clients, sauf si un processus sécurisé est en place pour gérer les secrets. Les attaquants savent que les secrets clients ont tendance à être moins gérés en toute sécurité et que l’utilisation des secrets divulguées est difficile à suivre. Les certificats peuvent être mieux gérés et révoqués en cas de compromission. Lorsque vous utilisez des secrets, générez ou utilisez un déploiement sans contact sécurisé et un processus de substitution pour ceux-ci. Utilisez des secrets dont le délai d'expiration est défini (par exemple, un an, deux ans) et évitez les secrets qui n'expirent jamais.

  • Restaurez régulièrement des certificats et des secrets pour générer la résilience dans votre application et éviter les pannes en raison d’une substitution d’urgence.

Étapes suivantes