Recommandations la gestion des identités et des accès

S’applique à cette recommandation de liste de contrôle azure Well-Architected Framework Security :

SE :05

Implémentez des identités et des accès stricts, conditionnels et auditables (IAM) sur tous les utilisateurs de la charge de travail, les membres de l’équipe et les composants système. Limitez l’accès exclusivement au besoin. Utilisez des normes industrielles modernes pour toutes les implémentations d’authentification et d’autorisation. Limitez et auditez rigoureusement l’accès qui n’est pas basé sur l’identité.

Ce guide décrit les recommandations relatives à l’authentification et à l’autorisation des identités qui tentent d’accéder à vos ressources de charge de travail.

Du point de vue du contrôle technique, l’identité est toujours le périmètre principal. Cette étendue n’inclut pas uniquement les bords de votre charge de travail. Il inclut également des composants individuels qui se trouvent à l’intérieur de votre charge de travail. Les identités classiques sont les suivantes :

• Les humains. Utilisateurs d’applications, administrateurs, opérateurs, auditeurs et acteurs incorrects.

• Systèmes. Identités de charge de travail, identités managées, clés API, principaux de service et ressources Azure.

• Anonyme. Entités qui n’ont fourni aucune preuve sur la personne qu’ils sont.

Définitions 

Petits caractères	Définition
Authentification (authN)	Processus qui vérifie qu’une identité est qui ou ce qu’elle dit.
Autorisation (AuthZ)	Processus qui vérifie si une identité a l’autorisation d’effectuer une action demandée.
Accès conditionnel	Ensemble de règles qui autorise les actions basées sur des critères spécifiés.
Fournisseur d’identité	Un fournisseur d’identité, tel que Microsoft Entra ID.
Utilisateur	Fonction de travail ou titre qui a un ensemble de responsabilités et d’actions.
Clés prépartage	Type de secret partagé entre un fournisseur et un consommateur et utilisé par le biais d’un mécanisme sécurisé et convenu.
Identité des ressources	Identité définie pour les ressources cloud gérées par la plateforme.
Rôle	Ensemble d’autorisations qui définissent ce qu’un utilisateur ou un groupe peut faire.
Étendue	Différents niveaux de hiérarchie organisationnelle où un rôle est autorisé à fonctionner. Il s’agit également d’un groupe de fonctionnalités dans un système.
Principal de sécurité	Identité qui fournit des autorisations. Il peut s’agir d’un utilisateur, d’un groupe ou d’un principal de service. Tous les membres du groupe obtiennent le même niveau d’accès.
Identité de l’utilisateur	Identité d’une personne, telle qu’un employé ou un utilisateur externe.
Identité de la charge de travail	Identité système pour une application, un service, un script, un conteneur ou un autre composant d’une charge de travail utilisée pour s’authentifier auprès d’autres services et ressources.

Remarque

Une identité peut être regroupée avec d’autres identités similaires sous un parent appelé principal de sécurité. Un groupe de sécurité est un exemple de principal de sécurité. Cette relation hiérarchique simplifie la maintenance et améliore la cohérence. Étant donné que les attributs d’identité ne sont pas gérés au niveau individuel, les chances d’erreurs sont également réduites. Dans cet article, l’identité de terme est incluse dans les principaux de sécurité.

Rôle d’un fournisseur d’identité

Un fournisseur d’identité (IdP) est un service hébergé dans le cloud qui stocke et gère les utilisateurs en tant qu’identités numériques.

Tirez parti des fonctionnalités fournies par un fournisseur d’identité approuvé pour votre gestion des identités et des accès. N’implémentez pas de systèmes personnalisés pour remplacer un fournisseur d’identité. Les systèmes idP sont améliorés fréquemment en fonction des derniers vecteurs d’attaque en capturant des milliards de signaux sur plusieurs locataires chaque jour. L’ID Microsoft Entra est le fournisseur d’identité pour la plateforme cloud Azure.

