Topik temu duga representatif

Temu duga reka bentuk sistem: Bagaimanakah anda mereka bentuk perkhidmatan ketelusan SCITT untuk bukti rantaian bekalan?

Reka bentuk sistemSukar
Pasukan Editorial Offer.ccDiterbitkan Dikemas kini

Soalan

Reka bentuk perkhidmatan ketelusan untuk rantaian bekalan perisian. Pembina (builders), penerbit (publishers) dan penyepadu (integrators) menyerahkan penyata bertandatangan; perkhidmatan mengesahkan dan mendaftarkannya; pengguna mengesahkan pengeluar, semakan dasar dan sejarah. Rangkumi API, struktur data, ketekalan, giliran kunci, penskalaan dan pengendalian kegagalan.

Soalan dan senario

Reka bentuk perkhidmatan ketelusan untuk bukti rantaian bekalan perisian. Pembina boleh memperakui persekitaran binaan dan digest artifak, penerbit boleh memperakui keluaran dan sumbernya, dan penyepadu boleh menambah keputusan ujian atau pematuhan. Pengguna mesti mengesahkan pihak yang menandatangani penyata, sama ada dasar pendaftaran diluluskan, dan sama ada resit sejarah yang boleh disahkan wujud.

Sempadan utama adalah antara rekod yang boleh disahkan dan pangkalan data perniagaan: perkhidmatan membuktikan bahawa penyata telah didaftarkan dan disemak pada satu masa tertentu. Ia tidak menggantikan storan objek, repositori pakej atau penyelesai kebergantungan yang lengkap.

Perkara yang diuji oleh penemu duga

Sempadan kepercayaan (Trust boundaries)

Jawapan yang kukuh memisahkan pengeluar (issuers), perkhidmatan ketelusan, juruaudit dan pihak yang bergantung (relying parties), kemudian menyatakan perkara yang boleh dan tidak boleh dibuktikan oleh setiap pihak.

Bahan kriptografi dan sejarah

Terangkan cara penyata bertandatangan, keputusan dasar, log tambah sahaja (append-only log) dan resit saling berkaitan. Menulis baris ke pangkalan data sahaja bukan bukti usikan (tamper evidence).

Tadbir urus yang boleh dikendalikan

Rangkumi giliran kunci, pembatalan (revocation), penyerahan pendua, versi dasar, pengasingan penyewa (tenant), privasi dan pemulihan bencana dan bukannya hanya melukis laluan tulis.

Kebolehpercayaan dan skala

Bincangkan pendaftaran idempoten, pengesahan kelompok, pembacaan bukti, replikasi rentas rantau dan main semula audit untuk volum penerbitan yang tinggi dan lonjakan pengguna.

Soalan penjelasan sebelum menjawab

  • Adakah penyata terhad kepada artifak perisian, atau adakah ia merangkumi perkakasan, model dan persekitaran penggunaan?
  • Adakah perkhidmatan dikendalikan oleh satu organisasi, atau dikongsi oleh penyewa yang mesti mengesahkan antara satu sama lain?
  • Adakah pengguna memerlukan bacaan yang konsisten secara ketat (strongly consistent), atau bolehkah mereka melihat "didaftarkan tetapi bukti belum direplikasi"?
  • Medan manakah yang sensitif, dan bolehkah paparan awam hanya mendedahkan digest, masa dan pengecam pengeluar?
  • Adakah pembatalan menyasarkan kunci, penyata, atau hanya keputusan dasar?
  • Apakah sasaran pemprosesan (throughput), tempoh pengekalan bukti dan titik pemulihan rentas rantau?

Rangka kerja jawapan 30 saat

"Saya akan membahagikan sistem kepada API pendaftaran penyata, penyemak dasar, log ketelusan, perkhidmatan resit dan SDK pengesahan. Pengeluar menyerahkan penyata bertandatangan COSE; perkhidmatan menyemak dasar berversi dan mendaftarkannya di bawah kunci keidempotenan dalam log tambah sahaja. Log mengembalikan resit dengan bukti rangkuman (inclusion proof). Pengguna mengesahkan tandatangan, rangkuman log, versi dasar dan masa secara luar talian menggunakan penyata, resit dan laluan audit. Medan sensitif kekal sebagai digest atau rujukan disulitkan. Giliran kunci dan pembatalan menggunakan punca amanah (trust roots) dan rekod status, manakala replikasi rentas rantau menerbitkan hanya selepas log dan keputusan dasar konsisten."

Jawapan mendalam langkah demi langkah

Langkah 1: Tentukan penyata dan peranan

