Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.
# Crittografa i dati inattivi e in transito con Amazon EMR
La crittografia dei dati consente di impedire agli utenti non autorizzati di leggere dati su un cluster e sui sistemi di archiviazione di dati associati. Sono inclusi i dati salvati su supporti persistenti, noti come dati *inattivi*, e i dati che possono essere intercettati quando circolano in rete, noti come dati *in transito*.
A partire dalla versione Amazon EMR 4.8.0, puoi utilizzare le configurazioni di sicurezza di Amazon EMR per configurare più facilmente impostazioni di crittografia di dati per cluster. Le configurazioni di sicurezza offrono impostazioni che assicurano la sicurezza dei dati in transito e a riposo nei volumi di Amazon Elastic Block Store (Amazon EBS) e in EMRFS su Amazon S3.
Facoltativamente, a partire da Amazon EMR versione 4.1.0 e successive, puoi scegliere di configurare la crittografia trasparente in HDFS, che non è configurata utilizzando le configurazioni di sicurezza. Per ulteriori informazioni, consulta [Crittografia trasparente in HDFS su Amazon EMR](https://docs.aws.amazon.com/emr/latest/ReleaseGuide/emr-encryption-tdehdfs.html) nella *Guida ai rilasci di Amazon EMR*.
**Topics**
+ [Opzioni di crittografia per Amazon EMR](emr-data-encryption-options.md)
+ [Crittografia inattiva utilizzando una chiave KMS del cliente per il servizio EMR WAL](encryption-at-rest-kms.md)
+ [Crea chiavi e certificati per la crittografia dei dati con Amazon EMR](emr-encryption-enable.md)
+ [Comprendere la crittografia in transito](emr-encryption-support-matrix.md)
# Opzioni di crittografia per Amazon EMR
Con le versioni 4.8.0 e successive di Amazon EMR, puoi utilizzare una configurazione di sicurezza per specificare le impostazioni per crittografare i dati inattivi, i dati in transito o entrambi. Quando abiliti la crittografia dei dati a riposo, puoi scegliere di crittografare i dati EMRFS in Amazon S3, i dati in dischi locali o entrambi. Ogni configurazione di sicurezza creata viene archiviata in Amazon EMR anziché nella configurazione del cluster. Di conseguenza, puoi facilmente riutilizzare una configurazione per specificare impostazioni di crittografia dei dati ogni volta che crei un cluster. Per ulteriori informazioni, consulta [Crea una configurazione di sicurezza con la console Amazon EMR o con AWS CLI](emr-create-security-configuration.md).
Il diagramma seguente mostra le differenti opzioni di crittografia dei dati disponibili con le configurazioni di sicurezza.
![\[Con Amazon EMR sono disponibili diverse opzioni di crittografia in transito e a riposo.\]](http://docs.aws.amazon.com/it_it/emr/latest/ManagementGuide/images/emr-encryption-options.png)
Anche le seguenti opzioni di crittografia sono disponibili e non sono configurate utilizzando una configurazione di sicurezza:
+ Facoltativamente, con Amazon EMR versione 4.1.0 e versioni successive, puoi scegliere di configurare la crittografia trasparente in HDFS. Per ulteriori informazioni, consulta [Crittografia trasparente in HDFS su Amazon EMR](https://docs.aws.amazon.com/emr/latest/ReleaseGuide/emr-encryption-tdehdfs.html) nella *Guida ai rilasci di Amazon EMR*.
+ Se utilizzi una versione di Amazon EMR che non supporta configurazioni di sicurezza, puoi configurare manualmente la crittografia per i dati EMRFS in Amazon S3. Per ulteriori informazioni, consulta [Specifica della crittografia Amazon S3 utilizzando le proprietà EMRFS](https://docs.aws.amazon.com/emr/latest/ReleaseGuide/emr-emrfs-encryption.html).
+ Se utilizzi una versione Amazon EMR precedente alla 5.24.0, un volume del dispositivo di root EBS crittografato è supportato solo quando utilizzi un'AMI personalizzata. Per ulteriori informazioni, consulta la sezione [Creazione di un'AMI personalizzata con un volume del dispositivo di root Amazon EBS crittografato](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-custom-ami.html#emr-custom-ami-encrypted) nella *Guida alla gestione di Amazon EMR*.
**Nota**
A partire dalla versione 5.24.0 di Amazon EMR, puoi utilizzare un'opzione di configurazione di sicurezza per crittografare il dispositivo root e i volumi di storage EBS quando lo specifichi come provider di chiavi. AWS KMS Per ulteriori informazioni, consulta [Crittografia del disco locale](#emr-encryption-localdisk).
La crittografia dei dati richiede chiavi e certificati. Una configurazione di sicurezza ti offre la flessibilità di scegliere tra diverse opzioni, tra cui chiavi gestite da AWS Key Management Service, chiavi gestite da Amazon S3 e chiavi e certificati di provider personalizzati da te forniti. Quando lo utilizzi AWS KMS come fornitore di chiavi, vengono addebitati costi per l'archiviazione e l'uso delle chiavi di crittografia. Per ulteriori informazioni, consultare [Prezzi di AWS KMS](https://aws.amazon.com/kms/pricing/).
Prima di specificare le opzioni di crittografia, scegli i sistemi di gestione di chiavi e certificati che intendi utilizzare, in modo da cominciare a creare chiavi e certificati o i provider personalizzati che specifichi durante l'impostazione dei parametri di crittografia.
## Crittografia dei dati a riposo per dati EMRFS in Amazon S3
La crittografia Amazon S3 funziona con gli oggetti Amazon EMR File System (EMRFS) letti e scritti su Amazon S3. Puoi specificare la crittografia lato server (SSE) o la crittografia lato client (CSE) di Amazon S3 come **modalità di crittografia predefinita** quando abiliti la crittografia dei dati a riposo. Facoltativamente, è possibile specificare diversi metodi di crittografia per singoli bucket utilizzando **override di crittografia per bucket**. Indipendentemente dall'abilitazione o meno della crittografia di Amazon S3, il protocollo Transport Layer Security (TLS) esegue la crittografia degli oggetti EMRFS in transito tra i nodi cluster EMR e Amazon S3. Per ulteriori informazioni sulla crittografia di Amazon S3, consulta [Protezione dei dati mediante crittografia](https://docs.aws.amazon.com/AmazonS3/latest/userguide/UsingEncryption.html) nella Guida per l'*utente di Amazon Simple Storage Service*.
**Nota**
Quando si utilizza AWS KMS, vengono addebitati costi per l'archiviazione e l'uso delle chiavi di crittografia. Per ulteriori informazioni, consultare [AWS KMS Prezzi](https://aws.amazon.com/kms/pricing/).
### Crittografia lato server di Amazon S3
Tutti i bucket Amazon S3 hanno la crittografia configurata per impostazione predefinita e tutti i nuovi oggetti caricati su un bucket S3 vengono crittografati automaticamente a riposo. Amazon S3 crittografa i dati a livello di oggetto mentre scrive i dati su disco e decrittografa i dati quando vi si accede. Per ulteriori informazioni sulla SEE, consulta [Protezione dei dati con la crittografia lato server](https://docs.aws.amazon.com/AmazonS3/latest/userguide/serv-side-encryption.html) nella *Guida per l'utente di Amazon Simple Storage Service*.
Puoi scegliere tra due diversi sistemi di gestione delle chiavi quando specifichi la SSE in Amazon EMR:
+ **SSE-S3**: Amazon S3 gestisce le chiavi per te.
+ **SSE-KMS**: si utilizza una configurazione con politiche adatte AWS KMS key ad Amazon EMR. Per ulteriori informazioni sui requisiti chiave per Amazon EMR, consulta [Using AWS KMS keys for encryption](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-encryption-enable.html#emr-awskms-keys).
La SSE con chiavi fornite dal cliente (SSE-C) non è disponibile per l'utilizzo con Amazon EMR.
### File crittografato lato client Amazon S3
Con la crittografia lato client di Amazon S3, la crittografia e la decrittografia Amazon S3 avvengono nel client EMRFS nel tuo cluster. Gli oggetti vengono crittografati prima di essere caricati su Amazon S3 e decrittati dopo il loro download. Il provider specificato fornisce la chiave di crittografia utilizzata dal client. Il client può utilizzare le chiavi fornite da AWS KMS (CSE-KMS) o una classe Java personalizzata che fornisce la chiave principale lato client (CSE-C). Le specifiche di crittografia sono leggermente diverse tra CSE-KMS e CSE-C, a seconda del provider specificato e dei metadati dell'oggetto da decrittare o crittografare. Per ulteriori informazioni su queste differenze, consulta [Protezione dei dati tramite la crittografia lato client](https://docs.aws.amazon.com/AmazonS3/latest/userguide/UsingClientSideEncryption.html) nella *Guida per l'utente di Amazon Simple Storage Service*.
**Nota**
Amazon S3 CSE garantisce solo che i dati EMRFS scambiati con Amazon S3 siano crittografati; non tutti i dati sui volumi delle istanze del cluster sono crittografati. Inoltre, poiché Hue non utilizza EMRFS, gli oggetti che il browser di file Hue S3 scrive su Amazon S3 non vengono crittografati.
## Crittografia inattiva per i dati in Amazon EMR WAL
Quando configuri la crittografia lato server (SSE) per il write-ahead logging (WAL), Amazon EMR crittografa i dati inattivi. Puoi scegliere tra due diversi sistemi di gestione delle chiavi quando specifichi SSE in Amazon EMR:
**SSE-EMR-WAL**
Amazon EMR gestisce le chiavi per te. Per impostazione predefinita, Amazon EMR crittografa i dati archiviati in Amazon EMR WAL. SSE-EMR-WAL
**SSE-KMS-WAL**
Usa una AWS KMS chiave per configurare le politiche che si applicano a Amazon EMR WAL. Per ulteriori informazioni sulla configurazione della crittografia a riposo per EMR WAL utilizzando una chiave KMS del cliente, [vedere Crittografia a riposo utilizzando una chiave KMS del cliente per](https://docs.aws.amazon.com/emr/latest/ManagementGuide/encryption-at-rest-kms.html) il servizio EMR WAL.
**Nota**
Non puoi usare la tua chiave con SSE quando abiliti WAL con Amazon EMR. Per ulteriori informazioni, consulta [WRITE-ahead logs (WAL) per Amazon EMR](https://docs.aws.amazon.com/emr/latest/ReleaseGuide/emr-hbase-wal.html).
## Crittografia del disco locale
I seguenti meccanismi interagiscono per crittografare i dischi locali quando abiliti la crittografia dei dischi locali utilizzando una configurazione Amazon EMR di sicurezza.
### Crittografia HDFS open source
HDFS scambia i dati tra le istanze del cluster durante l'elaborazione distribuita. Inoltre, legge e scrive i dati nei volumi instance store e nei volumi EBS collegati alle istanze. Le seguenti opzioni di crittografia Hadoop open source sono attivate quando abiliti la crittografia per dischi locali:
+ [Secure Hadoop RPC (RPC Hadoop protetto)](https://hadoop.apache.org/docs/r2.7.2/hadoop-project-dist/hadoop-common/SecureMode.html#Data_Encryption_on_RPC) è impostata su `Privacy`, che utilizza Simple Authentication Security Layer (SASL).
+ [Data encryption on HDFS block data transfer (Crittografia di dati su trasferimento di dati di blocco HDFS)](https://hadoop.apache.org/docs/r2.7.2/hadoop-project-dist/hadoop-common/SecureMode.html#Data_Encryption_on_Block_data_transfer.) è impostata su `true` ed è configurata per utilizzare la crittografia AES 256.
**Nota**
Puoi attivare una crittografia Apache Hadoop supplementare abilitando la crittografia in transito. Per ulteriori informazioni, consulta [Crittografia dei dati in transito](#emr-encryption-intransit). Queste impostazioni di crittografia non attivano la crittografia trasparente HDFS, che puoi configurare manualmente. Per ulteriori informazioni, consulta [Crittografia trasparente in HDFS su Amazon EMR](https://docs.aws.amazon.com/emr/latest/ReleaseGuide/emr-encryption-tdehdfs.html) nella *Guida ai rilasci di Amazon EMR*.
### Crittografia dell'archivio istanza
Per i tipi di istanze EC2 che utilizzano NVMe based SSDs come volume di archiviazione delle istanze, la NVMe crittografia viene utilizzata indipendentemente dalle impostazioni di crittografia di Amazon EMR. Per ulteriori informazioni, consulta i [volumi NVMe SSD nella Guida](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ssd-instance-store.html#nvme-ssd-volumes) per l'utente di *Amazon EC2*. Per altri volumi di archivio istanza, Amazon EMR utilizza LUKS per crittografare il volume di archivio istanza quando la crittografia su disco locale è abilitata, indipendentemente dal fatto che i volumi EBS siano crittografati utilizzando la crittografia EBS o LUKS.
### Crittografia dei volumi EBS
Se crei un cluster in una regione in cui la crittografia Amazon EC2 dei volumi EBS è abilitata per impostazione predefinita per il tuo account, i volumi EBS vengono crittografati anche se la crittografia su disco locale non è abilitata. Per ulteriori informazioni, consulta la sezione [Encryption by default](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/EBSEncryption.html#encryption-by-default) nella *Guida per l’utente di Amazon EC2*. Con la crittografia locale del disco abilitata in una configurazione di sicurezza, le impostazioni di Amazon EMR hanno la precedenza sulle impostazioni di Amazon EC2 per le istanze EC2 encryption-by-default del cluster.
Sono disponibili le seguenti opzioni per crittografare i volumi EBS utilizzando una configurazione di sicurezza:
+ **Crittografia EBS**: a partire da Amazon EMR versione 5.24.0, puoi scegliere di abilitare la crittografia EBS. L'opzione di crittografia EBS crittografa il volume dispositivo root EBS e i volumi di storage collegati. L'opzione di crittografia EBS è disponibile solo se specifichi come provider di chiavi. AWS Key Management Service Ti consigliamo di utilizzare la crittografia EBS.
+ **Crittografia LUKS**: se scegli di utilizzare la crittografia LUKS per i volumi Amazon EBS, la crittografia LUKS si applica solo ai volumi di archiviazione collegati, non al volume del dispositivo di root. Per ulteriori informazioni sulla crittografia LUKS, vedi la [specifica di LUKS su disco](https://gitlab.com/cryptsetup/cryptsetup/wikis/Specification).
Per il tuo fornitore di chiavi, puoi configurare una classe AWS KMS key con policy adatte ad Amazon EMR o una classe Java personalizzata che fornisca gli artefatti di crittografia. Quando si utilizza AWS KMS, vengono addebitati costi per l'archiviazione e l'uso delle chiavi di crittografia. Per ulteriori informazioni, consultare [Prezzi di AWS KMS](https://aws.amazon.com/kms/pricing/).
**Nota**
Per verificare se la crittografia EBS è abilitata sul cluster, è consigliabile utilizzare la chiamata API `DescribeVolumes`. Per ulteriori informazioni, consulta [DescribeVolumes](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_DescribeVolumes.html). L'esecuzione di `lsblk` sul cluster verificherà solo lo stato della crittografia LUKS anziché la crittografia EBS.
## Crittografia dei dati in transito
Diversi meccanismi di crittografia sono abilitati con la crittografia in transito. Si tratta di funzionalità open source, sono specifiche dell'applicazione e possono variare in base alla versione di Amazon EMR. Per abilitare la crittografia in transito, usala [Crea una configurazione di sicurezza con la console Amazon EMR o con AWS CLI](emr-create-security-configuration.md) in Amazon EMR. Per i cluster EMR con crittografia in transito abilitata, Amazon EMR configura automaticamente le configurazioni delle applicazioni open source per abilitare la crittografia in transito. Per casi d'uso avanzati, puoi configurare direttamente le configurazioni delle applicazioni open source per sovrascrivere il comportamento predefinito in Amazon EMR. [Per ulteriori informazioni, consulta la matrice di [supporto per la crittografia in transito e](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-encryption-support-matrix.html) la sezione Configurazione delle applicazioni.](https://docs.aws.amazon.com/emr/latest/ReleaseGuide/emr-configure-apps.html)
Consulta quanto segue per ulteriori dettagli specifici sulle applicazioni open source relative alla crittografia in transito:
+ Quando abiliti la crittografia in transito con una configurazione di sicurezza, Amazon EMR abilita la crittografia in transito per tutti gli endpoint di applicazioni open source che supportano la crittografia in transito. Il supporto per la crittografia in transito per diversi endpoint applicativi varia a seconda della versione di rilascio di Amazon EMR. Per ulteriori informazioni, consulta la matrice di supporto per la crittografia [in transito](https://docs.aws.amazon.com/).
+ È possibile sovrascrivere le configurazioni open source, il che consente di effettuare le seguenti operazioni:
+ Disattiva la verifica del nome host TLS se i certificati TLS forniti dall'utente non soddisfano i requisiti
+ Disattiva la crittografia in transito per determinati endpoint in base ai requisiti di prestazioni e compatibilità
+ Controlla quali versioni TLS e suite di crittografia utilizzare.
[Puoi trovare maggiori dettagli sulle configurazioni specifiche dell'applicazione nella matrice di supporto per la crittografia in transito](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-encryption-support-matrix.html)
+ Oltre ad abilitare la crittografia in transito con una configurazione di sicurezza, alcuni canali di comunicazione richiedono anche configurazioni di sicurezza aggiuntive per abilitare la crittografia in transito. Ad esempio, alcuni endpoint applicativi open source utilizzano Simple Authentication and Security Layer (SASL) per la crittografia in transito, che richiede che l'autenticazione Kerberos sia abilitata nella configurazione di sicurezza del cluster EMR. [Per ulteriori informazioni su questi endpoint, consulta la matrice di supporto per la crittografia in transito.](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-encryption-support-matrix.html)
+ Ti consigliamo di utilizzare software che supporti TLS v1.2 o versioni successive. Amazon EMR su EC2 fornisce la distribuzione JDK Corretto predefinita, che determina quali versioni TLS, suite di crittografia e dimensioni delle chiavi sono consentite dalle reti open source eseguite su Java. Al momento, la maggior parte dei framework open source applica TLS v1.2 o versioni successive per Amazon EMR 7.0.0 e versioni successive. Questo perché la maggior parte dei framework open source funziona su Java 17 per Amazon EMR 7.0.0 e versioni successive. Le versioni precedenti di Amazon EMR potrebbero supportare TLS v1.0 e v1.1 perché utilizzano versioni Java precedenti, ma Corretto JDK potrebbe modificare le versioni TLS supportate da Java, il che potrebbe influire sulle versioni esistenti di Amazon EMR.
Puoi specificare gli artifact di crittografia utilizzati per la crittografia di dati in transito in due modi: fornendo un file zippato di certificati che hai caricato in Amazon S3 oppure facendo riferimento a una classe Java personalizzata che fornisce artifact di crittografia. Per ulteriori informazioni, consulta [Fornitura di certificati per la crittografia di dati in transito con Amazon EMR](emr-encryption-enable.md#emr-encryption-certificates).
# Crittografia inattiva utilizzando una chiave KMS del cliente per il servizio EMR WAL
I registri WAL (write-ahead logs) EMR forniscono supporto chiave KMS ai clienti. encryption-at-rest I seguenti dettagli di alto livello su come Amazon EMR WAL è integrato con: AWS KMS
I registri di scrittura anticipata EMR (WAL) interagiscono AWS durante le seguenti operazioni:`CreateWAL`,,,,, `AppendEdit` `ArchiveWALCheckPoint` `CompleteWALFlush` `DeleteWAL` `GetCurrentWALTime``ReplayEdits`, `TrimWAL` tramite l'impostazione `EMR_EC2_DefaultRole` predefinita Quando viene richiamata una delle operazioni precedenti elencate, il WAL EMR crea e contro la chiave KMS. `Decrypt` `GenerateDataKey`
## Considerazioni
Considerate quanto segue quando utilizzate la crittografia AWS KMS basata per EMR WAL:
+ La configurazione di crittografia non può essere modificata dopo la creazione di un WAL EMR.
+ Quando utilizzi la crittografia KMS con la tua chiave KMS, la chiave deve esistere nella stessa regione del cluster Amazon EMR.
+ Sei responsabile del mantenimento di tutte le autorizzazioni IAM richieste e si consiglia di non revocare le autorizzazioni necessarie durante il ciclo di vita del WAL. In caso contrario, causerà scenari di errore imprevisti, come l'impossibilità di eliminare EMR WAL, poiché la chiave di crittografia associata non esiste.
+ L'utilizzo delle chiavi comporta un costo. AWS KMS Per ulteriori informazioni, consultare [Prezzi di AWS Key Management Service](https://aws.amazon.com/kms/pricing/).
## Autorizzazioni IAM richieste
Per utilizzare la chiave KMS del cliente per crittografare EMR WAL a riposo, è necessario assicurarsi di impostare l'autorizzazione appropriata per il ruolo client EMR WAL e il principale del servizio EMR WAL. `emrwal.amazonaws.com`
### Autorizzazioni per il ruolo client EMR WAL
Di seguito è riportata la politica IAM necessaria per il ruolo del client EMR WAL:
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"kms:Decrypt",
"kms:GenerateDataKey*"
],
"Resource": [
"*"
],
"Sid": "AllowKMSDecrypt"
}
]
}
```
------
Il client EMR WAL sul cluster EMR verrà utilizzato per impostazione predefinita. `EMR_EC2_DefaultRole` Se utilizzi un ruolo diverso per il profilo dell'istanza nel cluster EMR, assicurati che ogni ruolo disponga delle autorizzazioni appropriate.
Per ulteriori informazioni sulla gestione della politica dei ruoli, consulta [Aggiungere e rimuovere i permessi di identità IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_manage-attach-detach.html).
### Autorizzazioni per la policy chiave KMS
È necessario fornire il ruolo del cliente EMR WAL e il servizio `Decrypt` e `GenerateDataKey*` l'autorizzazione EMR WAL nella propria politica KMS. [Per ulteriori informazioni sulla gestione delle politiche chiave, consulta la politica chiave di 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"
}
]
}
```
------
Il ruolo specificato nello snippet può cambiare se si modifica il ruolo predefinito.
## Monitoraggio dell'interazione WAL di Amazon EMR con AWS KMS
### Contesto di crittografia WAL di Amazon EMR
Un contesto di crittografia è un insieme di coppie chiave-valore che contiene dati arbitrari non segreti. Quando includi un contesto di crittografia in una richiesta di crittografia dei dati, associa AWS KMS crittograficamente il contesto di crittografia ai dati crittografati. lo stesso contesto di crittografia sia necessario per decrittografare i dati.
Nelle sue richieste [GenerateDataKey](https://docs.aws.amazon.com/kms/latest/APIReference/API_GenerateDataKey.html)e [Decrypt](https://docs.aws.amazon.com/kms/latest/APIReference/API_Decrypt.html) a, AWS KMS Amazon EMR WAL utilizza un contesto di crittografia con coppie nome-valore che identificano il nome WAL EMR.
```
"encryptionContext": {
"aws:emrwal:walname": "111222333444555-testworkspace-emrwalclustertest-emrwaltestwalname"
}
```
Puoi utilizzare il contesto di crittografia per identificare queste operazioni crittografiche nei record e nei log di controllo, come AWS CloudTrail [Amazon CloudWatch Logs](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-user-guide.html), e come condizione per l'autorizzazione nelle politiche e nelle concessioni.
# Crea chiavi e certificati per la crittografia dei dati con Amazon EMR
Prima di specificare le opzioni di crittografia utilizzando una configurazione di sicurezza, scegli il provider che desideri utilizzare per le chiavi e gli artefatti di crittografia. Ad esempio, puoi utilizzare AWS KMS o un provider personalizzato da te creato. Quindi, crea le chiavi o il provider di chiavi come descritto in questa sezione.
## Fornitura di chiavi per crittografare i dati inattivi
Puoi utilizzare AWS Key Management Service (AWS KMS) o un provider di chiavi personalizzate per la crittografia dei dati a riposo in Amazon EMR. Quando si utilizza AWS KMS, vengono addebitati costi per l'archiviazione e l'uso delle chiavi di crittografia. Per ulteriori informazioni, consultare [Prezzi di AWS KMS](https://aws.amazon.com/kms/pricing/).
Questo argomento fornisce dettagli sulla policy delle chiavi per una chiave KMS da utilizzare con Amazon EMR, nonché linee guida ed esempi di codice per scrivere una classe di provider di chiavi personalizzato per la crittografia di Amazon S3. Per ulteriori informazioni sulla creazione di chiavi, consulta [Creazione di chiavi](https://docs.aws.amazon.com/kms/latest/developerguide/create-keys.html) nella *Guida per gli sviluppatori di AWS Key Management Service *.
### Utilizzo AWS KMS keys per la crittografia
La chiave di AWS KMS crittografia deve essere creata nella stessa regione dell'istanza del cluster Amazon EMR e dei bucket Amazon S3 utilizzati con EMRFS. Se la chiave specificata si trova in un account diverso da quello utilizzato per configurare un cluster, è necessario specificare la chiave utilizzando il relativo ARN.
Il ruolo del profilo dell'istanza Amazon EC2 deve disporre delle autorizzazioni per utilizzare la chiave KMS specificata. Il ruolo predefinito per il profilo dell'istanza in Amazon EMR è `EMR_EC2_DefaultRole`. Se utilizzi un ruolo diverso per il profilo dell'istanza o utilizzi ruoli IAM per le richieste EMRFS ad Amazon S3, assicurati che ogni ruolo venga aggiunto come utente chiave a seconda dei casi. Ciò concede al ruolo l'autorizzazione a utilizzare la chiave KMS. Per ulteriori informazioni, consulta [Utilizzo di policy delle chiavi](https://docs.aws.amazon.com/kms/latest/developerguide/key-policies.html#key-policy-default-allow-users) nella *Guida per gli sviluppatori di AWS Key Management Service * e [Configurazione dei ruoli IAM per richieste EMRFS ad Amazon S3](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-emrfs-iam-roles.html).
Puoi usare il Console di gestione AWS per aggiungere il tuo profilo di istanza o il tuo profilo di istanza EC2 all'elenco degli utenti chiave per la chiave KMS specificata, oppure puoi utilizzare il AWS CLI o un AWS SDK per allegare una policy di chiave appropriata.
Nota che Amazon EMR supporta solo [Chiavi KMS simmetriche](https://docs.aws.amazon.com/kms/latest/developerguide/concepts.html#symmetric-cmks). Non è possibile utilizzare una [chiave KMS asimmetrica](https://docs.aws.amazon.com/kms/latest/developerguide/symmetric-asymmetric.html#asymmetric-cmks) per crittografare i dati a riposo in un cluster Amazon EMR. Per informazioni su come determinare se una chiave KMS è simmetrica o asimmetrica, consulta [ Identificazione di chiavi KMS simmetriche e asimmetriche](https://docs.aws.amazon.com/kms/latest/developerguide/find-symm-asymm.html).
La procedura seguente descrive come aggiungere il profilo dell'istanza Amazon EMR predefinito, `EMR_EC2_DefaultRole` come *utente di chiavi* utilizzando la Console di gestione AWS. Presuppone che tu abbia già creato una chiave KMS. Per creare una nuova chiave KMS, consulta [Creazione di chiavi](https://docs.aws.amazon.com/kms/latest/developerguide/create-keys.html) nella *Guida per gli sviluppatori di AWS Key Management Service *.
**Aggiunta del profilo dell'istanza EC2 per Amazon EMR all'elenco degli utenti della chiave di crittografia**
1. [Accedi Console di gestione AWS e apri la console AWS Key Management Service (AWS KMS) su /kms. https://console.aws.amazon.com](https://console.aws.amazon.com/kms)
1. Per modificare il Regione AWS, usa il selettore della regione nell'angolo in alto a destra della pagina.
1. Seleziona l'alias della chiave KMS da modificare.
1. Nella pagina dei dettagli della chiave, in **Key Users** (Utenti di chiavi), scegli **Add** (Aggiungi).
1. Nella finestra di dialogo **Add key users** (Aggiungi utenti chiave) selezionare il ruolo appropriato. Il nome del ruolo di default è `EMR_EC2_DefaultRole`.
1. Scegliere **Add** (Aggiungi).
### Abilitazione della crittografia EBS fornendo autorizzazioni aggiuntive per le chiavi KMS
A partire da Amazon EMR versione 5.24.0, puoi crittografare il dispositivo di root EBS e i volumi di archiviazione utilizzando un'opzione di configurazione di sicurezza. Per abilitare tale opzione, è necessario specificare AWS KMS come fornitore di chiavi. Inoltre, è necessario concedere al ruolo `EMR_DefaultRole` di servizio le autorizzazioni per utilizzare AWS KMS key quanto specificato.
È possibile utilizzare il Console di gestione AWS per aggiungere il ruolo di servizio all'elenco degli utenti chiave per la chiave KMS specificata oppure utilizzare il AWS CLI o un AWS SDK per allegare una politica di chiave appropriata.
La procedura seguente descrive come utilizzare per Console di gestione AWS aggiungere il ruolo di servizio Amazon EMR predefinito `EMR_DefaultRole` come utente *chiave*. Presuppone che tu abbia già creato una chiave KMS. Per creare una nuova chiave KMS, consulta [Creazione di chiavi](https://docs.aws.amazon.com/kms/latest/developerguide/create-keys.html) nella *Guida per gli sviluppatori di AWS Key Management Service *.
**Per aggiungere il ruolo del servizio Amazon EMR all'elenco degli utenti delle chiavi di crittografia**
1. Accedi a Console di gestione AWS e apri la console AWS Key Management Service (AWS KMS) su [https://console.aws.amazon.com/kms](https://console.aws.amazon.com/kms).
1. Per modificare il Regione AWS, usa il selettore della regione nell'angolo in alto a destra della pagina.
1. Nella barra laterale sinistra, scegli **Customer managed keys (Chiavi gestite dal cliente)**.
1. Seleziona l'alias della chiave KMS da modificare.
1. Nella pagina dei dettagli della chiave, in **Key Users** (Utenti di chiavi), scegli **Add** (Aggiungi).
1. Nella sezione **Aggiungi utenti chiave**, seleziona il ruolo appropriato. Il nome del ruolo di servizio predefinito per Amazon EMR è. `EMR_DefaultRole`
1. Scegliere **Aggiungi**.
### Creazione di un provider di chiavi personalizzato
Quando utilizzi una configurazione di sicurezza, devi specificare un nome di classe di provider differente per la crittografia per dischi locali e la crittografia di Amazon S3. I requisiti per il fornitore di chiavi personalizzate dipendono dall'utilizzo della crittografia locale del disco e della crittografia Amazon S3, nonché della versione di rilascio di Amazon EMR.
A seconda del tipo di crittografia utilizzato per la creazione di un provider di chiavi personalizzate, l'applicazione deve inoltre implementare interfacce diverse EncryptionMaterialsProvider . Entrambe le interfacce sono disponibili nella versione AWS SDK for Java 1.11.0 e successive.
+ [Per implementare la crittografia Amazon S3, usa com.amazonaws.services.s3.model. EncryptionMaterialsProvider interfaccia.](https://docs.aws.amazon.com/AWSJavaSDK/latest/javadoc/com/amazonaws/services/s3/model/EncryptionMaterialsProvider.html)
+ Per implementare la crittografia locale del disco, utilizza [com.amazonaws.services.elasticmapreduce.spi.security. EncryptionMaterialsProvider interfaccia.](https://docs.aws.amazon.com/AWSJavaSDK/latest/javadoc/com/amazonaws/services/elasticmapreduce/spi/security/EncryptionMaterialsProvider.html)
È possibile utilizzare qualsiasi strategia per fornire materiali di crittografia per l'implementazione. Ad esempio, è possibile scegliere di fornire materiali di crittografia statici o integrarli con un sistema di gestione delle chiavi più complesso.
Se utilizzi la crittografia Amazon S3, devi utilizzare gli algoritmi di crittografia **AES/GCM/NoPadding**per materiali di crittografia personalizzati.
Se utilizzi la crittografia del disco locale, l'algoritmo di crittografia da utilizzare per i materiali di crittografia personalizzati varia in base alla versione EMR. Per Amazon EMR 7.0.0 e versioni precedenti, è necessario utilizzare. **AES/GCM/NoPadding** **Per Amazon EMR 7.1.0 e versioni successive, devi utilizzare AES.**
La EncryptionMaterialsProvider classe ottiene materiali di crittografia in base al contesto di crittografia. Amazon EMR popola le informazioni sul contesto di crittografia al runtime per aiutare il chiamante a determinare i materiali di crittografia corretti da restituire.
**Example Esempio: utilizzo di un provider di chiavi personalizzato per la crittografia Amazon S3 con EMRFS**
Quando Amazon EMR recupera i materiali di crittografia dalla EncryptionMaterialsProvider classe per eseguire la crittografia, EMRFS compila facoltativamente l'argomento MaterialsDescription con due campi: l'URI Amazon S3 per l'oggetto JobFlowId e il cluster, che possono essere utilizzati dalla classe per restituire i materiali di crittografia in modo selettivo. EncryptionMaterialsProvider
Ad esempio, il provider potrebbe restituire chiavi diverse per diversi prefissi URI di Amazon S3. Sarà la descrizione dei materiali di crittografia restituiti a essere memorizzata con l'oggetto Amazon S3 anziché il valore materialsDescription generato da EMRFS e passato al provider. Durante la decrittografia di un oggetto Amazon S3, la descrizione dei materiali di crittografia viene passata alla EncryptionMaterialsProvider classe, in modo che possa, ancora una volta, restituire selettivamente la chiave corrispondente per decrittografare l'oggetto.
Di seguito viene fornita un'implementazione di riferimento EncryptionMaterialsProvider . Un altro provider personalizzato è disponibile presso GitHub. [EMRFSRSAEncryptionMaterialsProvider](https://github.com/awslabs/emr-sample-apps/tree/master/emrfs-plugins/EMRFSRSAEncryptionMaterialsProvider)
```
import com.amazonaws.services.s3.model.EncryptionMaterials;
import com.amazonaws.services.s3.model.EncryptionMaterialsProvider;
import com.amazonaws.services.s3.model.KMSEncryptionMaterials;
import org.apache.hadoop.conf.Configurable;
import org.apache.hadoop.conf.Configuration;
import java.util.Map;
/**
* Provides KMSEncryptionMaterials according to Configuration
*/
public class MyEncryptionMaterialsProviders implements EncryptionMaterialsProvider, Configurable{
private Configuration conf;
private String kmsKeyId;
private EncryptionMaterials encryptionMaterials;
private void init() {
this.kmsKeyId = conf.get("my.kms.key.id");
this.encryptionMaterials = new KMSEncryptionMaterials(kmsKeyId);
}
@Override
public void setConf(Configuration conf) {
this.conf = conf;
init();
}
@Override
public Configuration getConf() {
return this.conf;
}
@Override
public void refresh() {
}
@Override
public EncryptionMaterials getEncryptionMaterials(Map materialsDescription) {
return this.encryptionMaterials;
}
@Override
public EncryptionMaterials getEncryptionMaterials() {
return this.encryptionMaterials;
}
}
```
## Fornitura di certificati per la crittografia di dati in transito con Amazon EMR
Con Amazon EMR versione 4.8.0 o successive, sono disponibili due opzioni per specificare artifact di crittografia dei dati in transito utilizzando una configurazione di sicurezza:
+ Puoi creare manualmente certificati PEM, includerli in un file .zip e quindi fare riferimento al file .zip in Amazon S3.
+ Puoi implementare un provider di certificati personalizzato come classe Java, specificare il file JAR dell'applicazione in Amazon S3 e infine fornire il nome di classe completo del provider come dichiarato nell'applicazione. La classe deve implementare l'interfaccia [TLSArtifactsProvider](https://docs.aws.amazon.com/AWSJavaSDK/latest/javadoc/com/amazonaws/services/elasticmapreduce/spi/security/TLSArtifactsProvider.html) disponibile a partire dalla AWS SDK per Java versione 1.11.0.
Amazon EMR scarica automaticamente artifact in ogni nodo nel cluster e successivamente li utilizza per implementare le funzionalità di crittografia in transito open source. Per ulteriori informazioni sulle opzioni disponibili, consulta [Crittografia dei dati in transito](emr-data-encryption-options.md#emr-encryption-intransit).
### Utilizzo di certificati PEM
Quando specifichi un file ZIP per la crittografia in transito, per la configurazione di sicurezza i file PEM nel file ZIP devono essere denominati esattamente come illustrato di seguito:
**Certificati di crittografia in transito**
| Nome file | Obbligatorio/facoltativo | Informazioni |
| --- | --- | --- |
| privateKey.pem | Richiesto | Chiave privata |
| certificateChain.pem | Richiesto | Catena di certificati |
| trustedCertificates.pem | Facoltativo | Si consiglia di fornire un certificato non firmato dalla Trusted Root Certification Authority (CA) predefinita di Java o da una CA intermedia che possa collegarsi alla CA root affidabile predefinita di Java. Non è consigliabile utilizzare il formato public CAs quando si utilizzano certificati wildcard o quando si disabilita la verifica del nome host. |
È probabile che tu intenda configurare il file PEM della chiave privata affinché sia un certificato generico che consente l'accesso al dominio Amazon VPC in cui si trovano le istanze di cluster. Ad esempio, se il cluster risiede in us-east-1 (Virginia settentrionale), puoi scegliere di specificare un nome comune nella configurazione del certificato che autorizza l'accesso al cluster specificando `CN=*.ec2.internal` nella definizione di oggetto del certificato. Se il cluster risiede in us-west-2 (Oregon), puoi specificare `CN=*.us-west-2.compute.internal`.
Se il file PEM fornito nell'elemento di crittografia non contiene un carattere jolly per il dominio nel nome comune, devi modificare il valore di to. `hadoop.ssl.hostname.verifier` `ALLOW_ALL` Per farlo nelle versioni 7.3.0 e successive di Amazon EMR, aggiungi la `core-site` classificazione quando invii le configurazioni a un cluster. Nelle versioni precedenti alla 7.3.0, aggiungi la configurazione `"hadoop.ssl.hostname.verifier": "ALLOW_ALL"` direttamente nel file. `core-site.xml` Questa modifica è necessaria perché il verificatore del nome host predefinito richiede un nome host senza il carattere jolly perché tutti gli host del cluster lo utilizzano. Per ulteriori informazioni sulla configurazione di cluster EMR in Amazon VPC, consulta [Configurazione della rete in un VPC per Amazon EMR](emr-plan-vpc-subnet.md).
L'esempio seguente dimostra come utilizzare [OpenSSL](https://www.openssl.org/) per generare un certificato X.509 autofirmato con una chiave privata RSA a 2048 bit. La chiave consente di accedere alle istanze del cluster Amazon EMR dell'emittente nella Regione `us-west-2` (Oregon) come specificato dal nome di dominio `*.us-west-2.compute.internal` come nome comune.
Sono specificati altri elementi di oggetto facoltativi, come paese (C), stato (S) e lingua (L). Poiché viene generato un certificato autofirmato, il secondo comando dell'esempio copia il file `certificateChain.pem` nel file `trustedCertificates.pem`. Il terzo comando usa `zip` per creare il file `my-certs.zip` che contiene i certificati.
**Importante**
Questo esempio è solo una proof-of-concept dimostrazione. L'utilizzo di certificati autofirmati non è consigliato e presenta un potenziale rischio per la sicurezza. Per i sistemi di produzione, utilizza un'autorità di certificazione attendibile per emettere certificati.
```
$ 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
```
# Comprendere la crittografia in transito
Puoi configurare un cluster EMR per eseguire framework open source come [Apache Spark, Apache](https://aws.amazon.com/emr/features/spark/) [Hive](https://aws.amazon.com/emr/features/hive/) e [Presto](https://aws.amazon.com/emr/features/presto/). Ognuno di questi framework open source ha una serie di processi in esecuzione sulle istanze EC2 di un cluster. Ciascuno di questi processi può ospitare endpoint di rete per le comunicazioni di rete.
Se la crittografia in transito è abilitata su un cluster EMR, diversi endpoint di rete utilizzano meccanismi di crittografia diversi. Consulta le sezioni seguenti per saperne di più sugli endpoint di rete con framework open source specifici supportati dalla crittografia in transito, sui relativi meccanismi di crittografia e sulla versione di Amazon EMR che ha aggiunto il supporto. Ogni applicazione open source può inoltre avere best practice e configurazioni di framework open source diverse che puoi modificare.
Per una copertura ottimale della crittografia in transito, consigliamo di abilitare sia la crittografia in transito che Kerberos. Se abiliti solo la crittografia in transito, la crittografia in transito sarà disponibile solo per gli endpoint di rete che supportano TLS. Kerberos è necessario perché alcuni endpoint di rete con framework open source utilizzano Simple Authentication and Security Layer (SASL) per la crittografia in transito.
Tieni presente che tutti i framework open source non supportati nelle versioni di Amazon EMR 7.x.x non sono inclusi.
## Spark
Quando abiliti la crittografia in transito nelle configurazioni di sicurezza, `spark.authenticate` viene automaticamente impostata e utilizza la crittografia basata su AES per `true` le connessioni RPC.
A partire da Amazon EMR 7.3.0, se utilizzi la crittografia in transito e l'autenticazione Kerberos, non puoi utilizzare le applicazioni Spark che dipendono dal metastore Hive. [Hive 3 risolve questo problema in HIVE-16340.](https://issues.apache.org/jira/browse/HIVE-16340) [HIVE-44114](https://issues.apache.org/jira/browse/SPARK-44114) risolve completamente questo problema quando Spark open source può essere aggiornato a Hive 3. Nel frattempo, puoi decidere di risolvere il problema. `hive.metastore.use.SSL` `false` Per ulteriori informazioni, consulta la sezione [Configurazione delle applicazioni](https://docs.aws.amazon.com/emr/latest/ReleaseGuide/emr-configure-apps.html).
Per ulteriori informazioni, consulta la [sicurezza di Spark](https://spark.apache.org/docs/latest/security) nella documentazione di Apache Spark.
| Componente | Endpoint | Porta | Meccanismo di crittografia in transito | Supportato dalla versione |
| --- | --- | --- | --- | --- |
| Spark History Server | spark.ssl.history.port | 18480 | TLS | emr-5,3,0\$1, emr-6,0\$1, emr-7,0\$1 |
| Interfaccia utente Spark | porta spark.ui.port | 4440 | TLS | emr-5,3,0\$1, emr-6,0\$1, emr-7,0\$1 |
| Driver Spark | spark.driver.port | Dinamico | Crittografia basata su Spark AES | emr-4.8.0\$1, emr-5.0.0\$1, emr-6.0.0\$1, emr-7.0\$1 |
| Esecutore Spark | Executor Port (nessuna configurazione con nome) | Dinamico | Crittografia basata su Spark AES | emr-4.8.0\$1, emr-5.0.0\$1, emr-6.0.0\$1, emr-7.0\$1 |
| FILATO NodeManager | spark.shuffle.service.porta 1 | 7337 | Crittografia basata su Spark AES | emr-4.8.0\$1, emr-5.0.0\$1, emr-6.0.0\$1, emr-7.0\$1 |
1 è ospitato su `spark.shuffle.service.port` YARN ma è utilizzato solo da Apache NodeManager Spark.
**Problema noto**
La `spark.yarn.historyServer.address` configurazione dei cluster abilitati a Intransit utilizza attualmente la porta`18080`, che impedisce l'accesso all'interfaccia utente dell'applicazione Spark utilizzando l'URL di tracciamento YARN. **Influisce sulla versione:** da EMR - 7.3.0 a EMR - 7.9.0.
Utilizza la seguente soluzione alternativa:
1. Modifica la `spark.yarn.historyServer.address` configurazione `/etc/spark/conf/spark-defaults.conf` per utilizzare il numero di `HTTPS` porta `18480` su un cluster in esecuzione.
1. Questo può essere fornito anche nelle sostituzioni di configurazione durante l'avvio del cluster.
Configurazione di esempio:
```
[
{
"Classification": "spark-defaults",
"Properties": {
"spark.yarn.historyServer.address": "${hadoopconf-yarn.resourcemanager.hostname}:18480"
}
}
]
```
## Hadoop YARN
[Secure Hadoop RPC](https://hadoop.apache.org/docs/r2.7.2/hadoop-project-dist/hadoop-common/SecureMode.html#Data_Encryption_on_RPC) è impostato e utilizza la crittografia in transito basata su SASL. `privacy` Ciò richiede che l'autenticazione Kerberos sia abilitata nella configurazione di sicurezza. Se non desideri la crittografia in transito per Hadoop RPC, configura. `hadoop.rpc.protection = authentication` Ti consigliamo di utilizzare la configurazione predefinita per la massima sicurezza.
Se i tuoi certificati TLS non sono in grado di soddisfare i requisiti di verifica del nome host TLS, puoi configurarli. `hadoop.ssl.hostname.verifier = ALLOW_ALL` Ti consigliamo di utilizzare la configurazione predefinita di`hadoop.ssl.hostname.verifier = DEFAULT`, che impone la verifica del nome host TLS.
Per disabilitare HTTPS per gli endpoint dell'applicazione web YARN, configura. `yarn.http.policy = HTTP_ONLY` In questo modo il traffico verso questi endpoint rimane non crittografato. Ti consigliamo di utilizzare la configurazione predefinita per la massima sicurezza.
Per ulteriori informazioni, consulta [Hadoop in secure mode](https://hadoop.apache.org/docs/r2.7.2/hadoop-project-dist/hadoop-common/SecureMode.html) (Hadoop in modalità protetta) nella documentazione di Apache Hadoop.
| Componente | Endpoint | Porta | Meccanismo di crittografia in transito | Supportato dalla versione |
| --- | --- | --- | --- | --- |
| 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\$1, emr-6.0.0\$1, emr-7.0\$1 |
| ResourceManager | yarn.resourcemanager.scheduler.address | 8030 | SASL\$1 Kerberos | emr-4.8.0\$1, emr-5.0\$1, emr-6.0.0\$1, emr-7.0\$1 |
| ResourceManager | yarn.resourcemanager.address | 8032 | SASL \$1 Kerberos | emr-4.8.0\$1, emr-5.0\$1, emr-6.0.0\$1, emr-7.0\$1 |
| ResourceManager | yarn.resourcemanager.admin.address | 8033 | SASL \$1 Kerberos | emr-4.8.0\$1, emr-5.0\$1, emr-6.0.0\$1, emr-7.0\$1 |
| TimelineServer | yarn.timeline-service.indirizzo | 10200 | SASL\$1 Kerberos | emr-4.8.0\$1, emr-5.0\$1, emr-6.0.0\$1, emr-7.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\$1, emr-6.0.0\$1, emr-7.0\$1 |
| NodeManager | yarn.nodemanager.address | 8041 | SASL\$1 Kerberos | emr-4.8.0\$1, emr-5.0\$1, emr-6.0.0\$1, emr-7.0\$1 |
| NodeManager | yarn.nodemanager.localizer.address | 8040 | SASL\$1 Kerberos | emr-4.8.0\$1, emr-5.0\$1, emr-6.0.0\$1, emr-7.0\$1 |
| NodeManager | yarn.nodemanager.webapp.address | 8044 | TLS | emr-7.3.0\$1 |
| NodeManager | mapreduce.shuffle.porta 1 | 13562 | TLS | emr-4.8.0\$1, emr-5.0\$1, emr-6.0,0\$1, emr-7.0\$1 |
| NodeManager | spark.shuffle.service.porta 2 | 7337 | Crittografia basata su Spark AES | emr-4.8.0\$1, emr-5.0.0\$1, emr-6.0.0\$1, emr-7.0\$1 |
1 è ospitato su `mapreduce.shuffle.port` YARN ma viene utilizzato solo da NodeManager Hadoop. MapReduce
2 `spark.shuffle.service.port` è ospitato su YARN NodeManager ma viene utilizzato solo da Apache Spark.
**Problema noto**
La `yarn.log.server.url` configurazione in utilizza attualmente HTTP con porta 19888, che impedisce l'accesso ai log delle applicazioni dall'interfaccia utente di Resource Manager. **Influisce sulla versione:** da EMR - 7.3.0 a EMR - 7.8.0.
Utilizza la seguente soluzione alternativa:
1. Modifica la `yarn.log.server.url` configurazione `yarn-site.xml` per utilizzare il `HTTPS` protocollo e il numero di `19890` porta.
1. Riavvia YARN Resource Manager:`sudo systemctl restart hadoop-yarn-resourcemanager.service`.
## Hadoop HDFS
Il nodo nome Hadoop, il nodo dati e il nodo journal supportano tutti TLS per impostazione predefinita se la crittografia in transito è abilitata nei cluster EMR.
[Secure Hadoop RPC](https://hadoop.apache.org/docs/r2.7.2/hadoop-project-dist/hadoop-common/SecureMode.html#Data_Encryption_on_RPC) è impostato e utilizza la crittografia in transito basata su SASL. `privacy` Ciò richiede che l'autenticazione Kerberos sia abilitata nella configurazione di sicurezza.
Ti consigliamo di non modificare le porte predefinite utilizzate per gli endpoint HTTPS.
[La crittografia dei dati sul trasferimento a blocchi HDFS utilizza](https://hadoop.apache.org/docs/r2.7.2/hadoop-project-dist/hadoop-common/SecureMode.html#Data_Encryption_on_Block_data_transfer.) AES 256 e richiede che la crittografia a riposo sia abilitata nella configurazione di sicurezza.
Per ulteriori informazioni, consulta [Hadoop in secure mode](https://hadoop.apache.org/docs/r2.7.2/hadoop-project-dist/hadoop-common/SecureMode.html) (Hadoop in modalità protetta) nella documentazione di Apache Hadoop.
| Componente | Endpoint | Porta | Meccanismo di crittografia in transito | Supportato dalla versione |
| --- | --- | --- | --- | --- |
| NomeNode | indirizzo dfs.namenode.https-address | 9871 | TLS | emr-4.8.0\$1, emr-5.0\$1, emr-6.0,0\$1, emr-7.0\$1 |
| Nodo del nome | dfs.namenode.rpc-indirizzo-pc | 8020 | SASL\$1 Kerberos | emr-4.8.0\$1, emr-5.0\$1, emr-6.0.0\$1, emr-7.0\$1 |
| Nodo dati | dfs.datanode.https.address | 9865 | TLS | emr-4.8.0\$1, emr-5.0\$1, emr-6.0,0\$1, emr-7.0\$1 |
| Nodo dati | dfs.datanode.address | 9866 | SASL \$1 Kerberos | emr-4.8.0\$1, emr-5.0\$1, emr-6.0.0\$1, emr-7.0\$1 |
| Nodo Journal | indirizzo dfs.journalnode.https-address | 8481 | TLS | emr-4.8.0\$1, emr-5.0\$1, emr-6.0.0\$1, emr-7.0\$1 |
| Nodo Journal | indirizzo dfs.journalnode.rpc | 8485 | SASL\$1 Kerberos | emr-4.8.0\$1, emr-5.0\$1, emr-6.0.0\$1, emr-7.0\$1 |
| DFSZKFailoverControllore | dfs.ha.zkfc.port | 8019 | Nessuno | TLS per ZKFC è supportato solo in Hadoop 3.4.0. [Per ulteriori informazioni, vedere HADOOP-18919.](https://issues.apache.org/jira/browse/HADOOP-18919) La versione 7.1.0 di Amazon EMR è attualmente su Hadoop 3.3.6. Le versioni successive di Amazon EMR saranno disponibili su Hadoop 3.4.0 in futuro |
## Hadoop MapReduce
Hadoop MapReduce, Job History Server e MapReduce shuffle supportano tutti TLS per impostazione predefinita quando la crittografia in transito è abilitata nei cluster EMR.
Lo shuffle crittografato [Hadoop MapReduce ](https://hadoop.apache.org/docs/r2.7.1/hadoop-mapreduce-client/hadoop-mapreduce-client-core/EncryptedShuffle.html) utilizza TLS.
Ti consigliamo di non modificare le porte predefinite per gli endpoint HTTPS.
Per ulteriori informazioni, consulta [Hadoop in secure mode](https://hadoop.apache.org/docs/r2.7.2/hadoop-project-dist/hadoop-common/SecureMode.html) (Hadoop in modalità protetta) nella documentazione di Apache Hadoop.
| Componente | Endpoint | Porta | Meccanismo di crittografia in transito | Supportato dalla versione |
| --- | --- | --- | --- | --- |
| JobHistoryServer | mapreduce.jobhistory.webapp.https.address | 19890 | TLS | emr-7.3.0\$1 |
| FILATO NodeManager | mapreduce.shuffle.porta 1 | 13562 | TLS | emr-4.8.0\$1, emr-5.0\$1, emr-6.0,0\$1, emr-7.0\$1 |
1 è ospitato su `mapreduce.shuffle.port` YARN ma viene utilizzato solo da NodeManager Hadoop. MapReduce
## Presto
[Nelle versioni 5.6.0 e successive di Amazon EMR, la comunicazione interna tra il coordinatore Presto e i lavoratori utilizza TLS Amazon EMR configura tutte le configurazioni richieste per consentire una comunicazione interna sicura in Presto.](https://prestodb.io/docs/current/security/internal-communication.html)
Se il connettore utilizza il metastore Hive come archivio di metadati, anche la comunicazione tra il comunicatore e il metastore Hive viene crittografata con TLS.
| Componente | Endpoint | Porta | Meccanismo di crittografia in transito | Supportato dalla versione |
| --- | --- | --- | --- | --- |
| Coordinatore Presto | http-server.https.port | 8446 | TLS | emr-5,6,0\$1, emr-6,0\$1, emr-7,0\$1 |
| Lavoratore Presto | http-server.https.port | 8446 | TLS | emr-5,6,0\$1, emr-6,0\$1, emr-7,0\$1 |
## Trino
[Nelle versioni 6.1.0 e successive di Amazon EMR, la comunicazione interna tra il coordinatore di Presto e i lavoratori utilizza TLS Amazon EMR configura tutte le configurazioni richieste per consentire una comunicazione interna sicura in Trino.](https://trino.io/docs/current/security/internal-communication.html)
Se il connettore utilizza il metastore Hive come archivio di metadati, anche la comunicazione tra il comunicatore e il metastore Hive viene crittografata con TLS.
| Componente | Endpoint | Porta | Meccanismo di crittografia in transito | Supportato dalla versione |
| --- | --- | --- | --- | --- |
| Coordinatore di Trino | http-server.https.port | 8446 | TLS | emr-6,1\$1, emr-7,0\$1 |
| Operaio di Trino | http-server.https.port | 8446 | TLS | emr-6,1\$1, emr-7,0\$1 |
## Hive e Tez
Per impostazione predefinita, Hive server 2, Hive metastore server, Hive LLAP Daemon Web UI e Hive LLAP shuffle supportano tutti TLS quando la crittografia in transito è abilitata nei cluster EMR. Per ulteriori informazioni [sulle](https://cwiki.apache.org/confluence/display/Hive/Configuration+Properties) configurazioni Hive, vedere Proprietà di configurazione.
L'interfaccia utente Tez ospitata sul server Tomcat è anche abilitata per HTTPS quando la crittografia in transito è abilitata nel cluster EMR. Tuttavia, HTTPS è disabilitato per il servizio di interfaccia utente web Tez AM, quindi gli utenti AM non hanno accesso al file keystore per il listener SSL di apertura. È inoltre possibile abilitare questo comportamento con le configurazioni booleane e. `tez.am.tez-ui.webservice.enable.ssl` `tez.am.tez-ui.webservice.enable.client.auth`
| Componente | Endpoint | Porta | Meccanismo di crittografia in transito | Supportato dalla versione |
| --- | --- | --- | --- | --- |
| 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\$1 |
| HiveServer2 | hive.server2.webui.port | 10002 | TLS | emr-7.3.0\$1 |
| HiveMetastoreServer | hive.metastore.port | 9083 | TLS | emr-7.3.0\$1 |
| Demone LLAP | hive.llap.daemon.yarn.shuffle.port | 1551 | TLS | emr-7.3.0\$1 |
| Demone LLAP | hive.llap.daemon.web.port | 15002 | TLS | emr-7.3.0\$1 |
| Demone LLAP | hive.llap.daemon.output.service.port | 15003 | Nessuno | Hive non supporta la crittografia in transito per questo endpoint |
| Demone LLAP | hive.llap.management.rpc.port | 15004 | Nessuno | Hive non supporta la crittografia in transito per questo endpoint |
| Demone LLAP | hive.llap.plugin.rpc.port | Dinamico | Nessuno | Hive non supporta la crittografia in transito per questo endpoint |
| Demone LLAP | hive.llap.daemon.rpc.port | Dinamico | Nessuno | Hive non supporta la crittografia in transito per questo endpoint |
| Web HCat | templeton.port | 5011 | TLS | emr-7.3.0\$1 |
| Tez Application Master | tez.am.client.am.port-range tez.am.task.am.port-range | Dinamico | Nessuno | Tez non supporta la crittografia in transito per questo endpoint |
| Tez Application Master | tez.am.tez-ui.webservice.port-range | Dinamico | Nessuno | Disabilitato per impostazione predefinita. Può essere abilitato utilizzando le configurazioni Tez in emr-7.3.0\$1 |
| Tez Task | N/A: non configurabile | Dinamico | Nessuno | Tez non supporta la crittografia in transito per questo endpoint |
| Interfaccia utente Tez | Configurabile tramite il server Tomcat su cui è ospitata l'interfaccia utente Tez | 8080 | TLS | emr-7.3.0\$1 |
## Flink
Gli endpoint REST Apache Flink e la comunicazione interna tra i processi flink supportano TLS per impostazione predefinita quando si abilita la crittografia in transito nei cluster 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)è impostato `true` e utilizza la crittografia in transito per la comunicazione interna tra i processi Flink. Se non desideri la crittografia in transito per le comunicazioni interne, disabilita tale configurazione. Ti consigliamo di utilizzare la configurazione predefinita per la massima sicurezza.
Amazon EMR imposta `true` e utilizza [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)la crittografia in transito per gli endpoint REST. Inoltre, Amazon EMR imposta su true [https://nightlies.apache.org/flink/flink-docs-release-1.18/docs/deployment/config/#historyserver-web-ssl-enabled](https://nightlies.apache.org/flink/flink-docs-release-1.18/docs/deployment/config/#historyserver-web-ssl-enabled)per utilizzare la comunicazione TLS con il server di cronologia Flink. Se non desideri la crittografia in transito per i punti REST, disabilita queste configurazioni. Ti consigliamo di utilizzare la configurazione predefinita per la massima sicurezza.
Amazon EMR utilizza [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). per specificare l'elenco di cifrari che utilizzano la crittografia basata su AES. Sostituisci questa configurazione per utilizzare i codici che desideri.
Per ulteriori informazioni, consulta [SSL Setup](https://nightlies.apache.org/flink/flink-docs-release-1.18/docs/deployment/security/security-ssl/) nella documentazione di Flink.
| Componente | Endpoint | Porta | Meccanismo di crittografia in transito | Supportato dalla versione |
| --- | --- | --- | --- | --- |
| Flink History Server | historyserver.web.port | 8082 | TLS | emr-7.3.0\$1 |
| Server Rest di Job Manager | rest.bind-port porta di riposo | Dinamico | TLS | emr-7.3.0\$1 |
## HBase
Amazon EMR imposta [Secure Hadoop](https://hadoop.apache.org/docs/r2.7.2/hadoop-project-dist/hadoop-common/SecureMode.html#Data_Encryption_on_RPC) RPC su. `privacy` HMaster e RegionServer utilizza la crittografia in transito basata su SASL. Ciò richiede che l'autenticazione Kerberos sia abilitata nella configurazione di sicurezza.
Amazon EMR imposta su true e utilizza TLS `hbase.ssl.enabled` per gli endpoint dell'interfaccia utente. Se non desideri utilizzare TLS per gli endpoint dell'interfaccia utente, disabilita questa configurazione. Ti consigliamo di utilizzare la configurazione predefinita per la massima sicurezza.
Amazon EMR imposta `hbase.rest.ssl.enabled` `hbase.thrift.ssl.enabled` e utilizza TLS per gli endpoint dei server REST e Thirft, rispettivamente. Se non desideri utilizzare TLS per questi endpoint, disabilita questa configurazione. Ti consigliamo di utilizzare la configurazione predefinita per la massima sicurezza.
A partire da EMR 7.6.0, TLS è supportato sugli endpoint. HMaster RegionServer Amazon EMR imposta `hbase.server.netty.tls.enabled` anche e. `hbase.client.netty.tls.enabled` Se non desideri utilizzare TLS per questi endpoint, disabilita questa configurazione. Ti consigliamo di utilizzare la configurazione predefinita, che fornisce la crittografia e quindi una maggiore sicurezza. Per ulteriori informazioni, consulta [Transport Level Security (TLS) nella comunicazione HBase RPC nella](https://hbase.apache.org/book.html#_transport_level_security_tls_in_hbase_rpc_communication) *Apache HBase * Reference Guide.
| Componente | Endpoint | Porta | Meccanismo di crittografia in transito | Supportato dalla versione |
| --- | --- | --- | --- | --- |
| 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 ed emr-7.0.0\$1 TLS in emr-7.6.0\$1 |
| HMaster | HMaster INTERFACCIA UTENTE | 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 ed emr-7.0.0\$1 TLS in emr-7.6.0\$1 |
| RegionServer | RegionServer Informazioni | 16030 | TLS | emr-7.3.0\$1 |
| HBase Server REST | Server di riposo | 8070 | TLS | emr-7.3.0\$1 |
| HBase Server REST | Interfaccia utente Rest | 8085 | TLS | emr-7.3.0\$1 |
| Hbase Thrift Server | Server Thrift | 9090 | TLS | emr-7.3.0\$1 |
| Hbase Thrift Server | Interfaccia utente di Thrift Server | 9095 | TLS | emr-7.3.0\$1 |
## Phoenix
Se hai abilitato la crittografia in transito nel tuo cluster EMR, Phoenix Query Server supporta la `phoenix.queryserver.tls.enabled` proprietà TLS, che è impostata su di default. `true`
Per ulteriori informazioni, consulta [Configurazioni relative a HTTPS](https://phoenix.apache.org/server.html#Configuration) nella documentazione di Phoenix Query Server.
| Componente | Endpoint | Porta | Meccanismo di crittografia in transito | Supportato dalla versione |
| --- | --- | --- | --- | --- |
| Server di interrogazione | phoenix.queryserver.http.port | 8765 | TLS | emr-7.3.0\$1 |
## Oozie
[OOZIE-3673](https://issues.apache.org/jira/browse/OOZIE-3673) è disponibile su Amazon EMR se esegui Oozie su Amazon EMR 7.3.0 e versioni successive. Se devi configurare protocolli SSL o TLS personalizzati quando esegui un'azione e-mail, puoi impostare la proprietà nel file. `oozie.email.smtp.ssl.protocols` `oozie-site.xml` Per impostazione predefinita, se hai abilitato la crittografia in transito, Amazon EMR utilizza il protocollo TLS v1.3.
[OOZIE-3677](https://issues.apache.org/jira/browse/OOZIE-3677) e [OOZIE-3674 sono](https://issues.apache.org/jira/browse/OOZIE-3674) disponibili anche su Amazon EMR se esegui Oozie su Amazon EMR 7.3.0 e versioni successive. Ciò consente di specificare `keyStoreType` `trustStoreType` le `oozie-site.xml` proprietà e le impostazioni. OOZIE-3674 aggiunge il parametro `--insecure` al client Oozie in modo che possa ignorare gli errori dei certificati.
Oozie applica la verifica del nome host TLS, il che significa che qualsiasi certificato utilizzato per la crittografia in transito deve soddisfare i requisiti di verifica del nome host. Se il certificato non soddisfa i criteri, il cluster potrebbe rimanere bloccato nella `oozie share lib update` fase in cui Amazon EMR effettua il provisioning del cluster. Ti consigliamo di aggiornare i certificati per assicurarti che siano conformi alla verifica del nome host. Tuttavia, se non riesci ad aggiornare i certificati, puoi disabilitare SSL per Oozie impostando la `oozie.https.enabled` proprietà su nella configurazione del cluster. `false`
| Componente | Endpoint | Porta | Meccanismo di crittografia in transito | Supportato dalla versione |
| --- | --- | --- | --- | --- |
| EmbeddedOozieServer | oozie.https.port | 11443 | TLS | emr-7.3.0\$1 |
| EmbeddedOozieServer | oozie.email.smtp.port | 25 | TLS | emr-7.3.0\$1 |
## Hue
Per impostazione predefinita, Hue supporta TLS quando la crittografia in transito è abilitata nei cluster Amazon EMR. [Per ulteriori informazioni sulle configurazioni Hue, consulta Configurare Hue con HTTPS/SSL.](https://gethue.com/configure-hue-with-https-ssl/)
| Componente | Endpoint | Porta | Meccanismo di crittografia in transito | Supportato dalla versione |
| --- | --- | --- | --- | --- |
| Hue | http\$1port | 8888 | TLS | emr-7,4\$1 |
## Livy
Per impostazione predefinita, Livy supporta TLS quando la crittografia in transito è abilitata nei cluster Amazon EMR. [Per ulteriori informazioni sulle configurazioni Livy, consulta Abilitazione di HTTPS con Apache Livy.](https://docs.aws.amazon.com/emr/latest/ReleaseGuide/enabling-https.html)
A partire da Amazon EMR 7.3.0, se utilizzi la crittografia in transito e l'autenticazione Kerberos, non puoi utilizzare il server Livy per le applicazioni Spark che dipendono dal metastore Hive. [Questo problema è stato risolto in [HIVE-16340 e completamente risolto in SPARK-44114 quando](https://issues.apache.org/jira/browse/HIVE-16340) l'applicazione open source Spark può essere aggiornata a Hive 3.](https://issues.apache.org/jira/browse/SPARK-44114) Nel frattempo, puoi risolvere il problema se lo imposti. `hive.metastore.use.SSL` `false` Per ulteriori informazioni, consulta la sezione [Configurazione delle applicazioni](https://docs.aws.amazon.com/emr/latest/ReleaseGuide/emr-configure-apps.html).
Per ulteriori informazioni, consulta [Abilitazione di HTTPS con Apache](https://docs.aws.amazon.com/emr/latest/ReleaseGuide/enabling-https.html) Livy.
| Componente | Endpoint | Porta | Meccanismo di crittografia in transito | Supportato dalla versione |
| --- | --- | --- | --- | --- |
| livy-server | livy.server.port | 8998 | TLS | emr-7.4.0\$1 |
## JupyterEnterpriseGateway
Per impostazione predefinita, Jupyter Enterprise Gateway supporta TLS quando la crittografia in transito è abilitata nei cluster Amazon EMR. [Per ulteriori informazioni sulle configurazioni di Jupyter Enterprise Gateway, consulta Securing Enterprise Gateway Server.](https://jupyter-enterprise-gateway.readthedocs.io/en/v1.2.0/getting-started-security.html#securing-enterprise-gateway-server)
| Componente | Endpoint | Porta | Meccanismo di crittografia in transito | Supportato dalla versione |
| --- | --- | --- | --- | --- |
| jupyter\$1enterprise\$1gateway | c. porta EnterpriseGatewayApp | 9547 | TLS | emr-7,4\$1 |
## JupyterHub
Per impostazione predefinita, JupyterHub supporta TLS quando la crittografia in transito è abilitata nei cluster Amazon EMR. Per ulteriori informazioni, consulta [Attivazione della crittografia SSL](https://jupyterhub.readthedocs.io/en/latest/tutorial/getting-started/security-basics.html#enabling-ssl-encryption) nella documentazione. JupyterHub Non è consigliabile disabilitare la crittografia.
| Componente | Endpoint | Porta | Meccanismo di crittografia in transito | Supportato dalla versione |
| --- | --- | --- | --- | --- |
| jupyter\$1hub | c. porta JupyterHub | 9443 | TLS | emr-5.14.0\$1, emr-6.0\$1, emr-7.0\$1 |
## Zeppelin
Per impostazione predefinita, Zeppelin supporta TLS quando abiliti la crittografia in transito nel tuo cluster EMR. [Per ulteriori informazioni sulle configurazioni Zeppelin, consulta Configurazione SSL nella documentazione di Zeppelin.](https://zeppelin.apache.org/docs/0.11.1/setup/operation/configuration.html#ssl-configuration)
| Componente | Endpoint | Porta | Meccanismo di crittografia in transito | Supportato dalla versione |
| --- | --- | --- | --- | --- |
| zeppelin | zeppelin.server.ssl.porta | 8890 | TLS | 7,3,0\$1 |
## Zookeeper
Amazon EMR si configura `serverCnxnFactory` per abilitare il TLS `org.apache.zookeeper.server.NettyServerCnxnFactory` per il quorum di Zookeeper e la comunicazione con i clienti.
`secureClientPort`specifica la porta che ascolta le connessioni TLS. Se il client non supporta le connessioni TLS a Zookeeper, i client possono connettersi alla porta non sicura 2181 specificata in. `clientPort` Puoi sovrascrivere o disabilitare queste due porte.
Amazon EMR imposta entrambi `sslQuorum` e `admin.forceHttps` per abilitare la comunicazione TLS `true` per il quorum e il server di amministrazione. Se non desideri la crittografia in transito per il quorum e il server di amministrazione, puoi disabilitare tali configurazioni. Ti consigliamo di utilizzare le configurazioni predefinite per la massima sicurezza.
Per ulteriori informazioni, consulta [Crittografia, Autenticazione, Opzioni di autorizzazione](https://zookeeper.apache.org/doc/r3.9.2/zookeeperAdmin.html#sc_authOptions) nella documentazione di Zookeeper.
| Componente | Endpoint | Porta | Meccanismo di crittografia in transito | Supportato dalla versione |
| --- | --- | --- | --- | --- |
| Server Zookeeper | secureClientPort | 2281 | TLS | emr-7,4\$1 |
| Server Zookeeper | Porte Quorum | Ce ne sono 2: I follower usano 2888 per connettersi al leader. Leader Election utilizza 3888 | TLS | emr-7.4.0\$1 |
| Server Zookeeper | Porta admin.server | 8341 | TLS | emr-7,4\$1 |