Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.
# Enkripsi data saat istirahat dan dalam perjalanan dengan Amazon EMR
Enkripsi data membantu mencegah pengguna yang tidak sah membaca data pada klaster dan sistem penyimpanan data terkait. Ini termasuk data yang disimpan ke media persisten, yang dikenal sebagai data *at rest*, dan data yang mungkin dicegat saat perjalanan jaringan, yang dikenal sebagai data *dalam transit*.
Dimulai dengan Amazon EMR versi 4.8.0, Anda dapat menggunakan konfigurasi keamanan Amazon EMR untuk mengonfigurasi pengaturan enkripsi data untuk klaster lebih mudah. Konfigurasi keamanan menawarkan pengaturan untuk mengaktifkan keamanan untuk data dalam transit dan data at rest di volume Amazon Elastic Block Store (Amazon EBS) dan EMRFS di Amazon S3.
Opsional, dimulai dengan Amazon EMR rilis versi 4.1.0 dan versi terbaru, Anda dapat memilih untuk mengonfigurasi enkripsi transparan di HDFS, yang tidak dikonfigurasi menggunakan konfigurasi keamanan. Untuk informasi selengkapnya, lihat [Enkripsi transparan di HDFS di Amazon EMR](https://docs.aws.amazon.com/emr/latest/ReleaseGuide/emr-encryption-tdehdfs.html) di *Panduan Amazon EMR rilis*.
**Topics**
+ [Opsi enkripsi untuk Amazon EMR](emr-data-encryption-options.md)
+ [Enkripsi saat istirahat menggunakan kunci KMS pelanggan untuk layanan EMR WAL](encryption-at-rest-kms.md)
+ [Buat kunci dan sertifikat untuk enkripsi data dengan Amazon EMR](emr-encryption-enable.md)
+ [Memahami enkripsi dalam transit](emr-encryption-support-matrix.md)
# Opsi enkripsi untuk Amazon EMR
Dengan Amazon EMR merilis 4.8.0 dan yang lebih tinggi, Anda dapat menggunakan konfigurasi keamanan untuk menentukan pengaturan untuk mengenkripsi data saat istirahat, data dalam perjalanan, atau keduanya. Bila Anda mengaktifkan enkripsi data yang tersisa, Anda dapat memilih untuk mengenkripsi data EMRFS di Amazon S3, data di disk lokal, atau keduanya. Setiap konfigurasi keamanan yang Anda buat disimpan di Amazon EMR daripada di konfigurasi klaster, sehingga Anda dapat dengan mudah menggunakan kembali konfigurasi untuk menentukan pengaturan enkripsi data setiap kali Anda membuat sebuah klaster. Untuk informasi selengkapnya, lihat [Buat konfigurasi keamanan dengan konsol EMR Amazon atau dengan AWS CLI](emr-create-security-configuration.md).
Diagram berikut menunjukkan pilihan enkripsi data yang berbeda tersedia dengan konfigurasi keamanan.
![\[Ada beberapa opsi enkripsi dalam transit dan istirahat yang tersedia dengan Amazon EMR.\]](http://docs.aws.amazon.com/id_id/emr/latest/ManagementGuide/images/emr-encryption-options.png)
Opsi enkripsi berikut juga tersedia dan tidak dikonfigurasi menggunakan konfigurasi keamanan:
+ Opsional, dengan Amazon EMR versi 4.1.0 dan versi terbaru, Anda dapat memilih untuk mengonfigurasi enkripsi transparan di HDFS. Untuk informasi selengkapnya, lihat [Enkripsi transparan di HDFS di Amazon EMR](https://docs.aws.amazon.com/emr/latest/ReleaseGuide/emr-encryption-tdehdfs.html) di *Panduan Amazon EMR rilis*.
+ Jika Anda menggunakan versi Amazon EMR rilis yang tidak mendukung konfigurasi keamanan, Anda dapat mengonfigurasi enkripsi untuk data EMRFS di Amazon S3 secara manual. Untuk informasi selengkapnya, lihat [Menentukan enkripsi Amazon S3 menggunakan](https://docs.aws.amazon.com/emr/latest/ReleaseGuide/emr-emrfs-encryption.html) properti EMRFS.
+ Jika Anda menggunakan versi Amazon EMR lebih awal dari 5.24.0, volume perangkat asal EBS yang dienkripsi didukung hanya bila menggunakan AMI kustom. Untuk informasi selengkapnya, lihat [Membuat AMI kustom dengan volume perangkat root Amazon EBS terenkripsi](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-custom-ami.html#emr-custom-ami-encrypted) di Panduan Manajemen *EMR* Amazon.
**catatan**
Dimulai dengan Amazon EMR versi 5.24.0, Anda dapat menggunakan opsi konfigurasi keamanan untuk mengenkripsi perangkat root EBS dan volume penyimpanan saat Anda menentukan sebagai penyedia kunci Anda. AWS KMS Untuk informasi selengkapnya, lihat [Enkripsi disk lokal](#emr-encryption-localdisk).
Enkripsi data memerlukan kunci dan sertifikat. Konfigurasi keamanan memberi Anda fleksibilitas untuk memilih dari beberapa opsi, termasuk kunci yang dikelola oleh AWS Key Management Service, kunci yang dikelola oleh Amazon S3, serta kunci dan sertifikat dari penyedia khusus yang Anda berikan. Saat menggunakan AWS KMS sebagai penyedia kunci Anda, biaya berlaku untuk penyimpanan dan penggunaan kunci enkripsi. Untuk informasi lebih lanjut, lihat [AWS KMS harga](https://aws.amazon.com/kms/pricing/).
Sebelum Anda menentukan opsi enkripsi, tentukan kunci dan sistem pengelolaan sertifikat yang ingin Anda gunakan, sehingga Anda dapat terlebih dahulu membuat kunci dan sertifikat atau penyedia kustom yang Anda tentukan sebagai bagian dari pengaturan enkripsi.
## Enkripsi saat istirahat untuk data EMRFS di Amazon S3
Enkripsi Amazon S3 berfungsi dengan objek Amazon EMR File System (EMRFS) yang dibaca dan ditulis ke Amazon S3. Anda menentukan Amazon S3 server-side encryption (SSE) atau client-side encryption (CSE) sebagai **Mode enkripsi default** saat Anda mengaktifkan enkripsi saat istirahat. Secara opsional, Anda dapat menentukan metode enkripsi yang berbeda untuk setiap bucket menggunakan **Per penimpaan enkripsi bucket**. Keamanan Lapisan Pengangkutan (TLS) terlepas dari apakah enkripsi Amazon S3 diaktifkan, Keamanan Lapisan Pengangkutan (TLS) mengenkripsi objek EMRFS dalam transit antara simpul klaster EMR dan Amazon S3. Untuk informasi selengkapnya tentang enkripsi Amazon S3, lihat [Melindungi data menggunakan enkripsi](https://docs.aws.amazon.com/AmazonS3/latest/userguide/UsingEncryption.html) di *Panduan Pengguna Layanan Penyimpanan Sederhana Amazon*.
**catatan**
Saat Anda menggunakan AWS KMS, biaya berlaku untuk penyimpanan dan penggunaan kunci enkripsi. Untuk informasi lebih lanjut, lihat [AWS KMS Harga](https://aws.amazon.com/kms/pricing/).
### Enkripsi sisi server Amazon S3
Semua bucket Amazon S3 memiliki enkripsi yang dikonfigurasi secara default, dan semua objek baru yang diunggah ke bucket S3 secara otomatis dienkripsi saat istirahat, Amazon S3 mengenkripsi data pada tingkat objek saat menulis data ke disk dan mendekripsi data saat diakses. Untuk informasi selengkapnya tentang SSE, lihat [Melindungi data menggunakan enkripsi sisi server di Panduan Pengguna](https://docs.aws.amazon.com/AmazonS3/latest/userguide/serv-side-encryption.html) Layanan *Penyimpanan Sederhana Amazon*.
Anda dapat memilih di antara dua sistem manajemen kunci yang berbeda saat Anda menentukan SSE di Amazon EMR:
+ **SSE-S3** – Amazon S3 mengelola kunci untuk Anda.
+ **SSE-KMS** - Anda menggunakan AWS KMS key untuk mengatur dengan kebijakan yang sesuai untuk Amazon EMR. Untuk informasi selengkapnya tentang persyaratan utama untuk Amazon EMR, lihat [Menggunakan AWS KMS keys untuk](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-encryption-enable.html#emr-awskms-keys) enkripsi.
SSE dengan kunci yang disediakan pelanggan (SSE-C) tidak tersedia untuk digunakan dengan Amazon EMR.
### Enkripsi di sisi klien Amazon S3
Dengan enkripsi sisi klien Amazon S3, enkripsi dan dekripsi Amazon S3 dilakukan di klien EMRFS pada klaster Anda. Objek dienkripsi sebelum diunggah ke Amazon S3 dan didekripsi setelah diunduh. Penyedia yang Anda tentukan menyediakan kunci enkripsi yang digunakan klien. Klien dapat menggunakan kunci yang disediakan oleh AWS KMS (CSE-KMS) atau kelas Java kustom yang menyediakan kunci root sisi klien (CSE-C). Spesifikasi enkripsi sedikit berbeda antara CSE-KMS dan CSE-C, tergantung pada penyedia yang ditentukan dan metadata objek yang didekripsi atau dienkripsi. Untuk informasi selengkapnya tentang perbedaan ini, lihat [Melindungi data menggunakan enkripsi sisi klien](https://docs.aws.amazon.com/AmazonS3/latest/userguide/UsingClientSideEncryption.html) di *Panduan Pengguna Layanan Penyimpanan Sederhana Amazon*.
**catatan**
Amazon S3 CSE hanya memastikan bahwa data EMRFS yang dipertukarkan dengan Amazon S3 dienkripsi; tidak semua data pada volume instans klaster dienkripsi. Lebih lanjut, karena Hue tidak menggunakan EMRFS, objek yang ditulis oleh Peramban Berkas Hue S3 ke Amazon S3 tidak dienkripsi.
## Enkripsi saat istirahat untuk data di Amazon EMR WAL
Saat Anda menyiapkan enkripsi sisi server (SSE) untuk pencatatan tertulis (WAL), Amazon EMR mengenkripsi data saat istirahat. Anda dapat memilih dari dua sistem manajemen kunci yang berbeda ketika Anda menentukan SSE di Amazon EMR:
**SSE-EMR-WAL**
Amazon EMR mengelola kunci untuk Anda. Secara default, Amazon EMR mengenkripsi data yang Anda simpan di Amazon EMR WAL. SSE-EMR-WAL
**SSE-KMS-WAL**
Anda menggunakan AWS KMS kunci untuk menyiapkan kebijakan yang berlaku untuk Amazon EMR WAL. Untuk informasi selengkapnya tentang mengonfigurasi enkripsi saat istirahat untuk EMR WAL menggunakan kunci KMS pelanggan, [lihat Enkripsi saat istirahat menggunakan kunci KMS pelanggan untuk](https://docs.aws.amazon.com/emr/latest/ManagementGuide/encryption-at-rest-kms.html) layanan EMR WAL.
**catatan**
Anda tidak dapat menggunakan kunci Anda sendiri dengan SSE saat Anda mengaktifkan WAL dengan Amazon EMR. Untuk informasi selengkapnya, lihat [Write-ahead logs (WAL) untuk Amazon EMR](https://docs.aws.amazon.com/emr/latest/ReleaseGuide/emr-hbase-wal.html).
## Enkripsi disk lokal
Mekanisme berikut bekerja sama untuk mengenkripsi disk lokal ketika Anda mengaktifkan enkripsi disk lokal menggunakan konfigurasi keamanan Amazon EMR.
### Enkripsi HDFS sumber terbuka
HDFS mempertukarkan data antara instans klaster selama pemrosesan terdistribusi. Hal ini juga membaca dari dan menulis data ke volume penyimpanan dan volume EBS terlampir ke instans. Opsi enkripsi Hadoop sumber terbuka berikut diaktifkan ketika Anda mengaktifkan enkripsi disk lokal:
+ [Secure Hadoop RPC](https://hadoop.apache.org/docs/r2.7.2/hadoop-project-dist/hadoop-common/SecureMode.html#Data_Encryption_on_RPC) diatur ke `Privacy`, yang menggunakan Simple Authentication Security Layer (SASL) sederhana.
+ [Enscriptsi data pada pemindahan data blok HDFS](https://hadoop.apache.org/docs/r2.7.2/hadoop-project-dist/hadoop-common/SecureMode.html#Data_Encryption_on_Block_data_transfer.) diatur ke `true` dan dikonfigurasi untuk menggunakan enkripsi AES 256.
**catatan**
Anda dapat mengaktifkan enkripsi Apache Hadoop tambahan dengan mengaktifkan enkripsi dalam transit. Untuk informasi selengkapnya, lihat [Enkripsi dalam transit](#emr-encryption-intransit). Pengaturan enkripsi ini tidak mengaktifkan enkripsi transparan HDFS, yang dapat Anda konfigurasikan secara manual. Untuk informasi selengkapnya, lihat [Enkripsi transparan di HDFS di Amazon EMR](https://docs.aws.amazon.com/emr/latest/ReleaseGuide/emr-encryption-tdehdfs.html) di *Panduan Amazon EMR rilis*.
### Enkripsi penyimpanan instans
Untuk jenis instans EC2 yang menggunakan NVMe based SSDs sebagai volume penyimpanan instans, NVMe enkripsi digunakan terlepas dari pengaturan enkripsi Amazon EMR. Untuk informasi selengkapnya, lihat [volume NVMe SSD](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ssd-instance-store.html#nvme-ssd-volumes) di *Panduan Pengguna Amazon EC2*. Untuk volume penyimpanan instans lain, Amazon EMR menggunakan LUKS untuk mengenkripsi volume penyimpanan instans ketika enkripsi disk lokal diaktifkan terlepas dari apakah volume EBS dienkripsi menggunakan enkripsi EBS atau LUKS.
### Enkripsi volume EBS
Jika Anda membuat klaster di Wilayah di mana enkripsi Amazon EC2 volume EBS diaktifkan secara default untuk akun Anda, volume EBS dienkripsi meskipun enkripsi disk lokal tidak diaktifkan. Untuk informasi selengkapnya, lihat [Enkripsi secara default](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/EBSEncryption.html#encryption-by-default) di *Panduan Pengguna Amazon EC2*. Dengan enkripsi disk lokal yang diaktifkan dalam konfigurasi keamanan, pengaturan EMR Amazon lebih diutamakan daripada setelan Amazon EC2 untuk instans EC2 cluster encryption-by-default.
Pilihan berikut tersedia untuk mengenkripsi volume EBS menggunakan konfigurasi keamanan:
+ **Enkripsi EBS** – Dimulai dengan Amazon EMR versi 5.24.0, Anda dapat memilih untuk mengaktifkan enkripsi EBS. Opsi enkripsi EBS mengenkripsi volume perangkat asal EBS dan volume penyimpanan terlampir. Opsi enkripsi EBS hanya tersedia ketika Anda menentukan AWS Key Management Service sebagai penyedia kunci Anda. Kami merekomendasikan penggunaan enkripsi EBS.
+ **Enkripsi LUKS** Jika Anda memilih untuk menggunakan enkripsi LUKS untuk volume Amazon EBS, enkripsi LUKS hanya berlaku untuk volume penyimpanan terlampir, bukan ke volume perangkat asal. Untuk informasi selengkapnya tentang enkripsi LUKS, lihat [spesifikasi pada disk LUKS](https://gitlab.com/cryptsetup/cryptsetup/wikis/Specification).
Untuk penyedia kunci Anda, Anda dapat menyiapkan kebijakan AWS KMS key dengan yang sesuai untuk Amazon EMR, atau kelas Java kustom yang menyediakan artefak enkripsi. Saat Anda menggunakan AWS KMS, biaya berlaku untuk penyimpanan dan penggunaan kunci enkripsi. Untuk informasi lebih lanjut, lihat [AWS KMS harga](https://aws.amazon.com/kms/pricing/).
**catatan**
Untuk memeriksa apakah enkripsi EBS diaktifkan pada klaster Anda, dianjurkan bahwa Anda menggunakan `DescribeVolumes` panggilan API. Untuk informasi selengkapnya, lihat [DescribeVolumes](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_DescribeVolumes.html). Menjalankan `lsblk` di klaster hanya akan memeriksa status enkripsi LUKS, bukan enkripsi EBS.
## Enkripsi dalam transit
Beberapa mekanisme enkripsi diaktifkan dengan enkripsi dalam transit. Ini adalah fitur sumber terbuka, khusus aplikasi, dan mungkin berbeda menurut rilis EMR Amazon. Untuk mengaktifkan enkripsi dalam transit, gunakan [Buat konfigurasi keamanan dengan konsol EMR Amazon atau dengan AWS CLI](emr-create-security-configuration.md) di Amazon EMR. Untuk kluster EMR dengan enkripsi in-transit diaktifkan, Amazon EMR secara otomatis mengonfigurasi konfigurasi aplikasi sumber terbuka untuk mengaktifkan enkripsi dalam transit. Untuk kasus penggunaan lanjutan, Anda dapat mengonfigurasi konfigurasi aplikasi sumber terbuka secara langsung untuk mengganti perilaku default di Amazon EMR. Untuk informasi selengkapnya, lihat [matriks dukungan enkripsi dalam transit](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-encryption-support-matrix.html) dan [Konfigurasi aplikasi](https://docs.aws.amazon.com/emr/latest/ReleaseGuide/emr-configure-apps.html).
Lihat berikut ini untuk mempelajari detail lebih spesifik tentang aplikasi sumber terbuka yang relevan dengan enkripsi dalam perjalanan:
+ Saat Anda mengaktifkan enkripsi dalam transit dengan konfigurasi keamanan, Amazon EMR mengaktifkan enkripsi dalam transit untuk semua titik akhir aplikasi sumber terbuka yang mendukung enkripsi dalam transit. Support untuk enkripsi dalam perjalanan untuk titik akhir aplikasi yang berbeda bervariasi menurut versi rilis Amazon EMR. Untuk informasi selengkapnya, lihat [matriks dukungan enkripsi dalam transit](https://docs.aws.amazon.com/).
+ Anda dapat mengganti konfigurasi sumber terbuka, yang memungkinkan Anda melakukan hal berikut:
+ Nonaktifkan verifikasi nama host TLS jika sertifikat TLS yang disediakan pengguna tidak memenuhi persyaratan
+ Nonaktifkan enkripsi dalam perjalanan untuk titik akhir tertentu berdasarkan persyaratan kinerja dan kompatibilitas Anda
+ Kontrol versi TLS dan cipher suite mana yang akan digunakan.
Anda dapat menemukan detail lebih lanjut tentang konfigurasi khusus aplikasi dalam matriks dukungan enkripsi dalam [transit](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-encryption-support-matrix.html)
+ Selain mengaktifkan enkripsi dalam transit dengan konfigurasi keamanan, beberapa saluran komunikasi juga memerlukan konfigurasi keamanan tambahan bagi Anda untuk mengaktifkan enkripsi dalam perjalanan. Misalnya, beberapa titik akhir aplikasi open-source menggunakan Simple Authentication and Security Layer (SASL) untuk enkripsi in-transit, yang mengharuskan otentikasi Kerberos diaktifkan dalam konfigurasi keamanan cluster EMR. Untuk mempelajari lebih lanjut tentang titik akhir ini, lihat matriks [dukungan enkripsi dalam transit](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-encryption-support-matrix.html).
+ Kami menyarankan Anda menggunakan perangkat lunak yang mendukung TLS v1.2 atau lebih tinggi. Amazon EMR di EC2 mengirimkan distribusi Corretto JDK default, yang menentukan versi TLS, cipher suite, dan ukuran kunci yang diizinkan oleh jaringan open-source yang berjalan di Java. Pada saat ini, sebagian besar kerangka kerja sumber terbuka memberlakukan TLS v1.2 atau lebih tinggi untuk Amazon EMR 7.0.0 dan rilis yang lebih tinggi. Ini karena sebagian besar kerangka kerja sumber terbuka berjalan di Java 17 untuk Amazon EMR 7.0.0 dan yang lebih tinggi. Versi rilis Amazon EMR yang lebih lama mungkin mendukung TLS v1.0 dan v1.1 karena mereka menggunakan versi Java yang lebih lama, tetapi Corretto JDK mungkin mengubah versi TLS mana yang didukung Java, yang mungkin memengaruhi rilis EMR Amazon yang ada.
Anda menentukan artefak enkripsi yang digunakan untuk enkripsi dalam transit di salah satu dari dua cara: baik dengan menyediakan file zip sertifikat yang Anda upload ke Amazon S3, atau dengan referensi kelas Java kustom yang menyediakan artefak enkripsi. Untuk informasi selengkapnya, lihat [Memberikan sertifikat untuk mengenkripsi data dalam transit dengan enkripsi Amazon EMR](emr-encryption-enable.md#emr-encryption-certificates).
# Enkripsi saat istirahat menggunakan kunci KMS pelanggan untuk layanan EMR WAL
EMR write-ahead logs (WAL) menyediakan dukungan kunci KMS pelanggan. encryption-at-rest Rincian berikut pada tingkat tinggi bagaimana Amazon EMR WAL terintegrasi dengan: AWS KMS
EMR write-ahead logs (WAL) berinteraksi dengan AWS selama operasi berikut:`CreateWAL`,,,,`AppendEdit`, `ArchiveWALCheckPoint``CompleteWALFlush`, `DeleteWAL` `GetCurrentWALTime``ReplayEdits`, `TrimWAL` melalui secara `EMR_EC2_DefaultRole` default Ketika setiap operasi sebelumnya yang terdaftar dipanggil, EMR WAL `Decrypt` membuat dan melawan kunci KMS. `GenerateDataKey`
## Pertimbangan-pertimbangan
Pertimbangkan hal berikut saat menggunakan enkripsi AWS KMS berbasis untuk EMR WAL:
+ Konfigurasi enkripsi tidak dapat diubah setelah EMR WAL dibuat.
+ Saat Anda menggunakan enkripsi KMS dengan kunci KMS Anda sendiri, kunci harus ada di wilayah yang sama dengan cluster EMR Amazon Anda.
+ Anda bertanggung jawab untuk mempertahankan semua izin IAM yang diperlukan dan disarankan untuk tidak mencabut izin yang diperlukan selama masa pakai WAL. Jika tidak, itu akan menyebabkan skenario kegagalan yang tidak terduga, seperti ketidakmampuan untuk menghapus EMR WAL, karena kunci enkripsi terkait tidak ada.
+ Ada biaya yang terkait dengan penggunaan AWS KMS kunci. Untuk informasi lebih lanjut, lihat [Harga AWS Key Management Service](https://aws.amazon.com/kms/pricing/).
## Izin IAM yang Diperlukan
Untuk menggunakan kunci KMS pelanggan Anda untuk mengenkripsi EMR WAL saat istirahat, Anda perlu memastikan Anda menetapkan izin yang tepat untuk peran klien EMR WAL dan prinsip layanan EMR WAL. `emrwal.amazonaws.com`
### Izin untuk peran klien EMR WAL
Di bawah ini adalah kebijakan IAM yang diperlukan untuk peran klien EMR WAL:
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"kms:Decrypt",
"kms:GenerateDataKey*"
],
"Resource": [
"*"
],
"Sid": "AllowKMSDecrypt"
}
]
}
```
------
Klien EMR WAL pada EMR cluster akan digunakan secara default. `EMR_EC2_DefaultRole` Jika Anda menggunakan peran yang berbeda untuk profil instance di kluster EMR, pastikan setiap peran memiliki izin yang sesuai.
Untuk informasi selengkapnya tentang mengelola kebijakan peran, lihat [Menambahkan dan menghapus izin identitas IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_manage-attach-detach.html).
### Izin untuk kebijakan kunci KMS
Anda perlu memberikan peran klien EMR WAL dan layanan EMR WAL `Decrypt` dan `GenerateDataKey*` izin dalam kebijakan KMS Anda. Untuk informasi lebih lanjut tentang manajemen kebijakan utama, lihat [kebijakan kunci 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"
}
]
}
```
------
Peran yang ditentukan dalam cuplikan dapat berubah jika Anda mengubah peran default.
## Memantau interaksi Amazon EMR WAL dengan AWS KMS
### Konteks enkripsi Amazon EMR WAL
Konteks enkripsi adalah sekumpulan pasangan kunci-nilai yang berisi data non-rahasia arbitrer. Ketika Anda menyertakan konteks enkripsi dalam permintaan untuk mengenkripsi data, secara AWS KMS kriptografis mengikat konteks enkripsi ke data terenkripsi. Untuk mendekripsi data, Anda harus meneruskan konteks enkripsi yang sama.
Dalam permintaannya [GenerateDataKey](https://docs.aws.amazon.com/kms/latest/APIReference/API_GenerateDataKey.html)dan [Dekripsi](https://docs.aws.amazon.com/kms/latest/APIReference/API_Decrypt.html) ke, AWS KMS Amazon EMR WAL menggunakan konteks enkripsi dengan satu pasangan nama-nilai yang mengidentifikasi nama EMR WAL.
```
"encryptionContext": {
"aws:emrwal:walname": "111222333444555-testworkspace-emrwalclustertest-emrwaltestwalname"
}
```
Anda dapat menggunakan konteks enkripsi untuk mengidentifikasi operasi kriptografi ini dalam catatan audit dan log, seperti AWS CloudTrail dan [Amazon CloudWatch Logs](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-user-guide.html), dan sebagai syarat untuk otorisasi dalam kebijakan dan hibah.
# Buat kunci dan sertifikat untuk enkripsi data dengan Amazon EMR
Sebelum Anda menentukan opsi enkripsi menggunakan konfigurasi keamanan, putuskan penyedia yang ingin Anda gunakan untuk kunci dan artefak enkripsi. Misalnya, Anda dapat menggunakan AWS KMS atau penyedia kustom yang Anda buat. Selanjutnya, membuat kunci atau penyedia kunci seperti yang dijelaskan di bagian ini.
## Menyediakan kunci untuk mengenkripsi data saat istirahat
Anda dapat menggunakan AWS Key Management Service (AWS KMS) atau penyedia kunci khusus untuk enkripsi data saat istirahat di Amazon EMR. Saat Anda menggunakan AWS KMS, biaya berlaku untuk penyimpanan dan penggunaan kunci enkripsi. Untuk informasi selengkapnya, lihat [harga AWS KMS](https://aws.amazon.com/kms/pricing/).
Topik ini memberikan detail kebijakan utama untuk kunci KMS yang akan digunakan dengan Amazon EMR, serta pedoman dan contoh kode untuk menulis kelas penyedia kunci khusus untuk enkripsi Amazon S3. Untuk informasi selengkapnya tentang pembuatan kunci, lihat [Membuat Kunci](https://docs.aws.amazon.com/kms/latest/developerguide/create-keys.html) di *AWS Key Management Service Panduan Developer*.
### Menggunakan AWS KMS keys untuk enkripsi
Kunci AWS KMS enkripsi harus dibuat di Wilayah yang sama dengan instans cluster EMR Amazon Anda dan bucket Amazon S3 yang digunakan dengan EMRFS. Jika kunci yang Anda tentukan berada di akun yang berbeda dari yang Anda gunakan untuk mengkonfigurasi klaster, Anda harus menentukan kunci menggunakan ARN-nya.
Peran untuk profil instans Amazon EC2 harus memiliki izin untuk menggunakan kunci KMS yang Anda tentukan. Peran default untuk profil instans di Amazon EMR adalah `EMR_EC2_DefaultRole`. Jika Anda menggunakan peran yang berbeda untuk profil instans, atau Anda menggunakan IAM role untuk permintaan EMRFS ke Amazon S3, pastikan bahwa setiap peran ditambahkan sebagai pengguna kunci sebagaimana mestinya. Ini memberikan izin peran untuk menggunakan kunci KMS. Untuk informasi selengkapnya, lihat [Menggunakan Kebijakan Utama](https://docs.aws.amazon.com/kms/latest/developerguide/key-policies.html#key-policy-default-allow-users) di *Panduan AWS Key Management Service Pengembang* dan [Mengonfigurasi peran IAM untuk permintaan EMRFS ke Amazon S3](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-emrfs-iam-roles.html).
Anda dapat menggunakan Konsol Manajemen AWS untuk menambahkan profil instans atau profil instans EC2 ke daftar pengguna utama untuk kunci KMS yang ditentukan, atau Anda dapat menggunakan AWS CLI atau AWS SDK untuk melampirkan kebijakan kunci yang sesuai.
Perhatikan bahwa Amazon EMR hanya mendukung kunci KMS [simetris](https://docs.aws.amazon.com/kms/latest/developerguide/concepts.html#symmetric-cmks). Anda tidak dapat menggunakan [kunci KMS asimetris](https://docs.aws.amazon.com/kms/latest/developerguide/symmetric-asymmetric.html#asymmetric-cmks) untuk mengenkripsi data saat istirahat di cluster EMR Amazon. Untuk bantuan menentukan apakah kunci KMS simetris atau asimetris, lihat [Mengidentifikasi kunci KMS simetris dan asimetris](https://docs.aws.amazon.com/kms/latest/developerguide/find-symm-asymm.html).
Prosedur di bawah ini menjelaskan cara menambahkan profil instans EMR Amazon default, `EMR_EC2_DefaultRole` sebagai *pengguna utama* yang menggunakan. Konsol Manajemen AWS Ini mengasumsikan bahwa Anda telah membuat kunci KMS. Untuk membuat kunci KMS baru, lihat [Membuat Kunci](https://docs.aws.amazon.com/kms/latest/developerguide/create-keys.html) di *Panduan AWS Key Management Service Pengembang*.
**Untuk menambahkan profil instans EC2 untuk Amazon EMR ke daftar pengguna kunci enkripsi**
1. Masuk ke Konsol Manajemen AWS dan buka konsol AWS Key Management Service (AWS KMS) di [https://console.aws.amazon.com/kms](https://console.aws.amazon.com/kms).
1. Untuk mengubah Wilayah AWS, gunakan pemilih Wilayah di sudut kanan atas halaman.
1. Pilih alias tombol KMS untuk memodifikasi.
1. Pada halaman detail kunci di bawah **Pengguna Kunci**, pilih **Tambahkan**.
1. Di kotak dialog **Tambah pengguna kunci**, pilih peran yang sesuai. Nama peran default adalah `EMR_EC2_DefaultRole`.
1. Pilih **Tambahkan**.
### Mengaktifkan enkripsi EBS dengan memberikan izin tambahan untuk kunci KMS
Dimulai dengan Amazon EMR versi 5.24.0, Anda dapat mengenkripsi perangkat root EBS dan volume penyimpanan dengan menggunakan opsi konfigurasi keamanan. Untuk mengaktifkan opsi tersebut, Anda harus menentukan AWS KMS sebagai penyedia kunci Anda. Selain itu, Anda harus memberikan peran layanan `EMR_DefaultRole` dengan izin untuk menggunakan AWS KMS key yang Anda tentukan.
Anda dapat menggunakan Konsol Manajemen AWS untuk menambahkan peran layanan ke daftar pengguna kunci untuk kunci KMS yang ditentukan, atau Anda dapat menggunakan atau AWS SDK untuk melampirkan kebijakan kunci yang sesuai. AWS CLI
Prosedur berikut menjelaskan cara menggunakan Konsol Manajemen AWS untuk menambahkan peran layanan EMR Amazon default `EMR_DefaultRole` sebagai pengguna *utama*. Ini mengasumsikan bahwa Anda telah membuat kunci KMS. Untuk membuat kunci KMS baru, lihat [Membuat kunci](https://docs.aws.amazon.com/kms/latest/developerguide/create-keys.html) di *Panduan AWS Key Management Service Pengembang*.
**Untuk menambahkan peran layanan EMR Amazon ke daftar pengguna kunci enkripsi**
1. Masuk ke Konsol Manajemen AWS dan buka konsol AWS Key Management Service (AWS KMS) di [https://console.aws.amazon.com/kms](https://console.aws.amazon.com/kms).
1. Untuk mengubah Wilayah AWS, gunakan pemilih Wilayah di sudut kanan atas halaman.
1. Pilih **Kunci terkelola pelanggan** di bilah sisi kiri.
1. Pilih alias tombol KMS untuk memodifikasi.
1. Pada halaman detail kunci di bawah **Pengguna Kunci**, pilih **Tambahkan**.
1. Di bagian **Tambah pengguna kunci**, pilih peran yang sesuai. Nama peran layanan default untuk Amazon EMR adalah. `EMR_DefaultRole`
1. Memilih **Tambahkan**.
### Membuat penyedia kunci kustom
Bila menggunakan konfigurasi keamanan, Anda harus menentukan nama kelas penyedia yang berbeda untuk enkripsi disk lokal dan enkripsi Amazon S3. Persyaratan untuk penyedia kunci khusus bergantung pada apakah Anda menggunakan enkripsi disk lokal dan enkripsi Amazon S3, serta versi rilis Amazon EMR.
Bergantung pada jenis enkripsi yang Anda gunakan saat membuat penyedia kunci khusus, aplikasi juga harus menerapkan EncryptionMaterialsProvider antarmuka yang berbeda. Kedua antarmuka tersedia di AWS SDK for Java versi 1.11.0 dan yang lebih baru.
+ [Untuk mengimplementasikan enkripsi Amazon S3, gunakan com.amazonaws.services.s3.model. EncryptionMaterialsProvider ](https://docs.aws.amazon.com/AWSJavaSDK/latest/javadoc/com/amazonaws/services/s3/model/EncryptionMaterialsProvider.html)antarmuka.
+ Untuk mengimplementasikan enkripsi disk lokal, gunakan [com.amazonaws.services.elasticmapreduce.spi.security. EncryptionMaterialsProvider ](https://docs.aws.amazon.com/AWSJavaSDK/latest/javadoc/com/amazonaws/services/elasticmapreduce/spi/security/EncryptionMaterialsProvider.html)antarmuka.
Anda dapat menggunakan strategi apa pun untuk menyediakan materi enkripsi untuk implementasi. Misalnya, Anda dapat memilih untuk menyediakan materi enkripsi statis atau mengintegrasikan dengan sistem manajemen kunci yang lebih kompleks.
Jika Anda menggunakan enkripsi Amazon S3, Anda harus menggunakan algoritme enkripsi **AES/GCM/NoPadding**untuk materi enkripsi khusus.
Jika Anda menggunakan enkripsi disk lokal, algoritme enkripsi yang digunakan untuk bahan enkripsi khusus bervariasi menurut rilis EMR. Untuk Amazon EMR 7.0.0 dan yang lebih rendah, Anda harus menggunakan. **AES/GCM/NoPadding** **Untuk Amazon EMR 7.1.0 dan yang lebih tinggi, Anda harus menggunakan AES.**
EncryptionMaterialsProvider Kelas mendapatkan materi enkripsi dengan konteks enkripsi. Amazon EMR mengisi informasi konteks enkripsi pada waktu aktif untuk membantu pemanggil dalam menentukan materi enkripsi yang benar untuk dikembalikan.
**Example Contoh: Menggunakan penyedia kunci khusus untuk enkripsi Amazon S3 dengan EMRFS**
Saat Amazon EMR mengambil materi enkripsi dari EncryptionMaterialsProvider kelas untuk melakukan enkripsi, EMRFS secara opsional mengisi argumen MaterialsDescription dengan dua bidang: URI Amazon S3 untuk objek dan cluster, yang dapat digunakan oleh kelas untuk mengembalikan materi enkripsi secara JobFlowId selektif. EncryptionMaterialsProvider
Misalnya, penyedia dapat mengembalikan kunci yang berbeda untuk prefiks URI Amazon S3 yang berbeda. Ini adalah deskripsi materi enkripsi yang dikembalikan yang pada akhirnya disimpan dengan objek Amazon S3 bukan nilai materialsDescription yang dihasilkan oleh EMRFS dan diteruskan ke penyedia. Saat mendekripsi objek Amazon S3, deskripsi bahan enkripsi diteruskan ke EncryptionMaterialsProvider kelas, sehingga dapat, sekali lagi, secara selektif mengembalikan kunci yang cocok untuk mendekripsi objek.
Implementasi EncryptionMaterialsProvider referensi disediakan di bawah ini. Penyedia kustom lain [EMRFSRSAEncryptionMaterialsProvider](https://github.com/awslabs/emr-sample-apps/tree/master/emrfs-plugins/EMRFSRSAEncryptionMaterialsProvider),, tersedia dari 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;
}
}
```
## Memberikan sertifikat untuk mengenkripsi data dalam transit dengan enkripsi Amazon EMR
Dengan Amazon EMR rilis versi 4.8.0 atau yang lebih baru, Anda memiliki dua pilihan untuk menentukan artefak untuk mengenkripsi data dalam transit menggunakan konfigurasi keamanan:
+ Anda dapat secara manual membuat sertifikat PEM, termasuk mereka di file .zip, dan kemudian referensi file .zip di Amazon S3.
+ Anda dapat menerapkan penyedia sertifikat kustom sebagai kelas Java. Anda menentukan file JAR dari aplikasi di Amazon S3, dan lalu memberikan nama kelas lengkap dari penyedia seperti yang dinyatakan di aplikasi. Kelas harus mengimplementasikan antarmuka [TLSArtifactsProvider](https://docs.aws.amazon.com/AWSJavaSDK/latest/javadoc/com/amazonaws/services/elasticmapreduce/spi/security/TLSArtifactsProvider.html) yang tersedia dimulai dengan AWS SDK untuk Java versi 1.11.0.
Amazon EMR secara otomatis mengunduh artefak ke setiap simpul di klaster dan versi terbaru menggunakannya untuk menerapkan fitur enkripsi dalam transit sumber daya terbuka. Untuk informasi lebih lanjut tentang menambahkan opsi, lihat [Enkripsi dalam transit](emr-data-encryption-options.md#emr-encryption-intransit).
### Menggunakan sertifikat PEM
Ketika Anda menetapkan file .zip untuk enkripsi dalam transit, konfigurasi keamanan mengharapkan file PEM di file .zip harus diberi nama persis seperti yang muncul di bawah ini:
**Sertifikat enkripsi dalam transit**
| Nama file | Diperlukan/opsional | Detail |
| --- | --- | --- |
| privateKey.pem | Diperlukan | Kunci privat |
| certificateChain.pem | Diperlukan | Rantai sertifikat |
| trustedCertificates.pem | Opsional | Sebaiknya Anda memberikan sertifikat yang tidak ditandatangani oleh otoritas sertifikasi root tepercaya (CA) default Java atau CA perantara yang dapat menautkan ke root CA tepercaya default Java. Kami tidak menyarankan bahwa Anda menggunakan public CAs saat Anda menggunakan sertifikat wildcard atau saat Anda menonaktifkan verifikasi nama host. |
Anda mungkin ingin mengonfigurasi file PEM kunci privat menjadi sertifikat wildcard yang mengizinkan akses ke domain Amazon VPC di mana instans klaster Anda berada. Misalnya, jika klaster Anda berada di us-east-1 (N. Virginia), Anda bisa menentukan nama umum di konfigurasi sertifikat yang mengizinkan akses ke klaster dengan menentukan `CN=*.ec2.internal` di definisi subjek sertifikat. Jika klaster Anda berada di us-west-2 (Oregon), Anda dapat menentukan `CN=*.us-west-2.compute.internal`.
Jika file PEM yang disediakan dalam artefak enkripsi tidak memiliki karakter wildcard untuk domain dalam nama umum, Anda harus mengubah nilai ke. `hadoop.ssl.hostname.verifier` `ALLOW_ALL` Untuk melakukannya di Amazon EMR rilis 7.3.0 dan yang lebih tinggi, tambahkan `core-site` klasifikasi saat Anda mengirimkan konfigurasi ke klaster. Dalam rilis yang lebih rendah dari 7.3.0, tambahkan konfigurasi `"hadoop.ssl.hostname.verifier": "ALLOW_ALL"` langsung ke `core-site.xml` file. Perubahan ini diperlukan karena verifier nama host default memerlukan nama host tanpa wildcard karena semua host di cluster menggunakannya. Untuk informasi selengkapnya tentang konfigurasi klaster EMR dalam VPC Amazon, lihat. [Konfigurasikan jaringan di VPC untuk Amazon EMR](emr-plan-vpc-subnet.md)
Contoh berikut menunjukkan cara menggunakan [OpenSSL](https://www.openssl.org/) untuk menghasilkan sertifikat X.509 yang ditandatangani sendiri dengan kunci pribadi RSA 2048-bit. Kunci ini memungkinkan akses ke instance cluster Amazon EMR penerbit di `us-west-2` Wilayah (Oregon) sebagaimana ditentukan oleh nama domain sebagai `*.us-west-2.compute.internal` nama umum.
Item subjek opsional lainnya, seperti negara (C), negara bagian (S), dan Lokal (L), ditentukan. Karena sertifikat yang bertandatangan sendiri dibuat, perintah kedua di contoh salinan `certificateChain.pem` file ke `trustedCertificates.pem` file. Perintah ketiga menggunakan `zip` untuk membuat file `my-certs.zip` yang berisi sertifikat.
**penting**
Contoh ini hanya proof-of-concept demonstrasi. Menggunakan sertifikat yang bertandatangan sendiri tidak direkomendasikan dan menimbulkan risiko keamanan potensial. Untuk sistem produksi, gunakan otoritas sertifikasi (CA) untuk menerbitkan sertifikat.
```
$ 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
```
# Memahami enkripsi dalam transit
Anda dapat mengonfigurasi klaster EMR untuk menjalankan kerangka kerja sumber terbuka seperti [Apache Spark, Apache](https://aws.amazon.com/emr/features/spark/) [Hive](https://aws.amazon.com/emr/features/hive/), dan [Presto](https://aws.amazon.com/emr/features/presto/). masing-masing kerangka kerja sumber terbuka ini memiliki serangkaian proses yang berjalan pada instance EC2 dari sebuah cluster. Masing-masing proses ini dapat meng-host titik akhir jaringan untuk komunikasi jaringan.
Jika enkripsi dalam transit diaktifkan pada kluster EMR, titik akhir jaringan yang berbeda menggunakan mekanisme enkripsi yang berbeda. Lihat bagian berikut untuk mempelajari lebih lanjut tentang titik akhir jaringan kerangka kerja sumber terbuka tertentu yang didukung dengan enkripsi dalam perjalanan, mekanisme enkripsi terkait, dan rilis Amazon EMR yang menambahkan dukungan. Setiap aplikasi open-source mungkin juga memiliki praktik terbaik dan konfigurasi kerangka kerja sumber terbuka yang berbeda yang dapat Anda ubah.
Untuk cakupan enkripsi paling dalam transit, kami menyarankan Anda mengaktifkan enkripsi dalam transit dan Kerberos. Jika Anda hanya mengaktifkan enkripsi dalam transit, maka enkripsi dalam transit hanya akan tersedia untuk titik akhir jaringan yang mendukung TLS. Kerberos diperlukan karena beberapa titik akhir jaringan kerangka open source menggunakan Simple Authentication and Security Layer (SASL) untuk enkripsi in-transit.
Perhatikan bahwa kerangka kerja sumber terbuka apa pun yang tidak didukung dalam rilis Amazon EMR 7.xx tidak disertakan.
## Spark
Saat Anda mengaktifkan enkripsi dalam transit dalam konfigurasi keamanan, secara otomatis `spark.authenticate` diatur ke `true` dan menggunakan enkripsi berbasis AES untuk koneksi RPC.
Dimulai dengan Amazon EMR 7.3.0, jika Anda menggunakan enkripsi dalam transit dan otentikasi Kerberos, Anda tidak dapat menggunakan aplikasi Spark yang bergantung pada metastore Hive. [Hive 3 memperbaiki masalah ini di HIVE-16340.](https://issues.apache.org/jira/browse/HIVE-16340) [HIVE-44114](https://issues.apache.org/jira/browse/SPARK-44114) sepenuhnya menyelesaikan masalah ini ketika Spark open-source dapat meningkatkan ke Hive 3. Sementara itu, Anda dapat mengatur `hive.metastore.use.SSL` `false` untuk mengatasi masalah ini. Untuk informasi selengkapnya, lihat [Mengkonfigurasi aplikasi](https://docs.aws.amazon.com/emr/latest/ReleaseGuide/emr-configure-apps.html).
Untuk informasi selengkapnya, lihat [Keamanan Spark](https://spark.apache.org/docs/latest/security) di dokumentasi Apache Spark.
| Komponen | Titik akhir | Port | Mekanisme Enkripsi Dalam Transit | Didukung dari Rilis |
| --- | --- | --- | --- | --- |
| Spark History Server | spark.ssl.history.port | 18480 | TLS | emr-5.3.0 \$1, emr-6.0 \$1, emr-7.0 \$1 |
| Spark UI | spark.ui.port | 4440 | TLS | emr-5.3.0 \$1, emr-6.0 \$1, emr-7.0 \$1 |
| Spark Driver | spark.driver.port | Dinamis | Enkripsi berbasis Spark AES | emr-4.8.0 \$1, emr-5.0.0\$1, emr-6.0 \$1, emr-7.0.0\$1 |
| Pelaksana Spark | Port Pelaksana (tidak ada konfigurasi bernama) | Dinamis | Enkripsi berbasis Spark AES | emr-4.8.0 \$1, emr-5.0.0\$1, emr-6.0 \$1, emr-7.0.0\$1 |
| BENANG NodeManager | spark.shuffle.service.port 1 | 7337 | Enkripsi berbasis Spark AES | emr-4.8.0 \$1, emr-5.0.0\$1, emr-6.0 \$1, emr-7.0.0\$1 |
1 `spark.shuffle.service.port` di-host di YARN NodeManager tetapi hanya digunakan oleh Apache Spark.
**Masalah yang diketahui**
Pada `spark.yarn.historyServer.address` konfigurasi cluster yang diaktifkan intransit saat ini menggunakan port`18080`, yang mencegah akses ke UI aplikasi spark menggunakan URL pelacakan YARN. **Mempengaruhi Versi:** EMR - 7.3.0 ke EMR - 7.9.0.
Gunakan solusi berikut:
1. Ubah `spark.yarn.historyServer.address` konfigurasi `/etc/spark/conf/spark-defaults.conf` untuk menggunakan nomor `HTTPS` port `18480` pada cluster yang sedang berjalan.
1. Ini juga dapat diberikan dalam penggantian konfigurasi saat meluncurkan cluster.
Contoh konfigurasi:
```
[
{
"Classification": "spark-defaults",
"Properties": {
"spark.yarn.historyServer.address": "${hadoopconf-yarn.resourcemanager.hostname}:18480"
}
}
]
```
## BENANG Hadoop
[Secure Hadoop RPC](https://hadoop.apache.org/docs/r2.7.2/hadoop-project-dist/hadoop-common/SecureMode.html#Data_Encryption_on_RPC) diatur ke `privacy` dan menggunakan enkripsi in-transit berbasis SASL. Ini mengharuskan otentikasi Kerberos diaktifkan dalam konfigurasi keamanan. Jika Anda tidak ingin enkripsi dalam transit untuk Hadoop RPC, konfigurasikan. `hadoop.rpc.protection = authentication` Kami menyarankan Anda menggunakan konfigurasi default untuk keamanan maksimum.
Jika sertifikat TLS Anda tidak dapat memenuhi persyaratan verifikasi nama host TLS, Anda dapat mengonfigurasinya. `hadoop.ssl.hostname.verifier = ALLOW_ALL` Kami menyarankan Anda menggunakan konfigurasi default`hadoop.ssl.hostname.verifier = DEFAULT`, yang memberlakukan verifikasi nama host TLS.
Untuk menonaktifkan HTTPS untuk titik akhir aplikasi web YARN, konfigurasikan`yarn.http.policy = HTTP_ONLY`. Ini membuatnya sehingga lalu lintas ke titik akhir ini tetap tidak terenkripsi. Kami menyarankan Anda menggunakan konfigurasi default untuk keamanan maksimum.
Untuk informasi selengkapnya, lihat [Hadoop dalam mode aman di dokumentasi](https://hadoop.apache.org/docs/r2.7.2/hadoop-project-dist/hadoop-common/SecureMode.html) Apache Hadoop.
| Komponen | Titik akhir | Port | Mekanisme Enkripsi Dalam Transit | Didukung dari Rilis |
| --- | --- | --- | --- | --- |
| ResourceManager | yarn.resourcemanager.webapp.address | 8088 | TLS | emr-7.3.0\$1 |
| ResourceManager | yarn.resourcemanager.resource-tracker.address | 8025 | SASL\$1Kerberos | emr-4.8.0 \$1, emr-5.0.0\$1, emr-6.0 \$1, emr-7.0.0\$1 |
| ResourceManager | yarn.resourcemanager.scheduler.address | 8030 | SASL\$1Kerberos | emr-4.8.0 \$1, emr-5.0.0\$1, emr-6.0 \$1, emr-7.0.0\$1 |
| ResourceManager | yarn.resourcemanager.address | 8032 | SASL\$1Kerberos | emr-4.8.0 \$1, emr-5.0.0\$1, emr-6.0 \$1, emr-7.0.0\$1 |
| ResourceManager | yarn.resourcemanager.admin.address | 8033 | SASL\$1Kerberos | emr-4.8.0 \$1, emr-5.0.0\$1, emr-6.0 \$1, emr-7.0.0\$1 |
| TimelineServer | yarn.timeline-service.address | 10200 | SASL\$1Kerberos | emr-4.8.0 \$1, emr-5.0.0\$1, emr-6.0 \$1, emr-7.0.0\$1 |
| TimelineServer | yarn.timeline-service.webapp.address | 8188 | TLS | emr-7.3.0\$1 |
| WebApplicationProxy | yarn.web-proxy.address | 20888 | SASL\$1Kerberos | emr-4.8.0 \$1, emr-5.0.0\$1, emr-6.0 \$1, emr-7.0.0\$1 |
| NodeManager | yarn.nodemanager.address | 8041 | SASL\$1Kerberos | emr-4.8.0 \$1, emr-5.0.0\$1, emr-6.0 \$1, emr-7.0.0\$1 |
| NodeManager | yarn.nodemanager.localizer.address | 8040 | SASL\$1Kerberos | emr-4.8.0 \$1, emr-5.0.0\$1, emr-6.0 \$1, emr-7.0.0\$1 |
| NodeManager | yarn.nodemanager.webapp.address | 8044 | TLS | emr-7.3.0\$1 |
| NodeManager | mapreduce.shuffle.port 1 | 13562 | TLS | emr-4.8.0 \$1, emr-5.0.0\$1, emr-6.0 \$1, emr-7.0.0\$1 |
| NodeManager | spark.shuffle.service.port 2 | 7337 | Enkripsi berbasis Spark AES | emr-4.8.0 \$1, emr-5.0.0\$1, emr-6.0 \$1, emr-7.0.0\$1 |
1 `mapreduce.shuffle.port` di-host di YARN NodeManager tetapi hanya digunakan oleh Hadoop MapReduce.
2 `spark.shuffle.service.port` di-host di YARN NodeManager tetapi hanya digunakan oleh Apache Spark.
**Masalah yang diketahui**
`yarn.log.server.url`Konfigurasi di saat ini menggunakan HTTP dengan port 19888, yang mencegah akses ke log aplikasi dari UI Resource Manager. **Mempengaruhi Versi:** EMR - 7.3.0 ke EMR - 7.8.0.
Gunakan solusi berikut:
1. Ubah `yarn.log.server.url` konfigurasi `yarn-site.xml` untuk menggunakan `HTTPS` protokol dan nomor port`19890`.
1. Mulai ulang Manajer Sumber Daya YARN:`sudo systemctl restart hadoop-yarn-resourcemanager.service`.
## Hadoop HDFS
Node nama Hadoop, simpul data, dan simpul jurnal semuanya mendukung TLS secara default jika enkripsi dalam transit diaktifkan di kluster EMR.
[Secure Hadoop RPC](https://hadoop.apache.org/docs/r2.7.2/hadoop-project-dist/hadoop-common/SecureMode.html#Data_Encryption_on_RPC) diatur ke `privacy` dan menggunakan enkripsi in-transit berbasis SASL. Ini mengharuskan otentikasi Kerberos diaktifkan dalam konfigurasi keamanan.
Kami menyarankan agar Anda tidak mengubah port default yang digunakan untuk titik akhir HTTPS.
[Enkripsi data pada transfer blok HDFS menggunakan](https://hadoop.apache.org/docs/r2.7.2/hadoop-project-dist/hadoop-common/SecureMode.html#Data_Encryption_on_Block_data_transfer.) AES 256 dan mengharuskan enkripsi saat istirahat diaktifkan dalam konfigurasi keamanan.
Untuk informasi selengkapnya, lihat [Hadoop dalam mode aman di dokumentasi](https://hadoop.apache.org/docs/r2.7.2/hadoop-project-dist/hadoop-common/SecureMode.html) Apache Hadoop.
| Komponen | Titik akhir | Port | Mekanisme Enkripsi Dalam Transit | Didukung dari Rilis |
| --- | --- | --- | --- | --- |
| Namenode | dfs.namenode.https-alamat | 9871 | TLS | emr-4.8.0 \$1, emr-5.0.0\$1, emr-6.0 \$1, emr-7.0.0\$1 |
| Namenode | dfs.namenode.rpc-address | 8020 | SASL\$1Kerberos | emr-4.8.0 \$1, emr-5.0.0\$1, emr-6.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 \$1, emr-7.0.0\$1 |
| Datanode | dfs.datanode.address | 9866 | SASL\$1Kerberos | emr-4.8.0 \$1, emr-5.0.0\$1, emr-6.0 \$1, emr-7.0.0\$1 |
| Node Jurnal | dfs.journalnode.https-alamat | 8481 | TLS | emr-4.8.0 \$1, emr-5.0.0\$1, emr-6.0 \$1, emr-7.0.0\$1 |
| Node Jurnal | dfs.journalnode.rpc-address | 8485 | SASL\$1Kerberos | emr-4.8.0 \$1, emr-5.0.0\$1, emr-6.0 \$1, emr-7.0.0\$1 |
| DFSZKFailoverPengontrol | dfs.ha.zkfc.port | 8019 | Tidak ada | TLS untuk ZKFC hanya didukung di Hadoop 3.4.0. Lihat [HADOOP-18919](https://issues.apache.org/jira/browse/HADOOP-18919) untuk informasi lebih lanjut. Amazon EMR rilis 7.1.0 saat ini ada di Hadoop 3.3.6. Rilis EMR Amazon yang lebih tinggi ada di Hadoop 3.4.0 di masa depan |
## Hadoop MapReduce
Hadoop MapReduce, server riwayat pekerjaan, dan MapReduce shuffle semua dukungan TLS secara default ketika enkripsi dalam transit diaktifkan di kluster EMR.
Shuffle [ MapReduce terenkripsi Hadoop](https://hadoop.apache.org/docs/r2.7.1/hadoop-mapreduce-client/hadoop-mapreduce-client-core/EncryptedShuffle.html) menggunakan TLS.
Kami menyarankan Anda untuk tidak mengubah port default untuk titik akhir HTTPS.
Untuk informasi selengkapnya, lihat [Hadoop dalam mode aman di dokumentasi](https://hadoop.apache.org/docs/r2.7.2/hadoop-project-dist/hadoop-common/SecureMode.html) Apache Hadoop.
| Komponen | Titik akhir | Port | Mekanisme Enkripsi Dalam Transit | Didukung dari Rilis |
| --- | --- | --- | --- | --- |
| JobHistoryServer | mapreduce.jobhistory.webapp.https.address | 19890 | TLS | emr-7.3.0\$1 |
| BENANG NodeManager | mapreduce.shuffle.port 1 | 13562 | TLS | emr-4.8.0 \$1, emr-5.0.0\$1, emr-6.0 \$1, emr-7.0.0\$1 |
1 `mapreduce.shuffle.port` di-host di YARN NodeManager tetapi hanya digunakan oleh Hadoop MapReduce.
## Presto
[Di Amazon EMR merilis 5.6.0 dan yang lebih tinggi, komunikasi internal antara koordinator Presto dan pekerja menggunakan TLS Amazon EMR menyiapkan semua konfigurasi yang diperlukan untuk mengaktifkan komunikasi internal yang aman di Presto.](https://prestodb.io/docs/current/security/internal-communication.html)
Jika konektor menggunakan metastore Hive sebagai penyimpanan metadata, komunikasi antara komunikator dan metastore Hive juga dienkripsi dengan TLS.
| Komponen | Titik akhir | Port | Mekanisme Enkripsi Dalam Transit | Didukung dari Rilis |
| --- | --- | --- | --- | --- |
| Koordinator Presto | http-server.https.port | 8446 | TLS | emr-5.6.0 \$1, emr-6.0 \$1, emr-7.0 \$1 |
| Pekerja Presto | http-server.https.port | 8446 | TLS | emr-5.6.0 \$1, emr-6.0 \$1, emr-7.0 \$1 |
## Trino
[Di Amazon EMR merilis 6.1.0 dan yang lebih tinggi, komunikasi internal antara koordinator Presto dan pekerja menggunakan TLS Amazon EMR menyiapkan semua konfigurasi yang diperlukan untuk memungkinkan komunikasi internal yang aman di Trino.](https://trino.io/docs/current/security/internal-communication.html)
Jika konektor menggunakan metastore Hive sebagai penyimpanan metadata, komunikasi antara komunikator dan metastore Hive juga dienkripsi dengan TLS.
| Komponen | Titik akhir | Port | Mekanisme Enkripsi Dalam Transit | Didukung dari Rilis |
| --- | --- | --- | --- | --- |
| Koordinator Trino | http-server.https.port | 8446 | TLS | emr-6.1.0 \$1, emr-7.0.0\$1 |
| Pekerja Trino | http-server.https.port | 8446 | TLS | emr-6.1.0 \$1, emr-7.0.0\$1 |
## Hive dan Tez
Secara default, server Hive 2, server metastore Hive, UI web Hive LLAP Daemon, dan Hive LLAP mengacak semua dukungan TLS saat enkripsi dalam transit diaktifkan di kluster EMR. Untuk informasi selengkapnya tentang konfigurasi Hive, lihat Properti [konfigurasi](https://cwiki.apache.org/confluence/display/Hive/Configuration+Properties).
UI yang di-host di server Tomcat juga diaktifkan HTTP saat enkripsi dalam transit diaktifkan di kluster EMR. Namun, HTTPS dinonaktifkan untuk layanan UI web Tez AM sehingga pengguna AM tidak memiliki akses ke file keystore untuk pembuka SSL listener. Anda juga dapat mengaktifkan perilaku ini dengan konfigurasi `tez.am.tez-ui.webservice.enable.ssl` Boolean dan. `tez.am.tez-ui.webservice.enable.client.auth`
| Komponen | Titik akhir | Port | Mekanisme Enkripsi Dalam Transit | Didukung dari Rilis |
| --- | --- | --- | --- | --- |
| 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 LLAP | hive.llap.daemon.yarn.shuffle.port | 15551 | TLS | emr-7.3.0\$1 |
| Daemon LLAP | hive.llap.daemon.web.port | 15002 | TLS | emr-7.3.0\$1 |
| Daemon LLAP | hive.llap.daemon.output.service.port | 15003 | Tidak ada | Hive tidak mendukung enkripsi dalam perjalanan untuk titik akhir ini |
| Daemon LLAP | hive.llap.management.rpc.port | 15004 | Tidak ada | Hive tidak mendukung enkripsi dalam perjalanan untuk titik akhir ini |
| Daemon LLAP | hive.llap.plugin.rpc.port | Dinamis | Tidak ada | Hive tidak mendukung enkripsi dalam perjalanan untuk titik akhir ini |
| Daemon LLAP | hive.llap.daemon.rpc.port | Dinamis | Tidak ada | Hive tidak mendukung enkripsi dalam perjalanan untuk titik akhir ini |
| Web HCat | templeton.port | 50111 | TLS | emr-7.3.0\$1 |
| Master Aplikasi Tez | tez.am.client.am.port-range tez.am.task.am.port-range | Dinamis | Tidak ada | Tez tidak mendukung enkripsi dalam perjalanan untuk titik akhir ini |
| Master Aplikasi Tez | tez.am.tez-ui.webservice.port-range | Dinamis | Tidak ada | Dinonaktifkan secara default. Dapat diaktifkan menggunakan konfigurasi Tez di emr-7.3.0 \$1 |
| Tugas Tez | N/A - tidak dapat dikonfigurasi | Dinamis | Tidak ada | Tez tidak mendukung enkripsi dalam perjalanan untuk titik akhir ini |
| Tez UI | Dapat dikonfigurasi melalui server Tomcat tempat Tez UI di-host | 8080 | TLS | emr-7.3.0\$1 |
## Flink
Titik akhir Apache Flink REST dan komunikasi internal antara proses flink mendukung TLS secara default saat Anda mengaktifkan enkripsi dalam transit di kluster 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)diatur ke `true` dan menggunakan enkripsi dalam transit untuk komunikasi internal antara proses Flink. Jika Anda tidak ingin enkripsi dalam perjalanan untuk komunikasi internal, nonaktifkan konfigurasi itu. Kami menyarankan Anda menggunakan konfigurasi default untuk keamanan maksimum.
Amazon EMR menyetel `true` dan [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)menggunakan enkripsi dalam transit untuk titik akhir REST. Selain itu, Amazon EMR juga menetapkan 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)untuk menggunakan komunikasi TLS dengan server riwayat Flink. Jika Anda tidak ingin enkripsi dalam perjalanan untuk titik REST, nonaktifkan konfigurasi ini. Kami menyarankan Anda menggunakan konfigurasi default untuk keamanan maksimum.
Amazon EMR menggunakan [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). untuk menentukan daftar cipher yang menggunakan enkripsi berbasis AES. Ganti konfigurasi ini untuk menggunakan cipher yang Anda inginkan.
Untuk informasi selengkapnya, lihat [Pengaturan SSL](https://nightlies.apache.org/flink/flink-docs-release-1.18/docs/deployment/security/security-ssl/) di dokumentasi Flink.
| Komponen | Titik akhir | Port | Mekanisme Enkripsi Dalam Transit | Didukung dari Rilis |
| --- | --- | --- | --- | --- |
| Server Sejarah Flink | historyserver.web.port | 8082 | TLS | emr-7.3.0\$1 |
| Server Istirahat Manajer Pekerjaan | rest.bind-port rest.port | Dinamis | TLS | emr-7.3.0\$1 |
## HBase
Amazon EMR menetapkan [Secure Hadoop](https://hadoop.apache.org/docs/r2.7.2/hadoop-project-dist/hadoop-common/SecureMode.html#Data_Encryption_on_RPC) RPC ke. `privacy` HMaster dan RegionServer menggunakan enkripsi in-transit berbasis SASL. Ini mengharuskan otentikasi Kerberos diaktifkan dalam konfigurasi keamanan.
Amazon EMR disetel `hbase.ssl.enabled` ke true dan menggunakan TLS untuk titik akhir UI. Jika Anda tidak ingin menggunakan TLS untuk titik akhir UI, nonaktifkan konfigurasi ini. Kami menyarankan Anda menggunakan konfigurasi default untuk keamanan maksimum.
Amazon EMR menetapkan `hbase.rest.ssl.enabled` dan `hbase.thrift.ssl.enabled` dan menggunakan TLS untuk titik akhir server REST dan Thirft, masing-masing. Jika Anda tidak ingin menggunakan TLS untuk titik akhir ini, nonaktifkan konfigurasi ini. Kami menyarankan Anda menggunakan konfigurasi default untuk keamanan maksimum.
Dimulai dengan EMR 7.6.0, TLS didukung pada dan titik akhir. HMaster RegionServer Amazon EMR juga menetapkan `hbase.server.netty.tls.enabled` dan. `hbase.client.netty.tls.enabled` Jika Anda tidak ingin menggunakan TLS untuk titik akhir ini, nonaktifkan konfigurasi ini. Kami menyarankan Anda menggunakan konfigurasi default, yang menyediakan enkripsi dan dengan demikian keamanan yang lebih tinggi. Untuk mempelajari lebih lanjut, lihat [Transport Level Security (TLS) dalam komunikasi HBase RPC di Panduan](https://hbase.apache.org/book.html#_transport_level_security_tls_in_hbase_rpc_communication) Referensi *Apache HBase *.
| Komponen | Titik akhir | Port | Mekanisme Enkripsi Dalam Transit | Didukung dari Rilis |
| --- | --- | --- | --- | --- |
| HMaster | HMaster | 16000 | SASL\$1Kerberos TLS | SASL\$1Kerberos di emr-4.8.0\$1, emr-5.0.0\$1, emr-6.0.0\$1, dan emr-7.0.0\$1 TLS di emr-7.6.0\$1 |
| HMaster | HMaster UI | 16010 | TLS | emr-7.3.0\$1 |
| RegionServer | RegionServer | 16020 | SASL\$1Kerberos TLS | SASL\$1Kerberos di emr-4.8.0\$1, emr-5.0.0\$1, emr-6.0.0\$1, dan emr-7.0.0\$1 TLS di emr-7.6.0\$1 |
| RegionServer | RegionServer Info | 16030 | TLS | emr-7.3.0\$1 |
| HBase Server Istirahat | Server Istirahat | 8070 | TLS | emr-7.3.0\$1 |
| HBase Server Istirahat | UI Istirahat | 8085 | TLS | emr-7.3.0\$1 |
| Server Hemat Hbase | Server Hemat | 9090 | TLS | emr-7.3.0\$1 |
| Server Hemat Hbase | UI Server Hemat | 9095 | TLS | emr-7.3.0\$1 |
## Phoenix
Jika Anda mengaktifkan enkripsi dalam transit di kluster EMR Anda, Phoenix Query Servermendukung `phoenix.queryserver.tls.enabled` properti TLS, yang disetel ke secara default. `true`
Untuk mempelajari lebih lanjut, lihat [Konfigurasi yang berkaitan dengan HTTPS](https://phoenix.apache.org/server.html#Configuration) di dokumentasi Phoenix Query Server.
| Komponen | Titik akhir | Port | Mekanisme Enkripsi Dalam Transit | Didukung dari Rilis |
| --- | --- | --- | --- | --- |
| Server Kueri | phoenix.queryserver.http.port | 8765 | TLS | emr-7.3.0\$1 |
## Oozie
[OOZIE-3673](https://issues.apache.org/jira/browse/OOZIE-3673) tersedia di Amazon EMR jika Anda menjalankan Oozie di Amazon EMR 7.3.0 dan yang lebih tinggi. Jika Anda perlu mengonfigurasi protokol SSL atau TLS kustom saat menjalankan tindakan email, Anda dapat mengatur properti `oozie.email.smtp.ssl.protocols` dalam file. `oozie-site.xml` Secara default, jika Anda mengaktifkan enkripsi dalam transit, Amazon EMR menggunakan protokol TLS v1.3.
[OOZIE-3677](https://issues.apache.org/jira/browse/OOZIE-3677) dan [OOZIE-3674 juga tersedia](https://issues.apache.org/jira/browse/OOZIE-3674) di Amazon EMR jika Anda menjalankan Oozie di Amazon EMR 7.3.0 dan yang lebih tinggi. Ini memungkinkan Anda menentukan properti `keyStoreType` dan `trustStoreType` di`oozie-site.xml`. OOZIE-3674 menambahkan parameter `--insecure` ke klien Oozie sehingga dapat mengabaikan kesalahan sertifikat.
Oozie memberlakukan verifikasi nama host TLS, yang berarti bahwa sertifikat apa pun yang Anda gunakan untuk enkripsi dalam perjalanan harus memenuhi persyaratan verifikasi nama host. Jika sertifikat tidak memenuhi kriteria, klaster mungkin macet pada `oozie share lib update` tahap saat Amazon EMR menyediakan klaster. Kami menyarankan Anda memperbarui sertifikat untuk memastikan sertifikat tersebut sesuai dengan verifikasi nama host. Namun, jika Anda tidak dapat memperbarui sertifikat, Anda dapat menonaktifkan SSL untuk Oozie dengan menyetel `oozie.https.enabled` properti ke `false` dalam konfigurasi cluster.
| Komponen | Titik akhir | Port | Mekanisme Enkripsi Dalam Transit | Didukung dari Rilis |
| --- | --- | --- | --- | --- |
| EmbeddedOozieServer | oozie.https.port | 11443 | TLS | emr-7.3.0\$1 |
| EmbeddedOozieServer | oozie.email.smtp.port | 25 | TLS | emr-7.3.0\$1 |
## Hue
Secara default, Hue mendukung TLS saat enkripsi dalam transit diaktifkan di kluster EMR Amazon. Untuk informasi selengkapnya tentang konfigurasi Hue, lihat [Mengonfigurasi Hue dengan HTTPS](https://gethue.com/configure-hue-with-https-ssl/)/SSL.
| Komponen | Titik akhir | Port | Mekanisme Enkripsi Dalam Transit | Didukung dari Rilis |
| --- | --- | --- | --- | --- |
| Hue | http\$1port | 8888 | TLS | emr-7.4.0\$1 |
## Livy
Secara default, Livy mendukung TLS saat enkripsi dalam transit diaktifkan di kluster EMR Amazon. Untuk informasi selengkapnya tentang konfigurasi Livy, lihat [Mengaktifkan HTTPS dengan](https://docs.aws.amazon.com/emr/latest/ReleaseGuide/enabling-https.html) Apache Livy.
Dimulai dengan Amazon EMR 7.3.0, jika Anda menggunakan enkripsi dalam transit dan otentikasi Kerberos, Anda tidak dapat menggunakan server Livy untuk aplikasi Spark yang bergantung pada metastore Hive. Masalah ini diperbaiki di [HIVE-16340](https://issues.apache.org/jira/browse/HIVE-16340) dan sepenuhnya diselesaikan di [SPARK-44114 ketika aplikasi Spark](https://issues.apache.org/jira/browse/SPARK-44114) open-source dapat meningkatkan ke Hive 3. Sementara itu, Anda dapat mengatasi masalah ini jika Anda `hive.metastore.use.SSL` menyetelnya. `false` Untuk informasi selengkapnya, lihat [Mengkonfigurasi aplikasi](https://docs.aws.amazon.com/emr/latest/ReleaseGuide/emr-configure-apps.html).
Untuk informasi selengkapnya, lihat [mengaktifkan HTTPS dengan Apache Livy](https://docs.aws.amazon.com/emr/latest/ReleaseGuide/enabling-https.html).
| Komponen | Titik akhir | Port | Mekanisme Enkripsi Dalam Transit | Didukung dari Rilis |
| --- | --- | --- | --- | --- |
| livy-server | livy.server.port | 8998 | TLS | emr-7.4.0\$1 |
## JupyterEnterpriseGateway
Secara default, Jupyter Enterprise Gateway mendukung TLS saat enkripsi dalam transit diaktifkan di kluster EMR Amazon. Untuk informasi selengkapnya tentang konfigurasi Jupyter Enterprise Gateway, lihat [Mengamankan](https://jupyter-enterprise-gateway.readthedocs.io/en/v1.2.0/getting-started-security.html#securing-enterprise-gateway-server) Server Gateway Perusahaan.
| Komponen | Titik akhir | Port | Mekanisme Enkripsi Dalam Transit | Didukung dari Rilis |
| --- | --- | --- | --- | --- |
| jupyter\$1enterprise\$1gateway | c. EnterpriseGatewayApp .port | 9547 | TLS | emr-7.4.0\$1 |
## JupyterHub
Secara default, JupyterHub mendukung TLS saat enkripsi dalam transit diaktifkan di kluster EMR Amazon. Untuk informasi selengkapnya, lihat [Mengaktifkan enkripsi SSL](https://jupyterhub.readthedocs.io/en/latest/tutorial/getting-started/security-basics.html#enabling-ssl-encryption) dalam dokumentasi. JupyterHub Tidak disarankan untuk menonaktifkan enkripsi.
| Komponen | Titik akhir | Port | Mekanisme Enkripsi Dalam Transit | Didukung dari Rilis |
| --- | --- | --- | --- | --- |
| jupyter\$1hub | c. JupyterHub .port | 9443 | TLS | emr-5.14.0 \$1, emr-6.0 \$1, emr-7.0 \$1 |
## Zeppelin
Secara default, Zeppelin mendukung TLS saat Anda mengaktifkan enkripsi dalam transit di kluster EMR Anda. Untuk informasi selengkapnya tentang konfigurasi Zeppelin, lihat Konfigurasi [SSL](https://zeppelin.apache.org/docs/0.11.1/setup/operation/configuration.html#ssl-configuration) dalam dokumentasi Zeppelin.
| Komponen | Titik akhir | Port | Mekanisme Enkripsi Dalam Transit | Didukung dari Rilis |
| --- | --- | --- | --- | --- |
| zeppelin | zeppelin.server.ssl.port | 8890 | TLS | 7.3.0\$1 |
## Zookeeper
Amazon EMR menetapkan `serverCnxnFactory` untuk mengaktifkan TLS `org.apache.zookeeper.server.NettyServerCnxnFactory` untuk kuorum Zookeeper dan komunikasi klien.
`secureClientPort`menentukan port yang mendengarkan koneksi TLS. Jika klien tidak mendukung koneksi TLS ke Zookeeper, klien dapat terhubung ke port tidak aman 2181 yang ditentukan dalam. `clientPort` Anda dapat mengganti atau menonaktifkan kedua port ini.
Amazon EMR menetapkan keduanya `sslQuorum` dan `admin.forceHttps` untuk mengaktifkan komunikasi TLS `true` untuk kuorum dan server admin. Jika Anda tidak ingin enkripsi dalam transit untuk kuorum dan server admin, Anda dapat menonaktifkan konfigurasi tersebut. Kami menyarankan Anda menggunakan konfigurasi default untuk keamanan maksimum.
Untuk informasi selengkapnya, lihat [Opsi Enkripsi, Otentikasi, Otorisasi dalam dokumentasi](https://zookeeper.apache.org/doc/r3.9.2/zookeeperAdmin.html#sc_authOptions) Zookeeper.
| Komponen | Titik akhir | Port | Mekanisme Enkripsi Dalam Transit | Didukung dari Rilis |
| --- | --- | --- | --- | --- |
| Server Penjaga Kebun Binatang | secureClientPort | 2281 | TLS | emr-7.4.0\$1 |
| Server Penjaga Kebun Binatang | Pelabuhan Kuorum | Ada 2: Pengikut menggunakan 2888 untuk terhubung ke pemimpin. Pemilu pemimpin menggunakan 3888 | TLS | emr-7.4.0\$1 |
| Server Penjaga Kebun Binatang | admin.ServerPort | 8341 | TLS | emr-7.4.0\$1 |