Penyata mengandungi pengecam subjek, pengeluar, jenis, masa sah, versi dasar dan digest kandungan; pengeluar menandatanganinya dengan COSE_Sign1. Perkhidmatan ketelusan hanya menerima pengeluar yang disahkan dan memautkan setiap penyata kepada penyewa, ruang nama dan sumber. Pengguna, juruaudit dan pentadbir dasar mempunyai kebenaran yang berasingan.

Langkah 2: Reka bentuk pendaftaran

Klien memanggil POST /statements dengan penyata bertandatangan, kunci keidempotenan dan pembayang dasar. Perkhidmatan mengesahkan tandatangan, tetingkap masa, skema dan status pengeluar, kemudian menilai dasar. Penyata yang lulus ditambahkan pada log ketelusan. Kandungan dan kunci yang sama mengembalikan resit asal; konflik mengembalikan pendaftaran semasa dan bukannya menulis ganti secara senyap.

text
POST /statements
Idempotency-Key: build-123
Content-Type: application/cbor

{ signedStatement, policyVersion }

Langkah 3: Keluarkan resit yang boleh disahkan

Perkhidmatan mencipta resit yang mengandungi versi pepohon log, digest daun, laluan bukti dan tandatangan perkhidmatan. Pembaca mengesahkan resit dengan kunci awam perkhidmatan, mengira semula digest penyata dan menyemak rangkuman. Resit membuktikan bahawa perkhidmatan telah mendaftarkan dan komited kepada rekod pada satu masa; ia tidak membuktikan bahawa artifak itu selamat.

Langkah 4: Kendalikan dasar, pembatalan dan masa

Dasar diberi versi dan ditetapkan pada setiap rekod pendaftaran. Dasar kemudian tidak menulis semula keputusan lama; ia mencipta penyata penilaian baharu. Giliran kunci mengekalkan kunci awam sejarah bersama masa pengaktifan. Rekod status boleh membatalkan pengeluar, kunci atau penyata. Pengesah menyemak masa penyata, masa resit dan tetingkap kesahan punca amanah.

Langkah 5: Asingkan privasi dan penyewa

Log awam hanya menyimpan digest, jenis, pengecam pengeluar dan cap masa yang diperlukan. Kod sumber, domain dalaman dan butiran kerentanan berada dalam storan objek yang disulitkan dan dirujuk mengikut alamat kandungan. Dasar penyewa, kuota dan kebenaran membaca dikuatkuasakan pada API; indeks log boleh dipisahkan mengikut penyewa sementara format bukti kekal boleh saling beroperasi.

Langkah 6: Skalakan, pulihkan dan kendalikan

Lakukan sharding log dan laksanakan commit secara kelompok pada laluan tulis; simpan kunci awam, skema dan resit dalam cache pada laluan baca. Replikasi log tersusun dan titik semak (checkpoints) merentasi rantau. Rantau sasaran kekal baca sahaja sehingga keadaan log, keputusan dasar dan status kunci menumpu (converge). Jejaki kejayaan pendaftaran, penolakan dasar, kependaman resit, lag replikasi, kegagalan pengesahan dan masa penyebaran pembatalan.

Contoh jawapan berkualiti tinggi

"Saya akan mendedahkan API pendaftaran penyata dan SDK pengesahan luar talian. Sistem binaan menyerahkan penyata COSE_Sign1 yang mengandungi digest artifak, pengeluar, jenis, masa dan versi dasar. Perkhidmatan mengesahkan tandatangan dan skema, menilai dasar penyewa, menambahkan digest pada log ketelusan tambah sahaja dan mengembalikan resit bukti rangkuman. Pendaftaran adalah idempoten, jadi percubaan semula mengembalikan resit yang sama.

Pengguna memuat turun penyata, resit dan punca amanah serta mengesahkan tandatangan, rangkuman log, status pengeluar dan versi dasar secara tempatan. Hasil pengesahan boleh menjadi penyata bertandatangan yang lain, membentuk rantaian yang boleh dikesan. Kandungan sensitif kekal di sebalik rujukan yang disulitkan. Punca amanah sejarah kekal tersedia selepas giliran kunci, dan pembatalan tersebar melalui penyata status. Replikasi rentas rantau menyalin data log tersusun, titik semak dan keputusan dasar sebelum bacaan pengesahan ketat dibuka. Sistem membuktikan pendaftaran dan kebolehkesanan; ia tidak menggantikan imbasan perisian hasad atau keselamatan masa jalanan."

