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

  • Article

S’applique à cette recommandation de liste de contrôle de sécurité Azure Well-Architected Framework :

SE :05 Implémentez une gestion des identités et des accès (IAM) stricte, conditionnelle et auditable pour tous les utilisateurs de charge de travail, les membres de l’équipe et les composants système. Limitez l’accès exclusivement à si nécessaire. Utilisez les normes modernes du secteur 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 pour 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 seulement 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 malveillants.

  • 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 de leur être.

Définitions 

Termes Définition
Authentification (authN) Processus qui vérifie qu’une identité est la personne ou ce qu’elle dit être.
Autorisation (AuthZ) Processus qui vérifie si une identité est autorisée à 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é, comme l’ID Microsoft Entra.
Utilisateur Une fonction de travail ou un titre qui a un ensemble de responsabilités et d’actions.
Clés prépartagées 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. Également 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, comme un employé ou un utilisateur externe.
Identité de charge de travail Identité système d’une application, d’un service, d’un script, d’un conteneur ou d’un autre composant d’une charge de travail utilisée pour s’authentifier auprès d’autres services et ressources.

Notes

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 risques d’erreurs sont également réduits. Dans cet article, le terme identité inclut 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 fréquemment améliorés en fonction des vecteurs d’attaque les plus récents en capturant des milliards de signaux sur plusieurs locataires chaque jour. Microsoft Entra ID est le fournisseur d’identité pour la plateforme cloud Azure.

Authentification

L’authentification est un processus qui vérifie les identités. L’identité de la demande est requise pour fournir une forme d’identification vérifiable. Par exemple :

  • Un nom d’utilisateur et un 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.

Dans la mesure du 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, ce que vous devez faire à l’aide des fonctionnalités fournies par votre fournisseur d’identité.

Stratégies de conception

Pour obtenir une vue holistique des besoins d’identité d’une charge de travail, vous devez cataloguer les flux, les ressources de charge de travail et les personnages, ainsi que les actions effectuées par les ressources et les personnages. 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 à l’intérieur) et les flux qui s’étendent de la charge de travail vers d’autres sources (accès à l’intérieur et à l’extérieur).

Chaque cas d’usage aura probablement son propre ensemble de contrôles que vous devez concevoir avec un état d’esprit de violation des hypothèses. En fonction des exigences d’identité du cas d’usage ou des personnages, identifiez les choix conditionnels. Évitez d’utiliser une seule 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 à l’identité. Cela permet de valider les contrôles, et vous pouvez utiliser les journaux 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 nécessiter un accès de l’extérieur. Par exemple, un opérateur qui a besoin d’un accès via le portail ou d’un accès 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 de 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 à des 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 :

Diagramme montrant comment 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 elles ont besoin :

  • Accès au plan de données. Les actions qui ont lieu dans le plan de données entraînent un transfert de données pour un accès à l’intérieur ou à l’extérieur. Par exemple, une application lisant des données d’une base de données et écrivant des données dans une base de données, récupérant des secrets ou écrivant des journaux dans un récepteur de surveillance. Au niveau du composant, les calculs qui extrayent ou poussent des images vers ou depuis un registre sont considérés comme des opérations de plan de données.

  • Accès au plan de contrôle. Les actions qui ont lieu 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 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 qu’elle n’en a besoin. 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 conduisent à des choix qui combinent l’identité, le rôle et l’étendue.

Prenons l’exemple d’une identité de charge de travail. L’application doit avoir un accès au plan de données à la base de données. Les actions de lecture et d’écriture sur la ressource de données doivent donc ê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 mauvais acteur, quel serait 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 qui est affecté à une identité. Attribuez des rôles qui autorisent uniquement l’identité à terminer la tâche, et pas plus. Lorsque les autorisations de l’utilisateur sont limitées à leurs exigences de travail, il est plus facile d’identifier les comportements suspects ou non autorisés dans le système.

Posez des questions comme celles-ci :

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

La limitation du niveau d’accès des utilisateurs, des applications ou des services 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 est suffisant pour évaluer les facteurs de risque, identifier les atténuations potentielles et faire rapport sur 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 des organization 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 de la complexité et de la confusion, car elles ne transmettent pas l’intention aux nouvelles ressources qui sont similaires. Cela peut créer une configuration héritée complexe qui est difficile à gérer et qui a un impact négatif à la fois sur 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é. Par exemple, l’accès en lecture à l’ensemble du code source et des données peut être dangereux et doit être contrôlé.

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 en fonction de vos besoins opérationnels ou d’accès aux données. Vos équipes techniques doivent avoir des conseils clairs pour implémenter des autorisations.

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

Faire des choix d’accès conditionnel

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

  • Heure. 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 obtenir plus de contrôle sur le système et les données ou utiliser cet accès pour continuer à modifier l’environnement. Limiter 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’ils 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, d’autres conditions s’appliquent. Par exemple, vous pouvez également utiliser l’appareil, le réseau et l’emplacement d’origine de l’accès pour définir des stratégies.

