Gestion de l’identité et des accès dans les zones de déploiement

Une fois que vous avez identifié votre architecture d’identité, vous devez gérer l’autorisation et l’accès pour les ressources dans les zones de déploiement de l’application et de la plate-forme. Considérez à quelles ressources chaque principal authentifié a accès et a besoin d’accès, et comment atténuer le risque d’accès non autorisé à vos ressources. Pour plus d’informations, veuillez consulter la conception de l’architecture d’identité.

Vue d’ensemble

La conception de la gestion de l’identité et des accès fournit des orientations pour vous aider à mettre en œuvre le modèle d’accès d’entreprise dans Azure et à mettre en œuvre et sécuriser les plans de contrôle. Lorsque vous incorporez le principe de conception de la démocratisation de l’abonnement, votre équipe d’application peut gérer ses propres charges de travail dans les garde-corps de politique définis par l’équipe de la plate-forme. Cette approche suit également le principe de gouvernance pilotée par les politiques.

L’équipe de la plate-forme est responsable de la création de nouvelles zones de déploiement d’application ou d’abonnements. Lorsqu’elle crée une zone de déploiement pour un propriétaire d’application, l’équipe de la plate-forme doit la configurer avec les contrôles d’accès appropriés afin que le propriétaire de l’application puisse gérer ses propres ressources. Le propriétaire de l’application devrait être capable de créer et de gérer des utilisateurs et des groupes au sein de Microsoft Azure Active Directory et d’attribuer des rôles à ces utilisateurs et groupes. Le propriétaire de l’application peut ensuite gérer l’accès à ses propres ressources et déléguer l’accès à d’autres utilisateurs et groupes au besoin. La zone de déploiement devrait également avoir une connectivité réseau facultative vers les Services de domaine Active Directory (AD DS) ou les Services de domaine Microsoft dans l’abonnement de la plate-forme d’identité Microsoft, en fonction des besoins de l’application.

Utilisez le contrôle d’accès basé sur les rôles (RBAC) Azure pour gérer l’accès administratif aux ressources Azure. Déterminez si les utilisateurs nécessitent des autorisations sur un périmètre restreint, tel qu’un administrateur pour une seule application, ou un périmètre large, tel qu’un administrateur réseau pour plusieurs charges de travail d’application. Dans les deux cas, suivez le principe de l’accès juste-à-temps et assurez-vous que l’utilisateur a seulement les rôles nécessaires pour ses activités normales. Utilisez des rôles personnalisés et le Privileged Identity Management (PIM) de Microsoft Entra au besoin pour imposer l’accès « just-in-time » (JIT). Bien que l’équipe de la plate-forme soit responsable des fondements de la gestion de l’identité et des accès, les équipes de la plate-forme et de l’application sont des consommateurs du service et doivent suivre les mêmes principes.

La gestion de l’identité et des accès est importante pour la séparation réussie d’une zone de déploiement d’une autre et l’isolation des charges de travail au sein d’une organisation. Il s’agit d’un domaine de conception critique pour les zones de déploiement de la plate-forme et de l’application.

Si votre organisation utilise un processus de distribution d’abonnements, vous pouvez automatiser bon nombre des configurations d’identité et d’accès pour les zones de déploiement d’application. Mettez en œuvre la distribution d’abonnements pour aider à normaliser la création de zones de déploiement et permettre aux équipes d’application de gérer leurs propres ressources.

Considérations sur la conception

Certaines organisations partagent des services entre plusieurs applications. Il peut par exemple s'agir d'un service d'intégration centralisé utilisé par plusieurs applications indépendantes. Dans ce scénario, il faut déterminer quels services sont gérés de manière centralisée et lesquels sont confiés aux équipes chargées des applications, et comprendre où les limites de sécurité doivent être appliquées. Le fait de donner aux équipes d'application un accès administratif au service partagé peut s'avérer utile pour la productivité des développeurs, mais risque de leur accorder un accès plus étendu qu'il n'est nécessaire.

La gestion des ressources d’application qui ne franchit pas les limites de sécurité peut être déléguée aux équipes d’applications. Envisagez de déléguer d’autres aspects requis pour assurer la sécurité et la conformité. Le fait de permettre aux utilisateurs d’approvisionner des ressources dans un environnement géré en toute sécurité permet aux organisations de tirer parti de la nature agile du cloud tout en prévenant la violation de toute limite de sécurité ou de gouvernance critique.

RBAC

Comprendre la différence entre les rôles Microsoft Entra ID et les rôles RBAC Azure.

