Wawancara Data Engineering: Bagaimana Anda Melindungi Kolom Parquet yang Sensitif?

Masalah dan cakupan

Sebuah data lake menyimpan alamat email, pengidentifikasi pembayaran, wilayah, dan agregat publik dalam file Parquet yang sama. Penyimpanan objek, layanan metadata, dan klaster komputasi dimiliki oleh tim yang berbeda. Job yang berwenang hanya boleh membaca kolom yang diperlukan; pembaca yang tidak berwenang tidak boleh melihat nilai sensitif atau metadata yang mengungkap identitas. Rancang enkripsi tingkat kolom dan manajemen kunci, lalu diskusikan footer, indeks, predicate pushdown, rotasi, pembaca lama, dan pemulihan (recovery).

Apache Parquet Modular Encryption melindungi modul-modul yang diserialisasi secara terpisah seperti page, page header, column index, offset index, Bloom filter, dan footer sambil tetap mempertahankan opsi proyeksi kolom, predicate pushdown, encoding, dan kompresi reguler. Jawaban yang kuat memisahkan data terenkripsi, metadata yang dilindungi, otorisasi kunci, dan bukti bahwa operasi baca serta tulis berjalan dengan benar.

Apa yang diuji oleh pewawancara

• Bisakah Anda menjelaskan hubungan antara kunci kolom, kunci footer, kunci enkripsi data (DEK), dan kunci master?
• Apakah Anda tahu bahwa mengenkripsi kolom sensitif saja masih dapat mengekspos skema, statistik, atau petunjuk identitas?
• Bisakah Anda membandingkan footer terenkripsi dan footer teks biasa (plaintext) dari segi keamanan, kompatibilitas, dan biaya migrasi?
• Apakah Anda memahami integritas AES-GCM dan pengikatan AAD, serta batasan dari page CTR?
• Bisakah Anda menghubungkan KMS, otorisasi, rotasi, cadangan, kegagalan kueri, dan audit ke dalam sebuah rancangan yang dapat dieksekusi?

Jawaban yang lemah hanya mengatakan "gunakan AES-256 untuk file tersebut." Jawaban yang kuat membuktikan modul Parquet mana yang dilindungi, job mana yang bisa mendapatkan kunci apa, dan apa yang harus dikorbankan oleh pembaca lama serta predicate pushdown.

Pertanyaan klarifikasi yang perlu diajukan terlebih dahulu

1. Apakah skema, jumlah baris, dan statistik harus disembunyikan, atau hanya nilai kolom? Hal ini menentukan apakah footer harus dienkripsi.
2. Job, tenant, dan kolom mana yang boleh dibaca bersama-sama? Ini mendefinisikan domain kunci kolom dan batasan kebijakan KMS.
3. Apakah query engine dan pustaka PyArrow/Parquet miliknya mendukung Modular Encryption? Jika tidak, jalur baca/tulis tidak dapat beralih secara langsung.
4. Haruskah pembaca lama tetap dapat membaca kolom yang tidak dienkripsi? Hal ini menentukan apakah transisi menggunakan footer plaintext dapat diterima.
5. Apakah file berupa partisi yang tidak dapat diubah (immutable) atau ditimpa, disalin, dan diputar ulang (replayed)? Ini menentukan identitas AAD, rotasi, dan deteksi replay.

Jawaban 30 detik

"Pertama-tama saya akan memutuskan apakah footer dan statistik bersifat sensitif, kemudian menentukan domain akses berdasarkan kolom. Setiap file atau kolom mendapatkan DEK acak yang dibungkus oleh MEK atau KEK yang dikelola KMS; page kolom, header, indeks, dan metadata kolom yang diperlukan menggunakan kunci kolom, sedangkan footer dilindungi secara terpisah. Saya lebih memilih AES-GCM karena memberikan kerahasiaan dan integritas, serta mengikat tabel, partisi, versi file, dan identitas modul melalui AAD untuk mencegah penggantian. Jika pembaca lama harus membaca kolom publik, footer plaintext dapat menjadi transisi dengan batas waktu tertentu, tetapi mengekspos sebagian metadata; kumpulan data sensitif dengan kerahasiaan skema yang ketat harus menggunakan footer terenkripsi. Saya akan memverifikasi otorisasi KMS, rotasi, predicate pushdown, pemulihan kesalahan, perilaku pembaca lama, dan kasus perusakan (tampering) sebelum peluncuran."

