Considérations relatives à la gestion des identités et des accès pour Red Hat Enterprise Linux sur Azure

Cet article décrit les considérations relatives à la gestion des identités et des accès (IAM) pour le déploiement de votre accélérateur de zone d’atterrissage Azure Red Hat Enterprise Linux (RHEL). L’IAM est un élément essentiel des paramètres de sécurité d’une organisation. Le système d’exploitation RHEL et les applications qui s’exécutent dessus doivent consommer des identités externes pour la mise à l’échelle des opérations. Il est nécessaire de concevoir une implémentation IAM de cloud hybride avec attention pour garantir une intégration et une gestion fluide du paysage de votre instance dans le cloud Azure. Red Hat et Microsoft collaborent pour garantir l’intégration native entre RHEL, Windows Server Active Directory et Microsoft Entra Privileged Identity Management (PIM).

Considérations sur la conception

Il faut mettre en œuvre ces considérations et recommandations de conception pour créer un plan IAM qui répond aux exigences d’une organisation pour le déploiement Azure RHEL.

En général, un déploiement RHEL dans un environnement de cloud hybride répond aux critères suivants :

• Utiliser une autorité d’identité Linux centralisée qui s’intègre si possible au sous-système de sécurité du système d’exploitation pour améliorer l’efficacité opérationnelle et la visibilité du contrôle d’accès Utiliser une autorité d’identité Linux centralisée pour pouvoir effectuer les actions suivantes :
  • Gérer l’autorisation spécifique à l’hôte pour le système d’exploitation Linux
  • Assurer la cohérence entre les déploiements hybrides
  • Déléguer l’authentification à des sources externes
  • Simplifier le processus de révision du contrôle d’accès
  • Vérifier l’uniformité
  • Accélérer le processus d’implémentation
  • Améliorer l’infrastructure de sécurité d’une infrastructure cloud Linux hybride
• Appliquer des stratégies uniformément à plusieurs instances simultanément Utilisez cette approche pour ne pas avoir besoin d’utiliser l’automatisation afin de modifier chaque instance de l’infrastructure lorsqu’une modification se produit.
• Prenez en charge le contrôle d’accès centralisé, sécurisé et différencié au niveau de l’instance via un contrôle d’accès, de délégation et d’autres règles basés sur l’hôte.
• Gérez de manière centralisée les règles d’élévation des privilèges au niveau du système au sein de l’autorité d’identité. Appliquez cette stratégie de manière cohérente entre les instances individuelles et les groupes d’instances au sein de l’environnement.
• Prenez en charge ou fournissez des fonctionnalités modernes d’outils d’automatisation pour tester et implémenter de manière cohérente des configurations de sécurité sur les flottes de systèmes. Il est conseillé de concevoir l’automatisation de la sécurité dans un déploiement cloud hybride dès le début.
• Prenez en charge l’intégration des fonctionnalités d’authentification unique (SSO) d’entreprise héritées existantes pour faciliter les charges de migration, maintenir la cohérence des opérations de sécurité et prendre en charge les intégrations modernes pour les déploiements cloud.

Mettre en œuvre une authentification

Pour les déploiements Linux, la tendance est d’implémenter des environnements d’authentification des utilisateurs locaux au niveau du système d’exploitation. L’authentification et l’autorisation au niveau du système, la propriété d’objet, les autorisations d’objet et les intégrations aux applications sont basées sur ce modèle. Les applications de système d’exploitation utilisent ces identités de plusieurs façons. Par exemple :

• Les processus d’application s’exécutent sous certaines identités utilisateur.
• Les processus d’application créent ou accèdent à des fichiers attribués à des utilisateurs et groupes spécifiques.
• L’ensemble des groupes auxquels appartient un utilisateur est fixé lors de sa connexion. Les modifications d’appartenance sont appliquées uniquement aux nouvelles sessions.
• Le flux d’authentification et d’autorisation d’un utilisateur est directement lié à la session de connexion active à la suite de l’authentification.

