Principes fondamentaux de la gestion des ressources Azure
Il est important de comprendre la structure et les termes spécifiques aux ressources Azure. L’image suivante montre un exemple des quatre niveaux d’étendue fournis par Azure :
Terminologie
Voici quelques-uns des termes que vous devez connaître :
Ressource : élément gérable disponible par le biais d’Azure. Les machines virtuelles, les comptes de stockage, les applications web, les bases de données et les réseaux virtuels sont des exemples de ressources.
Groupe de ressources – Conteneur qui contient des ressources associées pour une solution Azure, comme une collection de machines virtuelles, de réseaux virtuels associés et d’équilibreurs de charge nécessitant d’être gérés par des équipes spécifiques. Le groupe de ressources inclut les ressources que vous voulez gérer en tant que groupe. Vous déterminez quelles sont les ressources qui appartiennent à un groupe de ressources en fonction de ce qui convient le mieux à votre organisation. Les groupes de ressources peuvent également être utilisés pour faciliter la gestion du cycle de vie en supprimant en une seule fois toutes les ressources qui ont la même durée de vie. Cette approche offre également un avantage de sécurité en ne laissant aucun fragment susceptible d’être exploité.
Abonnement – Du point de vue de la hiérarchie organisationnelle, un abonnement est un conteneur de facturation et de gestion des ressources et des groupes de ressources. Un abonnement Azure a une relation d’approbation avec Microsoft Entra ID. Un abonnement approuve Microsoft Entra ID pour authentifier les utilisateurs, les services et les appareils.
Remarque
Un abonnement ne peut approuver qu’un seul locataire Microsoft Entra. Toutefois, chaque locataire peut approuver plusieurs abonnements et les abonnements peuvent être déplacés entre les locataires.
Groupe d’administration - Les groupes d’administration Azure fournissent une méthode hiérarchique d’application de stratégies et de conformité à différentes étendues au-dessus des abonnements. Il peut se trouver au niveau du groupe d’administration racine du locataire (étendue la plus élevée) ou à des niveaux inférieurs dans la hiérarchie. Vous organisez les abonnements en conteneurs appelés « groupes d’administration » et vous appliquez vos conditions de gouvernance aux groupes d’administration. Tous les abonnements d’un groupe d’administration héritent automatiquement des conditions appliquées à ce groupe d’administration. Notez que les définitions de stratégie peuvent être appliquées à un groupe d’administration ou à un abonnement.
Fournisseur de ressources – Service qui fournit des ressources Azure. Par exemple, comme fournisseur de ressources courant, on peut citer Microsoft. Compute, qui fournit la ressource de machine virtuelle. Microsoft. Storage est un autre fournisseur de ressources courant.
Modèle Resource Manager – Fichier JSON (JavaScript Object Notation) qui définit une ou plusieurs ressources à déployer dans un groupe de ressources, un abonnement, un locataire ou un groupe d’administration. Le modèle peut être utilisé pour déployer les ressources de manière cohérente et répétée. Consultez Vue d’ensemble du déploiement de modèles. En outre, le langage Bicep peut être utilisé à la place de JSON.
Modèle de gestion des ressources Azure
Chaque abonnement Azure est associé aux contrôles utilisés par Azure Resource Manager. Resource Manager est le service de déploiement et de gestion pour Azure. Il a une relation d’approbation avec Microsoft Entra ID pour la gestion des identités pour les organisations et avec le compte Microsoft (MSA) pour les individus. Resource Manager fournit une couche de gestion qui vous permet de créer, mettre à jour et supprimer des ressources dans votre abonnement Azure. Vous utilisez les fonctionnalités de gestion, telles que le contrôle d’accès, les verrous et les étiquettes, pour sécuriser et organiser vos ressources après le déploiement.
Notes
Avant ARM, il y avait un autre modèle de déploiement nommé Azure Service Manager (ASM) ou « classique ». Pour en savoir plus, consultez Déploiement Azure Resource Manager et déploiement Classic. La gestion des environnements avec le modèle ASM est hors de portée de ce contenu.
Azure Resource Manager est le service frontal, qui héberge les API REST utilisées par PowerShell, le portail Azure ou d’autres clients pour gérer les ressources. Quand un client crée une demande pour gérer une ressource spécifique, Resource Manager dirige par proxy la demande au fournisseur de ressources pour terminer la demande. Par exemple, si un client crée une demande pour gérer une ressource de machine virtuelle, Resource Manager dirige par proxy la demande au fournisseur de ressources Microsoft. Compute. Resource Manager exige du client qu’il spécifie un identificateur pour l’abonnement et le groupe de ressources, afin de gérer la ressource de machine virtuelle.
Avant qu’une demande de gestion de ressources puisse être exécutée par Resource Manager, plusieurs contrôles sont vérifiés.
Vérification de l’utilisateur valide – L’utilisateur qui demande de gérer la ressource doit avoir un compte dans le locataire Microsoft Entra ID associé à l’abonnement de la ressource managée.
Vérification des autorisations d’utilisateur – Les autorisations sont attribuées aux utilisateurs à l’aide du contrôle d’accès en fonction du rôle (RBAC). Un rôle RBAC spécifie un ensemble d’autorisations qu’un utilisateur peut utiliser pour une ressource spécifique. RBAC vous permet de gérer qui a accès aux ressources Azure, ce que ces utilisateurs peuvent en faire, ainsi que les zones auxquelles ils ont accès.
Vérification de la stratégie Azure - Les stratégies Azure spécifient les opérations autorisées ou explicitement refusées pour une ressource spécifique. Par exemple, une stratégie peut spécifier que les utilisateurs sont uniquement autorisés (ou non) à déployer un type spécifique de machine virtuelle.
Le diagramme suivant récapitule le modèle de ressource que nous venons de décrire.
Azure Lighthouse - Azure Lighthouse permet la gestion des ressources entre les locataires. Les organisations peuvent déléguer des rôles au niveau de l’abonnement ou du groupe de ressources aux identités d’un autre locataire.
Les abonnements qui permettent la gestion des ressources déléguées avec Azure Lighthouse ont des attributs qui indiquent les ID de locataire qui peuvent gérer des abonnements ou des groupes de ressources, ainsi que le mappage entre le rôle RBAC intégré dans le locataire des ressources et les identités dans le locataire du fournisseur de services. Au moment de l’exécution, Azure Resource Manager consommera ces attributs pour autoriser les jetons provenant du locataire du fournisseur de services.
Il est important de noter qu’Azure Lighthouse lui-même est modélisé en tant que fournisseur de ressources Azure, ce qui signifie que les aspects de la délégation sur un locataire peuvent être ciblés par le biais de stratégies Azure.
Microsoft 365 Lighthouse - Microsoft 365 Lighthouse est un portail d’administration qui permet aux fournisseurs de services managés de sécuriser et de gérer des appareils, des données et des utilisateurs à grande échelle pour les clients de petite et moyenne entreprise qui utilisent Microsoft 365 Business Premium, Microsoft 365 E3 ou Windows 365 Business.
Gestion des ressources Azure avec Microsoft Entra ID
Maintenant que vous comprenez mieux le modèle de gestion des ressources dans Azure, examinons brièvement certaines des fonctionnalités de Microsoft Entra ID permettant d’assurer la gestion des identités et des accès pour les ressources Azure.
Facturation
La facturation est importante pour la gestion des ressources, car certains rôles de facturation interagissent avec les ressources et peuvent les gérer. La facturation fonctionne différemment selon le type de contrat que vous avez passé avec Microsoft.
Contrats Entreprise Azure
Les clients Contrat Entreprise Azure (Azure EA) sont intégrés au portail Azure EA lors de l’exécution de leur contrat commercial avec Microsoft. Lors de l’intégration, une identité est associée à un rôle de facturation Administrateur d’entreprise « racine ». Le portail fournit une hiérarchie des fonctions de gestion :
Les départements vous aident à segmenter les coûts en regroupements logiques et vous permettent de définir un budget ou un quota au niveau du département.
Les comptes permettent de segmenter encore davantage les départements. Vous pouvez utiliser les comptes pour gérer les abonnements et accéder aux rapports. Le portail EA peut autoriser les comptes Microsoft (MSA) ou Microsoft Entra ID (identifiés dans le portail comme « Comptes professionnels ou scolaires »). Les identités avec le rôle « Propriétaire de compte » dans le portail EA peuvent créer des abonnements Azure.
Facturation d’entreprise et locataires Microsoft Entra
Lorsqu’un propriétaire de compte crée un abonnement Azure dans un contrat entreprise, la gestion des identités et des accès de l’abonnement est configurée comme suit :
L’abonnement Azure est associé au même locataire Microsoft Entra que celui du propriétaire du compte.
Le propriétaire du compte qui a créé l’abonnement se verra affecter des rôles Administrateur de service et Administrateur de compte. (Le portail Azure EA affecte les rôles Azure Service Manager (ASM) ou « classique » pour gérer les abonnements. Pour en savoir plus, consultez Déploiement Azure Resource Manager et déploiement Classic.)
Un contrat entreprise peut être configuré pour prendre en charge plusieurs locataires en définissant le type d’authentification « Compte professionnel ou scolaire interlocataire » dans le portail Azure EA. Compte tenu des points ci-dessus, les organisations peuvent définir plusieurs comptes pour chaque locataire et plusieurs abonnements pour chaque compte, comme indiqué dans le diagramme ci-dessous.
Il est important de noter que la configuration par défaut décrite ci-dessus accorde les privilèges Propriétaire de compte Azure EA pour gérer les ressources dans tous les abonnements qu’ils ont créés. Pour les abonnements qui détiennent des charges de travail de production, envisagez de découpler la facturation et la gestion des ressources en modifiant l’administrateur de service de l’abonnement juste après sa création.
Pour continuer à découpler et à empêcher le propriétaire du compte de récupérer l’accès de l’administrateur de service à l’abonnement, le locataire de l’abonnement peut être modifié après création. Si le propriétaire du compte n’a pas d’objet utilisateur dans le locataire Microsoft Entra vers lequel l’abonnement est déplacé, il ne peut pas récupérer le rôle de propriétaire du service.
Pour en savoir plus, consultez Rôles Azure, rôles Microsoft Entra et rôles d’administrateur d’abonnement classiques.
Contrat client Microsoft
Les clients inscrits avec un Contrat client Microsoft (MCA) ont un système de gestion de facturation différent avec ses propres rôles.
Un compte de facturation pour le Contrat client Microsoft contient un ou plusieurs profils de facturation qui vous permettent de gérer vos factures et modes de paiement. Chaque profil de facturation contient une ou plusieurs sections de facture pour l’organisation des coûts sur la facture du profil de facturation.
Dans un contrat client Microsoft, les rôles de facturation proviennent d’un seul locataire Microsoft Entra. Pour approvisionner des abonnements pour plusieurs locataires, les abonnements doivent être créés initialement dans le même locataire Microsoft Entra que celui du compte MCA, puis modifiés. Dans le diagramme ci-dessous, les abonnements pour l’environnement de préproduction Services informatiques ont été déplacés vers le locataire ContosoSandbox après leur création.
RBAC et attributions de rôles dans Azure
Dans la section Principes fondamentaux de Microsoft Entra, vous avez appris que RBAC Azure est le système d’autorisation qui fournit une gestion précise des accès aux ressources Azure et inclut de nombreux rôles intégrés. Vous pouvez créer des rôles personnalisés et attribuer des rôles à différentes étendues. Les autorisations sont appliquées en affectant des rôles RBAC à des objets demandant l’accès aux ressources Azure.
Les rôles Microsoft Entra utilisent des concepts similaires au contrôle d’accès en fonction du rôle Azure. La différence entre ces deux systèmes de contrôle d’accès en fonction du rôle est que RBAC Azure utilise la gestion des ressources Azure pour contrôler l’accès aux ressources Azure (telles que les machines virtuelles ou le stockage), et que les rôles Microsoft Entra contrôlent l’accès à Microsoft Entra ID, aux applications et aux services Microsoft tels qu’Office 365.
Les rôles Microsoft Entra et les rôles RBAC Azure s’intègrent à Microsoft Entra Privileged Identity Management pour activer des stratégies d’activation juste-à-temps, telles que le flux de travail d’approbation et l’authentification multifacteur.
ABAC et attributions de rôles dans Azure
Le contrôle d’accès en fonction des attributs (ABAC) est un système d’autorisation qui définit l’accès en fonction des attributs associés aux principaux de sécurité, aux ressources et à l’environnement. ABAC vous permet d’accorder à un principal de sécurité l’accès à une ressource selon les attributs. Azure ABAC fait référence à l’implémentation d’ABAC pour Azure.
Azure ABAC s’appuie sur Azure RBAC en ajoutant des conditions d’attribution de rôle en fonction des attributs dans le contexte d’actions spécifiques. Une condition d’attribution de rôle est une autre vérification que vous pouvez éventuellement ajouter à votre attribution de rôle pour fournir un contrôle d’accès encore plus précis. Une condition filtre les autorisations accordées dans le cadre de la définition de rôle et de l’attribution de rôle. Par exemple, vous pouvez ajouter une condition qui oblige un objet à porter une étiquette spécifique pour être lu. Vous ne pouvez pas refuser explicitement l’accès à des ressources spécifiques en utilisant des conditions.
Accès conditionnel
L’accès conditionnel Microsoft Entra peut être utilisé pour gérer l’accès aux points de terminaison de gestion Azure. Des stratégies d’accès conditionnel peuvent être appliquées à l’application cloud API Gestion des services Windows Azure pour protéger les points de terminaison de gestion des ressources Azure tels que :
Fournisseur Azure Resource Manager (services)
API Azure Resource Manager
Azure PowerShell
Azure CLI
Portail Azure
Par exemple, un administrateur peut configurer une stratégie d’accès conditionnel, ce qui permet à un utilisateur de se connecter au portail Azure uniquement à partir d’emplacements approuvés et nécessite également l’authentification multifacteur (MFA) ou un appareil hybride Microsoft Entra joint à un domaine.
Identités managées Azure
La gestion des informations d’identification dans votre code pour s’authentifier auprès des services cloud constitue un défi courant lors de la génération d’applications cloud. La sécurisation de ces informations d’identification est une tâche importante. Dans l’idéal, elles ne s’affichent jamais sur les stations de travail de développement et ne sont jamais archivées dans le contrôle de code source. Les identités managées pour les ressources Azure fournissent des services Azure avec une identité managée automatiquement dans Microsoft Entra ID. Vous pouvez utiliser l’identité pour vous authentifier auprès d’un service quelconque prenant en charge l’authentification Microsoft Entra, sans aucune information d’identification dans votre code.
Il existe deux types d’identités administrées :
Une identité managée attribuée par le système est activée directement sur une ressource Azure. Quand la ressource est activée, Azure crée une identité pour la ressource dans le locataire Microsoft Entra approuvé de l’abonnement associé. Une fois l’identité créée, les informations d’identification sont provisionnées sur la ressource. Le cycle de vie d’une identité attribuée par le système est directement lié à la ressource Azure. Si la ressource est supprimée, Azure efface automatiquement les informations d’identification et l’identité dans Microsoft Entra ID.
Une identité managée attribuée par l’utilisateur est créée en tant que ressource Azure autonome. Azure crée une identité dans le locataire Microsoft Entra approuvé par l’abonnement auquel la ressource est associée. Une fois l’identité créée, elle peut être affectée à une ou plusieurs ressources Azure. Le cycle de vie d’une identité attribuée par l’utilisateur est géré séparément du cycle de vie des ressources Azure auxquelles elle est affectée.
En interne, les identités managées sont des principaux de service d’un type spécial, qui peuvent être utilisés uniquement par des ressources Azure spécifiques. Lorsqu’une identité managée est supprimée, le principal de service correspondant est automatiquement supprimé. Notez que les autorisations d’API Graph ne peuvent être autorisées que par PowerShell. Par conséquent, toutes les fonctionnalités de l’identité managée ne sont pas accessibles via l’interface utilisateur du portail.
Services de domaine Microsoft Entra
Microsoft Entra Domain Services fournit un domaine managé pour faciliter l’authentification pour les charges de travail Azure à l’aide de protocoles hérités. Les serveurs pris en charge sont déplacés d’une forêt AD DS locale et joints à un domaine managé Microsoft Entra Domain Services. Ils continuent d’utiliser des protocoles hérités pour l’authentification (par exemple, l’authentification Kerberos).
Annuaires Azure AD B2C et Azure
Un locataire Azure AD B2C est lié à un abonnement Azure à des fins de facturation et de communication. Les locataires Azure AD B2C ont une structure de rôles autonome dans l’annuaire, qui est indépendante des rôles privilégiés RBAC Azure de l’abonnement Azure.
Quand le client Azure AD B2C est initialement provisionné, l’utilisateur qui crée le client B2C doit disposer d’autorisations de contributeur ou de propriétaire dans l’abonnement. Ils peuvent ensuite créer d’autres comptes et les affecter aux rôles d’annuaire. Pour plus d’informations sur l’étendue, consultez Vue d’ensemble du contrôle d’accès en fonction du rôle (RBAC) dans Microsoft Entra ID.
Il est important de noter que les propriétaires et contributeurs de l’abonnement Microsoft Entra lié peuvent supprimer le lien entre l’abonnement et l’annuaire, ce qui affectera la facturation continue de l’utilisation d’Azure AD B2C.
Considérations relatives aux identités pour les solutions IaaS dans Azure
Ce scénario couvre les exigences d’isolation des identités dont disposent les organisations pour les charges de travail IaaS (Infrastructure-as-a-Service).
Il existe trois options clés concernant la gestion de l’isolation des charges de travail IaaS :
Des machines virtuelles jointes au service Active Directory Domain Services (AD DS) autonome
Machines virtuelles jointes à Microsoft Entra Domain Services
Connexion à des machines virtuelles dans Azure à l’aide de l’authentification Microsoft Entra
Un concept clé à traiter avec les deux premières options est qu’il existe deux domaines d’identité impliqués dans ces scénarios.
Lorsque vous vous connectez à une machine virtuelle Azure Windows Server via le protocole RDP (Remote Desktop Protocol), vous vous connectez généralement au serveur à l’aide de vos informations d’identification de domaine, ce qui entraîne une authentification Kerberos auprès d’un contrôleur de domaine AD DS local ou Microsoft Entra Domain Services. Sinon, si le serveur n’est pas joint à un domaine, un compte local peut être utilisé pour se connecter aux machines virtuelles.
Lorsque vous vous connectez au portail Azure pour créer ou gérer une machine virtuelle, vous vous authentifiez auprès de Microsoft Entra ID (éventuellement en utilisant les mêmes informations d’identification si vous avez synchronisé les bons comptes). Cela peut entraîner une authentification auprès de vos contrôleurs de domaine si vous utilisez les services de fédération Active Directory (AD FS) ou l’authentification directe.
Machines virtuelles jointes au service Active Directory Domain Services autonome
AD DS est le service d’annuaire Windows Server que les organisations ont largement adopté pour les services d’identité locaux. AD DS peut être déployé lorsqu’il existe une exigence pour déployer des charges de travail IaaS sur Azure qui nécessitent l’isolation des identités des administrateurs et des utilisateurs AD DS dans une autre forêt.
Les considérations suivantes doivent être prises en compte dans ce scénario :
Contrôleurs de domaine AD DS : au moins deux contrôleurs de domaine AD DS doivent être déployés pour garantir que les services d’authentification sont hautement disponibles et performants. Pour plus d’informations, consultez Planification et conception des services AD DS.
Planification et conception des services AD DS – Une nouvelle forêt AD DS doit être créée avec les services suivants configurés correctement :
Service DNS (Domain Name System) AD DS – Le service DNS AD DS doit être configuré pour les zones appropriées dans AD DS afin de garantir que la résolution de noms fonctionne correctement pour les serveurs et les applications.
Sites et services AD DS – Ces services doivent être configurés pour garantir que les applications disposent d’un accès performant à faible latence aux contrôleurs de domaine. Les réseaux virtuels, sous-réseaux et emplacements de centre de données appropriés où se trouvent les serveurs doivent être configurés dans des sites et des services.
FSMO AD DS – Les rôles FSMO (Flexible Single Master Operation) requis doivent être examinés et affectés aux contrôleurs de domaine AD DS appropriés.
Jonction de domaine AD DS – Tous les serveurs (à l’exception des « serveurs de rebond ») qui nécessitent AD DS pour l’authentification, la configuration et la gestion doivent être joints à la forêt isolée.
Stratégie de groupe (GPO) AD DS – Les objets de stratégie de groupe AD DS doivent être configurés pour garantir que la configuration répond aux exigences de sécurité et que la configuration est normalisée sur les machines jointes au domaine et à la forêt.
Unités organisationnelles AD DS (OU) – Les unités d’organisation AD DS doivent être définies pour garantir le regroupement de ressources AD DS en silos de gestion logique et de configuration à des fins d’administration et d’application de la configuration.
Contrôle d’accès en fonction du rôle – RBAC doit être défini pour l’administration et l’accès aux ressources jointes à cette forêt. notamment :
Groupes AD DS – Des groupes doivent être créés pour appliquer des autorisations appropriées aux utilisateurs aux ressources AD DS.
Comptes d’administration – Comme mentionné au début de cette section, deux comptes d’administration sont requis pour gérer cette solution.
Un compte d’administration AD DS avec le droit d’accès minimal requis pour effectuer l’administration requise dans les serveurs joints à un domaine ou à AD DS.
Un compte d’administration Microsoft Entra pour accéder au portail Azure afin de connecter, gérer et configurer des machines virtuelles, des réseaux virtuels, des groupes de sécurité réseau et d’autres ressources Azure requises.
Comptes d’utilisateur AD DS – Les comptes d’utilisateur appropriés doivent être provisionnés et ajoutés aux groupes appropriés pour autoriser l’accès des utilisateurs aux applications hébergées par cette solution.
Réseaux virtuels (réseaux virtuels) – Conseils de configuration
Adresse IP du contrôleur de domaine AD DS – Les contrôleurs de domaine ne doivent pas être configurés avec des adresses IP statiques au sein du système d’exploitation. Les adresses IP doivent être réservées sur le réseau virtuel Azure pour garantir qu’elles resteront toujours les mêmes et que le contrôleur de domaine doit être configuré pour utiliser DHCP.
Serveur DNS de réseau virtuel – Les serveurs DNS doivent être configurés sur des réseaux virtuels qui font partie de cette solution isolée pour pointer vers les contrôleurs de domaine. Cela est nécessaire pour garantir que les applications et les serveurs pourront résoudre les services AD DS requis ou d’autres services joints à la forêt AD DS.
Groupes de sécurité réseau (NSG) – Les contrôleurs de domaine doivent se trouver sur leur propre réseau virtuel ou sous-réseau avec des groupes de sécurité réseau définis pour autoriser uniquement l’accès aux contrôleurs de domaine à partir de serveurs requis (par exemple, des machines jointes à un domaine ou des serveurs de rebond). Des serveurs de rebond doivent être ajoutés à un groupe de sécurité d’application (ASG) pour simplifier la création et l’administration du groupe de sécurité réseau.
Défis – La liste ci-dessous met en évidence les principaux défis liés à l’utilisation de cette option pour l’isolation des identités :
Une forêt AD DS supplémentaire pour administrer, gérer et surveiller, ce qui entraîne davantage de travail pour l’équipe informatique.
Une infrastructure supplémentaire peut être nécessaire pour la gestion des correctifs et des déploiements de logiciels. Les organisations doivent envisager de déployer Azure Update Management, une stratégie de groupe (GPO) ou System Center Configuration Manager (SCCM) pour gérer ces serveurs.
Des informations d’identification supplémentaires que les utilisateurs doivent mémoriser et utiliser pour accéder aux ressources.
Important
Pour ce modèle isolé, il est supposé qu’il n’y a pas de connectivité avec les contrôleurs de domaine issus du réseau d’entreprise du client et qu’il n’y a pas d’approbations configurées avec d’autres forêts. Un serveur de rebond ou d’administration doit être créé pour autoriser un point à partir duquel les contrôleurs de domaine AD DS peuvent être gérés et administrés.
Machines virtuelles jointes à Microsoft Entra Domain Services
Quand une exigence impose de déployer des charges de travail IaaS sur Azure qui nécessitent une isolation d’identité par rapport aux administrateurs et utilisateurs AD DS dans une autre forêt, un domaine managé Microsoft Entra Domain Services peut être déployé. Microsoft Entra Domain Services est un service qui fournit un domaine managé pour faciliter l’authentification pour les charges de travail Azure à l’aide de protocoles hérités. Cela fournit un domaine isolé sans la complexité technique de la création et de la gestion de votre propre service AD DS. Les considérations suivantes doivent être prises en compte.
Domaine managé Microsoft Entra Domain Services – Un seul domaine managé Microsoft Entra Domain Services peut être déployé par locataire Microsoft Entra et il est lié à un seul réseau virtuel. Il est recommandé que ce réseau virtuel constitue le « hub » pour l’authentification Microsoft Entra Domain Services. À partir de ce hub, les « spokes » peuvent être créés et liés pour autoriser l’authentification héritée pour les serveurs et les applications. Les spokes sont des réseaux virtuels supplémentaires sur lesquels des serveurs joints à Microsoft Entra Domain Services se trouvent et sont liés au hub à l’aide de passerelles réseau Azure ou du peering de réseaux virtuels.
Emplacement de domaine managé – Un emplacement doit être défini lors du déploiement d’un domaine managé Microsoft Entra Domain Services. L’emplacement est une région physique (centre de données) où le domaine managé est déployé. Il est recommandé de :
Considérer un emplacement géographiquement proche des serveurs et applications qui nécessitent des services Microsoft Entra Domain Services.
Considérer des régions qui fournissent des fonctionnalités de type Zones de disponibilité pour les exigences de haute disponibilité. Pour plus d'informations, consultez Régions et zones de disponibilité dans Azure.
Approvisionnement d’objets – Microsoft Entra Domain Services synchronise les identités à partir de l’annuaire Microsoft Entra ID associé à l’abonnement dans lequel Microsoft Entra Domain Services est déployé. Il convient également de noter que si la synchronisation de l’annuaire Microsoft Entra ID associé est configurée avec Microsoft Entra Connect (scénario avec forêt d’utilisateurs), le cycle de vie de ces identités peut également être reflété dans Microsoft Entra Domain Services. Ce service a deux modes qui peuvent être utilisés pour l’approvisionnement d’objets utilisateur et groupe à partir de Microsoft Entra ID.
Tous – Tous les utilisateurs et groupes sont synchronisés de Microsoft Entra ID vers Microsoft Entra Domain Services.
Délimité – Seuls les utilisateurs dans l’étendue d’un ou plusieurs groupes sont synchronisés de Microsoft Entra ID vers Microsoft Entra Domain Services.
Lorsque vous déployez Microsoft Entra Domain Services pour la première fois, une synchronisation unidirectionnelle automatique est configurée pour répliquer les objets à partir de Microsoft Entra ID. Cette synchronisation unidirectionnelle continue à s’exécuter en arrière-plan pour maintenir à jour le domaine managé Microsoft Entra Domain Services avec les modifications apportées par Microsoft Entra ID. Aucune synchronisation n’est effectuée entre Microsoft Entra Domain Services et Microsoft Entra ID. Pour plus d’informations, consultez Synchronisation des objets et des informations d’identification dans un domaine managé Microsoft Entra Domain Services.
Il est important de noter que si vous devez modifier le type de synchronisation de Tous vers Délimité (ou vice versa), le domaine managé Microsoft Entra Domain Services doit être supprimé, recréé et configuré. En outre, en guise de bonne pratique, les organisations doivent envisager l’utilisation d’un approvisionnement « délimité » pour réduire les identités aux seules personnes qui ont besoin d’accéder aux ressources Microsoft Entra Domain Services.
Objets de stratégie de groupe (GPO) – Pour configurer un objet de stratégie de groupe dans un domaine managé Microsoft Entra Domain Services, vous devez utiliser des outils de gestion de stratégie de groupe sur un serveur joint au domaine managé Microsoft Entra Domain Services. Pour plus d’informations, consultez Administrer les objets de stratégie de groupe sur un domaine managé Microsoft Entra Domain Services.
LDAP sécurisé – Microsoft Entra Domain Services fournit un service LDAP sécurisé qui peut être utilisé par les applications qui en ont besoin. Ce paramètre est désactivé par défaut et un certificat doit être chargé pour activer le protocole LDAP sécurisé. En outre, le groupe de sécurité réseau qui sécurise le réseau virtuel sur lequel Microsoft Entra Domain Services est déployé doit autoriser la connectivité du port 636 aux domaines managés Microsoft Entra Domain Services. Pour plus d’informations, consultez Configurer le protocole LDAPS (LDAP sécurisé) pour un domaine managé Microsoft Entra Domain Services.
Administration – Pour effectuer des tâches d’administration sur Microsoft Entra Domain Services (par exemple, joindre des machines à un domaine ou modifier un objet de stratégie de groupe), le compte utilisé pour cette tâche doit faire partie du groupe Administrateurs Microsoft Entra DC. Les comptes qui sont membres de ce groupe ne peuvent pas se connecter directement aux contrôleurs de domaine pour effectuer des tâches de gestion. Au lieu de cela, vous créez une machine virtuelle de gestion qui est jointe au domaine managé Microsoft Entra Domain Services, puis vous installez vos outils de gestion AD DS standard. Pour plus d’informations, consultez Concepts de gestion pour les comptes d’utilisateur, les mots de passe et l’administration dans Microsoft Entra Domain Services.
Hachages de mot de passe – Pour que l’authentification avec Microsoft Entra Domain Services fonctionne, les hachages de mot de passe pour tous les utilisateurs doivent être dans un format adapté à NT LAN Manager (NTLM) et à l’authentification Kerberos. Pour garantir que l’authentification avec Microsoft Entra Domain Services fonctionne comme prévu, les prérequis suivants doivent être respectés.
Utilisateurs synchronisés avec Microsoft Entra Connect (à partir d’AD DS) – Les hachages de mot de passe hérités doivent être synchronisés du service AD DS local vers Microsoft Entra ID.
Utilisateurs créés dans Microsoft Entra ID – Ils doivent réinitialiser leur mot de passe pour que les hachages appropriés soient générés pour pouvoir être utilisés avec Microsoft Entra Domain Services. Pour plus d’informations, consultez Activer la synchronisation des hachages de mot de passe.
Réseau – Microsoft Entra Domain Services est déployé sur un réseau virtuel Azure, de sorte que des considérations doivent être prises en compte pour garantir que les serveurs et les applications seront sécurisés et pourront accéder correctement au domaine managé. Pour plus d’informations, consultez Considérations relatives à la conception du réseau virtuel et options de configuration pour Microsoft Entra Domain Services.
Microsoft Entra Domain Services doit être déployé dans son propre sous-réseau : n’utilisez pas de sous-réseau existant ni de sous-réseau de passerelle.
Un groupe de sécurité réseau est créé pendant le déploiement d’un domaine managé Microsoft Entra Domain Services. Ce groupe de sécurité réseau contient les règles requises pour permettre une communication de service appropriée. Ne créez et n’utilisez pas un groupe de sécurité réseau existant avec vos propres règles personnalisées.
Microsoft Entra Domain Services nécessite 3 à 5 adresses IP – Assurez-vous que votre plage d’adresses IP de sous-réseau peut fournir ce nombre d’adresses. La restriction des adresses IP disponibles peut empêcher Microsoft Entra Domain Services de gérer deux contrôleurs de domaine.
Serveur DNS de réseau virtuel – Comme indiqué précédemment sur le modèle « hub-and-spoke », il est important de configurer correctement le DNS sur les réseaux virtuels pour garantir que les serveurs joints au domaine managé Microsoft Entra Domain Services disposeront des paramètres DNS appropriés pour résoudre le domaine managé Microsoft Entra Domain Services. Chaque réseau virtuel a une entrée de serveur DNS qui est transmise aux serveurs quand ils obtiennent une adresse IP et ces entrées DNS doivent être les adresses IP du domaine managé Microsoft Entra Domain Services. Pour plus d’informations, consultez Mettre à jour les paramètres DNS pour le réseau virtuel Azure.
Défis – La liste suivante met en évidence les principaux défis liés à l’utilisation de cette option pour l’isolation des identités.
Certaines configurations Microsoft Entra Domain Services ne peuvent être administrées qu’à partir d’un serveur joint à Microsoft Entra Domain Services.
Un seul domaine managé Microsoft Entra Domain Services peut être déployé par locataire Microsoft Entra. Comme nous le décrivons dans cette section, le modèle hub-and-spoke est recommandé pour fournir l’authentification Microsoft Entra Domain Services aux services sur d’autres réseaux virtuels.
Une infrastructure supplémentaire peut être nécessaire pour la gestion des correctifs et des déploiements de logiciels. Les organisations doivent envisager de déployer Azure Update Management, une stratégie de groupe (GPO) ou System Center Configuration Manager (SCCM) pour gérer ces serveurs.
Pour ce modèle isolé, il est supposé qu’il n’existe aucune connectivité au réseau virtuel qui héberge le domaine managé Microsoft Entra Domain Services à partir du réseau d’entreprise du client et qu’il n’y a aucune approbation configurée avec d’autres forêts. Un serveur de rebond ou d’administration doit être créé pour autoriser un point à partir duquel le service Microsoft Entra Domain Services peut être géré et administré.
Se connecter à des machines virtuelles dans Azure avec l’authentification Microsoft Entra
Lorsqu’une exigence impose de déployer des charges de travail IaaS vers Azure qui nécessitent l’isolation des identités, l’option finale consiste à utiliser Microsoft Entra ID pour se connecter aux serveurs dans ce scénario. Cela permet de faire de Microsoft Entra ID le domaine d’identité à des fins d’authentification, et l’isolation des identités peut être obtenue en approvisionnant les serveurs dans l’abonnement approprié, lié au locataire Microsoft Entra requis. Les considérations suivantes doivent être prises en compte.
Systèmes d’exploitation pris en charge – La connexion à des machines virtuelles dans Azure à l’aide de l’authentification Microsoft Entra est actuellement prise en charge dans Windows et Linux. Pour plus d’informations sur les systèmes d’exploitation pris en charge, reportez-vous à la documentation pour Windows et Linux.
Informations d’identification – L’un des principaux avantages de la connexion à des machines virtuelles dans Azure à l’aide de l’authentification Microsoft Entra est la possibilité d’utiliser les mêmes informations d’identification Microsoft Entra fédérées ou managées que celles que vous utilisez normalement pour accéder aux services Microsoft Entra pour vous connecter à la machine virtuelle.
Remarque
Le locataire Microsoft Entra utilisé pour la connexion dans ce scénario est le locataire Microsoft Entra associé à l’abonnement dans lequel la machine virtuelle a été approvisionnée. Ce locataire Microsoft Entra peut être un locataire dont les identités sont synchronisées à partir du service AD DS local. Les organisations doivent faire un choix informé qui s’aligne sur leurs principaux d’isolation lors du choix de l’abonnement et du locataire Microsoft Entra qu’ils souhaitent utiliser pour la connexion à ces serveurs.
Configuration requise pour le réseau – Ces machines virtuelles doivent accéder à Microsoft Entra ID pour l’authentification et vous devez vous assurer que la configuration du réseau des machines virtuelles autorise l’accès sortant aux points de terminaison Microsoft Entra sur le port 443. Pour plus d’informations, consultez la documentation pour Windows et Linux.
Contrôle d’accès en fonction du rôle (RBAC) – Deux rôles RBAC sont disponibles pour fournir le niveau d’accès approprié à ces machines virtuelles. Ces rôles RBAC peuvent être configurés dans le portail Azure ou via l’expérience Azure Cloud Shell. Pour plus d’informations, consultez Configurer des attributions de rôle pour la machine virtuelle.
Connexion administrateur aux machines virtuelles – Les utilisateurs auxquels ce rôle est attribué peuvent se connecter à une machine virtuelle Azure avec des privilèges d’administrateur.
Connexion utilisateur aux machines virtuelles – Les utilisateurs auxquels ce rôle est attribué peuvent se connecter à une machine virtuelle Azure avec des privilèges d’utilisateur standard.
Accès conditionnel : un avantage clé relatif à l’utilisation de Microsoft Entra ID pour la connexion à des machines virtuelles Azure est la possibilité d’appliquer l’accès conditionnel dans le cadre du processus de connexion. Cela permet aux organisations d’exiger que les conditions soient remplies avant d’autoriser l’accès à la machine virtuelle et d’utiliser l’authentification multifacteur pour fournir une authentification forte. Pour plus d’informations, consultez Utilisation d’un accès conditionnel.
Remarque
La connexion à distance aux machines virtuelles jointes à Microsoft Entra ID est autorisée uniquement à partir des PC Windows 10, Windows 11 et Cloud PC avec jointure Microsoft Entra ou jointure hybride Microsoft Entra au même annuaire que la machine virtuelle.
Défis – La liste ci-dessous met en évidence les principaux défis liés à l’utilisation de cette option pour l’isolation des identités.
Aucune configuration ni gestion centrale des serveurs. Par exemple, il n’existe aucune stratégie de groupe pouvant être appliquée à un groupe de serveurs. Les organisations doivent envisager de déployer Update Management dans Azure pour gérer les correctifs et les mises à jour de ces serveurs.
Non adapté aux applications multiniveau qui ont des exigences pour s’authentifier avec des mécanismes locaux tels que l’authentification Windows intégrée sur ces serveurs ou services. S’il s’agit d’une exigence pour l’organisation, il est recommandé d’explorer le service Active Directory Domain Services autonome ou les scénarios Microsoft Entra Domain Services décrits dans cette section.
Pour ce modèle isolé, il est supposé qu’il n’existe aucune connectivité au réseau virtuel qui héberge les machines virtuelles à partir du réseau d’entreprise du client. Un serveur de rebond ou d’administration doit être créé pour autoriser un point à partir duquel ces serveurs peuvent être gérés et administrés.