Petunjuk dan ruang lingkup
Desain layanan log audit multi-tenant yang mencatat tindakan-tindakan relevan untuk keamanan dan kepatuhan: proses masuk (sign-in), perubahan izin, akses data, dan pembaruan konfigurasi. Penyelidik membutuhkan riwayat yang dapat dicari dan ekspor yang dapat diverifikasi, sementara lalu lintas aplikasi harus tetap tersedia selama terjadi gangguan logging.
Definisikan jaminan integritas secara tepat. AWS CloudTrail menjelaskan riwayat peristiwa yang tidak dapat diubah (immutable) dan dapat dicari, sementara OpenTelemetry menyediakan model log terstruktur yang umum; keduanya tidak mengklaim bahwa suatu peristiwa sudah benar sebelum dimunculkan. Desain Anda harus menyatakan apa yang dapat dibuktikan oleh layanan tersebut.
Hal yang diuji oleh pewawancara
Mereka menguji penyerapan yang tahan lama (durable ingestion), penyimpanan append-only, verifikasi integritas, isolasi penyewa, kebijakan retensi, dan trade-off operasional. Jawaban yang baik membedakan bukti audit dari log debug biasa dan menjelaskan cara menghindari kehilangan atau pengubahan peristiwa keamanan selama beban berlebih (overload).
Pertanyaan untuk diklarifikasi sebelum menjawab
- Tindakan mana yang wajib dicatat, dan berapa perkiraan peristiwa per detik serta ukuran lonjakannya (burst size)?
- Apakah persyaratannya bersifat tamper-evident, tamper-resistant, atau dapat dibuktikan secara eksternal (externally attestable)?
- Haruskah permintaan aplikasi gagal jika suatu peristiwa audit tidak dapat diterima?
- Berapa lama setiap penyewa harus menyimpan peristiwa, dan apakah penahanan hukum (legal holds) mengesampingkan penghapusan?
- Siapa yang dapat mencari, mengekspor, atau memverifikasi data penyewa lain?
- Dimensi kueri dan format ekspor apa yang dibutuhkan oleh penyelidik?
Kerangka jawaban 30 detik
"Saya akan menyediakan API penyerapan regional dan buffer tahan lama (durable buffer) lokal agar panggilan aplikasi tidak bergantung pada indeks pencarian. Setiap peristiwa memuat penyewa, pelaku (actor), tindakan, target, korelasi permintaan, waktu peristiwa, waktu penyerapan, versi skema, dan sumber. Partisi log append-only berdasarkan penyewa dan waktu, replikasikan, dan buat rantai hash (hash chain) atau manifes segmen bertanda tangan sehingga pengeditan di kemudian hari dapat dideteksi. Pisahkan indeks pencarian panas (hot) dari penyimpanan retensi yang tidak dapat diubah. Terapkan otorisasi berbasis penyewa, retensi, dan penahanan hukum, serta sediakan ekspor dengan metadata verifikasi. Pantau peristiwa yang diterima versus yang diabaikan (dropped), latensi penyerapan (ingestion lag), pemeriksaan integritas, dan penyelesaian ekspor."
Pembahasan mendalam langkah demi langkah
Langkah 1: Tentukan kontrak peristiwa
Wajibkan ID peristiwa, ID penyewa, pelaku dan konteks autentikasi, tindakan, target, hasil, layanan sumber, ID permintaan, waktu peristiwa, waktu penyerapan, versi skema, dan atribut terpilih. Jauhkan rahasia dan muatan data (payload) yang tidak perlu dari catatan; catat referensi atau ringkasan yang telah disunting (redacted) sebagai gantinya.
Langkah 2: Pisahkan penerimaan dari pengindeksan
Kembalikan status berhasil hanya setelah peristiwa mencapai buffer tahan lama atau log yang direplikasi. Konsumen kemudian membangun indeks pencarian dan ekspor secara asinkron. Ini mencegah insiden pada kluster pencarian menghapus bukti secara diam-diam atau membuat setiap permintaan aplikasi menunggu proses pengindeksan.
Langkah 3: Buat integritas dapat diverifikasi
Kanonikalisasi setiap peristiwa, lakukan hash bersama peristiwa sebelumnya atau akar segmen, dan secara berkala tandatangani atau tambatkan (anchor) manifes dalam domain kepercayaan terpisah. Simpan celah urutan (sequence gaps) dan hasil verifikasi. Rantai hash mendeteksi perubahan setelah penyerapan; ini tidak membuktikan bahwa layanan hulu (upstream) memancarkan peristiwa yang benar.
append(event):
canonical = canonicalize(event)
record.hash = H(previous_hash || canonical)
durable_log.append(record)
return accepted(record.event_id, record.hash)Langkah 4: Partisi dan replikasi
Partisi berdasarkan penyewa dan waktu, dengan hash atau kunci penyewa untuk mendistribusikan penyewa yang aktif (hot tenants). Replikasikan ke seluruh domain kegagalan sebelum mengirimkan konfirmasi (acknowledgment) sesuai target ketahanan. Pertahankan pengurutan per penyewa atau agregat, tetapi jangan menjanjikan pengurutan global kecuali biayanya sebanding.
Langkah 5: Bangun pencarian panas dan retensi dingin
Indeks peristiwa terkini untuk kueri penyelidik dan padatkan segmen lama ke dalam penyimpanan objek yang tidak dapat diubah. Pastikan indeks dapat dibangun kembali dari log. Tugas retensi harus mematuhi kebijakan per penyewa dan penahanan hukum; penghapusan harus meninggalkan catatan kebijakan yang dapat diaudit tanpa mempertahankan muatan data yang dilindungi.
Langkah 6: Terapkan kontrol akses dan ekspor
Otorisasi setiap kueri berdasarkan penyewa, peran, tujuan, dan rentang waktu. Catat pembacaan dan ekspor sebagai peristiwa audit juga. Buat manifes bertanda tangan yang berisi filter, jumlah peristiwa, hash segmen, dan stempel waktu sehingga penerima dapat memverifikasi kelengkapan dan mendeteksi perubahan.
Langkah 7: Tentukan perilaku saat terjadi pemadaman dan beban berlebih
Pilih buffer lokal terbatas, backpressure, dan kebijakan yang jelas untuk peristiwa wajib. Untuk telemetri non-kritis, pengambilan sampel (sampling) atau pengiriman tertunda dapat diterima; untuk peristiwa keamanan, tolak mutasi asal atau alihkan ke saluran darurat yang terisolasi. Jangan pernah melaporkan diterima jika peristiwa hanya disimpan dalam memori volatil.
Langkah 8: Operasikan batas kepercayaan (trust boundary)
Ukur latensi penyerapan, latensi penerimaan tahan lama, lag konsumen, peristiwa yang ditolak, celah urutan, kegagalan verifikasi hash, kesegaran indeks, durasi ekspor, dan kesalahan tugas retensi. Batasi akses kunci, rotasi kunci penandatanganan, uji pemulihan dan verifikasi, serta buat peringatan untuk jejak audit dari jejak audit itu sendiri.
Contoh Jawaban Berkualitas Tinggi
"Saya akan memperlakukan log audit sebagai sistem bukti yang independen. Layanan bisnis memancarkan peristiwa kanonikal dengan ID peristiwa, penyewa, pelaku, konteks autentikasi, tindakan, target, hasil, ID permintaan, dan versi skema. Layanan hanya mengonfirmasi penerimaan setelah peristiwa mencapai log tahan lama yang direplikasi. Konsumen asinkron membangun indeks pencarian dan ekspor, sehingga indeks yang hilang dapat dibangun kembali dari bukti.
Log bukti disegmentasi berdasarkan penyewa dan waktu, menautkan rekaman dengan hash, dan secara berkala menandatangani atau menambatkan kepala segmen. Kueri diotorisasi berdasarkan penyewa, peran, tujuan, dan rentang waktu; kueri dan ekspor itu sendiri turut diaudit. Sebuah ekspor mencakup filternya, jumlah peristiwa, hash segmen, dan manifes bertanda tangan. Selama kegagalan penyerapan, peristiwa keamanan masuk ke jalur darurat tahan lama yang terbatas atau tindakan berisiko tinggi yang asli ditolak; buffer dalam memori tidak dianggap sebagai peristiwa yang diterima. Operasional memantau latensi penyerapan, celah urutan, kegagalan hash, kesegaran indeks, peristiwa yang ditolak, dan kesalahan retensi, serta secara teratur melatih pembangunan kembali indeks, rotasi kunci, dan isolasi penyewa berbeban tinggi. Layanan ini membuktikan integritas setelah penerimaan; identitas, otorisasi, dan transaksi bisnis tetap menjadi penentu apakah peristiwa di hulu benar adanya."
Kesalahan Umum
- Mengonfirmasi peristiwa sebelum disimpan secara tahan lama, menciptakan celah data yang tidak disadari setelah proses mengalami crash.
- Memperlakukan tabel basis data yang dapat diubah atau log debug biasa sebagai bukti audit.
- Menjadikan indeks pencarian sebagai satu-satunya salinan, sehingga kerusakan data tidak dapat diperbaiki.
- Lupa bahwa kueri, ekspor, perubahan retensi, dan rotasi kunci juga memerlukan audit.
- Mengklaim bahwa rantai hash membuktikan bahwa peristiwa di hulu adalah benar.
Pertanyaan Lanjutan dan Tanggapan
Apa yang terjadi jika seluruh indeks pencarian hilang?
Biarkan penyerapan bukti tetap tersedia, bangun kembali indeks dari segmen yang tidak dapat diubah, dan verifikasi rentang yang dibangun kembali dengan jumlah peristiwa, urutan, dan manifes bertanda tangan.
Haruskah lalu lintas bisnis berlanjut selama terjadi gangguan penyerapan?
Putuskan berdasarkan kekritisan peristiwa. Tindakan berisiko rendah dapat dimasukkan ke dalam buffer tahan lama terbatas. Tindakan keamanan berisiko tinggi yang tidak dapat dicatat dengan andal harus ditolak atau dialihkan melalui jalur darurat terisolasi, tidak boleh dibiarkan lolos begitu saja.
Bagaimana cara Anda menghentikan satu penyewa yang padat agar tidak merugikan penyewa lain?
Partisi berdasarkan penyewa dan waktu, terapkan kuota penyerapan, kueri, dan ekspor, serta isolasi sumber daya konsumen. Uji beban harus memverifikasi target tingkat layanan (SLO) untuk ketahanan dan kueri bagi penyewa yang tidak terpengaruh.
Bagaimana penghapusan privasi dan retensi audit dapat berdampingan?
Klasifikasikan bidang data berdasarkan penahanan hukum dan kebijakan penyewa, prioritaskan intisari (digest) yang disunting atau referensi terkontrol, terapkan penghapusan secara konsisten pada indeks, segmen objek, dan cadangan (backup), serta simpan catatan yang dapat diverifikasi mengenai tindakan kebijakan tersebut.