Authentification

L’authentification est un processus qui vérifie les identités. L’identité demandée est nécessaire pour fournir une forme d’identification vérifiable. Par exemple :

• Nom d’utilisateur et mot de passe.

• Un secret prépartagé, comme une clé API qui accorde l’accès.

• Utilisez un jeton de signature d’accès partagé (SAP).

• Certificat utilisé dans l’authentification mutuelle TLS.

Autant que possible, le processus de vérification doit être géré par votre fournisseur d’identité.

Autorisation

L’autorisation est un processus qui autorise ou refuse les actions demandées par l’identité vérifiée. L’action peut être d’ordre opérationnel ou liée à la gestion des ressources.

L’autorisation nécessite que vous affectiez des autorisations aux identités, que vous devez effectuer à l’aide des fonctionnalités fournies par votre fournisseur d’identité.

Stratégies de conception

Pour obtenir une vue holistique des besoins d’identité pour une charge de travail, vous devez cataloguer les flux, les ressources de charge de travail et les personnages, et les actions que les ressources et les personnages effectueront. Votre stratégie doit couvrir tous les cas d’usage qui gèrent les flux qui atteignent la charge de travail ou ses composants (accès externe) et les flux qui accèdent de la charge de travail à d’autres sources (accès à l’intérieur) .

Chaque cas d’usage aura probablement son propre ensemble de contrôles que vous devez concevoir avec un état d’esprit de pré-violation. En fonction des exigences d’identité du cas d’usage ou des personnages, identifiez les choix conditionnels. Évitez d’utiliser une solution pour tous les cas d’usage. À l’inverse, les contrôles ne doivent pas être si granulaires que vous introduisez une surcharge de gestion inutile.

Vous devez enregistrer la piste d’accès aux identités. Cela permet de valider les contrôles, et vous pouvez utiliser les journaux d’activité pour les audits de conformité.

Déterminer toutes les identités pour l’authentification

• Accès de l’extérieur. Votre conception d’identité doit authentifier tous les utilisateurs qui accèdent à la charge de travail à diverses fins. Par exemple, un utilisateur final qui accède à l’application en appelant des API.

  À un niveau granulaire, les composants de la charge de travail peuvent également avoir besoin d’un accès extérieur. Par exemple, un opérateur qui a besoin d’accéder via le portail ou d’accéder au calcul pour exécuter des commandes.

  Les deux sont des exemples d’identités utilisateur qui ont des personnages différents.

• Accès de l’intérieur. Votre application doit accéder à d’autres ressources. Par exemple, la lecture ou l’écriture dans la plateforme de données, la récupération des secrets à partir du magasin de secrets et la journalisation des données de télémétrie dans les services de surveillance. Il peut même avoir besoin d’accéder aux services tiers. Ces besoins d’accès nécessitent une identité de charge de travail, ce qui permet à l’application de s’authentifier auprès des autres ressources.

  Le concept s’applique au niveau du composant. Dans l’exemple suivant, le conteneur peut avoir besoin d’accéder aux pipelines de déploiement pour obtenir sa configuration. Ces besoins d’accès nécessitent une identité de ressource.

Toutes ces identités doivent être authentifiées par votre fournisseur d’identité.

Voici un exemple de la façon dont l’identité peut être implémentée dans une architecture :

Déterminer les actions pour l’autorisation

Ensuite, vous devez savoir ce que chaque identité authentifiée tente de faire afin que ces actions puissent être autorisées. Les actions peuvent être divisées par le type d’accès dont ils ont besoin :

• Accès au plan de données. Les actions qui se produisent dans le plan de données entraînent le transfert de données pour l’accès à l’intérieur ou à l’extérieur. Par exemple, une application lisant des données à partir d’une base de données et en écrivant des données dans une base de données, en récupérant des secrets ou en écrivant des journaux dans un récepteur de surveillance. Au niveau du composant, le calcul qui extrait ou envoie (push) des images vers ou à partir d’un registre est considéré comme des opérations de plan de données.

