Strategi arsitektur untuk mengamankan siklus hidup pengembangan

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

SE:02 Selaraskan siklus hidup pengembangan aman (SDL) di seluruh siklus hidup pengembangan perangkat lunak (SDLC) untuk memastikan kerahasiaan, integritas, dan ketersediaan perangkat lunak dan mengadopsi pola pikir keamanan-pertama.

Kode aplikasi adalah inti dari setiap beban kerja. Sematkan keamanan di seluruh SDLC dengan mengintegrasikan kontrol pada beberapa tahap pengembangan. Tujuannya adalah untuk memastikan keputusan desain tidak memperkenalkan celah keamanan yang dapat dihindari dan bahwa pilihan kode dan konfigurasi tidak mengakibatkan kerentanan yang dapat dieksploitasi.

Diagram siklus keamanan.

Panduan ini menjelaskan praktik terbaik keamanan untuk melindungi kode aplikasi dan mencegah implementasi yang rentan dan pengenalan komponen yang disusupi. Perluas praktik terbaik ke komponen pihak ketiga dan sumber terbuka untuk mengurangi risiko rantai pasokan. Fokusnya bukan pada lapisan infrastruktur.

Panduan ini berdasarkan pada praktik SDL dan berdasarkan pemahaman dasar prinsip-prinsip DevSecOps. Ini memperluas di luar kode aplikasi untuk mengatasi rantai pasokan perangkat lunak lengkap, termasuk stasiun kerja pengembang, repositori sumber, sistem build, dan lingkungan penyebaran.

Terminologi

Istilah Definition
Kerentanan Umum dan Eksposur (CVE) Database yang tersedia untuk umum tentang kerentanan dan paparan keamanan yang diketahui dalam produk perangkat lunak dan perangkat keras.
Pertahanan berlapis Strategi keamanan yang menggunakan beberapa lapisan perlindungan untuk melindungi sistem, jadi jika satu lapisan gagal, yang lain terus memberikan keamanan.
DevSecOps Pendekatan yang mengintegrasikan praktik keamanan ke dalam proses DevOps, menekankan kolaborasi antara tim pengembangan, keamanan, dan operasi di seluruh siklus hidup perangkat lunak.
Pengujian Keamanan Aplikasi Dinamis (DAST) Pengujian keamanan yang menganalisis aplikasi selama runtime untuk mengidentifikasi kerentanan dengan mensimulasikan skenario serangan dunia nyata.
Identitas yang dikelola Fitur Azure yang menyediakan aplikasi dengan identitas terkelola secara otomatis di ID Microsoft Entra, menghilangkan kebutuhan untuk menyimpan kredensial dalam kode.
Eksposur progresif Strategi penyebaran yang secara bertahap merilis perubahan pada kelompok pengguna untuk meminimalkan risiko, dan menangani potensi masalah.
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.
Pengujian Keamanan Aplikasi Statis (SAST) Pengujian keamanan yang menganalisis kode sumber, bytecode, atau biner tanpa mengeksekusi program untuk mengidentifikasi potensi kerentanan.
LANGKAHNYA Metodologi pemodelan ancaman yang mengategorikan ancaman menjadi enam jenis: Spoofing, Tampering, Repudiasi, Pengungkapan informasi, Penolakan layanan, dan Peningkatan hak akses.
Keamanan rantai pasokan Perlindungan seluruh rantai pasokan perangkat lunak, termasuk komponen pihak ketiga, alat pengembangan, dan proses dari kompromi atau perusakan.
Pemodelan ancaman Proses terstruktur untuk mengidentifikasi, mengevaluasi, dan mengurangi potensi ancaman keamanan terhadap sistem di awal fase desain.

Pikirkan tentang keamanan sejak hari pertama

