Ringkasan perlindungan data
Azure DevOps
Azure DevOps Services adalah aplikasi yang dihosting cloud untuk proyek pengembangan Anda, dari perencanaan melalui penyebaran. Berdasarkan kemampuan lokal, dengan lebih banyak layanan cloud, kami mengelola kode sumber, item kerja, build, dan pengujian Anda. Azure DevOps menggunakan infrastruktur platform as a service (PaaS) dan banyak layanan Azure, termasuk Azure SQL, untuk memberikan layanan yang andal dan tersedia secara global untuk proyek pengembangan Anda.
Artikel ini membahas langkah-langkah yang diambil Microsoft untuk membantu menjaga proyek Anda tetap aman, tersedia, aman, dan privat. Ini menjelaskan peran yang Anda mainkan dalam menjaga proyek Anda tetap aman dan aman.
Artikel ini untuk administrator organisasi dan profesional TI yang mengelola aset proyek mereka setiap hari. Ini paling berguna bagi individu yang sudah terbiasa dengan Azure DevOps dan ingin tahu lebih banyak tentang bagaimana Microsoft melindungi aset yang disimpan di Azure DevOps.
Komitmen kami
Microsoft membantu memastikan bahwa proyek Anda tetap aman dan aman, tanpa terkecuali. Saat Anda menyimpan proyek di Azure DevOps, proyek tersebut mendapat manfaat dari beberapa lapisan teknologi keamanan dan tata kelola, praktik operasional, dan kebijakan kepatuhan. Kami memberlakukan privasi dan integritas data baik saat tidak aktif maupun saat transit.
Ancaman yang Anda hadapi berada dalam empat kategori dasar: ketersediaan data, ketersediaan layanan, keamanan layanan, dan privasi data. Artikel ini mengeksplorasi ancaman tertentu dalam setiap kategori dan menjelaskan apa yang dilakukan Azure DevOps untuk mengatasinya. Artikel ini dimulai dengan menjelaskan bagaimana data disimpan dan bagaimana Azure DevOps mengelola akses ke data Anda.
Perlindungan data memerlukan keterlibatan aktif administrator dan pengguna yang mengetahui langkah-langkah apa yang harus diambil untuk melindungi aset Anda dari pengungkapan dan perusakan yang tidak sah. Jadilah eksplisit saat Anda memberikan izin ke titik akses pengguna, jadi hanya orang yang tepat yang mengakses data dalam Azure DevOps.
Anda harus mempertimbangkan semua data berpotensi berisiko, di mana pun data tersebut berada atau bagaimana data tersebut digunakan. Pernyataan ini berlaku untuk data yang disimpan di cloud dan data yang disimpan di pusat data privat. Penting untuk mengklasifikasikan data Anda, sensitivitas dan risikonya, dan kerusakan yang mungkin dilakukan jika data tersebut disusupi. Selain itu, kategorikan data Anda relatif terhadap kebijakan keseluruhan untuk mengelola keamanan informasi.
Dibangun di Azure
Kami menghosting Azure DevOps sepenuhnya di pusat data Azure. Azure DevOps menggunakan banyak layanan Azure inti, termasuk komputasi, penyimpanan, jaringan, Azure SQL, manajemen identitas dan akses, dan Azure Bus Layanan.
Azure DevOps menggunakan Azure Storage sebagai repositori utama untuk metadata layanan dan data pelanggan. Bergantung pada jenis data dan persyaratan penyimpanan dan pengambilan, Azure DevOps menggunakan Penyimpanan Azure Blob dan penyimpanan Azure SQL Database.
Untuk membantu Anda memahami pendekatan Azure DevOps Services untuk perlindungan data, berikut adalah beberapa latar belakang pada layanan penyimpanan:
Azure Blob Storage menyimpan potongan besar data yang tidak terstruktur. Semua proyek menggunakan layanan ini. Data mencakup informasi yang bisa jadi bersifat sensitif atau privat, seperti konten file sumber dan lampiran untuk item kerja. Untuk sebagian besar proyek, sebagian besar penyimpanan yang digunakan adalah jenis penyimpanan blob yang tidak terstruktur ini.
Azure SQL Database menyimpan aspek terstruktur dan transaksional organisasi Anda, termasuk metadata proyek, riwayat kontrol sumber versi, dan detail item kerja. Penyimpanan database memberi Anda akses cepat ke elemen penting proyek Anda. Ini menyediakan indeks ke dalam penyimpanan blob untuk mencari file dan lampiran.
Administrator dapat mengelola akses ke sumber daya dengan memberikan atau membatasi izin pada identitas atau grup pengguna. Azure DevOps menggunakan autentikasi federasi identitas pengguna melalui ID Microsoft Entra dan akun Microsoft.
Selama autentikasi, pengguna dirutekan ke penyedia autentikasi, tempat mereka memberikan kredensial mereka. Setelah penyedia autentikasi memverifikasi kredensial pengguna, Azure DevOps mengeluarkan cookie autentikasi kepada pengguna. Cookie ini memungkinkan pengguna untuk tetap diautentikasi terhadap Azure DevOps.
Dengan cara ini, informasi kredensial pengguna tidak pernah dibagikan langsung dengan Azure DevOps. Untuk setiap sumber daya Azure DevOps yang coba diakses pengguna, validasi izin didasarkan pada izin eksplisit pengguna dan izin yang diwarisi pengguna melalui keanggotaan grup.
Administrator dapat menggunakan kontrol akses untuk membantu melindungi akses ke organisasi, koleksi proyek, proyek tim, dan data dan fungsionalitas yang tercakup dalam tim. Administrator juga dapat menggunakan kontrol akses untuk aset tertentu seperti folder untuk kontrol versi dan jalur area untuk item kerja.
Ketersediaan data
Azure DevOps menggunakan banyak fitur Azure Storage untuk membantu memastikan ketersediaan data jika ada kegagalan perangkat keras, gangguan layanan, atau bencana regional. Selain itu, tim Azure DevOps mengikuti prosedur untuk membantu melindungi data dari penghapusan yang tidak disengaja atau berbahaya.
Redundansi data
Untuk membantu melindungi data selama kegagalan perangkat keras atau layanan, Azure Storage mereplikasi data pelanggan antara dua wilayah di lokasi geografis yang sama. Misalnya, Azure Storage dapat mereplikasi data secara geografis antara Eropa Utara dan Barat atau antara Amerika Serikat Utara dan Selatan.
Untuk Azure Blob Storage, data pelanggan direplikasi tiga kali dalam satu wilayah. Data pelanggan direplikasi secara asinkron ke wilayah kedua di lokasi geografis yang sama. Dengan demikian, Azure selalu mempertahankan setara dengan enam salinan data Anda.
Memiliki beberapa salinan memungkinkan Anda untuk melakukan failover ke wilayah terpisah jika ada pemadaman atau bencana besar, sekaligus memiliki redundansi lokal untuk kegagalan perangkat keras dalam suatu wilayah. Untuk penyimpanan Azure SQL Database, pencadangan harian dipertahankan di luar lokasi jika ada bencana regional.
Mengenai redundansi dan failover data:
- Ada delta yang melekat, diukur dalam hitungan menit, saat Microsoft mereplikasi data Anda antara wilayah utama dan sekunder.
- Failover ke wilayah sekunder adalah keputusan yang harus dibuat Microsoft secara terpusat, karena memengaruhi semua pelanggan pada unit skala tertentu. Kecuali dalam keadaan ekstrem, Microsoft memilih untuk menghindari failover sehingga data pelanggan tidak hilang.
- Azure DevOps menawarkan perjanjian tingkat layanan (SLA) 99,9 persen waktu aktif. Azure DevOps mengembalikan sebagian biaya bulanan jika melewatkan SLA tersebut pada bulan tertentu.
- Karena hanya ada satu wilayah di Brasil, data pelanggan di Brasil direplikasi ke wilayah AS Tengah Selatan untuk tujuan pemulihan bencana.
Kesalahan terjadi
Untuk melindungi dari kehilangan data yang tidak disengaja, Microsoft menggunakan cadangan point-in-time untuk kedua blob yang disimpan di Azure Blob Storage dan database dalam Azure SQL Database. Setiap akun penyimpanan mempertahankan salinan terpisah dari semua blob, dengan perubahan ditambahkan ke data yang ada. Cadangan ini tidak dapat diubah, menghilangkan kebutuhan untuk menulis ulang penyimpanan yang ada selama prosedur pencadangan.
Azure SQL Database menyertakan fitur cadangan standar yang digunakan oleh Azure DevOps. Data Anda disimpan selama 28 hari, dengan cadangan ini juga direplikasi di wilayah berpasangan untuk memfasilitasi pemulihan selama pemadaman regional.
Anda dapat memulihkan organisasi atau proyek yang dihapus dalam jendela 28 hari setelah penghapusan. Tetapi, setelah periode waktu ini berlalu, entitas ini dihapus secara permanen dan tidak dapat dipulihkan. Meskipun pencadangan ini berfungsi sebagai komponen penting untuk pemulihan bencana, sangat penting bagi pelanggan untuk mempraktikkan strategi manajemen data dan cadangan yang sesuai untuk memastikan perlindungan komprehensif data mereka.
Penting
- Penghapusan yang tidak disengaja di sini mengacu pada skenario yang muncul sebagai akibat dari insiden pada layanan kami. Ini tidak termasuk penghapusan aset yang tidak disengaja pelanggan (misalnya, repositori, item kerja, lampiran, atau artefak).
- Kami tidak mendukung pemulihan aset yang dihapus pelanggan secara tidak sengaja. Pencadangan ini dimaksudkan hanya untuk kelangsungan bisnis dan untuk membantu pemulihan dari pemadaman atau skenario bencana.
- Dalam kasus yang jarang terjadi, proses penghapusan kami mungkin memakan waktu hingga 70 hari karena percobaan ulang backend dan kebutuhan untuk menghapus data dari beberapa sumber.
Praktik sangat penting
Memiliki beberapa cadangan data Anda baik, tetapi tanpa praktik, pemulihan dapat tidak dapat diprediksi. Orang mengatakan bahwa "cadangan tidak pernah gagal; pemulihannya." Meskipun pernyataannya secara teknis salah, sentimennya benar.
Microsoft secara teratur berlatih memulihkan himpunan data dari cadangan. Kami secara teratur menguji penyimpanan geo-redundan dari Azure. Ada banyak kombinasi skenario bencana dan kerusakan data. Kami terus merencanakan dan menjalankan pengujian baru untuk skenario ini secara teratur.
Ketersediaan layanan
Azure DevOps menawarkan perlindungan penolakan layanan terdistribusi (DDoS) dan respons situs langsung untuk membantu memastikan bahwa Anda memiliki akses ke organisasi dan aset terkait.
Perlindungan DDoS
Dalam beberapa kasus, serangan DDoS berbahaya dapat memengaruhi ketersediaan layanan. Azure memiliki sistem pertahanan DDoS yang membantu mencegah serangan terhadap layanan kami. Ini menggunakan teknik deteksi dan mitigasi standar seperti cookie SYN, pembatasan laju, dan batas koneksi. Sistem ini dirancang untuk menahan serangan tidak hanya dari luar tetapi juga dari dalam Azure.
Untuk serangan khusus aplikasi yang dapat menembus sistem pertahanan Azure, Azure DevOps menetapkan kuota dan pembatasan tingkat aplikasi dan tingkat organisasi. Praktik ini membantu mencegah penggunaan sumber daya layanan utama yang berlebihan selama serangan atau penyalahgunaan sumber daya yang tidak disengaja.
Respons situs langsung
Dalam keadaan yang jarang terjadi, Anda mungkin memerlukan respons situs langsung terhadap masalah dengan ketersediaan layanan. Kami memiliki tim operasi yang terus tersedia untuk mengidentifikasi masalah dengan cepat dan melibatkan sumber daya tim pengembangan yang diperlukan.
Sumber daya tim pengembangan kemudian mengatasi masalah tersebut. Mereka juga bertujuan untuk memperbarui halaman status layanan dalam hitungan menit setelah mendeteksi masalah yang memengaruhi layanan. Setelah sumber daya tim pengembangan mengatasi masalah, mereka mengidentifikasi akar penyebab dan melacak perubahan yang diperlukan untuk mencegah masalah serupa di masa depan.
Proses Azure DevOps untuk manajemen situs langsung berfokus pada pengalaman Anda dan kesehatan layanan. Proses ini meminimalkan waktu untuk mendeteksi, merespons, dan mengurangi masalah. Semua disiplin teknik terlibat dan bertanggung jawab, sehingga peningkatan berkelanjutan berevolusi dari pengalaman langsung. Pemantauan, diagnostik, ketahanan, dan proses jaminan kualitas kemudian meningkat dari waktu ke waktu.
Manajemen situs langsung di Azure DevOps memiliki tiga trek yang berbeda: telemetri, manajemen insiden, dan tinjauan situs langsung. Berikut adalah apa yang memerlukan trek ini:
Tim operasi juga memantau metrik ketersediaan untuk masing-masing organisasi. Metrik ini memberikan wawasan tentang kondisi tertentu yang mungkin hanya memengaruhi beberapa pelanggan kami. Investigasi ke dalam data ini sering kali dapat mengakibatkan peningkatan yang ditargetkan untuk mengatasi masalah khusus pelanggan. Dalam beberapa kasus, Microsoft bahkan mungkin menghubungi Anda secara langsung untuk memahami pengalaman Anda dan bekerja sama dengan Anda untuk meningkatkan layanan.
Microsoft menerbitkan SLA dan memberikan jaminan keuangan untuk memastikan bahwa kami memenuhi perjanjian ini setiap bulan. Untuk informasi selengkapnya, lihat SLA untuk Azure DevOps.
Terkadang, tim mitra atau dependensi memiliki insiden yang memengaruhi Azure DevOps. Semua tim mitra mengikuti pendekatan serupa untuk mengidentifikasi, menyelesaikan, dan belajar dari pemadaman layanan ini.
Keamanan layanan
Keamanan layanan memerlukan kewaspadaan konstan, mulai dari teknik desain dan pengodean yang tepat hingga faktor operasional. Microsoft secara aktif berinvestasi dalam pencegahan lubang keamanan dan dalam deteksi pelanggaran. Jika ada pelanggaran, Microsoft menggunakan rencana respons keamanan untuk meminimalkan kebocoran, kehilangan, atau kerusakan data. Untuk informasi selengkapnya, lihat Tentang keamanan, autentikasi, dan otorisasi.
Keamanan berdasarkan desain
Azure DevOps dirancang agar aman. Azure DevOps menggunakan Siklus Hidup Pengembangan Keamanan Microsoft pada inti proses pengembangannya. Program Jaminan Keamanan Operasional Microsoft memandu prosedur operasi cloud di Azure DevOps.
Tim Azure DevOps memiliki persyaratan pelatihan tahunan untuk semua insinyur dan personel operasi. Tim ini juga mensponsori pertemuan informal yang diselenggarakan oleh insinyur Microsoft. Setelah tim memecahkan masalah yang muncul dalam rapat, tim berbagi pelajaran yang dipelajari dengan tim lain.
Metodologi berikut menentukan persyaratan pelatihan:
- Pemodelan ancaman selama desain layanan
- Mengikuti praktik terbaik untuk desain dan kode
- Memverifikasi keamanan dengan alat dan pengujian standar
- Membatasi akses ke data operasional dan pelanggan
- Peluncuran gating fitur baru melalui proses persetujuan yang kaku
Layanan cloud hanya seaman platform host. Azure DevOps menggunakan PaaS untuk sebagian besar infrastrukturnya. PaaS secara otomatis menyediakan pembaruan rutin untuk kerentanan keamanan yang diketahui.
Komputer virtual yang dihosting di Azure menggunakan infrastruktur sebagai layanan (IaaS), seperti untuk layanan build yang dihosting. Gambar tersebut menerima pembaruan rutin untuk menyertakan patch keamanan terbaru yang tersedia dari Windows Update. Kekakuan pembaruan yang sama berlaku untuk komputer lokal, termasuk mesin yang digunakan untuk penyebaran, pemantauan, dan pelaporan.
Tim Azure DevOps melakukan pengujian penetrasi azure DevOps yang teratur dan berfokus pada keamanan. Pengujian penetrasi mencoba mengeksploitasi layanan produksi langsung dan infrastruktur Azure DevOps dengan menggunakan teknik dan mekanisme yang sama dengan yang digunakan penyerang jahat. Tujuannya adalah untuk mengidentifikasi kerentanan dunia nyata, konfigurasi, kesalahan, atau kesenjangan keamanan lainnya dalam proses yang terkontrol.
Tim meninjau hasil tes ini untuk mengidentifikasi bidang peningkatan lainnya dan untuk meningkatkan kualitas sistem dan pelatihan pencegahan. Anda dapat meninjau hasil pengujian penetrasi Azure DevOps terbaru di Portal Kepercayaan Layanan Microsoft.
Keamanan kredensial
Microsoft berkomitmen untuk memastikan bahwa proyek Anda tetap aman dan aman, tanpa terkecuali. Di Azure DevOps, proyek Anda mendapat manfaat dari beberapa lapisan teknologi keamanan dan tata kelola, praktik operasional, dan kebijakan kepatuhan. Kami memberlakukan privasi dan integritas data baik saat tidak aktif maupun saat transit. Selain itu, kami mematuhi praktik berikut sehubungan dengan kredensial atau rahasia yang disimpan Azure DevOps. Untuk mempelajari selengkapnya tentang cara memilih mekanisme autentikasi yang tepat, lihat Panduan untuk autentikasi.
Penting
Azure DevOps tidak mendukung autentikasi Kredensial Alternatif. Jika Anda masih menggunakan Kredensial Alternatif, kami sangat mendorong Anda untuk beralih ke metode autentikasi yang lebih aman.
Token akses pribadi (PATs)
- Kami menyimpan hash PAT.
- PATs mentah menghasilkan dalam memori di sisi server. 32 byte dihasilkan secara acak melalui RNGCryptoServiceProvider dan dibagikan dengan pemanggil sebagai string yang dikodekan base-32. Nilai ini TIDAK disimpan.
- Hash PAT menghasilkan dalam memori di sisi server sebagai HMACSHA256Hash dari PAT mentah menggunakan kunci penandatanganan simetris 64 byte yang disimpan di brankas kunci kami.
- Hash akan disimpan dalam database kita.
Kunci secure shell (SSH)
- Kami menyimpan hash ID organisasi yang tertutup dan kunci umum SSH.
- Kunci publik mentah disediakan langsung oleh pemanggil melalui SSL.
- Hash SSH menghasilkan dalam memori di sisi server sebagai HMACSHA256Hash dari ID organisasi dan kunci publik mentah menggunakan kunci penandatanganan simetris 64 byte yang disimpan di brankas kunci kami.
- Hash akan disimpan dalam database kita.
Kredensial OAuth (JWT)
- Masalah kredensial OAuth sebagai sepenuhnya menjelaskan token web (JWT) JSON dan tidak disimpan dalam layanan kami.
- Klaim dalam JWTs yang dikeluarkan dan disajikan kepada layanan kami divalidasi menggunakan sertifikat yang disimpan di brankas kunci kami.
Melaporkan kelemahan keamanan
Jika Anda yakin bahwa pengujian penetrasi Anda mengungkapkan potensi kelemahan keamanan yang terkait dengan layanan Azure DevOps, laporkan ke Microsoft dalam waktu 24 jam. Untuk informasi selengkapnya, lihat halaman web Microsoft untuk melaporkan kerentanan keamanan komputer.
Penting
Meskipun Anda tidak perlu memberi tahu Microsoft tentang aktivitas pengujian penetrasi, Anda harus mematuhi Aturan Keterlibatan Pengujian Penetrasi Microsoft.
Program bounty
Azure DevOps berpartisipasi dalam program Microsoft Bug Bounty. Program ini memberi penghargaan kepada peneliti keamanan yang melaporkan masalah kepada kami, dan mendorong lebih banyak orang untuk membantu menjaga Azure DevOps tetap aman. Untuk informasi selengkapnya, lihat Program Bounty Microsoft Azure DevOps.
Membatasi akses
Microsoft mempertahankan kontrol ketat atas siapa yang mendapatkan akses ke lingkungan produksi dan data pelanggan kami. Kami memberikan akses pada tingkat hak istimewa paling sedikit yang diperlukan, dan hanya setelah verifikasi pembenaran pengguna. Jika anggota tim memerlukan akses untuk mengatasi masalah mendesak atau menyebarkan perubahan konfigurasi, mereka harus mengajukan permohonan akses just-in-time ke layanan produksi. Akses dicabut segera setelah situasi diselesaikan.
Kami melacak dan memantau permintaan dan persetujuan akses dalam sistem terpisah. Semua akses ke sistem berkorelasi dengan persetujuan ini. Jika kami mendeteksi akses yang tidak disetujui, kami memperingatkan tim operasi untuk menyelidikinya.
Kami menggunakan autentikasi dua faktor untuk semua akses sistem jarak jauh. Jika nama pengguna dan kata sandi untuk salah satu pengembang atau staf operasi kami dicuri, data tetap dilindungi. Pemeriksaan autentikasi lebih lanjut melalui kartu pintar atau panggilan telepon ke nomor yang disetujui sebelumnya harus terjadi sebelum kami mengizinkan akses jarak jauh ke layanan.
Untuk mengelola dan memelihara layanan, Microsoft menggunakan rahasia seperti kata sandi RDP, sertifikat SSL, dan kunci enkripsi. Rahasia ini semuanya dikelola, disimpan, dan ditransmisikan dengan aman melalui portal Azure. Akses apa pun ke rahasia ini memerlukan izin khusus, yang dicatat dan direkam dengan aman. Semua rahasia diputar pada irama reguler, dan kita dapat memutarnya sesuai permintaan jika ada peristiwa keamanan.
Tim operasi Azure DevOps menggunakan stasiun kerja administrator yang diperkuat untuk mengelola layanan. Mesin-mesin ini menjalankan jumlah aplikasi minimal dan beroperasi di lingkungan tersegmentasi secara logis.
Anggota tim operasi harus memberikan kredensial tertentu dengan autentikasi dua faktor untuk mengakses stasiun kerja. Semua akses dipantau dan dicatat dengan aman. Untuk mengisolasi layanan dari gangguan luar, kami tidak mengizinkan aplikasi seperti Outlook dan Office, karena mereka sering menjadi target pengelabuan tombak dan jenis serangan lainnya.
Perlindungan dan respons intrusi
Kami mengenkripsi data melalui HTTPS dan SSL untuk membantu memastikan bahwa data tersebut tidak disadap atau dimodifikasi saat transit antara Anda dan Azure DevOps. Data yang kami simpan atas nama Anda di Azure DevOps dienkripsi sebagai berikut:
Data yang disimpan dalam database Azure SQL dienkripsi melalui enkripsi data transparan. Fitur ini membantu melindungi dari aktivitas berbahaya dengan melakukan enkripsi database secara real time, pencadangan terkait, dan file log transaksi saat tidak aktif.
Koneksi Azure Blob Storage dienkripsi untuk membantu melindungi data Anda saat transit. Untuk data tidak aktif yang disimpan di Azure Blob Storage, Azure DevOps menggunakan enkripsi sisi layanan.
Tim Azure DevOps menggunakan infrastruktur Azure untuk mencatat dan memantau aspek utama layanan. Pengelogan dan pemantauan membantu memastikan bahwa aktivitas dalam layanan sah, dan membantu mendeteksi pelanggaran atau upaya pelanggaran.
Semua aktivitas penyebaran dan administrator dicatat dengan aman, seperti halnya akses operator ke penyimpanan produksi. Informasi log dianalisis secara otomatis, dan perilaku apa pun yang berpotensi berbahaya atau tidak sah menimbulkan pemberitahuan real time.
Ketika tim Azure DevOps mengidentifikasi kemungkinan gangguan atau kerentanan keamanan berprioritas tinggi, tim tersebut memiliki rencana respons yang jelas. Rencana ini menguraikan pihak yang bertanggung jawab, langkah-langkah yang diperlukan untuk mengamankan data pelanggan, dan instruksi tentang cara terlibat dengan pakar keamanan di Microsoft. Tim juga memberi tahu setiap pemilik organisasi jika data diungkapkan atau rusak, sehingga mereka dapat mengambil langkah-langkah yang tepat untuk memulihkan situasi.
Untuk membantu memerangi ancaman yang muncul, Azure DevOps menggunakan strategi asumsikan pelanggaran . Tim pakar keamanan yang sangat khusus dalam Microsoft mengasumsikan peran adversaries canggih. Tim ini menguji deteksi dan respons pelanggaran, untuk mengukur kesiapan dan dampak serangan dunia nyata secara akurat. Strategi ini memperkuat deteksi ancaman, respons, dan pertahanan layanan. Ini juga memungkinkan tim untuk memvalidasi dan meningkatkan efektivitas seluruh program keamanan.
Perlindungan serangan ransomware
Azure DevOps menggunakan kontrol Azure untuk membantu mencegah, mendeteksi, dan merespons serangan ransomware. Untuk informasi selengkapnya tentang bagaimana Azure membantu melindungi pelanggan dari serangan ransomware, lihat Perlindungan ransomware di Azure.
Privasi data
Anda harus memiliki keyakinan bahwa kami menangani data Anda dengan tepat dan untuk penggunaan yang sah. Bagian dari jaminan itu melibatkan pembatasan penggunaan dengan hati-hati.
Peraturan Perlindungan Data Umum
Peraturan Perlindungan Data Umum (GDPR) adalah perubahan terbesar dalam undang-undang perlindungan data di Eropa sejak pengenalan 1995 dari Arahan Perlindungan Data Uni Eropa (UE) 95/46/EC. Untuk informasi selengkapnya tentang GDPR, lihat halaman gambaran umum di Pusat Kepercayaan Microsoft.
Residensi dan kedaulatan data
Azure DevOps tersedia di delapan lokasi geografis berikut di seluruh dunia: Amerika Serikat, Kanada, Eropa, Inggris, India, Australia, Asia Pasifik, dan Brasil. Secara default, organisasi Anda ditetapkan ke lokasi terdekat Anda. Namun, Anda dapat memilih lokasi lain saat membuat organisasi. Jika Anda berubah pikiran nanti, Anda dapat memigrasikan organisasi ke lokasi yang berbeda dengan bantuan dukungan Microsoft.
Azure DevOps tidak memindahkan atau mereplikasi data pelanggan di luar lokasi yang dipilih. Sebagai gantinya, data Anda direplikasi secara geografis ke wilayah kedua dalam lokasi yang sama. Satu-satunya pengecualian adalah Brasil, yang mereplikasi data ke wilayah US Tengah Selatan untuk tujuan pemulihan bencana.
Catatan
Untuk build dan rilis yang berjalan pada agen macOS yang disediakan Microsoft, data Anda ditransfer ke pusat data GitHub di Amerika Serikat.
Untuk informasi selengkapnya, lihat Lokasi data untuk Azure DevOps.
Akses penegakan hukum
Dalam beberapa kasus, pihak ketiga seperti entitas penegak hukum mungkin mendekati Microsoft untuk mendapatkan akses ke data pelanggan yang disimpan di Azure DevOps. Kami mencoba mengalihkan permintaan ke pemilik organisasi untuk resolusi. Ketika perintah pengadilan memaksa Microsoft untuk mengungkapkan data pelanggan kepada pihak ketiga, Microsoft melakukan upaya yang wajar untuk memberi tahu pemilik organisasi terlebih dahulu, kecuali kami dilarang secara hukum melakukannya.
Beberapa pelanggan memerlukan penyimpanan data mereka di lokasi geografis tertentu untuk memastikan yurisdiksi hukum tertentu untuk setiap aktivitas penegakan hukum. Semua data pelanggan, seperti kode sumber, item kerja, hasil pengujian, dan cermin geo-redundan dan cadangan di luar situs, dipertahankan dalam salah satu lokasi yang disebutkan sebelumnya.
Akses Microsoft
Dari waktu ke waktu, karyawan Microsoft perlu mendapatkan akses ke data pelanggan yang disimpan di Azure DevOps. Sebagai tindakan pencegahan, semua karyawan yang memiliki (atau mungkin pernah memiliki) akses ke data pelanggan harus melewati pemeriksaan latar belakang yang mencakup pekerjaan sebelumnya dan keyakinan kriminal. Kami mengizinkan akses ke sistem produksi hanya ketika ada insiden situs langsung atau aktivitas pemeliharaan lain yang disetujui, yang dicatat dan dipantau.
Karena tidak semua data dalam sistem kami diperlakukan dengan cara yang sama, kami mengklasifikasikan data ke dalam jenis ini:
- Data pelanggan: Apa yang Anda unggah ke Azure DevOps.
- Data organisasi: Informasi yang Anda kirimkan saat mendaftar atau mengelola organisasi Anda.
- Data Microsoft: Informasi yang diperlukan untuk atau dikumpulkan melalui pengoperasian layanan.
Berdasarkan klasifikasi, kami mengontrol skenario penggunaan, persyaratan lokasi geografis, pembatasan akses, dan persyaratan retensi.
Penggunaan promosi Microsoft
Microsoft terkadang ingin menghubungi pelanggan untuk memberi tahu mereka tentang lebih banyak fitur dan layanan yang mungkin berguna. Karena tidak semua pelanggan ingin dihubungi tentang penawaran ini, Anda dapat memilih ikut serta dan menolak komunikasi email pemasaran.
Microsoft tidak pernah menggunakan data pelanggan untuk menargetkan penawaran tertentu untuk pengguna atau organisasi tertentu. Sebagai gantinya, kami menggunakan data organisasi dan statistik penggunaan agregat di tingkat organisasi untuk menentukan grup yang harus menerima penawaran tertentu.
Membangun kepercayaan diri
Anda dapat yakin dengan upaya lain yang dilakukan Microsoft atas nama Azure DevOps. Upaya ini termasuk kebijakan adopsi internal di Microsoft, tingkat transparansi ke dalam status layanan kami, dan kemajuan menuju penerimaan sertifikasi sistem kami untuk mengelola keamanan informasi.
Adopsi internal
Tim Microsoft mengadopsi Azure DevOps secara internal. Tim Azure DevOps pindah ke organisasi pada tahun 2014 dan menggunakannya secara ekstensif. Kami menetapkan panduan untuk mengaktifkan rencana adopsi untuk tim lain.
Tim besar bergerak lebih bertahap daripada yang lebih kecil, karena investasi mereka dalam sistem DevOps yang ada. Untuk tim yang bergerak cepat, kami membuat pendekatan klasifikasi proyek. Ini menilai toleransi risiko, berdasarkan karakteristik proyek, untuk menentukan apakah proyek sesuai untuk Azure DevOps. Untuk tim yang lebih besar, adopsi biasanya terjadi secara bertahap, dengan lebih banyak perencanaan.
Persyaratan lainnya untuk proyek internal termasuk mengaitkan organisasi dengan ID Microsoft Entra untuk memastikan siklus hidup identitas pengguna dan kompleksitas kata sandi yang tepat. Proyek yang lebih sensitif juga memerlukan autentikasi dua faktor.
Sertifikasi kepatuhan
Anda mungkin tertarik untuk memahami evaluasi pihak ketiga tentang prosedur kami untuk keamanan data. Azure DevOps mencapai sertifikasi berikut:
- ISO 27001:2013
- ISO 27018:2019
- ISO 26262:2023
- Undang-Undang Portabilitas dan Akuntabilitas Asuransi Kesehatan (HIPAA)
- Perjanjian Asosiasi Bisnis (BAA)
- Klausul Model UE
- Kontrol Sistem dan Organisasi (SOC) 1 Tipe 2
- SOC 2 Tipe 2
- Germany C5
- Australia IRAP
- ENS-Spanyol
Audit SOC untuk Azure DevOps mencakup kontrol untuk keamanan data, ketersediaan, integritas pemrosesan, dan kerahasiaan. Laporan SOC untuk Azure DevOps tersedia melalui Portal Kepercayaan Layanan Microsoft.
Kuesioner Inisiatif Penilaian Konsesius (CAIQ) membantu organisasi menilai dan mengevaluasi praktik dan kemampuan keamanan penyedia layanan cloud. Selaras dengan komitmen kami terhadap keamanan dan transparansi, kami baru-baru ini menyelesaikan penilaian CAIQ untuk Azure DevOps. Kami mengundang Anda untuk meninjau laporan lengkap di Portal Kepercayaan Layanan Microsoft.
Langkah-langkah yang dapat Anda ambil
Perlindungan data yang tepat memerlukan keterlibatan aktif dari Anda, administrator, dan pengguna Anda. Data proyek Anda yang disimpan di Azure DevOps hanya seaman titik akses pengguna. Cocokkan tingkat ketegasan izin dan granularitas untuk organisasi tersebut dengan tingkat sensitivitas proyek Anda.
Klasifikasikan data Anda
Langkah pertama adalah mengklasifikasikan data Anda. Mengklasifikasikan data berdasarkan sensitivitas dan cakrawala risiko, bersama dengan kerusakan yang mungkin terjadi jika disusupi. Banyak perusahaan memiliki metode klasifikasi yang ada yang dapat mereka gunakan kembali saat proyek pindah ke Azure DevOps. Untuk informasi selengkapnya, Anda dapat mengunduh klasifikasi Data untuk kesiapan cloud dari Microsoft Trustworthy Computing.
Mengadopsi ID Microsoft Entra
Gunakan ID Microsoft Entra untuk mengelola akses organisasi Anda ke Azure DevOps. MICROSOFT Entra ID menyediakan cara lain untuk meningkatkan keamanan kredensial pengguna Anda.
MICROSOFT Entra ID memungkinkan departemen IT Anda mengelola kebijakan akses pengguna, kompleksitas kata sandi, refresh kata sandi, dan kedaluwarsa saat pengguna meninggalkan organisasi Anda. Melalui federasi Direktori Aktif, Anda dapat langsung menautkan ID Microsoft Entra ke direktori pusat organisasi Anda, sehingga Anda hanya memiliki satu lokasi untuk mengelola detail ini untuk perusahaan Anda.
Tabel berikut membandingkan karakteristik akun Microsoft dan Microsoft Entra relatif terhadap akses Azure DevOps:
| Properti | Akun Microsoft | Microsoft Entra ID |
|---|---|---|
| Pembuat identitas | Pengguna | Organization |
| Nama pengguna dan kata sandi tunggal untuk semua aset kerja | Tidak | Ya |
| Masa pakai kata sandi dan kontrol kompleksitas | Pengguna | Organization |
| Batas keanggotaan Azure DevOps | Akun Microsoft apa pun | Direktori organisasi |
| Identitas yang dapat dilacak | Tidak | Ya |
| Kepemilikan organisasi dan IP | Jelas | Organization |
| Pendaftaran autentikasi dua faktor | Pengguna | Organization |
| Akses bersyarat berbasis perangkat | No | Organization |
Pelajari selengkapnya tentang mengonfigurasi dukungan ini untuk organisasi Anda.
Mewajibkan autentikasi dua faktor
Anda mungkin ingin membatasi akses ke organisasi Anda dengan memerlukan lebih dari satu faktor untuk masuk. Anda dapat memerlukan beberapa faktor dengan menggunakan ID Microsoft Entra. Misalnya, Anda dapat memerlukan autentikasi telepon, selain nama pengguna dan kata sandi, untuk semua permintaan autentikasi.
Gunakan BitLocker
Untuk proyek sensitif, Anda dapat menggunakan BitLocker di laptop Windows atau komputer desktop Anda. BitLocker mengenkripsi seluruh drive tempat Windows dan data Anda berada. Ketika BitLocker diaktifkan, BitLocker secara otomatis mengenkripsi file apa pun yang Anda simpan di drive tersebut. Jika komputer Anda jatuh ke tangan yang salah, BitLocker mencegah akses tidak sah salinan data lokal dari proyek Anda.
Batasi penggunaan kredensial autentikasi alternatif
Mekanisme autentikasi default untuk alat terkait Git adalah autentikasi alternatif (terkadang disebut autentikasi dasar). Mekanisme ini memungkinkan pengguna untuk menyiapkan nama pengguna dan kata sandi alternatif untuk digunakan selama operasi baris perintah Git. Pengguna dapat menggunakan kombinasi nama pengguna/kata sandi ini untuk mengakses data lain yang izinnya dimiliki pengguna tersebut. Secara alami, kredensial autentikasi alternatif kurang aman daripada autentikasi federasi default.
Anda masih dapat membuat pilihan untuk meningkatkan keamanan. Semua komunikasi dikirim melalui HTTPS, dan ada persyaratan kompleksitas kata sandi. Organisasi Anda harus terus mengevaluasi apakah perlu lebih banyak kebijakan untuk memenuhi persyaratan keamanan proyek Anda.
Anda dapat menonaktifkan kredensial autentikasi alternatif jika Anda memutuskan bahwa kredensial tersebut tidak memenuhi persyaratan keamanan organisasi Anda. Untuk informasi selengkapnya, lihat Mengubah koneksi aplikasi & kebijakan keamanan untuk organisasi Anda.
Mengamankan akses ke organisasi Anda
Administrator dapat menggunakan ID Microsoft Entra untuk mengontrol akses ke sumber daya dan aplikasi Azure, seperti Azure DevOps. Dengan kontrol akses berskala di tempat, MICROSOFT Entra ID memeriksa kondisi tertentu yang Anda tetapkan bagi pengguna untuk mengakses aplikasi. Setelah pengguna memenuhi persyaratan akses, pengguna diautentikasi dan dapat mengakses aplikasi.
Azure DevOps mendukung penerapan jenis kebijakan akses bersyariah tertentu (misalnya, pagar IP) untuk mekanisme autentikasi Azure DevOps kustom. Mekanisme ini termasuk token akses pribadi, autentikasi alternatif, OAuth, dan kunci Secure Shell (SSH). Jika pengguna Anda mengakses Azure DevOps melalui klien pihak ketiga, hanya kebijakan berbasis IPv4 yang dihormati.