• Contrôle de l’accès au plan. Les actions qui se produisent dans le plan de contrôle entraînent la création, la modification ou la suppression d’une ressource Azure. Par exemple, les modifications apportées aux propriétés de ressource.

Les applications ciblent généralement les opérations de plan de données, tandis que les opérations accèdent souvent aux plans de contrôle et de données. Pour identifier les besoins d’autorisation, notez les actions opérationnelles qui peuvent être effectuées sur la ressource. Pour plus d’informations sur les actions autorisées pour chaque ressource, consultez les opérations du fournisseur de ressources Azure.

Fournir une autorisation basée sur les rôles

En fonction de la responsabilité de chaque identité, autorisez les actions qui doivent être autorisées. Une identité ne doit pas être autorisée à faire plus que nécessaire. Avant de définir des règles d’autorisation, vous devez comprendre clairement qui ou ce qui effectue des demandes, ce que ce rôle est autorisé à faire et dans quelle mesure il peut le faire. Ces facteurs entraînent des choix qui combinent l’identité, le rôle et l’étendue.

Considérez une identité de charge de travail comme exemple. L’application doit avoir un accès au plan de données à la base de données. Par conséquent, les actions de lecture et d’écriture dans la ressource de données doivent être autorisées. Toutefois, l’application a-t-elle besoin d’un accès au plan de contrôle au magasin de secrets ? Si l’identité de la charge de travail est compromise par un acteur incorrect, quel est l’impact sur le système en termes de confidentialité, d’intégrité et de disponibilité ?

Attribution de rôle

Un rôle est un ensemble d’autorisations affectées à une identité. Attribuez des rôles qui autorisent uniquement l’identité à effectuer la tâche, et pas plus. Lorsque les autorisations de l’utilisateur sont limitées à ses exigences de travail, il est plus facile d’identifier le comportement suspect ou non autorisé dans le système.

Posez des questions telles que celles-ci :

• L’accès en lecture seule suffit-il ?
• L’identité a-t-elle besoin d’autorisations pour supprimer des ressources ?

Limiter le niveau d’accès que les utilisateurs, les applications ou les services doivent avoir aux ressources Azure réduit la surface d’attaque potentielle. Si vous accordez uniquement les autorisations minimales requises pour effectuer des tâches spécifiques, le risque d’une attaque réussie ou d’un accès non autorisé est considérablement réduit. Par exemple, les équipes de sécurité ont uniquement besoin d’un accès en lecture seule aux attributs de sécurité pour tous les environnements techniques. Ce niveau suffit pour évaluer les facteurs de risque, identifier les atténuations potentielles et signaler les risques.

Il existe des scénarios dans lesquels les utilisateurs ont besoin d’un accès plus grand en raison de la structure organisationnelle et de l’organisation d’équipe. Il peut y avoir un chevauchement entre différents rôles, ou des utilisateurs uniques peuvent effectuer plusieurs rôles standard. Dans ce cas, utilisez plusieurs attributions de rôles basées sur la fonction métier au lieu de créer un rôle personnalisé pour chacun de ces utilisateurs. Cela facilite la gestion des rôles.

Évitez les autorisations qui référencent des ressources ou des utilisateurs spécifiques. Les autorisations granulaires et personnalisées créent une complexité et une confusion, car elles ne transmettent pas l’intention de nouvelles ressources similaires. Cela peut créer une configuration héritée complexe difficile à maintenir et à affecter négativement la sécurité et la fiabilité.

Compromis : une approche de contrôle d’accès granulaire permet de mieux auditer et surveiller les activités des utilisateurs.