• Les rôles Microsoft Entra ID contrôlent les privilèges administratifs pour les services à l’échelle des locataires comme Microsoft Entra ID, ainsi que d’autres services Microsoft tels que Teams, Exchange Online et Intune.

• Les rôles RBAC Azure contrôlent les privilèges administratifs pour les ressources Azure telles que les machines virtuelles, les abonnements et les groupes de ressources.

• Les rôles Azure RBAC Propriétaire et Administrateur d’accès Utilisateur peuvent modifier les affectations de rôle sur les ressources Azure. Par défaut, le rôle d’administrateur global Microsoft ne dispose pas de l’autorisation de gérer l’accès aux ressources Azure. Elle doit être activée de manière explicite. Pour plus d’informations, consultez Élever l’accès pour gérer tous les abonnements et groupes d’administration Azure.

Le diagramme suivant montre la relation entre les rôles d’identité Microsoft et les rôles RBAC Azure:

• Vous pouvez créer des groupes pouvant être affectés par rôle et attribuer des rôles d’identité Microsoft aux groupes si vous définissez la propriété isAssignableToRole comme true. Seuls les groupes ayant cette propriété paramétrée sont protégés. Les seuls rôles qui peuvent modifier l’appartenance à un groupe sont les Administrateurs généraux, les Administrateurs de rôle privilégié ou le propriétaire du groupe.

• Seuls certains rôles peuvent réinitialiser le mot de passe ou les paramètres d’authentification multi-facteur (MFA) pour un autre administrateur. Cette restriction empêche les administrateurs non autorisés de réinitialiser les informations d’identification d’un compte plus privilégié pour obtenir davantage d’autorisations.

• Si les rôles intégrés Azure ne répondent pas aux besoins spécifiques de votre organisation, vous pouvez créer vos propres rôles personnalisés. À l’instar des rôles intégrés, vous pouvez attribuer des rôles personnalisés aux utilisateurs, groupes et principaux de service aux niveaux du locataire, du groupe de gestion, de l’abonnement et du groupe de ressources. Cherchez à utiliser les rôles intégrés Azure lorsque c’est possible, et créez uniquement des rôles personnalisés lorsque cela est nécessaire.

• Lorsque vous concevez votre stratégie de contrôle d’accès, soyez conscients des limites de service pour les rôles, des affectations de rôle et ses rôles personnalisés.

• Certains rôles Azure RBAC prennent en charge le contrôle d’accès basé sur les attributs (ABAC) ou les conditions d’attribution de rôle. Lorsque vous utilisez des conditions, les administrateurs peuvent attribuer dynamiquement des rôles en fonction des attributs de la ressource. Par exemple, vous pouvez attribuer le rôle de contributeur aux données du blob de stockage mais uniquement pour les blobs qui ont un tag d’index spécifique plutôt que pour tous les blobs dans un conteneur.

• Vous pouvez utiliser des rôles RBAC intégrés et personnalisés avec des autorisations Microsoft.Authorization/roleAssignments/write ou Microsoft.Authorization/roleAssignments/delete pour créer, supprimer et mettre à jour des attributions de rôles. Toute personne ayant ce rôle peut décider à qui assigner des autorisations d’écriture, de lecture et de suppression pour n’importe quelle ressource comprise dans l’étendue d’affectation. Les membres de l’équipe chargée de la zone d’atterrissage de plateforme ou d’application doivent réfléchir à la façon de déléguer des rôles privilégiés à d’autres utilisateurs et groupes afin de leur accorder l’autonomie nécessaire. Afin de garantir la conformité avec le principe de moindre privilège, ils peuvent utiliser des conditions pour déléguer des utilisateurs.

Recommandations de conception

Recommandations générales

• Appliquez l’authentification multi-facteur (MFA) Microsoft Entra pour les utilisateurs ayant des droits sur l’environnement Azure, y compris l’abonnement de la plate-forme, l’abonnement de l’application et le locataire Microsoft Entra ID. De nombreux cadres de conformité exigent l’application de l’authentification multi-facteur. L’authentification multi-facteur contribue à réduire le risque de vol de justificatifs d’identité et d’accès non autorisé. Pour éviter un accès non autorisé aux informations sensibles, assurez-vous d’inclure les utilisateurs avec des rôles de lecteur dans les politiques MFA.

