Konsumsi artefak perangkat lunak pihak ketiga dalam rantai pasokan Anda hanya ketika diverifikasi dan ditandai sebagai aman untuk digunakan, oleh proses yang ditentukan dengan baik. Pola ini adalah sespan operasional untuk proses pengembangan. Konsumen pola ini memanggil proses ini untuk memverifikasi dan memblokir penggunaan perangkat lunak yang berpotensi memperkenalkan kerentanan keamanan.
Konteks dan masalah
Solusi cloud sering mengandalkan perangkat lunak pihak ketiga yang diperoleh dari sumber eksternal. Biner sumber terbuka, gambar kontainer publik, gambar OS vendor adalah beberapa contoh jenis artefak ini. Semua artefak eksternal tersebut harus diperlakukan sebagai tidak tepercaya.
Dalam alur kerja umum, artefak diambil dari penyimpanan di luar cakupan solusi dan kemudian diintegrasikan ke dalam alur penyebaran. Ada beberapa potensi masalah dalam pendekatan ini. Sumbernya mungkin tidak tepercaya, artefak mungkin mengandung kerentanan, atau mungkin tidak cocok dengan cara lain untuk lingkungan pengembang.
Jika masalah ini tidak diatasi, integritas data dan jaminan kerahasiaan solusi mungkin disusupi, atau menyebabkan ketidakstabilan karena ketidaksesuaian dengan komponen lain.
Beberapa masalah keamanan tersebut dapat dihindari dengan menambahkan pemeriksaan ke setiap artefak.
Solusi
Memiliki proses yang memvalidasi perangkat lunak untuk keamanan sebelum memperkenalkannya dalam beban kerja Anda. Selama proses, setiap artefak mengalami ketelitian operasional menyeluruh yang memverifikasinya terhadap kondisi tertentu. Hanya setelah artefak memenuhi kondisi tersebut, proses menandainya sebagai tepercaya.
Proses karantina adalah tindakan keamanan, yang terdiri dari serangkaian titik pemeriksaan yang digunakan sebelum artefak dikonsumsi. Titik pemeriksaan keamanan tersebut memastikan bahwa artefak beralih dari status yang tidak tepercaya ke status tepercaya.
Penting untuk dicatat bahwa proses karantina tidak mengubah komposisi artefak. Proses ini independen dari siklus pengembangan perangkat lunak dan dipanggil oleh konsumen, sesuai kebutuhan. Sebagai konsumen artefak, blokir penggunaan artefak sampai mereka melewati karantina.
Berikut adalah alur kerja karantina umum:
Konsumen menandakan niat mereka, menentukan sumber input artefak, dan memblokir penggunaannya.
Proses karantina memvalidasi asal permintaan dan mendapatkan artefak dari penyimpanan yang ditentukan.
Proses verifikasi kustom dilakukan sebagai bagian dari karantina, yang mencakup verifikasi batasan input dan memeriksa atribut, sumber, dan jenis terhadap standar yang ditetapkan.
Beberapa pemeriksaan keamanan ini dapat berupa pemindaian kerentanan, deteksi malware, dan sebagainya, pada setiap artefak yang dikirimkan.
Pemeriksaan aktual tergantung pada jenis artefak. Mengevaluasi gambar OS berbeda dari mengevaluasi paket NuGet, misalnya.
Jika proses verifikasi berhasil, artefak diterbitkan di penyimpanan yang aman dengan anotasi yang jelas. Jika tidak, itu tetap tidak tersedia untuk konsumen.
Proses penerbitan dapat mencakup laporan kumulatif yang menunjukkan bukti verifikasi dan kekritisan setiap pemeriksaan. Sertakan kedaluwarsa dalam laporan di luar laporan yang seharusnya tidak valid dan artefak dianggap tidak aman.
Proses menandai akhir karantina dengan memberi sinyal peristiwa dengan informasi status disertai dengan laporan.
Berdasarkan informasi tersebut, konsumen dapat memilih untuk mengambil tindakan untuk menggunakan artefak tepercaya. Tindakan tersebut berada di luar cakupan pola Karantina.
Masalah dan pertimbangan
Sebagai tim yang menggunakan artefak pihak ketiga, pastikan artefak tersebut diperoleh dari sumber tepercaya. Pilihan Anda harus selaras dengan standar yang disetujui organisasi untuk artefak yang diperoleh dari vendor pihak ketiga. Vendor harus dapat memenuhi persyaratan keamanan beban kerja Anda (dan organisasi Anda). Misalnya, pastikan rencana pengungkapan vendor yang bertanggung jawab memenuhi persyaratan keamanan organisasi Anda.
Buat segmentasi antara sumber daya yang menyimpan artefak tepercaya dan tidak tepercaya. Gunakan kontrol identitas dan jaringan untuk membatasi akses ke pengguna yang berwenang.
Memiliki cara yang dapat diandalkan untuk memanggil proses karantina. Pastikan artefak tidak digunakan secara tidak sengaja hingga ditandai sebagai tepercaya. Sinyal harus diotomatisasi. Misalnya, tugas yang terkait dengan memberi tahu pihak yang bertanggung jawab ketika artefak diserap ke lingkungan pengembang, melakukan perubahan pada repositori GitHub, menambahkan gambar ke registri privat, dan sebagainya.
Alternatif untuk menerapkan pola Karantina adalah dengan mengalihdayakannya. Ada praktisi karantina yang mengkhususkan diri dalam validasi aset publik sebagai model bisnis mereka. Mengevaluasi biaya keuangan dan operasional penerapan pola versus outsourcing tanggung jawab. Jika persyaratan keamanan Anda memerlukan kontrol lebih, disarankan untuk menerapkan proses Anda sendiri.
Mengotomatiskan proses penyerapan artefak dan juga proses penerbitan artefak. Karena tugas validasi dapat memakan waktu, proses otomatisasi harus dapat dilanjutkan hingga semua tugas selesai.
Pola ini berfungsi sebagai validasi sesaat peluang pertama. Berhasil melewati karantina tidak memastikan bahwa artefak tetap dapat dipercaya tanpa batas waktu. Artefak harus terus menjalani pemindaian berkelanjutan, validasi alur, dan pemeriksaan keamanan rutin lainnya yang berfungsi sebagai validasi peluang terakhir sebelum mempromosikan rilis.
Pola dapat diimplementasikan oleh tim pusat organisasi atau tim beban kerja individu. Jika ada banyak instans atau variasi proses karantina, operasi ini harus distandarkan dan dipusatkan oleh organisasi. Dalam hal ini, tim beban kerja berbagi proses dan mendapat manfaat dari manajemen proses offloading.
Kapan menggunakan pola ini
Gunakan pola ini ketika:
Beban kerja mengintegrasikan artefak yang dikembangkan di luar lingkup tim beban kerja. Contoh umumnya termasuk:
Artefak Open Container Initiative (OCI) dari registri publik seperti, DockerHub, registri Kontainer GitHub, registri kontainer Microsoft
Pustaka perangkat lunak atau paket dari sumber publik seperti, Galeri NuGet, Indeks Paket Python, repositori Apache Maven
Paket Infrastructure-as-Code (IaC) eksternal seperti modul Terraform, Community Chef Cookbooks, Azure Verified Modules
Gambar OS yang disediakan vendor
Tim beban kerja menganggap artefak sebagai risiko yang layak untuk dimitigasi. Tim memahami konsekuensi negatif dari mengintegrasikan artefak yang disusupi dan nilai karantina dalam memastikan lingkungan tepercaya.
Tim memiliki pemahaman yang jelas dan bersama tentang aturan validasi yang harus diterapkan pada jenis artefak. Tanpa konsekuensi, pola mungkin tidak efektif.
Misalnya, jika serangkaian pemeriksaan validasi yang berbeda diterapkan setiap kali gambar OS diserap ke dalam karantina, proses verifikasi keseluruhan untuk gambar OS menjadi tidak konsisten.
Pola ini mungkin tidak berguna jika:
Artefak perangkat lunak dibuat oleh tim beban kerja atau tim mitra tepercaya.
Risiko tidak memverifikasi artefak lebih murah daripada biaya membangun dan mempertahankan proses karantina.
Desain beban kerja
Arsitek dan tim beban kerja harus mengevaluasi bagaimana pola Karantina dapat digunakan sebagai bagian dari praktik DevSecOps beban kerja. Prinsip-prinsip yang mendasarinya tercakup dalam pilar Azure Well-Architected Framework.
| Pilar | Bagaimana pola ini mendukung tujuan pilar |
|---|---|
| Keputusan desain keamanan membantu memastikan kerahasiaan, integritas, dan ketersediaan data dan sistem beban kerja Anda. | Tanggung jawab pertama validasi keamanan dilayani oleh pola Karantina. Validasi pada artefak eksternal dilakukan di lingkungan tersegmentasi sebelum dikonsumsi oleh proses pengembangan. - Siklus hidup pengembangan aman SE:02 - Pengujian dan validasi SE:11 |
| Keunggulan Operasional membantu memberikan kualitas beban kerja melalui proses standar dan kohesi tim. | Pola Karantina mendukung praktik penyebaran aman (SDP) dengan memastikan bahwa artefak yang disusupi tidak dikonsumsi oleh beban kerja, yang dapat menyebabkan pelanggaran keamanan selama penyebaran paparan progresif. - Praktik pengembangan Perangkat Lunak OE:03 - Pengujian dan validasi OE:11 |
Seperti halnya keputusan desain apa pun, pertimbangkan tradeoff terhadap tujuan pilar lain yang mungkin diperkenalkan dengan pola ini.
Contoh
Contoh ini menerapkan alur kerja solusi ke skenario di mana tim beban kerja ingin mengintegrasikan artefak OCI dari registri publik ke instans Azure Container Registry (ACR), yang dimiliki oleh tim beban kerja. Tim memperlakukan instans tersebut sebagai penyimpanan artefak tepercaya.
Lingkungan beban kerja menggunakan Azure Policy untuk Kubernetes untuk menegakkan tata kelola. Ini membatasi penarikan kontainer hanya dari instans registri tepercaya mereka. Selain itu, pemberitahuan Azure Monitor disiapkan untuk mendeteksi impor apa pun ke dalam registri tersebut dari sumber yang tidak terduga.
Permintaan untuk gambar eksternal dibuat oleh tim beban kerja melalui aplikasi kustom yang dihosting di Azure Web Apps. Aplikasi ini mengumpulkan informasi yang diperlukan hanya dari pengguna yang berwenang.
Titik pemeriksaan keamanan: Identitas pemohon, registri kontainer tujuan, dan sumber gambar yang diminta, diverifikasi.
Permintaan disimpan di Azure Cosmos DB.
Titik pemeriksaan keamanan: Jejak audit dipertahankan dalam database, melacak silsilah data dan validasi gambar. Jejak ini juga digunakan untuk pelaporan historis.
Permintaan ditangani oleh orkestrator alur kerja, yang merupakan Fungsi Azure yang tahan lama. Orkestrator menggunakan pendekatan scatter-gather untuk menjalankan semua validasi.
Titik pemeriksaan keamanan: Orkestrator memiliki identitas terkelola dengan akses cukup untuk melakukan tugas validasi.
Orkestrator membuat permintaan untuk mengimpor gambar ke Azure Container Registry (ACR) karantina yang dianggap sebagai penyimpanan yang tidak tepercaya.
Proses impor pada registri karantina mendapatkan gambar dari repositori eksternal yang tidak tepercaya. Jika impor berhasil, registri karantina memiliki salinan lokal gambar untuk menjalankan validasi.
Titik pemeriksaan keamanan: Registri karantina melindungi dari perubahan dan konsumsi beban kerja selama proses validasi.
Orkestrator menjalankan semua tugas validasi pada salinan lokal gambar. Tugas termasuk pemeriksaan seperti, deteksi Common Vulnerabilities and Exposures (CVE), evaluasi software bill of material (SBOM), deteksi malware, penandatanganan gambar, dan lainnya.
Orkestrator memutuskan jenis pemeriksaan, urutan eksekusi, dan waktu eksekusi. Dalam contoh ini, ia menggunakan Azure Container Instance sebagai pelari tugas dan hasilnya ada di database audit Cosmos DB. Semua tugas dapat memakan waktu yang signifikan.
Titik pemeriksaan keamanan: Langkah ini adalah inti dari proses karantina yang melakukan semua pemeriksaan validasi. Jenis pemeriksaan dapat berupa solusi kustom, sumber terbuka, atau yang dibeli vendor.
Orkestrator membuat keputusan. Jika gambar melewati semua validasi, peristiwa dicatat dalam database audit, gambar didorong ke registri tepercaya, dan salinan lokal dihapus dari registri karantina. Jika tidak, gambar dihapus dari registri karantina untuk mencegah penggunaannya yang tidak disengaja.
Titik pemeriksaan keamanan: Orkestrator mempertahankan segmentasi antara lokasi sumber daya tepercaya dan tidak tepercaya.
Catatan
Alih-alih orkestrator membuat keputusan, tim beban kerja dapat mengambil tanggung jawab tersebut. Dalam alternatif ini, orkestrator menerbitkan hasil validasi melalui API dan menyimpan gambar di registri karantina untuk jangka waktu tertentu.
Tim beban kerja membuat keputusan setelah meninjau hasil. Jika hasilnya memenuhi toleransi risikonya, mereka menarik gambar dari repositori karantina ke dalam instans kontainer mereka. Model penarikan ini lebih praktis ketika pola ini digunakan untuk mendukung beberapa tim beban kerja dengan toleransi risiko keamanan yang berbeda.
Semua registri kontainer dicakup oleh Pertahanan Microsoft untuk Kontainer, yang terus memindai masalah yang baru ditemukan. Masalah ini ditampilkan dalam Pengelolaan Kerentanan Microsoft Defender.
Langkah berikutnya
Panduan berikut bisa jadi relevan saat menerapkan pola berikut ini:
Rekomendasi untuk mengamankan siklus hidup pengembangan memberikan panduan tentang menggunakan unit kode tepercaya melalui semua tahap siklus hidup pengembangan.
Praktik terbaik untuk rantai pasokan perangkat lunak yang aman terutama ketika Anda memiliki dependensi NuGet dalam aplikasi Anda.
Dokumentasi Azure Artifacts adalah pustaka informasi yang terkait dengan pengelolaan paket perangkat lunak dengan Azure Artifacts.