As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá.
# Criptografia de dados em repouso e em trânsito com o Amazon EMR
A criptografia de dados ajuda a impedir que usuários não autorizados leiam dados em um cluster e em sistemas de armazenamento físico de dados associados. Isso inclui dados salvos em mídias persistentes, conhecidos como dados *em repouso*, e dados que podem ser interceptados enquanto viajam pela rede, conhecidos como dados *em trânsito*.
Começando com o Amazon EMR versão 4.8.0, você pode usar as configurações de segurança do Amazon EMR para definir configurações de criptografia de dados para clusters com mais facilidade. Configurações de segurança oferecem configurações para habilitar a segurança dos dados em trânsito e dos dados em repouso em volumes do Amazon Elastic Block Store (Amazon EBS) e do EMRFS no Amazon S3.
Opcionalmente, a partir do Amazon EMR versão 4.1.0 e posterior, você tem a opção de configurar a criptografia transparente no HDFS, que não é configurada usando configurações de segurança. Para obter mais informações, consulte [Transparent encryption in HDFS on Amazon EMR](https://docs.aws.amazon.com/emr/latest/ReleaseGuide/emr-encryption-tdehdfs.html) no *Guia de lançamento do Amazon EMR*.
**Topics**
+ [Opções de criptografia do Amazon EMR](emr-data-encryption-options.md)
+ [Criptografia em repouso usando uma chave do KMS do cliente para o serviço EMR WAL](encryption-at-rest-kms.md)
+ [Criação de chaves e certificados para criptografia de dados com o Amazon EMR](emr-encryption-enable.md)
+ [Noções básicas da criptografia em trânsito](emr-encryption-support-matrix.md)
# Opções de criptografia do Amazon EMR
Com a versão 4.8.0 ou posteriores do Amazon EMR, é possível usar uma configuração de segurança para especificar configurações de criptografia de dados em repouso, dados em trânsito ou ambos. Ao habilitar a criptografia de dados em repouso, você tem a opção de criptografar dados do EMRFS no Amazon S3, dados em discos locais ou ambos. Cada configuração de segurança que você cria é armazenada no Amazon EMR, e não na configuração do cluster. Dessa forma, você pode facilmente reutilizar uma configuração para especificar as configurações de criptografia de dados sempre que criar um cluster. Para obter mais informações, consulte [Crie uma configuração de segurança com o console do Amazon EMR ou com o AWS CLI](emr-create-security-configuration.md).
O diagrama a seguir mostra as diferentes opções de criptografia de dados disponíveis com as configurações de segurança.
![\[Há várias opções de criptografia em trânsito e em repouso disponíveis no Amazon EMR.\]](http://docs.aws.amazon.com/pt_br/emr/latest/ManagementGuide/images/emr-encryption-options.png)
As seguintes opções de criptografia também estão disponíveis e não são configuradas usando uma configuração de segurança:
+ Se preferir, com as versões 4.1.0 e posteriores do Amazon EMR, você pode optar por configurar uma criptografia transparente no HDFS. Para obter mais informações, consulte [Transparent encryption in HDFS on Amazon EMR](https://docs.aws.amazon.com/emr/latest/ReleaseGuide/emr-encryption-tdehdfs.html) no *Guia de lançamento do Amazon EMR*.
+ Se estiver usando uma versão do Amazon EMR que não seja compatível com as configurações de segurança, você poderá configurar a criptografia para dados do EMRFS no Amazon S3 manualmente. Para obter mais informações, consulte [Specifying Amazon S3 encryption using EMRFS properties](https://docs.aws.amazon.com/emr/latest/ReleaseGuide/emr-emrfs-encryption.html).
+ Se você estiver usando uma versão do Amazon EMR anterior à 5.24.0, só haverá suporte para volumes de dispositivo raiz do EBS criptografados ao usar uma AMI personalizada. Para obter mais informações, consulte [Creating a custom AMI with an encrypted Amazon EBS root device volume](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-custom-ami.html#emr-custom-ami-encrypted) no *Guia de gerenciamento do Amazon EMR*.
**nota**
A partir da versão 5.24.0 do Amazon EMR, você pode usar uma opção de configuração de segurança para criptografar o dispositivo raiz e os volumes de armazenamento do EBS ao especificar como seu provedor de chaves. AWS KMS Para obter mais informações, consulte [Criptografia de disco local](#emr-encryption-localdisk).
A criptografia de dados requer chaves e certificados. Uma configuração de segurança oferece a flexibilidade de escolher entre várias opções, incluindo chaves gerenciadas por AWS Key Management Service, chaves gerenciadas pelo Amazon S3 e chaves e certificados de fornecedores personalizados fornecidos por você. Ao usar AWS KMS como seu provedor de chaves, cobranças se aplicam pelo armazenamento e uso de chaves de criptografia. Para obter mais informações, consulte [Preços do AWS KMS](https://aws.amazon.com/kms/pricing/).
Antes de especificar opções de criptografia, decida quais sistemas de gerenciamento de chaves e certificados você deseja usar, para poder primeiro criar as chaves e os certificados ou os provedores personalizados especificados como parte das configurações de criptografia.
## Criptografia em repouso para dados do EMRFS no Amazon S3
A criptografia do Amazon S3 funciona com objetos do Amazon EMR File System (EMRFS) lidos e gravados no Amazon S3. Você especifica a criptografia do lado do servidor (SSE) ou a criptografia do lado do cliente (CSE) do Amazon S3 como o **modo de criptografia padrão** ao habilitar a criptografia em repouso. Opcionalmente, você pode especificar diferentes métodos de criptografia para buckets individuais usando **Per bucket encryption overrides (Substituições de criptografia por bucket)**. Independentemente de a criptografia do Amazon S3 estar habilitada, o Transport Layer Security (TLS) criptografa os objetos do EMRFS em trânsito entre os nós do cluster do EMR e o Amazon S3. Para obter mais informações sobre criptografia no Amazon S3, consulte [Protecting data using encryption](https://docs.aws.amazon.com/AmazonS3/latest/userguide/UsingEncryption.html) no *Guia do usuário do Amazon Simple Storage Service*.
**nota**
Quando você usa AWS KMS, cobranças são cobradas pelo armazenamento e uso de chaves de criptografia. Para obter mais informações, consulte [AWS KMS Preço](https://aws.amazon.com/kms/pricing/).
### Criptografia do lado do servidor do Amazon S3
Todos os buckets do Amazon S3 têm criptografia configurada por padrão, e todos os novos objetos que são carregados em um bucket do S3 são automaticamente criptografados em repouso. O Amazon S3 criptografa os dados no nível do objeto à medida que os grava no disco e os descriptografa quando eles são acessados. Para ter mais informações sobre o SSE, consulte [Proteger os dados usando criptografia do lado do servidor](https://docs.aws.amazon.com/AmazonS3/latest/userguide/serv-side-encryption.html) no *Guia do usuário do Amazon Simple Storage Service*.
Você pode escolher entre dois sistemas de gerenciamento de chaves diferentes ao especificar a SSE no Amazon EMR:
+ **SSE-S3**: o Amazon S3 gerencia as chaves para você.
+ **SSE-KMS** — Você usa um AWS KMS key para configurar políticas adequadas para o Amazon EMR. Para obter mais informações sobre os principais requisitos do Amazon EMR, consulte [Uso AWS KMS keys para criptografia](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-encryption-enable.html#emr-awskms-keys).
A SSE com chaves fornecidas pelo cliente (SSE-C) não está disponível para o uso com o Amazon EMR.
### Criptografia do lado do cliente do Amazon S3
Com a criptografia do lado do cliente do Amazon S3, a criptografia e a descriptografia do Amazon S3 ocorrem no cliente do EMRFS em seu cluster. Os objetos são criptografados antes de serem carregados no Amazon S3 e descriptografados após serem baixados. O provedor especificado por você fornece a chave de criptografia que o cliente usa. O cliente pode usar chaves fornecidas pelo AWS KMS (CSE-KMS) ou uma classe Java personalizada que fornece a chave raiz do lado do cliente (CSE-C). As especificações de criptografia são ligeiramente diferentes entre a CSE-KMS e a CSE-C, dependendo do provedor especificado e dos metadados do objeto que está sendo descriptografado ou criptografado. Para obter mais informações sobre essas diferenças, consulte [Proteger dados usando a criptografia do lado do cliente](https://docs.aws.amazon.com/AmazonS3/latest/userguide/UsingClientSideEncryption.html) no *Guia do usuário do Amazon Simple Storage Service*.
**nota**
A CSE do Amazon S3 garante somente que os dados do EMRFS trocados com o Amazon S3 sejam criptografados. Não são todos os dados nos volumes de instâncias do cluster que são criptografados. Além disso, como o Hue não usa o EMRFS, os objetos que o navegador de arquivos do S3 para Hue grava no Amazon S3 não são criptografados.
## Criptografia em repouso para dados no Amazon EMR WAL
Ao configurar a criptografia do lado do servidor (SSE) para registro em log com gravação antecipada (WAL), o Amazon EMR criptografa dados em repouso. Você pode escolher entre dois sistemas de gerenciamento de chaves diferentes ao especificar a SSE no Amazon EMR:
**SSE-EMR-WAL**
O Amazon EMR gerencia as chaves para você. Por padrão, o Amazon EMR criptografa os dados armazenados no Amazon EMR WAL com SSE-EMR-WAL.
**SSE-KMS-WAL**
Você usa uma AWS KMS chave para configurar políticas que se aplicam ao Amazon EMR WAL. Para obter mais informações sobre como configurar a criptografia em repouso para WAL do EMR usando uma chave do KMS do cliente, consulte [Criptografia em repouso usando uma chave KMS do do cliente para o serviço de WAL do EMR](https://docs.aws.amazon.com/emr/latest/ManagementGuide/encryption-at-rest-kms.html).
**nota**
Você não pode usar sua própria chave com o SSE ao habilitar o WAL com o Amazon EMR. Para obter mais informações, consulte [Write-ahead logs (WAL) for Amazon EMR](https://docs.aws.amazon.com/emr/latest/ReleaseGuide/emr-hbase-wal.html).
## Criptografia de disco local
Os mecanismos a seguir funcionam em conjunto para criptografar discos locais quando você habilita a criptografia de disco local usando uma configuração de segurança do Amazon EMR.
### Criptografia HDFS de código aberto
O HDFS troca dados entre instâncias de cluster durante o processamento distribuído. Ele também lê e grava dados em volumes de armazenamento de instâncias e em volumes do EBS anexados às instâncias. As seguintes opções de criptografia Hadoop de código-fonte aberto são ativadas quando você habilita a criptografia do disco local:
+ [Secure Hadoop RPC](https://hadoop.apache.org/docs/r2.7.2/hadoop-project-dist/hadoop-common/SecureMode.html#Data_Encryption_on_RPC): é definida como `Privacy`, que usa a 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.): é definida como `true` e configurada para usar a criptografia AES de 256 bits.
**nota**
Você pode ativar a criptografia adicional do Apache Hadoop habilitando a criptografia em trânsito. Para obter mais informações, consulte [Criptografia em trânsito](#emr-encryption-intransit). Essas configurações de criptografia não ativam a criptografia transparente do HDFS, que você pode configurar manualmente. Para obter mais informações, consulte [Transparent encryption in HDFS on Amazon EMR](https://docs.aws.amazon.com/emr/latest/ReleaseGuide/emr-encryption-tdehdfs.html) no *Guia de lançamento do Amazon EMR*.
### Criptografia de armazenamento de instância
Para tipos de instância do EC2 que usam NVMe based SSDs como volume de armazenamento de instâncias, a NVMe criptografia é usada independentemente das configurações de criptografia do Amazon EMR. Para obter mais informações, consulte [volumes NVMe SSD](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ssd-instance-store.html#nvme-ssd-volumes) no Guia do usuário do *Amazon EC2*. Para outros volumes de armazenamento de instância, o Amazon EMR usa LUKS para criptografar o volume de armazenamento de instância quando a criptografia de disco local está habilitada, não importa se os volumes do EBS foram criptografados usando criptografia do EBS ou LUKS.
### Criptografia de volume do EBS
Se você criar um cluster em uma região onde a criptografia do Amazon EC2 de volumes do EBS está habilitada por padrão para sua conta, os volumes do EBS serão criptografados mesmo que a criptografia de disco local não esteja habilitada. Para obter mais informações, consulte [Habilitar a criptografia por padrão](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/EBSEncryption.html#encryption-by-default) no *Manual do usuário do Amazon EC2*. Com a criptografia de disco local habilitada em uma configuração de segurança, as configurações do Amazon EMR têm precedência sobre as configurações do Amazon EC2 para instâncias EC2 encryption-by-default em cluster.
As seguintes opções estão disponíveis para criptografar volumes do EBS usando uma configuração de segurança:
+ **Criptografia do EBS**: a partir do Amazon EMR versão 5.24.0, você tem a opção de habilitar a criptografia do EBS. A opção de criptografia do EBS criptografa o volume do dispositivo raiz do EBS e os volumes de armazenamento anexados. A opção de criptografia do EBS está disponível somente quando você especifica AWS Key Management Service como seu provedor de chaves. Recomendamos usar a criptografia do EBS.
+ **Criptografia LUKS**: se você optar por usar a criptografia LUKS para volumes do Amazon EBS, a criptografia LUKS se aplicará apenas a volumes de armazenamento anexados, e não ao volume do dispositivo raiz. Para obter mais informações sobre a criptografia LUKS, consulte a [Especificação da no disco](https://gitlab.com/cryptsetup/cryptsetup/wikis/Specification).
Para seu provedor de chaves, você pode configurar uma AWS KMS key com políticas adequadas para o Amazon EMR ou uma classe Java personalizada que forneça os artefatos de criptografia. Quando você usa AWS KMS, cobranças são cobradas pelo armazenamento e uso de chaves de criptografia. Para obter mais informações, consulte [Preços do AWS KMS](https://aws.amazon.com/kms/pricing/).
**nota**
Para verificar se a criptografia do EBS está habilitada no cluster, é recomendável usar a chamada de API `DescribeVolumes`. Para obter mais informações, consulte [DescribeVolumes](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_DescribeVolumes.html). A execução de `lsblk` no cluster só verificará o status da criptografia LUKS, em vez da criptografia do EBS.
## Criptografia em trânsito
Vários mecanismos de criptografia estão habilitados com a criptografia em trânsito. Esses recursos são de código aberto, específicos da aplicação, e podem variar de acordo com a versão do Amazon EMR. Para habilitar a criptografia em trânsito, use [Crie uma configuração de segurança com o console do Amazon EMR ou com o AWS CLI](emr-create-security-configuration.md) no Amazon EMR. Para clusters do EMR com criptografia em trânsito habilitada, o Amazon EMR define automaticamente as configurações da aplicação de código aberto para permitir a criptografia em trânsito. Em casos de uso avançados, você pode definir diretamente as configurações de aplicações de código aberto para substituir o comportamento padrão no Amazon EMR. Para obter mais informações, consulte a [In-transit encryption support matrix](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-encryption-support-matrix.html) e [Configuração de aplicações](https://docs.aws.amazon.com/emr/latest/ReleaseGuide/emr-configure-apps.html).
Consulte as seguintes informações para saber mais detalhes específicos sobre aplicações de código aberto relevantes à criptografia em trânsito:
+ Quando você habilita a criptografia em trânsito com uma configuração de segurança, o Amazon EMR ativa a criptografia em trânsito para todos os endpoints de aplicações de código aberto que oferecem suporte à criptografia em trânsito. O suporte à criptografia em trânsito para diferentes endpoints de aplicações varia de acordo com a versão de lançamento do Amazon EMR. Para obter mais informações, consulte a [matriz de suporte à criptografia em trânsito](https://docs.aws.amazon.com/).
+ Você pode substituir as configurações de código aberto, o que permite fazer o seguinte:
+ Desabilite a verificação do nome de host TLS se os certificados TLS fornecidos pelo usuário não atenderem aos requisitos
+ Desabilite a criptografia em trânsito para determinados endpoints com base nos seus requisitos de performance e compatibilidade
+ Controle quais versões do TLS e pacotes de criptografia usar.
Você encontra mais detalhes sobre as configurações específicas da aplicação na [matriz de suporte à criptografia em trânsito](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-encryption-support-matrix.html)
+ Além de habilitar a criptografia em trânsito com uma configuração de segurança, alguns canais de comunicação também exigem configurações de segurança adicionais para que você habilite a criptografia em trânsito. Por exemplo, alguns endpoints de aplicações de código aberto usam Simple Authentication and Security Layer (SASL) para criptografia em trânsito, o que exige que a autenticação do Kerberos esteja habilitada na configuração de segurança do cluster do EMR. Para saber mais sobre esses endpoints, consulte a [matriz de suporte à criptografia em trânsito](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-encryption-support-matrix.html).
+ Recomendamos que você use um software compatível com TLS v1.2 ou superior. O Amazon EMR no EC2 envia a distribuição padrão do Corretto JDK, que determina quais versões do TLS, conjuntos de cifras e tamanhos de chave são permitidos pelas redes de código aberto executadas em Java. No momento, a maioria das estruturas de código aberto impõe o TLS v1.2 ou superior para o Amazon EMR 7.0.0 e versões superiores. Isso ocorre porque a maioria das estruturas de código aberto é executada no Java 17 para o Amazon EMR 7.0.0 e versões superiores. As versões mais antigas do Amazon EMR podem oferecer suporte ao TLS v1.0 e v1.1 porque consomem versões mais antigas do Java, mas o Corretto JDK pode alterar as versões do TLS compatíveis com Java, o que pode afetar as versões existentes do Amazon EMR.
Você especifica os artefatos de criptografia usados para a criptografia em trânsito de uma destas duas maneiras: fornecendo um arquivo compactado de certificados, que é carregado no Amazon S3, ou referenciando uma classe Java personalizada, que fornece artefatos de criptografia. Para obter mais informações, consulte [Fornecer certificados para criptografia de dados em trânsito com a criptografia do Amazon EMR](emr-encryption-enable.md#emr-encryption-certificates).
# Criptografia em repouso usando uma chave do KMS do cliente para o serviço EMR WAL
Os registros de gravação antecipada (WAL) do EMR fornecem suporte chave KMS ao cliente. encryption-at-rest A seguir, detalhamos em alto nível como o recurso de WAL do Amazon EMR WAL é integrado ao AWS KMS:
Os registros de gravação antecipada (WAL) do EMR interagem AWS durante as seguintes operações:`CreateWAL`,,,,,, `AppendEdit` `ArchiveWALCheckPoint` `CompleteWALFlush` `DeleteWAL` `GetCurrentWALTime``ReplayEdits`, `TrimWAL` `EMR_EC2_DefaultRole` por padrão. Quando qualquer uma das operações anteriores listadas é invocada, o EMR WAL cria e com base na chave KMS. `Decrypt` `GenerateDataKey`
## Considerações
Considere o seguinte ao usar a criptografia AWS KMS baseada para EMR WAL:
+ Não é possível alterar a configuração de criptografia após a criação de um WAL do EMR.
+ Ao usar a criptografia KMS com sua própria chave do KMS, a chave deve existir na mesma região que seu cluster do Amazon EMR.
+ Você é responsável por manter todas as permissões necessárias do IAM e é recomendável não revogar as permissões necessárias durante a vida útil do WAL. Caso contrário, isso causará cenários de falha inesperados, como a incapacidade de excluir o WAL do EMR, pois a chave de criptografia associada não existe.
+ Há um custo associado ao uso de AWS KMS chaves. Para obter mais informações, consulte [Preços do AWS Key Management Service](https://aws.amazon.com/kms/pricing/).
## Permissões obrigatórias do IAM
Para usar a chave do KMS do cliente para criptografar o WAL do EMR em repouso, você precisa ter certeza de definir a permissão adequada para o perfil de cliente do WAL do EMR e para a entidade principal `emrwal.amazonaws.com` do serviço WAL do EMR.
### Permissões para o perfil de cliente WAL do EMR
Abaixo está a política do IAM necessária para o perfil de cliente WAL do EMR:
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"kms:Decrypt",
"kms:GenerateDataKey*"
],
"Resource": [
"*"
],
"Sid": "AllowKMSDecrypt"
}
]
}
```
------
O cliente WAL do EMR no cluster do EMR usará `EMR_EC2_DefaultRole` por padrão. Se você usar um perfil diferente para o perfil de instância no cluster do EMR, certifique-se de que cada perfil tenha permissões apropriadas.
Para obter informações sobre gerenciamento da política de perfil, consulte [Adicionar e remover permissões de identidade do IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_manage-attach-detach.html).
### Permissões para a política de chave do KMS
Você precisa conceder o perfil do cliente WAL do EMR e as permissões `Decrypt` e `GenerateDataKey*` do serviço WAL do EMR na sua política do KMS. Para obter mais informações sobre o gerenciamento de políticas de chaves, consulte [Política de chaves do 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"
}
]
}
```
------
O perfil especificado no snippet pode mudar se você alterar o perfil padrão.
## Monitorando a interação do Amazon EMR WAL com AWS KMS
### Contexto de criptografia de WAL do Amazon EMR
Um contexto de criptografia é um conjunto de pares de chave-valor que contêm dados arbitrários não secretos. Quando você inclui um contexto de criptografia em uma solicitação para criptografar dados, vincula AWS KMS criptograficamente o contexto de criptografia aos dados criptografados. Para descriptografar os dados, é necessário passar o mesmo contexto de criptografia.
Em suas solicitações [GenerateDataKey](https://docs.aws.amazon.com/kms/latest/APIReference/API_GenerateDataKey.html)e [Decrypt para](https://docs.aws.amazon.com/kms/latest/APIReference/API_Decrypt.html), o AWS KMS Amazon EMR WAL usa um contexto de criptografia com pares de um nome e valor que identificam o nome WAL do EMR.
```
"encryptionContext": {
"aws:emrwal:walname": "111222333444555-testworkspace-emrwalclustertest-emrwaltestwalname"
}
```
Você pode usar o contexto de criptografia para identificar essas operações criptográficas em registros e registros de auditoria, como AWS CloudTrail [Amazon CloudWatch Logs](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-user-guide.html), e como condição para autorização em políticas e concessões.
# Criação de chaves e certificados para criptografia de dados com o Amazon EMR
Antes de especificar as opções de criptografia usando uma configuração de segurança, decida qual provedor você quer usar para as chaves e os artefatos criptográficos. Por exemplo, você pode usar AWS KMS ou um provedor personalizado criado por você. Depois, crie as chaves ou o provedor de chaves conforme descrito nesta seção.
## Fornecimento de chaves para criptografia de dados em repouso
Você pode usar AWS Key Management Service (AWS KMS) ou um provedor de chave personalizado para criptografia de dados em repouso no Amazon EMR. Quando você usa AWS KMS, cobranças são cobradas pelo armazenamento e uso de chaves de criptografia. Para obter mais informações, consulte [Preços do AWS KMS](https://aws.amazon.com/kms/pricing/).
Este tópico fornece detalhes sobre políticas de chave para uma chave do KMS a ser usada com o Amazon EMR, bem como orientações e exemplos de código para escrever uma classe de provedor de chave personalizada para criptografia do Amazon S3. Para obter mais informações sobre como criar chaves, consulte [Creating keys](https://docs.aws.amazon.com/kms/latest/developerguide/create-keys.html) no *Guia do desenvolvedor do AWS Key Management Service *.
### Usando AWS KMS keys para criptografia
A chave de AWS KMS criptografia deve ser criada na mesma região da sua instância de cluster do Amazon EMR e dos buckets do Amazon S3 usados com o EMRFS. Se a chave especificada estiver em uma conta diferente da que foi usada para configurar um cluster, será necessário especificar a chave usando o respectivo ARN.
O perfil do perfil de instância do Amazon EC2 deverá ter permissões para usar a chave do KMS que você especificar. O perfil padrão para o perfil de instância no Amazon EMR é `EMR_EC2_DefaultRole`. Se você usar um perfil diferente para o perfil de instância ou usar perfis do IAM para solicitações do EMRFS para o Amazon S3, certifique-se de que cada perfil seja adicionado como um usuário de chave, conforme o caso. Isso concede ao perfil permissões para usar a chave do KMS. Para obter mais informações, consulte [Using Key Policies](https://docs.aws.amazon.com/kms/latest/developerguide/key-policies.html#key-policy-default-allow-users) no *Guia do desenvolvedor do AWS Key Management Service * e [Configure IAM roles for EMRFS requests to Amazon S3](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-emrfs-iam-roles.html).
Você pode usar o Console de gerenciamento da AWS para adicionar seu perfil de instância ou perfil de instância do EC2 à lista de usuários principais da chave KMS especificada, ou você pode usar o AWS CLI ou um AWS SDK para anexar uma política de chaves apropriada.
O Amazon EMR oferece suporte somente a [chaves do KMS simétricas](https://docs.aws.amazon.com/kms/latest/developerguide/concepts.html#symmetric-cmks). Não é possível usar uma [chave do KMS assimétrica](https://docs.aws.amazon.com/kms/latest/developerguide/symmetric-asymmetric.html#asymmetric-cmks) para criptografar dados em repouso em um cluster do Amazon EMR. Para obter ajuda para determinar se uma chave do KMS é simétrica ou assimétrica, consulte [Identifying symmetric and asymmetric KMS keys](https://docs.aws.amazon.com/kms/latest/developerguide/find-symm-asymm.html).
O procedimento abaixo descreve como adicionar o perfil de instância do Amazon EMR padrão, `EMR_EC2_DefaultRole`, como um *usuário de chave* usando o Console de gerenciamento da AWS. Ele pressupõe que você já tenha criado uma chave do KMS. Para criar uma nova chave do KMS, consulte [Creating Keys](https://docs.aws.amazon.com/kms/latest/developerguide/create-keys.html) no *Guia do desenvolvedor do AWS Key Management Service *.
**Adicionar o perfil de instância do EC2 para Amazon EMR à lista de usuários de chaves de criptografia**
1. Faça login no console Console de gerenciamento da AWS e abra o AWS Key Management Service (AWS KMS) em [https://console.aws.amazon.com/kms](https://console.aws.amazon.com/kms).
1. Para alterar o Região da AWS, use o seletor de região no canto superior direito da página.
1. Selecione o alias da chave do KMS a ser modificada.
1. Na página de detalhes da chave, em **Key Users (Usuários de chaves)**, escolha **Add (Adicionar)**.
1. Na caixa de diálogo **Add key users (Adicionar usuários da chave)** selecione a função apropriada. O nome da função padrão é `EMR_EC2_DefaultRole`.
1. Escolha **Adicionar**.
### Habilitar a criptografia do EBS fornecendo permissões adicionais para chaves do KMS
A partir do Amazon EMR versão 5.24.0, você pode criptografar o dispositivo raiz do EBS e os volumes de armazenamento usando uma opção de configuração de segurança. Para ativar essa opção, você deve especificar AWS KMS como seu provedor de chaves. Além disso, você deve conceder à função `EMR_DefaultRole` de serviço permissões para usar o AWS KMS key que você especificar.
Você pode usar o Console de gerenciamento da AWS para adicionar a função de serviço à lista de usuários principais da chave KMS especificada ou usar o AWS CLI ou um AWS SDK para anexar uma política de chaves apropriada.
O procedimento a seguir descreve como usar o Console de gerenciamento da AWS para adicionar a função de serviço padrão do Amazon EMR `EMR_DefaultRole` como um usuário *chave*. Ele pressupõe que você já tenha criado uma chave do KMS. Para criar uma nova chave do KMS, consulte [Creating keys](https://docs.aws.amazon.com/kms/latest/developerguide/create-keys.html) no *Guia do desenvolvedor do AWS Key Management Service *.
**Para adicionar o perfil de serviço do Amazon EMR à lista de usuários de chaves de criptografia**
1. Faça login no console Console de gerenciamento da AWS e abra o AWS Key Management Service (AWS KMS) em [https://console.aws.amazon.com/kms](https://console.aws.amazon.com/kms).
1. Para alterar o Região da AWS, use o seletor de região no canto superior direito da página.
1. Escolha **Chaves gerenciadas pelo cliente** na barra lateral esquerda.
1. Selecione o alias da chave do KMS a ser modificada.
1. Na página de detalhes da chave, em **Key Users (Usuários de chaves)**, escolha **Add (Adicionar)**.
1. Na seção **Adicionar usuários da chave** selecione o perfil apropriado. O nome do perfil de serviço padrão do Amazon EMR é `EMR_DefaultRole`.
1. Escolha **Adicionar**.
### Criar um provedor de chaves personalizado
Ao usar uma configuração de segurança, você deve especificar um nome de classe de provedor diferente para a criptografia de disco local e para a criptografia do Amazon S3. Os requisitos para o provedor de chaves personalizadas dependem de você usar criptografia de disco local e criptografia do Amazon S3, bem como da versão de lançamento do Amazon EMR.
Dependendo do tipo de criptografia que você usa ao criar um provedor de chave personalizado, o aplicativo também deve implementar EncryptionMaterialsProvider interfaces diferentes. Ambas as interfaces estão disponíveis no AWS SDK for Java versão 1.11.0 e posterior.
+ [Para implementar a criptografia do Amazon S3, use o com.amazonaws.services.s3.model. EncryptionMaterialsProvider ](https://docs.aws.amazon.com/AWSJavaSDK/latest/javadoc/com/amazonaws/services/s3/model/EncryptionMaterialsProvider.html)interface.
+ Para implementar a criptografia de disco local, use [com.amazonaws.services.elasticmapreduce.spi.security. EncryptionMaterialsProvider ](https://docs.aws.amazon.com/AWSJavaSDK/latest/javadoc/com/amazonaws/services/elasticmapreduce/spi/security/EncryptionMaterialsProvider.html)interface.
Você pode usar qualquer estratégia para fornecer materiais de criptografia para a implementação. Por exemplo, você pode optar por fornecer materiais de criptografia estáticos ou fazer uma integração com um sistema de gerenciamento de chaves mais complexo.
Se você estiver usando a criptografia do Amazon S3, deverá usar os algoritmos de criptografia **AES/GCM/NoPadding**para materiais de criptografia personalizados.
Se estiver usando criptografia de disco local, o algoritmo de criptografia a ser utilizado para materiais de criptografia personalizados varia de acordo com a versão do EMR. Para o Amazon EMR 7.0.0 e versões anteriores, você deve usar. **AES/GCM/NoPadding** No Amazon EMR 7.1.0 e versões posteriores, você deve usar **AES**.
A EncryptionMaterialsProvider classe obtém materiais de criptografia por contexto de criptografia. O Amazon EMR popula informações de contexto de criptografia em runtime para ajudar o chamador a determinar os materiais de criptografia corretos a serem retornados.
**Example Exemplo: usar um provedor de chaves personalizado para a criptografia do Amazon S3 com o EMRFS**
Quando o Amazon EMR busca os materiais de criptografia da EncryptionMaterialsProvider classe para realizar a criptografia, o EMRFS opcionalmente preenche o argumento MaterialsDescription com dois campos: o URI do Amazon S3 para o objeto JobFlowId e o do cluster, que pode ser usado pela classe para retornar materiais de criptografia seletivamente. EncryptionMaterialsProvider
Por exemplo, o provedor pode retornar diferentes chaves para diferentes prefixos de URI do Amazon S3. É a descrição dos materiais de criptografia retornados que acaba sendo armazenada com o objeto do Amazon S3 no lugar do valor de materialsDescription que é gerado pelo EMRFS e transmitido ao provedor. Ao descriptografar um objeto do Amazon S3, a descrição do material de criptografia é passada para a EncryptionMaterialsProvider classe, para que ela possa, novamente, retornar seletivamente a chave correspondente para descriptografar o objeto.
Uma implementação de EncryptionMaterialsProvider referência é fornecida abaixo. Outro provedor personalizado, [EMRFSRSAEncryptionMaterialsProvider](https://github.com/awslabs/emr-sample-apps/tree/master/emrfs-plugins/EMRFSRSAEncryptionMaterialsProvider), está disponível em 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;
}
}
```
## Fornecer certificados para criptografia de dados em trânsito com a criptografia do Amazon EMR
Com a versão 4.8.0 ou posteriores do Amazon EMR, há duas opções para especificar artefatos para a criptografia de dados em trânsito usando uma configuração de segurança:
+ É possível criar certificados PEM manualmente, incluí-los em um arquivo .zip e referenciar o arquivo .zip no Amazon S3.
+ É possível implementar um provedor de certificados personalizado como uma classe Java. Especifique o arquivo JAR da aplicação no Amazon S3 e depois forneça o nome completo da classe desse provedor, conforme declarado na aplicação. A classe deve implementar a interface [TLSArtifactsProvider](https://docs.aws.amazon.com/AWSJavaSDK/latest/javadoc/com/amazonaws/services/elasticmapreduce/spi/security/TLSArtifactsProvider.html) disponível a partir da AWS SDK para Java versão 1.11.0.
O Amazon EMR baixa os artefatos automaticamente em cada nó do cluster e depois os utiliza para implementar os recursos de criptografia em trânsito de código aberto. Para obter mais informações sobre as opções disponíveis, consulte [Criptografia em trânsito](emr-data-encryption-options.md#emr-encryption-intransit).
### Usar certificados PEM
Quando você especifica um arquivo de .zip para criptografia em trânsito, a configuração de segurança espera que os arquivos PEM dentro do arquivo .zip tenham exatamente os nomes indicados abaixo:
**Certificados de criptografia em trânsito**
| Nome do arquivo | Obrigatório/opcional | Detalhes |
| --- | --- | --- |
| privateKey.pem | Obrigatório | Chave privada |
| certificateChain.pem | Obrigatório | Cadeia de certificados |
| trustedCertificates.pem | Opcional | Recomendamos que você forneça um certificado que não seja assinado pela autoridade de certificação (CA) raiz confiável padrão Java ou por uma CA intermediária que possa vincular-se à CA raiz confiável padrão Java. Não recomendamos que você use public CAs ao usar certificados curinga ou ao desativar a verificação do nome do host. |
Você provavelmente deseja configurar o arquivo PEM de chave particular para ser um certificado curinga que permite o acesso ao domínio da Amazon VPC no qual as suas instâncias de cluster residem. Por exemplo, se o seu cluster reside em us-east-1 (Norte da Virgínia), você pode optar por especificar um nome comum na configuração do certificado que permita o acesso ao cluster, especificando `CN=*.ec2.internal` na definição de requerente do certificado. Se o seu cluster residir em us-west-2 (Oregon), poderá especificar `CN=*.us-west-2.compute.internal`.
Se o arquivo PEM fornecido no artefato de criptografia não tiver um caractere curinga para o domínio no nome comum, você deverá alterar o valor de para. `hadoop.ssl.hostname.verifier` `ALLOW_ALL` Para fazer isso nas versões 7.3.0 e superiores do Amazon EMR, adicione a classificação `core-site` ao enviar configurações para um cluster. Nas versões anteriores à 7.3.0, adicione a configuração `"hadoop.ssl.hostname.verifier": "ALLOW_ALL"` diretamente ao arquivo `core-site.xml`. Essa alteração é necessária porque o verificador do nome de host padrão exige um nome de host sem curinga, pois todos os hosts do cluster o usam. Para obter mais informações sobre a configuração do cluster do EMR em uma Amazon VPC, consulte [Configuração de redes em uma VPC no Amazon EMR](emr-plan-vpc-subnet.md).
O exemplo a seguir demonstra como usar [OpenSSL](https://www.openssl.org/) para gerar um certificado X.509 autoassinado com uma chave privada RSA de 2.048 bits. A chave permite o acesso às instâncias de cluster do Amazon EMR do emissor na região `us-west-2` (Oregon) conforme especificado pelo nome de domínio `*.us-west-2.compute.internal` como o nome comum.
Outros itens de requerente opcionais como país (C), estado (S) e Localidade (L) são especificados. Como um certificado autoassinado é gerado, o segundo comando no exemplo copia o arquivo `certificateChain.pem` no arquivo `trustedCertificates.pem`. O terceiro comando usa `zip` para criar o arquivo `my-certs.zip` que contém os certificados.
**Importante**
Este exemplo é apenas uma proof-of-concept demonstração. O uso de certificados autoassinados não é recomendado e apresenta um possível risco de segurança. Para sistemas de produção, use uma autoridade de certificação (AC) confiável 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
```
# Noções básicas da criptografia em trânsito
Você pode configurar um cluster do EMR para executar estruturas de código aberto, como [Apache Spark](https://aws.amazon.com/emr/features/spark/), [Apache Hive](https://aws.amazon.com/emr/features/hive/) e [Presto](https://aws.amazon.com/emr/features/presto/). Cada uma dessas estruturas de código aberto tem um conjunto de processos em execução nas instâncias do EC2 de um cluster. Cada um desses processos pode hospedar endpoints de rede para comunicação de rede.
Se a criptografia em trânsito estiver habilitada em um cluster do EMR, diferentes endpoints de rede usarão mecanismos de criptografia distintos. Consulte as seções a seguir para saber mais sobre os endpoints de rede específicos da estrutura de código aberto compatíveis com criptografia em trânsito, os mecanismos de criptografia relacionados e qual versão do Amazon EMR adicionou suporte. Cada aplicação de código aberto também pode ter diferentes práticas recomendadas e configurações da estrutura de código aberto que você pode alterar.
Para obter a maior cobertura de criptografia em trânsito, recomendamos que você habilite a criptografia em trânsito e o Kerberos. Se você habilitar somente a criptografia em trânsito, ela estará disponível somente para os endpoints de rede compatíveis com TLS. O Kerberos é necessário porque alguns endpoints de rede da estrutura de código aberto usam Simple Authentication and Security Layer (SASL) para criptografia em trânsito.
Observe que qualquer estrutura de código aberto sem suporte nas versões 7.x.x do Amazon EMR não está incluída.
## Spark
Ao habilitar a criptografia em trânsito nas configurações de segurança, `spark.authenticate` é automaticamente definido para `true` e usa a criptografia baseada em AES para conexões RPC.
A partir do Amazon EMR 7.3.0, se você usar criptografia em trânsito e autenticação do Kerberos, não poderá usar aplicações Spark que dependam do Hive Metastore. O Hive 3 corrige esse problema no [HIVE-16340](https://issues.apache.org/jira/browse/HIVE-16340). O [HIVE-44114](https://issues.apache.org/jira/browse/SPARK-44114) resolve totalmente esse problema quando o Spark de código aberto pode ser atualizado para o Hive 3. Enquanto isso, você pode definir `hive.metastore.use.SSL` para `false` e contornar esse problema. Para obter mais informações, consulte [Configure applications](https://docs.aws.amazon.com/emr/latest/ReleaseGuide/emr-configure-apps.html).
Para obter mais informações, consulte [Spark security](https://spark.apache.org/docs/latest/security) da documentação do Apache Spark.
| Componente | Endpoint | Porta | Mecanismo de criptografia em trânsito | Com suporte da versão |
| --- | --- | --- | --- | --- |
| Servidor de histórico do Spark | spark.ssl.history.port | 18480 | TLS | emr-5.3.0\$1, emr-6.0.0\$1, emr-7.0.0\$1 |
| Interface do usuário do Spark | spark.ui.port | 4440 | TLS | emr-5.3.0\$1, emr-6.0.0\$1, emr-7.0.0\$1 |
| Driver do Spark | spark.driver.port | Dinâmico | Criptografia baseada em AES do Spark | emr-4.8.0\$1, emr-5.0.0\$1, emr-6.0.0\$1, emr-7.0.0\$1 |
| Executor do Spark | Porta do executor (sem configuração nomeada) | Dinâmico | Criptografia baseada em AES do Spark | emr-4.8.0\$1, emr-5.0.0\$1, emr-6.0.0\$1, emr-7.0.0\$1 |
| FIO NodeManager | spark.shuffle.service.port1 | 7337 | Criptografia baseada em AES do 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á hospedado no YARN NodeManager , mas é usado somente pelo Apache Spark.
**Problema conhecido**
Em clusters habilitados em trânsito, a configuração `spark.yarn.historyServer.address` atualmente usa a porta `18080`, que impede o acesso à interface do usuário da aplicação Spark usando o URL de rastreamento do YARN. **Versão afetada:** EMR - 7.3.0 a EMR - 7.9.0.
Use a seguinte solução alternativa:
1. Modifique a configuração `spark.yarn.historyServer.address` em `/etc/spark/conf/spark-defaults.conf` para usar o número da porta `HTTPS` `18480` em um cluster em execução.
1. Isso também pode ser fornecido em substituições de configuração durante a inicialização do cluster.
Exemplo de configuração:
```
[
{
"Classification": "spark-defaults",
"Properties": {
"spark.yarn.historyServer.address": "${hadoopconf-yarn.resourcemanager.hostname}:18480"
}
}
]
```
## YARN do Hadoop
O [Secure Hadoop RPC](https://hadoop.apache.org/docs/r2.7.2/hadoop-project-dist/hadoop-common/SecureMode.html#Data_Encryption_on_RPC) está configurado para `privacy` e usa criptografia em trânsito baseada em SASL. Isso requer que a autenticação do Kerberos esteja habilitada na configuração de segurança. Se você não quiser criptografia em trânsito para o Hadoop RPC, configure `hadoop.rpc.protection = authentication`. Recomendamos usar a configuração padrão para obter a segurança máxima.
Se os certificados TLS não atenderem aos requisitos de verificação do nome de host TLS, você poderá configurar `hadoop.ssl.hostname.verifier = ALLOW_ALL`. Recomendamos que você use a configuração padrão de `hadoop.ssl.hostname.verifier = DEFAULT`, que impõe a verificação do nome de host TLS.
Para desabilitar o HTTPS nos endpoints da aplicação Web do YARN, configure `yarn.http.policy = HTTP_ONLY`. Isso faz com que o tráfego para esses endpoints permaneça sem criptografia. Recomendamos usar a configuração padrão para obter a segurança máxima.
Para obter mais informações, consulte [Hadoop in secure mode](https://hadoop.apache.org/docs/r2.7.2/hadoop-project-dist/hadoop-common/SecureMode.html), na documentação do Apache Hadoop.
| Componente | Endpoint | Porta | Mecanismo de criptografia em trânsito | Com suporte da versão |
| --- | --- | --- | --- | --- |
| 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 | 2088 | 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 | Criptografia baseada em AES do 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á hospedado no YARN NodeManager , mas é usado somente pelo MapReduce Hadoop.
2 `spark.shuffle.service.port` está hospedado no YARN NodeManager , mas é usado apenas pelo Apache Spark.
**Problema conhecido**
Atualmente, a configuração `yarn.log.server.url` em está usando HTTP com a porta 19888, o que impede o acesso aos logs da aplicação a partir da interface do usuário do Resource Manager. **Versão afetada:** EMR - 7.3.0 a EMR - 7.8.0.
Use a seguinte solução alternativa:
1. Modifique a configuração `yarn.log.server.url` em `yarn-site.xml` para usar o protocolo `HTTPS` e o número da porta `19890`.
1. Reinicie o YARN Resource Manager: `sudo systemctl restart hadoop-yarn-resourcemanager.service`.
## HDFS do Hadoop
O nó de nome, o nó de dados e o nó de diário do Hadoop oferecem suporte a TLS por padrão se a criptografia em trânsito estiver habilitada nos clusters do EMR.
O [Secure Hadoop RPC](https://hadoop.apache.org/docs/r2.7.2/hadoop-project-dist/hadoop-common/SecureMode.html#Data_Encryption_on_RPC) está configurado para `privacy` e usa criptografia em trânsito baseada em SASL. Isso requer que a autenticação do Kerberos esteja habilitada na configuração de segurança.
Recomendamos não alterar as portas padrão usadas em endpoints HTTPS.
A [criptografia de dados na transferência de blocos HDFS](https://hadoop.apache.org/docs/r2.7.2/hadoop-project-dist/hadoop-common/SecureMode.html#Data_Encryption_on_Block_data_transfer.) usa AES 256 e requer que a criptografia em repouso esteja habilitada na configuração de segurança.
Para obter mais informações, consulte [Hadoop in secure mode](https://hadoop.apache.org/docs/r2.7.2/hadoop-project-dist/hadoop-common/SecureMode.html), na documentação do Apache Hadoop.
| Componente | Endpoint | Porta | Mecanismo de criptografia em trânsito | Com suporte da versão |
| --- | --- | --- | --- | --- |
| 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 | 986 | SASL \$1 Kerberos | emr-4.8.0\$1, emr-5.0.0\$1, emr-6.0.0\$1, emr-7.0.0\$1 |
| Nó de diário | 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 |
| Nó de diário | 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 | Nenhum | O TLS para ZKFC só é compatível com o Hadoop 3.4.0. Para obter mais informações, consulte [HADOOP-18919](https://issues.apache.org/jira/browse/HADOOP-18919). A versão 7.1.0 do Amazon EMR está atualmente no Hadoop 3.3.6. Versões superiores do Amazon EMR estarão no Hadoop 3.4.0 |
## Hadoop MapReduce
O Hadoop MapReduce, o servidor de histórico de tarefas e o MapReduce shuffle oferecem suporte a TLS por padrão quando a criptografia em trânsito está habilitada nos clusters do EMR.
O [shuffle MapReduce criptografado do Hadoop](https://hadoop.apache.org/docs/r2.7.1/hadoop-mapreduce-client/hadoop-mapreduce-client-core/EncryptedShuffle.html) usa TLS.
Recomendamos que você não altere as portas padrão para endpoints HTTPS.
Para obter mais informações, consulte [Hadoop in secure mode](https://hadoop.apache.org/docs/r2.7.2/hadoop-project-dist/hadoop-common/SecureMode.html), na documentação do Apache Hadoop.
| Componente | Endpoint | Porta | Mecanismo de criptografia em trânsito | Com suporte da versão |
| --- | --- | --- | --- | --- |
| JobHistoryServer | mapreduce.jobhistory.webapp.https.address | 1980 a 90 | TLS | emr-7.3.0\$1 |
| FIO 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á hospedado no YARN NodeManager , mas é usado somente pelo MapReduce Hadoop.
## Presto
Nas versões 5.6.0 e superiores do Amazon EMR, a comunicação interna entre o coordenador do Presto e os trabalhadores usa TLS. O Amazon EMR define todas as configurações necessárias para permitir a [comunicação interna segura](https://prestodb.io/docs/current/security/internal-communication.html) no Presto.
Se o conector usar o metastore do Hive como armazenamento de metadados, a comunicação entre o comunicador e o metastore do Hive também será criptografada com TLS.
| Componente | Endpoint | Porta | Mecanismo de criptografia em trânsito | Com suporte da versão |
| --- | --- | --- | --- | --- |
| Coordenador do Presto | http-server.https.port | 846 | TLS | emr-5.6.0\$1, emr-6.0.0\$1, emr-7.0.0\$1 |
| Trabalhador do Presto | http-server.https.port | 846 | TLS | emr-5.6.0\$1, emr-6.0.0\$1, emr-7.0.0\$1 |
## Trino
Nas versões 6.1.0 e posteriores do Amazon EMR, a comunicação interna entre o coordenador do Presto e os trabalhadores usa TLS. O Amazon EMR define todas as configurações necessárias para permitir a [comunicação interna segura](https://trino.io/docs/current/security/internal-communication.html) no Trino.
Se o conector usar o metastore do Hive como armazenamento de metadados, a comunicação entre o comunicador e o metastore do Hive também será criptografada com TLS.
| Componente | Endpoint | Porta | Mecanismo de criptografia em trânsito | Com suporte da versão |
| --- | --- | --- | --- | --- |
| Trino Coordinator | http-server.https.port | 846 | TLS | emr-6.1.0\$1, emr-7.0.0\$1 |
| Trino Worker | http-server.https.port | 846 | TLS | emr-6.1.0\$1, emr-7.0.0\$1 |
## Hive e Tez
Por padrão, o servidor Hive 2, o servidor Hive Metastore, a interface de usuário da Web do daemon do LLAP do Hive e o shuffle do LLAP do Hive oferecem suporte ao TLS quando a criptografia em trânsito está habilitada nos clusters do EMR. Para obter mais informações sobre as configurações do Hive, consulte [Configuration properties](https://cwiki.apache.org/confluence/display/Hive/Configuration+Properties).
A interface de usuário do Tez hospedada no servidor Tomcat também é habilitada para HTTPS quando a criptografia em trânsito está ativada no cluster do EMR. No entanto, o HTTPS está desabilitado para o serviço de interface do usuário da Web do Tez AM, portanto, os usuários do AM não têm acesso ao arquivo de keystore do receptor de SSL de abertura. Você também pode habilitar esse comportamento com as configurações booleanas `tez.am.tez-ui.webservice.enable.ssl` e `tez.am.tez-ui.webservice.enable.client.auth`.
| Componente | Endpoint | Porta | Mecanismo de criptografia em trânsito | Com suporte da versão |
| --- | --- | --- | --- | --- |
| 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 |
| Daemon do LLAP | hive.llap.daemon.yarn.shuffle.port | 1551 | TLS | emr-7.3.0\$1 |
| Daemon do LLAP | hive.llap.daemon.web.port | 15002 | TLS | emr-7.3.0\$1 |
| Daemon do LLAP | hive.llap.daemon.output.service.port | 15003 | Nenhum | O Hive não oferece suporte à criptografia em trânsito para esse endpoint |
| Daemon do LLAP | hive.llap.management.rpc.port | 15004 | Nenhum | O Hive não oferece suporte à criptografia em trânsito para esse endpoint |
| Daemon do LLAP | hive.llap.plugin.rpc.port | Dinâmico | Nenhum | O Hive não oferece suporte à criptografia em trânsito para esse endpoint |
| Daemon do LLAP | hive.llap.daemon.rpc.port | Dinâmico | Nenhum | O Hive não oferece suporte à criptografia em trânsito para esse endpoint |
| Web HCat | templeton.port | 50111 | TLS | emr-7.3.0\$1 |
| Tez Application Master | tez.am.client.am.port-range tez.am.task.am.port-range | Dinâmico | Nenhum | O Tez não oferece suporte à criptografia em trânsito para esse endpoint |
| Tez Application Master | tez.am.tez-ui.webservice.port-range | Dinâmico | Nenhum | Desabilitado por padrão. Pode ser habilitado usando as configurações do Tez no emr-7.3.0\$1 |
| Tarefa do Tez | N/D: não configurável | Dinâmico | Nenhum | O Tez não oferece suporte à criptografia em trânsito para esse endpoint |
| IU Tez | Configurável por meio do servidor Tomcat no qual a interface de usuário do Tez está hospedada | 8080 | TLS | emr-7.3.0\$1 |
## Flink
Os endpoints REST do Apache Flink e a comunicação interna entre os processos do Flink oferecem suporte ao TLS por padrão quando você habilita a criptografia em trânsito nos clusters do 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á definido como `true` e usa criptografia em trânsito para comunicação interna entre os processos do Flink. Se você não quiser criptografia em trânsito para comunicação interna, desabilite essa configuração. Recomendamos usar a configuração padrão para obter segurança máxima.
O Amazon EMR define [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) como `true` e usa criptografia em trânsito para os endpoints REST. Além disso, o Amazon EMR define [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) como verdadeiro para usar a comunicação TLS com o servidor de histórico do Flink. Se você não quiser criptografia em trânsito para os pontos REST, desabilite essas configurações. Recomendamos usar a configuração padrão para obter segurança máxima.
O Amazon EMR usa [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 a lista de cifras que usam criptografia baseada em AES. Substitua essa configuração para usar as cifras desejadas.
Para obter mais informações, consulte [SSL Setup](https://nightlies.apache.org/flink/flink-docs-release-1.18/docs/deployment/security/security-ssl/) na documentação do Flink.
| Componente | Endpoint | Porta | Mecanismo de criptografia em trânsito | Com suporte da versão |
| --- | --- | --- | --- | --- |
| Servidor de histórico do Flink | historyserver.web.port | 8082 | TLS | emr-7.3.0\$1 |
| Servidor REST do gerenciador de trabalhos | rest.bind-port rest.port | Dinâmico | TLS | emr-7.3.0\$1 |
## HBase
O Amazon EMR define o [Secure Hadoop](https://hadoop.apache.org/docs/r2.7.2/hadoop-project-dist/hadoop-common/SecureMode.html#Data_Encryption_on_RPC) RPC como. `privacy` HMaster e RegionServer use criptografia em trânsito baseada em SASL. Isso requer que a autenticação do Kerberos esteja habilitada na configuração de segurança.
O Amazon EMR define `hbase.ssl.enabled` como verdadeiro e usa TLS para endpoints de interface do usuário. Se não quiser usar o TLS para endpoints da interface do usuário, desabilite essa configuração. Recomendamos usar a configuração padrão para obter a segurança máxima.
O Amazon EMR define `hbase.rest.ssl.enabled` e `hbase.thrift.ssl.enabled` e usa TLS para os endpoints do servidor REST e Thrift, respectivamente. Se não quiser usar o TLS para esses endpoints, desabilite essa configuração. Recomendamos usar a configuração padrão para obter a segurança máxima.
A partir do EMR 7.6.0, o TLS é suportado em endpoints. HMaster RegionServer O Amazon EMR também define `hbase.server.netty.tls.enabled` e `hbase.client.netty.tls.enabled`. Se não quiser usar o TLS para esses endpoints, desabilite essa configuração. Recomendamos usar a configuração padrão, que fornece criptografia e, portanto, maior segurança. Para saber mais, consulte [Transport Level Security (TLS) na comunicação HBase RPC](https://hbase.apache.org/book.html#_transport_level_security_tls_in_hbase_rpc_communication) no Guia de Referência do *Apache HBase *.
| Componente | Endpoint | Porta | Mecanismo de criptografia em trânsito | Com suporte da versão |
| --- | --- | --- | --- | --- |
| HMaster | HMaster | 16000 | SASL \$1 Kerberos TLS | SASL \$1 Kerberos in emr-4.8.0\$1, emr-5.0.0\$1, emr-6.0.0\$1 e emr-7.0.0\$1 TLS no emr-7.6.0\$1 |
| HMaster | HMaster UI | 16010 | TLS | emr-7.3.0\$1 |
| RegionServer | RegionServer | 16020 | SASL \$1 Kerberos TLS | SASL \$1 Kerberos in emr-4.8.0\$1, emr-5.0.0\$1, emr-6.0.0\$1 e emr-7.0.0\$1 TLS no emr-7.6.0\$1 |
| RegionServer | RegionServer Informações | 16030 | TLS | emr-7.3.0\$1 |
| HBase Servidor Rest | Servidor REST | 8070 | TLS | emr-7.3.0\$1 |
| HBase Servidor Rest | Interface do usuário REST | 8085 | TLS | emr-7.3.0\$1 |
| Servidor Thrift do Hbase | Servidor Thrift | 9090 | TLS | emr-7.3.0\$1 |
| Servidor Thrift do Hbase | Interface do usuário do servidor Thrift | 9095 | TLS | emr-7.3.0\$1 |
## Phoenix
Se você habilitou a criptografia em trânsito no cluster do EMR, o Phoenix Query Server será compatível com a propriedade `phoenix.queryserver.tls.enabled` do TLS, que é definida como `true` por padrão.
Para saber mais, consulte [Configurations relating to HTTPS](https://phoenix.apache.org/server.html#Configuration) na documentação do Phoenix Query Server.
| Componente | Endpoint | Porta | Mecanismo de criptografia em trânsito | Com suporte da versão |
| --- | --- | --- | --- | --- |
| Query Server | phoenix.queryserver.http.port | 8765 | TLS | emr-7.3.0\$1 |
## Oozie
O [OOZIE-3673](https://issues.apache.org/jira/browse/OOZIE-3673) está disponível no Amazon EMR ao executar o Oozie no Amazon EMR 7.3.0 e superior. Se precisar configurar protocolos SSL ou TLS personalizados ao executar uma ação de e-mail, você pode definir a propriedade `oozie.email.smtp.ssl.protocols` no arquivo `oozie-site.xml`. Por padrão, se você habilitou a criptografia em trânsito, o Amazon EMR usa o protocolo TLS v1.3.
O [OOZIE-3677](https://issues.apache.org/jira/browse/OOZIE-3677) e o [OOZIE-3674](https://issues.apache.org/jira/browse/OOZIE-3674) também estão disponíveis no Amazon EMR se você executar o Oozie no Amazon EMR 7.3.0 e superior. Isso permite especificar as propriedades `keyStoreType` e `trustStoreType` em `oozie-site.xml`. O OOZIE-3674 adiciona o parâmetro `--insecure` ao cliente Oozie para que ele possa ignorar os erros do certificado.
O Oozie impõe a verificação do nome de host TLS, o que significa que qualquer certificado usado para criptografia em trânsito deve atender aos requisitos de verificação do nome de host. Se o certificado não atender aos critérios, o cluster pode ficar preso no estágio `oozie share lib update` quando o Amazon EMR provisiona o cluster. Recomendamos que você atualize seus certificados para garantir que eles estejam em conformidade com a verificação do nome de host. No entanto, se você não conseguir atualizar os certificados, poderá desabilitar o SSL para o Oozie definindo a propriedade `oozie.https.enabled` como `false` na configuração do cluster.
| Componente | Endpoint | Porta | Mecanismo de criptografia em trânsito | Com suporte da versão |
| --- | --- | --- | --- | --- |
| EmbeddedOozieServer | oozie.https.port | 11443 | TLS | emr-7.3.0\$1 |
| EmbeddedOozieServer | oozie.email.smtp.port | 25 | TLS | emr-7.3.0\$1 |
## Hue
Por padrão, o Hue oferece suporte a TLS quando a criptografia em trânsito está habilitada nos clusters do Amazon EMR. Para obter mais informações sobre as configurações do Hue, consulte [Configurar o Hue com HTTPS/SSL](https://gethue.com/configure-hue-with-https-ssl/).
| Componente | Endpoint | Porta | Mecanismo de criptografia em trânsito | Com suporte da versão |
| --- | --- | --- | --- | --- |
| Hue | http\$1port | 888 | TLS | emr-7.4.0\$1 |
## Livy
Por padrão, o Livy oferece suporte a TLS quando a criptografia em trânsito está habilitada nos clusters do Amazon EMR. Para obter mais informações sobre as configurações do Livy, consulte [Habilitar o HTTPS com o Apache Livy](https://docs.aws.amazon.com/emr/latest/ReleaseGuide/enabling-https.html).
A partir do Amazon EMR 7.3.0, se você usar criptografia em trânsito e autenticação do Kerberos, não poderá usar o servidor Livy para aplicações Spark que dependem do metastore Hive. Esse problema foi corrigido no [HIVE-16340](https://issues.apache.org/jira/browse/HIVE-16340) e será totalmente resolvido no [SPARK-44114](https://issues.apache.org/jira/browse/SPARK-44114) quando a aplicação Spark de código aberto puder ser atualizada para o Hive 3. Enquanto isso, você pode contornar esse problema definindo `hive.metastore.use.SSL` como `false`. Para obter mais informações, consulte [Configure applications](https://docs.aws.amazon.com/emr/latest/ReleaseGuide/emr-configure-apps.html).
Para obter mais informações, consulte [como habilitar o HTTPS com o Apache Livy](https://docs.aws.amazon.com/emr/latest/ReleaseGuide/enabling-https.html).
| Componente | Endpoint | Porta | Mecanismo de criptografia em trânsito | Com suporte da versão |
| --- | --- | --- | --- | --- |
| livy-server | livy.server.port | 8998 | TLS | emr-7.4.0\$1 |
## JupyterEnterpriseGateway
Por padrão, o Jupyter Enterprise Gateway oferece suporte a TLS quando a criptografia em trânsito está habilitada nos clusters do Amazon EMR. Para obter mais informações sobre as configurações do Jupyter Enterprise Gateway, consulte [Proteção do Enterprise Gateway Server](https://jupyter-enterprise-gateway.readthedocs.io/en/v1.2.0/getting-started-security.html#securing-enterprise-gateway-server).
| Componente | Endpoint | Porta | Mecanismo de criptografia em trânsito | Com suporte da versão |
| --- | --- | --- | --- | --- |
| jupyter\$1enterprise\$1gateway | c. EnterpriseGatewayApp porta | 9547 | TLS | emr-7.4.0\$1 |
## JupyterHub
Por padrão, é JupyterHub compatível com TLS quando a criptografia em trânsito está habilitada nos clusters do Amazon EMR. Para obter mais informações, consulte [Habilitar a criptografia SSL](https://jupyterhub.readthedocs.io/en/latest/tutorial/getting-started/security-basics.html#enabling-ssl-encryption) na JupyterHub documentação. Não é recomendável desabilitar a criptografia.
| Componente | Endpoint | Porta | Mecanismo de criptografia em trânsito | Com suporte da versão |
| --- | --- | --- | --- | --- |
| jupyter\$1hub | c. JupyterHub porta | 9443 | TLS | emr-5.14.0\$1, emr-6.0.0\$1, emr-7.0.0\$1 |
## Zeppelin
Por padrão, o Zeppelin é compatível com TLS ao habilitar a criptografia em trânsito no cluster do EMR. Para obter mais informações sobre as configurações do Zeppelin, consulte [ SSL Configuration](https://zeppelin.apache.org/docs/0.11.1/setup/operation/configuration.html#ssl-configuration) na documentação do Zeppelin.
| Componente | Endpoint | Porta | Mecanismo de criptografia em trânsito | Com suporte da versão |
| --- | --- | --- | --- | --- |
| zeppelin | zeppelin.server.ssl.port | 8890 | TLS | 7.3.0\$1 |
## Zookeeper
O Amazon EMR define `serverCnxnFactory` como `org.apache.zookeeper.server.NettyServerCnxnFactory` para habilitar o TLS para o quorum do Zookeeper e a comunicação com o cliente.
`secureClientPort` especifica a porta que escuta as conexões TLS. Se o cliente não oferecer suporte para conexões TLS com o Zookeeper, os clientes poderão se conectar à porta não segura 2181 especificada em `clientPort`. Você pode substituir ou desabilitar essas duas portas.
O Amazon EMR define `sslQuorum` e `admin.forceHttps` como `true` para habilitar a comunicação TLS para o quórum e o servidor administrativo. Se não quiser criptografia em trânsito para o quórum e o servidor de administração, você pode desabilitar essas configurações. Recomendamos usar as configurações padrão para obter a segurança máxima.
Para obter mais informações, consulte [Opções de criptografia, autenticação e autorização](https://zookeeper.apache.org/doc/r3.9.2/zookeeperAdmin.html#sc_authOptions), na documentação do Zookeeper.
| Componente | Endpoint | Porta | Mecanismo de criptografia em trânsito | Com suporte da versão |
| --- | --- | --- | --- | --- |
| Zookeeper Server | secureClientPort | 2281 | TLS | emr-7.4.0\$1 |
| Zookeeper Server | Portas de quórum | Existem 2: Os seguidores usam 2888 para se conectar ao líder. A eleição do líder usa 3888 | TLS | emr-7.4.0\$1 |
| Zookeeper Server | admin.serverPort | 8341 | TLS | emr-7.4.0\$1 |