Un rôle a également une étendue associée. Le rôle peut fonctionner au niveau du groupe d’administration, de l’abonnement, du groupe de ressources ou de l’étendue de ressource autorisé, ou dans une autre étendue personnalisée. Même si l’identité dispose d’un ensemble limité d’autorisations, l’élargissement de l’étendue pour inclure les ressources qui se trouvent en dehors de la fonction de travail de l’identité est risquée. Par exemple, l’accès en lecture à tout le code source et les données peuvent être dangereux et doivent être contrôlés.

Vous attribuez des rôles à des identités à l’aide du contrôle d’accès en fonction du rôle (RBAC). Utilisez toujours le RBAC fourni par le fournisseur d’identité pour tirer parti des fonctionnalités qui vous permettent d’appliquer le contrôle d’accès de manière cohérente et de le révoquer rigoureusement.

Utilisez des rôles intégrés. Ils sont conçus pour couvrir la plupart des cas d’usage. Les rôles personnalisés sont puissants et parfois utiles, mais vous devez les réserver pour les scénarios dans lesquels les rôles intégrés ne fonctionnent pas. La personnalisation entraîne une complexité qui augmente la confusion et rend l’automatisation plus complexe, difficile et fragile. Ces facteurs ont un impact négatif sur la sécurité.

Accordez des rôles qui commencent par des privilèges minimum et ajoutez davantage de données en fonction de vos besoins d’accès opérationnel ou de données. Vos équipes techniques doivent disposer d’instructions claires pour implémenter des autorisations.

Si vous souhaitez un contrôle précis sur RBAC, ajoutez des conditions à l’attribution de rôle en fonction du contexte, telles que les actions et les attributs.

Faire des choix d’accès conditionnel

Ne donnez pas à toutes les identités le même niveau d’accès. Basez vos décisions sur deux facteurs principaux :

• Durée. Durée pendant laquelle l’identité peut accéder à votre environnement.

• Privilège. Niveau d’autorisations.

Ces facteurs ne s’excluent pas mutuellement. Une identité compromise qui a plus de privilèges et une durée d’accès illimitée peut prendre plus de contrôle sur le système et les données ou utiliser cet accès pour continuer à modifier l’environnement. Limitez ces facteurs d’accès à la fois comme mesure préventive et pour contrôler le rayon d’explosion.

• Les approches juste-à-temps (JIT) fournissent les privilèges requis uniquement lorsqu’elles sont nécessaires.

• Just Enough Access (JEA) fournit uniquement les privilèges requis.

Bien que le temps et le privilège soient les principaux facteurs, il existe d’autres conditions qui s’appliquent. Par exemple, vous pouvez également utiliser l’appareil, le réseau et l’emplacement à partir duquel l’accès provient de définir des stratégies.

Utilisez des contrôles forts qui filtrent, détectent et bloquent l’accès non autorisé, notamment les paramètres tels que l’identité et l’emplacement de l’utilisateur, l’intégrité de l’appareil, le contexte de charge de travail, la classification des données et les anomalies.

Par exemple, votre charge de travail peut être accessible par des identités tierces telles que des fournisseurs, des partenaires et des clients. Ils ont besoin du niveau d’accès approprié plutôt que des autorisations par défaut que vous fournissez aux employés à temps plein. La différenciation claire des comptes externes facilite la prévention et la détection des attaques provenant de ces vecteurs.

Votre choix d’IdP doit être en mesure de fournir cette différenciation, de fournir des fonctionnalités intégrées qui accordent des autorisations basées sur les privilèges minimum et de fournir des informations intégrées sur les menaces. Cela inclut la surveillance des demandes d’accès et des connexions. Le fournisseur d’identité Azure est l’ID Microsoft Entra. Pour plus d’informations, consultez la section de facilitation Azure de cet article.

Protéger les comptes d’impact critique

Les identités administratives présentent certains des risques de sécurité les plus importants, car les tâches qu’ils effectuent nécessitent un accès privilégié à un large ensemble de ces systèmes et applications. La compromission ou l’utilisation abusive peut avoir un effet néfaste sur votre entreprise et ses systèmes d’information. La sécurité de l’administration est l’un des domaines de sécurité les plus critiques.

