Wawancara coding: Bisakah runtime/secret Go 1.26 menjamin kunci terhapus dari memori?

Prompt dan konteks

Sebuah layanan menangani kunci berumur pendek (short-lived keys) pada Linux amd64 dan arm64. Tim ingin menggunakan runtime/secret eksperimental Go 1.26 untuk menghapus register, penyimpanan stack, dan alokasi heap sementara, guna mengurangi risiko kunci residual. Rancang kriteria adopsi, batasan secret.Do, kebijakan build dan fallback, serta jelaskan mengapa fitur ini tidak menggantikan KMS, izin akses, rotasi kunci, isolasi proses, atau kontrol forensik memori. Keahlian intinya adalah menganalisis batasan kode kriptografi, sehingga ini adalah pertanyaan coding.

Hal yang dievaluasi pewawancara

Pertama, apakah Anda menyatakan dengan tepat bahwa paket eksperimental ini hanya ada dengan GOEXPERIMENT=runtimesecret dan berada di luar janji kompatibilitas Go (Go compatibility promise).

Kedua, apakah Anda memahami bahwa secret.Do mengontrol waktu pembersihan untuk penyimpanan sementara di dalam pohon panggilannya (call tree), bukan setiap referensi eksternal atau salinan persisten.

Ketiga, apakah Anda menempatkan batasan di sekitar operasi kriptografi kecil, alih-alih di sekitar jaringan, pencatatan log, atau cache berumur panjang.

Keempat, apakah arsitektur, proses build, performa, dan perilaku fallback dibuat eksplisit, bukan sekadar berasumsi pada platform yang tidak didukung secara diam-diam.

Kelima, apakah KMS/HSM, rotasi, hak istimewa terendah (least privilege), kontrol core-dump, dan pengujian membentuk pertahanan berlapis (defense in depth).

Pertanyaan klarifikasi awal

• Apakah versi Go, platform, dan flag build telah dikunci (pinned)?
• Apakah kunci berasal dari KMS/HSM, environment proses, file, atau database?
• Apakah Anda melindungi nilai perantara berumur pendek atau kunci privat yang menetap lama?
• Apakah core dump, debugger, atau alat analisis memori diaktifkan?
• Bisakah pustaka kripto menyalin rahasia ke goroutine lain, buffer, atau log?
• Bisakah layanan menonaktifkan eksperimen dan menggunakan implementasi kompatibilitas?

Jawaban 30 detik

“runtime/secret adalah paket eksperimental Go 1.26 yang hanya tersedia dengan GOEXPERIMENT=runtimesecret pada platform yang didukung; paket ini bukan API stabil. secret.Do dapat membungkus proses derivasi kunci singkat atau operasi dekapsulasi serta membantu menghapus register, penyimpanan stack, dan variabel sementara heap baru dalam pohon panggilannya, tetapi tidak menghapus salinan di buffer eksternal, log, cache, atau swap. Lingkungan produksi tetap membutuhkan KMS/HSM, rotasi, least privilege, kontrol core-dump, dan isolasi proses. Saya memverifikasi build yang diaktifkan dan dinonaktifkan, batasan kebocoran, performa, serta respons fallback atau rotasi kunci yang cepat.”

Solusi mendalam

Langkah 1: Kunci API dan eksperimen

Go 1.26 runtime/secret mengekspos Do(func()) dan Enabled(), tetapi hanya ketika GOEXPERIMENT=runtimesecret diatur. Saat ini paket tersebut menargetkan Linux amd64 dan arm64, serta berada di luar janji kompatibilitas Go 1. Skrip build harus mencatat toolchain, platform, dan flag.

Langkah 2: Pilih batasan penghapusan yang sempit

Tempatkan wilayah sementara kriptografi terkecil di dalam secret.Do, seperti dekapsulasi, derivasi, atau komputasi MAC sekali pakai. Jangan membungkus HTTP, panggilan database, atau dependensi yang tidak terkontrol: pohon panggilan yang lebih besar meningkatkan biaya pembersihan, waktu pemblokiran, dan kompleksitas audit.

func deriveKey(input []byte) ([]byte, error) {
  var out []byte
  secret.Do(func() {
    out = deriveTemporaryKey(input)
  })
  return out, nil // out still needs explicit ownership and erasure rules
}

Contoh ini mendefinisikan sebuah batasan; ini tidak berarti out secara otomatis di-zeroing. Pemanggil tetap memiliki kontrol penuh atas masa pakai, penyalinan, dan keputusan penghapusan.

Langkah 3: Temukan salinan yang tidak terhapus otomatis

Slice input dapat disalin, nilai balik keluar dari Do, logging dan serialisasi mengalokasikan buffer baru, serta garbage collector tidak memberikan momen penghapusan yang presisi bagi kode pengguna. Kurangi penyalinan, jangan pernah mengubah rahasia menjadi string, dan hapus secara eksplisit buffer yang masih dimiliki aplikasi pada batasan kritis.

Langkah 4: Hubungkan forward secrecy dengan manajemen kunci

Menghapus memori sementara mempersempit jendela paparan residual, tetapi forward secrecy juga membutuhkan kunci sesi berumur pendek, rotasi, pemusnahan kunci lama, dan pemulihan terkontrol. Kunci root harus berada di KMS/HSM; proses hanya menerima materi turunan minimum. runtime/secret tidak menyediakan kontrol akses, pencabutan (revocation), atau jejak audit.

Langkah 5: Tangani build dan fallback

