Gérer la sécurité des applications/middlewares
Les grandes organisations ont de nombreux utilisateurs de différents groupes professionnels qui doivent :
- Se connecter de manière sécurisée au cluster.
- Appliquer le principe du privilège minimum en ce qui concerne l’accès aux données sous-jacentes.
- Enregistrer les événements significatifs en matière de sécurité.
L’objectif de la sécurité des applications dans HDInsight est de fournir des moyens d’authentifier de manière sécurisée plusieurs utilisateurs auprès de HDInsight, en veillant à limiter les droits d’accès aux données des utilisateurs aux autorisations minimales dont ils ont besoin pour effectuer leur travail, puis à enregistrer les événements qui ont une signification en matière de sécurité, telle que les connexions, les tentatives d’exécution d’une action privilégiée ou les modifications d’un enregistrement important.
Authentification
L’authentification est le processus qui consiste à établir l’identité de l’utilisateur, et à valider ainsi le fait qu’il est bien celui qu’il prétend être. Les clusters HDInsight dans les scénarios de production doivent généralement permettre à un large éventail d’utilisateurs de différents groupes professionnels de s’authentifier auprès du cluster pour exécuter des activités telles que la configuration, l’envoi, l’exécution et la supervision des charges de travail. L’activation de la fonctionnalité « Pack Sécurité Entreprise » (ESP) lors de la création d’un cluster HDInsight lui permet d’être joint à un domaine, et permet aux utilisateurs du domaine d’utiliser leurs informations d’identification de domaine pour s’authentifier auprès du cluster. Vous pouvez utiliser des groupes Active Directory pour créer des groupes d’utilisateurs représentant une fonction ou un service au sein d’une organisation, et plusieurs de ces groupes peuvent être synchronisés avec le cluster au moment de la création. Les clusters doivent avoir un administrateur de cluster de domaine et un ou plusieurs groupes d’utilisateurs avec un accès restreint. Vous trouverez ci-dessous une représentation des composants et des parties impliquées dans le processus d’authentification HDInsight.
Les composants ci-dessous dans le domaine d’identité d’entreprise participent à la configuration et au processus d’authentification d’un cluster ESP.
- Windows Server Active Directory : contrôleur de domaine local, et stocke les noms d’utilisateur principaux (UPN) (par exemple
user@Contoso.com) et leurs mots de passe de domaine respectifs. - Active Directory Connect (AD Connect) : outil Microsoft conçu pour effectuer la configuration des identités hybrides. Des fonctionnalités telles que la synchronisation du hachage de mot de passe sont critiques dans la configuration d’ESP sur HDInsight.
- Répertoire Azure Activity (Microsoft Entra ID) : Service de gestion des identités et des accès basé sur Microsoft Azure.
- Microsoft Entra Domain Services (Microsoft Entra Domain Services) : fournit des services de domaine managé comme la jonction de domaine, la politique de groupe, le protocole Lightweight Directory Access Protocol (LDAP) et l'authentification Kerberos/NTLM entièrement compatible avec Windows Server Active Directory. Vous utilisez ces services de domaine sans avoir à déployer, gérer et apporter des correctifs aux contrôleurs de domaine dans le cloud. Microsoft Entra Domain Services s’intègre à votre locataire Microsoft Entra existant, permettant ainsi aux utilisateurs de se connecter à l’aide de leurs informations d’identification existantes. Vous pouvez également utiliser des comptes d’utilisateurs et des groupes existants pour sécuriser l’accès aux ressources, et ainsi fournir une migration lift-and-shift plus simple des ressources locales vers Azure.
HDInsight prend en charge deux types de scénarios d’authentification.
- Lorsque les hachages de mots de passe sont synchronisés sur Microsoft Entra ID.
- Lorsque les hachages de mot de passe sont conservés sur des contrôleurs de domaine locaux. Notez que l’utilisateur peut choisir de créer le cluster HDInsight avec stockage ADLS Gen2 ou WASB (Windows Azure Storage Blob), et que le processus d’authentification diffère légèrement de l’un à l’autre. Bien que toutes les étapes du processus d’authentification s’effectuent automatiquement et n’impliquent pas l’utilisateur, il peut être utile de comprendre, à un niveau général, la séquence d’événements qui sous-tendent l’authentification d’un utilisateur.
Authentification : lorsque les hachages de mot de passe sont synchronisés avec Microsoft Entra ID
- L’utilisateur John Doe s’authentifie auprès d’un service HDInsight (par exemple Ambari, ssh ou Zeppelin) avec ses informations d’identification de domaine
user@contoso.onmicrosoft.com(appelées nom d’utilisateur principal ou UPN) et un mot de passe. La passerelle contient le nom d’utilisateur et le mot de passe. - La passerelle HDInsight envoie le nom d'utilisateur principal et le mot de passe fournis par l'utilisateur à Microsoft Entra ID en utilisant le flux d'informations d'identification de mot de passe du propriétaire de la ressource (ROPC), et sollicite une requête d'accès OAuth. Microsoft Entra ID confirme l'identité de l'utilisateur et émet un jeton d'actualisation qui est enregistré dans le service d'informations d'identification, qui s'exécute sur le nœud principal. Dans les clusters avec des comptes de stockage ADLS Gen 2, les pilotes de stockage communiquent avec le service d’informations d’identification afin de récupérer le jeton OAuth en vue de l’authentification directe auprès d’ADLS.
- La passerelle authentifie ensuite l'utilisateur auprès de Microsoft Entra Domain Services et obtient un ticket Kerberos. La passerelle transmet ensuite le ticket Kerberos aux nœuds principaux et authentifie l’utilisateur auprès du cluster.
Authentification MFA : lorsque les hachages de mots de passe ne sont pas synchronisés avec Microsoft Entra ID
Remarque
Cette configuration est également appelée HDInsight Identity Broker (HIB) ; elle prend en charge l’authentification multifacteur (MFA). Dans cette configuration, si les hachages de mots de passe ne sont pas synchronisés avec Microsoft Entra ID, l'utilisateur peut toujours s'authentifier auprès de la passerelle.
- L’utilisateur John Doe lance un service web HDInsight, tel qu’Ambari ou Zeppelin. La page redirige l’utilisateur vers un écran de connexion interactif.
Le client est redirigé vers Microsoft Entra ID, afin que l'utilisateur vérifie son identité à l'aide de son nom d'utilisateur principal
user@contoso.onmicrosoft.com. - Une fois l’UPN entré, le client est redirigé vers le serveur ADFS local, où l’utilisateur entre son mot de passe. L’authentification MFA, si elle est activée, est maintenant exécutée. Une fois l’authentification réussie, un jeton OAuth est délivré au client.
- Le client présente le jeton OAuth à la passerelle HDInsight.
- La passerelle HDInsight utilise le jeton OAuth pour acquérir un ticket Kerberos à partir du nœud HIB.
- La passerelle utilise le ticket Kerberos et inscrit le jeton OAuth auprès du service d’informations d’identification des nœuds principaux, puis procède à l’authentification auprès du cluster.
Remarque
Si les hachages de mot de passe ne sont pas synchronisés avec Microsoft Entra ID, les utilisateurs de domaine ne peuvent pas se connecter aux nœuds principaux à l'aide du protocole SSH. Seul l’utilisateur SSH local sera en mesure d’effectuer des activités SSH. Vous trouverez des conseils sur la configuration des mécanismes d’authentification pour les deux scénarios dans Utiliser le Broker d’ID pour la gestion des informations d’identification.
Autorisation
L’autorisation dans HDInsight concerne la détermination et l’application des privilèges utilisateur sur les jeux de données sous-jacents. Une autorisation affinée sur des actions et/ou des opérations spécifiques est disponible sur les services HDInsight de Hive, HBase et Kafka, et est gérée par le biais d’Apache Ranger. Ranger fournit un contrôle d’accès en fonction du rôle et un contrôle d’accès basé sur les attributs, et centralise l’audit de l’accès utilisateur et des actions administratives. Vous vous authentifiez généralement auprès d’Apache Ranger avec les informations d’identification de domaine de l’administrateur de cluster, puis vous configurez des stratégies pour les groupes ou utilisateurs restreints sur Ranger. L’exemple ci-dessous illustre comment créer une stratégie Ranger pour définir des autorisations sur un exemple de table Hive dans Ranger.
Lancez Apache Ranger à l’aide de l’URL
https://CLUSTERNAME.azurehdinsight.net/Ranger/. Remplacez « CLUSTERNAME » par le nom de votre cluster. Utilisez l’administrateur de domaine de cluster et le mot de passe correspondant pour vous connecter.
Cliquez sur Add new policy (Ajouter une nouvelle stratégie) pour ajouter une nouvelle stratégie Ranger.
Renseignez les détails de la stratégie avec les informations suivantes :
- Policy Name : nom de la stratégie.
- Database : choisissez la base de données Hive.
- Table : choisissez la table Hive dans la base de données sélectionnée.
- Hive Column : choisissez la colonne Hive sur laquelle la stratégie doit être appliquée.
- Affectez la valeur Oui à la journalisation d’audit pour activer la journalisation de tous les accès.
- Conditions d’autorisation :
- Les stratégies peuvent être appliquées aux utilisateurs de domaine ou aux groupes de domaine Active Directory (AD) dans la section Allow Conditions. Si vous souhaitez appliquer la stratégie à tous les utilisateurs d’un groupe AD, ajoutez ce groupe AD à la section Select Group.
- Si vous souhaitez que la stratégie s’applique à un utilisateur spécifique ou à un ensemble d’utilisateurs choisis issus par exemple de différents groupes AD, vous pouvez ajouter tous les ID de domaine des utilisateurs dans le champ Select User.
- Choisissez parmi un ensemble d’autorisations dans la barre de cases à cocher Permissions.
Faites défiler et cliquez sur Add.
Une fois ceci configuré, cette règle sera appliquée à tous les utilisateurs qui ont été inclus dans la stratégie.
Les paramètres des stratégies Ranger pour HBase et Kafka sont décrits dans les liens hypertexte respectifs de la section.
Audit
L’audit dans HDInsight du point de vue de la sécurité concerne l’enregistrement et la supervision des demandes d’authentification et d’autorisation qui se produisent pendant la durée de vie opérationnelle du cluster, et même après sa suppression.
L’audit dans HDInsight est activé à l’aide des journaux Azure Monitor, et peut servir à exposer des journaux qui sont essentiels à la sécurité du cluster. Vous trouverez ci-dessous quelques tables de journaux qui contiennent des informations critiques pour la sécurité des clusters.
| Nom de la table de journal | Objectif |
|---|---|
| ranger_audit_logs_CL | Journaux d’audit d’Apache Ranger sur les clusters ESP |
| log_gateway_audit_CL | Journaux d’audit de la passerelle indiquant les tentatives ayant réussi et échoué |
| log_ambari_audit_CL | Journaux d’audit d’Ambari |
| log_auth_CL | Journaux SSH indiquant les tentatives ayant réussi et échoué |
L’activation de la supervision Azure s’effectue en quelques clics à partir du portail Azure.
Sur le cluster HDInsight, cliquez sur Azure Monitor dans le volet gauche. Choisissez Activer pour Intégration à Azure Monitor et, dans Sélectionner un espace de travail, choisissez un espace de travail Log Analytics créé au préalable dans la liste déroulante.
Lancez l’espace de travail Log Analytics et importez les solutions de supervision HDInsight pertinentes en fonction de votre type de cluster. Lancez la solution et cliquez sur Journaux.
Les tables de journaux relatives à la sécurité se trouvent dans la section Journaux personnalisés sur la gauche. Elles peuvent ensuite être interrogées pour extraire les informations d’accès pertinentes.
