Praktik terbaik keamanan

  • Artikel

Layanan Azure DevOps | Azure DevOps Server 2022 - Azure DevOps Server 2019

Saat Anda bekerja dengan informasi dan data, terutama dalam solusi berbasis cloud seperti Azure DevOps Services, memprioritaskan keamanan harus selalu menjadi perhatian utama Anda. Meskipun Microsoft mempertahankan keamanan infrastruktur cloud yang mendasar, Anda bertanggung jawab untuk mengonfigurasi keamanan di Azure DevOps.

Meskipun tidak wajib, menggabungkan praktik terbaik saat menggunakan Azure DevOps dapat meningkatkan pengalaman Anda dan membuatnya lebih aman. Kami telah mengkompilasi praktik terbaik berikut yang bertujuan untuk menjaga lingkungan Azure DevOps Anda tetap aman:

Lingkungan Azure DevOps yang aman

Menghapus pengguna

  • Jika organisasi Anda menggunakan akun MSA, hapus pengguna yang tidak aktif langsung dari organisasi, karena Anda tidak memiliki cara lain untuk mencegah akses. Saat melakukannya, Anda tidak dapat membuat kueri untuk item kerja yang ditetapkan ke akun pengguna yang dihapus. Untuk informasi selengkapnya, lihat Menghapus pengguna dari Azure DevOps.
  • Jika organisasi Anda tersambung ke ID Microsoft Entra, maka Anda dapat menonaktifkan atau menghapus akun pengguna Microsoft Entra dan membiarkan akun pengguna Azure DevOps Anda aktif. Dengan cara ini, Anda dapat terus mengkueri riwayat item kerja menggunakan ID pengguna Azure DevOps Anda.
  • Mencabut PAT pengguna.
  • Cabut izin khusus apa pun yang mungkin telah diberikan ke akun pengguna individual.
  • Menetapkan ulang pekerjaan dari pengguna yang Anda hapus ke anggota tim saat ini.

Menggunakan ID Microsoft Entra

Integrasikan Azure DevOps dengan MICROSOFT Entra ID untuk memiliki satu bidang untuk identitas. Konsistensi dan satu sumber otoritatif meningkatkan kejelasan dan mengurangi risiko keamanan dari kesalahan manusia dan kompleksitas konfigurasi. Kunci untuk tata kelola akhir adalah memiliki beberapa penetapan peran (dengan definisi peran yang berbeda dan cakupan sumber daya yang berbeda ke grup Microsoft Entra yang sama). Tanpa ID Microsoft Entra, Anda bertanggung jawab penuh untuk mengontrol akses organisasi.

Menggunakan MICROSOFT Entra ID juga memungkinkan Anda mengakses fitur keamanan lain, seperti autentikasi multifaktor atau kebijakan akses bersyar lainnya.

Untuk informasi lebih lanjut, baca artikel berikut:

Meninjau peristiwa audit

Setelah memiliki organisasi yang didukung Microsoft Entra, Anda dapat mengaktifkan Audit dalam kebijakan Keamanan Anda. Tinjau peristiwa audit secara berkala untuk memantau dan bereaksi terhadap pola penggunaan yang tidak terduga oleh administrator dan pengguna lain.

Mengamankan jaringan Anda

Beberapa cara untuk melakukannya mungkin termasuk:

  • Siapkan daftar yang diizinkan untuk membatasi IP tertentu.
  • Selalu gunakan enkripsi.
  • Memvalidasi sertifikat.
  • Terapkan firewall aplikasi Web (WAF), sehingga mereka dapat memfilter, memantau, dan memblokir lalu lintas berbasis web berbahaya ke dan dari Azure DevOps.
  • Untuk informasi selengkapnya, lihat panduan ini tentang praktik terbaik manajemen aplikasi

Izin terlingkup

Sistem mengelola izin pada tingkat yang berbeda - individu, koleksi, proyek, dan objek - dan menetapkannya ke satu atau beberapa grup bawaan secara default.

