Konteks dan cakupan
Rancang monitor log Certificate Transparency (CT) multi-tenant. Pengguna mengirimkan satu atau beberapa domain; layanan secara terus-menerus memeriksa log CT publik, memberikan peringatan untuk sertifikat atau prasertifikat (precertificate) yang cocok, dan membuktikan bahwa data log tidak ditulis ulang secara diam-diam. Sistem juga harus mendeteksi log yang usang, kegagalan pembuktian, dan pelanggaran maximum merge delay.
Ini adalah pertanyaan system-design yang sangat baik untuk peran keamanan platform dan infrastruktur sertifikat. Bagian yang penting adalah pipeline data yang dapat diverifikasi dan batasan kegagalan yang eksplisit, bukan daftar layanan yang sedang tren.
Apa yang dievaluasi oleh pewawancara
- Apakah Anda membedakan antara monitor, kebijakan browser, dan penerbitan CA.
- Apakah Anda memahami signed tree head (STH), Merkle inclusion proof, consistency proof, dan semantik append-only.
- Apakah maximum merge delay (MMD) menjadi kondisi penjadwalan dan peringatan yang terukur.
- Apakah Anda mencakup banyak log, pembacaan duplikat, split view, pemadaman (outage), dan isolasi tenant.
- Apakah asumsi penyimpanan, idempoten, pengendalian noise peringatan, dan kapasitas bersifat konkret.
Klarifikasi yang perlu ditanyakan terlebih dahulu
Konfirmasikan empat batasan:
- Apakah pencocokan harus mencakup nama persis, domain yang dapat didaftarkan (registrable domain), wildcard, atau nama dalam SAN?
- Apakah deteksi mendekati real-time diperlukan, atau latensi tingkat menit dapat diterima? Saluran dan eskalasi on-call apa yang dibutuhkan?
- Haruskah monitor memeriksa setiap log publik, atau hanya kumpulan tepercaya tertentu? Haruskah sertifikat mentah dan pembuktian disimpan?
- Berapa jumlah tenant, periode retensi, persyaratan privasi, dan anggarannya?
Jika tidak ada jawaban yang diberikan, asumsikan 100 log di-polling sekali per menit, target penemuan end-to-end lima menit, dan bukti audit disimpan.
Kerangka jawaban tiga puluh detik
Saya akan membagi sistem menjadi pengumpulan log, verifikasi kriptografi, pencocokan sertifikat, peringatan, dan penyimpanan audit. Setiap log menyimpan ukuran tree yang terverifikasi dan STH terbaru. Pengumpul memverifikasi tanda tangan STH, mengambil entri secara bertahap (incremental), dan menggunakan inclusion proof atau consistency proof untuk memeriksa perilaku append-only. Lapisan pencocokan menormalisasi SAN, wildcard, dan registrable domain; lapisan peringatan melakukan deduplikasi dan eskalasi sesuai kebijakan tenant; lapisan audit menyimpan entri mentah, STH, pembuktian, dan hash. Metrik utama adalah kesegaran STH, jeda log (log lag), tingkat kegagalan pembuktian, latensi peringatan, dan tingkat positif palsu. Split view atau pelanggaran MMD akan membekukan status tepercaya log tersebut dan mengeskalasikannya.
Pembahasan mendalam langkah demi langkah
1. Pengumpulan dan state machine
Simpan identitas setiap log, kunci publik, ukuran tree tepercaya, STH terakhir yang diverifikasi, waktu polling terakhir, dan status. Penjadwal menetapkan pekerjaan berdasarkan status: log normal menggunakan pembacaan bertahap, kegagalan sementara menggunakan exponential backoff, dan kegagalan berulang masuk ke karantina. Gunakan identitas log ditambah ukuran tree target sebagai kunci tugas agar upaya coba lagi bersifat idempoten.
2. Verifikasi STH dan Merkle
Pertama, verifikasi tanda tangan dan stempel waktu STH dengan kunci publik log, kemudian wajibkan ukuran tree yang monotonik tidak menurun. Sinkronisasi awal dapat membuat snapshot penuh; sinkronisasi berikutnya menggunakan consistency proof untuk menunjukkan bahwa tree baru mencakup tree lama. Untuk setiap entri yang cocok, gunakan inclusion proof untuk menunjukkan bahwa entri tersebut milik tree tersebut. Pembuktian yang gagal, rollback, atau tanda tangan yang buruk tidak boleh menimpa status lama; simpan buktinya dan tandai log sebagai mencurigakan.
3. Pembacaan bertahap dan integritas
Minta rentang setelah ukuran tree yang terakhir dikonfirmasi dan tulis sertifikat mentah, prasertifikat, posisi log, dan waktu penerimaan. Lakukan deduplikasi berdasarkan identitas entri tanpa membuang fakta bahwa satu sertifikat muncul di beberapa log. Jika tidak ada STH baru yang dapat diverifikasi tiba dalam MMD, catat log lag dan buat peringatan platform. “Tidak ada sertifikat yang cocok” tidak boleh disimpulkan dari “tidak ada entri baru yang teramati.”
4. Pencocokan sertifikat dan peringatan
Parsing SAN, wildcard, penerbit (issuer), notBefore, notAfter, dan sidik jari (fingerprint) sertifikat. Utamakan aturan nama eksplisit dan domain yang dapat didaftarkan daripada pencocokan substring. Peringatan harus mencakup tenant, nama, log, sidik jari, waktu pertama kali diamati, dan tautan bukti. Lakukan deduplikasi untuk sidik jari yang sama dalam jendela waktu singkat; penerbit baru, masa berlaku yang luar biasa pendek, atau domain produksi dapat meningkatkan tingkat keparahan.
5. Penyimpanan, multi-tenancy, dan pemulihan
Simpan status hot dalam penyimpanan relasional atau key-value; letakkan entri mentah dan pembuktian dalam object storage yang diindeks berdasarkan log dan ukuran tree. Tulis peristiwa ke aliran audit yang tidak dapat diubah (immutable) untuk replay. Kueri tenant hanya mengembalikan nama yang diotorisasi. Terapkan batas laju (rate limit) per log dan batas konkurensi global agar monitor tidak membebani log publik secara berlebihan. Jika status lokal hilang, pulihkan dari STH tepercaya terakhir dan kejar ketertinggalan dengan consistency proof daripada memercayai kursor yang belum diverifikasi.
6. Observabilitas dan penanganan kegagalan
Ukur usia STH, jeda MMD, ukuran tree yang dikonfirmasi, throughput pengambilan, kegagalan pembuktian, ketersediaan log, tingkat kecocokan, latensi peringatan, dan duplikat. Selama pemadaman, pertahankan status tepercaya terakhir dan coba lagi. Pada split view atau kegagalan konsistensi, hentikan penggunaan kecocokan dari log tersebut, gunakan log lain, dan buat peristiwa keamanan. Jika notifikasi gagal, simpan peristiwa dalam antrean yang tahan lama (durable) dan kirimkan berdasarkan ID peristiwa setelah pemulihan.
Contoh jawaban berkualitas tinggi
Pertama, saya akan menentukan progres tepercaya: kursor log hanya maju setelah STH yang ditandatangani dengan benar dan berukuran monotonik lolos consistency proof. Pengumpul menyimpan kursor tersebut dan rentang yang diminta beserta token coba lagi. Eksekusi pertama menetapkan dasar (baseline); eksekusi berikutnya membaca berdasarkan rentang ukuran tree. Setiap entri mempertahankan sidik jari, SAN, posisi log, respons mentah, dan bukti verifikasinya.
Pencocok menormalisasi SAN sebelum membandingkannya dengan aturan tenant untuk nama persis, domain yang dapat didaftarkan, dan wildcard eksplisit. Peristiwa dengan kunci tenant, sidik jari, dan log masuk ke antrean; pekerja notifikasi melakukan deduplikasi, eskalasi, dan mencatat pengiriman. Penyimpanan audit menyimpan STH, pembuktian, hash entri, dan versi verifikator sehingga teknisi keamanan dapat memutar ulang (replay) keputusan secara independen.
Saya memperlakukan anomali log sebagai kegagalan kepercayaan data: tanda tangan buruk, rollback, kegagalan consistency proof, atau timeout MMD menciptakan peristiwa platform berprioritas tinggi. Log tersebut dikarantina dan status tepercaya lamanya dipertahankan. Sharding berdasarkan log, pembatasan laju, pembacaan batch, dan object storage mengendalikan biaya; kueri yang diotorisasi dan kuota tenant menegakkan isolasi. Saya akan menerima desain ini menggunakan metrik kesegaran STH, kegagalan pembuktian, latensi penemuan, tingkat positif palsu peringatan, dan tingkat keberhasilan replay.
Kesalahan umum
- Melakukan polling hanya pada satu log dan mengabaikan fakta bahwa sertifikat dapat muncul di beberapa log.
- Membaca teks sertifikat tanpa memvalidasi tanda tangan STH dan Merkle proof.
- Memajukan kursor hanya karena permintaan terbaru berhasil, meskipun data belum diverifikasi.
- Memperlakukan MMD sebagai masa berlaku sertifikat, atau tidak memiliki peringatan kesegaran log sama sekali.
- Mencocokkan domain dengan pencarian substring, menciptakan positif palsu untuk nama serupa dan SAN yang tidak terkait.
- Mendeduplikasi sidik jari secara global sehingga kehilangan lokasi kemunculannya di berbagai log.
- Terus mengeluarkan kesimpulan “tidak ditemukan” yang berkeyakinan rendah saat sebuah log sedang anomali.
- Hanya menyimpan peringatan akhir tanpa entri mentah, STH, atau pembuktian, sehingga audit menjadi mustahil.
Pertanyaan lanjutan dan jawaban
Bagaimana jika log mengembalikan tree yang lebih kecil?
Jangan majukan kursor. Simpan kedua STH beserta responsnya, karantina log tersebut, dan buat peringatan konsistensi. Lanjutkan hanya setelah peninjauan manual oleh manusia atau penetapan baseline tepercaya yang baru.
Bagaimana cara mengurangi biaya polling mendekati real-time?
Lakukan sharding berdasarkan log, kumpulkan rentang baru dalam batch, sesuaikan frekuensi polling secara dinamis, dan letakkan bukti dingin (cold evidence) di object storage. Jangan mengorbankan verifikasi hanya demi memenuhi target latensi.
Bagaimana Anda memverifikasi kepemilikan domain?
Wajibkan otorisasi DNS, HTTP, atau organisasi saat monitor dibuat. Hanya principal yang berwenang yang dapat mengubah aturan pencocokan, dan setiap perubahan diaudit.
Apa perbedaan monitor dengan kebijakan CT pada browser?
Monitor menemukan dan membuktikan entri dalam log publik. Kebijakan browser menentukan apakah suatu sertifikat memenuhi persyaratan koneksi. Penanganan kegagalan dan batasan kepercayaan keduanya berbeda.
Bagaimana Anda akan mengujinya?
Gunakan log yang dapat dikontrol atau respons yang direkam untuk menyuntikkan tanda tangan buruk, pembuktian tidak valid, rollback, timeout MMD, entri duplikat, dan coba lagi notifikasi. Verifikasi bahwa kursor tidak pernah maju secara keliru, peristiwa tetap idempoten, dan audit dapat diputar ulang dengan sukses.