Petunjuk dan cakupan
Data bisnis berada di penyimpanan objek, tabel lakehouse, dan warehouse; para analis menggunakan SQL, Spark, dan alat BI. Akses dikelola melalui tiket manual dan akun mesin lokal. Proses offboarding berjalan lambat, dan audit tidak dapat merekonstruksi kueri lintas akun. Tujuannya adalah permintaan mandiri (self-service), hak istimewa paling rendah (least privilege), perlindungan baris dan kolom, akses darurat, dan satu jejak audit terpadu.
Rancang lapisan tata kelola: klasifikasi, pemberi persetujuan, titik keputusan dan penegakan kebijakan (policy decision and enforcement points), cakupan multimesin, break-glass, pencabutan hak akses, cache, ekspor, dan bukti bahwa otorisasi serta pembacaan aktual dapat diaudit. Keterampilan intinya adalah tata kelola dan operasi platform data, jadi ini adalah pertanyaan data.
Apa yang dievaluasi oleh pewawancara
Pewawancara mencari siklus katalog, kebijakan, penegakan, bukti, dan operasi daripada sekadar "menambahkan RBAC". Jawaban yang kuat membedakan identitas, tujuan, label sumber daya, filter baris/kolom, dan penyamaran (masking), serta menjelaskan batasan antara keputusan dan penegakan.
Mereka juga memperhatikan konsistensi lintas layanan. Pengguna yang sama saat mengakses Athena, Spark, BI, atau tugas ekspor tidak boleh kehilangan konteks otorisasi atau bidang audit. Log harus terbukti bebas dari manipulasi (tamper-evident), dapat dicari, disimpan secara terencana, dan mencakup penolakan, perubahan administratif, serta akses darurat—bukan hanya kueri yang berhasil.
Pertanyaan untuk diklarifikasi terlebih dahulu
- Sumber data, mesin, penyedia identitas, dan batasan lintas akun apa saja yang ada?
- Kolom mana saja yang bersifat pribadi, finansial, atau dibatasi kontrak, dan siapa yang mengelola klasifikasi?
- Apakah akses diputuskan berdasarkan peran, atribut, tujuan, penyewa (tenant), filter baris/kolom, atau kombinasinya?
- Apakah persetujuan bersifat sekali pakai, dapat diperbarui, atau diperlukan per kueri?
- Berapa durasi maksimum, siapa pemberi persetujuan, dan bagaimana tinjauan untuk akses darurat?
- Bisakah sistem mencatat cakupan yang dipindai, baris yang dikembalikan, tujuan ekspor, dan identitas layanan?
Jawaban 30 detik
"Saya akan membuat katalog dengan kepemilikan yang jelas dan label sensitivitas, lalu mengirimkan identitas, tim, tujuan, wilayah, dan label sumber daya ke titik keputusan kebijakan. Penegakan di setiap mesin atau proksi data akan menerapkan filter baris/kolom dan penyamaran, dengan izin yang dibatasi waktu. Peristiwa izin, penolakan, versi kebijakan, sumber daya kueri, identitas layanan, dan ekspor akan masuk ke aliran terpusat yang tahan manipulasi. Akses break-glass akan kedaluwarsa dan memicu tinjauan. Saya akan menguji pencabutan hak akses, konteks lintas akun, cache, dan pergeseran kebijakan (drift) untuk membuktikan bahwa pembacaan aktual sesuai dengan jejak audit."
Solusi langkah demi langkah
Bangun inventaris aset untuk tabel, kolom, jalur (path), topik, penyewa, dan data turunan. Setiap aset memerlukan pemilik, klasifikasi, sumber, retensi, dan tujuan yang disetujui. Klasifikasi tidak bisa hanya berupa pemindaian satu kali: perubahan skema, kolom baru, dan perubahan aturan bisnis harus memicu tinjauan. Bidang sensitif yang belum pasti harus menerima label konservatif hingga ditinjau.
Pisahkan keputusan dari penegakan. Masukan keputusan mencakup identitas subjek, grup, atribut, tujuan, kondisi perangkat atau jaringan, label sumber daya, dan lingkungan. Keluarannya mencakup izin atau tolak, filter, penyamaran, versi kebijakan, dan masa kedaluwarsa. Penegakan dapat berada di proksi, plugin mesin, atau filter tabel, tetapi melewati mesin kueri tidak boleh sampai mengekspos file penyimpanan objek mentah.
Permintaan mandiri menampilkan tujuan, bidang, durasi, dan pemilik. Penggunaan berisiko rendah yang telah disetujui sebelumnya dapat menerima peran berumur pendek secara otomatis; akses sensitif memerlukan persetujuan pemilik data atau tim kepatuhan. Izin kedaluwarsa dengan cepat dan diperbarui secara terencana. Offboarding, perubahan tim, dan penyelesaian proyek akan memicu pencabutan hak akses. Hubungkan bukti persetujuan dengan versi kebijakan yang benar-benar aktif digunakan.
Jelaskan semantik baris dan kolom. Seorang analis mungkin melihat email yang disamarkan dan hasil agregat, tetapi tidak boleh merekonstruksi data asli melalui join, ekspor, atau pesan kesalahan. Predikat penyewa berasal dari identitas tepercaya, bukan dari ID penyewa yang diberikan oleh pengguna. Terapkan kontrol yang setara pada ekspor, tabel sementara, cache, dan materialized view sehingga sumber yang dilindungi tidak menciptakan salinan yang tidak terlindungi.
Peristiwa audit harus memuat subjek, rantai identitas, tujuan, sumber daya, keputusan baris/kolom, versi kebijakan, mesin, ID kueri atau tugas, waktu, akun sumber, ukuran yang dipindai atau dikembalikan, tujuan ekspor, serta hasil izin atau tolak. Tulis ke jalur penambahan (append) dengan hak istimewa rendah dan pembaca terkontrol di penyimpanan yang tidak dapat diubah (immutable storage); gunakan checksum atau rantai versi untuk mendeteksi penghapusan dan manipulasi. Penolakan dan pengeditan kebijakan sama pentingnya dengan kueri yang berhasil.
Di seluruh mesin dan akun, pertahankan identitas pengguna dan layanan asli. Layanan yang bertindak atas nama pengguna tetap mempertahankan rantai delegasinya; peristiwa lintas akun disalin ke pemilik sumber daya. Mesin lawas yang tidak dapat membawa konteks harus diisolasi, dibatasi pada view yang telah difilter sebelumnya, atau ditandai sebagai celah audit daripada dinyatakan patuh.
Rancang break-glass untuk kelompok kecil yang terautentikasi secara kuat. Wajibkan alasan, kedaluwarsa otomatis yang singkat, peringatan langsung, dan tinjauan; akses darurat tidak pernah melewati audit. Rilis versi kebijakan dengan canary dan rollback. Pantau penolakan, upaya eskalasi hak istimewa, latensi pencabutan, aset tanpa pemilik, celah audit, dan ekspor berisiko tinggi. Identitas sintetis dan kolom jebakan (honey column) digunakan untuk menguji apakah data dapat dibaca dan apakah pembacaan tersebut dicatat.
Jawaban model
"Saya akan membuat katalog dengan kepemilikan yang jelas dan label sensitivitas yang mencakup sumber, data turunan, jalur objek, dan ekspor. Titik keputusan kebijakan akan menerima identitas, tim, tujuan, wilayah, dan label sumber daya, lalu mengembalikan izin, tolak, filter baris/kolom, penyamaran, versi kebijakan, dan masa kedaluwarsa. Penegakan akan berada di proksi atau plugin mesin, sementara jalur objek mentah tetap tidak dapat diakses.
Permintaan akan menyatakan tujuan, cakupan, durasi, dan pemilik; akses sensitif akan memerlukan persetujuan, dan izin akan kedaluwarsa saat offboarding atau proyek selesai. Kebijakan baris/kolom yang sama akan berlaku untuk tabel sementara, cache, dan ekspor sehingga pengguna tidak dapat merekonstruksi nilai melalui salinan.
Peristiwa audit akan mempertahankan rantai identitas pengguna dan layanan, sumber daya, versi kebijakan, mesin, ID kueri, hasil pemfilteran, ukuran, tujuan ekspor, dan hasil izin/tolak dalam penyimpanan yang tidak dapat diubah. Akses break-glass akan kedaluwarsa, mengirimkan peringatan, dan memerlukan tinjauan. Saya akan menguji konteks lintas akun, pencabutan hak akses, mesin lawas, cache, ekspor, dan kolom jebakan untuk membuktikan bahwa pembacaan aktual sesuai dengan bukti."
Kesalahan umum
- Hanya merancang RBAC → batasan tujuan, wilayah, dan kolom terlewatkan → gabungkan identitas, atribut, label, dan filter.
- Hanya melindungi mesin kueri → pengguna memintasnya melalui penyimpanan objek → amankan jalur mentah dan tegakkan satu batas akses.
- Hanya mencatat akun ETL bersama → akuntabilitas pengguna hilang → pertahankan rantai delegasi.
- Hanya mencatat kueri yang berhasil → penolakan dan penyimpangan tidak terlihat → catat penolakan, pengeditan kebijakan, dan penggunaan darurat.
- Izin permanen → akses proyek bertahan selamanya → terapkan kedaluwarsa singkat, pembaruan, dan pencabutan.
- Hanya melindungi tabel sumber → cache, ekspor, dan materialisasi bocor → tegakkan kebijakan pada setiap jalur turunan.
- Break-glass melewati audit → jalur darurat menjadi pintu belakang → autentikasi kuat, alasan, kedaluwarsa, peringatan, tinjauan.
- Hanya menguji keluaran kebijakan → filter dapat dilewati → uji pembacaan nyata, ekspor, identitas sintetis, dan kolom jebakan.
Pertanyaan lanjutan dan tanggapan
Lanjutan 1: RBAC atau ABAC?
Gunakan peran untuk batasan tim yang stabil dan atribut untuk tujuan dinamis, wilayah, label, dan waktu. Sebagian besar sistem nyata menggabungkan keduanya sambil membatasi kompleksitas kebijakan.
Lanjutan 2: Bagaimana Anda menghentikan rekonstruksi melalui agregat?
Batasi kohort kecil, join, kueri pembedaan (differencing), dan frekuensi ekspor; gunakan ambang batas atau penambahan derau (noise) jika sesuai. Validasi aturan terhadap persyaratan sensitivitas dan akurasi.
Lanjutan 3: Bagaimana Anda mengaudit pembacaan cache?
Ikatkan kunci cache ke subjek dan versi kebijakan, catat rantai identitas pengisian (fill) dan pembacaan, serta batalkan (invalidate) saat ada pencabutan atau perubahan kebijakan. Cache bersama tanpa konteks pengguna tidak boleh menyimpan hasil yang sensitif.
Lanjutan 4: Bagaimana jika log audit berisi SQL yang sensitif?
Simpan pengidentifikasi sumber daya terstruktur dan ringkasan yang aman alih-alih SQL lengkap, parameter, atau data mentah. Enkripsi, batasi, dan simpan bidang audit secara terencana.
Lanjutan 5: Bagaimana jika mesin lawas tidak dapat menegakkan kebijakan baris atau kolom?
Isolasi mesin tersebut, ekspos hanya view yang telah difilter sebelumnya, atau migrasikan di belakang proksi, dan tandai sisa celah audit tersebut. Konvensi tim bukanlah penegakan sistem.
Lanjutan 6: Bagaimana Anda membuktikan tata kelola tidak memperlambat analisis?
Lacak latensi keputusan, p95 kueri, penolakan palsu (false denials), rasio hit cache, dan waktu persetujuan. Batalkan keputusan yang di-cache secara instan saat terjadi perubahan identitas atau versi kebijakan.
Lanjutan 7: Mengapa perlu mencatat versi kebijakan?
Kueri yang sama dapat mengembalikan hasil yang berbeda sebelum dan sesudah pembaruan kebijakan. Versi menjelaskan mengapa akses diizinkan, ditolak, atau difilter, serta mendukung rollback dan peninjauan insiden.