Penalaran langkah demi langkah

1. Buat daftar modul Parquet yang memerlukan perlindungan

Parquet bukanlah kotak hitam yang hanya memiliki area data. Page dan page header memuat nilai; column index, offset index, dan Bloom filter dapat mengungkap rentang nilai atau distribusi; footer berisi skema, jumlah baris, informasi pengurutan, statistik, dan metadata key-value. Mengenkripsi page kolom saja masih dapat mengekspos kategori pelanggan atau rentang waktu.

file
├── row-group
│   └── column chunk
│       ├── dictionary/data pages
│       ├── page headers
│       ├── column index
│       ├── offset index
│       └── bloom-filter modules
└── footer / FileMetaData

Gunakan model ancaman (threat model) untuk memilih cakupan perlindungan. Kolom dengan tingkat sensitivitas rendah dapat tetap dapat dibaca oleh alat-alat lama; kolom sensitif beserta statistik, skema, dan identitas filenya memerlukan perlindungan footer dan metadata kolom yang lebih kuat. Keputusan ini jauh lebih penting daripada sekadar memilih panjang kunci AES secara terpisah.

2. Rancang enkripsi amplop dan batasan akses

Berikan kunci enkripsi data (DEK) acak untuk setiap file atau kolom, yang dibungkus oleh master encryption key (MEK) atau key-encryption key (KEK). Simpan MEK di KMS organisasi. Sebuah job menerima izin pembukaan bungkus (unwrap) melalui identitas berumur pendek; penyimpanan objek hanya berisi ciphertext dan metadata kunci yang diperlukan, bukan kunci master plaintext.

authorized job -> KMS policy -> unwrap DEK -> decrypt footer/columns
object storage  -> ciphertext + key metadata only

Pisahkan kunci kolom berdasarkan tenant, domain data, atau sensitivitas sehingga satu job tidak menerima izin untuk keseluruhan tabel. Metadata kunci dapat berupa KMS key ID, pengidentifikasi material terbungkus, atau referensi eksternal; ini bukan rahasia itu sendiri tetapi memengaruhi audit dan rotasi. Selama rotasi kunci master, bungkus ulang DEK terlebih dahulu. Jangan menulis ulang semua data page yang bersifat immutable hanya karena MEK berubah.

3. Pilih antara footer terenkripsi dan footer plaintext

Footer terenkripsi menyembunyikan skema, jumlah baris, nama kolom, informasi pengurutan, dan metadata kolom lainnya. Ini memberikan batasan yang lebih kuat, tetapi setiap pembaca file sensitif harus mendukung enkripsi modular. Parquet menggunakan magic bytes PARE untuk file ber-footer terenkripsi, sehingga pembaca lama yang mengharapkan PAR1 dapat langsung menolak format tersebut.

Footer plaintext memungkinkan pembaca lama melihat beberapa metadata dan membaca kolom yang tidak dienkripsi. Mereka tidak dapat membaca data kolom yang dienkripsi, sementara footer ditandatangani untuk menjamin integritas. Ini dapat menjadi mode migrasi dengan batas waktu tertentu, bukan pengganti keamanan ketika data statistik bersifat sensitif.

Uji matriks pembaca: bisakah engine menemukan kolom terenkripsi, apakah akses tanpa izin gagal, bisakah kueri khusus publik tetap melakukan pushdown predikat, dan apakah pembaca lama melaporkan kesalahan enkripsi tidak didukung secara eksplisit alih-alih menganggap file tersebut rusak (corrupt)?

4. Pilih algoritma dan ikat AAD

