Partager via

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

  • Article

À mesure que vous apprenez à développer des applications en suivant les principes de la Confiance Zéro, consultez cet article après avoir passé en revue Acquérir l’autorisation d’accéder aux ressources et Développer 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.

Quand aucun utilisateur n’est impliqué, vous n’avez pas de modèle d’autorisation efficace dans la mesure où des autorisations préaffectées sont toujours accordées à votre application.

  • L’application prouve que c’est l’application qui demande l’autorisation. Votre application prouve sa propre identité à l’aide de 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. Elle demande les autorisations que l’administrateur attribue à l’application.

  • Fonctionnalités trans-utilisateur. Par défaut, User.ReadWrite.All permet à votre application de mettre à jour le profil de chaque utilisateur. En tant qu’autorisation d’application, elle permet à votre application de lire et de mettre à jour le profil 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’application

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. Si vous choisissez Sites.Selected pour votre application au lieu de l’une des autres autorisations, votre application, par défaut, n’a accès à aucune collection 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.

Gérer les 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 guident dans le développement d’applications qui prennent en charge la détection et la correction tout en évitant les temps d’arrêt et en affectant des 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