Amazon Redshift tidak akan lagi mendukung pembuatan Python UDFs baru mulai Patch 198. Python yang ada UDFs akan terus berfungsi hingga 30 Juni 2026. Untuk informasi lebih lanjut, lihat [posting blog](https://aws.amazon.com/blogs/big-data/amazon-redshift-python-user-defined-functions-will-reach-end-of-support-after-june-30-2026/).
Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.
# Enkripsi data
Perlindungan data mengacu pada melindungi data saat transit (saat melakukan perjalanan ke dan dari Amazon Redshift) dan saat istirahat (saat disimpan di disk di pusat data Amazon Redshift). Anda dapat melindungi data dalam perjalanan dengan menggunakan SSL atau dengan menggunakan enkripsi sisi klien. Anda memiliki opsi berikut untuk melindungi data saat istirahat di Amazon Redshift.
+ **Gunakan enkripsi sisi server** — Anda meminta Amazon Redshift untuk mengenkripsi data Anda sebelum menyimpannya di disk di pusat datanya dan mendekripsi ketika Anda mengunduh objek.
+ **Gunakan enkripsi sisi klien** — Anda dapat mengenkripsi data sisi klien dan mengunggah data terenkripsi ke Amazon Redshift. Dalam hal ini, Anda mengelola proses enkripsi, kunci enkripsi, dan alat terkait.
# Enkripsi saat diam
Enkripsi sisi server adalah tentang enkripsi data saat istirahat—yaitu, Amazon Redshift secara opsional mengenkripsi data Anda saat menulisnya di pusat datanya dan mendekripsi untuk Anda saat Anda mengaksesnya. Selama Anda mengautentikasi permintaan Anda dan memiliki izin akses, tidak ada perbedaan dalam cara Anda mengakses data terenkripsi atau tidak terenkripsi.
Amazon Redshift melindungi data saat istirahat melalui enkripsi. Secara opsional, Anda dapat melindungi semua data yang disimpan pada disk dalam cluster dan semua cadangan di Amazon S3 dengan Advanced Encryption Standard AES-256.
[Untuk mengelola kunci yang digunakan untuk mengenkripsi dan mendekripsi sumber daya Amazon Redshift, Anda menggunakan (). AWS Key Management ServiceAWS KMS](https://docs.aws.amazon.com/kms/latest/developerguide/) AWS KMSmenggabungkan perangkat keras dan perangkat lunak yang aman dan sangat tersedia untuk menyediakan sistem manajemen kunci yang diskalakan untuk cloud. Dengan menggunakanAWS KMS, Anda dapat membuat kunci enkripsi dan menentukan kebijakan yang mengontrol bagaimana kunci ini dapat digunakan. AWS KMSmendukungAWS CloudTrail, sehingga Anda dapat mengaudit penggunaan kunci untuk memverifikasi bahwa kunci sedang digunakan dengan tepat. Anda dapat menggunakan AWS KMS tombol Anda dalam kombinasi dengan Amazon Redshift dan layanan yang didukung.. AWS Untuk daftar layanan yang mendukungAWS KMS, lihat [Cara Penggunaan AWS Layanan AWS KMS](https://docs.aws.amazon.com/kms/latest/developerguide/services.html) di *Panduan AWS Key Management Service Pengembang*.
Jika Anda memilih untuk mengelola kata sandi admin cluster atau namespace tanpa server yang disediakan, Amazon AWS Secrets Manager Redshift juga menerima kunci KMS tambahan AWS yang digunakan untuk mengenkripsi kredensil Anda. AWS Secrets Manager Kunci tambahan ini dapat berupa kunci yang dihasilkan secara otomatis dariAWS Secrets Manager, atau kunci khusus yang Anda berikan.
Editor kueri Amazon Redshift v2 dengan aman menyimpan informasi yang dimasukkan ke dalam editor kueri sebagai berikut:
+ Nama Sumber Daya Amazon (ARN) dari kunci KMS yang digunakan untuk mengenkripsi data editor kueri v2.
+ Informasi koneksi database.
+ Nama dan isi file dan folder.
Editor kueri Amazon Redshift v2 mengenkripsi informasi menggunakan enkripsi tingkat blok dengan kunci KMS Anda atau kunci KMS akun layanan. Enkripsi data Amazon Redshift Anda dikendalikan oleh properti klaster Amazon Redshift Anda.
**Topics**
+ [Enkripsi basis data Amazon Redshift](working-with-db-encryption.md)
# Enkripsi basis data Amazon Redshift
Di Amazon Redshift, database Anda dienkripsi secara default untuk melindungi data Anda saat istirahat. Enkripsi database berlaku untuk cluster dan juga untuk snapshot-nya.
Anda dapat memodifikasi klaster yang tidak terenkripsi untuk menggunakan enkripsi AWS Key Management Service ()AWS KMS. Untuk melakukannya, Anda dapat menggunakan kunci yang AWS dimiliki atau kunci yang dikelola pelanggan. Saat Anda memodifikasi klaster untuk mengaktifkan AWS KMS enkripsi, Amazon Redshift secara otomatis memigrasikan data Anda ke kluster terenkripsi baru. Snapshot yang dibuat dari cluster terenkripsi juga dienkripsi. **Anda juga dapat memigrasikan kluster terenkripsi ke klaster yang tidak terenkripsi dengan memodifikasi klaster dan mengubah opsi Enkripsi database.** Untuk informasi selengkapnya, lihat [Mengubah enkripsi cluster](changing-cluster-encryption.md).
Meskipun Anda masih dapat mengubah cluster terenkripsi default menjadi tidak terenkripsi setelah membuat cluster, kami sarankan Anda menyimpan cluster yang berisi data sensitif sebagai terenkripsi. Selain itu, Anda mungkin diminta untuk menggunakan enkripsi tergantung pada pedoman atau peraturan yang mengatur data Anda. Misalnya, Standar Keamanan Data Industri Kartu Pembayaran (PCI DSS), Sarbanes-Oxley Act (SOX), Health Insurance Portability and Accountability Act (HIPAA), dan peraturan lainnya memberikan pedoman untuk menangani jenis data tertentu.
Amazon Redshift menggunakan hierarki kunci enkripsi untuk mengenkripsi database. Anda dapat menggunakan AWS Key Management Service (AWS KMS) atau modul keamanan perangkat keras (HSM) untuk mengelola kunci enkripsi tingkat atas dalam hierarki ini. Proses yang digunakan Amazon Redshift untuk enkripsi berbeda tergantung pada cara Anda mengelola kunci. Amazon Redshift secara otomatis terintegrasi dengan AWS KMS tetapi tidak dengan HSM. Saat Anda menggunakan HSM, Anda harus menggunakan sertifikat klien dan server untuk mengonfigurasi koneksi tepercaya antara Amazon Redshift dan HSM Anda.
**penting**
Amazon Redshift dapat kehilangan akses ke kunci KMS untuk klaster yang disediakan atau namespace tanpa server saat Anda menonaktifkan kunci KMS yang dikelola pelanggan. Dalam kasus ini, Amazon Redshift mengambil cadangan gudang data Amazon Redshift dan menempatkannya dalam keadaan selama 14 `inaccessible-kms-key` hari. Jika Anda mengembalikan kunci KMS dalam periode itu, Amazon Redshift akan memulihkan akses dan gudang akan berfungsi secara normal. Jika periode 14 hari berakhir tanpa kunci KMS dipulihkan, Amazon Redshift akan menghapus gudang data. Sementara gudang dalam `inaccessible-kms-key` keadaan, ia memiliki karakteristik sebagai berikut:
Anda tidak dapat menjalankan kueri apa pun di gudang data.
Jika gudang data adalah gudang produsen dari datashare, Anda tidak dapat menjalankan kueri pembagian data terhadapnya dari gudang konsumen.
Anda tidak dapat membuat salinan snapshot lintas wilayah.
Untuk informasi tentang memulihkan kunci KMS yang dinonaktifkan, lihat [Mengaktifkan dan menonaktifkan kunci](https://docs.aws.amazon.com/kms/latest/developerguide/enabling-keys.html) di Panduan *AWS Key Management Service Pengembang*. Jika kunci KMS gudang dihapus, Anda dapat menggunakan cadangan untuk membuat gudang data baru sebelum gudang `inaccessible-kms-key` status dihapus.
## Peningkatan proses enkripsi untuk kinerja dan ketersediaan yang lebih baik
### Enkripsi dengan RA3 node
Pembaruan proses enkripsi untuk RA3 node telah membuat pengalaman jauh lebih baik. Kueri baca dan tulis dapat berjalan selama proses dengan dampak kinerja yang lebih sedikit dari enkripsi. Juga, enkripsi selesai jauh lebih cepat. Langkah-langkah proses yang diperbarui mencakup operasi pemulihan dan migrasi metadata cluster ke cluster target. Pengalaman yang ditingkatkan berlaku untuk jenis enkripsi seperti AWS KMS, misalnya. Ketika Anda memiliki volume data skala petabyte, operasi telah berkurang dari minggu ke hari.
Sebelum mengenkripsi klaster Anda, jika Anda berencana untuk terus menjalankan beban kerja database, Anda dapat meningkatkan kinerja dan mempercepat proses dengan menambahkan node dengan pengubahan ukuran elastis. Anda tidak dapat menggunakan pengubahan ukuran elastis saat enkripsi sedang dalam proses, jadi lakukan sebelum Anda mengenkripsi. Perhatikan bahwa menambahkan node biasanya menghasilkan biaya yang lebih tinggi.
### Enkripsi dengan tipe node lainnya
Saat Anda mengenkripsi cluster dengan DC2 node, Anda tidak memiliki kemampuan untuk menjalankan kueri tulis, seperti dengan RA3 node. Hanya kueri baca yang dapat dijalankan.
### Catatan penggunaan untuk enkripsi dengan RA3 node
Wawasan dan sumber daya berikut membantu Anda mempersiapkan enkripsi dan memantau prosesnya.
+ **Menjalankan kueri setelah memulai enkripsi** — Setelah enkripsi dimulai, membaca dan menulis tersedia dalam waktu sekitar lima belas menit. Berapa lama waktu yang dibutuhkan proses enkripsi penuh untuk menyelesaikan tergantung pada jumlah data pada cluster dan tingkat beban kerja.
+ **Berapa lama enkripsi?** — Waktu untuk mengenkripsi data Anda tergantung pada beberapa faktor: Ini termasuk jumlah beban kerja yang berjalan, sumber daya komputasi yang digunakan, jumlah node, dan jenis node. Kami menyarankan agar Anda awalnya melakukan enkripsi di lingkungan pengujian. Sebagai aturan praktis, jika Anda bekerja dengan volume data dalam petabyte, kemungkinan akan memakan waktu 1-3 hari untuk menyelesaikan enkripsi.
+ **Bagaimana saya tahu enkripsi selesai?** — Setelah Anda mengaktifkan enkripsi, penyelesaian snapshot pertama mengonfirmasi bahwa enkripsi selesai.
+ **Menggulung kembali enkripsi** - Jika Anda perlu memutar kembali operasi enkripsi, cara terbaik untuk melakukannya adalah memulihkan dari cadangan terbaru yang diambil sebelum enkripsi dimulai. Anda harus menerapkan kembali setiap pembaruan baru (updates/deletes/inserts) setelah pencadangan terakhir.
+ **Melakukan pemulihan tabel** — Perhatikan bahwa Anda tidak dapat memulihkan tabel dari klaster yang tidak terenkripsi ke kluster terenkripsi.
+ **Mengenkripsi kluster simpul tunggal — Mengenkripsi kluster simpul** tunggal memiliki keterbatasan kinerja. Dibutuhkan waktu lebih lama dari enkripsi untuk cluster multi-node.
+ **Membuat cadangan setelah enkripsi** — Saat Anda mengenkripsi data di klaster Anda, cadangan tidak dibuat sampai cluster sepenuhnya dienkripsi. Jumlah waktu yang dibutuhkan dapat bervariasi. Waktu yang dibutuhkan untuk pencadangan bisa berjam-jam hingga berhari-hari, tergantung pada ukuran cluster. Setelah enkripsi selesai, mungkin ada penundaan sebelum Anda dapat membuat cadangan.
Perhatikan bahwa karena backup-and-restore operasi terjadi selama proses enkripsi, setiap tabel atau tampilan terwujud yang dibuat dengan `BACKUP NO` tidak dipertahankan. Untuk informasi selengkapnya, lihat [MEMBUAT TABEL](https://docs.aws.amazon.com/redshift/latest/dg/r_CREATE_TABLE_NEW.html) atau [MEMBUAT TAMPILAN TERWUJUD](https://docs.aws.amazon.com/redshift/latest/dg/materialized-view-create-sql-command.html).
**Topics**
+ [Peningkatan proses enkripsi untuk kinerja dan ketersediaan yang lebih baik](#resize-classic-encryption)
+ [Enkripsi menggunakan AWS KMS](#working-with-aws-kms)
+ [Enkripsi menggunakan modul keamanan perangkat keras](#working-with-HSM)
+ [Rotasi kunci enkripsi](#working-with-key-rotation)
+ [Mengubah enkripsi cluster](changing-cluster-encryption.md)
+ [Migrasi ke cluster terenkripsi HSM](migrating-to-an-encrypted-cluster.md)
+ [Memutar kunci enkripsi](manage-key-rotation-console.md)
## Enkripsi menggunakan AWS KMS
Saat Anda memilih AWS KMS untuk manajemen kunci dengan Amazon Redshift, ada hierarki kunci enkripsi empat tingkat. Kunci ini, dalam urutan hierarkis, adalah kunci root, kunci enkripsi cluster (CEK), kunci enkripsi database (DEK), dan kunci enkripsi data.
Saat Anda meluncurkan cluster Anda, Amazon Redshift mengembalikan daftar Amazon Redshift atau akun AWS Anda telah dibuat atau memiliki izin untuk digunakan. AWS KMS keys AWS KMS Anda memilih kunci KMS untuk digunakan sebagai kunci root Anda dalam hierarki enkripsi.
Secara default, Amazon Redshift memilih kunci AWS milik yang dibuat secara otomatis sebagai kunci root untuk AWS akun Anda untuk digunakan di Amazon Redshift.
Jika Anda tidak ingin menggunakan kunci default, Anda harus memiliki (atau membuat) kunci KMS yang dikelola pelanggan secara terpisah AWS KMS sebelum meluncurkan klaster di Amazon Redshift. Kunci yang dikelola pelanggan memberi Anda lebih banyak fleksibilitas, termasuk kemampuan untuk membuat, memutar, menonaktifkan, menentukan kontrol akses, dan mengaudit kunci enkripsi yang digunakan untuk membantu melindungi data Anda. Untuk informasi selengkapnya tentang membuat kunci KMS, lihat [Membuat Kunci](https://docs.aws.amazon.com/kms/latest/developerguide/create-keys.html) di *Panduan AWS Key Management Service Pengembang*.
Jika Anda ingin menggunakan AWS KMS kunci dari AWS akun lain, Anda harus memiliki izin untuk menggunakan kunci dan menentukan Nama Sumber Daya Amazon (ARN) di Amazon Redshift. Untuk informasi selengkapnya tentang akses ke kunci AWS KMS, lihat [Mengontrol Akses ke Kunci Anda](https://docs.aws.amazon.com/kms/latest/developerguide/control-access.html) di *Panduan AWS Key Management Service Pengembang*.
Setelah Anda memilih kunci root, Amazon Redshift meminta yang AWS KMS menghasilkan kunci data dan mengenkripsinya menggunakan kunci root yang dipilih. Kunci data ini digunakan sebagai CEK di Amazon Redshift. AWS KMS mengekspor CEK terenkripsi ke Amazon Redshift, di mana ia disimpan secara internal pada disk dalam jaringan terpisah dari cluster bersama dengan hibah ke kunci KMS dan konteks enkripsi untuk CEK. Hanya CEK terenkripsi yang diekspor ke Amazon Redshift; kunci KMS tetap ada. AWS KMS Amazon Redshift juga meneruskan CEK terenkripsi melalui saluran aman ke cluster dan memuatnya ke dalam memori. Kemudian, Amazon Redshift memanggil AWS KMS untuk mendekripsi CEK dan memuat CEK yang didekripsi ke dalam memori. Untuk informasi selengkapnya tentang hibah, konteks enkripsi, dan konsep AWS KMS terkait lainnya, lihat [Konsep dalam Panduan AWS Key Management Service](https://docs.aws.amazon.com/kms/latest/developerguide/concepts.html) *Pengembang*.
Selanjutnya, Amazon Redshift secara acak menghasilkan kunci untuk digunakan sebagai DEK dan memuatnya ke dalam memori di cluster. CEK yang didekripsi digunakan untuk mengenkripsi DEK, yang kemudian dilewatkan melalui saluran aman dari cluster untuk disimpan secara internal oleh Amazon Redshift pada disk di jaringan terpisah dari cluster. Seperti CEK, versi DEK yang dienkripsi dan didekripsi dimuat ke dalam memori di cluster. Versi DEK yang didekripsi kemudian digunakan untuk mengenkripsi kunci enkripsi individu yang dihasilkan secara acak untuk setiap blok data dalam database.
Saat cluster reboot, Amazon Redshift dimulai dengan versi CEK dan DEK yang tersimpan secara internal dan terenkripsi, memuat ulang ke dalam memori, dan kemudian AWS KMS memanggil untuk mendekripsi CEK dengan kunci KMS lagi sehingga dapat dimuat ke dalam memori. CEK yang didekripsi kemudian digunakan untuk mendekripsi DEK lagi, dan DEK yang didekripsi dimuat ke dalam memori dan digunakan untuk mengenkripsi dan mendekripsi kunci blok data sesuai kebutuhan.
Untuk informasi selengkapnya tentang membuat klaster Amazon Redshift yang dienkripsi dengan kunci, lihat. AWS KMS [Membuat kluster](create-cluster.md)
### Menyalin AWS KMS—snapshot terenkripsi ke yang lain Wilayah AWS
AWS KMS kunci khusus untuk sebuah Wilayah AWS. Jika Anda ingin mengaktifkan penyalinan snapshot Amazon Redshift dari cluster sumber terenkripsi ke yang Wilayah AWS lain, tetapi ingin menggunakan kunci Anda AWS KMS sendiri untuk snapshot di tujuan, Anda perlu mengonfigurasi hibah untuk Amazon Redshift untuk menggunakan kunci root di akun Anda di tujuan. Wilayah AWS Hibah ini memungkinkan Amazon Redshift mengenkripsi snapshot di tujuan. Wilayah AWS Jika Anda ingin snapshot di tujuan dienkripsi oleh kunci yang Wilayah AWS dimiliki, Anda tidak perlu mengonfigurasi hibah apa pun di tujuan. Wilayah AWS Untuk informasi selengkapnya tentang salinan snapshot lintas wilayah, lihat. [Menyalin snapshot ke Wilayah lain AWS](cross-region-snapshot-copy.md)
**catatan**
Jika Anda mengaktifkan penyalinan snapshot dari cluster terenkripsi dan digunakan AWS KMS untuk kunci root Anda, Anda tidak dapat mengganti nama cluster Anda karena nama cluster adalah bagian dari konteks enkripsi. Jika Anda harus mengganti nama cluster Anda, Anda dapat menonaktifkan penyalinan snapshot di AWS Wilayah sumber, mengganti nama cluster, dan kemudian mengkonfigurasi dan mengaktifkan penyalinan snapshot lagi.
Proses untuk mengonfigurasi hibah untuk menyalin snapshot adalah sebagai berikut.
1. Di AWS Wilayah tujuan, buat hibah salinan snapshot dengan melakukan hal berikut:
+ Jika Anda belum memiliki AWS KMS kunci untuk digunakan, buat satu. Untuk informasi selengkapnya tentang membuat AWS KMS kunci, lihat [Membuat Kunci](https://docs.aws.amazon.com/kms/latest/developerguide/create-keys.html) di *Panduan AWS Key Management Service Pengembang*.
+ Tentukan nama untuk hibah salinan snapshot. Nama ini harus unik di AWS Wilayah itu untuk AWS akun Anda.
+ Tentukan ID AWS KMS kunci tempat Anda membuat hibah. Jika Anda tidak menentukan ID kunci, hibah berlaku untuk kunci default Anda.
1. Di AWS wilayah sumber, aktifkan penyalinan snapshot dan tentukan nama hibah salinan snapshot yang Anda buat di Wilayah tujuan. AWS
Proses sebelumnya ini hanya diperlukan jika Anda mengaktifkan penyalinan snapshot menggunakan, AWS CLI Amazon Redshift API, atau. SDKs Jika Anda menggunakan konsol, Amazon Redshift menyediakan alur kerja yang tepat untuk mengonfigurasi hibah saat Anda mengaktifkan salinan snapshot lintas wilayah. Untuk informasi selengkapnya tentang mengonfigurasi salinan snapshot lintas wilayah untuk cluster AWS KMS-enkripsi menggunakan konsol, lihat. [Mengonfigurasi salinan snapshot lintas wilayah untuk kluster —terenkripsi AWS KMS](xregioncopy-kms-encrypted-snapshot.md)
Sebelum snapshot disalin ke AWS Wilayah tujuan, Amazon Redshift mendekripsi snapshot menggunakan kunci root di Wilayah AWS sumber dan mengenkripsi ulang sementara menggunakan kunci RSA yang dibuat secara acak yang dikelola Amazon Redshift secara internal. Amazon Redshift kemudian menyalin snapshot melalui saluran aman ke AWS Wilayah tujuan, mendekripsi snapshot menggunakan kunci RSA yang dikelola secara internal, dan kemudian mengenkripsi ulang snapshot menggunakan kunci root di Wilayah tujuan. AWS
## Enkripsi menggunakan modul keamanan perangkat keras
Jika Anda tidak menggunakan AWS KMS untuk manajemen kunci, Anda dapat menggunakan modul keamanan perangkat keras (HSM) untuk manajemen kunci dengan Amazon Redshift.
**penting**
Enkripsi HSM tidak didukung untuk DC2 dan tipe RA3 node.
HSMs adalah perangkat yang memberikan kontrol langsung atas pembuatan dan manajemen kunci. Mereka memberikan keamanan yang lebih besar dengan memisahkan manajemen kunci dari lapisan aplikasi dan database. Amazon Redshift mendukung AWS CloudHSM Classic untuk manajemen kunci. Proses enkripsi berbeda ketika Anda menggunakan HSM untuk mengelola kunci enkripsi Anda alih-alih. AWS KMS
**penting**
Amazon Redshift hanya AWS CloudHSM mendukung Klasik. Kami tidak mendukung AWS CloudHSM layanan yang lebih baru.
AWS CloudHSM Klasik tertutup untuk pelanggan baru. Untuk informasi selengkapnya, lihat Harga [Classic CloudHSM](https://aws.amazon.com/cloudhsm/pricing-classic/). AWS CloudHSM Klasik tidak tersedia di semua AWS Wilayah. Untuk informasi selengkapnya tentang AWS Wilayah yang tersedia, lihat [Tabel AWS Wilayah](https://aws.amazon.com/about-aws/global-infrastructure/regional-product-services/).
Saat Anda mengonfigurasi klaster Anda untuk menggunakan HSM, Amazon Redshift mengirimkan permintaan ke HSM untuk menghasilkan dan menyimpan kunci yang akan digunakan sebagai CEK. Namun, tidak seperti AWS KMS, HSM tidak mengekspor CEK ke Amazon Redshift. Sebaliknya, Amazon Redshift secara acak menghasilkan DEK di cluster dan meneruskannya ke HSM untuk dienkripsi oleh CEK. HSM mengembalikan DEK terenkripsi ke Amazon Redshift, di mana ia dienkripsi lebih lanjut menggunakan kunci root internal yang dihasilkan secara acak dan disimpan secara internal pada disk di jaringan terpisah dari cluster. Amazon Redshift juga memuat versi DEK yang didekripsi dalam memori di cluster sehingga DEK dapat digunakan untuk mengenkripsi dan mendekripsi kunci individual untuk blok data.
Jika klaster di-boot ulang, Amazon Redshift mendekripsi DEK terenkripsi ganda yang disimpan secara internal menggunakan kunci root internal untuk mengembalikan DEK yang disimpan secara internal ke status terenkripsi CEK. DEK yang dienkripsi CEK kemudian diteruskan ke HSM untuk didekripsi dan diteruskan kembali ke Amazon Redshift, di mana ia dapat dimuat dalam memori lagi untuk digunakan dengan kunci blok data individual.
### Mengonfigurasi koneksi tepercaya antara Amazon Redshift dan HSM
Ketika Anda memilih untuk menggunakan HSM untuk pengelolaan kunci klaster Anda, Anda perlu mengonfigurasi tautan jaringan tepercaya antara Amazon Redshift dan HSM Anda. Melakukan hal ini memerlukan konfigurasi sertifikat klien dan server. Koneksi tepercaya digunakan untuk meneruskan kunci enkripsi antara HSM dan Amazon Redshift selama operasi enkripsi dan dekripsi.
Amazon Redshift membuat sertifikat klien publik dari key pair private dan public key pair yang dibuat secara acak. Ini dienkripsi dan disimpan secara internal. Anda mengunduh dan mendaftarkan sertifikat klien publik di HSM Anda, dan menetapkannya ke partisi HSM yang berlaku.
Anda memberikan Amazon Redshift dengan alamat IP HSM, nama partisi HSM, kata sandi partisi HSM, dan sertifikat server HSM publik, yang dienkripsi dengan menggunakan kunci root internal. Amazon Redshift menyelesaikan proses konfigurasi dan memverifikasi bahwa ia dapat terhubung ke HSM. Jika tidak bisa, cluster dimasukkan ke dalam status INCOMPATIBLE\$1HSM dan cluster tidak dibuat. Dalam hal ini, Anda harus menghapus cluster yang tidak lengkap dan coba lagi.
**penting**
Ketika Anda memodifikasi klaster Anda untuk menggunakan partisi HSM yang berbeda, Amazon Redshift memverifikasi bahwa ia dapat terhubung ke partisi baru, tetapi tidak memverifikasi bahwa kunci enkripsi yang valid ada. Sebelum Anda menggunakan partisi baru, Anda harus mereplikasi kunci Anda ke partisi baru. Jika cluster dimulai ulang dan Amazon Redshift tidak dapat menemukan kunci yang valid, restart gagal. Untuk informasi selengkapnya, lihat [Mereplikasi Kunci Di Seluruh HSMs](https://docs.aws.amazon.com/cloudhsm/latest/userguide/cli-clone-hapg.html).
Setelah konfigurasi awal, jika Amazon Redshift gagal terhubung ke HSM, peristiwa dicatat. Untuk informasi selengkapnya tentang peristiwa ini, lihat [Pemberitahuan Acara Amazon Redshift](https://docs.aws.amazon.com/redshift/latest/mgmt/working-with-event-notifications.html).
## Rotasi kunci enkripsi
Di Amazon Redshift, Anda dapat memutar kunci enkripsi untuk cluster terenkripsi. Saat Anda memulai proses rotasi kunci, Amazon Redshift memutar CEK untuk cluster yang ditentukan dan untuk snapshot cluster otomatis atau manual apa pun. Amazon Redshift juga memutar DEK untuk cluster yang ditentukan, tetapi tidak dapat memutar DEK untuk snapshot saat disimpan secara internal di Amazon Simple Storage Service (Amazon S3) dan dienkripsi menggunakan DEK yang ada.
Sementara rotasi sedang berlangsung, cluster dimasukkan ke dalam status ROTATING\$1KEYS sampai selesai, pada saat itu cluster kembali ke status AVAILABLE. Amazon Redshift menangani dekripsi dan enkripsi ulang selama proses rotasi kunci.
**catatan**
Anda tidak dapat memutar tombol untuk snapshot tanpa cluster sumber. Sebelum Anda menghapus cluster, pertimbangkan apakah snapshot-nya bergantung pada rotasi tombol.
Karena klaster sesaat tidak tersedia selama proses rotasi kunci, Anda harus memutar kunci hanya sesering yang dibutuhkan data Anda atau ketika Anda mencurigai kunci mungkin telah disusupi. Sebagai praktik terbaik, Anda harus meninjau jenis data yang Anda simpan dan merencanakan seberapa sering memutar kunci yang mengenkripsi data tersebut. Frekuensi untuk memutar kunci bervariasi tergantung pada kebijakan perusahaan Anda untuk keamanan data, dan standar industri apa pun mengenai data sensitif dan kepatuhan terhadap peraturan. Pastikan paket Anda menyeimbangkan kebutuhan keamanan dengan pertimbangan ketersediaan untuk klaster Anda.
Untuk informasi selengkapnya tentang tombol putar, lihat[Memutar kunci enkripsi](manage-key-rotation-console.md).
# Mengubah enkripsi cluster
Anda dapat memodifikasi klaster yang tidak terenkripsi untuk menggunakan enkripsi AWS Key Management Service (AWS KMS) menggunakan kunci yang AWS dimiliki atau kunci yang dikelola pelanggan. Saat Anda memodifikasi klaster untuk mengaktifkan AWS KMS enkripsi, Amazon Redshift secara otomatis memigrasikan data Anda ke kluster terenkripsi baru. Anda juga dapat memigrasikan kluster terenkripsi ke cluster yang tidak terenkripsi dengan memodifikasi cluster dengan, tetapi tidak dengan cluster. AWS CLI Konsol Manajemen AWS
**Selama operasi migrasi, klaster Anda tersedia dalam mode hanya-baca, dan status klaster muncul sebagai pengubahan ukuran.**
Jika klaster Anda dikonfigurasi untuk mengaktifkan salinan snapshot lintas AWS Wilayah, Anda harus menonaktifkannya sebelum mengubah enkripsi. Untuk informasi selengkapnya, lihat [Menyalin snapshot ke Wilayah lain AWS](cross-region-snapshot-copy.md) dan [Mengonfigurasi salinan snapshot lintas wilayah untuk kluster —terenkripsi AWS KMS](xregioncopy-kms-encrypted-snapshot.md). Anda tidak dapat mengaktifkan enkripsi modul keamanan perangkat keras (HSM) dengan memodifikasi cluster. Sebagai gantinya, buat cluster baru yang dienkripsi HSM dan migrasi data Anda ke cluster baru. Untuk informasi selengkapnya, lihat [Migrasi ke cluster terenkripsi HSM](migrating-to-an-encrypted-cluster.md).
------
#### [ Amazon Redshift console ]
1. Masuk ke Konsol Manajemen AWS dan buka konsol Amazon Redshift di. [https://console.aws.amazon.com/redshiftv2/](https://console.aws.amazon.com/redshiftv2/)
1. Pada menu navigasi, pilih **Cluster**, lalu pilih cluster yang ingin Anda ubah enkripsi.
1. Pilih **Properti**.
1. Di bagian **Konfigurasi basis data**, pilih **Edit**, lalu pilih **Edit enkripsi**.
1. Pilih salah satu opsi enkripsi dan pilih **Simpan perubahan**.
------
#### [ AWS CLI ]
Untuk memodifikasi cluster yang tidak terenkripsi untuk digunakan AWS KMS, jalankan perintah `modify-cluster` CLI dan tentukan`–-encrypted`, seperti yang ditunjukkan berikut. Secara default, kunci KMS default Anda digunakan. Untuk menentukan kunci yang dikelola pelanggan, sertakan `--kms-key-id` opsi.
```
aws redshift modify-cluster --cluster-identifier --encrypted --kms-key-id
```
Untuk menghapus enkripsi dari cluster Anda, jalankan perintah CLI berikut.
```
aws redshift modify-cluster --cluster-identifier --no-encrypted
```
------
# Migrasi ke cluster terenkripsi HSM
Untuk memigrasikan klaster yang tidak terenkripsi ke kluster yang dienkripsi menggunakan modul keamanan perangkat keras (HSM), Anda membuat klaster terenkripsi baru dan memindahkan data Anda ke klaster baru. Anda tidak dapat bermigrasi ke klaster terenkripsi HSM dengan memodifikasi klaster.
Untuk bermigrasi dari klaster yang tidak terenkripsi ke klaster terenkripsi HSM, pertama-tama Anda membongkar data Anda dari kluster sumber yang ada. Kemudian Anda memuat ulang data dalam cluster target baru dengan pengaturan enkripsi yang dipilih. Untuk informasi selengkapnya tentang meluncurkan cluster terenkripsi, lihat. [Enkripsi basis data Amazon Redshift](working-with-db-encryption.md)
Selama proses migrasi, kluster sumber Anda tersedia untuk kueri hanya-baca hingga langkah terakhir. Langkah terakhir adalah mengganti nama kluster target dan sumber, yang mengalihkan titik akhir sehingga semua lalu lintas diarahkan ke cluster target yang baru. Cluster target tidak tersedia sampai Anda reboot mengikuti penggantian nama. Tangguhkan semua beban data dan operasi penulisan lainnya di cluster sumber saat data sedang ditransfer.
**Untuk mempersiapkan migrasi**
1. Identifikasi semua sistem dependen yang berinteraksi dengan Amazon Redshift, misalnya alat intelijen bisnis (BI) dan mengekstrak, mengubah, dan memuat (ETL) sistem.
1. Identifikasi kueri validasi untuk menguji migrasi.
Misalnya, Anda dapat menggunakan kueri berikut untuk menemukan jumlah tabel yang ditentukan pengguna.
```
select count(*)
from pg_table_def
where schemaname != 'pg_catalog';
```
Query berikut mengembalikan daftar semua tabel yang ditentukan pengguna dan jumlah baris di setiap tabel.
```
select "table", tbl_rows
from svv_table_info;
```
1. Pilih waktu yang tepat untuk migrasi Anda. Untuk menemukan waktu ketika penggunaan cluster terendah, pantau metrik cluster seperti pemanfaatan CPU dan jumlah koneksi database. Untuk informasi selengkapnya, lihat [Melihat data kinerja cluster](performance-metrics-perf.md).
1. Jatuhkan tabel yang tidak digunakan.
Untuk membuat daftar tabel dan berapa kali setiap tabel telah ditanyakan, jalankan kueri berikut.
```
select database,
schema,
table_id,
"table",
round(size::float/(1024*1024)::float,2) as size,
sortkey1,
nvl(s.num_qs,0) num_qs
from svv_table_info t
left join (select tbl,
perm_table_name,
count(distinct query) num_qs
from stl_scan s
where s.userid > 1
and s.perm_table_name not in ('Internal worktable','S3')
group by tbl,
perm_table_name) s on s.tbl = t.table_id
where t."schema" not in ('pg_internal');
```
1. Luncurkan cluster baru yang dienkripsi.
Gunakan nomor port yang sama untuk cluster target seperti untuk cluster sumber. Untuk informasi selengkapnya tentang meluncurkan cluster terenkripsi, lihat. [Enkripsi basis data Amazon Redshift](working-with-db-encryption.md)
1. Atur proses bongkar muat dan muat.
Anda dapat menggunakan [Amazon Redshift Unload/Copy Utility](https://github.com/awslabs/amazon-redshift-utils/tree/master/src/UnloadCopyUtility) untuk membantu memigrasikan data antar cluster. Utilitas mengekspor data dari cluster sumber ke lokasi di Amazon S3. Data dienkripsi dengan. AWS KMS Utilitas kemudian secara otomatis mengimpor data ke target. Secara opsional, Anda dapat menggunakan utilitas untuk membersihkan Amazon S3 setelah migrasi selesai.
1. Jalankan tes untuk memverifikasi proses Anda dan memperkirakan berapa lama operasi penulisan harus ditangguhkan.
Selama operasi bongkar muat, pertahankan konsistensi data dengan menangguhkan beban data dan operasi penulisan lainnya. Menggunakan salah satu tabel terbesar Anda, jalankan proses bongkar muat untuk membantu Anda memperkirakan waktu.
1. Buat objek database, seperti skema, tampilan, dan tabel. Untuk membantu Anda menghasilkan pernyataan bahasa definisi data (DDL) yang diperlukan, Anda dapat menggunakan skrip di [AdminViews](https://github.com/awslabs/amazon-redshift-utils/tree/master/src/AdminViews)dalam repositori. AWS GitHub
**Untuk memigrasikan klaster**
1. Hentikan semua proses ETL pada cluster sumber.
Untuk mengonfirmasi bahwa tidak ada operasi penulisan dalam proses, gunakan Amazon Redshift Management Console untuk memantau penulisan IOPS. Untuk informasi selengkapnya, lihat [Melihat data kinerja cluster](performance-metrics-perf.md).
1. Jalankan kueri validasi yang Anda identifikasi sebelumnya untuk mengumpulkan informasi tentang kluster sumber yang tidak terenkripsi sebelum migrasi.
1. (Opsional) Buat satu antrian manajemen beban kerja (WLM) untuk menggunakan sumber daya maksimum yang tersedia di cluster sumber dan target. Misalnya, buat antrian bernama `data_migrate` dan konfigurasikan antrian dengan memori 95 persen dan konkurensi 4. *Untuk informasi selengkapnya, lihat [Perutean Kueri ke Antrian Berdasarkan Grup Pengguna dan Grup Kueri](https://docs.aws.amazon.com/redshift/latest/dg/tutorial-wlm-routing-queries-to-queues.html) di Panduan Pengembang Database Amazon Redshift.*
1. Menggunakan `data_migrate` antrian, jalankan file. UnloadCopyUtility
Pantau proses UNLOAD dan COPY menggunakan Amazon Redshift Console.
1. Jalankan kueri validasi lagi dan verifikasi bahwa hasilnya cocok dengan hasil dari cluster sumber.
1. Ganti nama sumber dan kluster target Anda untuk menukar titik akhir. Untuk menghindari gangguan, lakukan operasi ini di luar jam kerja.
1. Verifikasi bahwa Anda dapat terhubung ke cluster target menggunakan semua klien SQL Anda, seperti ETL dan alat pelaporan.
1. Matikan cluster sumber yang tidak terenkripsi.
# Memutar kunci enkripsi
Anda dapat menggunakan prosedur berikut untuk memutar kunci enkripsi dengan menggunakan konsol Amazon Redshift.
**Untuk memutar kunci enkripsi untuk sebuah cluster**
1. Masuk ke Konsol Manajemen AWS dan buka konsol Amazon Redshift di. [https://console.aws.amazon.com/redshiftv2/](https://console.aws.amazon.com/redshiftv2/)
1. Pada menu navigasi, pilih **Cluster**, lalu pilih cluster yang ingin Anda perbarui kunci enkripsi.
1. Untuk **Tindakan**, pilih **Putar enkripsi** untuk menampilkan halaman **Putar kunci enkripsi**.
1. Pada halaman **Putar kunci enkripsi**, pilih **Putar kunci enkripsi**.
# Enkripsi saat bergerak
Anda dapat mengonfigurasi lingkungan Anda untuk melindungi kerahasiaan dan integritas data dalam perjalanan.
Rincian berikut berlaku untuk enkripsi data dalam perjalanan antara kluster Amazon Redshift dan klien SQL melalui JDBC/ODBC:
+ Anda dapat terhubung ke cluster Amazon Redshift dari alat klien SQL melalui koneksi Java Database Connectivity (JDBC) dan Open Database Connectivity (ODBC).
+ Amazon Redshift mendukung koneksi Secure Sockets Layer (SSL) untuk mengenkripsi data dan sertifikat server untuk memvalidasi sertifikat server yang terhubung dengan klien. Klien terhubung ke node pemimpin cluster Amazon Redshift. Untuk informasi selengkapnya, lihat [Mengkonfigurasi opsi keamanan untuk koneksi](connecting-ssl-support.md).
+ Untuk mendukung koneksi SSL, Amazon Redshift membuat dan AWS Certificate Manager menginstal (ACM) mengeluarkan sertifikat di setiap klaster. Untuk informasi selengkapnya, lihat [Transisi ke sertifikat ACM untuk koneksi SSL](connecting-transitioning-to-acm-certs.md).
+ Untuk melindungi data Anda saat transit di dalam AWS Cloud, Amazon Redshift menggunakan SSL yang dipercepat perangkat keras untuk berkomunikasi dengan Amazon S3 atau Amazon DynamoDB untuk operasi COPY, UNLOAD, backup, dan restore.
Detail berikut berlaku untuk enkripsi data dalam perjalanan antara cluster Amazon Redshift dan Amazon S3 atau DynamoDB:
+ Amazon Redshift menggunakan SSL yang dipercepat perangkat keras untuk berkomunikasi dengan Amazon S3 atau DynamoDB untuk operasi COPY, UNLOAD, backup, dan restore.
+ Redshift Spectrum mendukung enkripsi sisi server (SSE) Amazon S3 menggunakan kunci default akun Anda yang dikelola oleh (KMS). AWS Key Management Service
+ Anda dapat mengenkripsi beban Amazon Redshift dengan Amazon S3 dan. AWS KMS Untuk informasi selengkapnya, lihat [Mengenkripsi Beban Amazon Redshift Anda dengan Amazon S3](https://aws.amazon.com/blogs/big-data/encrypt-your-amazon-redshift-loads-with-amazon-s3-and-aws-kms/) dan. AWS KMS
Detail berikut berlaku untuk enkripsi dan penandatanganan data dalam transit antaraAWS CLI, SDK, atau klien API dan titik akhir Amazon Redshift:
+ Amazon Redshift menyediakan titik akhir HTTPS untuk mengenkripsi data dalam perjalanan.
+ Untuk melindungi integritas permintaan API ke Amazon Redshift, panggilan API harus ditandatangani oleh pemanggil. Panggilan ditandatangani oleh sertifikat X.509 atau kunci akses AWS rahasia pelanggan sesuai dengan Proses Penandatanganan Versi Tanda Tangan 4 (Sigv4). Untuk informasi selengkapnya, lihat [Proses Penandatanganan Versi Tanda Tangan 4](https://docs.aws.amazon.com/general/latest/gr/signature-version-4.html) di *Referensi Umum AWS*.
+ Gunakan AWS CLI atau salah satu AWS SDKs untuk membuat permintaanAWS. Alat-alat ini secara otomatis menandatangani permintaan untuk Anda dengan kunci akses yang Anda tentukan saat Anda mengonfigurasi alat.
Rincian berikut berlaku untuk enkripsi data dalam perjalanan antara kluster Amazon Redshift dan editor kueri Amazon Redshift v2:
+ Data ditransmisikan antara editor kueri v2 dan cluster Amazon Redshift melalui saluran terenkripsi TLS.
# Kontrol enkripsi VPC dengan Amazon Redshift
Amazon Redshift mendukung [kontrol enkripsi VPC](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-encryption-controls.html), fitur keamanan yang membantu Anda menerapkan enkripsi saat transit untuk semua lalu lintas di dalam dan di seluruh Wilayah. VPCs Dokumen ini menjelaskan cara menggunakan kontrol enkripsi VPC dengan klaster Amazon Redshift dan grup kerja tanpa server.
Kontrol enkripsi VPC menyediakan kontrol terpusat untuk memantau dan menegakkan enkripsi saat transit di dalam Anda. VPCs Ketika diaktifkan dalam mode penegakan, ini memastikan bahwa semua lalu lintas jaringan dienkripsi baik di lapisan perangkat keras (menggunakan Sistem AWS Nitro) atau pada lapisan aplikasi (menggunakan TLS/SSL).
Amazon Redshift terintegrasi dengan kontrol enkripsi VPC untuk membantu Anda memenuhi persyaratan kepatuhan untuk industri seperti layanan kesehatan (HIPAA), pemerintah (FedRAMP), dan keuangan (PCI DSS).
## Cara kerja kontrol enkripsi VPC dengan Amazon Redshift
Kontrol enkripsi VPC beroperasi dalam dua mode:
+ Mode Monitor: Memberikan visibilitas ke dalam status enkripsi arus lalu lintas dan membantu mengidentifikasi sumber daya yang memungkinkan lalu lintas tidak terenkripsi.
+ Menegakkan Mode: Mencegah pembuatan atau penggunaan sumber daya yang memungkinkan lalu lintas tidak terenkripsi dalam VPC. Semua lalu lintas harus dienkripsi baik pada lapisan perangkat keras (instance berbasis Nitro) atau lapisan aplikasi (TLS/SSL).
## Persyaratan untuk menggunakan kontrol enkripsi VPC
**Persyaratan jenis instans**
Amazon Redshift memerlukan instans berbasis Nitro untuk mendukung kontrol enkripsi VPC. Semua jenis instans Redshift modern mendukung kemampuan enkripsi yang diperlukan.
**Persyaratan SSL/TLS**
Ketika kontrol enkripsi VPC diaktifkan dalam mode enforce, parameter require\$1ssl harus disetel ke true dan tidak dapat dinonaktifkan. Ini memastikan bahwa semua koneksi klien menggunakan koneksi TLS terenkripsi.
## Migrasi ke kontrol ecncryption VPC
**Untuk cluster dan kelompok kerja yang ada**
Anda tidak dapat mengaktifkan kontrol enkripsi VPC dalam mode penerapan pada VPC yang berisi klaster Redshift atau grup kerja tanpa server yang ada. Lihat langkah-langkah berikut untuk menggunakan kontrol enkripsi jika Anda memiliki klaster atau grup kerja yang ada:
1. Buat snapshot dari cluster atau namespace yang ada
1. Buat VPC baru dengan kontrol enkripsi VPC yang diaktifkan dalam mode penegakkan
1. Kembalikan dari snapshot ke VPC baru menggunakan salah satu operasi ini:
+ Untuk cluster yang disediakan: Gunakan operasi `restore-from-cluster-snapshot`
+ Untuk tanpa server: Gunakan `restore-from-snapshot` operasi di workgroup Anda
**Saat membuat cluster atau workgroup baru di VPC dengan kontrol enkripsi diaktifkan, parameter require\$1ssl harus disetel ke true.**
Amazon Redshift memerlukan instans berbasis Nitro untuk mendukung kontrol enkripsi VPC. Semua jenis instans Redshift modern mendukung kemampuan enkripsi yang diperlukan.
**Persyaratan SSL/TLS**
Ketika kontrol enkripsi VPC diaktifkan dalam mode enforce, parameter require\$1ssl harus disetel ke true dan tidak dapat dinonaktifkan. Ini memastikan bahwa semua koneksi klien menggunakan koneksi TLS terenkripsi.
## Pertimbangan dan batasan
Saat menggunakan kontrol enkripsi VPC di Amazon Redshift, pertimbangkan hal berikut:
**Pembatasan Negara VPC**
+ Pembuatan cluster dan workgroup diblokir saat kontrol enkripsi VPC dalam status `enforce-in-progress`
+ Anda harus menunggu hingga VPC mencapai `enforce` mode sebelum membuat sumber daya baru
**Konfigurasi SSL**
+ parameter require\$1ssl: Harus selalu `true` untuk cluster dan grup kerja yang dibuat dalam enkripsi yang diberlakukan VPCs
+ Setelah klaster atau grup kerja dibuat dalam `require_ssl` VPC yang diberlakukan enkripsi, tidak dapat dinonaktifkan selama masa pakainya
**Ketersediaan Wilayah**
Fitur ini tidak tersedia dalam mode penegakan dengan Amazon Redshift Tanpa Server di Wilayah berikut:
+ Amerika Selatan (Sao Paulo)
+ Europe (Zurich)
# Manajemen kunci
Anda dapat mengonfigurasi lingkungan Anda untuk melindungi data dengan kunci:
+ Amazon Redshift secara otomatis terintegrasi dengan AWS Key Management Service (AWS KMS) untuk manajemen kunci. AWS KMSmenggunakan enkripsi amplop. Untuk informasi selengkapnya, lihat [Enkripsi Amplop](https://docs.aws.amazon.com/kms/latest/developerguide/concepts.html#enveloping).
+ Saat kunci enkripsi dikelolaAWS KMS, Amazon Redshift menggunakan arsitektur berbasis kunci empat tingkat untuk enkripsi. Arsitektur terdiri dari kunci enkripsi data AES-256 yang dihasilkan secara acak, kunci database, kunci cluster, dan kunci root. Untuk informasi selengkapnya, lihat [Cara Penggunaan Amazon Redshift](https://docs.aws.amazon.com/kms/latest/developerguide/services-redshift.html). AWS KMS
+ Anda dapat membuat kunci yang dikelola pelanggan Anda sendiriAWS KMS. Untuk informasi selengkapnya, lihat [Membuat Kunci](https://docs.aws.amazon.com/kms/latest/developerguide/create-keys.html).
+ Anda juga dapat mengimpor materi kunci Anda sendiri untuk yang baruAWS KMS keys. Untuk informasi selengkapnya, lihat [Mengimpor Materi Utama di AWS Key Management Service (AWS KMS)](https://docs.aws.amazon.com/kms/latest/developerguide/importing-keys.html).
+ Amazon Redshift mendukung pengelolaan kunci enkripsi dalam modul keamanan perangkat keras eksternal ()HSMs. HSM dapat berada di tempat atau bisa. AWS CloudHSM Saat Anda menggunakan HSM, Anda harus menggunakan sertifikat klien dan server untuk mengonfigurasi koneksi tepercaya antara Amazon Redshift dan HSM Anda. Amazon Redshift hanya mendukung AWS CloudHSM Classic untuk manajemen kunci. Untuk informasi selengkapnya, lihat [Enkripsi menggunakan modul keamanan perangkat keras](working-with-db-encryption.md#working-with-HSM). Untuk informasi tentangAWS CloudHSM, lihat [Apa ituAWS CloudHSM?](https://docs.aws.amazon.com/cloudhsm/latest/userguide/introduction.html)
+ Anda dapat memutar kunci enkripsi untuk cluster terenkripsi.. Untuk informasi selengkapnya, lihat [Rotasi kunci enkripsi](working-with-db-encryption.md#working-with-key-rotation).