Implémenter la sécurité d’accès aux données
HDInsight est un service PaaS, et le modèle le plus implémenté est la séparation totale du calcul et du stockage. Dans les modèles de ce genre, la sécurité d’accès aux données permet de sécuriser les données au repos et de sécuriser le trafic entre HDInsight et la couche de données. Ces zones de sécurité se situent en dehors de la portée des fonctionnalités de sécurité propres à HDInsight, et sont accomplies par des fonctionnalités de sécurité disponibles dans les services de stockage et de réseau Azure. Vous trouverez ci-dessous la liste des recommandations sur la façon dont la sécurité de l’accès aux données peut être obtenue sur les clusters HDInsight. Vous pouvez choisir d’implémenter toutes ou certaines de ces recommandations, en fonction de votre cas d’usage.
Autoriser les requêtes de stockage uniquement à partir de connexions sécurisées
Le transfert sécurisé autorise les requêtes provenant de connexions sécurisées (HTTPS) et rejette toutes les connexions HTTP. Avant de créer le cluster, vous devez activer un transfert sécurisé. Faites glisser le curseur « Transfert sécurisé requis » sur « Activé ». Familiarisez-vous avec les recommandations et les bonnes pratiques en matière de sécurité pour ADLSG2, notamment le transfert sécurisé.
Implémenter des listes de contrôle d’accès (ACL) pour ADLS Gen2
Le modèle de contrôle d’accès ADLS Gen2 prend en charge à la fois le contrôle d’accès en fonction du rôle Azure (RBAC) et le contrôle d’accès de type POSIX (ACL). Vous pouvez choisir d’implémenter le modèle de liste ACL au niveau POSIX pour HDInsight afin de configurer l’authentification directe pour les fichiers et les dossiers. Chaque fichier ou répertoire sur ADLS Gen2 a des autorisations distinctes pour ces identités.
- L’utilisateur propriétaire
- Le groupe propriétaire
- Les utilisateurs nommés
- Les groupes nommés
- Les principaux de service nommés
- Identités managées nommées
- Le contrôle d’accès au niveau POSIX pour les fichiers et dossiers ADLS Gen2 peut donc être accordé aux utilisateurs et aux groupes de domaine HDInsight, et ces autorisations seront respectées par tous les services HDInsight au cours de l’accès. En savoir plus sur le contrôle d’accès dans Azure Data Lake Storage Gen2.
Pare-feu de stockage Azure
Le pare-feu de stockage Azure utilise la stratégie réseau « refuser tout, autoriser par exception » afin de s’assurer que seules les entités autorisées peuvent accéder au compte de stockage. Les pare-feu de stockage peuvent être configurés pour autoriser l’accès au compte à partir d’une adresse IP fixe approuvée ou d’une plage d’adresses IP approuvée prédéterminée. Vérifiez que les services Microsoft approuvés peuvent accéder au compte de stockage afin d’activer des fonctionnalités telles que la journalisation. Vous pouvez activer le Pare-feu Azure sur votre compte de stockage à partir du volet Pare-feu et réseaux virtuels, comme illustré ci-dessous.
TLS (Transport Layer Security) pour un client de stockage en dehors du cluster HDInsight
L’activation du protocole TLS sur le compte de stockage garantit le chiffrement des données en transit vers et à partir du compte de stockage. Le stockage Azure utilise le protocole TLS 1.2 sur les points de terminaison HTTPS publics, mais les protocoles TLS 1.0 et TLS 1.1 sont toujours pris en charge à des fins de compatibilité descendante. Afin de garantir une connexion sécurisée et conforme à Stockage Azure, vous devez activer TL 1.2 ou version ultérieure côté client avant d’envoyer des requêtes au service Stockage Azure. Dans ce cas, TLS 1.2 est déjà activé par défaut lorsqu’un compte de stockage échange des données avec HDInsight, et vous n’avez rien de particulier à faire pour l’activer. Apprenez-en davantage sur la sécurisation TLS pour les clients de stockage Azure.
Points de terminaison de service de réseau virtuel
HDInsight prend en charge les points de terminaison de service de réseau virtuel pour Stockage Blob Azure, Azure Data Lake Storage Gen2, Cosmos DB et SQL Database. Dans le contexte de la sécurité HDInsight, vous pouvez configurer des points de terminaison de service de réseau virtuel sur des comptes de stockage, des metastores de cluster et Cosmos DB afin d’autoriser l’accès uniquement à partir du sous-réseau HDInsight. Le trafic circulant entre ces entités et HDInsight reste toujours sur le réseau principal Azure. Dans le compte de stockage, vous pouvez activer les points de terminaison de service de réseau virtuel à partir du volet Pare-feu et réseaux virtuels en cliquant sur Ajouter un nouveau réseau virtuel/Ajouter un réseau virtuel existant, en sélectionnant la case d’option Autoriser l’accès à partir/vers le réseau sélectionné, puis en fournissant les informations sur le réseau virtuel à partir duquel l’accès doit être autorisé. Dans le cas présent, vous indiqueriez votre réseau virtuel et vos sous-réseaux HDInsight à partir desquels vous souhaitez accéder à ce compte de stockage. Dans l’exemple ci-dessous, le compte de stockage pourra accéder au trafic uniquement à partir des trois sous-réseaux HDInsight qui ont été explicitement spécifiés.
Pour les bases de données SQL, les points de terminaison de service de réseau virtuel peuvent être configurés à partir du volet Pare-feu et réseaux virtuels.
En savoir plus sur les points de terminaison de service de réseau virtuel dans Azure.
Clés gérées par le client
Le chiffrement des données au repos est un incontournable de la sécurité dans les paysages de Big Data. Le stockage Azure chiffre toutes les données dans un compte de stockage à l’aide de clés managées par Microsoft par défaut. Toutefois, les clients peuvent choisir d’apporter leurs propres clés afin de bénéficier d’un contrôle supplémentaire sur leurs données. À partir du portail, le volet Chiffrement sur le compte de stockage sert à déterminer les paramètres clés du compte de stockage. Choisissez Utiliser votre propre clé, puis sélectionnez un URI de clé ou sélectionnez une clé dans le coffre de clés Azure. En savoir plus sur les clés gérées par le client pour le stockage Azure.
De même, pour les clusters Kafka, vous pouvez apporter votre propre clé lors de la création du cluster afin de chiffrer toutes les données des répartiteurs au repos.