Renforcer la sécurité des applications à l’aide des principes de la Confiance Zéro

Il n’est pas possible de présupposer l’existence d’un périmètre réseau sécurisé autour des applications développés. Presque toutes les applications développées sont, par conception, accessibles à partir de l’extérieur du périmètre réseau. Il n’est pas garanti que les applications soient sécurisées lorsqu’elles sont développées ou resteront en l’état après leur déploiement. Il incombe au développeur de l’application d’optimiser non seulement la sécurité de l’application, mais également de minimiser les dommages que l’application peut causer si elle est compromise.

En outre, la responsabilité inclut la prise en charge de l’évolution des besoins des clients et utilisateurs qui s’attendront à ce que l’application soit conforme aux exigences de la sécurité de la Confiance Zéro. Découvrez les principes du modèle Confiance Zéro et adoptez ses pratiques. En découvrant et en adoptant les principes, les applications développées peuvent être plus sécurisées et réduire les dommages qu’elles peuvent causer en cas de faille de sécurité.

Le modèle de Confiance Zéro prescrit une culture de vérification explicite plutôt que de confiance implicite. Le modèle repose sur trois principes directeurs clés :

  • Vérifier explicitement
  • Utiliser le droit d'accès minimal
  • Supposer une violation

Meilleures pratiques basées sur la Confiance Zéro

Suivez ces meilleures pratiques pour générer des applications Confiance Zéro avec la Plateforme d’identités Microsoft et ses outils.

Vérifier explicitement

La Plateforme d’identités Microsoft offre des mécanismes d’authentification pour vérifier l’identité de la personne ou du service accédant à une ressource. Appliquez les meilleures pratiques décrites ci-dessous pour vérifier explicitement toutes les entités qui ont besoin d’accéder aux données ou aux ressources.

Bonne pratique Avantages de la sécurité des applications
Utiliser les bibliothèques d’authentification Microsoft (MSAL). MSAL est un ensemble de bibliothèques d’authentification Microsoft pour les développeurs. Avec MSAL, quelques lignes de code suffisent pour authentifier les utilisateurs et applications, et acquérir des jetons pour accéder aux ressources d’entreprise. MSAL utilise des protocoles modernes (OpenID Connecter et OAuth 2.0) qui éliminent la nécessité pour les applications de gérer directement les informations d’identification d’un utilisateur. Cette gestion des informations d’identification améliore considérablement la sécurité des utilisateurs et des applications, car le fournisseur d’identité devient le périmètre de sécurité. En outre, ces protocoles évoluent continuellement pour répondre aux nouveaux paradigmes, opportunités et défis en matière de sécurité des identités.
Adoptez les extensions de sécurité renforcée telles que l’Évaluation continue de l’accès et le contexte d’authentification de l’accès conditionnel, le cas échéant. Dans Microsoft Entra ID, certaines des extensions les plus utilisées sont l’Accès conditionnel, le Contexte d’authentification de l’accès conditionnel et l’Évaluation continue de l’accès. Les applications qui utilisent des fonctionnalités de sécurité améliorées, telles que l’Évaluation continue de l’accès et le Contexte d’authentification de l’accès conditionnel, doivent être codées pour gérer les défis liés aux revendications. Des protocoles ouverts permettent d’utiliser les défis et demandes de revendications pour appeler des fonctionnalités du client supplémentaires. Les fonctionnalités peuvent être de poursuivre l’interaction avec Microsoft Entra ID (par exemple, lorsqu’une anomalie s’est produite ou si les conditions d’authentification de l’utilisateur changent). Ces extensions peuvent être codées dans une application sans perturber les flux de code principaux pour l’authentification.
Utilisez le flux authentification approprié selon le type d’application. Pour les applications web, essayez toujours d’utiliser des flux de client confidentiels. Pour les applications mobiles, essayez d’utiliser des répartiteurs ou le navigateur système pour l’authentification. Les flux pour applications web qui peuvent contenir un secret (clients confidentiels) sont considérés comme plus sûrs que des clients publics (par exemple, applications de bureau et de console). Lorsque le navigateur web système est utilisé pour authentifier une application mobile, une expérience d’authentification unique (SSO) sécurisée permet d’utiliser des stratégies de protection des applications.

Utiliser le droit d’accès minimal

Un développeur utilise la plateforme d’identités Microsoft pour accorder des autorisations (étendues) et vérifier qu’un appelant a reçu l’autorisation appropriée avant d’autoriser l’accès. Appliquez le droit d’accès minimal dans les applications en activant des autorisations fines qui permettent d’accorder le minimum d’accès nécessaire. Tenez compte des pratiques suivantes pour vous assurer de l’adhésion au principe du privilège minimum :

  • Évaluez les autorisations demandées pour vous assurer que le privilège minimum absolu est défini pour accomplir la tâche. Ne créez pas des autorisations « passe-partout » avec un accès à la surface entière de l’API.
  • Lors de la conception d’API, fournissez des autorisations fines pour permettre un accès assorti d’un privilège minimum. Commencez par diviser la fonctionnalité et l’accès aux données en sections contrôlables à l’aide d’étendues et de rôles d’application. N’ajoutez pas des API aux autorisations existantes d’une façon qui modifie la sémantique de l’autorisation.
  • Accordez des autorisations en lecture seule. Un accès Write inclut des privilèges pour les opérations de création, de mise à jour et de suppression. Un client ne devrait jamais exiger d’accès en écriture seulement pour lire des données.
  • Accordez des autorisations déléguées et d’application. Ignorer les autorisations d’application peut entraîner l’imposition d’exigences rigoureuses aux clients pour la réalisation de scénarios courants tels que l’automatisation, les microservices, etc.
  • Si vous utilisez des données sensibles, prenez en compte les autorisations d’accès « standard » et « complet ». Limitez les propriétés sensibles afin qu’elles ne soient pas accessibles à l’aide d’une autorisation d’accès « standard » (par exemple, Resource.Read). Implémentez ensuite une autorisation d’accès « complet » (par exemple, Resource.ReadFull) qui retourne toutes les propriétés disponibles, dont les informations sensibles.

Supposer une violation

Le portail d’inscription d’application de la Plateforme d’identités Microsoft est le point d’entrée principal pour les applications qui ont l’intention d’utiliser la plateforme pour leur authentification et leurs besoins associés. Lors de l’inscription et de la configuration des applications, suivez les méthodes décrites ci-dessous pour réduire le risque d’endommagement des applications en cas de violation de la sécurité. Pour plus d’informations, consultez Meilleures pratiques de sécurité pour l’inscription d’applications Microsoft Entra.

Prenez en compte les actions suivantes pour empêcher les violations de sécurité :

  • Définissez correctement les URI de redirection pour l’application. N’utilisez pas la même inscription d’application pour plusieurs applications.
  • Vérifiez les URI de redirection utilisés dans l’inscription d’application pour en vérifier la propriété et pour éviter les prises de contrôle de domaine. Ne créez pas l’application en tant qu’application multilocataire, sauf si vous tenez à ce qu’elle le soit. |
  • Assurez-vous que les propriétaires d’application et de principal de service sont toujours définis et gérés pour les applications inscrites dans le locataire.

Voir aussi