La protection de l’accès privilégié contre ses adversaires déterminés vous oblige à adopter une approche complète et réfléchie pour isoler ces systèmes des risques. Voici quelques stratégies :

• Réduisez le nombre de comptes d’impact critique.

• Utilisez des rôles distincts au lieu d’élever les privilèges pour les identités existantes.

• Évitez l’accès permanent ou permanent à l’aide des fonctionnalités JIT de votre fournisseur d’identité. Pour les situations de verre d’arrêt, suivez un processus d’accès d’urgence.

• Utilisez des protocoles d’accès modernes tels que l’authentification sans mot de passe ou l’authentification multifacteur. Externalisez ces mécanismes à votre fournisseur d’identité.

• Appliquez des attributs de sécurité clés à l’aide de stratégies d’accès conditionnel.

• Désaffectez les comptes d’administration qui ne sont pas utilisés.

Utilisez une identité unique dans les environnements et associez une identité unique à l’utilisateur ou au principal. La cohérence des identités entre les environnements cloud et locaux réduit les erreurs humaines et les risques de sécurité résultants. Les équipes des deux environnements qui gèrent les ressources ont besoin d’une source cohérente et faisant autorité pour répondre aux garanties de sécurité. Collaborez avec votre équipe d’identité centrale pour vous assurer que les identités dans les environnements hybrides sont synchronisées.

Risque : il existe un risque associé à la synchronisation des identités à privilèges élevés. Un attaquant peut obtenir un contrôle total des ressources locales, ce qui peut entraîner une compromission réussie d’un compte cloud. Évaluez votre stratégie de synchronisation en filtrant les comptes pouvant être ajoutés à la surface d’attaque.

Établir des processus pour gérer le cycle de vie des identités

L’accès aux identités ne doit pas durer plus longtemps que les ressources auxquelles les identités accèdent. Vérifiez que vous disposez d’un processus de désactivation ou de suppression d’identités lorsqu’il existe des modifications dans la structure d’équipe ou les composants logiciels.

Ces conseils s’appliquent au contrôle de code source, aux données, aux plans de contrôle, aux utilisateurs de charge de travail, à l’infrastructure, aux outils, à la surveillance des données, aux journaux, aux métriques et à d’autres entités.

Établissez un processus de gouvernance des identités pour gérer le cycle de vie des identités numériques, des utilisateurs à privilèges élevés, des utilisateurs externes/invités et des utilisateurs de charge de travail. Implémentez les révisions d’accès pour vous assurer que lorsque les identités quittent l’organisation ou l’équipe, leurs autorisations de charge de travail sont supprimées.

Protéger les secrets non basés sur l’identité

Les secrets d’application tels que les clés prépartage doivent être considérés comme des points vulnérables dans le système. Dans la communication bidirectionnelle, si le fournisseur ou le consommateur est compromis, des risques de sécurité importants peuvent être introduits. Ces clés peuvent également être fastidieuses, car elles introduisent des processus opérationnels.

Lorsque vous pouvez, évitez d’utiliser des secrets et envisagez d’utiliser l’authentification basée sur l’identité pour l’accès utilisateur à l’application elle-même, pas seulement à ses ressources.

La liste suivante fournit un résumé des conseils. Pour plus d’informations, consultez Recommandations pour les secrets d’application.

• Traitez ces secrets comme des entités qui peuvent être extraites dynamiquement d’un magasin de secrets. Ils ne doivent pas être codés en dur dans le code de votre application, les scripts IaC, les pipelines de déploiement ou dans un autre artefact.

• Assurez-vous que vous avez la possibilité de révoquer des secrets.

• Appliquez des pratiques opérationnelles qui gèrent des tâches telles que la rotation des clés et l’expiration.