• Utilisez les politiques d’accès conditionnel Microsoft Entra pour les utilisateurs ayant des droits sur l’environnement Azure. L’accès conditionnel est une autre fonctionnalité qui aide à protéger un environnement Azure contrôlé contre les accès non autorisés. Les administrateurs d’application et de plate-forme devraient avoir des politiques d’accès conditionnel qui reflètent le profil de risque de leur rôle. Par exemple, vous pouvez avoir des exigences pour effectuer des activités administratives uniquement à partir d’emplacements spécifiques ou de postes de travail spécifiques. Ou la tolérance au risque de connexion pour les utilisateurs ayant un accès administratif aux ressources Azure pourrait être plus basse que pour les utilisateurs Microsoft Entra ID standard.

• Activez Microsoft Defender pour les identités pour aider à protéger les identités des utilisateurs et sécuriser les justificatifs d’identité. Defender pour les identités fait partie de Microsoft Defender XDR. Vous pouvez utiliser Defender pour les identités pour identifier les activités d’utilisateur suspectes et obtenir des chronologies d’incident. Vous pouvez également l’utiliser avec l’accès conditionnel pour refuser les tentatives d’authentification à haut risque. Déployez les capteurs Defender pour les identités sur les contrôleurs de domaine sur site et les contrôleurs de domaine dans l’abonnement d’identité Azure.

• Utilisez Microsoft Sentinel pour fournir des capacités de renseignement sur les menaces et d’investigation. Sentinel utilise des journaux provenant de Azure Monitor Logs, de Microsoft Entra ID, de Microsoft 365, et d’autres services pour fournir une détection proactive des menaces, une investigation et une réponse.

• Séparez l’accès administratif de l’accès quotidien non administratif, tel que la navigation sur le web et l’accès aux e-mails. Le web et l’e-mail sont des vecteurs d’attaque courants. Lorsqu’un compte utilisateur est compromis, il est moins probable que cela entraîne une violation de sécurité si le compte n’est pas utilisé pour un accès administratif.

  • Utilisez des comptes distincts, uniquement basés sur le cloud, pour les rôles privilégiés. N’utilisez pas le même compte pour un usage quotidien que pour l’administration privilégiée. Les rôles privilégiés Microsoft Entra ID et Azure RBAC sont marqués comme PRIVILÉGIÉS dans le portail Azure et dans la documentation.

  • Pour les rôles de fonction non privilégiés qui peuvent gérer les ressources d’application Azure, demandez-vous si vous avez besoin de comptes administratifs séparés ou utilisez Microsoft 365 PIM pour contrôler l’accès administratif. PIM garantit que le compte a les autorisations requises uniquement lorsque cela est nécessaire et que les autorisations sont supprimées lorsque la tâche est terminée (également appelé accès just-in-time).

• Pour rendre les affectations de rôles plus gérables, n’attribuez pas les rôles directement aux utilisateurs. Au lieu de cela, attribuez les rôles aux groupes pour aider à minimiser le nombre d’affectations de rôles, qui ont une limite pour chaque abonnement.

  • Utilisez Microsoft Entra PIM pour les groupes pour appliquer des contrôles d’accès administratifs juste-à-temps aux utilisateurs privilégiés. Envisagez l’option de contrôler l’appartenance au groupe avec la gestion des droits. Vous pouvez utiliser la fonctionnalité de gestion des droits pour ajouter des flux de travail d’approbation et d’audit aux opérations d’appartenance au groupe et vous assurer que les membres du groupe administratif ne sont pas ajoutés ou supprimés inutilement.

  • Utilisez des groupes Microsoft Entra uniquement pour les ressources de plan de contrôle Azure dans lorsque vous accordez l’accès à des ressources. Les utilisateurs et les groupes Entra uniquement, ainsi que ceux synchronisés à partir d’un site local à l’aide de Microsoft Entra Connecter, peuvent être ajoutés à un groupe Entra uniquement. Ajoutez des groupes locaux au groupe Microsoft Entra uniquement si un système de gestion de groupe est déjà en place. L’utilisation de groupes Entra uniquement permet de protéger le plan de contrôle du cloud contre toute modification non autorisée des services d’annuaire locaux. Notez que Microsoft Entra uniquement est également appelé cloud uniquement.

• Créez des comptes d’accès d’urgence, ou des comptes de secours, pour éviter d’être accidentellement exclu de votre organisation Microsoft Entra ID. Les comptes d’accès d’urgence sont très privilégiés et ne sont assignés qu’à des individus spécifiques. Stockez les informations d’identification des comptes de manière sécurisée, surveillez leur utilisation et testez-les régulièrement pour vous assurer que vous pouvez les utiliser en cas de catastrophe.

  Pour plus d’informations, veuillez consulter les pratiques d’accès sécurisé pour les administrateurs dans Microsoft Entra ID.

Recommandations pour Microsoft Entra ID

