Skenario
Anda mengelola API Node.js dalam kontainer dengan dependensi pihak ketiga. API ini membaca konfigurasi, mengakses penyimpanan objek, dan sesekali menjalankan child process untuk pemrosesan gambar. Tim keamanan mengusulkan --permission hanya dengan izin file, jaringan, dan child process yang diperlukan. Jelaskan model ancaman, inventaris izin, uji kompatibilitas, pemantauan, dan rollback.
Hal yang dievaluasi oleh pewawancara
- Mengetahui bahwa Permission Model adalah sabuk pengaman untuk kode tepercaya, bukan sandbox untuk kode berbahaya (malicious code).
- Memecah kapabilitas file, jaringan, child process, worker, dan native addon ke dalam hak akses terendah (least privilege).
- Mengenali symlink, deskriptor file yang ada, urutan inisialisasi, dan batas pewarisan (inheritance).
- Merancang canary, telemetri penolakan (denial) yang berguna, dan rollback yang aman bagi bisnis.
Pertanyaan klarifikasi
Konfirmasikan versi Node, entrypoint, native addon, kebutuhan worker/FFI/WASI, path dan domain, serta apakah aplikasi harus memunculkan (spawn) proses. Periksa kontrol kontainer dan OS yang ada seperti seccomp, identitas pengguna, dan sistem file read-only sehingga Node tidak diperlakukan sebagai satu-satunya pertahanan.
Jawaban 30 detik
Saya akan memperlakukannya sebagai kontrol hak akses terendah untuk kode tepercaya, bukan pertahanan lengkap terhadap dependensi berbahaya. Bangun izin dari audit dependensi dan runtime produksi untuk fs.read, fs.write, serta cakupan jaringan, child process, dan worker. Aktifkan dalam mode shadow dan 1% traffic, catat ERR_ACCESS_DENIED dan latensi, lalu uji native addon, symlink, dan deskriptor yang ada. Pertahankan isolasi kontainer. Jika tingkat kesalahan meningkat atau dependensi kritis mengalami regresi, hapus flag startup untuk melakukan rollback dan perbaiki inventaris izin.
Penalaran langkah demi langkah
1. Menentukan batasan keamanan
Node mendeskripsikan Permission Model sebagai pembatasan sumber daya proses dan secara eksplisit menyatakan bahwa fitur ini tidak melindungi dari kode berbahaya; Node memercayai kode yang diminta untuk dijalankan. Fitur ini mengurangi akses tidak disengaja oleh aplikasi tepercaya, tetapi tidak dapat menggantikan kontainer, pengguna OS, seccomp, atau kontrol rantai pasokan dependensi.
2. Membangun inventaris izin
Mulai dengan penolakan secara default (default deny). Berikan --allow-fs-read hanya ke konfigurasi dan path statis, persempit --allow-fs-write ke output sementara, dan --allow-net ke domain penyimpanan objek yang diperlukan. Tambahkan --allow-child-process, --allow-worker, atau --allow-addons hanya dengan kebutuhan yang terdokumentasi. Beri versi pada izin-izin tersebut dan wajibkan tinjauan oleh pemilik layanan.
3. Memverifikasi perilaku runtime
Cakup startup, health check, upload, pemrosesan gambar, scheduled work, dan jalur error. Verifikasi process.permission.has() dan ingat bahwa permission.drop() bersifat ireversibel dan hanya memengaruhi pemeriksaan di masa mendatang; ini tidak menutup deskriptor, soket, atau worker yang sudah terbuka. Uji symlink, native addon, npx, dan batasan child process.
4. Canary dan rollback
Aktifkan terlebih dahulu di staging dan satu instance stateless. Kumpulkan kelas sumber daya yang ditolak, stack trace, versi, dan tenant tanpa mencatat nilai sensitif. Jadikan tingkat kesalahan, P95, keberhasilan startup, dan pekerjaan bisnis yang selesai sebagai gerbang (gate) ekspansi. Rollback dilakukan dengan menghapus --permission atau flag --allow-* yang relevan; pertahankan kontrol read-only, non-root, dan jaringan di lapisan kontainer.
Contoh jawaban berkualitas tinggi
Saya akan menyusun matriks izin: konfigurasi read-only, direktori sementara yang dapat ditulisi, domain penyimpanan objek yang diperlukan, child process konversi gambar, serta tanpa worker atau native addon tanpa alasan bisnis. Permission Model membatasi fs secara default, sehingga parameter startup memberikan setiap kapabilitas secara eksplisit. Saya akan membuat versi dari parameter-parameter tersebut, menjalankan skenario integrasi di CI dengan image terkecil, dan memverifikasi setiap rute dan background job. Canary mencakup satu kelas stateless, mengagregasikan ERR_ACCESS_DENIED, dan melakukan hashing pada path sumber daya. Saya akan menguji symlink secara khusus, deskriptor yang ada, dan fakta bahwa child process serta worker tidak mewarisi model dengan cara yang sama; risiko kode berbahaya tetap ditangani oleh isolasi kontainer dan OS. Lakukan ekspansi hanya setelah kriteria startup, P95, penolakan, dan penyelesaian pekerjaan terpenuhi. Jika dependensi kritis ditolak atau terjadi peningkatan error, hapus flag untuk memulihkan perilaku, lalu perbarui inventaris sebelum mencoba kembali.
Kesalahan umum
- Mengklaim bahwa Permission Model aman untuk menjalankan paket pihak ketiga yang berbahaya.
- Memberikan
--allow-fs-read=*dan--allow-fs-write=*tanpa kebutuhan. - Mengabaikan native addon, worker, child process, WASI, FFI, atau pembatasan jaringan.
- Mengasumsikan
permission.drop()menutup deskriptor, soket, atau worker yang sudah terbuka. - Hanya menguji startup lokal dan melewatkan npx, symlink, atau background job yang sebenarnya.
Pertanyaan lanjutan dan tanggapan
“Bisakah ini menggantikan sandbox kontainer?”
Tidak. Node secara eksplisit menyatakan bahwa fitur ini tidak melindungi dari kode berbahaya. Gabungkan dengan eksekusi non-root, sistem file read-only, seccomp, kebijakan jaringan, dan kontrol rantai pasokan dependensi.
“Mengapa layanan masih tidak dapat membaca file?”
Periksa entrypoint dan path yang dikonfigurasi, perilaku wildcard, dan apakah pembacaan inisialisasi terjadi setelah model ditetapkan. Gunakan permission.has() dan event penolakan untuk menemukan izin yang kurang.
“Bagaimana Anda mengizinkan pemrosesan gambar?”
Berikan --allow-child-process secara terpisah, batasi file executable serta direktori input/output, dan pertahankan pembatasan OS dan kontainer. Jika panggilan library dapat menggantikan child process, hapus izin tersebut sebagai gantinya.