Lakukan kompilasi dengan dan tanpa eksperimen. Enabled() dapat menginformasikan diagnostik atau pilihan implementasi, tetapi jalur yang dinonaktifkan tidak boleh dianggap terlindungi secara setara. Pada platform yang tidak didukung, gunakan fungsi kompatibilitas, upgrade gate, atau tolak untuk memulai; buat pilihan tersebut eksplisit dalam model ancaman dan rencana ketersediaan.

Langkah 6: Ukur performa dan observabilitas

Membersihkan pohon panggilan dapat memengaruhi latensi, terutama dengan alokasi sementara yang besar. Bandingkan latensi p50/p95, alokasi memori, dan throughput dengan input yang identik. Catat hanya jalur fitur dan status flag, jangan pernah mencatat data rahasia. “Zeroing berhasil” bukanlah metrik bisnis langsung.

Langkah 7: Bangun pengujian dan respons insiden

Uji matriks build, perilaku Enabled(), output kripto, penanganan error, batasan penyalinan, dan pemanggilan konkuren. Gabungkan penonaktifan core dump, alat analisis memori, dan latihan simulasi kegagalan terkontrol untuk pertahanan berlapis. Jika eksperimen gagal, siapkan jalur untuk menonaktifkannya, merotasi kunci yang terdampak, dan memperpendek TTL sesi.

Contoh jawaban berkualitas tinggi

“Saya memperlakukan runtime/secret sebagai mitigasi jendela residual eksperimental, bukan manajemen kunci. Saya mengunci Go 1.26, Linux amd64/arm64, dan flag build, lalu hanya menempatkan derivasi kunci atau dekapsulasi di dalam secret.Do. Saya mengaudit input, nilai balik, log, cache, dan salinan goroutine di luar pohon panggilan karena hal-hal tersebut tidak hilang secara otomatis. Kunci produksi tetap berasal dari KMS/HSM dengan rotasi, pencabutan, least privilege, kontrol core-dump, dan isolasi proses. Saya menguji build yang aktif dan nonaktif, performa, serta batasan kebocoran; jika eksperimen gagal, saya dapat menonaktifkannya, merotasi kunci, dan memperpendek masa pakai sesi.”

Kesalahan umum

• Memperlakukan eksperimen sebagai API stabil → pembaruan versi atau build platform gagal → kunci versi, flag, dan matriks dukungan.
• Menganggap Do menghapus setiap rahasia → buffer eksternal, log, dan nilai balik dapat tertinggal → audit salinan dan kepemilikan data.
• Membungkus seluruh request → batasannya terlalu luas dan latensi menjadi tidak terduga → bungkus hanya wilayah kriptografi kecil.
• Menggunakan Enabled sebagai jaminan keamanan → sebuah flag bukanlah pertahanan ancaman → dokumentasikan eksperimen dan pertahanan berlapis.
• Mengabaikan KMS/HSM → proses menyimpan kunci root terlalu lama → pisahkan kunci root dari derivasi berumur pendek.
• Hanya menguji fungsionalitas → perbedaan residual, performa, dan build tetap ada → tambahkan uji matriks, kebocoran, dan benchmark.
• Mengubah rahasia menjadi string untuk log → lebih banyak salinan tak terkontrol muncul → hindari string dan lakukan redaksi data.
• Tidak ada pemutus darurat (emergency switch-off) → kegagalan hanya menyisakan downtime atau risiko → tentukan tindakan flag, rotasi, dan pemendekan sesi sebelumnya.

Pertanyaan lanjutan

Lanjutan 1: Apakah secret.Do menjamin stack di-zeroing saat return?

Dokumentasi menjelaskan pembersihan register dan variabel stack sementara yang digunakan oleh panggilan fungsi sebelum return, tetapi itu tidak mencakup setiap salinan yang dipegang oleh kode pengguna. Slice, nilai balik, log, dan cache di luar batasan tetap menjadi tanggung jawab aplikasi.

Lanjutan 2: Mengapa platform yang didukung itu penting?

Register, stack, dan implementasi runtime berbeda menurut arsitektur. Build produksi harus memverifikasi matriks platform alih-alih mengasumsikan semantik pembersihan yang identik.

Lanjutan 3: Bisakah request jaringan berjalan di dalam Do?

Hal ini tidak disarankan. I/O jaringan memperbesar pohon panggilan dan jendela pemblokiran, serta library downstream dapat menyalin rahasia. Selesaikan operasi kriptografi kecil terlebih dahulu, lalu lakukan pekerjaan jaringan di luar.

Lanjutan 4: Bagaimana Anda menangani rahasia yang dikembalikan?

Tentukan kepemilikan, durasi penggunaan, dan tanggung jawab penghapusan; minimalkan salinan, bersihkan buffer pemilik saat selesai, dan jangan pernah mengubah nilai tersebut menjadi string atau entri cache berumur panjang.

Lanjutan 5: Apakah ini menggantikan protokol forward-secret?

Tidak. Fitur ini mengurangi paparan memori residual. Forward secrecy bergantung pada kunci sesi efemeral, rotasi, pemusnahan, dan desain protokol, ditambah KMS/HSM serta kontrol akses.

Lanjutan 6: Bagaimana jika eksperimen mengalami crash di produksi?

Nonaktifkan jalur eksperimental atau lakukan rollback ke implementasi kompatibilitas, rotasi kunci yang berpotensi terekspos, perpendek TTL sesi yang terdampak, dan simpan bukti build, performa, serta error untuk diagnosis.