• Intégrez Microsoft Entra ID avec Azure Monitor afin de pouvoir analyser votre activité de connexion et le journal d’audit des modifications dans votre locataire. Configurez un paramètre de diagnostic pour envoyer les journaux de connexion et les journaux d’audit vers l’espace de travail central Azure Monitor Logs dans l’abonnement de gestion.

• Utilisez la fonctionnalité de gestion des droits de Microsoft Entra ID pour créer des packages d’accès qui contrôlent l’appartenance au groupe via des processus d’approbation automatiques et des examens d’accès réguliers pour les membres de groupe privilégiés.

• Utilisez les rôles intégrés de Microsoft Entra pour gérer les paramètres d’identité suivants au niveau du locataire :

  Rôle	Description	Remarque
  Administrateur général	Gère tous les aspects de Microsoft Entra ID et des services Microsoft qui utilisent les identités Microsoft Entra.	N’attribuez pas plus de cinq personnes à ce rôle.
  Administrateur d’identité hybride	Gère l’approvisionnement cloud de l’Active Directory à Microsoft Entra ID et gère également Microsoft Entra Connect, l’authentification par hachage de mot de passe Microsoft Entra, l’authentification unique transparente Microsoft Entra (Seamless SSO), et les paramètres de fédération.
  Administrateur de sécurité	Lit les informations et les rapports de sécurité, et gère les configurations dans Microsoft Entra ID et Microsoft 365.
  Administrateur d’application	Crée et gère tous les aspects des enregistrements d’applications et des applications d’entreprise.	Vous ne pouvez pas accorder un consentement administratif à l’échelle des locataires.

• N’attribuez pas à une tâche un rôle plus privilégié qu’un rôle moins privilégié pourrait remplir. Par exemple, attribuez le rôle d’administrateur d’utilisateur pour gérer les utilisateurs, et non le rôle d’administrateur global. Pour plus d’informations, consultez les autorisations des rôles intégrés de Microsoft Entra.

• Utilisez des unités administratives pour restreindre un ensemble d’administrateurs afin qu’ils ne puissent gérer que des objets spécifiques dans votre locataire. Vous pouvez utiliser des unités administratives pour déléguer l’administration d’un sous-ensemble du répertoire. Par exemple, vous pouvez déléguer l’administration d’un service d’assistance à une seule unité commerciale au sein d’une organisation plus large.

  Les unités administratives peuvent également aider à éliminer le besoin de locataires Microsoft Entra ID séparés en tant que limite de sécurité, où des équipes séparées gèrent la plate-forme Microsoft 365 et la plate-forme Azure dans la même organisation. Par exemple, vous pouvez utiliser des unités administratives pour déléguer la gestion des principaux de sécurité d’application Azure à l’équipe d’application sans accorder de privilèges sur l’ensemble du locataire Microsoft Entra ID.

• Utilisez des unités administratives de gestion restreinte pour fournir une protection supplémentaire. Empêchez quiconque autre qu’un ensemble spécifique d’administrateurs que vous désignez de modifier des objets spécifiques. Par exemple, vos politiques de séparation des tâches pourraient exiger que vous utilisiez cette fonctionnalité pour empêcher quiconque de modifier un compte utilisateur spécifique, même les utilisateurs avec le rôle d’administrateur d’utilisateur. Cette restriction est utile pour les comptes de service utilisés par les applications et que même les administrateurs ne doivent pas modifier. Vous pouvez également empêcher l’élévation de privilèges, par exemple si quelqu’un modifie un compte utilisateur ou un groupe qui a des privilèges d’administration de plate-forme ou de zone de déploiement.

Recommandations relatives à Azure RBAC

• Pour simplifier l’administration et réduire le risque de mauvaise configuration, standardisez les rôles et les affectations de rôles dans toutes les zones d’atterrissage d’application. Par exemple, si vous avez un rôle qui délègue aux utilisateurs la gestion des machines virtuelles, utilisez le même rôle dans toutes les zones d’atterrissage d’application. Cette approche simplifie également le processus de déplacement des ressources entre les zones d’atterrissage.

• Utilisez le contrôle d’accès en fonction du rôle (RBAC) Azure pour gérer l’accès du plan de données aux ressources dans la mesure du possible. Azure Key Vault, un compte de stockage ou SQL Database sont des exemples de points de terminaison de plan de données.

• Assurez-vous que les espaces de travail Azure Monitor Logs sont configurés avec le modèle de permission approprié. Lorsque vous utilisez un espace de travail centralisé Azure Monitor Logs, utilisez les autorisations des ressources pour garantir que les équipes d’application ont accès à leurs propres journaux mais pas aux journaux des autres équipes.