Selama diskusi perencanaan dan arsitektur paling awal, tentukan persyaratan keamanan fungsi dan non-fungsi bersama tujuan bisnis. Terapkan kontrol keamanan pada lapisan arsitektur. Pikirkan tentang batas isolasi, akses luar masuk dan keluar, dan tingkat sensitivitas yang berlaku untuk data beban kerja. Sebaiknya ikuti daftar periksa Keamanan dengan rajin untuk mengembangkan dimensi keamanan arsitektur. Tinjau juga pola desain arsitektur yang mendukung keamanan.

Agar tim tetap akuntabel, pertimbangan dan hasil keamanan harus ditambahkan langsung ke item backlog sehingga dirancang dan dikirimkan sebagai bagian dari produk. Misalnya, pertimbangkan aplikasi yang mendukung alur pengguna penting yang memungkinkan pengguna mengunggah dan memanipulasi data. Hasil kerja keamanan harus mengatasi bagaimana pengguna berinteraksi dengan sistem (memberlakukan autentikasi dan otorisasi yang kuat) untuk memastikan hanya tindakan yang diizinkan yang diizinkan.

Arsitek harus secara eksplisit mendokumen trade-off keamanan dan memformalkan penerimaan risiko untuk memastikan transparansi dan akuntabilitas. Misalnya, keputusan keamanan mungkin memerlukan langkah-langkah untuk memblokir kerentanan OWASP di muka. Jika pemangku kepentingan memilih untuk tidak mendanainya, mereka harus mengakui dan menerima risiko serangan lapisan aplikasi yang dihasilkan.

Pilih opsi teknologi yang mendukung keamanan

Identifikasi kontrol keamanan yang diperlukan untuk mencapai hasil yang Anda inginkan dan manfaatkan kemampuan asli Azure jika memungkinkan. Misalnya, tentukan strategi segmentasi menggunakan batas identitas, jaringan, dan sumber daya, dan pilih firewall aplikasi web (WAF) seperti Azure Front Door atau Azure Application Gateway untuk melindungi aplikasi. Ketika WAF diperlukan saat masuk, gunakan layanan terkelola ini alih-alih mereplikasi fungsionalitasnya dalam kode aplikasi kustom.

Pertimbangan teknis juga termasuk hanya memilih kerangka kerja tepercaya, pustaka, dan perangkat lunak rantai pasokan, yang bersumber dari penyedia terverifikasi. Vendor pihak ketiga harus memenuhi persyaratan keamanan Anda dan mempertahankan rencana pengungkapan yang bertanggung jawab, segera melaporkan insiden keamanan apa pun. Pertahankan daftar aset yang disetujui dan tidak diizinkan, dan jika memungkinkan, terapkan pagar pembatas dalam alur pengembangan untuk mencegah penggunaan komponen yang tidak disetujui. Untuk dependensi yang disetujui, pemindaian otomatis membantu mendeteksi kerentanan secara dini dan konsisten.

Tentukan cara menyimpan rahasia aplikasi dan kunci yang telah dibagikan sebelumnya dengan cara yang aman. Jangan pernah menyimpan kredensial atau rahasia di repositori kode sumber. Gunakan alat eksternal, seperti Azure Key Vault, sehingga bahkan jika kode sumber terekspos, penyerang tidak dapat memperoleh akses. Jika memungkinkan, hindari menggunakan rahasia sama sekali, misalnya, dengan memanfaatkan identitas terkelola. Untuk panduan selengkapnya, lihat Rekomendasi untuk mengelola rahasia aplikasi.

Jadikan pemodelan ancaman sebagai disiplin desain

Pemodelan ancaman membantu Anda mengidentifikasi kerentanan, mengevaluasi ancaman, dan menentukan mitigasi di awal fase desain. Mulailah dengan menentukan cakupan: tetapkan batas sistem yang jelas dan inventarisi aset Anda sehingga Anda fokus pada hal yang paling penting. Kumpulkan informasi terperinci tentang setiap komponen, termasuk aliran data dan dependensi, dan analisis masing-masing dari perspektif penyerang untuk menentukan bagaimana hal itu dapat dieksploitasi. Mengadopsi pola pikir asumsikan pelanggaran —rencanakan kegagalan kontrol dan terapkan pertahanan mendalam untuk membatasi dampak.

