Partager via

Informations et recommandations générales sur la sécurité d’entreprise dans Azure HDInsight

  • Article

Lors du déploiement d’un cluster HDInsight sécurisé, certaines meilleures pratiques peuvent faciliter le déploiement et la gestion des clusters. Des informations générales et des instructions sont abordées ici.

Utilisation d’un cluster sécurisé

  • Le cluster sera utilisé simultanément par plusieurs utilisateurs.
  • Les utilisateurs ont différents niveaux d’accès aux mêmes données.

Pas nécessaire

  • Vous allez exécuter uniquement des travaux automatisés (comme un compte d’utilisateur unique). Un cluster standard suffit.
  • Vous pouvez effectuer l’importation de données à l’aide d’un cluster standard et utiliser le même compte de stockage sur un autre cluster sécurisé où les utilisateurs peuvent exécuter des travaux d’analytique.

Utilisation d’un compte local

  • Si vous utilisez un compte d’utilisateur partagé ou un compte local, il sera difficile d’identifier qui a utilisé le compte pour changer la configuration ou le service.
  • L’utilisation de comptes locaux pose problème quand les utilisateurs ne font plus partie de l’organisation.

Ranger

Stratégies

  • Par défaut, Ranger utilise Refuser comme stratégie.

  • Quand l’accès aux données s’effectue par le biais d’un service où l’autorisation est activée :

    • Le plug-in d’autorisation Ranger est appelé et le contexte de la requête lui est indiqué.
    • Ranger applique les stratégies configurées pour le service. Si les stratégies Ranger échouent, le contrôle d’accès est déféré au système de fichiers. Certains services comme MapReduce vérifient uniquement si le fichier/dossier appartient au même utilisateur que celui qui envoie la requête. Les services comme Hive vérifient la correspondance de propriété ou les autorisations de système de fichiers appropriées (rwx).

  • Pour Hive, en plus de disposer des autorisations nécessaires pour créer/mettre à jour/supprimer, l’utilisateur doit disposer d’autorisations rwx sur le répertoire du stockage et sur tous les sous-répertoires.

  • Les stratégies peuvent être appliquées à des groupes (option préférable) plutôt qu’à des personnes.

  • À chaque requête, l’agent d’autorisation Ranger évalue toutes les stratégies Ranger pour ce service. Cette évaluation peut avoir un impact sur le temps nécessaire à l’acceptation du travail ou de la demande.

Accès au stockage

  • Si le type de stockage est WASB, aucun jeton OAuth n’est impliqué.
  • Si Ranger a effectué l’autorisation, l’accès au stockage se produit à l’aide de l’identité managée.
  • Si Ranger n’a effectué aucune autorisation, l’accès au stockage se produit à l’aide du jeton OAuth de l’utilisateur.

Espace de noms hiérarchique

Quand l’espace de noms hiérarchique n’est pas activé :

  • Il n’y a pas d’autorisations héritées.
  • La seule autorisation de système de fichiers qui fonctionne est le rôle Azure Données de stockage XXXX, à attribuer à l’utilisateur directement dans le portail Azure.

Autorisations HDFS par défaut

  • Par défaut, les utilisateurs n’ont pas accès au dossier / sur HDFS. (Ils doivent se trouver dans le rôle propriétaire d’objets blob de stockage pour que l’accès aboutisse).
  • Concernant le répertoire de préproduction pour MapReduce et d’autres applications, un répertoire spécifique à l’utilisateur est créé et des autorisations sticky _wx lui sont attribuées. Les utilisateurs peuvent créer des fichiers et des dossiers dessous, mais ils ne peuvent pas consulter d’autres éléments.

Authentification d’URL