Pour plus d’informations sur les stratégies de rotation, consultez Automatiser la rotation d’un secret pour les ressources qui ont deux ensembles d’informations d’identification d’authentification et tutoriel : Mise à jour de la fréquence de rotation automatique des certificats dans Key Vault.

Sécuriser les environnements de développement

Tous les systèmes de code et de script, les outils de pipeline et les systèmes de contrôle de code source doivent être considérés comme des ressources de charge de travail. L’accès aux écritures doit être contrôlé avec l’automatisation et la révision des pairs. L’accès en lecture au code source doit être limité aux rôles selon un besoin de connaissance. Les référentiels de code doivent avoir un contrôle de version et des révisions de code de sécurité par les pairs doivent être une pratique régulière intégrée au cycle de vie du développement. Vous devez disposer d’un processus qui analyse régulièrement les ressources et identifie les dernières vulnérabilités.

Utilisez des identités de charge de travail pour accorder l’accès aux ressources à partir d’environnements de déploiement, tels que GitHub.

Maintenir une piste d’audit

L’un des aspects de la gestion des identités est de s’assurer que le système est auditable. Les audits vérifient si les stratégies de violation des hypothèses sont efficaces. La maintenance d’une piste d’audit vous aide à :

• Vérifiez que l’identité est authentifiée avec une authentification forte. Toute action doit être traçable pour empêcher les attaques de répudiation.

• Détectez les protocoles d’authentification faibles ou manquants et obtenez une visibilité sur les connexions utilisateur et application.

• Évaluez l’accès des identités à la charge de travail en fonction des exigences de sécurité et de conformité, et tenez compte du risque de compte d’utilisateur, de l’état de l’appareil et d’autres critères et stratégies que vous définissez.

• Suivez la progression ou l’écart par rapport aux exigences de conformité.

La plupart des ressources disposent d’un accès au plan de données. Vous devez connaître les identités qui accèdent aux ressources et aux actions qu’ils effectuent. Vous pouvez utiliser ces informations pour les diagnostics de sécurité.

Pour plus d’informations, consultez Recommandations sur la surveillance de la sécurité et l’analyse des menaces.

Facilitation Azure

Nous vous recommandons d’utiliser toujours des protocoles d’authentification modernes qui prennent en compte tous les points de données disponibles et utilisent l’accès conditionnel. Microsoft Entra ID fournit la gestion des identités et des accès dans Azure. Il couvre le plan de gestion d’Azure et est intégré aux plans de données de la plupart des services Azure. Microsoft Entra ID est le locataire associé à l’abonnement de charge de travail. Il suit et gère les identités et leurs autorisations autorisées et simplifie la gestion globale afin de réduire le risque de surveillance ou d’erreur humaine.

Ces fonctionnalités s’intègrent en mode natif dans le même modèle d’identité et d’autorisation Microsoft Entra pour les segments d’utilisateur :

• Microsoft Entra ID. Employés et ressources d’entreprise.

• ID externe Microsoft Entra. Partenaires.

• Azure AD B2C. Clientèle.

• Liste de compatibilité de fédération Microsoft Entra. Solutions de fédération tierces.

Vous pouvez utiliser l’ID Microsoft Entra pour l’authentification et l’autorisation d’applications personnalisées via la bibliothèque d’authentification Microsoft (MSAL) ou les fonctionnalités de plateforme, telles que l’authentification pour les applications web. Il couvre le plan de gestion d’Azure, les plans de données de la plupart des services Azure et les fonctionnalités d’intégration pour vos applications.

Vous pouvez rester à jour en visitant Les nouveautés de Microsoft Entra ID.

Compromis : Microsof Microsoft Entra ID est un point de défaillance unique comme tout autre service de base. Il n’existe aucune solution de contournement tant que la panne n’est pas résolue par Microsoft. Toutefois, l’ensemble de fonctionnalités riche de Microsoft Entra dépasse le risque d’utilisation de solutions personnalisées.

