Pertanyaan dan skenario
Desain layanan transparansi untuk bukti rantai pasok perangkat lunak. Pembangun dapat mengesahkan lingkungan build dan digest artefak, penerbit dapat mengesahkan rilis dan sumbernya, dan pengintegrasi dapat menambahkan hasil pengujian atau kepatuhan. Konsumen harus memverifikasi siapa yang menandatangani pernyataan, apakah kebijakan pendaftaran lolos, dan apakah ada tanda terima riwayat yang dapat diverifikasi.
Batasan kuncinya terletak di antara catatan yang dapat diverifikasi dan basis data bisnis: layanan membuktikan bahwa suatu pernyataan telah didaftarkan dan diperiksa pada waktu tertentu. Layanan ini tidak menggantikan penyimpanan objek, registri paket, atau dependency resolver lengkap.
Hal yang sedang diuji oleh pewawancara
Batasan kepercayaan (Trust boundaries)
Jawaban yang kuat memisahkan antara penerbit (issuers), layanan transparansi, auditor, dan relying parties, lalu menyatakan apa yang dapat dan tidak dapat dibuktikan oleh masing-masing pihak.
Materi kriptografi dan riwayat
Jelaskan bagaimana hubungan antara pernyataan bertanda tangan, hasil kebijakan, log append-only, dan tanda terima. Menulis baris ke basis data saja bukanlah bukti anti-rusak (tamper evidence).
Tata kelola yang dapat dioperasikan
Cakup rotasi kunci, pencabutan (revocation), pengiriman duplikat, versi kebijakan, isolasi penyewa (tenant), privasi, dan pemulihan bencana alih-alih hanya menggambarkan alur tulis.
Keandalan dan skala
Bahas pendaftaran idempoten, verifikasi batch, pembacaan bukti, replikasi lintas wilayah, dan pemutaran ulang audit untuk volume publikasi yang tinggi dan lonjakan konsumen.
Pertanyaan klarifikasi sebelum menjawab
- Apakah pernyataan dibatasi pada artefak perangkat lunak, atau mencakup perangkat keras, model, dan lingkungan deployment?
- Apakah layanan dijalankan oleh satu organisasi, atau dibagikan oleh penyewa yang harus saling memverifikasi?
- Apakah konsumen memerlukan pembacaan yang konsisten kuat (strongly consistent), atau dapatkah mereka melihat status "terdaftar tetapi bukti belum direplikasi"?
- Bidang mana saja yang sensitif, dan dapatkah tampilan publik hanya mengekspos digest, waktu, dan pengidentifikasi penerbit?
- Apakah pencabutan menargetkan kunci, pernyataan, atau hanya keputusan kebijakan?
- Berapa target throughput, periode retensi bukti, dan titik pemulihan lintas wilayah?
Kerangka jawaban 30 detik
"Saya akan membagi sistem menjadi API pendaftaran pernyataan, pemeriksa kebijakan, log transparansi, layanan tanda terima, dan SDK verifikasi. Penerbit mengirimkan pernyataan yang ditandatangani COSE; layanan memeriksa kebijakan berversi dan mendaftarkannya di bawah kunci idempotensi dalam log append-only. Log mengembalikan tanda terima dengan bukti inklusi (inclusion proof). Konsumen memverifikasi tanda tangan, inklusi log, versi kebijakan, dan waktu secara offline menggunakan pernyataan, tanda terima, dan jalur audit. Bidang sensitif tetap berupa digest atau referensi terenkripsi. Rotasi kunci dan pencabutan menggunakan trust root dan catatan status, sementara replikasi lintas wilayah hanya memublikasikan setelah log dan hasil kebijakan konsisten."
Jawaban mendalam langkah demi langkah
Langkah 1: Tentukan pernyataan dan peran
Pernyataan berisi pengidentifikasi subjek, penerbit, tipe, waktu validitas, versi kebijakan, dan digest konten; penerbit menandatanganinya dengan COSE_Sign1. Layanan transparansi hanya menerima penerbit yang terotentikasi dan menautkan setiap pernyataan ke penyewa, namespace, dan sumber. Konsumen, auditor, dan administrator kebijakan memiliki izin terpisah.
Langkah 2: Desain pendaftaran
Klien memanggil POST /statements dengan pernyataan bertanda tangan, kunci idempotensi, dan petunjuk kebijakan. Layanan memvalidasi tanda tangan, jendela waktu, skema, dan status penerbit, lalu mengevaluasi kebijakan. Pernyataan yang lolos ditambahkan ke log transparansi. Konten dan kunci yang sama mengembalikan tanda terima asli; konflik akan mengembalikan pendaftaran saat ini alih-alih menimpanya secara diam-diam.
POST /statements
Idempotency-Key: build-123
Content-Type: application/cbor
{ signedStatement, policyVersion }Langkah 3: Terbitkan tanda terima yang dapat diverifikasi
Layanan membuat tanda terima yang berisi versi log-tree, digest leaf, jalur bukti, dan tanda tangan layanan. Pembaca memverifikasi tanda terima dengan kunci publik layanan, menghitung ulang digest pernyataan, dan memeriksa inklusi. Tanda terima membuktikan bahwa layanan telah mendaftarkan dan berkomitmen pada suatu catatan pada suatu waktu; ini tidak membuktikan bahwa artefak tersebut aman.
Langkah 4: Tangani kebijakan, pencabutan, dan waktu
Kebijakan memiliki versi dan ditetapkan pada setiap catatan pendaftaran. Kebijakan berikutnya tidak menulis ulang hasil lama; kebijakan tersebut membuat pernyataan penilaian baru. Rotasi kunci menyimpan kunci publik historis beserta waktu aktivasinya. Catatan status dapat mencabut penerbit, kunci, atau pernyataan. Pemverifikasi memeriksa waktu pernyataan, waktu tanda terima, dan jendela validitas trust root.
Langkah 5: Isolasi privasi dan penyewa
Log publik hanya menyimpan digest, tipe, pengidentifikasi penerbit, dan stempel waktu yang diperlukan. Kode sumber, domain internal, dan detail kerentanan berada di penyimpanan objek terenkripsi dan direferensikan berdasarkan alamat konten. Kebijakan penyewa, kuota, dan otorisasi baca diberlakukan di API; indeks log dapat dipartisi berdasarkan penyewa sementara format bukti tetap interoperabel.
Langkah 6: Skalakan, pulihkan, dan operasikan
Lakukan sharding log dan commit batch pada alur tulis; cache kunci publik, skema, dan tanda terima pada alur baca. Replikasi log berurutan dan checkpoint lintas wilayah. Wilayah target tetap berstatus read-only hingga status log, hasil kebijakan, dan status kunci bertemu (converge). Lacak keberhasilan pendaftaran, penolakan kebijakan, latensi tanda terima, lag replikasi, kegagalan verifikasi, dan waktu propagasi pencabutan.
Contoh jawaban berkualitas tinggi
"Saya akan menyediakan API pendaftaran pernyataan dan SDK verifikasi offline. Sistem build mengirimkan pernyataan COSE_Sign1 yang berisi digest artefak, penerbit, tipe, waktu, dan versi kebijakan. Layanan memvalidasi tanda tangan dan skema, mengevaluasi kebijakan penyewa, menambahkan digest ke log transparansi append-only, dan mengembalikan tanda terima bukti inklusi. Pendaftaran bersifat idempoten, sehingga percobaan ulang menghasilkan tanda terima yang sama.
Konsumen mengunduh pernyataan, tanda terima, dan trust root serta memverifikasi tanda tangan, inklusi log, status penerbit, dan versi kebijakan secara lokal. Hasil verifikasi dapat menjadi pernyataan bertanda tangan lainnya, membentuk rantai yang dapat dilacak. Konten sensitif tetap berada di balik referensi terenkripsi. Trust root historis tetap tersedia setelah rotasi kunci, dan pencabutan merambat melalui pernyataan status. Replikasi lintas wilayah menyalin data log yang teratur, checkpoint, dan hasil kebijakan sebelum pembacaan verifikasi kuat dibuka. Sistem membuktikan pendaftaran dan keterlacakan; ini tidak menggantikan pemindaian malware atau keamanan runtime."
Kesalahan umum
- Menyimpan pernyataan dalam tabel yang dapat diedit → administrator dapat menulis ulang riwayat → gunakan log append-only, tanda terima bertanda tangan, dan pemverifikasi independen.
- Memperlakukan tanda terima transparansi sebagai vonis keamanan → pendaftaran tidak berarti artefak bebas kerentanan → pisahkan asal-usul (provenance), hasil kebijakan, dan risiko runtime.
- Menimpa catatan lama saat kebijakan berubah → audit tidak dapat mereproduksi keputusan → kunci versi kebijakan dan tambahkan penilaian baru.
- Hanya merotasi kunci saat ini → pernyataan lama tidak dapat diverifikasi → pertahankan kunci historis dan trust root dengan waktu aktivasinya.
- Memublikasikan setiap bidang pernyataan → metadata sumber dan kerentanan bocor → ekspos digest dan enkripsi referensi sensitif.
- Membiarkan percobaan ulang membuat pendaftaran duplikat → riwayat tidak stabil dan penyimpanan terbuang → ikat kunci idempotensi ke penyewa dan konten bertanda tangan.
- Membuka replika sebelum bukti konvergen → jalur inklusi tidak lengkap → replikasi log, checkpoint, dan status kunci sebelum melayani pembacaan.
- Memerlukan API pusat untuk setiap verifikasi → audit offline gagal → sertakan pernyataan, tanda terima, trust root, dan pemverifikasi offline.
Pertanyaan lanjutan dan tanggapan
Lanjutan 1: Bagaimana Anda membuktikan log tidak menghapus catatan perantara?
Auditor secara berkala mengambil dan membandingkan checkpoint yang ditandatangani. Pemverifikasi memerlukan ukuran tree yang monoton, root historis yang konsisten, dan bukti inklusi yang valid; percabangan (fork) menghentikan kepercayaan terhadap log.
Lanjutan 2: Bisakah tanda terima dari dua layanan transparansi memverifikasi satu sama lain?
Keduanya dapat berbagi digest pernyataan dan format tanda terima standar, tetapi setiap layanan tetap menandatangani dengan trust root-nya sendiri. Kesetaraan lintas layanan memerlukan pernyataan silang tambahan; kunci publik satu layanan tidak otomatis menjadi kepercayaan bagi layanan lainnya.
Lanjutan 3: Bagaimana cara mencabut pernyataan yang sudah terdaftar?
Pertahankan pernyataan dan tanda terima asli, lalu tambahkan pernyataan pencabutan atau status risiko. Pemverifikasi menerapkan waktu dan kebijakan untuk memutuskan penerimaan saat ini sementara auditor mempertahankan fakta pendaftaran asli.
Lanjutan 4: Apa yang terjadi jika pendaftaran tidak tersedia selama rilis?
Klien menyimpan pernyataan bertanda tangan dan digest secara lokal serta melabeli rilis dengan "belum ada tanda terima transparansi". Setelah pulih, klien mendaftar dengan kunci idempotensi yang sama; bukti yang hilang tidak pernah ditampilkan sebagai terverifikasi.
Lanjutan 5: Bagaimana cara menjaga log agar tidak menjadi kebocoran privasi?
Daftarkan bidang publik minimum, terapkan kebijakan akses tingkat penyewa, dan gunakan referensi terenkripsi. Agregasikan waktu, penerbit, dan tipe artefak hanya jika diperlukan sambil mempertahankan digest yang dapat diverifikasi untuk audit.
Sumber 1: Arsitektur SCITT RFC 9943
RFC 9943 mendefinisikan pernyataan bertanda tangan, layanan transparansi, tanda terima, dan bukti struktur data yang dapat diverifikasi. Standar ini juga membedakan bukti pendaftaran dari penyimpanan artefak dan resolusi dependensi. Batasan-batasan tersebut mendasari peran, alur pendaftaran, dan desain tanda terima di sini.
Sumber 2: Gambaran umum proyek SCITT
Proyek SCITT menjelaskan riwayat yang dapat diaudit, dilacak, dan diverifikasi untuk pernyataan rantai pasok. Verifikasi penyewa, tata kelola kebijakan, dan operasi regional dalam jawaban ini mengubah tujuan tersebut menjadi trade-off desain yang eksplisit.
Sumber 3: Riset wawancara rekayasa perangkat lunak
Riset tentang persiapan wawancara teknis rekayasa perangkat lunak menekankan keseimbangan antara komunikasi, klarifikasi batasan, dan penalaran teknis. Pertanyaan klarifikasi, kerangka singkat, dan tindak lanjut kegagalan dirancang untuk menunjukkan keterampilan tersebut alih-alih menguji ingatan terminologi.