Izin tingkat proyek

  • Batasi akses ke proyek dan repositori untuk mengurangi risiko kebocoran informasi sensitif dan menyebarkan kode yang tidak aman ke produksi.
  • Gunakan grup keamanan bawaan atau grup keamanan kustom untuk mengelola izin. Untuk informasi selengkapnya, lihat Memberikan atau membatasi izin untuk memilih tugas.
  • Nonaktifkan "Izinkan proyek publik" di pengaturan kebijakan organisasi Anda untuk mencegah setiap pengguna organisasi membuat proyek publik. Layanan Azure DevOps memungkinkan Anda mengubah visibilitas proyek Anda dari publik ke privat, dan sebaliknya. Jika pengguna belum masuk ke organisasi Anda, mereka memiliki akses baca-saja ke proyek publik Anda. Jika pengguna telah masuk, mereka dapat diberikan akses ke proyek privat dan membuat perubahan yang diizinkan kepada mereka.
  • Jangan izinkan pengguna untuk membuat proyek baru.

Akses tamu eksternal

  • Blokir akses tamu eksternal sepenuhnya dengan menonaktifkan kebijakan "Izinkan undangan dikirim ke domain apa pun". Ada baiknya melakukannya jika tidak ada kebutuhan bisnis untuk itu.
  • Gunakan email atau nama prinsipal pengguna (UPN) yang berbeda untuk akun pribadi dan bisnis Anda, meskipun diizinkan. Tindakan ini menghilangkan tantangan pembedaan antara akun bisnis dan pribadi Anda ketika email/UPN sama.
  • Letakkan semua pengguna tamu eksternal dalam satu grup Microsoft Entra dan kelola izin grup tersebut dengan tepat. Anda dapat dengan mudah mengelola dan mengaudit dengan cara ini.
    • Hapus penetapan langsung sehingga aturan grup berlaku untuk pengguna tersebut. Untuk informasi selengkapnya, lihat Menambahkan aturan grup untuk menetapkan tingkat akses.
    • Mengevaluasi ulang aturan secara teratur pada tab Aturan grup di halaman Pengguna. Klarifikasi apakah ada perubahan keanggotaan grup di ID Microsoft Entra dapat memengaruhi organisasi Anda. ID Microsoft Entra dapat memakan waktu hingga 24 jam untuk memperbarui keanggotaan grup dinamis. Setiap 24 jam dan kapan saja aturan grup berubah, aturan akan dievaluasi ulang secara otomatis dalam sistem.
  • Untuk informasi selengkapnya, lihat Tamu B2B di ID Microsoft Entra.

Mengelola grup keamanan

Grup keamanan dan pengguna

Lihat rekomendasi berikut untuk menetapkan izin ke grup keamanan dan grup pengguna.

Lakukan Jangan
Gunakan ID Microsoft Entra, Direktori Aktif, atau grup keamanan Windows saat Anda mengelola banyak pengguna. Jangan ubah izin default untuk grup Pengguna Valid Proyek. Grup ini dapat mengakses dan melihat informasi proyek.
Saat Anda menambahkan tim, pertimbangkan izin apa yang ingin Anda tetapkan kepada anggota tim yang perlu membuat dan memodifikasi jalur area, jalur perulangan, dan kueri. Jangan tambahkan pengguna ke beberapa grup keamanan yang berisi tingkat izin yang berbeda. Dalam kasus tertentu, tingkat izin Tolak dapat mengambil alih tingkat izin Izinkan .
Saat Anda menambahkan banyak tim, pertimbangkan untuk membuat grup kustom Administrator Tim tempat Anda mengalokasikan subset izin yang tersedia untuk Administrator Proyek. Jangan ubah penetapan default yang dibuat ke grup Pengguna Valid Proyek. Jika Anda menghapus atau mengatur Tampilkan informasi tingkat instans ke Tolak untuk salah satu grup Pengguna Valid Proyek, tidak ada pengguna dalam grup yang dapat mengakses proyek, koleksi, atau penyebaran apa pun yang Anda tetapkan izinnya.
Pertimbangkan untuk memberikan izin Kontribusi folder kueri item kerja kepada pengguna atau grup yang memerlukan kemampuan untuk membuat dan berbagi kueri item kerja untuk proyek. Jangan tetapkan izin yang dicatat sebagai Tetapkan hanya ke akun layanan ke akun pengguna.
Jaga grup sekecil mungkin. Akses harus dibatasi, dan grup harus sering diaudit.
Manfaatkan peran bawaan dan default ke Kontributor untuk pengembang. Admin ditetapkan ke kelompok keamanan Administrator Proyek untuk izin yang lebih tinggi, yang memungkinkannya mengonfigurasi izin keamanan.

