Enkripsi basis data Amazon Redshift - Amazon Redshift
Peningkatan proses enkripsi untuk kinerja dan ketersediaan yang lebih baikEnkripsi menggunakan AWS KMSEnkripsi menggunakan modul keamanan perangkat kerasRotasi kunci enkripsi

Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.

Enkripsi basis data Amazon Redshift

Di Amazon Redshift, Anda dapat mengaktifkan enkripsi database untuk cluster Anda untuk membantu melindungi data saat istirahat. Saat Anda mengaktifkan enkripsi untuk klaster, blok data dan metadata sistem dienkripsi untuk cluster dan snapshot-nya.

Anda dapat mengaktifkan enkripsi saat meluncurkan klaster, atau memodifikasi klaster yang tidak terenkripsi untuk menggunakan enkripsi AWS Key Management Service ()AWS KMS. Untuk melakukannya, Anda dapat menggunakan kunci AWS-managed 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.

Meskipun enkripsi adalah pengaturan opsional di Amazon Redshift, kami menyarankan Anda mengaktifkannya untuk cluster yang berisi data sensitif. Selain itu, Anda mungkin diminta untuk menggunakan enkripsi tergantung pada pedoman atau peraturan yang mengatur data Anda. Misalnya, Standar Keamanan Data Industri Kartu Pembayaran (PCIDSS), Sarbanes-Oxley Act ()SOX, Undang-Undang Portabilitas dan Akuntabilitas Asuransi Kesehatan (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 file. HSM Bila Anda menggunakanHSM, Anda harus menggunakan sertifikat klien dan server untuk mengonfigurasi koneksi tepercaya antara Amazon Redshift dan Anda. HSM

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 klaster ke kluster 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 cluster Anda, jika Anda berencana untuk terus menjalankan beban kerja database, Anda dapat meningkatkan kinerja dan mempercepat proses dengan menambahkan node dengan mengubah 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 pembaruan baru (pembaruan/hapus/sisipan) 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 lebih lanjut, lihat CREATETABLEatau CREATEMATERIALIZEDVIEW.

Topik

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 meluncurkan klaster, Amazon Redshift mengembalikan daftar AWS akun AWS KMS keys yang telah dibuat atau memiliki izin untuk digunakan. AWS KMS Anda memilih KMS kunci untuk digunakan sebagai kunci root Anda dalam hierarki enkripsi.

Secara default, Amazon Redshift memilih kunci default Anda sebagai kunci root. Kunci default Anda adalah kunci AWS-managed yang dibuat agar AWS akun Anda dapat digunakan di Amazon Redshift. AWS KMS membuat kunci ini saat pertama kali Anda meluncurkan cluster terenkripsi di AWS Wilayah dan memilih kunci default.

Jika Anda tidak ingin menggunakan kunci default, Anda harus memiliki (atau membuat) KMS kunci 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 KMS kunci, lihat Membuat Kunci 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 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 yang dienkripsi ke Amazon CEK Redshift, di mana ia disimpan secara internal pada disk dalam jaringan terpisah dari cluster bersama dengan hibah ke KMS kunci dan konteks enkripsi untuk file. CEK Hanya yang dienkripsi yang CEK diekspor ke Amazon Redshift; kuncinya tetap ada. KMS AWS KMS Amazon Redshift juga meneruskan terenkripsi CEK melalui saluran aman ke cluster dan memuatnya ke dalam memori. Kemudian, Amazon Redshift memanggil AWS KMS untuk mendekripsi CEK dan memuat yang didekripsi ke dalam memori. CEK Untuk informasi selengkapnya tentang hibah, konteks enkripsi, dan konsep AWS KMS terkait lainnya, lihat Konsep dalam Panduan AWS Key Management Service Pengembang.

Selanjutnya, Amazon Redshift secara acak menghasilkan kunci untuk digunakan sebagai DEK dan memuatnya ke dalam memori di cluster. Dekripsi CEK digunakan untuk mengenkripsiDEK, yang kemudian dilewatkan melalui saluran aman dari cluster untuk disimpan secara internal oleh Amazon Redshift pada disk di jaringan terpisah dari cluster. SepertiCEK, baik versi terenkripsi dan didekripsi dimuat ke dalam memori di DEK cluster. Versi yang didekripsi kemudian DEK digunakan untuk mengenkripsi kunci enkripsi individu yang dihasilkan secara acak untuk setiap blok data dalam database.

Ketika cluster reboot, Amazon Redshift dimulai dengan versi terenkripsi yang disimpan secara internal dan, memuat ulang ke dalam memori, DEK dan kemudian AWS KMS memanggil untuk mendekripsi CEK dengan KMS kunci lagi sehingga dapat dimuat ke dalam memori. CEK Yang didekripsi kemudian CEK digunakan untuk mendekripsi DEK lagi, dan yang didekripsi dimuat ke dalam memori dan digunakan untuk mengenkripsi DEK dan mendekripsi kunci blok data sesuai kebutuhan.

Untuk informasi selengkapnya tentang membuat klaster Amazon Redshift yang dienkripsi dengan kunci, lihat. AWS KMS Membuat klaster

Menyalin AWS KMS—snapshot terenkripsi ke Wilayah lain AWS

AWS KMS kunci khusus untuk suatu AWS Wilayah. Jika Anda mengaktifkan penyalinan snapshot Amazon Redshift ke Wilayah AWS lain, dan cluster sumber serta snapshot-nya dienkripsi menggunakan kunci root AWS KMS dari, Anda perlu mengonfigurasi hibah untuk Amazon Redshift untuk menggunakan kunci root di Wilayah tujuan. AWS Hibah ini memungkinkan Amazon Redshift mengenkripsi snapshot di Wilayah tujuan. AWS Untuk informasi selengkapnya tentang salinan snapshot lintas wilayah, lihat. Menyalin snapshot ke yang lain AWS Wilayah

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 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.

  2. 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, atau. API 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 AWS KMS—kluster terenkripsi

Sebelum snapshot disalin ke AWS Wilayah tujuan, Amazon Redshift mendekripsi snapshot menggunakan kunci root di Wilayah AWS sumber dan mengenkripsi ulang sementara menggunakan kunci yang dibuat secara acak yang dikelola Amazon Redshift secara internal. RSA Amazon Redshift kemudian menyalin snapshot melalui saluran aman ke AWS Wilayah tujuan, mendekripsi snapshot menggunakan kunci yang dikelola secara internal, dan kemudian mengenkripsi ulang snapshot menggunakan RSA kunci root di Wilayah tujuan. AWS

Enkripsi menggunakan modul keamanan perangkat keras

Jika tidak digunakan AWS KMS untuk manajemen kunci, Anda dapat menggunakan modul keamanan perangkat keras (HSM) untuk manajemen kunci dengan Amazon Redshift.

penting

HSMenkripsi tidak didukung untuk DC2 dan tipe RA3 node.

HSMsadalah 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 Cloud HSM Classic. AWS CloudHSM Klasik tidak tersedia di semua AWS Wilayah. Untuk informasi selengkapnya tentang AWS Wilayah yang tersedia, lihat Tabel AWS Wilayah.

Saat Anda mengonfigurasi klaster Anda untuk menggunakanHSM, Amazon Redshift mengirimkan permintaan ke HSM untuk menghasilkan dan menyimpan kunci untuk digunakan sebagai. CEK Namun, tidak seperti AWS KMS, HSM tidak mengekspor CEK ke Amazon Redshift. Sebagai gantinya, Amazon Redshift secara acak menghasilkan DEK dalam cluster dan meneruskannya ke yang akan dienkripsi oleh. HSM CEK Ini HSM mengembalikan yang dienkripsi DEK 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 terdekripsi DEK dalam memori di cluster sehingga DEK dapat digunakan untuk mengenkripsi dan mendekripsi kunci individual untuk blok data.

Jika cluster di-boot ulang, Amazon Redshift mendekripsi yang disimpan secara internal, dienkripsi DEK ganda menggunakan kunci root internal untuk mengembalikan penyimpanan internal ke status -enkripsi. DEK CEK CEK-Encrypted kemudian diteruskan ke yang akan DEK didekripsi dan diteruskan kembali ke Amazon Redshift, di mana ia dapat dimuat dalam memori lagi untuk digunakan dengan kunci blok data individual. HSM

Mengonfigurasi koneksi tepercaya antara Amazon Redshift dan HSM

Ketika Anda memilih untuk menggunakan HSM for management dari kunci cluster Anda, Anda perlu mengonfigurasi tautan jaringan tepercaya antara Amazon Redshift dan Anda. HSM Melakukan hal ini memerlukan konfigurasi sertifikat klien dan server. Koneksi tepercaya digunakan untuk meneruskan kunci enkripsi antara Amazon Redshift HSM dan Amazon 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 AndaHSM, dan menetapkannya ke HSM partisi yang berlaku.

Anda memberikan Amazon Redshift dengan alamat HSM IP, nama HSM partisi, kata sandi HSM partisi, dan sertifikat HSM server publik, yang dienkripsi dengan menggunakan kunci root internal. Amazon Redshift menyelesaikan proses konfigurasi dan memverifikasi bahwa ia dapat terhubung ke file. HSM Jika tidak bisa, cluster dimasukkan ke dalam HSM status INCOMPATIBLE _ 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 HSM partisi 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.

Setelah konfigurasi awal, jika Amazon Redshift gagal terhubung keHSM, peristiwa dicatat. Untuk informasi selengkapnya tentang peristiwa ini, lihat Pemberitahuan Acara Amazon Redshift.

Rotasi kunci enkripsi

Di Amazon Redshift, Anda dapat memutar kunci enkripsi untuk cluster terenkripsi. Saat Anda memulai proses rotasi kunci, Amazon Redshift memutar untuk cluster yang ditentukan dan CEK untuk snapshot cluster otomatis atau manual apa pun. Amazon Redshift juga memutar DEK untuk cluster yang ditentukan, tetapi tidak dapat memutar snapshot saat disimpan secara internal di Amazon Simple Storage Service (Amazon S3) dan dienkripsi menggunakan yang sudah ada. DEK DEK

Saat rotasi sedang berlangsung, cluster dimasukkan ke dalam KEYS status ROTATING _ hingga selesai, pada saat itu cluster kembali ke AVAILABLE keadaan. 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, lihatMemutar kunci enkripsi.