Gunakan metodologi industri seperti STRIDE untuk mengklasifikasikan ancaman dan mendorong keputusan mitigasi. Dokumentasikan setiap ancaman yang diidentifikasi, kontrol yang mencegahnya, dan rencana respons jika kontrol tersebut gagal. Tentukan garis waktu dan kepemilikan yang jelas untuk mengatasi kerentanan dengan cepat agar tidak dibiarkan tidak tertangani.

Lacak hasil pemodelan ancaman dan tinjau kembali selama siklus hidup beban kerja. Perbarui model saat arsitektur berkembang untuk memastikan fitur dan perubahan baru tidak menimbulkan risiko yang tidak terkelola.

Lihat: Alat Pemodelan Ancaman Microsoft

Membangun keahlian pengkodian yang aman

Pastikan tim pengembangan menyelesaikan pelatihan formal dan khusus peran dalam praktik pengkodan yang aman. Misalnya, pengembang web dan API harus tahu cara mencegah scripting lintas situs (XSS), sementara pengembang back-end harus memahami cara mengurangi risiko seperti injeksi SQL dan serangan lapisan database lainnya. Mengharuskan pengembang untuk menyelesaikan pelatihan ini sebelum memberikan akses ke kode sumber produksi. Perkuat keterampilan ini melalui tinjauan kode rekan internal, yang mempromosikan akuntabilitas, berbagi pengetahuan, dan peningkatan berkelanjutan.

Menggunakan pengujian keamanan sebagai kontrol strategis

Jadikan pengujian keamanan sebagai disiplin teknik inti. Tetapkan strategi pengujian yang mengevaluasi arsitektur, kode, dan perilaku runtime terus menerus sepanjang siklus hidup pengembangan. Gunakan campuran analisis arsitektur, pengujian statis dan dinamis, pemindaian dependensi, dan pagar pembatas otomatis.

Gunakan pengujian keamanan aplikasi statis (SAST) untuk mendeteksi kerentanan dalam kode saat pengembang menulisnya. Melengkapi ini dengan pengujian keamanan aplikasi dinamis (DAST) untuk mengevaluasi aplikasi yang sedang berjalan dan mensimulasikan skenario serangan dunia nyata.

Integrasikan pemindaian keamanan otomatis ke dalam alur kerja build dan integrasi sehingga keamanan menjadi gerbang kualitas. Pindai dependensi dan komponen pihak ketiga terus menerus, dan perlakukan pustaka yang rentan sebagai risiko rantai pasokan yang memerlukan manajemen aktif. Gunakan linter dan penganalisis kode untuk mencegah data sensitif, seperti kredensial, masuk ke sistem kendali sumber, dan memperkuat perlindungan ini dengan kontrol pipeline yang mendeteksi dan memblokir terungkapnya rahasia.

Mengadopsi standar industri sebagai cara untuk meningkatkan kepercayaan diri ketahanan keamanan Anda. Untuk informasi selengkapnya, lihat bagian Sumber daya komunitas di artikel ini.

Tulis kode yang cukup

Setiap baris kode meningkatkan permukaan serangan Anda. Prioritaskan penggunaan kembali daripada penemuan ulang. Gunakan kerangka kerja dan pustaka yang mapan yang telah menjalani validasi keamanan alih-alih menduplikasi fungsionalitas dalam kode kustom.

Adopsi pola pikir yang mengutamakan platform. Gunakan layanan Azure terkelola dan kapabilitas PaaS jika memungkinkan untuk mengalihkan tugas berat ke Azure, seperti autentikasi, enkripsi, penskalaan, dan perlindungan ingress. Semakin sedikit logika keamanan kustom yang Anda tulis, semakin rendah risiko jangka panjang Anda.