Untuk informasi selengkapnya, lihat Grup pengguna yang valid.

Akses just-in-time untuk grup admin

Anda dapat mengubah konfigurasi organisasi atau proyek jika Anda memiliki akses Administrator Koleksi Proyek dan Administrator Proyek. Untuk melindungi akses ke grup administrator bawaan ini, perlu akses just-in-time menggunakan grup Microsoft Entra Privileged Identity Management (PIM).

Mengonfigurasi akses

  1. Buat grup yang dapat ditetapkan peran di ID Microsoft Entra.
  2. Tambahkan grup Microsoft Entra Anda ke grup Azure DevOps.

Catatan

Pastikan setiap pengguna dengan akses yang ditingkatkan menggunakan grup PIM juga memiliki akses standar ke organisasi, sehingga mereka dapat melihat halaman untuk me-refresh izin mereka.

Menggunakan akses

  1. Aktifkan akses Anda.
  2. Refresh izin Anda di Azure DevOps.
  3. Ambil tindakan yang memerlukan akses administrator.

Catatan

Pengguna telah meningkatkan akses di Azure DevOps hingga 1 jam setelah akses grup PIM mereka dinonaktifkan.

Akun layanan cakupan

  • Pastikan akun layanan tidak memiliki hak masuk interaktif.
  • Batasi hak istimewa akun layanan hingga minimum yang diperlukan.
  • Gunakan identitas yang berbeda untuk akun pembaca laporan, jika Anda menggunakan akun domain untuk akun layanan Anda. Untuk informasi selengkapnya, lihat Akun layanan dan dependensi.
  • Gunakan akun lokal untuk akun pengguna, jika Anda menginstal komponen dalam grup kerja. Untuk informasi selengkapnya, lihat Persyaratan akun layanan.
  • Gunakan koneksi layanan jika memungkinkan. Koneksi layanan menyediakan mekanisme yang aman untuk terhubung ke berbagai layanan tanpa perlu meneruskan variabel rahasia ke build secara langsung. - Batasi koneksi ini ke tempat tertentu yang harus digunakan dan tidak lebih.
  • Pantau aktivitas akun layanan dan buat streaming audit. Audit memungkinkan Anda mendeteksi dan bereaksi terhadap proses masuk dan aktivitas yang mencurigakan.
  • Untuk informasi selengkapnya, lihat Jenis koneksi layanan umum.

Koneksi layanan cakupan

  • Cakupan Azure Resource Manager, dan koneksi layanan lainnya, hanya ke sumber daya dan grup yang mereka butuhkan aksesnya. Koneksi layanan tidak boleh memiliki hak kontributor yang luas pada seluruh langganan Azure.
  • Gunakan federasi identitas beban kerja untuk koneksi layanan Azure Resource Manager (ARM) Anda. Federasi identitas beban kerja memungkinkan Anda membuat koneksi layanan bebas rahasia di Azure Pipelines ke Azure.
  • Jangan memberi pengguna hak kontributor umum atau luas pada langganan Azure.
  • Jangan gunakan koneksi layanan Azure Classic, karena tidak ada cara untuk mencakup izin.
  • Pastikan grup sumber daya hanya berisi Virtual Machines (VM) atau sumber daya yang perlu diakses build.
  • Gunakan akun layanan tim khusus tujuan untuk mengautentikasi koneksi layanan.
  • Untuk informasi selengkapnya, lihat Jenis koneksi layanan umum.