AES-GCM menyediakan enkripsi dan tag autentikasi. AAD mengikat tabel, partisi, versi file, dan posisi modul ke ciphertext, mencegah penyerang mengganti file saat ini, partisi lain, atau row group lain di bawah kunci yang sama. Nonce acak harus tetap unik untuk satu kunci, dan batas pemanggilan kunci harus dikelola di seluruh proses penulisan.

Parquet juga mendefinisikan AESGCMCTRV1: modul non-page menggunakan GCM sedangkan data page menggunakan CTR untuk meningkatkan throughput. Page CTR tidak memiliki integritas terautentikasi seperti GCM. Jika model ancaman memerlukan deteksi perusakan (tamper detection) pada page, prioritaskan AESGCM_V1 daripada hanya memilih berdasarkan kecepatan CPU.

5. Pertahankan kemampuan kueri dan definisikan jalur kegagalan

Enkripsi diterapkan pada page terkompresi dan modul lainnya, sehingga format tersebut tetap dapat menjalankan proyeksi, predicate pushdown, encoding, dan kompresi. Planner kueri dapat membaca footer atau indeks yang terlihat dan hanya meminta kolom yang diizinkan. Namun, jika footer atau column index dienkripsi, planner memerlukan izin dekripsi terkait; pernyataan "saya hanya mengueri kolom publik" tidak secara otomatis berarti "tidak memerlukan kunci."

Catat kegagalan dekripsi, batas waktu KMS (timeout), izin yang dicabut, ketidakcocokan AAD, dan kegagalan tag autentikasi secara terpisah. Jangan pernah beralih kembali ke plaintext secara diam-diam dan jangan melabeli setiap kegagalan sebagai file rusak. Simpan ID file, metadata kunci, versi algoritma, dan audit principal, tetapi jangan pernah mencatat DEK, nilai plaintext, atau materi kunci lengkap ke dalam log.

6. Verifikasi rotasi, perusakan data, dan pemulihan bencana

Uji pembacaan kolom sensitif tanpa izin, pembacaan kolom publik yang diizinkan, pembacaan sensitif yang diizinkan, penggantian file lama, pertukaran row group, pengeditan page ciphertext, penolakan KMS, pembacaan pasca-rotasi, dan pemulihan lintas-wilayah (cross-region). Untuk setiap pengujian, catat kesalahan yang diharapkan, apakah ada plaintext yang dikembalikan, dan event auditnya.

Pemulihan memerlukan file terenkripsi, metadata kunci, pemetaan versi kunci KMS, dan identitas file AAD. Memulihkan penyimpanan tanpa izin KMS akan menghasilkan file yang tidak dapat dibaca; memulihkan KMS tanpa awalan AAD dapat mencegah verifikasi identitas file. Pertahankan versi kunci lama selama jendela validasi snapshot, replay, dan cadangan sebelum dimusnahkan.

Contoh jawaban berkualitas tinggi

"Saya akan mulai dengan menentukan model ancaman: apakah skema, jumlah baris, dan statistik harus disembunyikan, dan job mana yang dapat membaca kolom mana? Parquet Modular Encryption dapat melindungi tidak hanya page kolom tetapi juga page header, column index, offset index, Bloom filter, dan footer. Saya akan menghasilkan DEK acak untuk file atau kolom dan membungkusnya dengan MEK/KEK di KMS. Job mendapatkan izin unwrap melalui identitas berumur pendek, dan file hanya berisi metadata kunci yang dapat diaudit.

Untuk batasan yang menyeluruh, saya akan menggunakan footer terenkripsi. Jika pembaca lama harus mengakses kolom publik, saya akan menggunakan migrasi footer plaintext dengan batas waktu tertentu dan mendokumentasikan metadata yang terekspos. Saya lebih memilih AES-GCM dengan AAD yang mengikat tabel, partisi, versi file, dan identitas modul, serta tidak akan mengorbankan integritas page hanya karena page CTR lebih cepat. Sebelum peluncuran, saya akan menguji proyeksi dan predicate pushdown, penolakan KMS, perusakan AAD, rotasi kunci, pemulihan lintas-wilayah, dan perilaku sistem lama. Log tidak akan memuat DEK, plaintext, dan materi kunci. Rancangan ini membuat enkripsi, otorisasi, perilaku kueri, dan pemulihan dapat diuji secara independen."