Auparavant, les sessions d’interpréteur de commandes initiées par l’utilisateur basées sur ces identités étaient les principaux moyens d’interaction avec les applications sur Linux. Avec le passage aux interfaces utilisateur web, mobiles et cloud, les applications qui utilisent ce modèle de consommation d’identité sont moins courantes.

Aujourd’hui, ces identités sont généralement un mécanisme de support lors de l’exécution des applications ou des services isolés sur un système d’exploitation. Les identités au niveau de l’application ne doivent pas nécessairement être identiques aux utilisateurs au niveau du système. Mais l’identité au niveau du système est toujours essentielle pour exécuter et sécuriser efficacement une infrastructure Linux qui s’exécute à grande échelle dans un environnement cloud.

Pour les petits déploiements cloud ou les déploiements pilotes, ces méthodologies IAM traditionnelles offrent un moyen simple de se lancer. Au fur et à mesure de l’évolution de l’environnement, ces mécanismes deviennent plus difficiles à gérer, même avec l’automatisation. À mesure que le nombre de points tactiles augmente, nous constatons aussi une augmentation du volume de données de configuration, de données de journalisation, de données de dérive et d’analyse requises. Pour gérer cette complexité, il est possible de centraliser l’IAM.

Il est possible d’utiliser différents outils qui fournissent une sécurité centralisée dans un environnement Linux. Il est nécessaire de s’assurer que l’outil répond aux exigences commerciales et techniques. RHEL dispose d’une grande liste de compatibilité logicielle pour la sécurité. Il est possible d’intégrer la sécurité au niveau de l’application via la solution Azure native Microsoft Entra ID, des solutions logicielles open source commerciales comme Okta, SailPoint ou JumpCloud, ou des solutions de projet open source telles que Keycloak. Il existe également différentes solutions de sécurité au niveau du système d’exploitation. Il est possible de déployer plusieurs solutions commerciales et projets logiciels open source dans le cloud.

Recommandations de conception pour Red Hat Identity Management

Cette section décrit les recommandations de conception pour IAM dans les zones d’atterrissage Azure pour RHEL lors de l’utilisation de Red Hat Identity Management (IdM) et de Red Hat SSO. Ces services s’alignent sur le Cloud Adoption Framework pour Azure et sur le modèle d’adoption de la norme d’infrastructure Red Hat. Les recommandations étendent les principes qui sont utilisés pour implémenter un déploiement cloud hybride.

Red Hat IdM offre un moyen centralisé de gérer les magasins d’identités, l’authentification, les stratégies et l’autorisation dans un domaine Linux. Red Hat IdM s’intègre en mode natif à Windows Server Active Directory et à Microsoft Entra ID et est inclus avec RHEL. Si une extension d’Active Directory local à Azure est effectuée, il est possible de bénéficier de la fonctionnalité de confiance Windows Server Active Directory native de Red Hat IdM. De même, adopter Microsoft Entra ID ou utiliser un autre fournisseur d’identité permet d’utiliser Red Hat IdM et Red Hat SSO pour une intégration transparente. Red Hat SSO est une implémentation d’entreprise prise en charge du projet open source Keycloak. Il est fourni sans frais supplémentaires avec différents abonnements Red Hat, y compris Red Hat Ansible Automation Platform. Red Hat recommande d’implémenter Red Hat IdM au sein du déploiement RHEL dans Azure. Le diagramme suivant illustre un déploiement d’abonnement de gestion RHEL.

Les composants IAM du déploiement Red Hat dans Azure utilisent le modèle de mise à l’échelle des abonnements pour fournir un contrôle et une isolation supplémentaires aux outils de gestion. Les systèmes principaux et réplicas Red Hat IdM et les instances de Red Hat SSO résident dans un abonnement Red Hat Management avec d’autres outils. L’abonnement fournit des groupes de ressources qu’il est possible d’utiliser tout au long de l’implémentation pour fournir des services localisés et une haute disponibilité.