Memilih cara autentikasi yang tepat

Pilih metode autentikasi Anda dari sumber berikut:

Pertimbangkan perwakilan layanan

Jelajahi alternatif seperti perwakilan layanan dan identitas terkelola yang memungkinkan Anda menggunakan token Microsoft Entra untuk mengakses sumber daya Azure DevOps. Token tersebut membawa lebih sedikit risiko ketika bocor dibandingkan dengan PATs dan mengandung manfaat seperti manajemen kredensial yang mudah.

Gunakan PAT dengan hemat

Jika memungkinkan, sebaiknya selalu gunakan layanan identitas untuk autentikasi alih-alih kunci kriptografi karena mengelola kunci dengan aman dengan kode aplikasi sangat menantang dan dapat menyebabkan kesalahan seperti secara tidak sengaja menerbitkan kunci akses sensitif ke repositori kode publik seperti GitHub. Namun, jika Anda harus menggunakan token akses pribadi (PATs), pertimbangkan panduan berikut:

  • PATS harus selalu dilingkup ke peran tertentu.

  • PATS tidak boleh menyediakan akses global ke beberapa organisasi.

  • PAT tidak boleh memberikan izin tulis atau kelola pada build atau rilis.

  • PATS harus memiliki tanggal kedaluwarsa dan dirahasiakan karena sama pentingnya dengan kata sandi.

  • PATS tidak boleh dikodekan secara permanen dalam kode aplikasi, bahkan jika menggoda untuk melakukannya untuk menyederhanakan kode.

  • Administrator harus mengaudit semua PAT secara teratur menggunakan REST API dan mencabut apa pun yang tidak memenuhi kriteria di atas.

  • Rahasiakan PAT Anda. Token Anda sama pentingnya dengan kata sandi.

  • Simpan token Anda di tempat yang aman.

  • Jangan token kode keras dalam aplikasi. Mungkin menggoda untuk menyederhanakan kode untuk mendapatkan token untuk jangka waktu yang lama dan menyimpannya di aplikasi Anda, tetapi jangan lakukan itu.

  • Berikan token tanggal kedaluwarsa.

  • Untuk informasi selengkapnya, lihat artikel berikut ini:

Amankan Artefak Azure

  • Pastikan Anda memahami perbedaan antara admin pengumpulan umpan, proyek, dan proyek. Untuk informasi selengkapnya, lihat Mengonfigurasi pengaturan Azure Artifacts.
  • Untuk informasi selengkapnya, lihat Mengatur izin umpan.

Mengamankan Azure Boards

Amankan Azure Pipelines

Kebijakan

  • Memerlukan setidaknya satu peninjau di luar pemohon asli. Pemberi persetujuan berbagi koownership atas perubahan dan harus bertanggung jawab sama untuk setiap dampak potensial.
  • Memerlukan CI build untuk lulus. Persyaratan ini berguna untuk menetapkan kualitas kode dasar, melalui kode linting, pengujian unit, dan pemeriksaan keamanan, seperti pemindaian virus dan kredensial.
  • Pastikan bahwa pemohon pull asli tidak dapat menyetujui perubahan.
  • Larang penyelesaian PR (Permintaan Pull), bahkan jika beberapa peninjau memilih untuk menunggu atau menolak.
  • Reset suara peninjau kode saat perubahan terbaru didorong.
  • Kunci alur rilis dengan menjalankannya hanya pada cabang produksi tertentu.
  • Aktifkan "Terapkan yang dapat diatur pada waktu antrean untuk variabel" di pengaturan alur organisasi Anda.
  • Jangan izinkan "Izinkan pengguna mengambil alih nilai ini saat menjalankan alur ini", untuk variabel yang diatur di editor.

