Rekomendasi untuk mengamankan siklus hidup pengembangan

  • Artikel

Berlaku untuk rekomendasi daftar periksa Azure Well-Architected Framework Security ini:

SE:02 Pertahankan siklus hidup pengembangan yang aman dengan menggunakan rantai pasokan perangkat lunak yang diperkeras, sebagian besar otomatis, dan dapat diaudit. Menggabungkan desain yang aman dengan menggunakan pemodelan ancaman untuk melindungi dari implementasi yang mengalahkan keamanan.

Panduan terkait: Analisis ancaman

Panduan ini menjelaskan rekomendasi untuk memperkuat kode, lingkungan pengembangan, dan rantai pasokan perangkat lunak Anda dengan menerapkan praktik terbaik keamanan di seluruh siklus pengembangan. Untuk memahami panduan ini, Anda harus memiliki pengetahuan tentang DevSecOps.

Diagram siklus keamanan.

DevSecOps mengintegrasikan keamanan ke dalam proses DevOps dengan:

  • Mengotomatiskan pengujian dan validasi keamanan.

  • Menerapkan alat seperti alur keamanan untuk memindai kode dan infrastruktur sebagai kode (IaC) untuk kerentanan.

Inti dari beban kerja adalah kode aplikasi yang mengimplementasikan logika bisnis. Kode dan proses pengembangan kode harus bebas dari cacat keamanan untuk memastikan kerahasiaan, integritas, dan ketersediaan.

Tidak cukup untuk mengamankan hanya bidang infrastruktur dengan menggunakan kontrol pada identitas dan jaringan dan langkah-langkah lainnya. Cegah implementasi kode yang buruk atau blok kode yang disusupi untuk memperkuat postur keamanan Anda secara keseluruhan. Bidang penggunaan, yaitu, kode aplikasi, juga harus diperkeras. Proses mengintegrasikan keamanan ke dalam siklus hidup pengembangan Anda pada dasarnya adalah proses pengerasan. Seperti pengerasan sumber daya, memperketat pengembangan kode juga konteks-agnostik. Fokusnya adalah meningkatkan keamanan dan bukan persyaratan fungsional aplikasi. Untuk informasi terkait pengerasan, lihat Rekomendasi untuk pengerasan sumber daya.

Definisi

Istilah Definisi
Siklus Hidup Pengembangan Keamanan (SDL) Serangkaian praktik yang disediakan oleh Microsoft yang mendukung persyaratan jaminan dan kepatuhan keamanan.
Siklus hidup pengembangan perangkat lunak (SDLC) Proses multistage dan sistematis untuk mengembangkan sistem perangkat lunak.

Strategi desain utama

Langkah-langkah keamanan harus diintegrasikan di beberapa titik ke dalam Siklus Hidup Pengembangan Perangkat Lunak (SDLC) yang ada untuk memastikan:

  • Pilihan desain tidak menyebabkan kesenjangan keamanan.

  • Kode dan konfigurasi aplikasi tidak menciptakan kerentanan karena implementasi yang dapat dieksploitasi dan praktik pengodean yang tidak tepat.

  • Perangkat lunak yang diperoleh melalui rantai pasokan tidak menimbulkan ancaman keamanan.

  • Kode aplikasi, build, dan proses penyebaran tidak dirusak.

  • Kerentanan yang diungkapkan melalui insiden dimitigasi.

  • Aset yang tidak digunakan dinonaktifkan dengan benar.

  • Persyaratan kepatuhan tidak disusupi atau dikurangi.

  • Pengelogan audit diterapkan di lingkungan pengembang.

Bagian berikut ini menyediakan strategi keamanan untuk fase SDLC yang umum dipraktikkan.

Fase persyaratan