Si l’authentification d’URL est activée :

  • La configuration contient les préfixes couverts dans l’authentification d’URL (par exemple adl://).
  • Si l’accès est destiné à cette URL, Ranger vérifie si l’utilisateur figure dans la liste d’autorisation.
  • Ranger ne vérifie aucune des stratégies affinées.

Gérer les journaux d’audit Ranger

Pour empêcher les journaux d’audit Ranger de consommer trop d’espace disque sur votre nœud principal hn0, vous pouvez modifier le nombre de jours pour conserver les journaux.

  1. Connectez-vous à l’interface utilisateur Ambari.
  2. Accédez à Services>Ranger>Configs>Avancé>ranger-solr-configuration avancée.
  3. Remplacez le nombre maximal de jours de rétention par 7 jours ou moins.
  4. Sélectionnez Enregistrer et redémarrer les composants affectés pour que la modification prenne effet.

Utiliser une base de données Ranger personnalisée

Nous vous recommandons de déployer une base de données Ranger externe à utiliser avec votre cluster ESP pour une haute disponibilité des métadonnées Ranger, ce qui garantit que les stratégies sont disponibles même si le cluster n’est pas disponible. Étant donné qu’une base de données externe est gérée par le client, vous aurez également la possibilité d’ajuster la taille de la base de données et de la partager entre plusieurs clusters ESP. Vous pouvez spécifier votre base de données Ranger externe pendant le processus de création du cluster ESP à l’aide de l’Portail Azure, d’Azure Resource Manager, d’Azure CLI, etc.

Définir la synchronisation utilisateur Ranger pour qu’elle s’exécute quotidiennement

Les clusters HDInsight ESP sont configurés pour Que Ranger synchronise automatiquement les utilisateurs AD toutes les heures. La synchronisation Ranger est une synchronisation utilisateur qui peut entraîner une charge supplémentaire sur le instance AD. Pour cette raison, nous vous recommandons de modifier l’intervalle de synchronisation utilisateur Ranger sur 24 heures.

  1. Connectez-vous à l’interface utilisateur Ambari.
  2. Accédez à Services>Ranger>Configs>Avancé>ranger-ugsync-site
  3. Définissez la propriété ranger.usersync.sleeptimeinmillisbetweensynccycle sur 86400000 (24h en millisecondes).
  4. Sélectionnez Enregistrer et redémarrer les composants affectés pour que la modification prenne effet.

Groupes de ressources

Utilisez un nouveau groupe de ressources pour chaque cluster afin de pouvoir faire la distinction entre les ressources de cluster.

Groupes de sécurité réseau, pare-feu et passerelle interne

  • Utilisez les groupes de sécurité réseau (NSG) pour verrouiller les réseaux virtuels.
  • Utilisez le pare-feu pour gérer les stratégies d’accès sortant.
  • Utilisez la passerelle interne qui n’est pas ouverte sur l’Internet public.

Microsoft Entra ID

Microsoft Entra ID (Microsoft Entra ID) est un service informatique de gestion des identités et des accès de Microsoft.

Stratégies

  • Désactivez la stratégie d’accès conditionnel à l’aide de la stratégie basée sur les adresses IP. Cela nécessite l’activation des points de terminaison de service sur les réseaux virtuels sur lesquels les clusters sont déployés. Si vous utilisez un service externe pour l’authentification multifacteur (autre que Microsoft Entra ID), la stratégie basée sur les adresses IP ne fonctionne pas

  • La stratégie AllowCloudPasswordValidation est nécessaire pour les utilisateurs fédérés. Étant donné que HDInsight utilise le nom d’utilisateur/mot de passe directement pour obtenir des jetons à partir de Microsoft Entra ID, cette stratégie doit être activée pour tous les utilisateurs fédérés.

  • Activez les points de terminaison de service si vous avez besoin de contourner l’accès conditionnel à l’aide d’adresses IP approuvées.

Groupes

  • Déployez toujours les clusters avec un groupe.
  • Utilisez Microsoft Entra ID pour gérer les appartenances aux groupes (plus faciles que d’essayer de gérer les services individuels dans le cluster).

Comptes d'utilisateurs

  • Utilisez un compte d’utilisateur unique pour chaque scénario. Par exemple, utilisez un compte pour l’importation, et un autre compte pour les travaux de requête ou les autres travaux de traitement.
  • Utilisez des stratégies Ranger basées sur un groupe plutôt que des stratégies individuelles.
  • Élaborez un plan pour gérer les utilisateurs qui ne doivent plus avoir accès aux clusters.

Services de domaine Microsoft Entra

Microsoft Entra Domain Services fournit des services de domaine managés, comme la jonction de domaine, la stratégie de groupe, le protocole LDAP (Lightweight Directory Access Protocol) et l’authentification Kerberos/NTLM entièrement compatible avec Windows Server Active Directory.

Microsoft Entra Domain Services est nécessaire pour que des clusters sécurisés rejoignent un domaine. HDInsight ne peut pas dépendre de contrôleurs de domaine locaux ou de contrôleurs de domaine personnalisés, car cela introduit un trop grand nombre de points d’erreur, un partage des informations d’identification, des autorisations DNS, etc. Si vous souhaitez obtenir plus d’informations, consultez les FAQ sur Microsoft Entra Domain Services.

Choisir la référence SKU correcte de Microsoft Entra Domain Services

Lors de la création de votre domaine managé, vous pouvez choisir parmi différentes références SKU qui offrent différents niveaux de performances et de fonctionnalités. Le nombre de clusters ESP et d’autres applications qui utiliseront l’instance Microsoft Entra Domain Services pour les demandes d’authentification détermine la référence SKU appropriée pour votre organisation. Si vous remarquez un niveau élevé de processeur sur votre domaine managé ou que vos besoins métier changent, vous pouvez mettre à niveau votre référence SKU.

Instance Microsoft Entra Domain Services

  • Créez l’instance avec le .onmicrosoft.com domain. Ainsi, il n’y aura pas plusieurs serveurs DNS traitant le domaine.
  • Créez un certificat auto-signé pour le protocole LDAP sécurisé et chargez-le dans Microsoft Entra Domain Services.
  • Utilisez un réseau virtuel appairé pour le déploiement de clusters. (C’est utile quand vous avez un certain nombre d’équipes qui déploient des clusters ESP HDInsight.) Cela garantit que vous n’avez pas besoin d’ouvrir des ports (NSG) sur le réseau virtuel avec contrôleur de domaine.
  • Configurez correctement le DNS pour le réseau virtuel (le nom de domaine Microsoft Entra Domain Services doit être résolu sans aucune entrée de fichier d’hôte).
  • Si vous limitez le trafic sortant, vérifiez que vous avez consulté la prise en charge du pare-feu dans HDInsight.

Envisager des jeux de réplicas Microsoft Entra Domain Services

Lorsque vous créez un domaine managé Microsoft Entra Domain Services, vous définissez un espace de noms unique et deux contrôleurs de domaine (DC) sont ensuite déployés dans votre région Azure sélectionnée. Ce déploiement de contrôleurs de domaine est appelé jeu de réplicas. L’ajout d’ensembles de réplica supplémentaires assure la résilience et garantit la disponibilité des services d’authentification, ce qui est essentiel pour les clusters Azure HDInsight.

Configurer la synchronisation utilisateur/groupe délimitée

Lorsque vous activez Microsoft Entra Domain Services pour votre cluster ESP, vous pouvez choisir de synchroniser tous les utilisateurs et groupes de Microsoft Entra ID ou des groupes étendus et leurs membres. Nous vous recommandons de choisir la synchronisation « étendue » pour obtenir les meilleures performances.

La synchronisation étendue peut être modifiée avec différentes sélections de groupes ou convertie en utilisateurs et groupes « Tous » si nécessaire. Vous ne pouvez pas remplacer le type de synchronisation « Tout » par « Étendu », sauf si vous supprimez et recréez l’instance Microsoft Entra Domain Services.

Propriétés synchronisées de Microsoft Entra ID avec Microsoft Entra Domain Services

  • Microsoft Entra Connect synchronise de l’environnement local avec Microsoft Entra ID.
  • Microsoft Entra Domain Services synchronise à partir de Microsoft Entra ID.

Microsoft Entra Domain Services synchronise des objets à partir de Microsoft Entra ID de manière périodique. Le panneau Microsoft Entra Domain Services du Portail Azure affiche l’état de la synchronisation. À chaque étape de la synchronisation, des propriétés uniques peuvent entrer en conflit et être renommées. Soyez attentif au mappage de propriété de Microsoft Entra ID vers Microsoft Entra Domain Services.

Si vous souhaitez obtenir plus d’informations, consultez Remplissage de UserPrincipalName dans Microsoft Entra et Fonctionnement de la synchronisation Microsoft Entra Domain Services.

Synchronisation de hachage de mot de passe

  • Les mots de passe sont synchronisés différemment des autres types d’objets. Seuls les hachages de mot de passe non réversibles sont synchronisés dans Microsoft Entra ID et Microsoft Entra Domain Services
  • La synchronisation de l’environnement local avec Microsoft Entra ID doit être activée via AD Connect
  • La synchronisation de Microsoft Entra ID avec Microsoft Entra Domain Services est automatique (les latences sont de moins de 20 minutes).
  • Les hachages de mot de passe sont synchronisés uniquement en cas de changement du mot de passe. Quand vous activez la synchronisation du hachage de mot de passe, tous les mots de passe existants ne sont pas automatiquement synchronisés, car ils sont stockés de manière irréversible. Quand vous changez le mot de passe, les hachages de mot de passe sont synchronisés.

Définir la synchronisation LDAP Ambari pour qu’elle s’exécute quotidiennement

Le processus de synchronisation des nouveaux utilisateurs LDAP avec Ambari est automatiquement configuré pour s’exécuter toutes les heures. L’exécution de cette opération toutes les heures peut entraîner un excès de charge sur les nœuds principaux du cluster et le instance AD. Pour améliorer les performances, nous vous recommandons de modifier le script /opt/startup_scripts/start_ambari_ldap_sync.py qui exécute la synchronisation LDAP Ambari pour l’exécuter une fois par jour. Ce script est exécuté via un travail crontab. Il est stocké dans le répertoire « /etc/cron.hourly/ » sur les nœuds principaux du cluster.

Pour l’exécuter une fois par jour, procédez comme suit :

  1. Connectez-vous via SSH à hn0
  2. Déplacez le script vers le dossier cron daily : sudo mv /etc/cron.hourly/ambarildapsync /etc/cron.daily/ambarildapsync
  3. Appliquez la modification dans la tâche crontab : sudo service cron reload
  4. ssh vers hn1 et répéter les étapes 1 à 3

Si nécessaire, vous pouvez utiliser l’API REST Ambari pour synchroniser manuellement les nouveaux utilisateurs et groupes immédiatement.

Emplacement d’objets ordinateur

Chaque cluster est associé à une seule unité d’organisation. Un utilisateur interne est provisionné dans l’unité d’organisation. Tous les nœuds sont joints à un domaine dans la même unité d’organisation.

Outils d’administration Active Directory

Pour plus d’informations, consultez Installer les outils de gestion.

Dépannage

Echecs répétés de création du cluster

Raisons les plus courantes :

  • La configuration DNS n’est pas correcte ; la jonction de domaine des nœuds de cluster échoue.
  • Les groupes de sécurité réseau (NSG) sont trop restrictifs, ce qui empêche la jonction de domaine.
  • L’identité managée ne dispose pas des autorisations suffisantes.
  • Le nom du cluster n’est pas unique sur les six premiers caractères (soit en raison d’un autre cluster actif, soit en raison d’un cluster supprimé).

Instauration et configuration de l’authentification

Nom d’utilisateur principal (UPN)

  • Veuillez utiliser des minuscules pour tous les services. Les UPN ne respectent pas la casse dans les clusters ESP, mais
  • Le préfixe UPN doit correspondre au deux valeurs SAMAccountName dans Microsoft Entra Domain Services. La correspondance avec le champ mail n’est pas obligatoire.

Propriétés LDAP dans la configuration Ambari

Pour obtenir la liste complète des propriétés Ambari qui affectent la configuration de votre cluster HDInsight, consultez Configuration de l’authentification LDAP Ambari.

Générer des clés utilisateur de domaine

Toutes les touches de service sont générées automatiquement pour vous pendant le processus de création du cluster ESP. Pour activer la communication sécurisée entre le cluster et d’autres services et/ou travaux qui nécessitent une authentification, vous pouvez générer un keytab pour votre nom d’utilisateur de domaine.

Utilisez le ktutil sur l’une des machines virtuelles de cluster pour créer un keytab Kerberos :


ktutil
ktutil: addent -password -p <username>@<DOMAIN.COM> -k 1 -e aes256-cts-hmac-sha1-96
Password for <username>@<DOMAIN.COM>: <password>
ktutil: wkt <username>.keytab
ktutil: q

Si votre TenantName et DomainName sont différents, vous devez ajouter une valeur SALT en utilisant l’option -s. Consultez la page FAQ HDInsight pour déterminer la valeur SALT appropriée lors de la création d’un keytab Kerberos.

Renouvellement de certificat LDAP

HDInsight renouvelle automatiquement les certificats pour les identités managées que vous utilisez pour les clusters avec le package de sécurité d’entreprise (ESP). Toutefois, il existe une limitation lorsque différentes identités managées sont utilisées pour Microsoft Entra Domain Services et ADLS Gen2, ce qui peut entraîner l’échec du processus de renouvellement. Suivez les 2 recommandations ci-dessous pour vous assurer que nous sommes en mesure de renouveler vos certificats avec succès :

  • Par exemple, si vous avez employé des identités managées différentes pour des clusters ADLS Gen2 et Microsoft Entra Domain Services, les rôles Propriétaire des données Blob du stockage et Contributeur HDInsight Domain Services doivent leur être affectés.
  • Les clusters HDInsight nécessitent des adresses IP publiques pour les mises à jour de certificat et d’autres opérations de maintenance, de sorte que toutes les stratégies qui refusent l’adresse IP publique sur le cluster doivent être supprimées.

Étapes suivantes