Gestion des identités et des accès avec des serveurs avec Azure Arc

Gestion de l’identité des serveurs traditionnellement impliquée dans Active Directory : les serveurs sont joints à un domaine, les administrateurs reçoivent des comptes de domaine ajoutés aux administrateurs locaux via des groupes de domaines et les paramètres Windows sont gérés à l’aide de la stratégie de groupe. Dans le modèle de gestion cloud, Microsoft Entra devient la pierre angulaire de l’identité et de l’accès, tandis que Active Directory (AD) peut toujours être utilisé pour l’authentification des applications et les protocoles hérités sur les machines Windows locales.

L’identité native cloud dans la gestion des serveurs est obtenue à l’aide de Microsoft Entra pour authentifier les administrateurs et les serveurs eux-mêmes. Les serveurs joints à un domaine ACTIVE Directory locaux sont toujours accessibles par des appareils Windows (station de travail) natifs dans le cloud ou des utilisateurs sur ces appareils. Grâce à Microsoft Entra, vous obtenez des informations d’identification unifiées, car Microsoft Entra ID peut gérer des machines virtuelles, des serveurs avec Arc, Office 365 et bien plus encore. Les fonctionnalités telles que l’authentification multifacteur (MFA) et l’accès conditionnel améliorent la sécurité. Les serveurs de votre environnement hybride peuvent utiliser le système d’identité d’Azure pour accéder en toute sécurité aux ressources. Ces avantages vous permettent de réduire le temps passé à gérer les comptes de service ou à accorder des droits d’administrateur local par ordinateur. Il s’agit d’une transition dans la pensée, mais qui s’aligne sur un écosystème entièrement géré par le cloud.

Examinons comment le monde d’un administrateur système change avec les avantages de Microsoft Entra.

Intégration de Microsoft Entra

Microsoft Entra ID est un service d’identité basé sur le cloud. Contrairement aux services de domaine Active Directory (AD DS), l’ID Microsoft Entra n’est pas structuré dans les unités organisationnelles et ne se concentre pas sur l’authentification Kerberos. Au lieu de cela, Microsoft Entra ID gère les identités utilisateur, les applications et l’accès aux ressources Microsoft, notamment Azure, Microsoft 365 et d’autres applications et systèmes d’exploitation qui prennent en charge l’ID Microsoft Entra.

Les serveurs eux-mêmes ne « rejoignent » pas l’ID Microsoft Entra de la façon dont ils rejoignent un domaine. Au lieu de cela, un serveur avec Arc est joint à un locataire Azure régi par l’ID Microsoft Entra lorsqu’il se connecte pour la première fois à Azure. Avec l’ID Microsoft Entra, les utilisateurs peuvent être affectés à une étendue désignée (ou ajoutés à un groupe avec ces autorisations) à l’aide du contrôle d’accès en fonction du rôle Azure (Azure RBAC). Ensuite, les utilisateurs disposant des autorisations appropriées peuvent utiliser une connexion Bureau à distance pour accéder aux machines Windows Server ou utiliser SSH pour accéder à Linux.

Votre « compte d’administrateur » est votre identité Microsoft Entra ID (ou un compte AD synchronisé) avec les rôles appropriés dans Azure. Par exemple, pour gérer les serveurs avec Arc, un utilisateur Microsoft Entra ID peut avoir le rôle de connexion administrateur de machine virtuelle intégré Azure ou une attribution de rôle personnalisée que vous créez avec les autorisations appropriées. Au lieu d’avoir un compte d’administrateur qui autorise un accès total à chaque serveur, l’ID Microsoft Entra vous permet d’étendre les rôles à un ensemble spécifique de charges de travail Azure, en accordant uniquement les autorisations nécessaires pour effectuer les tâches nécessaires sur les serveurs avec Arc et les ressources Azure natives.

Identité gérée attribuée par le système

Les serveurs avec Arc nécessitent une identité managée affectée par le système. Il s’agit d’un type d’application d’entreprise qui représente l’identité d’une ressource de machine dans Azure. Au lieu de stocker des informations d’identification, les applications s’exécutant sur le serveur peuvent utiliser l’identité managée du serveur pour s’authentifier auprès d’Azure. L’agent de machine connectée Azure Arc expose un point de terminaison que l’application peut utiliser pour demander un jeton. L’application n’a pas besoin de s’authentifier auprès du service web non routable qui fournit des jetons autres que la mise en forme correcte de la requête (y compris un en-tête de métadonnées), de sorte que la limite de sécurité attendue est la machine virtuelle. Votre serveur local peut accéder directement aux services Azure sans nécessiter d’informations d’identification codées en dur, car Azure sait que la demande provient de ce serveur et l’autorise uniquement en fonction des attributions de rôles que vous définissez.