Tujuan dari fase persyaratan adalah untuk mengumpulkan dan menganalisis persyaratan fungsional dan non-fungsional untuk aplikasi atau fitur baru aplikasi. Fase ini penting karena memfasilitasi pembuatan pagar pembatas yang disesuaikan dengan tujuan aplikasi. Melindungi data dan integritas aplikasi Anda harus menjadi persyaratan inti di setiap fase siklus hidup pengembangan.

Misalnya, pertimbangkan aplikasi yang perlu mendukung alur pengguna penting yang memungkinkan pengguna mengunggah dan memanipulasi data. Pilihan desain keamanan harus mencakup jaminan untuk interaksi pengguna dengan aplikasi, seperti mengautentikasi dan mengotorisasi identitas pengguna, hanya mengizinkan tindakan yang diizinkan pada data, dan mencegah injeksi SQL. Demikian pula, mencakup persyaratan non-fungsional seperti ketersediaan, skalabilitas, dan pemeliharaan. Pilihan keamanan harus mencakup batas segmentasi, masuk dan keluar firewall, dan masalah keamanan lintas pemotongan lainnya.

Semua keputusan ini harus mengarah pada definisi yang baik dari postur keamanan aplikasi. Dokumentasikan persyaratan keamanan dalam spesifikasi yang disepakati dan refleksikan dalam backlog. Ini harus secara eksplisit menyatakan investasi keamanan dan tradeoff dan risiko yang bersedia dilakukan bisnis jika investasi tidak disetujui oleh pemangku kepentingan bisnis. Misalnya, Anda mungkin mendokumentasikan kebutuhan untuk menggunakan firewall aplikasi web (WAF) di depan aplikasi Anda, seperti Azure Front Door atau Azure Application Gateway. Jika pemangku kepentingan bisnis tidak siap menerima biaya tambahan untuk menjalankan WAF, mereka perlu menerima risiko bahwa serangan lapisan aplikasi mungkin diarahkan ke aplikasi.

Pengumpulan persyaratan keamanan adalah bagian penting dari fase ini. Tanpa upaya ini, fase desain dan implementasi akan didasarkan pada pilihan yang tidak dibatasi, yang dapat menyebabkan kesenjangan keamanan. Anda mungkin perlu mengubah implementasi nanti untuk mengakomodasi keamanan, yang bisa mahal.

Fase desain

Selama fase ini, persyaratan keamanan dikonversi ke persyaratan teknis. Dalam spesifikasi teknis Anda, dokumentasikan semua keputusan desain untuk mencegah ambiguitas selama implementasi. Berikut adalah beberapa tugas umum:

Menentukan dimensi keamanan arsitektur sistem

Overlay arsitektur dengan kontrol keamanan. Misalnya, kontrol yang praktis pada batas isolasi per strategi segmentasi Anda, jenis identitas yang diperlukan untuk komponen aplikasi, dan jenis metode enkripsi yang akan digunakan. Untuk beberapa contoh arsitektur, lihat ilustrasi di bagian Contoh dari artikel Manajemen identitas dan akses dan Jaringan .

Mengevaluasi kesediaan yang disediakan platform

Penting untuk memahami pembagian tanggung jawab antara Anda dan penyedia cloud. Hindari tumpang tindih dengan kontrol keamanan asli Azure, misalnya. Anda akan mendapatkan cakupan keamanan yang lebih baik dan dapat merealokasi sumber daya pengembangan dengan kebutuhan aplikasi.

Misalnya, jika desain Anda memanggil firewall aplikasi web saat masuk, Anda dapat membongkar tanggung jawab tersebut ke load balancer seperti Application Gateway atau Azure Front Door. Hindari mereplikasi fitur sebagai kode kustom di aplikasi Anda.

Pilih hanya kerangka kerja tepercaya, pustaka, dan perangkat lunak rantai pasokan. Desain Anda juga harus menentukan kontrol versi yang aman. Dependensi aplikasi harus bersumber dari pihak tepercaya. Vendor pihak ketiga harus dapat memenuhi persyaratan keamanan Anda dan berbagi rencana pengungkapan yang bertanggung jawab. Setiap insiden keamanan harus segera dilaporkan sehingga Anda dapat mengambil tindakan yang diperlukan. Selain itu, pustaka tertentu mungkin dilarang oleh organisasi Anda. Misalnya, perangkat lunak mungkin aman dari kerentanan tetapi masih tidak diizinkan karena pembatasan lisensi.