Kesalahan umum

• Hanya menggunakan enkripsi tingkat penyimpanan → siapa pun yang memiliki akses ke objek dapat membaca setiap kolom → rancang batasan pada kolom, footer, dan modul.
• Mengenkripsi page sensitif tetapi membiarkan footer terbuka → skema, statistik, dan jumlah baris dapat bocor → pilih footer terenkripsi atau nyatakan paparan footer plaintext secara eksplisit.
• Memperlakukan DEK sebagai master key jangka panjang → kebocoran satu file memperluas dampak rotasi dan pencabutan izin → bungkus DEK acak dengan KMS MEK atau KEK.
• Mengabaikan AAD → file lama atau partisi lain di bawah kunci yang sama dapat disubstitusi → ikat identitas file serta modul dan uji kasus penukaran (swap).
• Menyebut AESGCMCTR_V1 terautentikasi penuh → page CTR mungkin tidak memiliki autentikasi page GCM → pilih berdasarkan persyaratan integritas dan uji ketahanan terhadap perusakan.
• Menghapus kunci lama segera setelah rotasi → snapshot, cadangan, dan job replay tidak dapat dipulihkan → pertahankan pemetaan versi dan jendela retensi kunci lama yang terkontrol.

Pertanyaan lanjutan dan tanggapan

Pembaca lama harus tetap membaca kolom publik. Bagaimana Anda melakukan migrasi?

Gunakan footer plaintext untuk sementara waktu sambil mengenkripsi data page kolom sensitif, dan biarkan pembaca lama hanya mengakses kolom publik. Ukur skema dan statistik yang terekspos, tetapkan batas waktu peningkatan (upgrade), lalu beralih ke footer terenkripsi setelah cakupan pembaca baru dan pengujian replay berhasil. Pertahankan versi file untuk rollback.

Bagaimana Anda mencegah page dari partisi lain disalin ke dalam file ini?

Bangun identitas AAD yang stabil dari file, tabel, partisi, row group, dan modul. Ketidakcocokan apa pun harus menggagalkan autentikasi. Uji pertukaran versi lama, lintas partisi, dan lintas kolom di bawah kunci yang sama, serta verifikasi bahwa semuanya ditolak.

Apakah setiap pembacaan page memerlukan round trip ke KMS?

Tidak. Lakukan unwrap DEK atau KEK melalui KMS, lalu simpan materi kunci berumur pendek di dalam cache proses yang terkontrol. Batasi cakupan cache dan TTL, batalkan (invalidate) saat terjadi rotasi atau pencabutan izin, serta pantau kegagalan KMS dan rasio cache hit. Jangan letakkan panggilan KMS pada jalur kritis (hot path) pembacaan page.

Mengapa tidak menggunakan AES-CTR saja untuk throughput yang lebih tinggi?

CTR tidak mengautentikasi integritas, sehingga modifikasi pada page mungkin tidak terdeteksi. Gunakan AES-GCM jika model ancaman memerlukan deteksi perusakan. Pertimbangkan CTR hanya jika kompromi integritas telah disetujui secara eksplisit dan mekanisme integritas luar telah diverifikasi.

Bagaimana Anda membuktikan bahwa predicate pushdown tidak memotong jalur otorisasi?

Jalankan kueri khusus publik, filter sensitif, dan proyeksi sensitif di bawah identitas yang berwenang dan tidak berwenang. Periksa modul yang diminta dan izin KMS. Catatan audit harus menghubungkan kueri, file, kolom, metadata kunci, dan alasan penolakan; verifikasi akhir jumlah baris saja tidak cukup.