Kesilapan biasa

  • Menyimpan penyata dalam jadual yang boleh diedit → pentadbir boleh menulis semula sejarah → gunakan log tambah sahaja, resit bertandatangan dan pengesah bebas.
  • Menganggap resit ketelusan sebagai keputusan keselamatan → pendaftaran tidak bermakna artifak bebas daripada kerentanan → asingkan asal-usul (provenance), keputusan dasar dan risiko masa jalanan.
  • Menulis ganti rekod lama apabila dasar berubah → audit tidak dapat menghasilkan semula keputusan → tetapkan versi dasar dan tambahkan penilaian baharu.
  • Menggilirkan kunci semasa sahaja → penyata lama tidak boleh disahkan → kekalkan kunci sejarah dan punca amanah dengan masa pengaktifan.
  • Menerbitkan setiap medan penyata → metadata sumber dan kerentanan bocor → dedahkan digest dan sulitkan rujukan sensitif.
  • Membiarkan percubaan semula mencipta pendaftaran pendua → sejarah tidak stabil dan pembaziran storan → ikat kunci keidempotenan kepada penyewa dan kandungan bertandatangan.
  • Membuka replika sebelum bukti menumpu → laluan rangkuman tidak lengkap → replikasi log, titik semak dan status kunci sebelum melayan pembacaan.
  • Memerlukan API pusat untuk setiap pengesahan → audit luar talian gagal → sediakan penyata, resit, punca amanah dan pengesah luar talian.

Soalan susulan dan jawapan

Susulan 1: Bagaimanakah anda membuktikan log tidak memadam rekod perantaraan?

Juruaudit mengambil dan membandingkan titik semak bertandatangan secara berkala. Pengesah memerlukan saiz pepohon monotonik, punca sejarah yang konsisten dan bukti rangkuman yang sah; sebarang pencabangan (fork) menyebabkan log tidak lagi dipercayai.

Susulan 2: Bolehkah resit daripada dua perkhidmatan ketelusan mengesahkan antara satu sama lain?

Kedua-duanya boleh berkongsi digest penyata dan format resit yang diseragamkan, tetapi setiap perkhidmatan masih menandatangani dengan punca amanahnya sendiri. Kesetaraan rentas perkhidmatan memerlukan penyata silang tambahan; kunci awam satu perkhidmatan tidak secara automatik menjadi amanah untuk perkhidmatan yang lain.

Susulan 3: Bagaimanakah anda membatalkan penyata yang telah didaftarkan?

Kekalkan penyata dan resit asal, kemudian tambahkan penyata pembatalan atau status risiko. Pengesah menggunakan masa dan dasar untuk memutuskan penerimaan semasa manakala juruaudit mengekalkan fakta pendaftaran asal.

Susulan 4: Apakah yang berlaku apabila pendaftaran tidak tersedia semasa pelepasan?

Klien menyimpan penyata bertandatangan dan digest secara tempatan serta melabelkan keluaran sebagai "belum ada resit ketelusan". Setelah pulih, ia mendaftar dengan kunci keidempotenan yang sama; bukti yang hilang tidak pernah dipersembahkan sebagai disahkan.

Susulan 5: Bagaimanakah anda menghalang log daripada menjadi kebocoran privasi?

Daftarkan medan awam minimum, kuatkuasakan dasar akses peringkat penyewa dan gunakan rujukan yang disulitkan. Agregatkan masa, pengeluar dan jenis artifak hanya apabila diperlukan sambil mengekalkan digest yang boleh disahkan untuk audit.

Sumber 1: Seni bina SCITT RFC 9943

RFC 9943 mentakrifkan penyata bertandatangan, perkhidmatan ketelusan, resit dan bukti struktur data yang boleh disahkan. Ia juga membezakan bukti pendaftaran daripada storan artifak dan penyelesaian kebergantungan. Sempadan tersebut menjadi asas kepada peranan, aliran pendaftaran dan reka bentuk resit di sini.

Sumber 2: Gambaran keseluruhan projek SCITT

Projek SCITT menerangkan sejarah yang boleh diaudit, dikesan dan disahkan untuk penyata rantaian bekalan. Pengesahan penyewa, tadbir urus dasar dan operasi serantau dalam jawapan ini mengubah matlamat tersebut menjadi pertukaran kompromi (trade-offs) reka bentuk yang jelas.

Sumber 3: Penyelidikan temu duga kejuruteraan perisian

Penyelidikan mengenai persediaan untuk temu duga teknikal kejuruteraan perisian menekankan pengimbangan komunikasi, penjelasan kekangan dan penaakulan teknikal. Soalan penjelasan, rangka kerja ringkas dan susulan kegagalan direka untuk menyerlahkan kemahiran tersebut dan bukannya menguji ingatan terhadap istilah.

Sumber awam

Soalan berkaitan

Alat temu duga berkaitan

Gunakan Jawab untuk jawapan reka bentuk sistem

Jelaskan keperluan terlebih dahulu, kemudian teruskan dengan skala, seni bina, pilihan komponen dan pertukaran (trade-off).

Lihat alat