Untuk memastikan bahwa panduan ini diikuti oleh semua kontributor perangkat lunak, pertahankan daftar kerangka kerja, pustaka, dan vendor yang disetujui dan/atau tidak disetujui. Jika memungkinkan, tempatkan pagar pembatas dalam alur pengembangan untuk mendukung daftar. Sebanyak mungkin, otomatiskan penggunaan alat untuk memindai dependensi kerentanan.

Tentukan pola desain keamanan yang harus diterapkan kode aplikasi.

Pola dapat mendukung masalah keamanan seperti segmentasi dan isolasi, otorisasi yang kuat, keamanan aplikasi yang seragam, dan protokol modern. Beberapa pola operasional, seperti pola Karantina, dapat membantu memverifikasi dan memblokir penggunaan perangkat lunak yang berpotensi menimbulkan kerentanan keamanan.

Untuk informasi selengkapnya, lihat Pola desain cloud yang mendukung keamanan.

Simpan rahasia aplikasi dengan aman

Terapkan penggunaan rahasia aplikasi dan kunci yang dibagikan sebelumnya dengan aman yang digunakan aplikasi Anda. Kredensial dan rahasia aplikasi tidak boleh disimpan di pohon kode sumber. Gunakan sumber daya eksternal seperti Azure Key Vault untuk memastikan bahwa, jika kode sumber Anda tersedia untuk penyerang potensial, tidak ada akses lebih lanjut yang dapat diperoleh. Secara umum, temukan cara untuk menghindari rahasia. Menggunakan identitas terkelola, jika memungkinkan, adalah salah satu cara untuk mencapai tujuan tersebut. Untuk informasi selengkapnya, lihat Rekomendasi untuk mengelola rahasia aplikasi.

Tentukan rencana pengujian

Tentukan kasus pengujian yang jelas untuk persyaratan keamanan. Evaluasi apakah Anda dapat mengotomatiskan pengujian tersebut di alur Anda. Jika tim Anda memiliki proses untuk pengujian manual, sertakan persyaratan keamanan untuk pengujian tersebut.

Catatan

Lakukan pemodelan ancaman selama fase ini. Pemodelan ancaman dapat mengonfirmasi bahwa pilihan desain selaras dengan persyaratan keamanan dan mengekspos celah yang harus Anda mitigasi. Jika beban kerja Anda menangani data yang sangat sensitif, investasikan pada pakar keamanan yang dapat membantu Anda melakukan pemodelan ancaman.

Latihan pemodelan ancaman awal harus terjadi selama fase desain ketika arsitektur perangkat lunak dan desain tingkat tinggi sedang ditentukan. Melakukannya selama fase tersebut membantu Anda mengidentifikasi potensi masalah keamanan sebelum dimasukkan ke dalam struktur sistem. Namun, latihan ini bukan aktivitas satu kali. Ini adalah proses berkelanjutan yang harus berlanjut sepanjang evolusi perangkat lunak.

Untuk informasi selengkapnya, lihat Rekomendasi untuk analisis ancaman.

Fase pengembangan dan pengujian

Selama fase ini, tujuannya adalah untuk mencegah cacat keamanan dan mengubah alur kode, build, dan penyebaran.

Terlatih dengan baik dalam praktik kode yang aman

Tim pengembangan harus memiliki pelatihan formal dan khusus dalam praktik pengkodan yang aman. Misalnya, pengembang web dan API mungkin memerlukan pelatihan khusus untuk melindungi dari serangan scripting lintas situs, dan pengembang back-end dapat memperoleh manfaat dari pelatihan mendalam untuk menghindari serangan tingkat database seperti serangan injeksi SQL.