support Azure ouvre des protocoles tels que OAuth2 et OpenID Connect. Nous vous recommandons d’utiliser ces mécanismes d’authentification et d’autorisation standard au lieu de concevoir vos propres flux.

Azure RBAC

Azure RBAC représente les principaux de sécurité dans l’ID Microsoft Entra. Toutes les attributions de rôles sont effectuées via Azure RBAC. Tirez parti des rôles intégrés qui fournissent la plupart des autorisations dont vous avez besoin. Pour plus d’informations, consultez Rôles intégrés Microsoft Entra.

Voici quelques cas d’usage :

• En affectant des utilisateurs à des rôles, vous pouvez contrôler l’accès aux ressources Azure. Pour plus d’informations, consultez Vue d’ensemble du contrôle d’accès en fonction du rôle dans l’ID Microsoft Entra.

• Vous pouvez utiliser Privileged Identity Management pour fournir une activation de rôle basée sur le temps et basée sur l’approbation pour les rôles associés à des identités à impact élevé. Pour plus d’informations, consultez Qu’est-ce que Privileged Identity Management ?.

Pour plus d’informations sur RBAC, consultez les meilleures pratiques pour Azure RBAC.

Pour plus d’informations sur les contrôles basés sur des attributs, consultez Qu’est-ce qu’Azure ABAC ?.

Identité de la charge de travail

Microsoft Entra ID peut gérer l’identité de votre application. Le principal de service associé à l’application peut dicter son étendue d’accès.

Pour plus d’informations, consultez Qu’est-ce que les identités de charge de travail ?.

Le principal de service est également extrait lorsque vous utilisez une identité managée. L’avantage est qu’Azure gère toutes les informations d’identification de l’application.

Tous les services ne prennent pas en charge les identités managées. Si vous ne pouvez pas utiliser d’identités managées, vous pouvez utiliser des principaux de service. Toutefois, l’utilisation de principaux de service augmente votre surcharge de gestion. Pour plus d’informations, consultez Que sont les identités managées pour les ressources Azure ?.

Identité des ressources

Le concept d’identités managées peut être étendu aux ressources Azure. Les ressources Azure peuvent utiliser des identités managées pour s’authentifier auprès d’autres services qui prennent en charge l’authentification Microsoft Entra. Pour plus d’informations, veuillez consulter la rubrique Azure services that can use managed identities to access other services.

Stratégies d’accès conditionnel

L’accès conditionnel décrit votre stratégie pour une décision d’accès. Pour utiliser l’accès conditionnel, vous devez comprendre les restrictions requises pour le cas d’usage. Configurez l’accès conditionnel Microsoft Entra en configurant une stratégie d’accès pour cela en fonction de vos besoins opérationnels.

Pour plus d’informations, consultez Accès conditionnel : Utilisateurs, groupes et identités de charge de travail.

Gestion des accès au groupe

Au lieu d’accorder des autorisations à des utilisateurs spécifiques, attribuez l’accès à des groupes dans Microsoft Entra ID. Si un groupe n’existe pas, collaborez avec votre équipe d’identité pour en créer un. Vous pouvez ensuite ajouter et supprimer des membres de groupe en dehors d’Azure et vérifier que les autorisations sont actuelles. Vous pouvez également utiliser le groupe à d’autres fins, comme les listes de diffusion.

Pour plus d’informations, consultez Contrôle d’accès sécurisé à l’aide de groupes dans Microsoft Entra ID.

Détection de menaces

Protection des ID Microsoft Entra pouvez vous aider à détecter, examiner et corriger les risques basés sur l’identité. Pour plus d’informations, consultez Qu’est-ce que Identity Protection ?.

La détection des menaces peut prendre la forme d’une réaction à une alerte d’activité suspecte ou à la recherche proactive d’événements anormaux dans les journaux d’activité. L’analyse du comportement des utilisateurs et des entités (UEBA) dans Microsoft Sentinel facilite la détection des activités suspectes. Pour plus d’informations, consultez Identifier les menaces avancées avec UEBA.