Saat Anda menulis kode, default untuk menolak. Desain logika otorisasi agar akses diblokir kecuali jika secara eksplisit diizinkan. Gunakan daftar izin untuk entitas tertentu yang disetujui, dan pastikan operasi istimewa hanya berhasil jika diotorisasi dengan jelas.

Membentengi lingkungan pengembang

Lingkungan pengembangan Anda adalah bagian dari permukaan serangan Anda. Lindungi stasiun kerja pengembang dengan kekakuan yang sama dengan sistem produksi. Ini berarti memberlakukan kontrol identitas yang kuat, menerapkan perlindungan jaringan, dan mempertahankan patching disiplin. Stasiun kerja yang disusupi dapat menjadi jalur langsung ke basis kode dan sistem build Anda.

Repositori kode sumber Anda adalah aset penting. Berikan akses dengan prinsip hak akses minimum dan hanya berdasarkan kebutuhan. Tetapkan proses peninjauan kode terstruktur dan berfokus pada keamanan dengan alur kerja persetujuan yang jelas terkait dengan pembenaran bisnis. Tata kelola yang kuat atas repositori dan alur mengurangi kemungkinan perusakan dan membatasi dampak pelanggaran.

Selain itu, akses jaringan harus disegmentasi sehingga pengembang tidak memiliki akses langsung ke sistem produksi.

Alat pengembangan juga dapat membantu meningkatkan keamanan dengan menggunakan ekstensi IDE yang memantau kode seperti yang ditulis dan memindai build lokal untuk kerentanan. Kredensial harus dilindungi dengan memastikan rahasia tidak disimpan dalam file konfigurasi dan dengan menggunakan manajer kredensial saat akses ke rahasia diperlukan.

Pengembang harus mengikuti alat pengembang yang disetujui dan menggunakan penginstalan yang dikelola secara terpusat. Lingkungan pengembangan, seperti GitHub Codespaces dan Microsoft Dev Box, dapat memberlakukan keamanan dengan menyediakan ruang kerja yang terisolasi dan dikelola secara terpusat.

Pengujian juga harus dijalankan di lingkungan terkontrol hanya dengan izin minimum yang diperlukan.

Alur build dan penyebaran yang aman

Alur build dan penyebaran adalah target utama. Penyerang dapat merusak alur Anda, menyuntikkan kode berbahaya, mengakses rahasia, atau membahayakan lingkungan hilir.

Perlakukanlah agen pembangunan sebagai aset bernilai tinggi. Mereka memiliki akses istimewa ke kode sumber dan membangun alur, yang menjadikannya target yang menarik. Autentikasi dan otorisasi akses secara ketat, segmentasikan akses di tingkat jaringan, dan lakukan pemantauan keamanan secara terus-menerus. Lebih suka agen build yang dihosting oleh Microsoft daripada yang dihost sendiri untuk mengurangi risiko operasional dan membatasi persistensi, karena mereka menyediakan lingkungan yang bersih untuk setiap eksekusi pipeline. Agen khusus meningkatkan beban manajemen dan memperluas area serangan.

Amankan kredensial build dan hapus artefak sementara untuk mencegah kebocoran. Jika memungkinkan, isolasi agen build dengan membatasi akses masuk dan hanya mengizinkan komunikasi keluar yang dikontrol.

Mulailah dengan mempertahankan visibilitas dan kontrol yang jelas. Simpan daftar inventaris terkini dari semua komponen dan dependensi terintegrasi, dan verifikasi secara rutin bahwa apa yang dijalankan dalam alur kerja sesuai dengan yang telah disetujui. Hanya gunakan tugas dan ekstensi alur dari sumber tepercaya dan tervalidasi, mengenali bahwa mereka menjalankan dengan akses istimewa.

Lindungi kredensial dengan menghilangkan rahasia yang dikodekan secara permanen dan utamakan identitas terkelola serta penyimpanan rahasia yang aman.Segmentasikan tahap alur untuk mengurangi paparan yang tidak perlu terhadap aset sensitif dan batasi pergerakan lateral jika tahap disusupi.