Pengembang harus diharuskan untuk menyelesaikan pelatihan ini sebelum mereka dapat memperoleh akses ke kode sumber produksi.

Anda juga harus melakukan tinjauan kode serekan internal untuk mempromosikan pembelajaran berkelanjutan.

Menggunakan alat uji keamanan

Lakukan pemodelan ancaman untuk mengevaluasi keamanan arsitektur aplikasi.

Gunakan pengujian keamanan aplikasi statis (SAST) untuk menganalisis kode kerentanan. Integrasikan metodologi ini ke lingkungan pengembang untuk mendeteksi kerentanan secara real time.

Gunakan pengujian keamanan aplikasi dinamis (DAST) selama runtime. Rantai alat ini dapat memeriksa kesalahan dalam domain keamanan dan mensimulasikan serangkaian serangan untuk menguji ketahanan keamanan aplikasi. Jika memungkinkan, integrasikan alat ini ke dalam alur build Anda.

Ikuti standar industri untuk praktik pengkodian yang aman. Untuk informasi selengkapnya, lihat bagian Sumber daya komunitas di artikel ini.

Gunakan linter dan penganalisis kode untuk mencegah kredensial didorong ke repositori kode sumber. Misalnya, Penganalisis .NET Compiler Platform (Roslyn) memeriksa kode aplikasi Anda.

Selama proses build, gunakan add-on alur untuk menangkap kredensial dalam kode sumber. Pindai semua dependensi, seperti pustaka pihak ketiga dan komponen kerangka kerja, sebagai bagian dari proses integrasi berkelanjutan. Selidiki komponen rentan yang ditandai oleh alat. Gabungkan tugas ini dengan tugas pemindaian kode lainnya yang memeriksa churn kode, hasil pengujian, dan cakupan.

Gunakan kombinasi pengujian. Untuk informasi tentang pengujian keamanan secara umum, lihat Rekomendasi untuk pengujian keamanan.

Menulis kode yang cukup

Saat Anda mengurangi jejak kode, Anda juga mengurangi kemungkinan cacat keamanan. Gunakan kembali kode dan pustaka yang sudah digunakan dan telah melalui validasi keamanan alih-alih menduplikasi kode.

Memanfaatkan fitur Azure adalah cara lain untuk mencegah kode yang tidak perlu. Salah satu caranya adalah dengan menggunakan layanan terkelola. Untuk informasi selengkapnya, lihat Opsi Gunakan platform sebagai sebuah layanan (PaaS).

Tulis kode dengan pendekatan tolak-semua secara default. Buat daftar izin hanya untuk entitas yang memerlukan akses. Misalnya, jika Anda memiliki kode yang perlu menentukan apakah operasi istimewa harus diizinkan, Anda harus menulisnya sehingga hasil penolakan adalah kasus default dan hasil yang diizinkan hanya terjadi ketika secara khusus diizinkan oleh kode.

Melindungi lingkungan pengembang

Stasiun kerja pengembang perlu dilindungi dengan kontrol jaringan dan identitas yang kuat untuk mencegah paparan. Pastikan pembaruan keamanan diterapkan dengan rajin.

Agen build sangat istimewa dan memiliki akses ke server build dan kode. Mereka harus dilindungi dengan kekakuan yang sama dengan komponen beban kerja Anda. Ini berarti bahwa akses ke agen build harus diautentikasi dan diotorisasi, mereka harus disegmentasi jaringan dengan kontrol firewall, mereka harus tunduk pada pemindaian kerentanan, dan sebagainya. Agen build yang dihosting Microsoft harus lebih disukai daripada agen build yang dihost sendiri. Agen yang dihosting Microsoft memberikan manfaat seperti komputer virtual yang bersih untuk setiap eksekusi alur.

