Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.
# Chiffrez les données au repos et en transit avec Amazon EMR
Le chiffrement des données vous permet d'empêcher les utilisateurs non autorisés de lire les données d'un cluster et celles des systèmes de stockage de données associés. Cela inclut les données enregistrées sur les supports persistants (données *au repos*) et les données qui peuvent être interceptées alors qu'elles circulent sur le réseau (données *en transit*).
A partir de la version 4.8.0 d'Amazon EMR, vous pouvez utiliser les configurations de sécurité Amazon EMR pour configurer plus facilement les paramètres de chiffrement des données pour les clusters. Les configurations de sécurité proposent des paramètres pour activer la sécurité des données en transit et au repos dans les volumes Amazon Elastic Block Store (Amazon EBS) et d'EMRFS dans Amazon S3.
Le cas échéant, à partir des versions 4.1.0 et ultérieures d'Amazon EMR, vous pouvez choisir de configurer un chiffrement transparent dans HDFS, qui n'est pas configuré à l'aide de configurations de sécurité. Pour plus d'informations, consultez [Chiffrement transparent dans HDFS sur Amazon EMR](https://docs.aws.amazon.com/emr/latest/ReleaseGuide/emr-encryption-tdehdfs.html) dans le *Guide de mise à jour Amazon EMR*.
**Topics**
+ [Options de chiffrement pour Amazon EMR](emr-data-encryption-options.md)
+ [Chiffrement au repos à l'aide d'une clé KMS client pour le service EMR WAL](encryption-at-rest-kms.md)
+ [Créez des clés et des certificats pour le chiffrement des données avec Amazon EMR](emr-encryption-enable.md)
+ [Comprendre le chiffrement en transit](emr-encryption-support-matrix.md)
# Options de chiffrement pour Amazon EMR
Avec les versions 4.8.0 et supérieures d'Amazon EMR, vous pouvez utiliser une configuration de sécurité pour spécifier les paramètres de chiffrement des données au repos, des données en transit, ou les deux. Lorsque vous activez le chiffrement des données au repos, vous pouvez choisir de chiffrer les données EMRFS dans Amazon S3, les données dans les disques locaux, ou les deux. Chaque configuration de sécurité créée est stockée dans Amazon EMR plutôt que dans la configuration du cluster. Dès lors, vous pouvez facilement réutiliser une configuration pour spécifier les paramètres de chiffrement des données chaque fois qu'un cluster est créé. Pour de plus amples informations, veuillez consulter [Créez une configuration de sécurité à l'aide de la console Amazon EMR ou du AWS CLI](emr-create-security-configuration.md).
Le schéma suivant illustre les différentes options de chiffrement des données disponibles avec les configurations de sécurité.
![\[Plusieurs options de chiffrement en transit et au repos sont disponibles avec Amazon EMR.\]](http://docs.aws.amazon.com/fr_fr/emr/latest/ManagementGuide/images/emr-encryption-options.png)
Les options de chiffrement suivantes sont également disponibles et ne sont pas configurées à l'aide d'une configuration de sécurité :
+ Le cas échéant, avec les versions Amazon EMR 4.1.0 et ultérieures, vous pouvez choisir de configurer le chiffrement transparent dans HDFS. Pour plus d'informations, consultez [Chiffrement transparent dans HDFS sur Amazon EMR](https://docs.aws.amazon.com/emr/latest/ReleaseGuide/emr-encryption-tdehdfs.html) dans le *Guide de mise à jour Amazon EMR*.
+ Si vous utilisez une version d'Amazon EMR qui ne prend pas en charge les configurations de sécurité, vous pouvez configurer manuellement le chiffrement pour les données EMRFS dans Amazon S3. Pour plus d'informations, consultez [Spécification du chiffrement Amazon S3 à l'aide des propriétés EMRFS](https://docs.aws.amazon.com/emr/latest/ReleaseGuide/emr-emrfs-encryption.html).
+ Si vous utilisez une version Amazon EMR antérieure à 5.24.0, un volume de périphérique racine EBS chiffré est pris en charge uniquement lorsque vous utilisez une AMI personnalisée. Pour plus d'informations, consultez [Création d'une AMI personnalisée avec un volume de périphérique racine Amazon EBS chiffré](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-custom-ami.html#emr-custom-ami-encrypted) dans le *Guide de gestion Amazon EMR*.
**Note**
À partir de la version 5.24.0 d'Amazon EMR, vous pouvez utiliser une option de configuration de sécurité pour chiffrer le périphérique racine EBS et les volumes de stockage lorsque vous le spécifiez comme fournisseur de clés. AWS KMS Pour de plus amples informations, veuillez consulter [Chiffrement de disque local](#emr-encryption-localdisk).
Le chiffrement des données nécessite des clés et des certificats. Une configuration de sécurité vous donne la flexibilité de choisir entre plusieurs options, notamment les clés gérées par AWS Key Management Service, les clés gérées par Amazon S3 et les clés et certificats fournis par les fournisseurs personnalisés que vous fournissez. Lorsque vous l'utilisez en AWS KMS tant que fournisseur de clés, des frais s'appliquent pour le stockage et l'utilisation des clés de chiffrement. Pour en savoir plus, consultez [Pricing AWS KMS](https://aws.amazon.com/kms/pricing/) (Tarification).
Avant de spécifier les options de chiffrement, choisissez les systèmes de gestion de clés et de certificats que vous voulez utiliser et commencez par créer les clés et les certificats ou les fournisseurs personnalisés que vous définissez dans le cadre des paramètres de chiffrement.
## Chiffrement au repos des données EMRFS dans Amazon S3
Le chiffrement Amazon S3 fonctionne avec les objets du système de fichiers Amazon EMR (EMRFS) lus et écrits sur Amazon S3. Vous indiquez le chiffrement côté serveur (SSE) ou le chiffrement côté client (CSE) sur Amazon S3 comme **Mode de chiffrement par défaut** lorsque vous activez le chiffrement au repos. Le cas échéant, vous pouvez spécifier différentes méthodes de chiffrement pour les compartiments individuels à l'aide de **remplacements de chiffrement par compartiment**. Que le chiffrement Amazon S3 soit activé ou non, le protocole TLS (Transport Layer Security) chiffre les objets EMRFS en transit entre les nœuds de cluster EMR et Amazon S3. Pour plus d'informations sur le chiffrement Amazon S3, consultez la section [Protection des données à l'aide du chiffrement](https://docs.aws.amazon.com/AmazonS3/latest/userguide/UsingEncryption.html) dans le *guide de l'utilisateur d'Amazon Simple Storage Service*.
**Note**
Lorsque vous les utilisez AWS KMS, des frais s'appliquent pour le stockage et l'utilisation des clés de chiffrement. Pour plus d’informations, consultez [Tarification d’AWS KMS](https://aws.amazon.com/kms/pricing/).
### Chiffrement côté serveur sur Amazon S3
Le chiffrement est configuré par défaut pour tous les compartiments Amazon S3, et tous les nouveaux objets chargés dans un compartiment S3 sont automatiquement chiffrés au repos. Amazon S3 chiffre les données au niveau de l'objet lorsqu'il écrit les données sur le disque et les déchiffre lors de l'accès. Pour plus d'informations sur SSE, consultez [Protection des données à l'aide du chiffrement côté serveur](https://docs.aws.amazon.com/AmazonS3/latest/userguide/serv-side-encryption.html) dans le *Guide de l'utilisateur Amazon Simple Storage Service*.
Lorsque vous indiquez le chiffrement SSE sur Amazon EMR, vous pouvez choisir entre deux systèmes de gestion de clés différents :
+ **SSE-S3** – Amazon S3 gère les clés pour vous.
+ **SSE-KMS** — Vous utilisez un AWS KMS key pour configurer des politiques adaptées à Amazon EMR. Pour plus d'informations sur les exigences clés relatives à Amazon EMR, consultez la section [Utilisation à des AWS KMS keys fins](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-encryption-enable.html#emr-awskms-keys) de chiffrement.
Le chiffrement SSE avec des clés fournies par le client (SSE-C) n'est pas disponible pour une utilisation avec Amazon EMR.
### Chiffrement côté client sur Amazon S3
Avec le chiffrement côté client sur Amazon S3, le chiffrement et le déchiffrement par Amazon S3 se déroulent dans le client EMRFS de votre cluster. Les objets sont chiffrés avant d'être chargés sur Amazon S3 et déchiffrés après leur chargement. Le fournisseur que vous indiquez fournit la clé de chiffrement utilisée par le client. Le client peut utiliser les clés fournies par AWS KMS (CSE-KMS) ou une classe Java personnalisée qui fournit la clé racine côté client (CSE-C). Les spécificités du chiffrement sont légèrement différentes entre CSE-KMS et CSE-C, en fonction du fournisseur indiqué et des métadonnées de l'objet à déchiffrer ou à chiffrer. Pour plus d'informations sur ces différences, consultez [Protection des données à l'aide du chiffrement côté client](https://docs.aws.amazon.com/AmazonS3/latest/userguide/UsingClientSideEncryption.html) dans le *Guide de l'utilisateur Amazon Simple Storage Service*.
**Note**
Le chiffrement CSE sur Amazon S3 garantit uniquement que les données EMRFS échangées avec Amazon S3 sont chiffrées ; cela ne signifie pas que toutes les données sur les volumes des instances du cluster sont chiffrées. De plus, étant donné que Hue n'utilise pas EMRFS, les objets que le navigateur de fichiers S3 de Hue écrit sur Amazon S3 ne sont pas chiffrés.
## Chiffrement au repos pour les données dans Amazon EMR WAL
Lorsque vous configurez le chiffrement côté serveur (SSE) pour la journalisation par écriture anticipée (WAL), Amazon EMR chiffre les données au repos. Vous pouvez choisir entre deux systèmes de gestion des clés lorsque vous spécifiez SSE dans Amazon EMR :
**SSE-EMR-WAL**
Amazon EMR gère les clés pour vous. Par défaut, Amazon EMR chiffre les données que vous avez stockées dans Amazon EMR WAL. SSE-EMR-WAL
**SSE-KMS-WAL**
Vous utilisez une AWS KMS clé pour configurer les politiques qui s'appliquent à Amazon EMR WAL. Pour plus d'informations sur la configuration du chiffrement au repos pour EMR WAL à l'aide d'une clé KMS client, voir [Chiffrement au repos à l'aide d'une clé KMS client pour le service EMR](https://docs.aws.amazon.com/emr/latest/ManagementGuide/encryption-at-rest-kms.html) WAL.
**Note**
Vous ne pouvez pas utiliser votre propre clé avec SSE lorsque vous activez le WAL avec Amazon EMR. Pour plus d'informations, consultez la section [Write ahead logs (WAL) pour Amazon EMR](https://docs.aws.amazon.com/emr/latest/ReleaseGuide/emr-hbase-wal.html).
## Chiffrement de disque local
Les mécanismes suivants fonctionnent ensemble pour chiffrer les disques locaux lorsque vous activez le chiffrement de disque local à l'aide d'une configuration de sécurité Amazon EMR.
### Chiffrement HDFS open source
HDFS échange des données entre les instances de cluster pendant le traitement distribué. Il lit et écrit également des données sur les volumes de stockage d'instance et les volumes EBS attachés aux instances. Les options de chiffrement open source Hadoop suivantes sont activées lorsque vous mettez en œuvre le chiffrement de disque local :
+ [Secure Hadoop RPC](https://hadoop.apache.org/docs/r2.7.2/hadoop-project-dist/hadoop-common/SecureMode.html#Data_Encryption_on_RPC) est défini sur `Privacy`, qui utilise Simple Authentication Security Layer (SASL).
+ [Data encryption on HDFS block data transfer](https://hadoop.apache.org/docs/r2.7.2/hadoop-project-dist/hadoop-common/SecureMode.html#Data_Encryption_on_Block_data_transfer.) est défini sur `true` et est configuré pour utiliser le chiffrement AES 256.
**Note**
Vous pouvez activer un chiffrement Apache Hadoop supplémentaire en mettant en activant le chiffrement en transit. Pour de plus amples informations, veuillez consulter [Chiffrement en transit](#emr-encryption-intransit). Ces paramètres de chiffrement n'activent pas le chiffrement transparent HDFS, que vous pouvez configurer manuellement. Pour plus d'informations, consultez [Chiffrement transparent dans HDFS sur Amazon EMR](https://docs.aws.amazon.com/emr/latest/ReleaseGuide/emr-encryption-tdehdfs.html) dans le *Guide de mise à jour Amazon EMR*.
### Chiffrement du stockage d'instance
Pour les types d'instances EC2 dont le volume de stockage SSDs d'instance est NVMe basé, le NVMe chiffrement est utilisé quels que soient les paramètres de chiffrement Amazon EMR. Pour plus d'informations, consultez la section [Volumes NVMe SSD](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ssd-instance-store.html#nvme-ssd-volumes) dans le guide de l'*utilisateur Amazon EC2*. Pour les autres volumes de stockage d'instance, Amazon EMR utilise LUKS pour chiffrer le volume de stockage d'instance lorsque le chiffrement de disque local est activé, que les volumes EBS soient chiffrés à l'aide du chiffrement EBS ou LUKS.
### Chiffrement de volume EBS
Si vous créez un cluster dans une région où le chiffrement Amazon EC2 des volumes EBS est activé par défaut pour votre compte, les volumes EBS sont chiffrés même si le chiffrement de disque local n'est pas activé. Pour plus d’informations, consultez la section [Chiffrement par défaut](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/EBSEncryption.html#encryption-by-default) dans le *Guide de l’utilisateur Amazon EC2*. Lorsque le chiffrement du disque local est activé dans une configuration de sécurité, les paramètres Amazon EMR ont priorité sur les paramètres Amazon EC2 pour les instances du cluster EC2 encryption-by-default.
Les options suivantes sont disponibles pour chiffrer les volumes EBS à l'aide d'une configuration de sécurité :
+ **Chiffrement EBS** : à partir d'Amazon EMR version 5.24.0, vous pouvez choisir d'activer le chiffrement EBS. L'option de chiffrement EBS chiffre le volume du périphérique racine EBS et les volumes de stockage attachés. L'option de chiffrement EBS n'est disponible que lorsque vous le spécifiez AWS Key Management Service comme fournisseur de clés. Nous vous recommandons d'utiliser le chiffrement EBS.
+ **Chiffrement LUKS** – Si vous choisissez d'utiliser le chiffrement LUKS pour les volumes Amazon EBS, le chiffrement LUKS s'applique uniquement aux volumes de stockage attachés, pas au volume du périphérique racine. Pour en savoir plus sur le chiffrement LUKS, consultez la [spécification de LUKS sur le disque](https://gitlab.com/cryptsetup/cryptsetup/wikis/Specification).
Pour votre fournisseur de clés, vous pouvez configurer une AWS KMS key avec des politiques adaptées à Amazon EMR, ou une classe Java personnalisée qui fournit les artefacts de chiffrement. Lorsque vous les utilisez AWS KMS, des frais s'appliquent pour le stockage et l'utilisation des clés de chiffrement. Pour en savoir plus, consultez [Pricing AWS KMS](https://aws.amazon.com/kms/pricing/) (Tarification).
**Note**
Pour vérifier si le chiffrement EBS est activé sur votre cluster, il est recommandé d'utiliser un appel d'API `DescribeVolumes`. Pour de plus amples informations, veuillez consulter [DescribeVolumes](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_DescribeVolumes.html). L'exécution de `lsblk` sur le cluster vérifie uniquement le statut de chiffrement LUKS, au lieu du chiffrement EBS.
## Chiffrement en transit
Plusieurs mécanismes de chiffrement sont activés avec le chiffrement en transit. Il s'agit de fonctionnalités open source, spécifiques à l'application et susceptibles de varier en fonction de la version d'Amazon EMR. Pour activer le chiffrement en transit, utilisez-le [Créez une configuration de sécurité à l'aide de la console Amazon EMR ou du AWS CLI](emr-create-security-configuration.md) dans Amazon EMR. Pour les clusters EMR sur lesquels le chiffrement en transit est activé, Amazon EMR configure automatiquement les configurations des applications open source pour activer le chiffrement en transit. Pour les cas d'utilisation avancés, vous pouvez configurer des configurations d'applications open source directement pour remplacer le comportement par défaut dans Amazon EMR. Pour plus d'informations, consultez la [matrice de prise en charge du chiffrement en transit](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-encryption-support-matrix.html) et la section [Configuration des applications.](https://docs.aws.amazon.com/emr/latest/ReleaseGuide/emr-configure-apps.html)
Consultez ce qui suit pour en savoir plus sur les applications open source pertinentes pour le chiffrement en transit :
+ Lorsque vous activez le chiffrement en transit avec une configuration de sécurité, Amazon EMR active le chiffrement en transit pour tous les points de terminaison des applications open source qui prennent en charge le chiffrement en transit. Support pour le chiffrement en transit pour les différents points de terminaison des applications varie en fonction de la version publiée par Amazon EMR. Pour plus d'informations, consultez la [matrice de prise en charge du chiffrement en transit](https://docs.aws.amazon.com/).
+ Vous pouvez remplacer les configurations open source, ce qui vous permet d'effectuer les opérations suivantes :
+ Désactivez la vérification du nom d'hôte TLS si les certificats TLS fournis par l'utilisateur ne répondent pas aux exigences
+ Désactivez le chiffrement en transit pour certains terminaux en fonction de vos exigences en matière de performances et de compatibilité
+ Contrôlez les versions TLS et les suites de chiffrement à utiliser.
Vous trouverez plus de détails sur les configurations spécifiques à l'application dans la matrice de prise en charge du [chiffrement en transit](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-encryption-support-matrix.html)
+ Outre l'activation du chiffrement en transit avec une configuration de sécurité, certains canaux de communication nécessitent également des configurations de sécurité supplémentaires pour que vous puissiez activer le chiffrement en transit. Par exemple, certains points de terminaison d'applications open source utilisent le protocole SASL (Simple Authentication and Security Layer) pour le chiffrement en transit, ce qui nécessite que l'authentification Kerberos soit activée dans la configuration de sécurité du cluster EMR. Pour en savoir plus sur ces points de terminaison, consultez la matrice de prise en [charge du chiffrement en transit](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-encryption-support-matrix.html).
+ Nous vous recommandons d'utiliser un logiciel compatible avec le protocole TLS v1.2 ou supérieur. Amazon EMR sur EC2 fournit la distribution Corretto JDK par défaut, qui détermine les versions TLS, les suites de chiffrement et les tailles de clés autorisées par les réseaux open source qui s'exécutent sur Java. À l'heure actuelle, la plupart des frameworks open source appliquent le protocole TLS v1.2 ou supérieur pour les versions 7.0.0 et supérieures d'Amazon EMR. Cela est dû au fait que la plupart des frameworks open source s'exécutent sur Java 17 pour Amazon EMR 7.0.0 et versions ultérieures. Les anciennes versions d'Amazon EMR peuvent prendre en charge TLS v1.0 et v1.1 car elles utilisent d'anciennes versions de Java, mais Corretto JDK peut modifier les versions TLS prises en charge par Java, ce qui peut avoir un impact sur les versions Amazon EMR existantes.
Vous spécifiez les objets de chiffrement utilisés pour le chiffrement en transit de l'une des deux façons suivantes : en fournissant un fichier compressé contenant les certificats que vous chargez dans Amazon S3 ou en renvoyant vers une classe Java personnalisée qui fournit les objets de chiffrement. Pour de plus amples informations, veuillez consulter [Fournir des certificats de chiffrement des données en transit avec le chiffrement Amazon EMR](emr-encryption-enable.md#emr-encryption-certificates).
# Chiffrement au repos à l'aide d'une clé KMS client pour le service EMR WAL
Les journaux d'écriture anticipée (WAL) EMR fournissent une assistance clé au client en matière de KMS. encryption-at-rest Voici des informations détaillées sur la manière dont Amazon EMR WAL est intégré à : AWS KMS
Les journaux d'écriture anticipée (WAL) EMR interagissent avec eux AWS lors des opérations suivantes :`CreateWAL`,,,`AppendEdit`,, `ArchiveWALCheckPoint` `CompleteWALFlush` `DeleteWAL` `GetCurrentWALTime``ReplayEdits`, `TrimWAL` `EMR_EC2_DefaultRole` par défaut. Lorsque l'une des opérations précédentes répertoriées est invoquée, le WAL EMR effectue `Decrypt` et contre la clé KMS. `GenerateDataKey`
## Considérations
Tenez compte des points suivants lorsque vous utilisez le chiffrement AWS KMS basé pour EMR WAL :
+ La configuration de chiffrement ne peut pas être modifiée après la création d'un EMR WAL.
+ Lorsque vous utilisez le chiffrement KMS avec votre propre clé KMS, celle-ci doit se trouver dans la même région que votre cluster Amazon EMR.
+ Vous êtes responsable du maintien de toutes les autorisations IAM requises et il est recommandé de ne pas révoquer les autorisations nécessaires pendant la durée de vie du WAL. Sinon, cela provoquera des scénarios de défaillance inattendus, tels que l'impossibilité de supprimer le WAL EMR, car la clé de chiffrement associée n'existe pas.
+ L'utilisation des AWS KMS clés entraîne un coût. Pour en savoir plus, consultez [Pricing AWS Key Management Service](https://aws.amazon.com/kms/pricing/) (Tarification).
## Autorisations IAM requises
Pour utiliser la clé KMS de votre client pour chiffrer le WAL EMR au repos, vous devez vous assurer de définir les autorisations appropriées pour le rôle client EMR WAL et le principal de service EMR WAL. `emrwal.amazonaws.com`
### Autorisations pour le rôle client EMR WAL
Vous trouverez ci-dessous la politique IAM requise pour le rôle de client EMR WAL :
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"kms:Decrypt",
"kms:GenerateDataKey*"
],
"Resource": [
"*"
],
"Sid": "AllowKMSDecrypt"
}
]
}
```
------
Le client EMR WAL sur le cluster EMR sera utilisé par défaut. `EMR_EC2_DefaultRole` Si vous utilisez un rôle différent pour le profil d'instance dans le cluster EMR, assurez-vous que chaque rôle dispose des autorisations appropriées.
Pour plus d'informations sur la gestion de la politique de rôle, reportez-vous à la section [Ajout et suppression d'autorisations d'identité IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_manage-attach-detach.html).
### Autorisations pour la politique des clés KMS
Vous devez attribuer le rôle de client EMR WAL et le service EMR WAL `Decrypt` et l'`GenerateDataKey*`autorisation dans votre politique KMS. Pour en savoir plus sur la gestion des politiques clés, reportez-vous à la section [Politique des clés KMS](https://docs.aws.amazon.com/kms/latest/developerguide/key-policies.html).
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"kms:Decrypt",
"kms:GenerateDataKey*"
],
"Resource": [
"arn:aws:kms:*:123456789012:key/*"
],
"Sid": "AllowKMSDecrypt"
}
]
}
```
------
Le rôle spécifié dans l'extrait peut changer si vous modifiez le rôle par défaut.
## Surveillance de l'interaction entre Amazon EMR WAL et AWS KMS
### Contexte de chiffrement Amazon EMR WAL
Un contexte de chiffrement est un ensemble de paires clé-valeur contenant des données arbitraires non secrètes. Lorsque vous incluez un contexte de chiffrement dans une demande de chiffrement de données, lie AWS KMS cryptographiquement le contexte de chiffrement aux données chiffrées. Pour déchiffrer les données, vous devez transmettre le même contexte de chiffrement.
Dans ses requêtes [GenerateDataKey](https://docs.aws.amazon.com/kms/latest/APIReference/API_GenerateDataKey.html)et [Decrypt](https://docs.aws.amazon.com/kms/latest/APIReference/API_Decrypt.html) à AWS KMS, Amazon EMR WAL utilise un contexte de chiffrement avec une paire nom-valeur identifiant le nom du WAL EMR.
```
"encryptionContext": {
"aws:emrwal:walname": "111222333444555-testworkspace-emrwalclustertest-emrwaltestwalname"
}
```
Vous pouvez utiliser le contexte de chiffrement pour identifier ces opérations cryptographiques dans les enregistrements et journaux d'audit, tels que AWS CloudTrail [Amazon CloudWatch Logs](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-user-guide.html), et comme condition d'autorisation dans les politiques et les autorisations.
# Créez des clés et des certificats pour le chiffrement des données avec Amazon EMR
Avant de spécifier les options de chiffrement à l'aide d'une configuration de sécurité, choisissez le fournisseur que vous souhaitez utiliser pour les clés et les artefacts de chiffrement. Par exemple, vous pouvez utiliser AWS KMS un fournisseur personnalisé que vous créez. Ensuite, créez les clés ou le fournisseur de clés comme décrit dans cette section.
## Fourniture de clés pour chiffrer les données au repos
Vous pouvez utiliser AWS Key Management Service (AWS KMS) ou un fournisseur de clés personnalisé pour le chiffrement des données au repos dans Amazon EMR. Lorsque vous les utilisez AWS KMS, des frais s'appliquent pour le stockage et l'utilisation des clés de chiffrement. Pour en savoir plus, consultez [Pricing AWS KMS](https://aws.amazon.com/kms/pricing/) (Tarification).
Cette rubrique fournit des informations sur la stratégie de clé KMS à utiliser avec Amazon EMR, ainsi que des instructions et des exemples de code pour écrire une classe de fournisseur de clés personnalisé pour le chiffrement Amazon S3. Pour plus d'informations sur la création de clés, consultez [Création de clés](https://docs.aws.amazon.com/kms/latest/developerguide/create-keys.html) dans le *Guide du développeur AWS Key Management Service *.
### Utilisation à AWS KMS keys des fins de chiffrement
La clé de AWS KMS chiffrement doit être créée dans la même région que votre instance de cluster Amazon EMR et les compartiments Amazon S3 utilisés avec EMRFS. Si la clé que vous spécifiez se trouve dans un compte différent de celui que vous utilisez pour configurer un cluster, vous devez spécifier la clé à l'aide de son ARN.
Le rôle du profil d'instance Amazon EC2 doit être autorisé à utiliser la clé KMS que vous spécifiez. Le rôle par défaut du profil d'instance dans Amazon EMR est `EMR_EC2_DefaultRole`. Si vous utilisez un rôle différent pour le profil d'instance, ou si vous utilisez des rôles IAM pour les demandes EMRFS adressées à Amazon S3, assurez-vous que chaque rôle est ajouté en tant qu'utilisateur clé, le cas échéant. Cela donne au rôle des autorisations pour utiliser la clé KMS. Pour plus d'informations, consultez les sections [Utilisation des stratégies de clé](https://docs.aws.amazon.com/kms/latest/developerguide/key-policies.html#key-policy-default-allow-users) dans le *Guide du développeur AWS Key Management Service * et [Configuration des rôles IAM pour les demandes EMRFS adressées à Amazon S3](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-emrfs-iam-roles.html).
Vous pouvez utiliser le AWS Management Console pour ajouter votre profil d'instance ou votre profil d'instance EC2 à la liste des utilisateurs clés pour la clé KMS spécifiée, ou vous pouvez utiliser le AWS CLI ou un AWS SDK pour associer une politique de clé appropriée.
Notez qu'Amazon EMR prend uniquement en charge les [clés KMS symétriques](https://docs.aws.amazon.com/kms/latest/developerguide/concepts.html#symmetric-cmks). Vous ne pouvez pas utiliser une [clé KMS asymétrique](https://docs.aws.amazon.com/kms/latest/developerguide/symmetric-asymmetric.html#asymmetric-cmks) pour chiffrer les données au repos dans un cluster Amazon EMR. Pour savoir si une clés KMS est symétrique ou asymétrique, consultez [Identification de clés KMS symétriques et asymétriques](https://docs.aws.amazon.com/kms/latest/developerguide/find-symm-asymm.html).
La procédure ci-dessous décrit comment ajouter le profil d'instance Amazon EMR par défaut, `EMR_EC2_DefaultRole`, en tant qu'*utilisateur de clé* à l'aide de la AWS Management Console. Elle suppose que vous avez déjà créé une clé KMS. Pour créer une nouvelle clé KMS, consultez [Création de clés](https://docs.aws.amazon.com/kms/latest/developerguide/create-keys.html) dans le *Guide du développeur AWS Key Management Service *.
**Pour ajouter le profil d'instance EC2 pour Amazon EMR à la liste des utilisateurs de clés de chiffrement**
1. Connectez-vous à la console AWS Key Management Service (AWS KMS) AWS Management Console et ouvrez-la à l'adresse [https://console.aws.amazon.com/kms.](https://console.aws.amazon.com/kms)
1. Pour modifier le Région AWS, utilisez le sélecteur de région dans le coin supérieur droit de la page.
1. Sélectionnez l'alias de la clé KMS à modifier.
1. Sur la page de détails de la clé, sous **Key Users (Utilisateurs de clés)**, choisissez **Add (Ajouter)**.
1. Dans la boîte de dialogue **Ajouter des utilisateurs clés** sélectionnez le rôle approprié. Le nom du rôle par défaut est `EMR_EC2_DefaultRole`.
1. Choisissez **Ajouter**.
### Activation du chiffrement EBS en fournissant des autorisations supplémentaires pour les clés KMS
À partir de la version 5.24.0 d'Amazon EMR, vous pouvez chiffrer le périphérique racine EBS et les volumes de stockage à l'aide d'une option de configuration de sécurité. Pour activer cette option, vous devez AWS KMS le spécifier comme fournisseur principal. En outre, vous devez accorder au rôle de service `EMR_DefaultRole` les autorisations nécessaires pour utiliser celles AWS KMS key que vous spécifiez.
Vous pouvez utiliser le AWS Management Console pour ajouter le rôle de service à la liste des utilisateurs clés pour la clé KMS spécifiée, ou vous pouvez utiliser le AWS CLI ou un AWS SDK pour associer une politique de clé appropriée.
La procédure suivante décrit comment utiliser le AWS Management Console pour ajouter le rôle de service Amazon EMR par défaut en `EMR_DefaultRole` tant qu'utilisateur *clé*. Elle suppose que vous avez déjà créé une clé KMS. Pour créer une nouvelle clé KMS, consultez [Création de clés](https://docs.aws.amazon.com/kms/latest/developerguide/create-keys.html) dans le *Guide du développeur AWS Key Management Service *.
**Pour ajouter le rôle de service Amazon EMR à la liste des utilisateurs de clés de chiffrement**
1. Connectez-vous à la console AWS Key Management Service (AWS KMS) AWS Management Console et ouvrez-la à l'adresse [https://console.aws.amazon.com/kms.](https://console.aws.amazon.com/kms)
1. Pour modifier le Région AWS, utilisez le sélecteur de région dans le coin supérieur droit de la page.
1. Sélectionnez **Clés gérées par le client** dans la barre latérale gauche.
1. Sélectionnez l'alias de la clé KMS à modifier.
1. Sur la page de détails de la clé, sous **Key Users (Utilisateurs de clés)**, choisissez **Add (Ajouter)**.
1. Dans la section **Ajouter des utilisateurs clés**, sélectionnez le rôle approprié. Le nom du rôle de service par défaut pour Amazon EMR est. `EMR_DefaultRole`
1. Choisissez **Ajouter**.
### Création d'un fournisseur de clés personnalisé
Lorsque vous utilisez une configuration de sécurité, vous devez spécifier un autre nom de classe de fournisseur pour le chiffrement de disque local et le chiffrement Amazon S3. Les exigences relatives au fournisseur de clés personnalisées dépendent de l'utilisation du chiffrement de disque local et du chiffrement Amazon S3, ainsi que de la version publiée par Amazon EMR.
Selon le type de chiffrement que vous utilisez lors de la création d'un fournisseur de clés personnalisé, l'application doit également implémenter différentes EncryptionMaterialsProvider interfaces. Les deux interfaces sont disponibles dans le AWS SDK pour Java version 1.11.0 et versions ultérieures.
+ Pour implémenter le chiffrement Amazon S3, utilisez le fichier [com.amazonaws.services.s3.model. EncryptionMaterialsProvider ](https://docs.aws.amazon.com/AWSJavaSDK/latest/javadoc/com/amazonaws/services/s3/model/EncryptionMaterialsProvider.html)interface.
+ Pour implémenter le chiffrement du disque local, utilisez le fichier [com.amazonaws.services.elasticmapreduce.spi.security. EncryptionMaterialsProvider ](https://docs.aws.amazon.com/AWSJavaSDK/latest/javadoc/com/amazonaws/services/elasticmapreduce/spi/security/EncryptionMaterialsProvider.html)interface.
Vous pouvez utiliser n'importe quelle stratégie pour fournir du matériel de chiffrement pour la mise en œuvre. Par exemple, vous pouvez choisir de fournir du matériel de chiffrement statique ou de l'intégrer à un système de gestion de clés plus complexe.
Si vous utilisez le chiffrement Amazon S3, vous devez utiliser les algorithmes de chiffrement **AES/GCM/NoPadding**pour le matériel de chiffrement personnalisé.
Si vous utilisez le chiffrement de disque local, l'algorithme de chiffrement à utiliser pour le matériel de chiffrement personnalisé varie selon la version de l'EMR. Pour Amazon EMR 7.0.0 et versions antérieures, vous devez utiliser. **AES/GCM/NoPadding** **Pour Amazon EMR 7.1.0 et versions ultérieures, vous devez utiliser AES.**
La EncryptionMaterialsProvider classe obtient le matériel de chiffrement par contexte de chiffrement. Amazon EMR renseigne les informations contextuelles de chiffrement au moment de l'exécution pour aider l'appelant à déterminer les matériaux de chiffrement à renvoyer.
**Example Exemple : utilisation d'un fournisseur de clés personnalisé pour le chiffrement Amazon S3 avec EMRFS**
Lorsqu'Amazon EMR extrait les matériaux de chiffrement de la EncryptionMaterialsProvider classe pour effectuer le chiffrement, EMRFS remplit éventuellement l'argument MaterialsDescription avec deux champs : l'URI Amazon S3 pour l'objet et JobFlowId l'URI du cluster, qui peuvent être utilisés par la classe pour renvoyer du matériel de chiffrement de manière sélective. EncryptionMaterialsProvider
Par exemple, le fournisseur peut renvoyer des clés différentes pour différents préfixes d'URI Amazon S3. C'est la description des matériaux de chiffrement renvoyés qui est finalement stockée avec l'objet Amazon S3 plutôt que la valeur materialsDescription qui est générée par EMRFS et transmise au fournisseur. Lors du déchiffrement d'un objet Amazon S3, la description du matériel de chiffrement est transmise à la EncryptionMaterialsProvider classe, afin qu'elle puisse, à nouveau, renvoyer de manière sélective la clé correspondante pour déchiffrer l'objet.
Une implémentation EncryptionMaterialsProvider de référence est fournie ci-dessous. Un autre fournisseur personnalisé est disponible auprès de GitHub. [EMRFSRSAEncryptionMaterialsProvider](https://github.com/awslabs/emr-sample-apps/tree/master/emrfs-plugins/EMRFSRSAEncryptionMaterialsProvider)
```
import com.amazonaws.services.s3.model.EncryptionMaterials;
import com.amazonaws.services.s3.model.EncryptionMaterialsProvider;
import com.amazonaws.services.s3.model.KMSEncryptionMaterials;
import org.apache.hadoop.conf.Configurable;
import org.apache.hadoop.conf.Configuration;
import java.util.Map;
/**
* Provides KMSEncryptionMaterials according to Configuration
*/
public class MyEncryptionMaterialsProviders implements EncryptionMaterialsProvider, Configurable{
private Configuration conf;
private String kmsKeyId;
private EncryptionMaterials encryptionMaterials;
private void init() {
this.kmsKeyId = conf.get("my.kms.key.id");
this.encryptionMaterials = new KMSEncryptionMaterials(kmsKeyId);
}
@Override
public void setConf(Configuration conf) {
this.conf = conf;
init();
}
@Override
public Configuration getConf() {
return this.conf;
}
@Override
public void refresh() {
}
@Override
public EncryptionMaterials getEncryptionMaterials(Map materialsDescription) {
return this.encryptionMaterials;
}
@Override
public EncryptionMaterials getEncryptionMaterials() {
return this.encryptionMaterials;
}
}
```
## Fournir des certificats de chiffrement des données en transit avec le chiffrement Amazon EMR
Avec la version 4.8.0 d'Amazon EMR ou une version ultérieure, deux options s'offrent à vous afin de spécifier les artefacts pour le chiffrement des données en transit à l'aide d'une configuration de sécurité :
+ Vous pouvez créer manuellement les certificats PEM, les inclure dans un fichier zip, puis référencer le fichier zip dans Amazon S3.
+ Vous pouvez implémenter un fournisseur de certificats personnalisés en tant que classe Java. Vous spécifiez le fichier JAR de l'application dans Amazon S3 puis vous fournissez le nom de classe complet du fournisseur, comme déclaré dans l'application. La classe doit implémenter l'interface [TLSArtifactsProvider](https://docs.aws.amazon.com/AWSJavaSDK/latest/javadoc/com/amazonaws/services/elasticmapreduce/spi/security/TLSArtifactsProvider.html) disponible à partir de la AWS SDK pour Java version 1.11.0.
Amazon EMR télécharge automatiquement les objets sur chaque nœud du cluster et les utilise ultérieurement pour mettre en œuvre les fonctionnalités de chiffrement open source en transit. Pour plus d'informations sur les options disponibles, consultez [Chiffrement en transit](emr-data-encryption-options.md#emr-encryption-intransit).
### Utilisation des certificats PEM
Lorsque vous spécifiez un fichier zip pour le chiffrement en transit, la configuration de sécurité s'attend à ce que les fichiers PEM contenus dans ce fichier zip aient exactement le même nom que ci-dessous :
**Certificats de chiffrement en transit**
| Nom de fichier | Obligatoire/facultatif | Détails |
| --- | --- | --- |
| privateKey.pem | Obligatoire | Clé privée |
| certificateChain.pem | Obligatoire | Chaîne de certificats |
| trustedCertificates.pem | Facultatif | Nous vous recommandons de fournir un certificat qui n'est pas signé par l'autorité de certification racine sécurisée (CA) par défaut de Java ou par une autorité de certification intermédiaire pouvant être liée à l'autorité de certification racine approuvée par défaut de Java. Nous vous déconseillons d'utiliser le mode public CAs lorsque vous utilisez des certificats génériques ou lorsque vous désactivez la vérification du nom d'hôte. |
Nous vous recommandons de configurer le fichier PEM de la clé privée de sorte qu'il joue le rôle de certificat générique permettant d'accéder au domaine Amazon VPC dans lequel se trouvent vos instances de cluster. Par exemple, si le cluster se trouve dans us-east-1 (N. Virginia), vous pourriez définir un nom commun dans la configuration du certificat qui autorise l'accès au cluster en spécifiant `CN=*.ec2.internal` dans la définition d'objet de ce certificat. Si votre cluster se trouve dans la région us-west-2 (Oregon), vous pouvez spécifier `CN=*.us-west-2.compute.internal`.
Si le fichier PEM fourni dans l'artefact de chiffrement ne contient pas de caractère générique pour le domaine dans le nom commun, vous devez modifier la valeur de en. `hadoop.ssl.hostname.verifier` `ALLOW_ALL` Pour ce faire, dans les versions 7.3.0 et supérieures d'Amazon EMR, ajoutez la `core-site` classification lorsque vous soumettez des configurations à un cluster. Dans les versions antérieures à 7.3.0, ajoutez la configuration `"hadoop.ssl.hostname.verifier": "ALLOW_ALL"` directement dans le `core-site.xml` fichier. Cette modification est nécessaire car le vérificateur de nom d'hôte par défaut nécessite un nom d'hôte sans caractère générique, car tous les hôtes du cluster l'utilisent. Pour plus d'informations sur la configuration d'un cluster EMR au sein d'un Amazon VPC, consultez [Configuration de la mise en réseau dans un VPC pour Amazon EMR](emr-plan-vpc-subnet.md).
L'exemple suivant montre comment utiliser [OpenSSL](https://www.openssl.org/) pour générer un certificat X.509 auto-signé avec une clé privée RSA de 2048 bits. La clé autorise l'accès aux instances de cluster Amazon EMR de l'émetteur dans la région `us-west-2` (Oregon), comme spécifié par le nom de domaine `*.us-west-2.compute.internal` comme nom commun.
D'autres éléments d'objet facultatifs tels que le pays (C), l'état (S), la langue (L), etc. sont spécifiés. Comme un certificat auto-signé est généré, la deuxième commande dans l'exemple copie le fichier `certificateChain.pem` dans le fichier `trustedCertificates.pem`. La troisième commande utilise `zip` pour créer le fichier `my-certs.zip` qui contient les certificats.
**Important**
Cet exemple n'est qu'une proof-of-concept démonstration. L'utilisation de certificats auto-signés n'est pas recommandé et présente un risque de sécurité potentiel. Pour les systèmes de production, utilisez une autorité de certification (CA) approuvée pour émettre des certificats.
```
$ openssl req -x509 -newkey rsa:2048 -keyout privateKey.pem -out certificateChain.pem -days 365 -nodes -subj '/C=US/ST=Washington/L=Seattle/O=MyOrg/OU=MyDept/CN=*.us-west-2.compute.internal'
$ cp certificateChain.pem trustedCertificates.pem
$ zip -r -X my-certs.zip certificateChain.pem privateKey.pem trustedCertificates.pem
```
# Comprendre le chiffrement en transit
Vous pouvez configurer un cluster EMR pour exécuter des frameworks open source tels qu'[Apache Spark](https://aws.amazon.com/emr/features/spark/), [Apache Hive](https://aws.amazon.com/emr/features/hive/) et [Presto](https://aws.amazon.com/emr/features/presto/). Chacun de ces frameworks open source comporte un ensemble de processus exécutés sur les instances EC2 d'un cluster. Chacun de ces processus peut héberger des points de terminaison réseau pour les communications réseau.
Si le chiffrement en transit est activé sur un cluster EMR, les différents points de terminaison du réseau utilisent des mécanismes de chiffrement différents. Consultez les sections suivantes pour en savoir plus sur les points de terminaison du réseau open source spécifiques pris en charge par le chiffrement en transit, les mécanismes de chiffrement associés et la version d'Amazon EMR qui a ajouté cette prise en charge. Chaque application open source peut également avoir des bonnes pratiques et des configurations de framework open source différentes que vous pouvez modifier.
Pour une couverture maximale du chiffrement en transit, nous vous recommandons d'activer à la fois le chiffrement en transit et Kerberos. Si vous activez uniquement le chiffrement en transit, le chiffrement en transit ne sera disponible que pour les points de terminaison du réseau qui prennent en charge le protocole TLS. Kerberos est nécessaire car certains points de terminaison réseau open source utilisent le protocole SASL (Simple Authentication and Security Layer) pour le chiffrement en transit.
Notez que les frameworks open source non pris en charge dans les versions 7.x.x d'Amazon EMR ne sont pas inclus.
## Spark
Lorsque vous activez le chiffrement en transit dans les configurations de sécurité, `spark.authenticate` il est automatiquement configuré `true` et utilise le chiffrement AES pour les connexions RPC.
À partir d'Amazon EMR 7.3.0, si vous utilisez le chiffrement en transit et l'authentification Kerberos, vous ne pouvez pas utiliser les applications Spark qui dépendent du métastore Hive. Hive 3 résout ce problème dans [HIVE-16340](https://issues.apache.org/jira/browse/HIVE-16340). [HIVE-44114](https://issues.apache.org/jira/browse/SPARK-44114) résout complètement ce problème lorsque Spark open source peut passer à Hive 3. En attendant, vous pouvez configurer `hive.metastore.use.SSL` `false` pour contourner ce problème. Pour plus d'informations, consultez [Configuration des applications](https://docs.aws.amazon.com/emr/latest/ReleaseGuide/emr-configure-apps.html).
Pour plus d'informations, consultez la section [Sécurité de Spark](https://spark.apache.org/docs/latest/security) dans la documentation d'Apache Spark.
| Composant | Endpoint | Port | Mécanisme de chiffrement en transit | Supporté depuis la sortie |
| --- | --- | --- | --- | --- |
| Serveur d'historique Spark | spark.ssl.history.port | 18480 | TLS | emr-5.3.0\$1, emr-6,0.0\$1, emr-7,0.0\$1 |
| Interface utilisateur Spark | spark.ui.port | 4440 | TLS | emr-5.3.0\$1, emr-6,0.0\$1, emr-7,0.0\$1 |
| Pilote Spark | spark.driver.port | Répartition dynamique | Chiffrement basé sur Spark AES | emr-4.8.0\$1, emr-5.0.0\$1, emr-6,0.0\$1, emr-7,0.0\$1 |
| Exécuteur Spark | Port de l'exécuteur (aucune configuration nommée) | Répartition dynamique | Chiffrement basé sur Spark AES | emr-4.8.0\$1, emr-5.0.0\$1, emr-6,0.0\$1, emr-7,0.0\$1 |
| LAINE NodeManager | spark.shuffle.service.port 1 | 7337 | Chiffrement basé sur Spark AES | emr-4.8.0\$1, emr-5.0.0\$1, emr-6,0.0\$1, emr-7,0.0\$1 |
1 `spark.shuffle.service.port` est hébergé sur YARN NodeManager mais n'est utilisé que par Apache Spark.
**Problème connu**
Sur les clusters activés en transit, `spark.yarn.historyServer.address` la configuration utilise actuellement le port`18080`, ce qui empêche l'accès à l'interface utilisateur de l'application Spark à l'aide de l'URL de suivi YARN. **Affecte la version :** EMR - 7.3.0 à EMR - 7.9.0.
Utilisez la solution de contournement suivante :
1. Modifiez la `spark.yarn.historyServer.address` configuration `/etc/spark/conf/spark-defaults.conf` pour utiliser le numéro de `HTTPS` port `18480` sur un cluster en cours d'exécution.
1. Cela peut également être fourni lors des remplacements de configuration lors du lancement du cluster.
Exemple de configuration :
```
[
{
"Classification": "spark-defaults",
"Properties": {
"spark.yarn.historyServer.address": "${hadoopconf-yarn.resourcemanager.hostname}:18480"
}
}
]
```
## FIL Hadoop
Le protocole [RPC sécurisé Hadoop](https://hadoop.apache.org/docs/r2.7.2/hadoop-project-dist/hadoop-common/SecureMode.html#Data_Encryption_on_RPC) est configuré `privacy` et utilise le chiffrement en transit basé sur le protocole SASL. Cela nécessite que l'authentification Kerberos soit activée dans la configuration de sécurité. Si vous ne souhaitez pas de chiffrement en transit pour Hadoop RPC, configurez. `hadoop.rpc.protection = authentication` Nous vous recommandons d'utiliser la configuration par défaut pour une sécurité maximale.
Si vos certificats TLS ne répondent pas aux exigences de vérification du nom d'hôte TLS, vous pouvez configurer. `hadoop.ssl.hostname.verifier = ALLOW_ALL` Nous vous recommandons d'utiliser la configuration par défaut de`hadoop.ssl.hostname.verifier = DEFAULT`, qui applique la vérification du nom d'hôte TLS.
Pour désactiver le protocole HTTPS pour les points de terminaison de l'application Web YARN, configurez`yarn.http.policy = HTTP_ONLY`. Ainsi, le trafic vers ces points de terminaison n'est pas chiffré. Nous vous recommandons d'utiliser la configuration par défaut pour une sécurité maximale.
Pour plus d'informations, consultez [Hadoop en mode sécurisé](https://hadoop.apache.org/docs/r2.7.2/hadoop-project-dist/hadoop-common/SecureMode.html) dans la documentation Apache Hadoop.
| Composant | Endpoint | Port | Mécanisme de chiffrement en transit | Supporté depuis la sortie |
| --- | --- | --- | --- | --- |
| ResourceManager | yarn.resourcemanager.webapp.address | 8088 | TLS | emr-7,3.0\$1 |
| ResourceManager | yarn.resourcemanager.resource-tracker.address | 8025 | SASL \$1 Kerberos | emr-4.8.0\$1, emr-5.0.0\$1, emr-6,0.0\$1, emr-7,0.0\$1 |
| ResourceManager | yarn.resourcemanager.scheduler.address | 8030 | SASL \$1 Kerberos | emr-4.8.0\$1, emr-5.0.0\$1, emr-6,0.0\$1, emr-7,0.0\$1 |
| ResourceManager | yarn.resourcemanager.address | 8032 | SASL \$1 Kerberos | emr-4.8.0\$1, emr-5.0.0\$1, emr-6,0.0\$1, emr-7,0.0\$1 |
| ResourceManager | yarn.resourcemanager.admin.address | 8033 | SASL \$1 Kerberos | emr-4.8.0\$1, emr-5.0.0\$1, emr-6,0.0\$1, emr-7,0.0\$1 |
| TimelineServer | yarn.timeline-service.address | 10200 | SASL \$1 Kerberos | emr-4.8.0\$1, emr-5.0.0\$1, emr-6,0.0\$1, emr-7,0.0\$1 |
| TimelineServer | yarn.timeline-service.webapp.address | 8188 | TLS | emr-7,3.0\$1 |
| WebApplicationProxy | yarn.web-proxy.address | 20888 | SASL \$1 Kerberos | emr-4.8.0\$1, emr-5.0.0\$1, emr-6,0.0\$1, emr-7,0.0\$1 |
| NodeManager | yarn.nodemanager.address | 8041 | SASL \$1 Kerberos | emr-4.8.0\$1, emr-5.0.0\$1, emr-6,0.0\$1, emr-7,0.0\$1 |
| NodeManager | yarn.nodemanager.localizer.address | 8040 | SASL \$1 Kerberos | emr-4.8.0\$1, emr-5.0.0\$1, emr-6,0.0\$1, emr-7,0.0\$1 |
| NodeManager | yarn.nodemanager.webapp.address | 8044 | TLS | emr-7,3.0\$1 |
| NodeManager | mapreduce.shuffle.port 1 | 13562 | TLS | emr-4.8.0\$1, emr-5.0.0\$1, emr-6,0.0\$1, emr-7,0.0\$1 |
| NodeManager | spark.shuffle.service.port 2 | 7337 | Chiffrement basé sur Spark AES | emr-4.8.0\$1, emr-5.0.0\$1, emr-6,0.0\$1, emr-7,0.0\$1 |
1 `mapreduce.shuffle.port` est hébergé sur YARN NodeManager mais n'est utilisé que par Hadoop MapReduce.
2 `spark.shuffle.service.port` est hébergé sur YARN NodeManager mais n'est utilisé que par Apache Spark.
**Problème connu**
La `yarn.log.server.url` configuration dans utilise actuellement le protocole HTTP avec le port 19888, ce qui empêche l'accès aux journaux des applications depuis l'interface utilisateur du gestionnaire de ressources. **Affecte la version :** EMR - 7.3.0 à EMR - 7.8.0.
Utilisez la solution de contournement suivante :
1. Modifiez la `yarn.log.server.url` configuration `yarn-site.xml` pour utiliser le `HTTPS` protocole et le numéro de port`19890`.
1. Redémarrez le gestionnaire de ressources YARN :`sudo systemctl restart hadoop-yarn-resourcemanager.service`.
## Hadoop HDFS
Le nœud de nom, le nœud de données et le nœud de journal Hadoop prennent tous en charge le protocole TLS par défaut si le chiffrement en transit est activé dans les clusters EMR.
Le protocole [RPC sécurisé Hadoop](https://hadoop.apache.org/docs/r2.7.2/hadoop-project-dist/hadoop-common/SecureMode.html#Data_Encryption_on_RPC) est configuré sur `privacy` et utilise le chiffrement en transit basé sur le protocole SASL. Cela nécessite que l'authentification Kerberos soit activée dans la configuration de sécurité.
Nous vous recommandons de ne pas modifier les ports par défaut utilisés pour les points de terminaison HTTPS.
[Le chiffrement des données lors du transfert par blocs HDFS utilise](https://hadoop.apache.org/docs/r2.7.2/hadoop-project-dist/hadoop-common/SecureMode.html#Data_Encryption_on_Block_data_transfer.) la norme AES 256 et nécessite que le chiffrement au repos soit activé dans la configuration de sécurité.
Pour plus d'informations, consultez [Hadoop en mode sécurisé](https://hadoop.apache.org/docs/r2.7.2/hadoop-project-dist/hadoop-common/SecureMode.html) dans la documentation Apache Hadoop.
| Composant | Endpoint | Port | Mécanisme de chiffrement en transit | Supporté depuis la sortie |
| --- | --- | --- | --- | --- |
| Nœud de nom | dfs.namenode.https-address | 9871 | TLS | emr-4.8.0\$1, emr-5.0.0\$1, emr-6,0.0\$1, emr-7,0.0\$1 |
| Nœud de nom | dfs.namenode.rpc-address | 8020 | SASL \$1 Kerberos | emr-4.8.0\$1, emr-5.0.0\$1, emr-6,0.0\$1, emr-7,0.0\$1 |
| Nœud de données | dfs.datanode.https.address | 9865 | TLS | emr-4.8.0\$1, emr-5.0.0\$1, emr-6,0.0\$1, emr-7,0.0\$1 |
| Nœud de données | dfs.datanode.address | 9866 | SASL \$1 Kerberos | emr-4.8.0\$1, emr-5.0.0\$1, emr-6,0.0\$1, emr-7,0.0\$1 |
| Nœud de journal | adresse dfs.journalnode.https | 8481 | TLS | emr-4.8.0\$1, emr-5.0.0\$1, emr-6,0.0\$1, emr-7,0.0\$1 |
| Nœud de journal | dfs.journalnode.rpc | 8485 | SASL \$1 Kerberos | emr-4.8.0\$1, emr-5.0.0\$1, emr-6,0.0\$1, emr-7,0.0\$1 |
| DFSZKFailoverContrôleur | dfs.ha.zkfc.port | 8019 | Aucune | TLS pour ZKFC n'est pris en charge que dans Hadoop 3.4.0. Consultez [HADOOP-18919](https://issues.apache.org/jira/browse/HADOOP-18919) pour plus d'informations. La version 7.1.0 d'Amazon EMR est actuellement sur Hadoop 3.3.6. Les versions supérieures d'Amazon EMR seront disponibles sur Hadoop 3.4.0 à l'avenir |
## Hadoop MapReduce
Hadoop MapReduce, le serveur d'historique des tâches et MapReduce Shuffle prennent tous en charge le protocole TLS par défaut lorsque le chiffrement en transit est activé dans les clusters EMR.
Le [shuffle MapReduce chiffré Hadoop utilise](https://hadoop.apache.org/docs/r2.7.1/hadoop-mapreduce-client/hadoop-mapreduce-client-core/EncryptedShuffle.html) le protocole TLS.
Nous vous recommandons de ne pas modifier les ports par défaut pour les points de terminaison HTTPS.
Pour plus d'informations, consultez [Hadoop en mode sécurisé](https://hadoop.apache.org/docs/r2.7.2/hadoop-project-dist/hadoop-common/SecureMode.html) dans la documentation Apache Hadoop.
| Composant | Endpoint | Port | Mécanisme de chiffrement en transit | Supporté depuis la sortie |
| --- | --- | --- | --- | --- |
| JobHistoryServer | mapreduce.jobhistory.webapp.https.address | 19890 | TLS | emr-7,3.0\$1 |
| LAINE NodeManager | mapreduce.shuffle.port 1 | 13562 | TLS | emr-4.8.0\$1, emr-5.0.0\$1, emr-6,0.0\$1, emr-7,0.0\$1 |
1 `mapreduce.shuffle.port` est hébergé sur YARN NodeManager mais n'est utilisé que par Hadoop MapReduce.
## Presto
[Dans les versions 5.6.0 et supérieures d'Amazon EMR, la communication interne entre le coordinateur Presto et les employés utilise le protocole TLS. Amazon EMR définit toutes les configurations requises pour permettre une communication interne sécurisée dans Presto.](https://prestodb.io/docs/current/security/internal-communication.html)
Si le connecteur utilise le métastore Hive comme magasin de métadonnées, les communications entre le communicateur et le métastore Hive sont également chiffrées avec le protocole TLS.
| Composant | Endpoint | Port | Mécanisme de chiffrement en transit | Supporté depuis la sortie |
| --- | --- | --- | --- | --- |
| Coordinateur Presto | serveur.https.port | 8446 | TLS | emr-5.6.0\$1, emr-6,0.0\$1, emr-7.0.0\$1 |
| Presto Worker | serveur.https.port | 8446 | TLS | emr-5.6.0\$1, emr-6,0.0\$1, emr-7.0.0\$1 |
## Trino
[Dans les versions 6.1.0 et supérieures d'Amazon EMR, la communication interne entre le coordinateur Presto et les employés utilise le protocole TLS. Amazon EMR définit toutes les configurations requises pour permettre une communication interne sécurisée dans Trino.](https://trino.io/docs/current/security/internal-communication.html)
Si le connecteur utilise le métastore Hive comme magasin de métadonnées, les communications entre le communicateur et le métastore Hive sont également chiffrées avec le protocole TLS.
| Composant | Endpoint | Port | Mécanisme de chiffrement en transit | Supporté depuis la sortie |
| --- | --- | --- | --- | --- |
| Coordinateur Trino | serveur.https.port | 8446 | TLS | emr-6,1.0\$1, emr-7,0.0\$1 |
| Travailleur de Trino | serveur.https.port | 8446 | TLS | emr-6,1.0\$1, emr-7,0.0\$1 |
## Hive et Tez
Par défaut, le serveur Hive 2, le serveur Hive Metastore, l'interface utilisateur Web Hive LLAP Daemon et le Hive LLAP shuffle prennent tous en charge le protocole TLS lorsque le chiffrement en transit est activé dans les clusters EMR. Pour plus d'informations sur les configurations Hive, consultez la section [Propriétés de configuration](https://cwiki.apache.org/confluence/display/Hive/Configuration+Properties).
L'interface utilisateur Tez hébergée sur le serveur Tomcat est également compatible HTTPS lorsque le chiffrement en transit est activé dans le cluster EMR. Cependant, le protocole HTTPS est désactivé pour le service d'interface utilisateur Web Tez AM, de sorte que les utilisateurs AM n'ont pas accès au fichier keystore pour l'écouteur SSL qui s'ouvre. Vous pouvez également activer ce comportement avec les configurations `tez.am.tez-ui.webservice.enable.ssl` booléennes et. `tez.am.tez-ui.webservice.enable.client.auth`
| Composant | Endpoint | Port | Mécanisme de chiffrement en transit | Supporté depuis la sortie |
| --- | --- | --- | --- | --- |
| HiveServer2 | hive.server2.thrift.port | 10 000 | TLS | emr-6,9,0\$1, emr-7,0.0\$1 |
| HiveServer2 | hive.server2.thrift.http.port | 10001 | TLS | emr-6,9,0\$1, emr-7,0.0\$1 |
| HiveServer2 | hive.server2.webui.port | 10002 | TLS | emr-7,3.0\$1 |
| HiveMetastoreServer | hive.metastore.port | 9083 | TLS | emr-7,3.0\$1 |
| Démon LLAP | hive.llap.daemon.yarn.shuffle.port | 15551 | TLS | emr-7,3.0\$1 |
| Démon LLAP | hive.llap.daemon.web.port | 15002 | TLS | emr-7,3.0\$1 |
| Démon LLAP | hive.llap.daemon.output.service.port | 15003 | Aucune | Hive ne prend pas en charge le chiffrement en transit pour ce point de terminaison |
| Démon LLAP | hive.llap.management.rpc.port | 15004 | Aucune | Hive ne prend pas en charge le chiffrement en transit pour ce point de terminaison |
| Démon LLAP | hive.llap.plugin.rpc.port | Répartition dynamique | Aucune | Hive ne prend pas en charge le chiffrement en transit pour ce point de terminaison |
| Démon LLAP | hive.llap.daemon.rpc.port | Répartition dynamique | Aucune | Hive ne prend pas en charge le chiffrement en transit pour ce point de terminaison |
| Web HCat | templeton.port | 50111 | TLS | emr-7,3.0\$1 |
| Maître d'application Tez | tez.am.client.am.port-range tez.am.task.am.port-range | Répartition dynamique | Aucune | Tez ne prend pas en charge le chiffrement en transit pour ce point de terminaison |
| Maître d'application Tez | tez.am.tez-ui.webservice.port-range | Répartition dynamique | Aucune | Ce paramètre est désactivé par défaut. Peut être activé à l'aide des configurations Tez dans emr-7.3.0\$1 |
| Tâche Tez | N/A - non configurable | Répartition dynamique | Aucune | Tez ne prend pas en charge le chiffrement en transit pour ce point de terminaison |
| Interface utilisateur Tez | Configurable via le serveur Tomcat sur lequel l'interface utilisateur de Tez est hébergée | 8080 | TLS | emr-7,3.0\$1 |
## Flink
Les points de terminaison REST Apache Flink et les communications internes entre les processus Flink prennent en charge le protocole TLS par défaut lorsque vous activez le chiffrement en transit dans les clusters EMR.
[https://nightlies.apache.org/flink/flink-docs-release-1.18/docs/deployment/config/#security-ssl-internal-enabled](https://nightlies.apache.org/flink/flink-docs-release-1.18/docs/deployment/config/#security-ssl-internal-enabled)est configuré `true` et utilise le chiffrement en transit pour les communications internes entre les processus Flink. Si vous ne souhaitez pas que les communications internes soient chiffrées en transit, désactivez cette configuration. Nous vous recommandons d'utiliser la configuration par défaut pour une sécurité maximale.
Amazon EMR définit `true` et utilise le chiffrement en transit [https://nightlies.apache.org/flink/flink-docs-release-1.18/docs/deployment/config/#security-ssl-rest-enabled](https://nightlies.apache.org/flink/flink-docs-release-1.18/docs/deployment/config/#security-ssl-rest-enabled)pour les points de terminaison REST. En outre, Amazon EMR est également défini sur true [https://nightlies.apache.org/flink/flink-docs-release-1.18/docs/deployment/config/#historyserver-web-ssl-enabled](https://nightlies.apache.org/flink/flink-docs-release-1.18/docs/deployment/config/#historyserver-web-ssl-enabled)pour utiliser la communication TLS avec le serveur d'historique Flink. Si vous ne souhaitez pas que les points REST soient chiffrés en transit, désactivez ces configurations. Nous vous recommandons d'utiliser la configuration par défaut pour une sécurité maximale.
Amazon EMR utilise [https://nightlies.apache.org/flink/flink-docs-release-1.18/docs/deployment/config/#security-ssl-algorithms](https://nightlies.apache.org/flink/flink-docs-release-1.18/docs/deployment/config/#security-ssl-algorithms). pour spécifier la liste des chiffrements utilisant le chiffrement AES. Remplacez cette configuration pour utiliser les chiffrements souhaités.
Pour plus d'informations, consultez la section [Configuration SSL](https://nightlies.apache.org/flink/flink-docs-release-1.18/docs/deployment/security/security-ssl/) dans la documentation de Flink.
| Composant | Endpoint | Port | Mécanisme de chiffrement en transit | Supporté depuis la sortie |
| --- | --- | --- | --- | --- |
| Serveur d'historique Flink | historyserver.web.port | 8082 | TLS | emr-7,3.0\$1 |
| Serveur REST Job Manager | rest.bind-port rest.port | Répartition dynamique | TLS | emr-7,3.0\$1 |
## HBase
Amazon EMR définit [Secure Hadoop](https://hadoop.apache.org/docs/r2.7.2/hadoop-project-dist/hadoop-common/SecureMode.html#Data_Encryption_on_RPC) RPC sur. `privacy` HMaster et RegionServer utilisez le chiffrement en transit basé sur le protocole SASL. Cela nécessite que l'authentification Kerberos soit activée dans la configuration de sécurité.
Amazon EMR est défini sur true et utilise le protocole TLS `hbase.ssl.enabled` pour les points de terminaison de l'interface utilisateur. Si vous ne souhaitez pas utiliser le protocole TLS pour les points de terminaison de l'interface utilisateur, désactivez cette configuration. Nous vous recommandons d'utiliser la configuration par défaut pour une sécurité maximale.
Amazon EMR définit `hbase.rest.ssl.enabled` `hbase.thrift.ssl.enabled` et utilise le protocole TLS pour les points de terminaison des serveurs REST et Thift, respectivement. Si vous ne souhaitez pas utiliser le protocole TLS pour ces points de terminaison, désactivez cette configuration. Nous vous recommandons d'utiliser la configuration par défaut pour une sécurité maximale.
À partir de la version 7.6.0 d'EMR, le protocole TLS est pris en charge sur et sur les terminaux. HMaster RegionServer Amazon EMR définit `hbase.server.netty.tls.enabled` également et. `hbase.client.netty.tls.enabled` Si vous ne souhaitez pas utiliser le protocole TLS pour ces points de terminaison, désactivez cette configuration. Nous vous recommandons d'utiliser la configuration par défaut, qui fournit un cryptage et donc une sécurité accrue. Pour en savoir plus, consultez la section [Transport Level Security (TLS) dans les communications HBase RPC](https://hbase.apache.org/book.html#_transport_level_security_tls_in_hbase_rpc_communication) dans le guide de * HBase référence Apache*.
| Composant | Endpoint | Port | Mécanisme de chiffrement en transit | Supporté depuis la sortie |
| --- | --- | --- | --- | --- |
| HMaster | HMaster | 16000 | SASL \$1 Kerberos TLS | Kerberos SASL \$1 dans emr-4.8.0\$1, emr-5.0.0\$1, emr-6.0.0\$1 et emr-7.0.0\$1 TLS dans emr-7.6.0\$1 |
| HMaster | HMaster interface utilisateur | 16010 | TLS | emr-7,3.0\$1 |
| RegionServer | RegionServer | 16020 | SASL \$1 Kerberos TLS | Kerberos SASL \$1 dans emr-4.8.0\$1, emr-5.0.0\$1, emr-6.0.0\$1 et emr-7.0.0\$1 TLS dans emr-7.6.0\$1 |
| RegionServer | RegionServer Infos | 16030 | TLS | emr-7,3.0\$1 |
| HBase Serveur Rest | Serveur Rest | 8070 | TLS | emr-7,3.0\$1 |
| HBase Serveur Rest | Interface utilisateur de repos | 8085 | TLS | emr-7,3.0\$1 |
| Serveur Hbase Thrift | Serveur Thrift | 9090 | TLS | emr-7,3.0\$1 |
| Serveur Hbase Thrift | Interface utilisateur du serveur Thrift | 9095 | TLS | emr-7,3.0\$1 |
## Phoenix
Si vous avez activé le chiffrement en transit dans votre cluster EMR, Phoenix Query Server prend en charge la `phoenix.queryserver.tls.enabled` propriété TLS, qui est définie sur par défaut. `true`
Pour en savoir plus, consultez la section [Configurations relatives au protocole HTTPS](https://phoenix.apache.org/server.html#Configuration) dans la documentation de Phoenix Query Server.
| Composant | Endpoint | Port | Mécanisme de chiffrement en transit | Supporté depuis la sortie |
| --- | --- | --- | --- | --- |
| Serveur de requêtes | phoenix.queryserver.http.port | 8765 | TLS | emr-7,3.0\$1 |
## Oozie
[OOZIE-3673](https://issues.apache.org/jira/browse/OOZIE-3673) est disponible sur Amazon EMR si vous exécutez Oozie sur Amazon EMR 7.3.0 ou version ultérieure. Si vous devez configurer des protocoles SSL ou TLS personnalisés lorsque vous exécutez une action par e-mail, vous pouvez définir la propriété `oozie.email.smtp.ssl.protocols` dans le `oozie-site.xml` fichier. Par défaut, si vous avez activé le chiffrement en transit, Amazon EMR utilise le protocole TLS v1.3.
[OOZIE-3677](https://issues.apache.org/jira/browse/OOZIE-3677) et [OOZIE-3674 sont](https://issues.apache.org/jira/browse/OOZIE-3674) également disponibles sur Amazon EMR si vous exécutez Oozie sur Amazon EMR 7.3.0 ou version ultérieure. Cela vous permet de spécifier les propriétés `keyStoreType` et `trustStoreType` dans`oozie-site.xml`. OOZIE-3674 ajoute le paramètre au client Oozie `--insecure` afin qu'il puisse ignorer les erreurs de certificat.
Oozie applique la vérification du nom d'hôte TLS, ce qui signifie que tout certificat que vous utilisez pour le chiffrement en transit doit répondre aux exigences de vérification du nom d'hôte. Si le certificat ne répond pas aux critères, le cluster risque de se bloquer au `oozie share lib update` moment où Amazon EMR approvisionne le cluster. Nous vous recommandons de mettre à jour vos certificats pour vous assurer qu'ils sont conformes à la vérification du nom d'hôte. Toutefois, si vous ne pouvez pas mettre à jour les certificats, vous pouvez désactiver le protocole SSL pour Oozie en définissant la `oozie.https.enabled` propriété sur `false` dans la configuration du cluster.
| Composant | Endpoint | Port | Mécanisme de chiffrement en transit | Supporté depuis la sortie |
| --- | --- | --- | --- | --- |
| EmbeddedOozieServer | oozie.https.port | 11443 | TLS | emr-7,3.0\$1 |
| EmbeddedOozieServer | oozie.email.smtp.port | 25 | TLS | emr-7,3.0\$1 |
## Hue
Par défaut, Hue prend en charge le protocole TLS lorsque le chiffrement en transit est activé dans les clusters Amazon EMR. Pour plus d'informations sur les configurations Hue, voir [Configurer Hue avec HTTPS/SSL](https://gethue.com/configure-hue-with-https-ssl/).
| Composant | Endpoint | Port | Mécanisme de chiffrement en transit | Supporté depuis la sortie |
| --- | --- | --- | --- | --- |
| Hue | http\$1port | 8888 | TLS | EMR-7.4.0\$1 |
## Livy
Par défaut, Livy prend en charge le protocole TLS lorsque le chiffrement en transit est activé dans les clusters Amazon EMR. Pour plus d'informations sur les configurations de Livy, consultez la section [Activation du protocole HTTPS avec Apache Livy](https://docs.aws.amazon.com/emr/latest/ReleaseGuide/enabling-https.html).
À partir d'Amazon EMR 7.3.0, si vous utilisez le chiffrement en transit et l'authentification Kerberos, vous ne pouvez pas utiliser le serveur Livy pour les applications Spark qui dépendent du métastore Hive. Ce problème est résolu dans [HIVE-16340](https://issues.apache.org/jira/browse/HIVE-16340) et entièrement résolu dans [SPARK-44114](https://issues.apache.org/jira/browse/SPARK-44114) lorsque l'application open source Spark peut passer à Hive 3. En attendant, vous pouvez contourner ce problème si vous configurez `hive.metastore.use.SSL` sur`false`. Pour plus d'informations, consultez [Configuration des applications](https://docs.aws.amazon.com/emr/latest/ReleaseGuide/emr-configure-apps.html).
Pour plus d'informations, consultez la section [Activation du protocole HTTPS avec Apache Livy.](https://docs.aws.amazon.com/emr/latest/ReleaseGuide/enabling-https.html)
| Composant | Endpoint | Port | Mécanisme de chiffrement en transit | Supporté depuis la sortie |
| --- | --- | --- | --- | --- |
| livy-server | livy.server.port | 8998 | TLS | EMR-7.4.0\$1 |
## JupyterEnterpriseGateway
Par défaut, Jupyter Enterprise Gateway prend en charge le protocole TLS lorsque le chiffrement en transit est activé dans les clusters Amazon EMR. Pour plus d'informations sur les configurations de Jupyter Enterprise Gateway, consultez la section [Sécurisation du serveur Enterprise Gateway](https://jupyter-enterprise-gateway.readthedocs.io/en/v1.2.0/getting-started-security.html#securing-enterprise-gateway-server).
| Composant | Endpoint | Port | Mécanisme de chiffrement en transit | Supporté depuis la sortie |
| --- | --- | --- | --- | --- |
| passerelle Jupyter\$1Enterprise\$1Gateway | EnterpriseGatewayAppc. port | 9547 | TLS | EMR-7.4.0\$1 |
## JupyterHub
Par défaut, JupyterHub prend en charge le protocole TLS lorsque le chiffrement en transit est activé dans les clusters Amazon EMR. Pour plus d'informations, consultez la section [Activation du cryptage SSL](https://jupyterhub.readthedocs.io/en/latest/tutorial/getting-started/security-basics.html#enabling-ssl-encryption) dans la JupyterHub documentation. Il n'est pas recommandé de désactiver le chiffrement.
| Composant | Endpoint | Port | Mécanisme de chiffrement en transit | Supporté depuis la sortie |
| --- | --- | --- | --- | --- |
| jupyter\$1hub | JupyterHubc. port | 9443 | TLS | emr-5.14.0\$1, emr-6,0.0\$1, emr-7,0.0\$1 |
## Zeppelin
Par défaut, Zeppelin prend en charge le protocole TLS lorsque vous activez le chiffrement en transit dans votre cluster EMR. Pour plus d'informations sur les configurations Zeppelin, consultez la section [Configuration SSL](https://zeppelin.apache.org/docs/0.11.1/setup/operation/configuration.html#ssl-configuration) dans la documentation Zeppelin.
| Composant | Endpoint | Port | Mécanisme de chiffrement en transit | Supporté depuis la sortie |
| --- | --- | --- | --- | --- |
| zeppelin | zeppelin.server.ssl.port | 8890 | TLS | 7,3,0\$1 |
## Zookeeper
Amazon EMR se configure `serverCnxnFactory` pour activer le protocole TLS `org.apache.zookeeper.server.NettyServerCnxnFactory` pour le quorum de Zookeeper et les communications avec les clients.
`secureClientPort`indique le port qui écoute les connexions TLS. Si le client ne prend pas en charge les connexions TLS à Zookeeper, les clients peuvent se connecter au port non sécurisé 2181 spécifié dans. `clientPort` Vous pouvez annuler ou désactiver ces deux ports.
Amazon EMR définit les deux paramètres `sslQuorum` et sur `admin.forceHttps` `true` pour activer la communication TLS pour le quorum et le serveur d'administration. Si vous ne souhaitez pas que le quorum et le serveur d'administration soient chiffrés en transit, vous pouvez désactiver ces configurations. Nous vous recommandons d'utiliser les configurations par défaut pour une sécurité maximale.
Pour plus d'informations, consultez la section [Options de chiffrement, d'authentification et d'autorisation](https://zookeeper.apache.org/doc/r3.9.2/zookeeperAdmin.html#sc_authOptions) dans la documentation de Zookeeper.
| Composant | Endpoint | Port | Mécanisme de chiffrement en transit | Supporté depuis la sortie |
| --- | --- | --- | --- | --- |
| Serveur Zookeeper | secureClientPort | 2281 | TLS | EMR-7.4.0\$1 |
| Serveur Zookeeper | Ports du quorum | Il y en a 2 : Les followers utilisent 2888 pour se connecter au leader. L'élection du leader utilise 3888 | TLS | EMR-7.4.0\$1 |
| Serveur Zookeeper | Port du serveur d'administration | 8341 | TLS | EMR-7.4.0\$1 |