Petunjuk dan konteks
Tim Anda menyimpan analitik luring yang sensitif dan ekspor pelanggan dalam file DuckDB. Anda berencana untuk meningkatkan ke versi 1.4 LTS dan mengaktifkan enkripsi file basis data. Jelaskan batas cakupan, konfigurasi ATTACH, siklus hidup kunci, migrasi file lawas, pemulihan cadangan, dan validasi performa. Jelaskan juga mengapa hanya mengenkripsi file utama masih dapat meninggalkan kebocoran data.
Hal yang dievaluasi oleh pewawancara
- Apakah Anda membedakan file basis data, WAL, file sementara, cadangan, dan ekspor.
- Apakah Anda menggunakan
ENCRYPTION_KEY,ENCRYPTION_CIPHER, dan batasan versi penyimpanan DuckDB dengan benar. - Apakah rencana manajemen kunci Anda menjaga kunci tetap berada di luar SQL, log, dan citra (images).
- Apakah migrasi, simulasi pemulihan, dan tolok ukur (benchmarks) menunjukkan keamanan sekaligus kemampuan operasional.
Pertanyaan klarifikasi
- Apakah file basis data akan diunggah ke penyimpanan objek, disalin ke node analisis, atau ditulis ke direktori sementara?
- Apakah Anda hanya melindungi data saat diam (at rest), atau juga teks biasa (plaintext) yang dipegang oleh proses yang diotorisasi?
- Apakah versi DuckDB saat ini, bahasa klien, dan alat cadangan mendukung versi penyimpanan 1.4?
- Bisakah bisnis menulis ulang seluruh file selama rotasi, dan apa target pemulihan serta waktu henti (downtime)?
Jawaban 30 detik
Enkripsi basis data DuckDB 1.4 menggunakan AES-GCM 256-bit secara default dan mencakup basis data utama, WAL, dan file sementara; fitur ini memerlukan versi penyimpanan 1.4 atau yang lebih baru. Saya akan memasukkan kunci dari KMS atau pengelola rahasia (secret manager) saat runtime, mengeksposnya hanya ke proses berumur pendek, dan menjauhkannya dari SQL, argumen, dan log. Saya akan menyalin sumber untuk migrasi luring dan simulasi pemulihan, membuat salinan terenkripsi dengan ATTACH ... (ENCRYPTION_KEY ...), serta menguji pembacaan, penulisan, cadangan, dan kegagalan klien lawas. Tolok ukur akan membandingkan enkripsi, jalur OpenSSL melalui httpfs, dan konkurensi. Jika risiko atau performa tidak memenuhi kriteria kelulusan, saya akan menghentikan peluncuran dan mempertahankan versi lama di bawah kontrol akses yang ketat.
Pembahasan mendalam
1. Menentukan batas perlindungan
Dokumentasi resmi menyatakan bahwa enkripsi mencakup basis data utama, WAL, dan file sementara, tetapi tidak secara otomatis melindungi Parquet yang diekspor, log, salinan cache, atau teks biasa dalam memori. Petakan siklus hidup file dan jalur replikasi sebelum menetapkan tujuan untuk enkripsi saat diam, izin proses, dan akses cadangan.
2. Memilih cipher dan versi penyimpanan
GCM adalah mode terotentikasi default; CBC dan CTR dapat dikonfigurasi tetapi memerlukan evaluasi eksplisit terkait integritas dan kompatibilitas. Enkripsi mengimplikasikan versi penyimpanan 1.4 atau yang lebih baru, sehingga biner DuckDB yang lebih lama mungkin tidak dapat membuka file tersebut. Tempatkan pemeriksaan versi dalam skrip startup dan pemulihan alih-alih baru menemukan ketidakcocokan setelah peningkatan.
3. Mengelola kunci, bukan sekadar string
Dapatkan kunci dari KMS, pengelola rahasia, atau identitas beban kerja berumur pendek dan masukkan ke dalam memori atau deskriptor file yang dilindungi. Jangan pernah melakukan commit ENCRYPTION_KEY ke repositori, lapisan citra, riwayat shell, log SQL, atau trace. Rotasi biasanya menulis ulang basis data dengan kunci baru, memverifikasinya, mengganti file secara atomik, dan menyimpan salinan rollback yang terkendali.
4. Memigrasikan dan memulihkan cadangan
Lakukan checksum dan buat snapshot sumber secara read-only, buat salinan terenkripsi dalam tugas terkontrol, dan bandingkan jumlah baris, statistik, serta hasil kueri penting tabel demi tabel. Cadangan harus mencakup file terenkripsi, versi kunci, dan urutan pemulihan. Hanya mencadangkan file utama sambil melewatkan WAL atau ekspor sementara dapat menyebabkan kegagalan pemulihan atau kebocoran data.
5. Memvalidasi performa dan kegagalan operasional
Ukur pemindaian cold-cache, penulisan, lonjakan WAL, tumpahan sementara (temporary spills), dan pembacaan bersamaan secara terpisah. Memuat httpfs dapat memanfaatkan OpenSSL dan akselerasi perangkat keras untuk jalur enkripsi yang lebih cepat, tetapi verifikasi hal tersebut pada platform target. Lakukan simulasi kunci yang salah atau hilang, klien lama, disk penuh, dan ketidaktersediaan KMS sehingga kesalahan dapat terlihat jelas dan tidak pernah secara diam-diam turun ke teks biasa.
Contoh jawaban berkualitas tinggi
Saya akan memperlakukan setiap file DuckDB sebagai aset sensitif yang memiliki siklus hidup. Saya akan memetakan file utama, WAL, direktori sementara, cadangan, ekspor, dan salinan penyimpanan objek; kemudian membuat salinan terenkripsi dengan default 1.4 LTS AES-256-GCM dan mendokumentasikan batas versi penyimpanan. KMS menyediakan kunci saat runtime, tidak pernah melalui SQL, citra, log, atau baris perintah. Rotasi menulis ulang dan memverifikasi salinan, menukarnya secara atomik, dan mempertahankan salinan rollback yang terkendali. Sebelum peluncuran, saya akan menjalankan pemeriksaan tingkat tabel, simulasi pemulihan, dan tolok ukur cold/hot-cache, termasuk WAL dan file sementara. Kegagalan KMS, klien lawas, atau gerbang performa akan menghentikan peluncuran dan mempertahankan versi lama di bawah izin yang ketat sementara risiko dan pengujian berikutnya dicatat.
Kesalahan umum
- Hanya mengenkripsi file utama dan mengabaikan WAL, file sementara, cadangan, serta ekspor.
- Mengodekan kunci secara permanen (hard-coding) di SQL, citra, riwayat shell, atau log.
- Mengabaikan batas kompatibilitas versi penyimpanan 1.4 dan merusak klien lama.
- Mengklaim bahwa GCM, CBC, dan CTR setara dalam hal keamanan dan performa.
- Melewatkan pengujian untuk kunci salah, pemadaman KMS, disk penuh, dan urutan pemulihan.
- Hanya mengukur waktu kueri rata-rata alih-alih cold cache, tumpahan ke disk, dan pembacaan bersamaan.
Pertanyaan lanjutan dan jawaban
Bisakah data tetap bocor setelah enkripsi?
Bisa. Ekspor, log, cache, memori, dan proses apa pun yang dapat membaca kunci dapat mengekspos teks biasa. Model ancaman harus mencakup siklus hidup file, izin proses, akses cadangan, dan audit kunci.
Bagaimana Anda merotasi kunci basis data?
Tulis ulang salinan dengan kunci baru di direktori terisolasi, verifikasi checksum dan pemulihan, lalu ganti secara atomik. Simpan kunci lama hanya selama jendela rollback sebelum mencabut dan mengauditnya di KMS.
Mengapa memuat httpfs?
DuckDB mendokumentasikan bahwa jalur OpenSSL dapat menggunakan akselerasi perangkat keras dan biasanya lebih cepat daripada mbedtls bawaan. Perlakukan hal itu sebagai hipotesis yang perlu diuji tolok ukurnya pada platform target, bukan sebagai hasil performa yang pasti.