Agen build kustom menambah kompleksitas manajemen dan dapat menjadi vektor serangan. Kredensial komputer build harus disimpan dengan aman, dan Anda perlu secara teratur menghapus artefak build sementara dari sistem file. Anda dapat mencapai isolasi jaringan dengan hanya mengizinkan lalu lintas keluar dari agen build, karena menggunakan model penarikan komunikasi dengan Azure DevOps.

Repositori kode sumber juga harus dijaga . Berikan akses ke repositori kode secara perlu diketahui dan kurangi paparan kerentanan sebanyak mungkin untuk menghindari serangan. Memiliki proses menyeluruh untuk meninjau kode untuk kerentanan keamanan. Gunakan kelompok keamanan untuk tujuan tersebut, dan terapkan proses persetujuan yang didasarkan pada pembenaran bisnis.

Amankan penyebaran kode

Ini tidak cukup untuk hanya mengamankan kode. Jika berjalan dalam alur yang dapat dieksploitasi, semua upaya keamanan sia-sia dan tidak lengkap. Lingkungan build dan rilis juga harus dilindungi karena Anda ingin mencegah pelaku jahat menjalankan kode berbahaya di alur Anda.

Pertahankan inventori terbaru dari setiap komponen yang diintegrasikan ke dalam aplikasi Anda

Setiap komponen baru yang diintegrasikan ke dalam aplikasi meningkatkan permukaan serangan. Untuk memastikan akuntabilitas dan peringatan yang tepat ketika komponen baru ditambahkan atau diperbarui, Anda harus memiliki inventarisasi komponen-komponen ini. Simpan di luar lingkungan build. Secara teratur, periksa apakah manifes Anda cocok dengan apa yang ada dalam proses build Anda. Melakukannya membantu memastikan bahwa tidak ada komponen baru yang berisi pintu belakang atau malware lainnya yang ditambahkan secara tak terduga.

Tugas alur

  • Tarik tugas di alur Anda dari sumber tepercaya, seperti Marketplace Azure. Jalankan tugas yang ditulis oleh vendor alur Anda. Kami merekomendasikan tugas GitHub atau GitHub Actions. Jika Anda menggunakan alur kerja GitHub, lebih suka tugas yang ditulis Microsoft. Selain itu, validasi tugas karena dijalankan dalam konteks keamanan alur Anda.

  • Rahasia alur. Aset penyebaran yang berjalan di dalam alur memiliki akses ke semua rahasia dalam alur tersebut. Memiliki segmentasi yang tepat untuk berbagai tahap alur untuk menghindari paparan yang tidak perlu. Gunakan penyimpanan rahasia yang disertakan dalam alur. Ingatlah bahwa Anda dapat menghindari penggunaan rahasia dalam beberapa situasi. Jelajahi penggunaan identitas beban kerja (untuk autentikasi alur) dan identitas terkelola (untuk autentikasi layanan ke layanan).

Memisahkan lingkungan yang berbeda

Data yang digunakan di lingkungan yang berbeda harus dipisahkan. Data produksi tidak boleh digunakan di lingkungan yang lebih rendah karena lingkungan tersebut mungkin tidak memiliki kontrol keamanan ketat yang dimiliki produksi. Hindari menyambungkan dari aplikasi non-produksi ke database produksi, dan hindari menyambungkan komponen non-produksi ke jaringan produksi.

Paparan progresif

Gunakan paparan progresif untuk merilis fitur ke subset pengguna berdasarkan kriteria yang dipilih. Jika ada masalah, dampaknya diminimalkan ke pengguna tersebut. Pendekatan ini adalah strategi mitigasi risiko umum karena mengurangi area permukaan. Saat fitur ini matang dan Anda memiliki lebih banyak kepercayaan pada jaminan keamanan, Anda dapat secara bertahap merilisnya ke sekumpulan pengguna yang lebih luas.

Fase produksi

Fase produksi menyajikan kesempatan terakhir yang bertanggung jawab untuk memperbaiki kesenjangan keamanan. Simpan catatan gambar emas yang dirilis dalam produksi.

