Agen, proyek, dan kontainer yang aman

Layanan Azure DevOps | Azure DevOps Server | Azure DevOps Server 2022

Saat mengamankan Azure Pipelines, pertimbangkan untuk melindungi infrastruktur bersama, repositori, proyek, dan lainnya.

Artikel ini adalah bagian dari seri yang membantu Anda menerapkan langkah-langkah keamanan untuk Azure Pipelines. Untuk informasi selengkapnya, lihat Mengamankan Azure Pipelines.

Prasyarat

Kategori	Persyaratan
Azure DevOps	- Terapkan rekomendasi di Membuat Azure DevOps Anda aman dan Alur Azure Aman. - Pengetahuan dasar tentang YAML dan Azure Pipelines. Untuk informasi selengkapnya, lihat Buat pipa pertama Anda.
Izin	- Untuk mengubah izin alur: Anggota grup Administrator Proyek. - Untuk mengubah izin organisasi: Anggota grup Administrator Koleksi Proyek.

Melindungi infrastruktur bersama

Sumber daya yang dilindungi di Azure Pipelines adalah abstraksi infrastruktur nyata. Ikuti rekomendasi ini untuk melindungi infrastruktur yang mendasar.

Menggunakan kumpulan yang dihosting Microsoft

Pool yang dihosting oleh Microsoft menyediakan isolasi dan komputer virtual yang bersih untuk setiap kali pipeline dijalankan. Jika memungkinkan, gunakan kumpulan yang dihosting Microsoft alih-alih kumpulan yang dihost sendiri.

Agen terpisah untuk setiap proyek

Agen hanya dapat terhubung dengan satu kumpulan. Anda dapat berbagi agen di seluruh proyek dengan mengaitkan kumpulan dengan beberapa proyek. Dalam praktiknya, beberapa proyek mungkin menggunakan agen yang sama secara berturut-turut. Meskipun hemat biaya, pendekatan ini dapat menimbulkan risiko pergerakan lateral.

Untuk mengurangi gerakan lateral dan mencegah kontaminasi silang antar proyek, pertahankan kumpulan agen terpisah, masing-masing didedikasikan untuk proyek tertentu.

Menggunakan akun dengan hak istimewa rendah untuk menjalankan agen

Menjalankan agen di bawah identitas dengan akses langsung ke sumber daya Azure DevOps bisa berisiko. Risiko ini lazim di organisasi yang menggunakan ID Microsoft Entra.

Mengapa risiko ini penting:

• Jika Anda menjalankan agen di bawah identitas yang didukung oleh ID Entra, agen tersebut dapat langsung mengakses API Azure DevOps tanpa mengandalkan token akses pekerjaan.
• Pihak lawan yang menjalankan pipeline yang diretas pada agen build ini potensial mendapatkan kontrol atas seluruh organisasi Azure DevOps.

Rekomendasi: Jalankan agen dengan menggunakan akun lokal yang tidak memiliki hak istimewa:

• Agen Windows: Gunakan Layanan Jaringan (NT AUTHORITY\NETWORK SERVICE), Layanan Lokal, atau Akun Layanan Terkelola Grup (gMSA).
• Agen Linux dan agen macOS: Buat akun pengguna non-root khusus (misalnya, svc_azuredevops). Akun ini seharusnya tidak memiliki akses sudo atau sudoers untuk keamanan maksimum.

Penting

Di Azure DevOps, grup Akun Layanan Koleksi Proyek dapat menyesatkan. Berdasarkan pewarisan, anggota Akun Layanan Koleksi Proyek juga merupakan anggota Administrator Koleksi Proyek. Beberapa pelanggan menjalankan agen build mereka dengan menggunakan identitas yang didukung oleh ID Entra, dan identitas ini dapat menjadi bagian dari Akun Layanan Koleksi Proyek.

Risiko agen yang sangat istimewa:

Agen yang di-host sendiri terkadang beroperasi di bawah akun dengan hak istimewa tinggi untuk mengakses rahasia atau lingkungan produksi. Jika lawan menjalankan pipeline yang disusupi pada salah satu agen build ini, mereka dapat:

• Mendapatkan akses ke rahasia tersebut
• Berpindah secara lateral melalui sistem lain yang dapat diakses melalui akun-akun ini

Praktik terbaik untuk keamanan agen:

• Gunakan akun dengan hak istimewa terendah yang mungkin untuk menjalankan agen yang dihost sendiri.
• Pertimbangkan untuk menggunakan akun komputer Anda atau identitas layanan terkelola.
• Biarkan Azure Pipelines mengelola akses ke rahasia dan lingkungan.

Meminimalkan cakupan koneksi layanan

Koneksi layanan hanya boleh mengakses sumber daya yang diperlukan.

Rekomendasi autentikasi:

• Gunakan federasi identitas beban kerja daripada perwakilan layanan untuk koneksi layanan Azure Anda sebisa mungkin.
• Federasi identitas beban kerja menggunakan Open ID Connect (OIDC), teknologi standar industri, untuk memfasilitasi autentikasi antara Azure dan Azure DevOps tanpa mengandalkan rahasia.