Pour un administrateur système, un scénario courant pourrait consister à exécuter une commande Azure CLI sur le serveur (sur lequel Azure CLI est installé) pour appeler dans le stockage Azure afin de récupérer un artefact utilisé par un script d'automatisation. Étant donné que le serveur dispose d’un accès autorisé à l’identité à ce compte de stockage, la demande est terminée sans nécessiter de compte de service ou de jeton d’accès personnel (PAT).

Contrôle d’accès en fonction du rôle

Le modèle d’Azure encourage le RBAC granulaire. Étant donné que différents rôles intégrés permettent différents types d’accès, vous pouvez attribuer des rôles avec des autorisations très limitées. Par exemple, un utilisateur peut avoir un rôle qui accorde uniquement la possibilité d’utiliser Run Command sur des serveurs avec Arc, ou autorise l’accès en lecture seule à une configuration et rien de plus.

Un rôle intégré courant utilisé avec Azure Arc est le rôle d’intégration des machines connectées Azure. Les utilisateurs disposant de ce rôle peuvent intégrer des serveurs à Azure Arc, mais ne peuvent pas effectuer la plupart des autres tâches de gestion, sauf si des rôles supplémentaires sont accordés. De même, vous pouvez donner aux propriétaires d’applications des rôles qui leur permettent de déployer des correctifs sur leurs serveurs via Azure Automation sans leur accorder un accès réel à la connexion au système d’exploitation. Ce niveau de réglage précis prend en charge les principes d’administration « juste-assez ».

Accès juste-à-temps

Pour contrôler davantage l’accès avec élévation de privilèges à vos serveurs avec Arc et d’autres ressources Azure, vous pouvez activer Microsoft Entra Privileged Identity Management (PIM). PIM peut être utilisé pour l’accès juste-à-temps (JIT), ce qui permet de demander à un(e) utilisateur(-trice) de s’élever explicitement à un rôle spécifique afin d’accomplir des tâches nécessitant des niveaux d’accès plus élevés. Vous pouvez demander à un administrateur d’approuver cet accès et de définir des périodes d’expiration automatiques pour le rôle avec élévation de privilèges. PIM inclut également un historique d’audit pour voir toutes les attributions de rôles et activations pour tous les rôles privilégiés au cours des 30 derniers jours (ou une période plus longue que vous configurez).

L’utilisation de PIM permet de réduire l’accès administrateur continu et prend en charge le principe du privilège minimum. Par exemple, vous pouvez utiliser PIM pour accorder à certains utilisateurs la possibilité d’élever leur rôle à Azure Connected Machine Resource Administrator, ce qui leur permet d’effectuer des tâches de gestion plus avancées sur des serveurs avec Arc.

Configurations d’identité hybride

Dans la pratique, de nombreuses entreprises exécutent des serveurs compatibles Arc qui sont également rattachés à un domaine dans Active Directory. Ils ne sont pas mutuellement exclusifs ; ils se complètent les uns les autres. Vous pouvez vous connecter au serveur via AD si nécessaire, mais effectuer des tâches de gestion dans Azure.

Sur des serveurs individuels, vous pouvez toujours gérer des comptes locaux via AD, comme l’utilisation de la solution de mot de passe administrateur local (LAPS) pour faire pivoter le mot de passe d’administrateur local. Étant donné qu’Azure Arc ne gère pas les comptes locaux, vous pouvez continuer à utiliser ce processus. Vous pouvez même utiliser Azure Policy pour vous assurer que LAPS est activé et stocker des mots de passe dans Microsoft Entra.

Il existe beaucoup de flexibilité pour utiliser les fonctionnalités de Microsoft Entra et Azure, tout en conservant des solutions d’identité locales qui fonctionnent pour vous. Au fil du temps, vous devrez interagir moins avec la gestion des comptes de service ou l’octroi de droits d’administrateur local, car vous pouvez avoir des options de gestion des identités dans le cloud.