Las traducciones son generadas a través de traducción automática. En caso de conflicto entre la traducción y la version original de inglés, prevalecerá la version en inglés.
# Cifrar datos en reposo y en tránsito con Amazon EMR
El cifrado de datos ayuda a impedir que los usuarios no autorizados lean los datos en un clúster y sistemas de almacenamiento de datos asociados. Esto incluye los datos guardados en medios persistentes, conocidos como datos *en reposo* y datos que pueden ser interceptados cuando recorren la red, conocidos como datos *en tránsito*.
A partir de la versión 4.8.0 de Amazon EMR, puede utilizar configuraciones de seguridad de Amazon EMR para definir configuraciones de cifrado de datos para clústeres de manera más sencilla. Las configuraciones de seguridad ofrecen ajustes para habilitar la seguridad de los datos en tránsito y de los datos en reposo en volúmenes de Amazon Elastic Block Store (Amazon EBS) y EMRFS en Amazon S3.
Opcionalmente, a partir de la versión 4.1.0 de Amazon EMR y posteriores, puede elegir configurar el cifrado transparente en el HDFS, que no se configura utilizando las configuraciones de seguridad. Para obtener más información, consulte [Cifrado transparente en el HDFS en Amazon EMR](https://docs.aws.amazon.com/emr/latest/ReleaseGuide/emr-encryption-tdehdfs.html) en la *Guía de lanzamiento de Amazon EMR*.
**Topics**
+ [Opciones de cifrado para Amazon EMR](emr-data-encryption-options.md)
+ [Cifrado en reposo con una clave de KMS del cliente para el servicio EMR WAL](encryption-at-rest-kms.md)
+ [Creación de claves y certificados para el cifrado de datos con Amazon EMR](emr-encryption-enable.md)
+ [Información sobre el cifrado en tránsito](emr-encryption-support-matrix.md)
# Opciones de cifrado para Amazon EMR
Con las versiones 4.8.0 y posteriores de Amazon EMR, puede utilizar una configuración de seguridad para especificar las opciones de cifrado de datos en reposo, datos en tránsito o ambos. Al habilitar el cifrado de datos en reposo, puede elegir cifrar datos de EMRFS en Amazon S3, datos en discos locales o ambos. Cada configuración de seguridad que se crea se almacena en Amazon EMR en lugar de en la configuración del clúster, por lo que puede volver a utilizar con facilidad una configuración para especificar ajustes de cifrado de datos cada vez que cree un clúster. Para obtener más información, consulte [Cree una configuración de seguridad con la consola Amazon EMR o con AWS CLI](emr-create-security-configuration.md).
En el siguiente diagrama se muestran las distintas opciones de cifrado de datos disponibles con las configuraciones de seguridad.
![\[Gracias a Amazon EMR hay varias opciones disponibles de cifrado en tránsito y en reposo.\]](http://docs.aws.amazon.com/es_es/emr/latest/ManagementGuide/images/emr-encryption-options.png)
Las siguientes opciones de cifrado también están disponibles y no se configuran utilizando una configuración de seguridad:
+ Opcionalmente, con las versiones 4.1.0 y posteriores de Amazon EMR, puede elegir configurar el cifrado transparente en el HDFS. Para obtener más información, consulte [Cifrado transparente en el HDFS en Amazon EMR](https://docs.aws.amazon.com/emr/latest/ReleaseGuide/emr-encryption-tdehdfs.html) en la *Guía de lanzamiento de Amazon EMR*.
+ Si utiliza una versión de Amazon EMR que no admite configuraciones de seguridad, puede configurar manualmente el cifrado para los datos de EMRFS en Amazon S3. Para obtener más información, consulte [Especificación del cifrado de Amazon S3 con propiedades de EMRFS](https://docs.aws.amazon.com/emr/latest/ReleaseGuide/emr-emrfs-encryption.html).
+ Si utiliza una versión de Amazon EMR anterior a 5.24.0, un volumen de dispositivo raíz cifrado de EBS se admite únicamente cuando se utiliza una AMI personalizada. Para obtener más información, consulte [Creación de una AMI personalizada con un volumen de dispositivo raíz de Amazon EBS cifrado](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-custom-ami.html#emr-custom-ami-encrypted) en la *Guía de administración de Amazon EMR*.
**nota**
A partir de la versión 5.24.0 de Amazon EMR, puede utilizar una opción de configuración de seguridad para cifrar los volúmenes de almacenamiento y los dispositivos raíz de EBS si lo especifica como proveedor de claves. AWS KMS Para obtener más información, consulte [Cifrado de disco local](#emr-encryption-localdisk).
El cifrado de datos requiere las claves y los certificados. Una configuración de seguridad le brinda la flexibilidad de elegir entre varias opciones, incluidas las claves administradas por AWS Key Management Service, las claves administradas por Amazon S3 y las claves y certificados de los proveedores personalizados que usted suministre. Si AWS KMS lo utiliza como proveedor de claves, se aplican cargos por el almacenamiento y el uso de las claves de cifrado. Para obtener más información, consulte [Precios de AWS KMS](https://aws.amazon.com/kms/pricing/).
Antes de especificar las opciones de cifrado, decida los sistemas de administración de clave y certificado que desee utilizar, para poder crear primero las claves y los certificados o los proveedores personalizados que especifique como parte de la configuración de cifrado.
## Cifrado en reposo para datos de EMRFS en Amazon S3
El cifrado de Amazon S3 funciona con objetos del sistema de archivos de Amazon EMR (EMRFS) que se leen y se escriben en Amazon S3. Se especifica el cifrado del servidor (SSE) o el cifrado del cliente (CSE) de Amazon S3 como **Modo de cifrado predeterminado** al habilitar el cifrado en reposo. También puede especificar métodos de cifrado diferentes para buckets individuales utilizando **Per bucket encryption overrides (Reemplazos de cifrado por bucket)**. Independientemente de si el cifrado de Amazon S3 está habilitado, la seguridad de la capa de transporte (TLS) cifra los objetos de EMRFS en tránsito entre los nodos del clúster de EMR y Amazon S3. Para obtener más información acerca del cifrado de Amazon S3, consulte [Protección de datos mediante cifrado](https://docs.aws.amazon.com/AmazonS3/latest/userguide/UsingEncryption.html) en la *Guía del usuario de Amazon Simple Storage Service*.
**nota**
Al utilizarlas AWS KMS, se cobran cargos por el almacenamiento y el uso de las claves de cifrado. Para obtener más información, consulte [AWS KMS Precios](https://aws.amazon.com/kms/pricing/).
### Cifrado del servidor de Amazon S3
Todos los buckets de Amazon S3 tienen el cifrado configurado de forma predeterminada, y todos los objetos nuevos que se cargan en un bucket de S3 se cifran automáticamente en reposo. Amazon S3 cifra los datos del objeto a medida que los escribe en el disco y los descifra cuando se accede a ellos. Para obtener más información sobre SSE, consulte [Protección de los datos con el cifrado del servidor](https://docs.aws.amazon.com/AmazonS3/latest/userguide/serv-side-encryption.html) en la *Guía del usuario de Amazon Simple Storage Service*.
Puede elegir entre dos sistemas de administración de claves distintos al especificar SSE en Amazon EMR:
+ **SSE-S3**: Amazon S3 administra las claves en su nombre.
+ **SSE-KMS**: se utiliza una AWS KMS key para configurar políticas adecuadas para Amazon EMR. Para obtener más información sobre los requisitos clave de Amazon EMR, consulte [Uso AWS KMS keys para cifrado](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-encryption-enable.html#emr-awskms-keys).
SSE con claves proporcionadas por el cliente (SSE-C) no está disponible para su uso con Amazon EMR.
### Cifrado del cliente de Amazon S3
Con el cifrado del cliente de Amazon S3, el proceso de cifrado y descifrado de Amazon S3 se produce en el cliente de EMRFS en su clúster. Los objetos se cifran antes de cargarlos en Amazon S3 y se descifran después de que se descarguen. El proveedor que especifique proporciona la clave de cifrado que utiliza el cliente. El cliente puede usar claves proporcionadas por AWS KMS (CSE-KMS) o una clase de Java personalizada que proporciona la clave raíz del cliente (CSE-C). Los detalles de cifrado son ligeramente diferentes entre CSE-KMS y CSE-C, en función del proveedor especificado y de los metadatos del objeto que se descifra o se cifra. Para obtener más información sobre estas diferencias, consulte [Protección de los datos con el cifrado del cliente](https://docs.aws.amazon.com/AmazonS3/latest/userguide/UsingClientSideEncryption.html) en la *Guía del usuario de Amazon Simple Storage Service*.
**nota**
El CSE de Amazon S3 solo garantiza que los datos de EMRFS intercambiados con Amazon S3 se cifren; no se cifran todos los datos en volúmenes de instancias de clúster. Además, ya que Hue no utiliza EMRFS, los objetos que Hue S3 File Browser escribe en Amazon S3 no se cifran.
## Cifrado en reposo para datos en Amazon EMR WAL
Al configurar el cifrado del servidor (SSE) para el registro de escritura anticipada (WAL), Amazon EMR cifra los datos en reposo. Puede elegir a partir de dos sistemas de administración de claves distintos al especificar SSE en Amazon EMR:
**SSE-EMR-WAL**
Amazon EMR administra las claves por usted. De forma predeterminada, Amazon EMR cifra los datos que ha almacenado en Amazon EMR WAL con SSE-EMR-WAL.
**SSE-KMS-WAL**
Utiliza una AWS KMS clave para configurar las políticas que se aplican a Amazon EMR WAL. Para obtener más información sobre cómo configurar el cifrado en reposo para EMR WAL mediante una clave de KMS proporcionada por el cliente, consulte [Cifrado en reposo con una clave de KMS del cliente para el servicio EMR WAL](https://docs.aws.amazon.com/emr/latest/ManagementGuide/encryption-at-rest-kms.html).
**nota**
No puede usar su propia clave con SSE cuando habilita WAL con Amazon EMR. Para obtener más información, consulte [Write Ahead Logs (WAL) para Amazon EMR](https://docs.aws.amazon.com/emr/latest/ReleaseGuide/emr-hbase-wal.html).
## Cifrado de disco local
Los siguientes mecanismos funcionan juntos para cifrar discos locales cuando habilita el cifrado de discos locales utilizando una configuración de seguridad de Amazon EMR.
### Cifrado HDFS de código abierto
HDFS intercambia datos entre las instancias de clúster durante el procesamiento distribuido. También lee y escribe datos a volúmenes de almacenes de instancias y a los volúmenes de EBS asociado a las instancias. Las siguientes opciones de cifrado de Hadoop de código abierto se activan cuando se habilita el cifrado de disco local:
+ [Secure Hadoop RPC](https://hadoop.apache.org/docs/r2.7.2/hadoop-project-dist/hadoop-common/SecureMode.html#Data_Encryption_on_RPC) se define en `Privacy`, que utiliza nivel de seguridad y autenticación simples (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.) se define como `true` y se configura para utilizar el cifrado AES 256.
**nota**
Puede activar el cifrado de Apache Hadoop adicional habilitando el cifrado en tránsito. Para obtener más información, consulte [Cifrado en tránsito](#emr-encryption-intransit). Estos ajustes de cifrado no activan el cifrado transparente de HDFS, que puede configurar manualmente. Para obtener más información, consulte [Cifrado transparente en el HDFS en Amazon EMR](https://docs.aws.amazon.com/emr/latest/ReleaseGuide/emr-encryption-tdehdfs.html) en la *Guía de lanzamiento de Amazon EMR*.
### Cifrado del almacén de instancias
Para los tipos de instancias EC2 que utilizan el volumen de almacén de instancias NVMe basado SSDs , el NVMe cifrado se utiliza independientemente de la configuración de cifrado de Amazon EMR. Para obtener más información, consulte los [volúmenes NVMe SSD](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ssd-instance-store.html#nvme-ssd-volumes) en la Guía del *usuario de Amazon EC2*. En otros volúmenes de almacén de instancias, Amazon EMR utiliza LUKS para cifrar el volumen de almacén de instancias cuando se ha habilitado el cifrado de disco local independientemente de si los volúmenes de EBS se han cifrado utilizando el cifrado de EBS o LUKS.
### Cifrado de volumen de EBS
Si crea un clúster en una región donde el cifrado de Amazon EC2 de volúmenes de EBS se ha habilitado por defecto para su cuenta, los volúmenes de EBS se cifran incluso si el cifrado de disco local no está habilitado. Para obtener más información, consulte [Cifrado de forma predeterminada](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/EBSEncryption.html#encryption-by-default) en la *Guía del usuario de Amazon EC2*. Con el cifrado de disco local activado en una configuración de seguridad, la configuración de Amazon EMR tiene prioridad sobre la configuración de Amazon EC2 para las instancias de EC2 encryption-by-default en clúster.
Las siguientes opciones están disponibles para volúmenes de cifrado de EBS que utilizan una configuración de seguridad:
+ **Cifrado EBS**: a partir de la versión 5.24.0 de Amazon EMR, puede optar por habilitar el cifrado EBS. La opción de cifrado de EBS cifra el volumen de dispositivo raíz de EBS y los volúmenes de almacenamiento adjuntos. La opción de cifrado de EBS solo está disponible si usted la especifica AWS Key Management Service como proveedor de claves. Recomendamos el uso del cifrado de EBS.
+ **Cifrado LUKS**: si decide utilizar el cifrado LUKS para los volúmenes de Amazon EBS, el cifrado LUKS se aplica únicamente a los volúmenes de almacenamiento adjuntos, no al volumen del dispositivo raíz. Para obtener más información sobre el cifrado de LUKS, consulte la [especificación de LUKS en disco](https://gitlab.com/cryptsetup/cryptsetup/wikis/Specification).
Para su proveedor de claves, puede configurar uno AWS KMS key con políticas adecuadas para Amazon EMR o una clase Java personalizada que proporcione los artefactos de cifrado. Al utilizarlas AWS KMS, se cobran cargos por el almacenamiento y el uso de las claves de cifrado. Para más información, consulte [Precios de AWS KMS](https://aws.amazon.com/kms/pricing/).
**nota**
Para comprobar si el cifrado de EBS está habilitado en el clúster, se recomienda utilizar una llamada a la API `DescribeVolumes`. Para obtener más información, consulte [DescribeVolumes](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_DescribeVolumes.html). La ejecución de `lsblk` en el clúster solo comprobará el estado del cifrado LUKS, en lugar del cifrado de EBS.
## Cifrado en tránsito
Hay habilitados diversos mecanismos de cifrado con el cifrado en tránsito. Se trata de características de código abierto, específicas de la aplicación y podrían variar según la versión de Amazon EMR. Para habilitar el cifrado en tránsito, utilice [Cree una configuración de seguridad con la consola Amazon EMR o con AWS CLI](emr-create-security-configuration.md) en Amazon EMR. Para los clústeres de EMR con el cifrado en tránsito habilitado, Amazon EMR configura automáticamente las configuraciones de las aplicaciones de código abierto para habilitar el cifrado en tránsito. Para los casos de uso avanzados, puede configurar las configuraciones de las aplicaciones de código abierto directamente para anular el comportamiento predeterminado en Amazon EMR. Para obtener más información, consulte la [matriz de compatibilidad de cifrado en tránsito](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-encryption-support-matrix.html) y [Configuración de aplicaciones](https://docs.aws.amazon.com/emr/latest/ReleaseGuide/emr-configure-apps.html).
Consulte lo siguiente para obtener información más específica sobre las aplicaciones de código abierto relacionadas con el cifrado en tránsito:
+ Cuando habilita el cifrado en tránsito con una configuración de seguridad, Amazon EMR habilita el cifrado en tránsito para todos los puntos de conexión de aplicaciones de código abierto que admiten el cifrado en tránsito. La compatibilidad con el cifrado en tránsito para los distintos puntos de conexión de las aplicaciones varía según la versión de lanzamiento de Amazon EMR. Para obtener más información, consulte la [matriz de compatibilidad de cifrado en tránsito](https://docs.aws.amazon.com/).
+ Puede anular las configuraciones de código abierto, lo que le permite hacer lo siguiente:
+ Deshabilite la verificación del nombre de host TLS si los certificados TLS proporcionados por el usuario no cumplen con los requisitos
+ Deshabilite el cifrado en tránsito para determinados puntos de conexión en función de sus requisitos de rendimiento y compatibilidad
+ Controle qué versiones de TLS y conjuntos de cifrado desea utilizar.
Puede encontrar más detalles sobre las configuraciones específicas de la aplicación en la [matriz de compatibilidad de cifrado en tránsito](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-encryption-support-matrix.html)
+ Además de habilitar el cifrado en tránsito con una configuración de seguridad, algunos canales de comunicación también requieren configuraciones de seguridad adicionales para poder habilitar el cifrado en tránsito. Por ejemplo, algunos puntos de conexión de aplicaciones de código abierto utilizan la capa de autenticación y seguridad simple (SASL) para el cifrado en tránsito, lo que requiere que la autenticación de Kerberos esté habilitada en la configuración de seguridad del clúster de EMR. Para obtener más información sobre estos puntos de conexión, consulte la [matriz de compatibilidad de cifrado en tránsito](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-encryption-support-matrix.html).
+ Se recomienda usar un software que admita TLS v1.2 o posterior. Amazon EMR en EC2 incluye la distribución Corretto JDK predeterminada, que determina qué versiones de TLS, conjuntos de cifrado y tamaños de clave permiten las redes de código abierto que se ejecutan en Java. En este momento, la mayoría de marcos de código abierto aplican TLS v1.2 o posterior para Amazon EMR 7.0.0 y versiones posteriores. Esto se debe a que la mayoría de marcos de código abierto se ejecutan en Java 17 para Amazon EMR 7.0.0 y versiones posteriores. Es posible que las versiones anteriores de Amazon EMR admitan TLS v1.0 y v1.1 porque consumen versiones anteriores de Java, pero Corretto JDK podría cambiar las versiones de TLS que admite Java, lo que podría afectar a las versiones de Amazon EMR existentes.
Tiene que especificar los artefactos de cifrado utilizados para el cifrado en tránsito de una de estas dos maneras: facilitando un archivo comprimido con los certificados que carga en Amazon S3, o bien, haciendo referencia a una clase de Java personalizada que proporcione artefactos de cifrado. Para obtener más información, consulte [Proporcionar certificados para el cifrado de datos en tránsito con el cifrado de Amazon EMR](emr-encryption-enable.md#emr-encryption-certificates).
# Cifrado en reposo con una clave de KMS del cliente para el servicio EMR WAL
Los registros de escritura anticipada (WAL) de EMR proporcionan soporte clave de KMS al cliente. encryption-at-rest A continuación, se presenta una descripción general de cómo Amazon EMR WAL se integra con AWS KMS:
Los registros de escritura anticipada (WAL) de EMR interactúan AWS durante las siguientes operaciones:`CreateWAL`,,,,, `AppendEdit` `ArchiveWALCheckPoint` `CompleteWALFlush` `DeleteWAL` `GetCurrentWALTime``ReplayEdits`, de forma `EMR_EC2_DefaultRole` predeterminada. Cuando se `TrimWAL` invoca alguna de las operaciones anteriores de la lista, la WAL de EMR realiza `Decrypt` y contra la clave KMS. `GenerateDataKey`
## Consideraciones
Tenga en cuenta lo siguiente cuando utilice el cifrado AWS KMS basado para EMR WAL:
+ La configuración de cifrado no puede modificarse después de crear un EMR WAL.
+ Cuando utilice cifrado con KMS mediante su propia clave de KMS, esa clave debe existir en la misma región que su clúster de Amazon EMR.
+ Usted es responsable de mantener todos los permisos de IAM necesarios; se recomienda no revocar estos permisos mientras el WAL esté activo. De lo contrario, pueden producirse fallas inesperadas, como la imposibilidad de eliminar un EMR WAL cuando la clave de cifrado asociada ya no existe.
+ El uso de AWS KMS claves conlleva un coste. Para obtener más información, consulte [Precios de AWS Key Management Service](https://aws.amazon.com/kms/pricing/).
## Permisos de IAM necesarios
Para usar su clave de KMS y cifrar EMR WAL en reposo, asegúrese de otorgar los permisos adecuados al rol del cliente de EMR WAL y al `emrwal.amazonaws.com` de la entidad principal de servicio de EMR WAL.
### Permisos para el rol del cliente de EMR WAL
La siguiente es la política de IAM necesaria para el rol del cliente de EMR WAL:
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"kms:Decrypt",
"kms:GenerateDataKey*"
],
"Resource": [
"*"
],
"Sid": "AllowKMSDecrypt"
}
]
}
```
------
El cliente de EMR WAL en el clúster EMR usa `EMR_EC2_DefaultRole` de manera predeterminada. Si utiliza un rol diferente para el perfil de instancia en el clúster EMR, asegúrese de que cada rol incluya los permisos adecuados.
Para obtener más información sobre la administración de políticas de roles, consulte [Adición y eliminación de permisos de identidad de IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_manage-attach-detach.html).
### Permisos para la política de claves de KMS
Debe otorgar al rol del cliente de EMR WAL y al servicio de EMR WAL los permisos de `Decrypt` y `GenerateDataKey*` en su política de KMS. Para obtener más información sobre la administración de políticas de claves, consulte [Política de claves de 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"
}
]
}
```
------
El rol especificado en el fragmento puede cambiar si usted modifica el rol predeterminado.
## Supervisión de la interacción de Amazon EMR WAL con AWS KMS
### Contexto de cifrado de Amazon EMR WAL
Un contexto de cifrado es un conjunto de pares de clave-valor que contiene datos no secretos arbitrarios. Cuando incluye un contexto de cifrado en una solicitud de cifrado de datos, vincula AWS KMS criptográficamente el contexto de cifrado a los datos cifrados. Para descifrar los datos, es necesario pasar el mismo contexto de cifrado.
En sus solicitudes [GenerateDataKey](https://docs.aws.amazon.com/kms/latest/APIReference/API_GenerateDataKey.html)y [Decrypt](https://docs.aws.amazon.com/kms/latest/APIReference/API_Decrypt.html) para AWS KMS, Amazon EMR WAL utiliza un contexto de cifrado con un par nombre-valor que identifican el nombre WAL de EMR.
```
"encryptionContext": {
"aws:emrwal:walname": "111222333444555-testworkspace-emrwalclustertest-emrwaltestwalname"
}
```
Puede usar el contexto de cifrado para identificar estas operaciones criptográficas en registros y registros de auditoría, como AWS CloudTrail [Amazon CloudWatch Logs](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-user-guide.html), y como condición para la autorización en políticas y concesiones.
# Creación de claves y certificados para el cifrado de datos con Amazon EMR
Antes de especificar las opciones de cifrado mediante una configuración de seguridad, decida el proveedor que desea usar para las claves y los artefactos de cifrado. Por ejemplo, puede usar AWS KMS o un proveedor personalizado que cree. A continuación, cree las claves o el proveedor tal y como se describe en esta sección.
## Proporcionar claves para cifrado de datos en reposo
Puede usar AWS Key Management Service (AWS KMS) o un proveedor de claves personalizado para el cifrado de datos en reposo en Amazon EMR. Cuando las usa AWS KMS, se cobran cargos por el almacenamiento y el uso de las claves de cifrado. Para obtener más información, consulte [Precios de AWS KMS](https://aws.amazon.com/kms/pricing/).
En este tema se ofrecen detalles sobre las políticas de claves para una clave de KMS que se vaya a usar con Amazon EMR, así como directrices y ejemplos de código para escribir una clase de proveedor de claves personalizadas para el cifrado de Amazon S3. Para más información sobre la creación de claves, consulte [Creación de claves](https://docs.aws.amazon.com/kms/latest/developerguide/create-keys.html) en la *Guía para desarrolladores de AWS Key Management Service *.
### Utilización AWS KMS keys para el cifrado
La clave de AWS KMS cifrado debe crearse en la misma región que la instancia de clúster de Amazon EMR y los buckets de Amazon S3 utilizados con EMRFS. Si la clave que especifica está en una cuenta diferente de la que usa para configurar un clúster, debe especificar la clave mediante su ARN.
El rol del perfil de instancia de Amazon EC2 debe tener permisos para usar la clave de KMS que especifique. El rol predeterminado del perfil de instancia en Amazon EMR es `EMR_EC2_DefaultRole`. Si usa un rol diferente para el perfil de instancia o usa roles de IAM para las solicitudes de EMRFS a Amazon S3, asegúrese de agregar cada rol como usuario clave, según corresponda. Esto proporciona al rol los permisos para utilizar la clave de KMS. Para obtener más información, consulte [Uso de políticas de claves](https://docs.aws.amazon.com/kms/latest/developerguide/key-policies.html#key-policy-default-allow-users) en la *Guía para desarrolladores de AWS Key Management Service * y [Configuración de roles de IAM para solicitudes de EMRFS a Amazon S3](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-emrfs-iam-roles.html).
Puede utilizarla Consola de administración de AWS para añadir su perfil de instancia o perfil de instancia EC2 a la lista de usuarios clave de la clave de KMS especificada, o puede utilizar la AWS CLI o un AWS SDK para adjuntar una política de claves adecuada.
Tenga en cuenta que Amazon EMR solo admite [claves de KMS simétricas](https://docs.aws.amazon.com/kms/latest/developerguide/concepts.html#symmetric-cmks). No se puede utilizar una [clave KMS asimétrica](https://docs.aws.amazon.com/kms/latest/developerguide/symmetric-asymmetric.html#asymmetric-cmks) para cifrar datos en reposo en un clúster de Amazon EMR. Para obtener ayuda para determinar si una clave de KMS es simétrica o asimétrica, consulte [Identificación de claves de KMS simétricas y asimétricas](https://docs.aws.amazon.com/kms/latest/developerguide/find-symm-asymm.html).
El siguiente procedimiento describe cómo agregar el perfil de instancia de Amazon EMR predeterminado, `EMR_EC2_DefaultRole` como un *usuario clave* con la Consola de administración de AWS. Se supone que ya ha creado una clave de KMS. Para crear una nueva clave de KMS, consulte [Creación de claves](https://docs.aws.amazon.com/kms/latest/developerguide/create-keys.html) en la *Guía para desarrolladores de AWS Key Management Service *.
**Para agregar el perfil de instancia de EC2 para Amazon EMR a la lista de usuarios de claves de cifrado**
1. Inicie sesión en la consola AWS Key Management Service (AWS KMS) Consola de administración de AWS y ábrala en [https://console.aws.amazon.com/kms.](https://console.aws.amazon.com/kms)
1. Para cambiarla Región de AWS, usa el selector de regiones en la esquina superior derecha de la página.
1. Seleccione el alias de la clave de KMS que desee modificar.
1. En la página de detalles de la clave, en **Key Users (Usuarios de claves)**, seleccione **Add (Añadir)**.
1. En el cuadro de diálogo **Add key users (Añadir usuarios clave)**, seleccione el rol adecuado. El nombre del rol predeterminado es `EMR_EC2_DefaultRole`.
1. Elija **Añadir**.
### Habilitación del cifrado de EBS proporcionando permisos adicionales para las claves de KMS
A partir de la versión 5.24.0 de Amazon EMR, puede cifrar el dispositivo raíz y los volúmenes de almacenamiento de EBS utilizando una opción de configuración de seguridad. Para activar esta opción, debe especificarla AWS KMS como proveedor de claves. Además, debe conceder al rol `EMR_DefaultRole` de servicio permisos para usar el AWS KMS key que especifique.
Puede utilizar la función de servicio Consola de administración de AWS para añadir la función de servicio a la lista de usuarios clave de la clave de KMS especificada, o bien puede utilizar la función de servicio AWS CLI o un AWS SDK para adjuntar una política de claves adecuada.
El siguiente procedimiento describe cómo utilizar el Consola de administración de AWS para añadir el rol de servicio Amazon EMR predeterminado `EMR_DefaultRole` como usuario *clave*. Se supone que ya ha creado una clave de KMS. Para crear una nueva clave de KMS, consulte [Creación de claves](https://docs.aws.amazon.com/kms/latest/developerguide/create-keys.html) en la *Guía para desarrolladores de AWS Key Management Service *.
**Para añadir el rol de servicio de Amazon EMR a la lista de usuarios de claves de cifrado**
1. Inicie sesión en la consola AWS Key Management Service (AWS KMS) Consola de administración de AWS y ábrala en [https://console.aws.amazon.com/kms.](https://console.aws.amazon.com/kms)
1. Para cambiarla Región de AWS, usa el selector de regiones en la esquina superior derecha de la página.
1. Elija **Claves administradas por el cliente** en la barra lateral izquierda.
1. Seleccione el alias de la clave de KMS que desee modificar.
1. En la página de detalles de la clave, en **Key Users (Usuarios de claves)**, seleccione **Add (Añadir)**.
1. En la sección **Añadir usuarios de clave**, seleccione el rol adecuado. El nombre del rol de servicio predeterminado para Amazon EMR es `EMR_DefaultRole`.
1. Elija **Añadir**.
### Creación de un proveedor de claves personalizadas
Cuando se utiliza una configuración de seguridad, es necesario especificar un nombre de clase de proveedor distinto para el cifrado de disco local y el cifrado de Amazon S3. Los requisitos del proveedor de claves personalizadas dependen de si utiliza el cifrado de disco local y el cifrado de Amazon S3, así como de la versión de lanzamiento de Amazon EMR.
Según el tipo de cifrado que utilice al crear un proveedor de claves personalizado, la aplicación también debe implementar diferentes EncryptionMaterialsProvider interfaces. Ambas interfaces están disponibles en la versión 1.11.0 y posteriores del AWS SDK for Java.
+ Para implementar el cifrado de Amazon S3, utilice [com.amazonaws.services.s3.model. EncryptionMaterialsProvider interfaz.](https://docs.aws.amazon.com/AWSJavaSDK/latest/javadoc/com/amazonaws/services/s3/model/EncryptionMaterialsProvider.html)
+ Para implementar el cifrado del disco local, usa [com.amazonaws.services.elasticmapreduce.spi.security. EncryptionMaterialsProvider interfaz.](https://docs.aws.amazon.com/AWSJavaSDK/latest/javadoc/com/amazonaws/services/elasticmapreduce/spi/security/EncryptionMaterialsProvider.html)
Puede utilizar cualquier estrategia para proporcionar materiales de cifrado para la implementación. Por ejemplo, podría elegir proporcionar materiales de cifrado estáticos o integrar con un sistema de administración de claves más complejo.
Si utiliza el cifrado de Amazon S3, debe utilizar los algoritmos de cifrado **AES/GCM/NoPadding**para los materiales de cifrado personalizados.
Si utiliza el cifrado de disco local, el algoritmo de cifrado que se utilizará para los materiales de cifrado personalizados varía según la versión del EMR. Para Amazon EMR 7.0.0 y versiones anteriores, debe usar. **AES/GCM/NoPadding** Para Amazon EMR 7.1.0 y versiones posteriores, debe usar **AES**.
La EncryptionMaterialsProvider clase obtiene los materiales de cifrado por contexto de cifrado. Amazon EMR rellena el contexto de cifrado en tiempo de ejecución para ayudar al intermediario a determinar qué materiales de cifrado debe devolver.
**Example Ejemplo: uso de un proveedor de claves de cifrado personalizadas para el cifrado de Amazon S3 con EMRFS**
Cuando Amazon EMR obtiene los materiales de cifrado de la EncryptionMaterialsProvider clase para realizar el cifrado, EMRFS rellena opcionalmente el argumento MaterialsDescription con dos campos: el URI de Amazon S3 del objeto y JobFlowId el del clúster, que la clase puede utilizar para devolver materiales de cifrado de forma selectiva. EncryptionMaterialsProvider
Por ejemplo, el proveedor podría devolver claves distintas para diferentes prefijos URI de Amazon S3. Se trata de la descripción de los materiales de cifrado devuelta que se almacena finalmente con el objeto de Amazon S3 en lugar del valor materialsDescription que genera EMRFS y se transfiere al proveedor. Al descifrar un objeto de Amazon S3, la descripción del material de cifrado se pasa a la EncryptionMaterialsProvider clase para que, una vez más, devuelva de forma selectiva la clave correspondiente para descifrar el objeto.
A continuación se EncryptionMaterialsProvider proporciona una implementación de referencia. Otro proveedor personalizado, [EMRFSRSAEncryptionMaterialsProvider](https://github.com/awslabs/emr-sample-apps/tree/master/emrfs-plugins/EMRFSRSAEncryptionMaterialsProvider), está disponible en GitHub.
```
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;
}
}
```
## Proporcionar certificados para el cifrado de datos en tránsito con el cifrado de Amazon EMR
Con la versión 4.8.0 o posterior de Amazon EMR, dispone de dos opciones para especificar artefactos para el cifrado de datos en tránsito utilizando una configuración de seguridad:
+ Puede crear manualmente certificados PEM, incluirlos en un archivo .zip y, a continuación, hacer referencia al archivo .zip en Amazon S3.
+ Puede implementar un proveedor de certificados personalizado como una clase Java. Deberá especificar el archivo JAR de la aplicación en Amazon S3 y, a continuación, proporcionar el nombre de la clase completa del proveedor tal como se declara en la aplicación. La clase debe implementar la interfaz [TLSArtifactsde proveedor](https://docs.aws.amazon.com/AWSJavaSDK/latest/javadoc/com/amazonaws/services/elasticmapreduce/spi/security/TLSArtifactsProvider.html) disponible a partir de la AWS SDK para Java versión 1.11.0.
Amazon EMR descarga automáticamente artefactos en cada nodo del clúster y, posteriormente, los utiliza para implementar las características de cifrado en tránsito de código abierto. Para obtener más información sobre las opciones disponibles, consulte [Cifrado en tránsito](emr-data-encryption-options.md#emr-encryption-intransit).
### Uso de certificados PEM
Cuando especifique un archivo zip para el cifrado en tránsito, la configuración de seguridad espera que los archivos PEM dentro del archivo zip se nombren exactamente tal y como aparecen a continuación:
**Certificados de cifrado en tránsito**
| Nombre de archivo | Obligatorio/opcional | Details |
| --- | --- | --- |
| privateKey.pem | Obligatorio | Clave privada |
| certificateChain.pem | Obligatorio | Cadena de certificados |
| trustedCertificates.pem | Opcional | Le recomendamos que proporcione un certificado que no esté firmado por la autoridad de certificación (CA) de raíz de confianza predeterminada de Java o una CA intermedia que enlace a la CA de raíz de confianza predeterminada de Java. No le recomendamos que utilice el sistema público CAs cuando utilice certificados comodín o cuando deshabilite la verificación del nombre de host. |
Es probable que desee configurar el archivo PEM de clave privada como un certificado comodín que permita el acceso al dominio de Amazon VPC en el que residen las instancias del clúster. Por ejemplo, si el clúster se encuentran en la región us-east-1 (Norte de Virginia), puede elegir especificar un nombre común en la configuración de certificado que permita el acceso al clúster especificando `CN=*.ec2.internal` en la definición del sujeto del certificado. Si el clúster reside en us-west-2 (Oregón), puede especificar `CN=*.us-west-2.compute.internal`.
Si el archivo PEM proporcionado en el artefacto de cifrado no tiene un carácter comodín para el dominio del nombre común, debe cambiar el valor de a. `hadoop.ssl.hostname.verifier` `ALLOW_ALL` Para hacerlo en las versiones 7.3.0 y posteriores de Amazon EMR, añada la clasificación `core-site` cuando envíe las configuraciones a un clúster. En las versiones anteriores a la 7.3.0, añada la configuración `"hadoop.ssl.hostname.verifier": "ALLOW_ALL"` directamente al archivo `core-site.xml`. Este cambio es necesario porque el verificador de nombres de host predeterminado requiere un nombre de host sin el comodín porque todos los hosts del clúster lo utilizan. Para obtener más información sobre la configuración del clúster de EMR en una instancia de Amazon VPC, consulte [Configuración de redes en una VPC para Amazon EMR](emr-plan-vpc-subnet.md).
En el siguiente ejemplo, se muestra cómo utilizar [OpenSSL](https://www.openssl.org/) para generar un certificado X.509 autofirmado con una clave privada RSA de 2048 bits. La clave permite el acceso a las instancias de clúster de Amazon EMR en la región `us-west-2` (Oregón), tal y como se especifica mediante el nombre de dominio `*.us-west-2.compute.internal` como nombre común.
Se especifican otros elementos del sujeto opcionales como país (C), estado (S) y configuración regional (L). Dado que se genera un certificado autofirmado, el segundo comando del ejemplo copia el archivo `certificateChain.pem` en el archivo `trustedCertificates.pem`. El tercer comando utiliza `zip` para crear el archivo `my-certs.zip` que contiene los certificados.
**importante**
Este ejemplo es solo una proof-of-concept demostración. El uso de certificados autofirmados no se recomienda y presenta un posible riesgo para la seguridad. En el caso de los sistemas de producción, utilice una autoridad de certificación (CA) de confianza para emitir certificados.
```
$ 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
```
# Información sobre el cifrado en tránsito
Puede configurar un clúster de EMR para ejecutar marcos de código abierto como [Apache Spark](https://aws.amazon.com/emr/features/spark/), [Apache Hive](https://aws.amazon.com/emr/features/hive/) y [Presto](https://aws.amazon.com/emr/features/presto/). Cada uno de estos marcos de código abierto tiene un conjunto de procesos que se ejecutan en las instancias de EC2 de un clúster. Cada uno de estos procesos puede alojar puntos de conexión de red para la comunicación de red.
Si el cifrado en tránsito está habilitado en un clúster de EMR, los diferentes puntos de conexión de la red utilizan diferentes mecanismos de cifrado. Consulte las siguientes secciones para obtener más información sobre los puntos de conexión de red específicos del marco de código abierto compatibles con el cifrado en tránsito, los mecanismos de cifrado relacionados y qué versión de Amazon EMR ha añadido esta compatibilidad. Cada aplicación de código abierto también puede tener diferentes prácticas recomendadas y configuraciones de marco de código abierto que puede cambiar.
Para obtener la máxima cobertura de cifrado en tránsito, le recomendamos que habilite tanto el cifrado en tránsito como Kerberos. Si solo habilita el cifrado en tránsito, el cifrado en tránsito solo estará disponible para los puntos de conexión de la red que admiten TLS. Kerberos es necesario porque algunos puntos de conexión de red de código abierto utilizan la capa de autenticación y seguridad simple (SASL) para el cifrado en tránsito.
Tenga en cuenta que no se incluye ningún marco de código abierto que no sea compatible con las versiones 7.x.x de Amazon EMR.
## Spark
Al habilitar el cifrado en tránsito en las configuraciones de seguridad, `spark.authenticate` se establece automáticamente en `true` y utiliza el cifrado basado en AES para las conexiones RPC.
A partir de Amazon EMR 7.3.0, si utiliza el cifrado en tránsito y la autenticación Kerberos, no podrá utilizar las aplicaciones de Spark que dependan del metaalmacén de Hive. Hive 3 corrige este problema en [HIVE-16340](https://issues.apache.org/jira/browse/HIVE-16340). [HIVE-44114](https://issues.apache.org/jira/browse/SPARK-44114) resuelve completamente este problema cuando Spark de código abierto puede actualizarse a Hive 3. Mientras tanto, puede establecer `hive.metastore.use.SSL` en `false` para tratar de solucionar este problema. Para obtener más información, consulte [Configuración de aplicaciones](https://docs.aws.amazon.com/emr/latest/ReleaseGuide/emr-configure-apps.html).
Para obtener más información, consulte [Seguridad de Spark](https://spark.apache.org/docs/latest/security) en la documentación de Apache Spark.
| Componente | punto de enlace | Puerto | Mecanismo de cifrado en tránsito | Compatible desde la versión |
| --- | --- | --- | --- | --- |
| Servidor de historial de Spark | spark.ssl.history.port | 18480 | TLS | emr-5.3.0\$1, emr-6.0.0\$1, emr-7.0.0\$1 |
| Interfaz de usuario Spark | spark.ui.port | 4440 | TLS | emr-5.3.0\$1, emr-6.0.0\$1, emr-7.0.0\$1 |
| Controlador de Spark | spark.driver.port | Dinámico | Cifrado basado en AES de Spark | emr-4.8.0\$1, emr-5.0.0\$1, emr-6.0.0\$1, emr-7.0.0\$1 |
| Ejecutor de Spark | Puerto ejecutor (sin configuración con nombre) | Dinámico | Cifrado basado en AES de Spark | emr-4.8.0\$1, emr-5.0.0\$1, emr-6.0.0\$1, emr-7.0.0\$1 |
| HILO NodeManager | spark.shuffle.service.port1 | 7337 | Cifrado basado en AES de Spark | 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á alojado en YARN NodeManager pero solo lo usa Apache Spark.
**Problema conocido**
En los clústeres con cifrado en tránsito habilitado, la configuración de `spark.yarn.historyServer.address` actualmente utiliza el puerto `18080`, lo que impide acceder a la interfaz de Spark mediante el enlace de seguimiento de YARN. **Versiones afectadas:** de EMR - 7.3.0 a EMR - 7.9.0.
Utilice la siguiente solución alternativa:
1. Modifique la configuración de `spark.yarn.historyServer.address` en `/etc/spark/conf/spark-defaults.conf` para usar el número de puerto `HTTPS` `18480` en un clúster en ejecución.
1. También puede proporcionar este ajuste en las anulaciones de configuración al iniciar el clúster.
Ejemplo de configuración:
```
[
{
"Classification": "spark-defaults",
"Properties": {
"spark.yarn.historyServer.address": "${hadoopconf-yarn.resourcemanager.hostname}:18480"
}
}
]
```
## Hadoop YARN
El [Secure Hadoop RPC](https://hadoop.apache.org/docs/r2.7.2/hadoop-project-dist/hadoop-common/SecureMode.html#Data_Encryption_on_RPC) se ha establecido en `privacy` y usa el cifrado en tránsito basado en SASL. Esto requiere que la autenticación de Kerberos esté habilitada en la configuración de seguridad. Si no desea el cifrado en tránsito para Hadoop RPC, configure `hadoop.rpc.protection = authentication`. Se recomienda usar la configuración predeterminada para garantizar la máxima seguridad.
Si sus certificados TLS no cumplen los requisitos de verificación del nombre de host de TLS, puede configurar `hadoop.ssl.hostname.verifier = ALLOW_ALL`. Se recomienda usar la configuración predeterminada de `hadoop.ssl.hostname.verifier = DEFAULT`, que exige la verificación del nombre de host de TLS.
Para deshabilitar HTTPS en los puntos de conexión de la aplicación web YARN, configure `yarn.http.policy = HTTP_ONLY`. Esto hace que el tráfico a estos puntos de conexión permanezca sin cifrar. Se recomienda usar la configuración predeterminada para garantizar la máxima seguridad.
Para obtener más información, consulte [Hadoop in Secure Mode](https://hadoop.apache.org/docs/r2.7.2/hadoop-project-dist/hadoop-common/SecureMode.html) en la documentación de Apache Hadoop:
| Componente | punto de enlace | Puerto | Mecanismo de cifrado en tránsito | Compatible desde la versión |
| --- | --- | --- | --- | --- |
| 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.port1 | 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.port2 | 7337 | Cifrado basado en AES de Spark | 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á alojado en YARN NodeManager pero solo lo usa MapReduce Hadoop.
2 `spark.shuffle.service.port` está alojado en YARN NodeManager pero solo lo usa Apache Spark.
**Problema conocido**
La configuración de `yarn.log.server.url` actualmente utiliza HTTP con el puerto 19888, lo que impide acceder a los registros de aplicaciones desde la interfaz de Resource Manager. **Versiones afectadas:** EMR - 7.3.0 a EMR - 7.8.0.
Utilice la siguiente solución alternativa:
1. Modifique la configuración `yarn.log.server.url` en `yarn-site.xml` para utilizar el protocolo `HTTPS` y el número de puerto `19890`.
1. Reinicie YARN Resource Manager: `sudo systemctl restart hadoop-yarn-resourcemanager.service`.
## HDFS de Hadoop
El nodo de nombre, el nodo de datos y el nodo de diario de Hadoop admiten TLS de forma predeterminada si el cifrado en tránsito está habilitado en los clústeres de EMR.
El [Secure Hadoop RPC](https://hadoop.apache.org/docs/r2.7.2/hadoop-project-dist/hadoop-common/SecureMode.html#Data_Encryption_on_RPC) se ha establecido en `privacy` y usa el cifrado en tránsito basado en SASL. Esto requiere que la autenticación Kerberos esté habilitada en la configuración de seguridad.
Se recomienda no cambiar los puertos predeterminados que se utilizan para los puntos de conexión HTTPS.
[El cifrado de datos en la transferencia de bloques de HDFS utiliza](https://hadoop.apache.org/docs/r2.7.2/hadoop-project-dist/hadoop-common/SecureMode.html#Data_Encryption_on_Block_data_transfer.) AES 256 y requiere que el cifrado en reposo esté habilitado en la configuración de seguridad.
Para obtener más información, consulte [Hadoop in Secure Mode](https://hadoop.apache.org/docs/r2.7.2/hadoop-project-dist/hadoop-common/SecureMode.html) en la documentación de Apache Hadoop:
| Componente | punto de enlace | Puerto | Mecanismo de cifrado en tránsito | Compatible desde la versión |
| --- | --- | --- | --- | --- |
| Namenode | 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 |
| Namenode | 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 |
| Datanode | 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 |
| Datanode | 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 |
| Nodo de diario | dfs.journalnode.https-address | 8481 | TLS | emr-4.8.0\$1, emr-5.0.0\$1, emr-6.0.0\$1, emr-7.0.0\$1 |
| Nodo de diario | dfs.journalnode.rpc-address | 8485 | SASL \$1 Kerberos | emr-4.8.0\$1, emr-5.0.0\$1, emr-6.0.0\$1, emr-7.0.0\$1 |
| DFSZKFailoverControlador | dfs.ha.zkfc.port | 8019 | Ninguno | El TLS para ZKFC solo se admite en Hadoop 3.4.0. Consulte [HADOOP-18919](https://issues.apache.org/jira/browse/HADOOP-18919) para más información. La versión 7.1.0 de Amazon EMR se encuentra actualmente en Hadoop 3.3.6. En el futuro, las versiones posteriores de Amazon EMR estarán en Hadoop 3.4.0 |
## Hadoop MapReduce
Hadoop MapReduce, Job History Server y MapReduce Shuffle admiten TLS de forma predeterminada cuando el cifrado en tránsito está habilitado en los clústeres de EMR.
[La mezcla cifrada de Hadoop utiliza TLS. MapReduce ](https://hadoop.apache.org/docs/r2.7.1/hadoop-mapreduce-client/hadoop-mapreduce-client-core/EncryptedShuffle.html)
Se recomienda no cambiar los puertos predeterminados para los puntos de conexión HTTPS.
Para obtener más información, consulte [Hadoop in Secure Mode](https://hadoop.apache.org/docs/r2.7.2/hadoop-project-dist/hadoop-common/SecureMode.html) en la documentación de Apache Hadoop:
| Componente | punto de enlace | Puerto | Mecanismo de cifrado en tránsito | Compatible desde la versión |
| --- | --- | --- | --- | --- |
| JobHistoryServer | mapreduce.jobhistory.webapp.https.address | 198-90 | TLS | emr-7.3.0\$1 |
| HILO NodeManager | mapreduce.shuffle.port1 | 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á alojado en YARN NodeManager pero solo lo usa MapReduce Hadoop.
## Presto
En las versiones 5.6.0 y posteriores de Amazon EMR, la comunicación interna entre el coordinador de Presto y los trabajadores utiliza TLS. Amazon EMR establece todas las configuraciones necesarias para permitir [una comunicación interna segura](https://prestodb.io/docs/current/security/internal-communication.html) en Presto.
Si el conector utiliza el metaalmacén de Hive como almacén de metadatos, la comunicación entre el comunicador y el metaalmacén de Hive también se cifra con TLS.
| Componente | punto de enlace | Puerto | Mecanismo de cifrado en tránsito | Compatible desde la versión |
| --- | --- | --- | --- | --- |
| Coordinador de Presto | http-server.https.port | 8446 | TLS | emr-5.6.0\$1, emr-6.0.0\$1, emr-7.0.0\$1 |
| Trabajador de Presto | http-server.https.port | 8446 | TLS | emr-5.6.0\$1, emr-6.0.0\$1, emr-7.0.0\$1 |
## Trino
En las versiones 6.1.0 y posteriores de Amazon EMR, la comunicación interna entre el coordinador y los trabajadores de Presto utiliza TLS. Amazon EMR establece todas las configuraciones necesarias para permitir [una comunicación interna segura](https://trino.io/docs/current/security/internal-communication.html) en Trino.
Si el conector utiliza el metaalmacén de Hive como almacén de metadatos, la comunicación entre el comunicador y el metaalmacén de Hive también se cifra con TLS.
| Componente | punto de enlace | Puerto | Mecanismo de cifrado en tránsito | Compatible desde la versión |
| --- | --- | --- | --- | --- |
| Coordinador de Trino | http-server.https.port | 8446 | TLS | emr-6.1.0\$1, emr-7.0.0\$1 |
| Trabajador de Trino | http-server.https.port | 8446 | TLS | emr-6.1.0\$1, emr-7.0.0\$1 |
## Hive y Tez
De forma predeterminada, el servidor Hive 2, el servidor de metaalmacén Hive, la IU web Hive LLAP Daemon y Hive LLAP intercambian toda la compatibilidad TLS cuando el cifrado en tránsito está habilitado en los clústeres de EMR. Para obtener más información acerca de las configuraciones de Hive, consulte [Propiedades de la configuración](https://cwiki.apache.org/confluence/display/Hive/Configuration+Properties).
La IU de Tez alojada en el servidor Tomcat también está habilitada para HTTPS cuando el cifrado en tránsito está habilitado en el clúster de EMR. Sin embargo, HTTPS está desactivado para el servicio de IU web de Tez AM, por lo que los usuarios de AM no tienen acceso al archivo del almacén de claves del agente de escucha SSL que lo abre. También puede habilitar este comportamiento con las configuraciones booleanas `tez.am.tez-ui.webservice.enable.ssl` y `tez.am.tez-ui.webservice.enable.client.auth`.
| Componente | punto de enlace | Puerto | Mecanismo de cifrado en tránsito | Compatible desde la versión |
| --- | --- | --- | --- | --- |
| HiveServer2. | hive.server2.thrift.port | 10000 | 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 |
| LLAP Daemon | hive.llap.daemon.yarn.shuffle.port | 15551 | TLS | emr-7.3.0\$1 |
| LLAP Daemon | hive.llap.daemon.web.port | 15002 | TLS | emr-7.3.0\$1 |
| LLAP Daemon | hive.llap.daemon.output.service.port | 15003 | Ninguno | Hive no admite el cifrado en tránsito para este punto de conexión |
| LLAP Daemon | hive.llap.management.rpc.port | 15004 | Ninguno | Hive no admite el cifrado en tránsito para este punto de conexión |
| LLAP Daemon | hive.llap.plugin.rpc.port | Dinámico | Ninguno | Hive no admite el cifrado en tránsito para este punto de conexión |
| LLAP Daemon | hive.llap.daemon.rpc.port | Dinámico | Ninguno | Hive no admite el cifrado en tránsito para este punto de conexión |
| Web HCat | templeton.port | 50111 | TLS | emr-7.3.0\$1 |
| Maestro de aplicación de Tez | tez.am.client.am.port-range tez.am.client.am.port-range | Dinámico | Ninguno | Tez no admite el cifrado en tránsito para este punto de conexión |
| Maestro de aplicación de Tez | tez.am.tez-ui.webservice.port-range | Dinámico | Ninguno | Está deshabilitado de forma predeterminada. Se puede habilitar mediante las configuraciones de Tez en emr-7.3.0\$1 |
| Tarea de Tez | N/D: no se puede configurar | Dinámico | Ninguno | Tez no admite el cifrado en tránsito para este punto de conexión |
| Tez UI | Se puede configurar mediante el servidor Tomcat en el que está alojada la IU de Tez | 8080 | TLS | emr-7.3.0\$1 |
## Flink
Los puntos de conexión REST de Apache Flink y la comunicación interna entre los procesos de Flink admiten TLS de forma predeterminada cuando se habilita el cifrado en tránsito en los clústeres de 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á establecido en `true` y usa cifrado en tránsito para la comunicación interna entre los procesos de Flink. Si no desea el cifrado en tránsito para la comunicación interna, deshabilite esa configuración. Se recomienda usar la configuración predeterminada para garantizar la máxima seguridad.
Amazon EMR establece [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) en `true` y utiliza el cifrado en tránsito para los puntos de conexión REST. Además, Amazon EMR también se establece [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) en verdadero para utilizar la comunicación TLS con el servidor de historial de Flink. Si no desea el cifrado en tránsito para los puntos REST, deshabilite esas configuraciones. Se recomienda usar la configuración predeterminada para garantizar la máxima seguridad.
Amazon EMR utiliza [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) para especificar la lista de cifrados que utilizan el cifrado basado en AES. Anule esta configuración para usar los cifrados que desee.
Para obtener más información, consulte [Configuración SSL](https://nightlies.apache.org/flink/flink-docs-release-1.18/docs/deployment/security/security-ssl/) en la documentación de Flink.
| Componente | punto de enlace | Puerto | Mecanismo de cifrado en tránsito | Compatible desde la versión |
| --- | --- | --- | --- | --- |
| Servidor de historial de Flink | historyserver.web.port | 8082 | TLS | emr-7.3.0\$1 |
| Servidor Rest del administrador de trabajos | rest.bind-port rest.port | Dinámico | TLS | emr-7.3.0\$1 |
## HBase
Amazon EMR establece [Secure Hadoop](https://hadoop.apache.org/docs/r2.7.2/hadoop-project-dist/hadoop-common/SecureMode.html#Data_Encryption_on_RPC) RPC en. `privacy` HMaster y RegionServer utilice el cifrado en tránsito basado en SASL. Esto requiere que la autenticación de Kerberos esté habilitada en la configuración de seguridad.
Amazon EMR establece `hbase.ssl.enabled` en verdadero y usa TLS para los puntos de conexión de la IU. Si no desea utilizar TLS para la IU de los puntos de conexión, deshabilite esta configuración. Se recomienda usar la configuración predeterminada para garantizar la máxima seguridad.
Amazon EMR establece `hbase.rest.ssl.enabled` y `hbase.thrift.ssl.enabled` y usa TLS para los puntos de conexión de los servidores REST y Thirft, respectivamente. Si no desea utilizar TLS para estos puntos de conexión, deshabilite esta configuración. Se recomienda usar la configuración predeterminada para garantizar la máxima seguridad.
A partir de EMR 7.6.0, TLS es compatible con los puntos finales. HMaster RegionServer Amazon EMR también establece `hbase.server.netty.tls.enabled` y `hbase.client.netty.tls.enabled`. Si no desea utilizar TLS para estos puntos de conexión, deshabilite esta configuración. Recomendamos mantener la configuración predeterminada, ya que proporciona cifrado y, por lo tanto, mayor seguridad. *Para obtener más información, consulte la sección [Seguridad a nivel de transporte (TLS) en la comunicación HBase RPC en la Guía](https://hbase.apache.org/book.html#_transport_level_security_tls_in_hbase_rpc_communication) de referencia de Apache. HBase *
| Componente | punto de enlace | Puerto | Mecanismo de cifrado en tránsito | Compatible desde la versión |
| --- | --- | --- | --- | --- |
| HMaster | HMaster | 16 000 | SASL \$1 Kerberos TLS | SASL \$1 Kerberos en emr-4.8.0\$1, emr-5.0.0\$1, emr-6.0.0\$1 y emr-7.0.0\$1 TLS en emr-7.6.0\$1 |
| HMaster | HMaster INTERFAZ DE USUARIO | 16010 | TLS | emr-7.3.0\$1 |
| RegionServer | RegionServer | 16020 | SASL \$1 Kerberos TLS | SASL \$1 Kerberos en emr-4.8.0\$1, emr-5.0.0\$1, emr-6.0.0\$1 y emr-7.0.0\$1 TLS en emr-7.6.0\$1 |
| RegionServer | RegionServer Información | 16030 | TLS | emr-7.3.0\$1 |
| HBase Servidor REST | Servidor Rest | 8070 | TLS | emr-7.3.0\$1 |
| HBase Servidor REST | IU REST | 8085 | TLS | emr-7.3.0\$1 |
| Servidor Thrift de HBase | Servidor Thrift | 9090 | TLS | emr-7.3.0\$1 |
| Servidor Thrift de HBase | IU del servidor Thrift | 9095 | TLS | emr-7.3.0\$1 |
## Phoenix
Si habilitó el cifrado en tránsito en su clúster de EMR, Phoenix Query Server admite la propiedad TLS de `phoenix.queryserver.tls.enabled`, que está establecida de forma predeterminada en `true`.
Para obtener más información, consulte [ Configuraciones relacionadas con HTTPS](https://phoenix.apache.org/server.html#Configuration) en la documentación de Phoenix Query Server.
| Componente | punto de enlace | Puerto | Mecanismo de cifrado en tránsito | Compatible desde la versión |
| --- | --- | --- | --- | --- |
| Servidor de consultas | phoenix.queryserver.http.port | 8765 | TLS | emr-7.3.0\$1 |
## Oozie
[OOZIE-3673](https://issues.apache.org/jira/browse/OOZIE-3673) está disponible en Amazon EMR si ejecuta Oozie en Amazon EMR 7.3.0 y versiones posteriores. Si necesita configurar protocolos SSL o TLS personalizados al ejecutar una acción de correo electrónico, puede establecer la propiedad `oozie.email.smtp.ssl.protocols` en el archivo `oozie-site.xml`. De forma predeterminada, si ha activado el cifrado en tránsito, Amazon EMR utiliza el protocolo TLS v1.3.
[OOZIE-3677](https://issues.apache.org/jira/browse/OOZIE-3677) y [OOZIE-3674](https://issues.apache.org/jira/browse/OOZIE-3674) están también disponible en Amazon EMR si ejecuta Oozie en Amazon EMR 7.3.0 y versiones posteriores. Esto le permite especificar las propiedades `keyStoreType` y `trustStoreType` en `oozie-site.xml`. OOZIE-3674 añade el parámetro `--insecure` al cliente de Oozie para que pueda ignorar los errores de certificado.
Oozie exige la verificación del nombre de host mediante TLS, lo que significa que cualquier certificado que utilice para el cifrado en tránsito debe cumplir los requisitos de verificación del nombre de host. Si el certificado no cumple los criterios, el clúster podría quedarse atascado en la fase de `oozie share lib update` en la que Amazon EMR aprovisiona el clúster. Se recomienda actualizar los certificados para asegurarse de que cumplen con la verificación del nombre de host. Sin embargo, si no puede actualizar los certificados, puede deshabilitar el SSL para Oozie estableciendo la propiedad de `oozie.https.enabled` en `false` en la configuración del clúster.
| Componente | punto de enlace | Puerto | Mecanismo de cifrado en tránsito | Compatible desde la versión |
| --- | --- | --- | --- | --- |
| EmbeddedOozieServer | oozie.https.port | 11443 | TLS | emr-7.3.0\$1 |
| EmbeddedOozieServer | oozie.email.smtp.port | 25 | TLS | emr-7.3.0\$1 |
## Hue
De forma predeterminada, Hue admite TLS cuando el cifrado en tránsito está habilitado en los clústeres de Amazon EMR. Para obtener más información sobre la configuración de Hue, consulte [Configure Hue with HTTPS / SSL](https://gethue.com/configure-hue-with-https-ssl/).
| Componente | punto de enlace | Puerto | Mecanismo de cifrado en tránsito | Compatible desde la versión |
| --- | --- | --- | --- | --- |
| Hue | http\$1port | 8888 | TLS | emr-7.4.0\$1 |
## Livy
De forma predeterminada, Livy admite TLS cuando el cifrado en tránsito está habilitado en los clústeres de Amazon EMR. Para obtener más información sobre la configuración de Livy, consulte [Habilitación de HTTPS con Apache Livy](https://docs.aws.amazon.com/emr/latest/ReleaseGuide/enabling-https.html).
A partir de Amazon EMR 7.3.0, si utiliza cifrado en tránsito y autenticación Kerberos, no podrá usar el servidor Livy para aplicaciones de Spark que dependen del metalmacén de Hive. Este problema se solucionó en [HIVE-16340](https://issues.apache.org/jira/browse/HIVE-16340) y se resolvió por completo en [SPARK-44114](https://issues.apache.org/jira/browse/SPARK-44114) cuando la aplicación de Spark de código abierto puede actualizarse a Hive 3. Mientras tanto, puede evitar este problema si establece `hive.metastore.use.SSL` en `false`. Para obtener más información, consulte [Configuración de aplicaciones](https://docs.aws.amazon.com/emr/latest/ReleaseGuide/emr-configure-apps.html).
Para obtener más información, consulte [Habilitación de HTTPS con Apache Livy](https://docs.aws.amazon.com/emr/latest/ReleaseGuide/enabling-https.html).
| Componente | punto de enlace | Puerto | Mecanismo de cifrado en tránsito | Compatible desde la versión |
| --- | --- | --- | --- | --- |
| livy-server | livy.server.port | 8998 | TLS | emr-7.4.0\$1 |
## JupyterEnterpriseGateway
De forma predeterminada, Jupyter Enterprise Gateway admite TLS cuando el cifrado en tránsito está habilitado en los clústeres de Amazon EMR. Para obtener más información sobre la configuración de Jupyter Enterprise Gateway, consulte [Securing Enterprise Gateway Server](https://jupyter-enterprise-gateway.readthedocs.io/en/v1.2.0/getting-started-security.html#securing-enterprise-gateway-server).
| Componente | punto de enlace | Puerto | Mecanismo de cifrado en tránsito | Compatible desde la versión |
| --- | --- | --- | --- | --- |
| jupyter\$1enterprise\$1gateway | c. .puerto EnterpriseGatewayApp | 9547 | TLS | emr-7.4.0\$1 |
## JupyterHub
De forma predeterminada, JupyterHub admite TLS cuando el cifrado en tránsito está habilitado en los clústeres de Amazon EMR. Para obtener más información, consulte [Habilitar el cifrado SSL](https://jupyterhub.readthedocs.io/en/latest/tutorial/getting-started/security-basics.html#enabling-ssl-encryption) en la documentación. JupyterHub No se recomienda desactivar el cifrado.
| Componente | punto de enlace | Puerto | Mecanismo de cifrado en tránsito | Compatible desde la versión |
| --- | --- | --- | --- | --- |
| jupyter\$1hub | c. JupyterHub .port | 9443 | TLS | emr-5.14.0\$1, emr-6.0.0\$1, emr-7.0.0\$1 |
## Zeppelin
De forma predeterminada, Zeppelin admite TLS cuando habilita el cifrado en tránsito en su clúster de EMR. Para obtener más información sobre las configuraciones de Zeppelin, consulte [Configuración SSL](https://zeppelin.apache.org/docs/0.11.1/setup/operation/configuration.html#ssl-configuration) en la documentación de Zeppelin.
| Componente | punto de enlace | Puerto | Mecanismo de cifrado en tránsito | Compatible desde la versión |
| --- | --- | --- | --- | --- |
| Zeppelin | zeppelin.server.ssl.port | 8890 | TLS | 7.3.0\$1 |
## ZooKeeper
Amazon EMR define `serverCnxnFactory` en `org.apache.zookeeper.server.NettyServerCnxnFactory` para habilitar TLS en el quórum de Zookeeper y en la comunicación con los clientes.
`secureClientPort` especifica el puerto que recibe las conexiones TLS. Si el cliente no admite conexiones TLS con Zookeeper, puede conectarse al puerto inseguro 2181 definido en `clientPort`. Usted puede sobrescribir o desactivar estos dos puertos.
Amazon EMR también define `sslQuorum` y `admin.forceHttps` en `true` para habilitar TLS en la comunicación del quórum y en el servidor de administración. Si no desea cifrado en tránsito para el quórum y el servidor de administración, puede desactivar esas configuraciones. Recomendamos mantener las configuraciones predeterminadas, ya que ofrecen un mayor nivel de seguridad.
Para obtener más información, consulte [Encryption, Authentication, Authorization Options](https://zookeeper.apache.org/doc/r3.9.2/zookeeperAdmin.html#sc_authOptions) en la documentación de Zookeeper.
| Componente | punto de enlace | Puerto | Mecanismo de cifrado en tránsito | Compatible desde la versión |
| --- | --- | --- | --- | --- |
| Zookeeper Server | secureClientPort | 2281 | TLS | emr-7.4.0\$1 |
| Zookeeper Server | Puertos de quórum | Hay dos: Los seguidores usan 2888 para conectarse al líder. La elección del líder usa 3888. | TLS | emr-7.4.0\$1 |
| Zookeeper Server | admin.serverPort | 8341 | TLS | emr-7.4.0\$1 |