Cakupan rekomendasi:

• Batasi koneksi layanan Azure Anda untuk mengakses hanya sumber daya yang diperlukan.
• Hindari memberikan hak kontributor yang luas untuk seluruh langganan Azure.
• Saat membuat koneksi layanan Azure Resource Manager baru, selalu pilih grup sumber daya tertentu.
• Pastikan grup sumber daya hanya berisi VM atau sumber daya yang diperlukan untuk build.
• Saat mengonfigurasi aplikasi GitHub, berikan akses hanya ke repositori yang ingin Anda bangun.

Melindungi proyek

Di luar sumber daya individual, sangat penting untuk mempertimbangkan grup sumber daya di Azure DevOps. Sumber daya diatur oleh proyek-proyek tim, dan Anda perlu memahami apa yang dapat diakses alur Anda berdasarkan pengaturan dan batasan proyek.

Setiap pekerjaan di alur Anda menerima token akses dengan izin untuk membaca sumber daya terbuka. Dalam beberapa kasus, alur mungkin juga memperbarui sumber daya ini. Model izin ini berarti bahwa meskipun akun pengguna Anda mungkin tidak memiliki akses langsung ke sumber daya, skrip, dan tugas tertentu yang berjalan di alur Anda masih dapat mengaksesnya. Selain itu, model keamanan Azure DevOps memungkinkan akses ke sumber daya ini dari proyek lain dalam organisasi. Jika Anda memutuskan untuk membatasi akses alur ke sumber daya tertentu, keputusan ini berlaku untuk semua alur dalam proyek - alur tertentu tidak dapat diberikan akses secara selektif ke sumber daya terbuka.

Memisahkan proyek

Mengingat sifat sumber daya terbuka, pertimbangkan untuk mengelola setiap produk dan tim dalam proyek terpisah. Dengan demikian, Anda mencegah alur dari satu produk secara tidak sengaja mengakses sumber daya terbuka dari produk lain, sehingga meminimalkan paparan lateral. Tetapi, ketika beberapa tim atau produk berbagi proyek, isolasi granular dari sumber daya mereka menjadi menantang.

Jika organisasi Azure DevOps Anda dibuat sebelum Agustus 2019, eksekusi mungkin masih memiliki akses untuk membuka sumber daya di semua proyek organisasi Anda. Administrator organisasi Anda harus meninjau pengaturan keamanan penting di Azure Pipelines yang memungkinkan isolasi proyek untuk alur.

Anda dapat menemukan pengaturan ini di Pengaturan>organisasi, atau secara langsung: . >

Melindungi repositori

Di repositori kontrol versi, Anda dapat menyimpan kode sumber, file YAML alur, dan skrip dan alat yang diperlukan. Untuk memastikan perubahan yang aman pada kode dan alur, sangat penting untuk menerapkan izin dan kebijakan cabang. Selain itu, pertimbangkan untuk menambahkan izin alur dan pemeriksaan ke repositori.

Selain itu, tinjau pengaturan kontrol akses default untuk repositori Anda.

Perlu diingat bahwa desain Git berarti bahwa perlindungan tingkat cabang memiliki batasan. Pengguna dengan akses dorong ke repositori biasanya dapat membuat cabang baru. Jika Anda bekerja dengan proyek sumber terbuka GitHub, siapa pun dengan akun GitHub dapat membuat fork repositori Anda dan mengusulkan kontribusi. Karena alur dikaitkan dengan repositori (bukan cabang tertentu), penting untuk memperlakukan kode dan file YAML sebagai kemungkinan tidak tepercaya.

Fork

Ketika Anda bekerja dengan repositori publik dari GitHub, pertimbangkan dengan cermat pendekatan Anda terhadap build fork. Fork yang berasal dari luar organisasi Anda menimbulkan risiko tertentu. Untuk melindungi produk Anda dari kode yang berkontribusi yang berpotensi tidak tepercaya, ikuti rekomendasi ini.

Catatan

Rekomendasi ini terutama berlaku untuk membangun repositori publik dari GitHub.

Jangan berikan rahasia ke build fork

Secara default, alur Anda membangun fork, tetapi tidak secara otomatis mengekspos rahasia dan sumber daya yang dilindungi ke pekerjaan di alur tersebut. Jangan nonaktifkan perlindungan ini untuk menjaga keamanan.

Catatan

Saat Anda mengaktifkan build fork untuk mengakses rahasia, Azure Pipelines membatasi token akses yang digunakan secara default. Token ini memiliki akses terbatas ke sumber daya terbuka dibandingkan dengan token akses reguler. Untuk memberikan build fork izin yang sama dengan build reguler, aktifkan buat build fork memiliki izin yang sama dengan pengaturan build reguler.

Pertimbangkan untuk memicu build fork secara manual

Nonaktifkan build fork otomatis dan sebagai gantinya gunakan komentar permintaan pull sebagai cara untuk membangun kontribusi ini secara manual. Pengaturan ini memberi Anda kesempatan untuk meninjau kode sebelum memicu build.

Menggunakan agen yang dihosting Microsoft untuk build fork

