Petunjuk dan cakupan
Platform multi-tenant sudah menyimpan event audit, tetapi tim keamanannya memerlukan cara independen untuk menentukan apakah rekaman historis telah dihapus, diurutkan ulang, atau dihitung ulang oleh seseorang yang memiliki akses ke database utama. Rancang protokol verifikasi, dengan fokus pada kanonikalisasi, rantai hash tersegmentasi, tanda tangan digital, jangkar eksternal, output verifikator, dan penanganan interval yang tidak dapat diverifikasi.
Rekaman append-only dan rantai hash membuat pengeditan di kemudian hari dapat dideteksi, tetapi keduanya tidak membuktikan bahwa suatu event benar ketika pertama kali ditulis. Pertanyaan ini menguji pemodelan ancaman, bukti, dan operasional; penyimpanan objek yang tidak dapat diubah (immutable object storage) saja bukanlah desain yang lengkap.
Apa yang dievaluasi oleh pewawancara
Evaluasi field event untuk aktor, target, tindakan, waktu, sumber, dan hasil; kopling yang andal ke transaksi bisnis; rantai hash yang tersegmentasi dan dijangkarkan; isolasi tenant, indeks, izin kunci, retensi, penghapusan, dan verifikator yang dapat digunakan.
Pertanyaan untuk Diklarifikasi Sebelum Menjawab
- Apakah pelaku ancaman dapat memodifikasi penyimpanan event, katalog hash, kunci penandatanganan, dan media penjangkaran?
- Apakah verifikasi harus mendeteksi penghapusan, modifikasi, dan pengurutan ulang, atau juga membuktikan keabsahan sumber event?
- Apakah platform, tim keamanan, atau auditor eksternal yang akan menjalankan verifikator?
- Berapa lama rekaman boleh dibiarkan tanpa dijangkarkan, dan bagaimana alur kerja investigasi harus terdegradasi setelah terjadi celah (gap)?
Kerangka jawaban 30 detik
"Saya akan mendefinisikan event kanonikal yang immutable dan memublikasikannya melalui outbox setelah transaksi bisnis melakukan commit. Writer yang terisolasi mengelompokkan event berdasarkan tenant dan waktu, membangun rantai hash, dan secara berkala menjangkarkan setiap head rantai di penyimpanan append-only independen atau buku besar transparansi. Kueri menggunakan indeks yang dapat dibangun kembali, tidak pernah mengubah bukti. Verifikator menghitung ulang rantai dan membandingkan jangkar. Integritas berasal dari rantai; kebenaran event tetap berasal dari otorisasi bisnis dan rekaman transaksi."
Jawaban mendalam langkah demi langkah
Langkah 1: Tentukan model ancaman dan tujuan pembuktian
Asumsikan administrator aplikasi atau database dapat menghapus, mengurutkan ulang, atau menulis ulang rekaman, dan layanan jangkar mungkin tidak tersedia. Tentukan apakah tujuannya adalah untuk mendeteksi event yang hilang, diubah, atau diurutkan ulang, atau untuk membuktikan bahwa suatu subjek telah bertindak. Log audit tidak menggantikan kontrol akses.
Langkah 2: Rancang event kanonikal
Sertakan ID event, tenant, aktor dan sumber identitas, tindakan, sumber daya, digest sebelum dan sesudah, ID permintaan, waktu event, urutan server, hasil, dan versi kebijakan. Kanonikalisasi JSON dan field serupa agar urutan serialisasi tidak mengubah hash. Simpan hanya digest atau referensi terkontrol untuk nilai-nilai sensitif.
Langkah 3: Gabungkan penulisan bisnis dan audit
Transaksi bisnis menulis ke outbox; konsumen yang andal memancarkan event setelah commit. Jangan mengandalkan pencatatan log best-effort setelah penulisan bisnis. Percobaan ulang bersifat idempoten berdasarkan ID event; kegagalan masuk ke antrean terisolasi dan memicu peringatan. Latensi audit dapat dibatasi, tetapi kehilangan data tidak boleh terjadi secara diam-diam.
Langkah 4: Bangun rantai hash tersegmentasi
Simpan hash sebelumnya, event kanonikal, dan hash saat ini, seperti H(previous || event || metadata). Putar segmen berdasarkan tenant, tanggal, atau ukuran dan catat awal, akhir, serta urutan segmen. Urutan lintas-shard menggunakan urutan server dan waktu penerimaan, bukan hanya jam klien.
Langkah 5: Beri jangkar secara eksternal dan kelola kunci
Tulis setiap head segmen secara berkala ke media append-only yang terisolasi dengan waktu penjangkaran, ID segmen, dan tanda tangan digital. Simpan kunci penandatanganan dalam layanan kunci terkontrol; rotasi dan pencabutan kunci itu sendiri diaudit. Jangkar independen mencegah writer database menghitung ulang dan mengganti seluruh rantai secara tidak terlihat.
Langkah 6: Isolasi kueri dan izin
Bangun indeks aktor, sumber daya, tindakan, dan waktu di indeks pencarian atau replika baca. Indeks dapat dibangun kembali; bukti tidak dapat diperbarui. Terapkan pemeriksaan tenant, peran, dan tujuan, serta sertakan digest verifikasi dalam ekspor. Setiap pembacaan, ekspor, atau verifikasi adalah event audit baru.
Langkah 7: Tangani retensi, penghapusan, dan privasi
Tetapkan kebijakan retensi, WORM, atau penguncian objek berdasarkan regulasi. Untuk penghapusan data pribadi, gunakan penghapusan kriptografis, redaksi field, atau digest yang tidak dapat diubah sambil mempertahankan bukti bahwa penghapusan telah terjadi; jangan pernah menulis ulang riwayat secara diam-diam. Selaraskan retensi cadangan, cache, dan jangkar.
Langkah 8: Verifikasi, pulihkan, dan pantau
Verifikator memeriksa kontinuitas rantai, urutan, hash kanonikal, tanda tangan digital, dan jangkar eksternal. Jalankan verifikasi sampel dan penuh secara berkala, pantau celah, kelambatan (lag), duplikat, kegagalan penjangkaran, dan waktu verifikasi. Pulihkan dengan memutar ulang outbox dan segmen append-only dari jangkar tepercaya terakhir, mengisolasi rentang yang tidak dapat dibuktikan.
Trade-off dan Batasan yang Lebih Mendalam
#### Satu Rantai versus Rantai Tersegmentasi
Satu rantai menyederhanakan kueri tetapi memperumit pemulihan dan penulisan bersamaan. Segmen memungkinkan isolasi tenant, verifikasi paralel, dan manajemen retensi, dengan konsekuensi biaya jangkar segmen dan metadata pengurutan.
#### Rantai Hash versus Log Bertanda Tangan
Rantai hash berbiaya rendah dan mendeteksi pengeditan; tanda tangan digital menambahkan verifikasi lintas-organisasi dan biaya manajemen kunci. Gabungkan keduanya saat bukti eksternal diperlukan.
#### Integritas versus Kebenaran
Sebuah rantai membuktikan hubungan antar rekaman dan konsistensi jangkar, bukan membuktikan bahwa konten event itu benar. Kebenaran tetap bergantung pada identitas, otorisasi, transaksi, dan bukti independen.
Simulasi Kegagalan dan Evolusi
#### Rekaman di Tengah Dihapus
Hapus satu objek dari segmen dan verifikasi bahwa celah urutan dan putusnya rantai dilaporkan beserta lokasi segmen dan jangkarnya.
#### Administrator Database Menghitung Ulang Hash
Tulis ulang segmen dan ganti head-nya; jangkar independen harus menolak rantai baru sementara rantai lama tetap dapat diambil untuk penyelidikan.
#### Layanan Jangkar Tidak Tersedia
Putuskan sambungannya dan verifikasi bahwa segmen memasuki status pending-anchor, event tetap tahan lama, dan jangkar ditambahkan secara berurutan setelah pemulihan disertai peringatan.
Contoh Jawaban Berkualitas Tinggi
"Pertama-tama saya akan menentukan batasan verifikasi: penyerang mungkin mengubah penyimpanan event dan indeks pencarian tetapi tidak dapat menulis ulang jangkar independen atau mendapatkan kunci verifikasi. Writer mengubah setiap event menjadi representasi kanonikal yang deterministik, mensegmentasi rekaman berdasarkan tenant dan waktu, serta menyimpan nomor urut, hash sebelumnya, dan hash saat ini. Writer menandatangani setiap akhir segmen dan secara berkala melakukan commit head rantai ke media append-only di bawah izin terpisah.
Verifikator independen dimulai dari jangkar tepercaya, menghitung ulang hash kanonikal, dan memeriksa kontinuitas urutan, tautan antar segmen, tanda tangan, waktu penjangkaran, dan kebijakan retensi. Penghapusan menghasilkan celah urutan, modifikasi menghasilkan ketidakcocokan hash, pengurutan ulang merusak tautan pendahulu, dan administrator yang menghitung ulang seluruh segmen tetap tidak dapat mencocokkan jangkar eksternal. Hasilnya melaporkan rentang yang diverifikasi, posisi kegagalan pertama, jendela yang tidak dijangkarkan, dan referensi bukti, bukan hanya satu nilai Boolean. Jika suatu interval tidak dapat diverifikasi, saya membekukan ekspor yang terdampak, mempertahankan objek asli, dan memberi tahu tim keamanan. Rantai tersebut menetapkan integritas rekaman; bukti identitas, otorisasi, dan transaksi bisnis tetap diperlukan untuk menetapkan kebenaran event."
Kesalahan Umum
- Menempatkan data di penyimpanan WORM tanpa menentukan siapa yang dapat menulis atau mengubah retensi.
- Melakukan hashing pada JSON mentah tanpa menganonikalisasi urutan field, pengodean, dan stempel waktu.
- Memperlakukan rantai hash yang valid sebagai bukti bahwa setiap event adalah benar.
- Membangun kembali dan mengganti rantai yang gagal secara otomatis, sehingga menghancurkan bukti investigasi.
Pertanyaan Lanjutan dan Respons
Apa yang diselesaikan oleh jangkar eksternal?
Ini mencegah operator dengan akses tulis penyimpanan utama menghitung ulang seluruh segmen secara diam-diam dan mengganti head rantainya. Jangkar memerlukan izin dan retensi terpisah.
Bagaimana verifikator dapat membuktikan bahwa rekaman telah dihapus?
Verifikator mendeteksi celah urutan dan hash berikutnya yang rusak, lalu menggunakan jangkar tepercaya terdekat untuk membatasi interval yang hilang. Ketiadaan data di indeks pencarian saja tidak cukup.
Apa yang terjadi saat layanan jangkar tidak tersedia?
Lanjutkan penulisan segmen lokal yang berurutan dan tandai sebagai pending. Kirimkan secara berurutan setelah pemulihan. Jendela yang tidak dijangkarkan harus muncul dalam output verifikator dan peringatan, serta tidak dapat digambarkan sebagai terverifikasi penuh.
Bagaimana seharusnya interval yang tidak dapat diverifikasi ditangani?
Karantina ekspor yang terdampak, pertahankan objek asli, tanda tangan, dan bukti jangkar, beri tahu tim keamanan, dan catat responsnya. Pemulihan tidak boleh melabeli ulang interval yang tidak diketahui sebagai lengkap.