Systèmes hybrides

Sur Azure, ne synchronisez pas les comptes avec l’ID Microsoft Entra qui disposent de privilèges élevés dans votre annuaire Active Directory existant. Cette synchronisation est bloquée dans la configuration microsoft Entra Connect Sync par défaut. Vous devez donc vérifier que vous n’avez pas personnalisé cette configuration.

Pour plus d’informations sur le filtrage dans l’ID Microsoft Entra, consultez Microsoft Entra Connect Sync : Configurer le filtrage.

Journalisation des identités

Activez les paramètres de diagnostic sur les ressources Azure pour émettre des informations que vous pouvez utiliser comme piste d’audit. Les informations de diagnostic indiquent quelles identités tentent d’accéder aux ressources et au résultat de ces tentatives. Les journaux collectés sont envoyés à Azure Monitor.

Compromis : la journalisation entraîne des coûts en raison du stockage de données utilisé pour stocker les journaux. Cela peut également entraîner un impact sur les performances, en particulier sur le code et sur les solutions de journalisation que vous ajoutez à l’application.

Exemple

L’exemple suivant montre une implémentation d’identité. Différents types d’identités sont utilisés ensemble pour fournir les niveaux d’accès requis.

Composants d’identité

• Identités gérées par le système. Microsoft Entra ID fournit l’accès aux plans de données de service qui ne font pas face aux utilisateurs, tels qu’Azure Key Vault et les magasins de données. Ces identités contrôlent également l’accès, via RBAC, au plan de gestion Azure pour les composants de charge de travail, les agents de déploiement et les membres de l’équipe.

• Identités de charge de travail. Les services d’application du cluster Azure Kubernetes Service (AKS) utilisent des identités de charge de travail pour s’authentifier auprès d’autres composants de la solution.

• Les identités managées. Les composants système du rôle client utilisent des identités gérées par le système, y compris des agents de build.

• Identités humaines. L’authentification de l’utilisateur et de l’opérateur est déléguée à l’ID Microsoft Entra ou à l’ID Microsoft Entra (natif, B2B ou B2C).

La sécurité des secrets prépartagés est essentielle pour n’importe quelle application. Azure Key Vault fournit un mécanisme de stockage sécurisé pour ces secrets, notamment Redis et les secrets tiers.

Un mécanisme de rotation est utilisé pour vous assurer que les secrets ne sont pas compromis. Les jetons pour l’implémentation Plateforme d’identités Microsoft d’OAuth 2 et OpenID Connect sont utilisés pour authentifier les utilisateurs.

Azure Policy est utilisé pour s’assurer que les composants d’identité tels que Key Vault utilisent RBAC au lieu de stratégies d’accès. JIT et JEA fournissent des autorisations permanentes traditionnelles pour les opérateurs humains.

Les journaux d’accès sont activés sur tous les composants via Diagnostics Azure ou via du code pour les composants de code.

Liens connexes

• Tutoriel : Automatiser la rotation d’un secret pour les ressources qui ont deux ensembles d’informations d’identification d’authentification
• Tutoriel : Mise à jour de la fréquence de rotation automatique des certificats dans Key Vault
• Nouveautés de Microsoft Entra ID ?
• Rôles intégrés dans Microsoft Entra
• Vue d’ensemble du contrôle d’accès en fonction du rôle dans Microsoft Entra ID
• Que sont les identités de la charge de travail ?
• Que sont les identités managées pour les ressources Azure ?
• Accès conditionnel : Utilisateurs, groupes et identités de charge de travail
• Synchronisation Microsoft Entra Connect : configurer le filtrage

Liste de contrôle de sécurité

Reportez-vous à l’ensemble complet de recommandations.

Liste de contrôle de sécurité