Agen

  • Berikan izin ke jumlah akun sekecil mungkin.
  • Memiliki firewall paling ketat yang membuat agen Anda dapat digunakan.
  • Perbarui kumpulan secara teratur untuk memastikan armada build tidak menjalankan kode rentan yang dapat dieksploitasi oleh aktor jahat.
  • Gunakan kumpulan agen terpisah untuk membangun artefak yang dikirim atau disebarkan ke produksi.
  • Segmentasi kumpulan "sensitif" dari kumpulan yang tidak sensitif, dan hanya mengizinkan penggunaan kredensial dalam definisi build yang dikunci ke kumpulan tersebut.

Definisi

  • Mengelola definisi alur dengan YAML (Namun Bahasa Markup Lain). YAML adalah metode yang lebih disukai untuk mengelola definisi alur, karena memberikan keterlacakan untuk perubahan dan dapat mengikuti pedoman persetujuan.
  • Amankan definisi alur Edit akses ke jumlah minimum akun.

Input

  • Sertakan pemeriksaan kewarasan untuk variabel dalam skrip build. Pemeriksaan kewarasan dapat mengurangi serangan injeksi perintah melalui variabel yang dapat diatur.
  • Atur variabel build sesegera mungkin ke "Dapat diatur pada waktu rilis."

Tugas

  • Hindari sumber daya yang diambil dari jarak jauh, tetapi, jika perlu, gunakan penerapan versi dan pemeriksaan hash.
  • Jangan mencatat rahasia.
  • Jangan simpan rahasia dalam variabel alur, gunakan Azure Key Vault. Pindai alur build Anda secara teratur untuk memastikan rahasia tidak disimpan dalam variabel alur build.
  • Jangan biarkan pengguna menjalankan build terhadap cabang atau tag arbitrer pada alur penting keamanan.
  • Nonaktifkan pewarisan pada alur, karena izin yang diwariskan luas dan tidak mencerminkan kebutuhan Anda untuk izin secara akurat.
  • Batasi cakupan otorisasi pekerjaan dalam semua kasus.

Repositori dan cabang

  • Atur kebijakan "Memerlukan jumlah minimum peninjau", agar setiap permintaan pull ditinjau oleh setidaknya dua pemberi persetujuan.
  • Konfigurasikan kebijakan keamanan khusus untuk setiap repositori atau cabang, alih-alih luas proyek. Kebijakan keamanan mengurangi risiko, menerapkan standar manajemen perubahan, dan meningkatkan kualitas kode tim Anda.
  • Simpan rahasia produksi di Key Vault terpisah dan pastikan bahwa akses hanya diberikan berdasarkan yang perlu diketahui untuk menjaga build nonproduksi tetap terpisah.
  • Jangan mencampur lingkungan pengujian dengan produksi, termasuk penggunaan kredensial.
  • Nonaktifkan forking. Semakin banyak fork yang ada, semakin sulit untuk melacak keamanan setiap fork. Selain itu, pengguna dapat dengan mudah membuat salinan repositori ke akun privat mereka sendiri.
  • Jangan berikan rahasia ke build fork.
  • Pertimbangkan untuk memicu build fork secara manual.
  • Gunakan agen yang dihosting Microsoft untuk build fork.
  • Untuk Git, periksa definisi build produksi Anda di repositori git proyek, sehingga dapat dipindai untuk kredensial.
  • Konfigurasikan pemeriksaan kontrol cabang sehingga hanya alur yang berjalan dalam konteks cabang yang production dapat menggunakan prod-connection.
  • Untuk informasi selengkapnya, lihat Pertimbangan keamanan lainnya.

Amankan Azure Repos

Paket Pengujian Azure yang Aman

Integrasi GitHub yang Aman

  • Nonaktifkan autentikasi berbasis Token Akses Pribadi (PAT), sehingga alur OAuth digunakan dengan koneksi layanan GitHub.
  • Jangan pernah mengautentikasi koneksi layanan GitHub sebagai identitas yang merupakan administrator atau pemilik repositori apa pun.
  • Jangan pernah menggunakan GitHub PAT lingkup penuh (Token Akses Pribadi) untuk mengautentikasi koneksi layanan GitHub.
  • Jangan gunakan akun GitHub pribadi sebagai koneksi layanan dengan Azure DevOps.