Perintah dan cakupan
Dua perusahaan ingin menghitung metrik tumpang tindih (overlap), konversi, atau atribusi tanpa saling menyalin alamat email, pengenal perangkat, atau baris log aktivitas (events). Wawancara ini menguji apakah prinsip "data tetap di tempatnya" dapat diwujudkan sebagai kontrol lapisan eksekusi alih-alih sekadar kontrak pembagian data, serta bagaimana Anda menangani kohort kecil, kueri berulang, penarikan izin, dan penerapan multi-cloud.
Hal yang diuji oleh pewawancara
Wawancara desain sistem biasanya menghargai klarifikasi cakupan sebelum mendalami model, otorisasi, dan jalur kegagalan yang paling rumit. Panduan wawancara rekayasa data juga mencantumkan desain sistem, tata kelola, dan privasi sebagai area evaluasi yang berbeda. AWS Clean Rooms mendokumentasikan hak istimewa terendah (least privilege), enkripsi, dan CloudTrail; panduan arsitektur Salesforce menempatkan pemrosesan zero-copy, penyelarasan identitas, ambang batas agregasi minimum, dan audit anti-perusakan (tamper-evident) pada batas eksekusi. Jawaban yang kuat menyebutkan komponen yang menegakkan setiap aturan beserta serangan yang diblokirnya.
Pertanyaan yang perlu diklarifikasi terlebih dahulu
Konfirmasikan jumlah pihak yang terlibat, apakah data tetap berada di akun cloud masing-masing, jenis analisis dan granularitas output yang diizinkan; apakah penerima boleh melihat jumlah persisnya; apakah differential privacy diperlukan; apakah pencocokan identitas menggunakan token yang disediakan mitra atau layanan pemetaan tepercaya; seberapa cepat pencabutan izin harus berlaku; serta persyaratan residensi data, kepemilikan kunci enkripsi, dan retensi audit. Agregasi dua pihak yang bersifat satu kali dapat menggunakan pemrosesan batch terkontrol; sedangkan kueri SQL terbuka mewajibkan bahasa kueri dan anggaran privasi dimasukkan ke dalam model ancaman.
Kerangka jawaban 30 detik
Awali dengan: "Saya akan membagi clean room menjadi control plane, konektor data, penyusun kebijakan (policy compiler), mesin eksekusi terisolasi, dan penerbit hasil (result publisher). Peserta mendaftarkan metadata dan tujuan yang diizinkan sementara tabel data mentah tetap berada di penyimpanan mereka. Mesin menjalankan kueri terbatas di batas data dan layanan terisolasi melakukan pencocokan identitas. Sebelum mempublikasikan, sistem menegakkan ambang batas kohort minimum, anggaran differential-privacy, dan pemindaian hasil. Kueri, versi kebijakan, dan operasi kunci dicatat ke dalam audit trail yang tidak dapat diubah (immutable). Pencabutan izin memblokir pekerjaan baru dan membatalkan hasil yang di-cache; setiap pekerjaan diisolasi berdasarkan penyewa (tenant), wilayah, dan kunci."
Pembahasan mendalam langkah demi langkah
Langkah 1: Mengubah perjanjian kolaborasi menjadi kebijakan
Control plane menyimpan daftar pihak yang terlibat, set data, tujuan, kunci join yang diizinkan, kolom output, wilayah, masa kedaluwarsa, dan versi izin. Kebijakan diberi versi dan ditandatangani, dan pekerjaan mengunci versi kebijakan saat dikirimkan; kueri tidak dapat mengubah aturan di tengah eksekusi. Identitas penyewa, peran manusia, dan identitas layanan tetap terpisah, dan pemohon hanya dapat melihat metadata yang diotorisasi.
Langkah 2: Menjaga data mentah tetap berada di dalam batas eksekusi
Konektor membaca tabel lokal atau view zero-copy dan hanya melaporkan skema, statistik, dan lokasi ke control plane. Policy compiler menyederhanakan permintaan hanya menjadi operasi join, filter, dan agregasi yang disetujui; ekspor arbitrer, pengurutan tingkat pengguna, fungsi bebas, dan kolom mentah dalam log akan ditolak. Pada penerapan multi-cloud, peran layanan dan kunci yang dikelola pelanggan (customer-managed keys) dipisahkan, TLS melindungi transmisi data, dan izin kunci dibatasi hanya untuk kolaborasi dan tabel perantara.
Langkah 3: Mencocokkan identitas tanpa mengeksposnya
Jangan menyimpan email mentah atau pengenal perangkat di control plane. Mitra menormalisasi nilai berdasarkan spesifikasi bersama dan membuat token, atau layanan pemetaan terisolasi melakukan pencocokan dan hanya mengembalikan hasil join yang tidak dapat diubah kembali (irreversible). Catat versi normalisasi, asal-usul data (provenance), dan penanganan tabrakan hash (collision). Aturan yang diubah akan menghasilkan versi baru alih-alih menggunakan kembali token secara diam-diam di bawah semantik yang berbeda. Hanya mesin eksekusi yang dapat menggunakan hasil pencocokan.
Langkah 4: Menegakkan privasi saat runtime
Sebelum mengembalikan hasil, eksekutor memeriksa ukuran kohort minimum, daftar izin kolom (allowlist), jumlah kueri, dan anggaran privasi. Differential privacy menambahkan derau (noise) terkalibrasi ke hasil agregasi dan melacak anggaran yang dikonsumsi oleh setiap kueri; setelah anggaran habis, kueri berikutnya akan diblokir. Bahkan dengan differential privacy, batasi operasi segmen berulang, operasi selisih (difference), dan kueri silang sehingga penyerang tidak dapat memperkecil kohort dengan menggabungkan beberapa output.
Langkah 5: Mempublikasikan hasil dengan bukti audit
Penerbit hanya mengeluarkan skema agregat yang disetujui, flag kualitas, dan status privasi. Sistem tidak pernah mengembalikan tabel perantara, token mentah, atau baris yang gagal. Setiap kueri mencatat pemohon, versi kebijakan dan set data, digest kueri, konsumsi anggaran, penerima, dan operasi kunci ke dalam penyimpanan yang tidak dapat dihapus oleh peserta. Cache hasil terikat pada versi kebijakan, izin, dan data; pencabutan salah satu di antaranya akan membatalkan cache tersebut.
Langkah 6: Menangani pencabutan izin, kegagalan, dan pemulihan regional
Pencabutan izin pertama-tama menghentikan pekerjaan yang ada di antrean, lalu membuat eksekutor memvalidasi ulang kebijakan pada checkpoint; hasil yang telah dipublikasikan ditandai sebagai terdampak dan tidak lagi didistribusikan ulang sesuai kontrak. Tugas yang gagal hanya menjalankan ulang partisi yang idempoten dan tidak pernah membaca tabel sementara di luar kebijakan. Penempatan regional mengikuti aturan residensi, dengan kunci dan log independen per wilayah. Jika control plane tidak tersedia, jeda kueri baru alih-alih menjalankannya dengan kebijakan yang sudah kedaluwarsa.
Contoh jawaban berkualitas tinggi
"Saya akan membuat kebijakan kolaborasi berversi yang menyebutkan tujuan, set data, kunci join, kolom output, wilayah, dan masa kedaluwarsa. Tabel mentah tetap berada di penyimpanan masing-masing peserta; konektor mengekspos view dan skema yang terkontrol. Policy compiler membatasi permintaan hanya pada join, filter, dan agregasi yang disetujui, dan mesin eksekusi berjalan di dalam batas data. Layanan pencocokan terisolasi mengubah pengenal yang telah dinormalisasi menjadi token yang tidak dapat diunduh. Sebelum publikasi, tegakkan ukuran kohort minimum, anggaran differential-privacy, dan pemeriksaan kueri gabungan; tolak permintaan setelah anggaran habis. Catat versi kebijakan dan data, pemohon, anggaran, panggilan kunci, dan penerima dalam log audit yang tidak dapat diubah. Pencabutan izin memblokir pekerjaan baru, membatalkan cache, dan memicu validasi ulang checkpoint. Isolasi regional dan kunci menjaga failover tetap berada dalam aturan residensi."
Kesalahan umum dan perbaikannya
- Mengandalkan kontrak hukum untuk mencegah kebocoran data: Pastikan eksekutor dan penerbit secara otomatis menolak kolom mentah, hasil tingkat pengguna, dan fungsi yang tidak sah.
- Menganggap hash sebagai anonimisasi otomatis: Masukkan normalisasi, salt, kunci, dan serangan tautan (linkage attacks) ke dalam model ancaman; lebih disukai menggunakan layanan token terisolasi.
- Hanya menetapkan satu pemeriksaan grup minimum: Batasi juga kueri berulang, operasi selisih, dan operasi lintas kueri, serta lacak anggaran privasi.
- Hanya mengubah flag konsol saat pencabutan izin: Periksa kembali versi kebijakan dan izin di antrean, eksekusi, cache, dan distribusi.
Pertanyaan lanjutan dan jawabannya
Bagaimana cara Anda menghentikan inferensi saat pemohon terus mengubah filter?
Ikatkan anggaran privasi ke setiap set data dan kolaborasi, lalu kenakan biaya anggaran untuk setiap kueri. Batasi dimensi segmentasi, frekuensi hasil, dan selisih antara kueri yang berdekatan. Tolak kueri ketika anggaran atau ambang batas risiko tercapai alih-alih mengembalikan kelompok data yang semakin mengecil.
Bagaimana jika kedua pihak menormalisasi email dengan cara yang berbeda?
Tetapkan versi normalisasi dalam kebijakan dan lakukan konversi di dalam layanan pencocokan terisolasi, lalu catat versi tersebut. Gagalkan proses dan wajibkan pemetaan ulang jika terjadi ketidakcocokan; menerima token secara diam-diam akan menciptakan hasil negatif palsu (false negatives) atau kecocokan palsu (false matches).
Bisakah suatu pekerjaan dipindahkan ke wilayah lain saat layanan kuncinya tidak tersedia?
Hanya jika aturan residensi data dan kebijakan kunci secara eksplisit mengizinkannya; jika tidak, jeda pekerjaan sembari mempertahankan checkpoint. Replikasi lintas wilayah hanya boleh membawa metadata kontrol terenkripsi dan catatan audit, tidak boleh membawa data mentah yang dibatasi atau tabel perantara yang dapat didekripsi.
Bagaimana cara Anda memverifikasi bahwa clean room tidak membocorkan data mentah?
Jalankan pengujian kebijakan negatif untuk pemilihan kolom mentah, pengurutan tingkat pengguna, kelompok di bawah ambang batas, operasi selisih berulang, dan injeksi log. Periksa execution plan dan skema hasil, simulasikan pencabutan izin dan kegagalan kunci, serta rekonsiliasikan peristiwa audit dengan panggilan API yang sebenarnya.