Le diagramme suivant illustre une architecture de déploiement zonal Red Hat IdM.

Le diagramme suivant illustre un déploiement à haute disponibilité de Red Hat IdM entre les régions et les zones de disponibilité.

Cette architecture comporte des serveurs IdM au sein de chaque région qui sont répliqués entre eux et vers un réplica masqué. Il existe au moins deux liens de réplication entre les régions. Les réplicas masqués servent de points de sauvegarde, car il est possible de les mettre hors connexion en tant que sauvegardes complètes sans affecter la disponibilité.

Les clients IdM peuvent équilibrer la charge et basculer entre les serveurs IdM en fonction de la découverte d’enregistrements de service ou via une liste de serveurs dans le fichier sssd.conf. Il ne faut pas utiliser d’équilibrage de charge externe ou de configurations de haute disponibilité avec IdM.

Tenez compte des recommandations de conception critiques ci-dessous pour votre déploiement Red Hat IdM.

• Il faut implémenter l’automatisation de l’infrastructure en tant que code (IaC) pour les opérations de déploiement, de configuration et jour 2 de Red Hat IdM. Pour automatiser Red Hat IdM, il est possible d’utiliser la collection Ansible certifiée redhat.rhel_idm via Ansible Automation Hub. Pour automatiser Red Hat SSO, il est possible d’utiliser la collection Ansible certifiée redhat.sso.

• Implémentez la prise en charge des identités d’entreprise et d’application. Identifiez les services exposés par des instances et les services nécessitant une authentification au niveau du système d’exploitation et au niveau de l’application. Utilisez Red Hat IdM pour implémenter la sécurité de la couche système d’exploitation, les règles de contrôle d’accès basées sur l’hôte et les règles de gestion d’élévation de privilèges telles que sudo. Il est également possible d’utiliser Red Hat IdM pour mapper les stratégies SELinux et les identités pour les systèmes hérités. Utilisez Red Hat SSO pour intégrer des sources d’authentification d’entreprise à des applications web.

• Utilisez la gestion centralisée des identités pour la réponse aux menaces. Il est possible d’invalider ou alterner instantanément les informations d’identification compromises dans les déploiements à l’échelle du cloud.

• Déterminez le chemin d’intégration initial pour les fournisseurs d’identité natifs d’Azure, tels que Windows Server Active Directory et Microsoft Entra ID. Red Hat IdM prend en charge plusieurs options d’intégration. Il est possible d’ajouter et de supprimer des intégrations dans IdM, mais il faut évaluer les exigences existantes, les effets de migration et le coût des modifications au fil du temps.

• Configurer les déploiements principaux Red Hat IdM et les déploiements de réplica pour réduire les latences et s’assurer qu’il n’existe aucun point de défaillance unique dans la réplication. Les déploiements géographiques d’instances RHEL affectent votre infrastructure Red Hat IdM. Il est possible d’utiliser Red Hat IdM pour déployer plusieurs réplicas Red Hat IdM, ce qui permet d’améliorer les performances, l’équilibrage de charge, le basculement et la haute disponibilité. Les déploiements peuvent comporter jusqu’à 60 réplicas. Les déploiements de réplica doivent s’assurer que les systèmes s’appliquent à plusieurs domaines d’erreur. La gestion des mises à jour de réplica Red Hat IdM par automatisation garantit la cohérence de la réplication. Utilisez des topologies de réplication recommandées par Red Hat.

• Vérifiez que la configuration d’approbation Windows Server Active Directory et la configuration DNS (Domain Name System) sont correctement configurées. Lors de la configuration de Red Hat IdM et de Windows Server Active Directory, les serveurs Active Directory local et Red Hat IdM doivent résider dans leurs propres domaines DNS ou sous-domaines. Cette exigence est due aux enregistrements de service Kerberos et à la découverte de service Kerberos. Cloud Adoption Framework recommande la résolution DNS IP privée pour les instances basées sur Azure.