Isolasi lingkungan sama pentingnya. Sistem produksi dan non-produksi yang terpisah secara ketat, hindari menggunakan data produksi di lingkungan yang lebih rendah tanpa perlindungan yang setara, dan mencegah konektivitas langsung yang dapat memungkinkan pelanggaran menyebar. Mengontrol risiko melalui paparan progresif. Merilis perubahan secara bertahap, menggunakan pengaturan fitur atau peluncuran bertahap, sehingga jika kerentanan muncul, Anda dapat membatasi dampaknya. Rancang alur Anda untuk mendukung penyebaran reguler dan darurat. Perbaikan keamanan sering memerlukan respons yang cepat, dan proses Anda harus memungkinkan roll-forward atau putar kembali cepat tanpa mengorbankan stabilitas sistem. Tetapkan prosedur komunikasi dan persetujuan yang jelas untuk mempercepat perubahan darurat secara bertanggung jawab.

Nota

Selalu prioritaskan perbaikan keamanan daripada kenyamanan. Tetapi jangan pernah membahayakan kualitas atau memperkenalkan regresi. Jika Anda perlu mempercepat proses perbaikan bug melalui pipeline darurat, evaluasi pengujian otomatis mana yang dapat dilewati dengan aman. Pertimbangkan pertimbangan antara nilai setiap pengujian dan waktu eksekusinya. Misalnya, pengujian unit cepat dan penting, sementara integrasi atau pengujian end-to-end mungkin memakan waktu lebih lama tetapi masih memberikan cakupan penting. Ambillah keputusan ini secara sengaja untuk menyeimbangkan kecepatan dengan keyakinan dalam perbaikan.

Lindungi kode dalam produksi

Produksi adalah garis pertahanan terakhir untuk melindungi kode pengembang sebelum mencapai pengguna. Teams harus mempertahankan catatan golden image yang diterapkan ke lingkungan produksi dan menyimpan katalog semua aset yang diterapkan beserta versinya, sehingga dapat mendukung pemecahan masalah, respons insiden, dan manajemen kerentanan. Ini juga dapat memengaruhi mekanisme penyimpangan konfigurasi. Pemeriksaan otomatis terhadap CVE yang diterbitkan membantu mengidentifikasi komponen yang sudah kedaluarsa atau berisiko dengan cepat.

Lingkungan pengembangan seharusnya tidak memiliki akses produksi langsung. Akses tersebut harus dibatasi. Selain itu, secara teratur mengganti rahasia dan sertifikat, serta melakukan latihan yang berfokus pada aspek keamanan seperti simulasi tabletop dan aktivitas red-teaming untuk memvalidasi pertahanan.

Lindungi kode dari pengembangan hingga penonaktifan

Melindungi kode adalah tanggung jawab yang sedang berlangsung. SDLC berulang, dan persyaratan berkembang, sehingga praktik dari fase sebelumnya harus terus diterapkan dan diperkuat dari waktu ke waktu.

Selalu perbarui semua perangkat lunak, pustaka, dan komponen infrastruktur dengan patch keamanan tepat waktu. Terus menilai dan meningkatkan proses Anda dengan menggabungkan pelajaran dari ulasan kode, umpan balik, penyelidikan insiden, dan ancaman yang muncul. Segera integrasikan perbaikan dari masalah produksi kembali ke siklus hidup pengembangan untuk mencegah pengulangan.

Menonaktifkan aset warisan yang tidak lagi digunakan untuk mengurangi permukaan serangan dan menyederhanakan pemeliharaan. Perbaiki praktik pengodean aman secara berkala untuk tetap terdepan terhadap ancaman yang berkembang, memastikan posisi keamanan Anda tetap kuat dan tangguh selama siklus hidup.

Dukungan 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 kumpulan rekomendasi lengkap.

Daftar periksa keamanan

  • Last updated on