Utilisez des contrôles forts qui filtrent, détectent et bloquent les accès non autorisés, y compris 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 avoir besoin d’ê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 à plein temps. La différenciation claire des comptes externes facilite la prévention et la détection des attaques provenant de ces vecteurs.

Votre choix de fournisseur d’identité 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 Microsoft Entra ID. Pour plus d’informations, consultez la section Sur la facilitation Azure de cet article.

Comptes à impact critique

Les identités administratives présentent certains des risques de sécurité les plus importants, car les tâches qu’elles effectuent nécessitent un accès privilégié à un large éventail 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 à impact critique.

  • Utilisez des rôles distincts au lieu d’élever des 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 bris de verre, suivez un processus d’accès d’urgence.

  • Utilisez des protocoles d’accès modernes comme l’authentification sans mot de passe ou l’authentification multifacteur. Externalisez ces mécanismes auprès de 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 dans les environnements cloud et locaux réduit les erreurs humaines et les risques de sécurité qui en résultent. Les équipes dans les deux environnements qui gèrent des 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 le contrôle total des ressources locales, ce qui peut conduire à une compromission réussie d’un compte cloud. Évaluez votre stratégie de synchronisation en filtrant les comptes qui peuvent ê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 elles accèdent. Vérifiez que vous disposez d’un processus pour désactiver ou supprimer des identités en cas de 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, des journaux, des 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 des révisions d’accès pour vous assurer que lorsque les identités quittent le organization 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épartagées 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 lourdes, car elles introduisent des processus opérationnels.

Lorsque vous le 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 votre code d’application, vos scripts IaC, vos pipelines de déploiement ou tout 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 et l’expiration des clés.

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.

Assurer la sécurité des environnements de développement

L’ensemble du code et des scripts, des outils de pipeline et des 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é par l’automatisation et la révision par les pairs. L’accès en lecture au code source doit être limité aux rôles selon le besoin de connaître. Les référentiels de code doivent avoir un contrôle de version, et les 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 vulnérabilités les plus récentes.

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

Gérer une piste d’audit

L’un des aspects de la gestion des identités consiste à 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é et des insights sur les connexions des utilisateurs et des applications.

  • É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, des status d’appareils et des autres critères et stratégies que vous définissez.

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

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

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

Animation Azure

Nous vous recommandons de toujours utiliser 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 pour réduire le risque de supervision 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 :

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 des 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 de vos applications.

Vous pouvez rester à jour en accédant à Nouveautés de Microsoft Entra ID.

Compromis : Microsof Microsoft Entra ID est un point de défaillance unique comme n’importe quel autre service de base. Il n’existe aucune solution de contournement tant que microsoft n’a pas résolu la panne. Toutefois, l’ensemble complet de fonctionnalités de Microsoft Entra l’emporte sur le risque lié à l’utilisation de solutions personnalisées.

Azure prend en charge les protocoles ouverts comme 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 Microsoft Entra ID. 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 :

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

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

Identité de 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 Que sont les identités de charge de travail ?.

Le principal de service est également abstrait 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 la 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, consultez Services Azure qui peuvent utiliser des identités managées pour accéder à d’autres 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 Microsoft Entra l’accès conditionnel en configurant une stratégie d’accès 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 de l’accès de groupe

Au lieu d’accorder des autorisations à des utilisateurs spécifiques, attribuez l’accès aux groupes dans Microsoft Entra ID. S’il n’existe pas de groupe, 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 vous assurer que les autorisations sont à jour. Vous pouvez également utiliser le groupe à d’autres fins, telles que les listes de diffusion.

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

Détection de menaces

Protection Microsoft Entra ID peuvent vous aider à détecter, examiner et corriger les risques liés à l’identité. Pour plus d’informations, consultez Qu’est-ce qu’Identity Protection ?.

La détection des menaces peut prendre la forme de réagir à une alerte d’activité suspecte ou de rechercher de manière proactive des é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 Microsoft Entra ID qui disposent de privilèges élevés dans votre annuaire Active Directory existant. Cette synchronisation étant bloquée dans la configuration par défaut Microsoft Entra Connect Sync, il vous suffit de confirmer que vous n’avez pas personnalisé cette configuration.

Pour plus d’informations sur le filtrage dans Microsoft Entra ID, 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 des données utilisé pour stocker les journaux. Cela peut également avoir 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.

Diagramme montrant une implémentation d’identité.

Composants d’identité

  • Identités gérées par le système. Microsoft Entra ID permet d’accéder aux plans de données de service qui ne font pas face aux utilisateurs, comme 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 les agents de build.

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

La sécurité des secrets prépartagés est essentielle pour toutes les applications. 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 garantir 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 permet de s’assurer que les composants d’identité comme Key Vault utilisent RBAC au lieu des 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 le code des composants de code.

Liste de contrôle de sécurité

Reportez-vous à l’ensemble complet de recommandations.

Liste de contrôle de sécurité