Hindari menjalankan build dari fork pada agen yang dihost sendiri. Jika Anda menggunakan agen yang dihost sendiri, organisasi eksternal dapat menjalankan kode eksternal pada komputer dalam jaringan perusahaan Anda. Jika memungkinkan, gunakan agen yang dihosting Microsoft. Untuk agen yang dihost sendiri, terapkan isolasi jaringan dan pastikan bahwa agen tidak mempertahankan statusnya di antara pekerjaan.

Meninjau perubahan kode

Sebelum Anda menjalankan pipeline Anda pada permintaan tarik fork, dengan cermat tinjau perubahan yang diusulkan dan pastikan Anda merasa nyaman untuk menjalankannya.

Versi alur YAML yang Anda jalankan adalah versi dari permintaan pull. Beri perhatian khusus pada perubahan pada kode YAML dan kode yang berjalan saat alur berjalan, seperti skrip baris perintah atau pengujian unit.

Batasan cakupan token GitHub

Saat Anda membuat permintaan pull fork GitHub, Azure Pipelines memastikan alur tidak dapat mengubah konten repositori GitHub apa pun. Pembatasan ini hanya berlaku jika Anda menggunakan aplikasi Azure Pipelines GitHub untuk berintegrasi dengan GitHub. Jika Anda menggunakan bentuk integrasi GitHub lainnya, seperti aplikasi OAuth, pembatasan tidak diberlakukan.

Cabang pengguna

Pengguna di organisasi Anda dengan izin yang tepat dapat membuat cabang baru yang berisi kode baru atau yang diperbarui. Kode ini dapat berjalan melalui alur yang sama dengan cabang yang dilindungi Anda. Jika file YAML di cabang baru diubah, YAML yang sudah diperbarui menjalankan pipeline. Meskipun desain ini menawarkan fleksibilitas dan layanan mandiri yang luar biasa, tidak semua perubahan aman (baik dibuat dengan berbahaya atau tidak).

Jika alur Anda menggunakan kode sumber atau ditentukan di Azure Repos, Anda harus sepenuhnya memahami model izin Azure Repos. Secara khusus, pengguna dengan izin Buat Cabang di tingkat repositori dapat memperkenalkan kode ke repositori bahkan jika pengguna tersebut tidak memiliki izin Kontribusi .

Pertimbangan keamanan lainnya

Pertimbangkan aspek keamanan berikut saat mengamankan alur.

Mengandalkan PATH

Mengandalkan pengaturan agen PATH berbahaya. Ini mungkin tidak menunjuk di mana Anda berpikir itu, karena skrip atau alat sebelumnya berpotensi mengubahnya. Untuk skrip dan biner penting keamanan, selalu gunakan jalur yang sepenuhnya memenuhi syarat untuk program.

Rahasia log

Azure Pipelines mencoba menghapus rahasia dari log sedapat mungkin. Pemfilteran ini berdasarkan upaya terbaik dan tidak dapat menangkap setiap cara rahasia dapat bocor. Hindari menggemakan rahasia ke konsol, menggunakannya dalam parameter baris perintah, atau mencatatnya ke file.

Mengunci kontainer

Kontainer memiliki beberapa pemetaan pemasangan volume yang disediakan sistem dalam tugas, ruang kerja, dan komponen eksternal yang diperlukan untuk berkomunikasi dengan agen host. Anda dapat menandai salah satu atau semua volume ini sebagai baca-saja.

resources:
  containers:
  - container: example
    image: ubuntu:22.04
    mountReadOnly:
      externals: true
      tasks: true
      tools: true
      work: false  # the default; shown here for completeness

Biasanya, sebagian besar orang menetapkan tiga direktori pertama sebagai baca-saja dan meninggalkan work sebagai baca-tulis. Jika Anda tidak menulis ke work direktori dalam pekerjaan atau langkah tertentu, jangan ragu untuk membuat work baca-saja juga. Tetapi, jika tugas alur Anda melibatkan modifikasi mandiri, Anda mungkin perlu tetap tasks sebagai baca-tulis.

Mengontrol tugas yang tersedia

Anda dapat menonaktifkan kemampuan untuk menginstal dan menjalankan tugas dari Marketplace. Pendekatan ini memberi Anda kontrol yang lebih besar atas kode yang berjalan dalam alur. Anda mungkin juga menonaktifkan semua tugas bawaan, kecuali untuk tugas Checkout, yang merupakan tindakan khusus pada agen tersebut. Jangan nonaktifkan tugas dalam kotak dalam sebagian besar keadaan.

Tugas yang Anda instal secara langsung dengan menggunakan tfx selalu tersedia. Saat Anda mengaktifkan kedua fitur ini, hanya tugas-tugas tersebut saja yang tersedia.

Menggunakan layanan Audit

Layanan Audit mencatat banyak peristiwa pipa. Tinjau log audit secara berkala untuk memastikan tidak ada perubahan berbahaya yang tergelincir di masa lalu. Untuk memulai, kunjungi https://dev.azure.com/ORG-NAME/_settings/audit.

Langkah berikutnya

Tinjau gambaran umum keamanan