• Configurez l’intégration de Red Hat Satellite pour Red Hat IdM pour automatiser les tâches de gestion telles que les zones DNS directes et inversées, l’inscription de l’hôte, la génération de clés SSH (Secure Shell) et l’inscription dans Red Hat IdM. Red Hat IdM fournit un service DNS intégré. Combinez cette intégration avec l’approbation Windows Server Active Directory afin que les utilisateurs de Windows Server Active Directory puissent se connecter en toute transparence aux systèmes et services RHEL via l’authentification unique.

• Sauvegardez vos ressources Red Hat IdM. En règle générale, on effectue un déploiement de Red Hat IdM dans une configuration de réplica multi-maître auto-gérée, mais il faut également s’assurer qu’on dispose de sauvegardes appropriées du système et des données. Utilisez des réplicas masqués Red Hat IdM pour implémenter des sauvegardes complètes hors connexion sans interrompre la disponibilité du service. Utilisez Azure Backup pour la fonctionnalité de sauvegarde chiffrée.

• Demandez à une autorité de certification (CA) externe, à une CA d’entreprise ou à une CA partenaire de signer le certificat racine Red Hat IdM lors du déploiement RHEL avec la CA intégrée.

• Intégrez les services Red Hat Identity à d’autres produits Red Hat. Red Hat IdM et Red Hat SSO s’intègrent à Ansible Automation Platform, OpenShift Container Platform, OpenStack Platform, Satellite et aux outils de développement.

Utilisez le guide Planning Identity Management afin de planifier votre infrastructure et intégrer des services pour votre déploiement Red Hat IdM. Reportez-vous au guide spécifique de la version du système d’exploitation de RHEL sur laquelle le déploiement de Red Hat IdM est envisagé.

Recommandations de conception pour la gestion des identités Azure native

• Utiliser des machines virtuelles Azure RHEL avec Microsoft Entra ID pour limiter les droits des utilisateurs et minimiser le nombre d’utilisateurs disposant de droits d’administrateur. Limiter les droits des utilisateurs pour protéger la configuration et l’accès aux secrets. Pour en savoir plus, consultez la documentation relative aux rôles intégrés Azure pour le calcul.

• Suivez le principe des privilèges minimaux et affectez les autorisations minimales requises par les utilisateurs pour les tâches autorisées. N’octroyez des accès complets et juste-à-temps que lorsque c’est nécessaire. Utilisez Microsoft Entra PIM et IAM dans les zones d’atterrissage Azure.

• Utilisez des identités managées pour accéder aux ressources RHEL protégées par Microsoft Entra ID sans avoir à gérer les secrets des charges de travail qui s’exécutent sur Azure.

• Envisagez l’utilisation de Microsoft Entra ID comme plateforme d’authentification principale et une autorité de certification pour se connecter par protocole SSH à une machine virtuelle Linux.

• Protégez les informations sensibles telles que les clés, les secrets et les certificats. Pour en savoir plus, consultez la documentation relative à Cloud Adoption Framework pour le chiffrement et la gestion des clés dans Azure.

• Implémentez l’authentification unique via Windows Server Active Directory, Microsoft Entra ID ou des Services de fédération Active Directory (AD FS). Choisissez un service en fonction du type d’accès. Utilisez l’authentification unique pour que les utilisateurs puissent se connecter à des applications RHEL sans ID d’utilisateur et mot de passe après que le fournisseur d’identité central les a authentifiés.

• Utilisez une solution de type solution de mot de passe d’administrateur local (LAPS) pour permuter souvent les mots de passe d’administrateur local. Pour plus d’informations, consultez Évaluation de la sécurité : Utilisation de Microsoft LAPS.

Étapes suivantes

• Continuité d’activité et reprise d’activité pour Red Hat Enterprise Linux sur Azure