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

Peningkatan proses enkripsi untuk kinerja dan ketersediaan yang lebih baik

Enkripsi dengan node RA3

Pembaruan proses enkripsi untuk node RA3 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 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 node DC2, Anda tidak memiliki kemampuan untuk menjalankan kueri tulis, seperti dengan node RA3. Hanya kueri baca yang dapat dijalankan.

Catatan penggunaan untuk enkripsi dengan node RA3

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 selengkapnya, lihat MEMBUAT TABEL atau MEMBUAT TAMPILAN TERWUJUD.

Topik

• Enkripsi database untuk Amazon Redshift menggunakan AWS KMS
• Enkripsi untuk Amazon Redshift menggunakan modul keamanan perangkat keras
• Rotasi kunci enkripsi di Amazon Redshift
• Mengubah enkripsi cluster
• Mengkonfigurasi enkripsi basis data menggunakan konsol
• Mengkonfigurasi enkripsi database menggunakan Amazon Redshift API danAWS CLI

Enkripsi database untuk Amazon Redshift 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 kunci KMS 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) 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 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 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 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 melewati 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 AWS KMS kunci, lihat dan. Membuat klaster Mengelola cluster menggunakan Amazon AWS CLI Redshift dan Amazon API

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 Wilayah lain AWS

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 API, atau SDK. 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. Konfigurasikan salinan snapshot lintas wilayah untuk kluster yang AWS KMS dienkripsi

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

Untuk informasi selengkapnya tentang mengonfigurasi hibah salinan snapshot untuk cluster AWS KMS-enkripsi, lihat. Mengkonfigurasi Amazon Redshift untuk digunakanAWS KMSkunci enkripsi menggunakan Amazon Redshift API danAWS CLI

Enkripsi untuk Amazon Redshift 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 tipe node DC2 dan RA3.

HSM 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 basis data. 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. 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 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 cluster 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_HSM 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 HSM.

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

Rotasi kunci enkripsi di Amazon Redshift

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_KEYS 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 menggunakan konsol Amazon Redshift danMemutar kunci enkripsi menggunakan Amazon Redshift API danAWS CLI.