Pertahankan artefak versi

Simpan katalog semua aset yang disebarkan dan versinya. Informasi ini berguna selama triase insiden, saat Anda mengurangi masalah, dan saat Anda membuat sistem kembali berfungsi. Aset versi juga dapat dibandingkan dengan pemberitahuan Kerentanan dan Paparan Umum (CVE) yang diterbitkan. Anda harus menggunakan otomatisasi untuk melakukan perbandingan ini.

Perbaikan darurat

Desain alur otomatis Anda harus memiliki fleksibilitas untuk mendukung penyebaran reguler dan darurat. Fleksibilitas ini penting untuk mendukung perbaikan keamanan yang cepat dan bertanggung jawab.

Rilis biasanya dikaitkan dengan beberapa gerbang persetujuan. Pertimbangkan untuk membuat proses darurat untuk mempercepat perbaikan keamanan. Proses ini mungkin melibatkan komunikasi antar tim. Alur harus memungkinkan penyebaran roll-forward dan rollback cepat yang mengatasi perbaikan keamanan, bug penting, dan pembaruan kode yang terjadi di luar siklus hidup penyebaran reguler.

Catatan

Selalu prioritaskan perbaikan keamanan daripada kenyamanan. Perbaikan keamanan tidak boleh memperkenalkan regresi atau bug. Jika Anda ingin mempercepat perbaikan melalui alur darurat, pertimbangkan dengan cermat pengujian otomatis mana yang dapat dilewati. Evaluasi nilai setiap pengujian terhadap waktu eksekusi. Misalnya, pengujian unit biasanya selesai dengan cepat. Integrasi atau pengujian menyeluruh dapat berjalan dalam waktu yang lama.

Fase pemeliharaan

Tujuan dari fase ini adalah untuk memastikan postur keamanan tidak membusuk dari waktu ke waktu. SDLC adalah proses tangkas yang sedang berlangsung. Konsep yang tercakup dalam fase sebelumnya berlaku untuk fase ini karena persyaratan berubah dari waktu ke waktu.

Manajemen patch. Selalu perbarui komponen perangkat lunak, pustaka, dan infrastruktur dengan patch dan pembaruan keamanan.

Peningkatan berkelanjutan. Terus menilai dan meningkatkan keamanan proses pengembangan perangkat lunak dengan mempertimbangkan ulasan kode, umpan balik, pelajaran yang dipelajari, dan ancaman yang berkembang.

Menonaktifkan aset warisan yang basi atau tidak lagi digunakan. Melakukannya mengurangi area permukaan aplikasi.

Pemeliharaan juga mencakup perbaikan insiden. Jika masalah ditemukan dalam produksi, masalah harus segera diintegrasikan kembali ke dalam proses sehingga tidak berulang.

Terus tingkatkan praktik pengkodian aman Anda untuk mengikuti lanskap ancaman.

Fasilitasi Azure

Microsoft Security Development Lifecycle (SDL) merekomendasikan praktik aman yang dapat Anda terapkan ke siklus hidup pengembangan Anda. Untuk informasi selengkapnya, lihat Siklus Hidup Pengembangan Keamanan Microsoft.

Defender untuk DevOps dan alat SAST disertakan sebagai bagian dari GitHub Advanced Security atau Azure DevOps. Alat-alat ini dapat membantu Anda melacak skor keamanan untuk organisasi Anda.

Ikuti rekomendasi keamanan Azure yang dijelaskan dalam sumber daya ini:

Untuk menemukan kredensial dalam kode sumber, pertimbangkan untuk menggunakan alat seperti GitHub Advanced Security dan alat analisis kode sumber OWASP.

Validasi keamanan kode sumber terbuka apa pun di aplikasi Anda. Alat dan sumber daya gratis ini dapat membantu Anda dengan penilaian Anda:

Daftar periksa keamanan

Lihat serangkaian rekomendasi lengkap.

Daftar periksa keamanan