Rôles intégrés

• Demandez-vois si les rôles intégrés sont adaptés à vos besoins. Dans de nombreux cas, vous pouvez attribuer plusieurs rôles intégrés à un groupe de sécurité pour fournir l’accès approprié à un utilisateur. Mais il peut parfois arriver que vous ne puissiez pas utiliser les rôles intégrés et respecter l’accès le moins privilégié car les rôles peuvent inclure des autorisations qui dépassent ce que vos utilisateurs requièrent. Pour un contrôle plus granulaire, envisagez de créer un rôle personnalisé qui reflète les autorisations spécifiques requises pour effectuer une fonction. Pour plus d’informations, veuillez consulter la rubrique Fournir une autorisation basée sur les rôles.

• De nombreux rôles intégrés Azure fournissent des affectations de rôle prédéfinies au niveau de la plate-forme et des ressources. Lorsque vous combinez plusieurs affectations de rôle, considérez les effets globaux.

• L’accélérateur de zone d’atterrissage Azure comprend plusieurs rôles administratifs personnalisés pour les fonctions administratives courantes. Vous pouvez utiliser ces rôles aux côtés des rôles intégrés Azure. Le tableau suivant décrit les rôles administratifs personnalisés ou les domaines pour l’accélérateur de zone de déploiement Azure :

  Rôle administratif ou domaine	Description	Actions	NotActions
  Propriétaire de la plate-forme Azure (tel que le rôle intégré Propriétaire)	Gère les groupes de gestion et les cycles de vie des abonnements	*
  Propriétaire de l’abonnement	Rôle délégué pour le propriétaire de l’abonnement	*	Microsoft.Authorization/*/write, Microsoft.Network/vpnGateways/*, Microsoft.Network/expressRouteCircuits/*, Microsoft.Network/routeTables/write, Microsoft.Network/vpnSites/*
  Propriétaire de l’application (DevOps, Opérations de l’application)	Rôle contributeur pour l’équipe d’application ou d’opérations au niveau de l’abonnement	*	Microsoft.Authorization/*/write, Microsoft.Network/publicIPAddresses/write, Microsoft.Network/virtualNetworks/write, Microsoft.KeyVault/locations/deletedVaults/purge/action
  Gestion du réseau (NetOps)	Gère la connectivité globale à l’échelle de la plateforme, telle que les réseaux virtuels, les routages de réseau définis par l’utilisateur (UDRs), les groupes de sécurité réseau (NSGs), les appareils de réseau virtuel (NVA), les VPN, Azure ExpressRoute, et autres	*/read, Microsoft.Network/*, Microsoft.Resources/deployments/*, Microsoft.Support/*
  Opérations de sécurité (SecOps)	Rôle d’administrateur de sécurité avec une vue horizontale sur l’ensemble de l’infrastructure Azure et la politique de purge du coffre de clés	*/read, */register/action, Microsoft.KeyVault/locations/deletedVaults/purge/action, Microsoft.PolicyInsights/*, Microsoft.Authorization/policyAssignments/*, Microsoft.Authorization/policyDefinitions/*, Microsoft.Authorization/policyExemptions/*, Microsoft.Authorization/policySetDefinitions/*, Microsoft.Insights/alertRules/*, Microsoft.Resources/deployments/*, Microsoft.Security/*, Microsoft.Support/*

  Ces rôles peuvent nécessiter des droits supplémentaires en fonction du modèle de responsabilité. Par exemple, dans certaines organisations, un rôle NetOps peut devoir seulement gérer et configurer la connectivité globale. Dans des organisations qui ont besoin d’une approche plus centralisée, vous pouvez enrichir le rôle NetOps de davantage d’actions autorisées, notamment la création d’un peering entre les hubs et leurs « spokes » (rayons).

Attributions de rôles et groupes

• Lorsque l’équipe de la plate-forme approvisionne une zone d’atterrissage d’application, elle doit s’assurer que tous les objets de gestion des identités et des accès requis sont créés, tels que les groupes de sécurité, les affectations de rôles standard et les identités gérées attribuées par l’utilisateur.

• Créez des affectations de rôles de zone d’atterrissage au niveau de l’abonnement ou du groupe de ressources. Les affectations de stratégies Azure se produisent au niveau du groupe de gestion, il est donc recommandé d’approvisionner les affectations de rôles de zone d’atterrissage à un niveau inférieur. Utilisez cette approche pour garantir que les administrateurs de zone d’atterrissage ont une autonomie totale sur leurs ressources mais ne peuvent pas modifier les affectations de stratégie Azure qui régissent leur zone d’atterrissage.

• Chaque zone d’atterrissage d’application doit avoir ses propres groupes et affectations de rôles. Ne créez pas de groupes génériques et ne les attribuez pas à plusieurs zones d’atterrissage. Cette approche peut entraîner des erreurs de configuration et des violations de sécurité, et elle est difficile à gérer à grande échelle. Si un utilisateur a besoin d’avoir accès à plusieurs zones d’atterrissage, attribuez-le aux groupes appropriés dans chaque zone d’atterrissage. Utilisez la gouvernance des identités pour gérer leur appartenance à des groupes.

• Affectez les rôles aux groupes, pas aux utilisateurs. Cette approche aide à garantir que les utilisateurs disposent des autorisations correctes lorsqu’ils rejoignent ou quittent votre organisation. Elle contribue également à garantir que les utilisateurs disposent des autorisations correctes lorsqu’ils passent d’une équipe à une autre. Par exemple, si un utilisateur passe de l’équipe réseau à l’équipe sécurité, vous devez le retirer du groupe réseau et l’ajouter au groupe sécurité. Si vous attribuez un rôle directement à un utilisateur, il conserve le rôle après avoir changé d’équipe. Utilisez la gouvernance des identités pour gérer l’appartenance à un groupe plutôt que d’ajouter et de supprimer manuellement les membres du groupe.

• Maintenez des configurations de sécurité distinctes pour différents environnements de la même application, tels que dev/test et production. Créez des groupes et des affectations de rôles distincts pour chaque environnement. Ne partagez pas les identités gérées ou les principaux de service entre les environnements. Traitez chaque environnement comme une zone d’atterrissage distincte. Cette approche aide à garantir l’isolation entre dev/test et production, et standardise le processus de déploiement d’applications entre les environnements. Si la même personne a besoin d’avoir accès à plusieurs zones d’atterrissage, vous devriez l’attribuer aux groupes appropriés dans chaque zone d’atterrissage.

• Demandez-vois si les administrateurs de la plate-forme ont besoin de permissions sur les zones d’atterrissage d’applications. Si tel est le cas, utilisez Microsoft Entra PIM pour contrôler l’accès à ces ressources, et attribuez les permissions les moins privilégiées nécessaires. Par exemple, un administrateur de plate-forme peut nécessiter l’accès à une zone d’atterrissage d’application spécifique pour résoudre un problème, mais ne devrait pas avoir un accès régulier aux données ou au code de l’application. Dans ce cas, l’administrateur de la plate-forme peut demander l’accès à l’application. Un administrateur de rôle privilégié approuve la demande, et l’administrateur de la plate-forme se voit accorder les autorisations requises pour la période de temps spécifiée. Cette approche aide à appliquer la séparation des tâches et à protéger les zones d’atterrissage d’applications contre les erreurs de configuration accidentelles ou malveillantes.

• Lorsque vous déléguez la responsabilité administrative à d’autres, tels que les équipes d’application, demandez-vous s’ils ont besoin de l’ensemble complet de privilèges ou seulement d’un sous-ensemble. Suivez le principe de moindre privilège (PoLP). Par exemple, vous pouvez attribuer les rôles Administrateur de l’accès utilisateur ou Administrateur RBAC à un utilisateur qui a besoin de gérer l’accès aux ressources Azure, mais pas les ressources elles-mêmes. Pour limiter les identités, les types d’identités et les rôles que les utilisateurs peuvent déléguer et leur attribuer des affectations RBAC Azure, utilisez les affectations de rôles délégués avec des conditions. Les équipes d’application peuvent utiliser des conditions pour gérer leurs propres principaux de sécurité dans les limites définies par l’équipe de plateforme. Les affectations de rôles plus privilégiées nécessitent une escalade vers l’équipe de la plate-forme. Tenez compte des facteurs suivants lorsque vous utilisez des conditions pour déléguer des rôles RBAC :

  • Examinez les attributions de rôles actuelles pour les rôles privilégiés intégrés et personnalisés, et évaluez si vous devez ajouter des conditions appropriées aux attributions existantes. Par exemple, vous pouvez ajouter des conditions aux rôles personnalisés Propriétaire de l’abonnement et Propriétaire de l’application que fournit l’accélérateur de zone d’atterrissage Azure. Ces conditions peuvent restreindre les types de principaux auxquels il est possible d'attribuer des rôles ou limiter des rôles spécifiques à attribuer.

  • Respectez le PoLP lorsque vous ajoutez des conditions à des attributions de rôles. Par exemple, limitez les délégués pour n'attribuer des rôles qu'à des groupes ou permettez aux délégués d’attribuer tous les rôles à l’exception de ceux d’administrateur privilégiés, tels que Propriétaire, Administrateur de l’accès utilisateur ou Administrateur RBAC.

  • Créez vos propres conditions si les modèles de condition disponibles ne répondent pas à vos exigences ou à vos stratégies.

    

  • Passez en revue les limitations connues pour la délégation de la gestion des accès Azure à d’autres utilisateurs.

• Le tableau suivant montre une structure d’affectation de rôles exemple pour un environnement de zone d’atterrissage Azure. Il offre un bon équilibre entre sécurité et simplicité d’administration. Vous pouvez adapter la structure à vos besoins organisationnels. Vous pouvez attribuer le même individu à plusieurs groupes, en fonction de son rôle au sein de l’organisation. Mais vous devez appliquer les affectations RBAC à un groupe spécifique au sein d’une zone d’atterrissage spécifique.

  Ressource	Utilisateur	Attribution de rôle	Cible de l’affectation	Étendue de l’affectation
  Zone d’atterrissage de l’application X	Propriétaires de l’application X	Propriétaire de l’application (personnalisé, inclus dans l’accélérateur de zone d’atterrissage Azure)	Groupe de sécurité Application X Admins	Abonnements de production et de développement/test de l’application X
  Zone d’atterrissage de l’application X	Propriétaires de l’application X	Administrateur d’accès à l’application (personnalisé, avec des conditions d’affectation de rôles pour gérer l’accès à leur propre application)	Groupe de sécurité Application X Admins	Abonnements de production et de développement/test de l’application X
  Zone d’atterrissage de l’application X	Administrateur de données de l’application X	Administrateur de données (personnalisé, avec des autorisations sur les ressources de données requises)	Groupe de sécurité Application X Data Team	Abonnements de production et de développement/test de l’application X
  Zone d’atterrissage de l’application Y	Propriétaires de l’application Y	Propriétaire de l’application (personnalisé, inclus dans l’accélérateur de zone d’atterrissage Azure)	Groupe de sécurité Application Y Admins	Abonnements de production et de développement/test de l’application Y
  Zone d’atterrissage de l’application Y	Équipe de test de l’application Y	Contributeur de test (personnalisé, avec les autorisations requises pour les tests d’application)	Groupe de sécurité Application Y Test Team	Abonnement de développement de l’application Y
  Bac à sable	Équipe de développement de l’application Z	Propriétaire (intégré)	Groupe de sécurité Application Z developers	Groupes de ressources de l’application Z dans l’abonnement sandbox
  Ressources de la plate-forme	Équipe de gestion de la plate-forme	Contributeur (intégré)	Platform Admins Groupe PIM	Groupe d’administration Platform
  Zones d’atterrissage de la plate-forme	Équipe de gestion de la plate-forme	Lecteur (intégré)	Groupe de sécurité Platform Team	Groupe de gestion de haut niveau de l’organisation
  À l’échelle du locataire	Équipe de sécurité	Opérations de sécurité (personnalisé, inclus dans l’accélérateur de zone d’atterrissage Azure)	Groupe de sécurité Security Ops	Groupe de gestion de haut niveau de l’organisation
  À l’échelle du locataire	Équipe de sécurité	Administrateur d’accès conditionnel (intégré, avec des actions protégées activées)	Groupe de sécurité Security administrators	Locataire Microsoft Entra ID
  À l’échelle du locataire	Équipe réseau	Opérations réseau (personnalisé, inclus dans l’accélérateur de zone de déploiement Azure)	Groupe de sécurité Network Ops	Tous les abonnements
  À l’échelle du locataire	Équipe FinOps	Lecteur de facturation (intégré)	Groupe de sécurité FinOps Team	Groupe de gestion de haut niveau de l’organisation

• Les affectations de stratégie Azure qui ont l’effet DeployIfNotExists exigent une identité managée pour remédier aux ressources non conformes. Si vous utilisez une identité managée attribuée par le système dans le cadre du processus d’attribution de stratégie Azure, Azure accorde automatiquement les autorisations requises. Si vous utilisez une identité gérée attribuée par l’utilisateur, les autorisations doivent être accordées manuellement. Les attributions de rôle d'identité managée doivent respecter le PoLP et ne permettre que les autorisations nécessaires pour corriger la stratégie sur l'étendue cible. Les identités gérées de remédiation des politiques ne prennent pas en charge les définitions de rôles personnalisés. Appliquez les attributions de rôles directement aux identités managées, et non pas aux groupes.

Recommandations pour Microsoft Entra PIM

• Utilisez Microsoft Entra PIM pour vous conformer au modèle Zero Trust et à l’accès basé sur le principe du moindre privilège. Corrélez les rôles de votre organisation aux niveaux d’accès minimum nécessaires. Dans Microsoft Entra PIM, vous pouvez utiliser des outils natifs Azure, étendre les outils et processus existants, ou utiliser à la fois les outils existants et natifs selon les besoins.

• Utilisez les révisions d’accès Microsoft Entra PIM pour valider régulièrement les droits d’accès aux ressources. Les révisions d’accès faisant partie de nombreuses infrastructures de conformité, de nombreuses organisations disposent déjà d’un processus en place pour répondre à cette exigence.

• Utilisez des identités privilégiées pour les runbooks d’automatisation qui nécessitent des permissions d’accès élevées, ou pour les pipelines de déploiement privilégiés. Vous pouvez utiliser les mêmes outils et politiques pour gouverner les flux de travail automatisés qui accèdent aux frontières de sécurité critiques que vous utilisez pour gouverner les utilisateurs de privilège équivalent. Les pipelines d’automatisation et de déploiement pour les équipes d’application devraient avoir des affectations de rôles qui empêchent un propriétaire d’application d’escalader ses propres privilèges.

• Contrôlez les rôles Azure RBAC hautement privilégiés, tels que Propriétaire ou Administrateurs d’Accès Utilisateur qui sont assignés aux membres de l’équipe de la zone d’atterrissage de plate-forme ou d’application sur un abonnement ou un groupe de gestion. Utilisez Microsoft Entra PIM pour les groupes pour configurer les rôles Azure RBAC de manière à ce qu’ils nécessitent le même processus d’élévation que les rôles Microsoft Entra ID.

  Par exemple, un utilisateur pourrait régulièrement nécessiter un accès administratif limité aux ressources dans une zone d’atterrissage d’application. Occasionnellement, il pourrait nécessiter le rôle de Propriétaire. Vous pouvez créer deux groupes de sécurité : Administrateurs d’Application et Propriétaires d’Application. Attribuez les rôles de moindre privilège au groupe des Administrateurs d’Application, et attribuez le rôle de propriétaire au rôle des Propriétaires d’Application. Utilisez les groupes PIM pour que l’utilisateur puisse demander le rôle de Propriétaire lorsque nécessaire. À tout autre moment, l’utilisateur n’a que les permissions nécessaires pour mener à bien ses activités usuelles.

• Utilisez les actions protégées avec Microsoft Entra PIM pour ajouter des couches supplémentaires de protection. Dans Microsoft Entra ID, les actions protégées sont des permissions qui sont assignées à des politiques d’accès conditionnel. Lorsqu’un utilisateur tente de réaliser une action protégée, il doit d’abord satisfaire aux politiques d’Accès Conditionnel qui sont assignées aux permissions requises. Par exemple, pour permettre aux administrateurs de mettre à jour les paramètres d’accès inter-locataires, vous pouvez exiger qu’ils satisfont d’abord à la politique MFA anti phishing.

Gestion des identités et des accès dans l’accélérateur de zone d’atterrissage Azure

La gestion des identités et des accès est une caractéristique centrale de la mise en œuvre de l’accélérateur de zone d’atterrissage Azure. Le déploiement inclut un abonnement dédié à l’identité, où les organisations peuvent déployer des contrôleurs de domaine AD DS ou d’autres services d’identité, tels que les serveurs Microsoft Entra Connect, nécessaires à leur environnement. Toutes les organisations n’ont pas besoin de services dans l’abonnement. Par exemple, certaines organisations peuvent avoir des applications qui sont déjà pleinement intégrées avec Microsoft Entra ID.

L’abonnement identité possède un réseau virtuel qui est apparié au réseau virtuel hub dans l’abonnement de la plate-forme. Avec cette configuration, l’équipe de la plate-forme peut gérer l’abonnement identité, et les propriétaires d’application ont accès aux services d’identité selon les besoins. Vous devez sécuriser l’abonnement identité et le réseau virtuel pour protéger les services d’identité contre les accès non autorisés.

La mise en œuvre de l’accélérateur de zone d’atterrissage Azure inclut également des options pour :

• Attribuer les stratégies recommandées pour régir les contrôleurs d’identité et de domaine.
• Créer un réseau virtuel et se connecter au hub via le peering de réseaux virtuels.

Étapes suivantes