Artikel ini menjelaskan cara mengotomatiskan operasi integrasi dan penyebaran Microsoft Azure Sentinel dengan Azure DevOps. Anda menerapkan Azure DevOps dengan menggunakan kemampuan Microsoft Azure Sentinel untuk membantu mengamankan penyebaran Anda. Anda kemudian menggunakan kerangka kerja DevSecOps untuk mengelola dan menyebarkan artefak Microsoft Azure Sentinel dalam skala besar.
Sistem
Diagram berikut menunjukkan penyiapan IaC Azure DevOps dan Microsoft Sentinel.
Unduh file Visio arsitektur ini.
Aliran data
- Master scrum dan manajemen produk menggunakan Azure DevOps untuk menentukan epik, cerita pengguna, dan item backlog produk sebagai bagian dari backlog proyek.
- Master scrum dan manajemen produk menggunakan Azure Boards untuk membuat backlog, menjadwalkan pekerjaan dalam sprint, meninjau papan proyek, membuat struktur repositori, dan menetapkan aturan keamanan seperti alur kerja persetujuan dan cabang.
- Repositori Azure Git menyimpan skrip dan izin untuk mengelola artefak Microsoft Azure Sentinel dalam infrastruktur sebagai kode.
- Artefak dan kontrol sumber mempertahankan ekstensi dan memperbarui paket atau komponen alur kerja DevSecOps yang digunakan dalam solusi, seperti Toolkit Templat Azure Resource Manager dan PowerShell Pester.
- Artefak Microsoft Azure Sentinel:
- Kebijakan. Teknisi SIEM menggunakan kebijakan Azure dalam arsitektur referensi, untuk mengonfigurasi dan menskalakan pengaturan diagnostik layanan Azure. Kebijakan ini membantu mengotomatiskan penyebaran konektor data Microsoft Azure Sentinel, seperti Azure Key Vault. Kebijakan bergantung pada API OMSIntegration.
- Konektor. Microsoft Azure Sentinel menggunakan konektor logis, azure Data Koneksi ors, untuk menyerap data keamanan, seperti dalam audit atau metrik, dari sumber data yang didukung, seperti ID Microsoft Entra, sumber daya Azure, Pertahanan Microsoft, atau solusi pihak ketiga. Daftar utama konektor data dikelola oleh SecurityInsights API. Yang lain mengandalkan API OMSIntegration dan dikelola dengan pengaturan diagnostik Azure Policy.
- Identitas terkelola. Microsoft Sentinel menggunakan identitas terkelola untuk bertindak atas nama Identitas layanan terkelola (MSI) saat berinteraksi dengan playbook, aplikasi logika, atau runbook otomatisasi dan brankas kunci.
- Automation. Tim SOC menggunakan otomatisasi selama penyelidikan. Tim SOC menjalankan prosedur akuisisi data forensik digital dengan Azure Automation, seperti rantai penahanan komputer virtual (VM) Azure atau eDiscovery (Premium) untuk Pertahanan Microsoft.
- Analitik. Analis SOC atau pemburu ancaman menggunakan aturan analitik bawaan atau kustom untuk menganalisis dan menghubungkan data di Microsoft Azure Sentinel atau untuk memicu playbook jika ancaman dan insiden diidentifikasi.
- Playbook. Aplikasi logika menjalankan tindakan Berulang SecOps, seperti menetapkan insiden, memperbarui insiden, atau mengambil tindakan remediasi, seperti mengisolasi atau berisi VM, mencabut token, atau mereset kata sandi pengguna.
- Perburuan ancaman. Pemburu ancaman menggunakan kemampuan perburuan ancaman proaktif yang dapat digabungkan dengan notebook Jupyter untuk kasus penggunaan tingkat lanjut, seperti pemrosesan data, manipulasi data, visualisasi data, pembelajaran mesin, atau pembelajaran mendalam.
- Buku kerja. Teknisi SIEM menggunakan dasbor Buku Kerja untuk memvisualisasikan tren dan statistik dan untuk melihat status instans Microsoft Azure Sentinel dan subkomponennya.
- Inteligensi ancaman. Konektor data tertentu yang menggabungkan platform inteligensi ancaman disalurkan ke Microsoft Azure Sentinel. Dua metode konektivitas didukung: TAXII dan Graph API. Kedua metode berfungsi sebagai tiIndicator, atau indikator inteligensi ancaman, dalam API keamanan.
- ID Microsoft Entra. Kemampuan manajemen identitas dan akses dikirimkan ke komponen yang digunakan dalam arsitektur referensi, seperti identitas terkelola, perwakilan layanan, kontrol akses berbasis peran Azure (RBAC) untuk Microsoft Sentinel, aplikasi logika, dan runbook otomatisasi.
- Azure Pipelines. Teknisi DevOps menggunakan alur untuk membuat koneksi layanan untuk mengelola langganan Azure yang berbeda seperti kotak pasir dan lingkungan produksi dengan integrasi berkelanjutan dan alur pengiriman berkelanjutan (CI/CD). Sebaiknya gunakan alur kerja persetujuan untuk mencegah penyebaran tak terduga dan perwakilan layanan yang dipisahkan jika Anda menargetkan beberapa langganan per lingkungan Azure.
- Azure Key Vault. Teknisi SOC menggunakan brankas kunci untuk menyimpan rahasia dan sertifikat perwakilan layanan dengan aman. Komponen arsitektur ini membantu memberlakukan prinsip DevSecOps tanpa rahasia dalam kode saat digunakan oleh koneksi layanan Azure Pipeline.
- Langganan Azure. Tim SOC menggunakan dua instans Microsoft Sentinel dalam arsitektur referensi ini, dipisahkan dalam dua langganan Azure logis untuk mensimulasikan lingkungan produksi dan kotak pasir. Anda dapat menskalakan untuk kebutuhan Anda dengan lingkungan lain, seperti pengujian, dev, praproduksi, dan sebagainya.
Contoh aliran data
- Administrator menambahkan, memperbarui, atau menghapus entri di fork file konfigurasi Microsoft 365 mereka.
- Administrator menerapkan dan menyinkronkan perubahan ke repositori fork mereka.
- Administrator kemudian membuat permintaan pull (PR) untuk menggabungkan perubahan ke repositori utama.
- Alur build berjalan pada PR.
Komponen
- MICROSOFT Entra ID adalah layanan berbasis cloud multi-penyewa untuk mengelola identitas dan kontrol akses Anda.
- Azure DevOps adalah layanan cloud untuk berkolaborasi pada kode, membangun dan menyebarkan aplikasi, atau merencanakan dan melacak pekerjaan Anda.
- Azure Key Vault adalah layanan cloud untuk menyimpan dan mengakses rahasia dengan aman. Rahasia adalah segala hal yang aksesnya ingin Anda kontrol dengan ketat, seperti kunci API, kata sandi, sertifikat, atau kunci kriptografi.
- Azure Policy adalah layanan untuk membuat, menetapkan, dan mengelola definisi kebijakan di lingkungan Azure Anda.
- Microsoft Sentinel adalah solusi orkestrasi, otomatisasi, dan respons (SOAR) yang dapat diskalakan, cloud-native, SIEM, dan keamanan.
- Azure Automation adalah layanan untuk menyederhanakan manajemen cloud melalui otomatisasi proses. Gunakan Azure Automation untuk mengotomatiskan tugas yang berjalan lama, manual, rawan kesalahan, dan sering berulang. Automation membantu meningkatkan keandalan, efisiensi, dan waktu untuk menghargai perusahaan Anda.
Detail skenario
Tim Security Operations Center (SOC) terkadang mengalami tantangan ketika mereka mengintegrasikan Microsoft Sentinel dengan Azure DevOps. Proses ini melibatkan banyak langkah, dan penyiapan dapat memakan waktu ber hari dan melibatkan pengulangan. Anda dapat mengotomatiskan bagian pengembangan ini.
Untuk memodernisasi cloud, teknisi harus terus-menerus mempelajari keterampilan dan teknik baru untuk mengamankan dan melindungi aset bisnis penting. Teknisi harus membangun solusi yang kuat dan dapat diskalakan yang mengimbangi lanskap keamanan yang berubah dan dengan kebutuhan bisnis. Solusi keamanan harus fleksibel, lincah, dan direncanakan dengan hati-hati dari tahap pengembangan paling awal. Metodologi perencanaan awal ini dikenal sebagai shift-left.
Artikel ini menjelaskan cara mengotomatiskan operasi integrasi dan penyebaran Microsoft Azure Sentinel dengan Azure DevOps. Anda dapat memperluas solusi untuk organisasi kompleks yang memiliki beberapa entitas, langganan, dan berbagai model operasi. Beberapa model operasi yang didukung oleh solusi ini termasuk SOC lokal, SOC global, penyedia layanan cloud (CSP), dan penyedia layanan keamanan terkelola (MSSP).
Artikel ini ditujukan untuk audiens berikut:
- Spesialis SOC, seperti analis dan pemburu ancaman
- Insinyur manajemen peristiwa dan informasi keamanan (SIEM)
- Arsitektur keamanan cyber
- Pengembang
Kemungkinan kasus penggunaan
Berikut ini adalah kasus penggunaan umum untuk arsitektur ini:
- Prototipe cepat dan bukti konsep. Solusi ini sangat ideal untuk organisasi keamanan dan tim SOC yang ingin meningkatkan cakupan ancaman cloud atau memodernisasi infrastruktur SIEM mereka dengan infrastruktur sebagai kode (IaC) dan Microsoft Sentinel.
- Microsoft Sentinel sebagai layanan. Kerangka kerja pengembangan ini mengintegrasikan prinsip manajemen siklus hidup layanan. Prinsip-prinsip ini sesuai dengan tim sederhana atau kompleks seperti MSP yang menjalankan tindakan standar yang dapat diulang di beberapa penyewa pelanggan sambil menggabungkan kekuatan Azure DevOps dan Azure Lighthouse. Misalnya, tim yang perlu menerbitkan kasus penggunaan Microsoft Azure Sentinel untuk pelaku ancaman baru atau kampanye yang sedang berlangsung dapat menggunakan solusi ini.
- Membangun kasus penggunaan SOC untuk deteksi ancaman. Banyak kelompok dan platform inteligensi ancaman mengandalkan konten dan taksonomi MITRE Att&ck untuk menganalisis postur keamanan mereka terhadap tradecraft atau teknik dan prosedur taktik tingkat lanjut. Solusi ini mendefinisikan pendekatan terstruktur untuk mengembangkan praktik rekayasa deteksi ancaman dengan menggabungkan terminologi MITRE Att&ck dalam pengembangan artefak Microsoft Azure Sentinel.
Ilustrasi berikut menunjukkan skenario cloud MITRE Att&ck.
Unduh file Visio arsitektur ini.
Skenario serangan definisi ancaman berdasarkan MITRE
Tabel ini menunjukkan istilah, definisi, dan detail aspek penting skenario serangan.
| Data item | Deskripsi | Artefak Microsoft Azure Sentinel |
|---|---|---|
| Judul | Nama deskriptif untuk skenario serangan, berdasarkan karakteristik vektor serangan atau deskripsi teknik. | Manifes MITRE |
| Taktik MITRE ATTA&CK | Taktik MITRE ATT&CK yang terkait dengan skenario serangan | Manifes MITRE |
| Teknik MITRE ATT&CK | Teknik MITRE ATT&CK, termasuk TEKNIK atau ID sub-teknik, yang terkait dengan skenario serangan. | Manifes MITRE |
| Sumber konektor data | Sumber informasi yang dikumpulkan oleh sensor atau sistem pengelogan yang mungkin digunakan untuk mengumpulkan informasi yang relevan dengan mengidentifikasi tindakan yang dilakukan, urutan tindakan, atau hasil tindakan tersebut oleh lawan. | Konektor data Microsoft Azure Sentinel atau Sumber log kustom |
| Deskripsi | Informasi tentang teknik, apa itu, untuk apa biasanya digunakan, bagaimana musuh dapat memanfaatkannya, dan variasi tentang bagaimana hal itu dapat digunakan. Termasuk referensi ke artikel otoritatif yang menjelaskan informasi teknis yang terkait dengan teknik serta dalam referensi penggunaan liar yang sesuai. | |
| Detection | Proses analitik tingkat tinggi, sensor, data, dan strategi deteksi berguna dalam mengidentifikasi teknik yang telah digunakan oleh seterusnya. Bagian ini memberi tahu mereka yang bertanggung jawab untuk mendeteksi perilaku pendukung, seperti pertahanan jaringan, sehingga mereka dapat mengambil tindakan seperti menulis analitik atau menyebarkan sensor. Harus ada cukup informasi dan referensi untuk menunjuk ke metodologi defensif yang berguna. Deteksi mungkin tidak selalu dimungkinkan untuk teknik tertentu dan harus didokumenkan seperti itu. | Perburuan ancaman analitik |
| Mitigasi | Konfigurasi, alat, atau proses yang mencegah teknik bekerja atau memiliki hasil yang diinginkan untuk seorang adversary. Bagian ini memberi tahu mereka yang bertanggung jawab untuk mengurangi lawan, seperti pembela jaringan atau pembuat kebijakan, untuk membiarkan mereka mengambil tindakan seperti mengubah kebijakan atau menyebarkan alat. Mitigasi mungkin tidak selalu dimungkinkan untuk teknik tertentu dan harus didokumenkan seperti itu. | |
| Mitigasi | Konfigurasi, alat, atau proses yang mencegah teknik bekerja atau memiliki hasil yang diinginkan untuk seorang adversary. Bagian ini menjelaskan cara mengurangi efek serangan musuh bagi pembela jaringan atau pembuat kebijakan. Ini mencakup langkah-langkah untuk mengubah kebijakan atau menyebarkan alat. Mitigasi mungkin tidak selalu dimungkinkan untuk teknik tertentu dan harus didokumenkan seperti itu. | Playbook, runbook otomatisasi |
Pertimbangan
Pertimbangan ini mengimplementasikan pilar Azure Well-Architected Framework, sekumpulan tenet panduan yang dapat Anda gunakan untuk meningkatkan kualitas beban kerja. Untuk informasi selengkapnya, lihat Microsoft Azure Well-Architected Framework.
Keamanan
Keamanan memberikan jaminan terhadap serangan yang disukai dan penyalahgunaan data dan sistem berharga Anda. Untuk informasi selengkapnya, lihat Gambaran Umum pilar keamanan.
Dengan keamanan, secara umum, otomatisasi meningkatkan efisiensi operasi sekaligus menghemat waktu untuk kasus penggunaan yang lebih kompleks, seperti rekayasa deteksi ancaman, inteligensi ancaman, SOC, dan kasus penggunaan SOAR. Tim DevOps perlu mengetahui di mana mereka dapat menggunakan IaC dengan aman dalam konteks MICROSOFT Sentinel CI/CD. Proses ini memperkenalkan penggunaan identitas tertentu yang digunakan oleh akun non-manusia di ID Microsoft Entra yang disebut perwakilan layanan dan identitas terkelola.
Tabel berikut ini meringkas pertimbangan keamanan untuk perwakilan layanan dan kasus penggunaan utama yang dicakup oleh alur rilis Microsoft Sentinel dan Azure DevOps.
| Gunakan huruf besar | Persyaratan (hak istimewa paling sedikit) | Durasi penetapan peran | Cakupan izin | Wali | Pertimbangan keamanan |
|---|---|---|---|---|---|
| Mengaktifkan konektor Microsoft Azure Sentinel | Administrator keamanan** Pemilik* Kontributor Microsoft Azure Sentinel Pembaca |
JIT (aktivasi satu kali) Sengaja (setiap kali langganan dan konektor baru disebarkan) |
Penyewa | SPN | Gunakan brankas kunci untuk menyimpan rahasia dan sertifikat nama prinsipal layanan (SPN). Aktifkan audit SPN. Secara berkala, tinjau penetapan izin (Azure Privileged Identity Management untuk SPN) atau aktivitas mencurigakan untuk SPN. Gunakan otoritas sertifikat Microsoft Entra dan autentikasi multifaktor (jika didukung) untuk akun istimewa. Gunakan Peran Kustom Microsoft Entra untuk lebih banyak granularitas. |
| Menyebarkan artefak Microsoft Azure Sentinel, seperti buku kerja, analitik, aturan, kueri perburuan ancaman, notebook, dan playbook | Kontributor Microsoft Azure Sentinel Kontributor Logic Apps |
Permanen | Ruang Kerja atau Grup Sumber Daya Microsoft Sentinel | SPN | Gunakan persetujuan alur kerja Azure DevOps (ADO) dan periksa untuk mengamankan penyebaran alur dengan SPN ini. |
| Menetapkan kebijakan untuk mengonfigurasi fitur streaming log ke Microsoft Azure Sentinel | Kontributor Kebijakan Sumber Daya ** | Sengaja (setiap kali langganan dan konektor baru disebarkan) | Semua langganan yang akan dipantau | SPN | Gunakan MICROSOFT Entra ID, CA, dan MFA, saat didukung, untuk akun istimewa. |
* Hanya menyangkut pengaturan diagnostik Microsoft Entra.
** Konektor tertentu memerlukan izin tambahan seperti "administrator keamanan" atau "kontributor kebijakan sumber daya" untuk memungkinkan data streaming ke ruang kerja Microsoft Azure Sentinel, ID Microsoft Entra, Microsoft 365 atau Pertahanan Microsoft, dan sumber daya Platform as a service (PaaS) seperti Azure Key Vault.
Model akses istimewa
Sebaiknya adopsi strategi model akses istimewa untuk menurunkan risiko dengan cepat kepada perusahaan Anda dari serangan berdampak tinggi dan berpeluang tinggi pada akses istimewa. Dalam kasus proses otomatis dalam model DevOps, dasarkan identitas pada identitas perwakilan layanan.
Akses istimewa harus menjadi prioritas keamanan teratas di setiap perusahaan. Setiap kompromi identitas ini menciptakan dampak yang sangat negatif. Identitas istimewa memiliki akses ke aset penting bisnis, yang hampir selalu menyebabkan dampak besar ketika penyerang membahayakan akun-akun ini.
Keamanan akses istimewa sangat penting karena merupakan dasar untuk semua jaminan keamanan lainnya. Penyerang yang mengendalikan akun istimewa Anda dapat merusak semua jaminan keamanan lainnya.
Untuk alasan itu, sebaiknya sebarkan perwakilan layanan secara logis ke tingkat atau tingkatan yang berbeda dengan mengikuti prinsip hak istimewa minimum. Ilustrasi berikut menunjukkan cara mengklasifikasikan perwakilan layanan, tergantung pada jenis akses dan di mana akses diperlukan.
Perwakilan layanan tingkat 0
Perwakilan layanan tingkat 0 memiliki tingkat izin tertinggi. Perwakilan layanan ini memberi seseorang hak untuk melakukan tugas administrasi grup manajemen seluruh penyewa atau akar sebagai administrator global.
Untuk alasan keamanan dan pengelolaan, kami sarankan Anda hanya memiliki satu perwakilan layanan untuk tingkat ini. Izin untuk perwakilan layanan ini tetap ada, jadi kami sarankan Anda hanya memberikan izin minimum yang diperlukan dan menjaga akun tetap dipantau dan diamankan.
Simpan rahasia atau sertifikat untuk akun ini dengan aman di Azure Key Vault. Kami sangat menyarankan Agar Anda menemukan brankas kunci dalam langganan administratif khusus jika memungkinkan.
Perwakilan layanan tingkat 1
Perwakilan layanan tingkat 1 adalah izin yang ditingkatkan yang dibatasi dan dilingkupkan ke grup manajemen di tingkat organisasi bisnis. Perwakilan layanan ini memberikan hak kepada seseorang untuk membuat langganan di bawah grup manajemen yang berada dalam cakupan.
Untuk alasan keamanan dan pengelolaan, kami sarankan Anda hanya memiliki satu perwakilan layanan untuk tingkat ini. Izin untuk perwakilan layanan ini tetap ada, jadi kami sangat menyarankan Agar Anda hanya memberikan izin minimum yang diperlukan dan menjaga akun tetap dipantau dan diamankan.
Simpan rahasia atau sertifikat untuk akun ini dengan aman di Azure Key Vault. Kami sangat menyarankan Agar Anda menemukan brankas kunci dalam langganan administratif khusus jika memungkinkan.
Perwakilan layanan tingkat 2
Perwakilan layanan tingkat 2 terbatas pada tingkat langganan. Perwakilan layanan ini memberi seseorang hak untuk melakukan tugas administratif berdasarkan langganan, yang bertindak sebagai pemilik langganan.
Untuk alasan keamanan dan pengelolaan, kami sarankan Anda hanya memiliki satu perwakilan layanan untuk tingkat ini. Izin untuk perwakilan layanan ini tetap ada, jadi kami sangat menyarankan Agar Anda hanya memberikan izin minimum yang diperlukan dan menjaga akun tetap dipantau dan diamankan.
Simpan rahasia atau sertifikat untuk akun ini dengan aman di Azure Key Vault. Kami sangat menyarankan Anda menemukan brankas kunci dalam grup sumber daya administratif khusus.
Perwakilan layanan tingkat 3
Perwakilan layanan tingkat 3 terbatas pada Administrator Beban Kerja. Dalam skenario umum, setiap beban kerja terkandung di dalam grup sumber daya yang sama. Struktur ini membatasi izin perwakilan layanan hanya untuk grup sumber daya ini.
Untuk alasan keamanan dan pengelolaan, kami sarankan Anda hanya memiliki satu perwakilan layanan per beban kerja. Izin untuk perwakilan layanan ini tetap ada, jadi kami sangat menyarankan Agar Anda hanya memberikan izin minimum yang diperlukan dan menjaga akun tetap dipantau dan diamankan.
Simpan rahasia atau sertifikat untuk akun ini dengan aman di Azure Key Vault. Kami sangat menyarankan Anda menemukan brankas kunci dalam grup sumber daya administratif khusus.
Perwakilan layanan tingkat 4
Perwakilan layanan tingkat 4 memiliki izin yang paling terbatas. Perwakilan layanan ini memberikan hak kepada seseorang untuk melakukan tugas administratif yang terbatas pada satu sumber daya.
Sebaiknya gunakan identitas terkelola jika memungkinkan. Dalam kasus identitas yang tidak dikelola, simpan rahasia atau sertifikat dengan aman di Azure Key Vault tempat rahasia Tingkat 3 disimpan.
Keunggulan operasional
Keunggulan operasional mencakup proses operasi yang menyebarkan aplikasi dan membuatnya tetap berjalan dalam produksi. Untuk informasi selengkapnya, lihat Gambaran umum pilar keunggulan operasional.
Solusi Microsoft Azure Sentinel terdiri dari tiga blok, yang memastikan operasi selesai dan berhasil.
Blok pertama adalah definisi lingkungan, yang membentuk elemen arsitektur penting. Perhatian utama Anda dengan blok ini adalah mempertimbangkan jumlah lingkungan produksi dan non-produksi yang akan disebarkan, dan kemudian memastikan pengaturan homogen dalam semua kasus.
Blok kedua adalah penyebaran konektor Microsoft Azure Sentinel, di mana Anda mempertimbangkan jenis konektor yang diperlukan oleh tim Anda dan persyaratan keamanan untuk mengaktifkannya.
Blok ketiga adalah manajemen siklus hidup artefak Microsoft Sentinel, yang mencakup pengkodan, penyebaran, dan penggunaan atau penghancuran komponen. Misalnya, blok ini berisi aturan analitik, playbook, buku kerja, perburuan ancaman, dan sebagainya.
Pertimbangkan dependensi ini di antara artefak:
- Aturan otomatisasi yang ditentukan dalam aturan analitik
- Buku kerja atau analitik yang memerlukan sumber data atau konektor baru
- Mengelola pembaruan komponen yang ada
- Cara membuat versi artefak Anda
- Cara mengidentifikasi, menguji, dan menyebarkan aturan analitik yang diperbarui atau sepenuhnya baru
Membangun, menguji, dan menyebarkan infrastruktur
Dalam mengelola solusi Microsoft Azure Sentinel dan DevOps, penting untuk mempertimbangkan aspek konektivitas dan keamanan arsitektur perusahaan Anda.
Azure DevOps dapat menggunakan agen yang dihosting Microsoft atau agen yang dihost sendiri untuk membangun, menguji, dan menyebarkan aktivitas. Bergantung pada persyaratan perusahaan Anda, Anda dapat menggunakan yang dihosting Microsoft, dihost sendiri, atau kombinasi kedua model.
- Agen yang di-hosting Microsoft. Opsi ini adalah cara tercepat untuk bekerja dengan agen Azure DevOps, karena ini adalah infrastruktur bersama untuk seluruh organisasi Anda. Untuk informasi selengkapnya tentang menggunakan agen yang dihosting Microsoft di alur Anda, lihat Agen yang dihosting Microsoft. Agen yang dihosting Microsoft dapat bekerja di lingkungan jaringan hibrid, memberikan akses untuk rentang IP. Untuk mengunduh rentang IP yang diberikan akses oleh agen ini, lihat Rentang IP Azure dan Tag Layanan – Cloud Publik.
- Agen yang dihost sendiri. Opsi ini memberi Anda sumber daya khusus dan kontrol lainnya saat menginstal perangkat lunak dependen untuk build dan penyebaran Anda. Agen yang dihost sendiri dapat bekerja melalui VM, set skala, dan kontainer di Azure. Untuk informasi selengkapnya tentang agen yang dihost sendiri, lihat Agen Azure Pipelines.
Pelari GitHub
GitHub dapat menggunakan pelari yang dihosting GitHub atau pelari yang dihost sendiri untuk aktivitas yang terkait dengan pembangunan, pengujian, dan penyebaran. Tergantung pada kebutuhan perusahaan Anda, Anda dapat menggunakan GitHub-hosted, self-hosted, atau kombinasi dari kedua model.
Runner yang di hosting GitHub
Opsi ini adalah cara tercepat untuk bekerja dengan alur kerja GitHub, karena ini adalah infrastruktur bersama untuk seluruh organisasi. Untuk informasi selengkapnya, lihat Tentang pelari yang dihosting GitHub. Agen yang dihosting GitHub bekerja di lingkungan jaringan hibrid, sesuai dengan persyaratan jaringan tertentu. Untuk informasi selengkapnya tentang persyaratan jaringan, lihat Runner dan sumber daya perangkat keras yang didukung.
Runner yang dihosting sendiri
Opsi ini memberi perusahaan Anda infrastruktur sumber daya khusus. Pelari yang dihost sendiri bekerja melalui VM dan kontainer di Azure dan mendukung penskalakan otomatis.
Pertimbangan untuk memilih pelari
Saat memilih opsi untuk agen dan pelari dalam solusi Microsoft Azure Sentinel Anda, pertimbangkan kebutuhan berikut:
- Apakah perusahaan Anda memerlukan sumber daya khusus untuk menjalankan proses di lingkungan Microsoft Azure Sentinel Anda?
- Apakah Anda ingin mengisolasi sumber daya untuk aktivitas DevOps lingkungan produksi dari lingkungan lainnya?
- Apakah Anda perlu menguji kasus tertentu yang memerlukan akses ke sumber daya atau sumber daya penting yang hanya tersedia di jaringan internal?
Orkestrasi dan otomatisasi proses rilis
Anda dapat menyiapkan proses penyebaran dengan Azure DevOps atau GitHub. Azure DevOps mendukung penggunaan alur YAML atau alur rilis. Untuk informasi selengkapnya tentang menggunakan alur YAML di Azure DevOps, lihat Menggunakan Azure Pipelines. Untuk informasi selengkapnya tentang menggunakan alur rilis di Azure DevOps, lihat Merilis alur. Untuk informasi selengkapnya tentang menggunakan GitHub dengan GitHub Actions, lihat Memahami GitHub Actions.
Azure DevOps
Anda dapat melakukan aktivitas penyebaran berikut dalam penyebaran Azure DevOps.
- Gunakan alur YAML untuk memicu persetujuan PR secara otomatis atau berjalan sesuai permintaan.
- Mengelola koneksi layanan untuk lingkungan yang berbeda dengan menggunakan grup Azure DevOps.
- Pada lingkungan penting Anda, siapkan persetujuan penyebaran dengan menggunakan fitur koneksi layanan dan grup Azure DevOps untuk menetapkan izin pengguna tertentu di tim Anda.
GitHub
Anda dapat melakukan aktivitas penyebaran berikut dalam penyebaran GitHub.
- Gunakan GitHub untuk membuat PR atau aktivitas penyebaran.
- Mengelola kredensial perwakilan layanan dengan menggunakan Rahasia GitHub.
- Integrasikan persetujuan penyebaran melalui alur kerja yang terkait dengan GitHub.
Penyebaran otomatis dengan infrastruktur Microsoft Azure Sentinel
Anda dapat menyebarkan satu atau beberapa lingkungan Microsoft Azure Sentinel, tergantung pada arsitektur perusahaan Anda:
- Organisasi yang membutuhkan beberapa instans di lingkungan produksi mereka dapat menyiapkan langganan yang berbeda pada penyewa yang sama untuk setiap lokasi geografis.
- Instans terpusat pada lingkungan produksi menyediakan akses ke satu atau beberapa organisasi pada penyewa yang sama.
- Grup yang membutuhkan beberapa lingkungan seperti produksi, praproduksi, integrasi, dan sebagainya dapat membuat dan menghancurkannya sesuai kebutuhan.
Definisi lingkungan fisik versus logis
Anda memiliki dua pilihan dalam menyiapkan definisi lingkungan Anda, fisik atau logis. Keduanya memiliki opsi dan keuntungan yang berbeda:
- Definisi fisik - Elemen arsitektur Microsoft Azure Sentinel didefinisikan dengan opsi berikut untuk infrastruktur sebagai kode (IaC):
- Templat Bicep
- Templat Azure Resource Manager (templat ARM)
- Terraform
- Definisi logis - Ini bertindak sebagai lapisan abstraksi untuk menyiapkan tim yang berbeda dalam grup dan menentukan lingkungan mereka. Definisi diatur dalam alur penyebaran dan alur kerja sebagai input untuk lingkungan build dengan menggunakan lapisan infrastruktur fisik.
Pertimbangkan poin-poin ini saat Anda menentukan lingkungan logis Anda:
- Konvensi penamaan
- Identifikasi lingkungan
- Koneksi or dan konfigurasi
Repositori kode
Mengingat pendekatan lingkungan yang ditampilkan di bagian sebelumnya, pertimbangkan organisasi repositori kode GitHub berikut.
Definisi fisik - Berdasarkan opsi IaC, pikirkan pendekatan yang menggunakan definisi modul individual yang ditautkan dalam definisi penyebaran utama.
Contoh berikut menunjukkan bagaimana kode Anda mungkin diatur.
Batasi akses ke repositori ini ke tim yang menentukan arsitektur di tingkat fisik, memastikan definisi homogen dalam arsitektur perusahaan.
Anda dapat menyesuaikan strategi percabangan dan penggabungan dengan strategi penyebaran untuk setiap organisasi. Jika tim Anda perlu memulai dengan definisi, lihat Mengadopsi strategi percabangan Git.
Untuk informasi selengkapnya tentang templat ARM, lihat Menggunakan templat tertaut dan berlapis saat menyebarkan sumber daya Azure.
Untuk informasi selengkapnya tentang menyiapkan lingkungan Bicep, lihat Menginstal alat Bicep. Untuk informasi selengkapnya tentang GitHub, lihat Alur GitHub.
Definisi logis mendefinisikan lingkungan perusahaan. Repositori Git mengumpulkan definisi yang berbeda untuk perusahaan.
Contoh berikut menunjukkan bagaimana kode Anda mungkin diatur.
Repositori mencerminkan tindakan PR yang dibuat oleh tim yang berbeda. Beberapa lingkungan didefinisikan oleh tim yang berbeda dan disetujui oleh pemilik atau pemberi persetujuan perusahaan.
Tingkat hak istimewa untuk menjalankan penyebaran lingkungan adalah Tingkat 2. Tingkat ini memastikan bahwa grup sumber daya dan sumber daya dibuat untuk lingkungan dengan keamanan dan privasi yang diperlukan. Tingkat ini juga mengatur izin pengguna pada tindakan yang diizinkan di lingkungan produksi, produksi, dan praproduksi.
Organisasi yang menginginkan lingkungan sesuai permintaan untuk pengujian dan pengembangan dan kemampuan untuk kemudian menghancurkan lingkungan setelah menyelesaikan pengujian mereka, dapat menerapkan alur Azure DevOps atau tindakan GitHub. Mereka dapat mengatur pemicu terjadwal untuk menghancurkan lingkungan sesuai kebutuhan dengan menggunakan peristiwa Azure DevOps atau tindakan GitHub.
Konfigurasi otomatis konektor Microsoft Azure Sentinel
Konektor Microsoft Azure Sentinel adalah bagian penting dari solusi yang mendukung koneksi dengan elemen yang berbeda dalam lanskap arsitektur perusahaan, seperti ID Microsoft Entra, Microsoft 365, Pertahanan Microsoft, solusi platform inteligensi ancaman, dan sebagainya.
Saat menentukan lingkungan, Anda dapat menggunakan konfigurasi konektor untuk menyiapkan lingkungan dengan konfigurasi homogen.
Mengaktifkan konektor sebagai bagian dari model DevOps harus didukung oleh model tingkat perwakilan layanan. Fokus ini memastikan tingkat izin yang tepat seperti yang diperlihatkan dalam tabel berikut.
| skenario Koneksi or | Tingkat model akses hak istimewa | Hak istimewa terkecil Azure | Memerlukan persetujuan alur kerja |
|---|---|---|---|
| Microsoft Entra ID | Tingkat 0 | admin global atau admin keamanan | Disarankan |
| Microsoft Entra ID Protection | Tingkat 0 | admin global atau admin keamanan | Disarankan |
| Microsoft Defender for Identity | Tingkat 0 | Admin global atau admin keamanan | Disarankan |
| Microsoft Office 365 | Tingkat 0 | admin global atau admin keamanan | Disarankan |
| Microsoft Cloud App Security | Tingkat 0 | admin global atau admin keamanan | Disarankan |
| Microsoft Defender XDR | Tingkat 0 | admin global atau admin keamanan | Disarankan |
| Pertahanan Microsoft untuk IOT | Level 2 | Kontributor | Disarankan |
| Microsoft Defender for Cloud | Level 2 | Pembaca Keamanan | Opsional |
| Azure Activity | Level 2 | Pembaca Langganan | Opsional |
| Platform Inteligensi Ancaman | Tingkat 0 | admin global atau admin keamanan | Disarankan |
| Peristiwa Keamanan | Level 4 | Tidak | Opsional |
| Syslog | Level 4 | Tidak | Opsional |
| DNS (pratinjau) | Level 4 | Tidak | Opsional |
| Windows Firewall | Level 4 | Tidak | Opsional |
| Windows Security Events melalui AMA | Level 4 | Tidak | Opsional |
Penyebaran artefak Microsoft Azure Sentinel
Dalam implementasi artefak Microsoft Azure Sentinel, DevOps mendapatkan relevansi yang lebih besar, karena setiap perusahaan membuat beberapa artefak untuk mencegah dan memulihkan serangan.
Menerapkan artefak dapat menjadi tanggung jawab satu tim atau beberapa tim. Penyebaran build dan artefak otomatis seringkali merupakan persyaratan proses yang paling umum dan menentukan pendekatan dan kondisi untuk agen dan pelari Anda.
Menyebarkan dan mengelola artefak Microsoft Azure Sentinel memerlukan penggunaan REST API Microsoft Sentinel. Untuk informasi selengkapnya, lihat MICROSOFT Sentinel REST API. Diagram berikut menunjukkan alur Azure DevOps pada tumpukan Azure REST API.
Anda juga dapat menerapkan repositori anda dengan menggunakan PowerShell.
Jika tim Anda menggunakan MITRE, pertimbangkan untuk mengklasifikasikan artefak yang berbeda dan menentukan taktik dan teknik untuk masing-masing artefak. Pastikan Anda menyertakan file metadata yang sesuai untuk setiap jenis artefak.
Misalnya, jika Anda membuat playbook baru dengan menggunakan templat Azure ARM dan nama file Playbook.arm.json, Anda menambahkan file JSON bernama Playbook.arm.mitre.json. Metadata untuk file ini kemudian mencakup format CSV, JSON, atau YAML yang sesuai dengan taktik atau teknik MITRE yang Anda gunakan.
Dengan mengikuti praktik ini, tim Anda dapat mengevaluasi cakupan MITRE Anda berdasarkan pekerjaan yang dilakukan selama penyiapan untuk berbagai jenis artefak yang Anda gunakan.
Membangun artefak
Tujuan dari proses build Anda adalah untuk memastikan bahwa Anda menghasilkan artefak berkualitas tertinggi. Diagram berikut menunjukkan beberapa tindakan proses build yang dapat Anda ambil.
Unduh file Visio arsitektur ini.
- Anda dapat mendasarkan definisi artefak Anda pada skema deskriptif dalam format JSON atau YAML lalu memvalidasi skema untuk menghindari kesalahan sintaks.
- Validasi templat ARM Anda dengan menggunakan toolkit pengujian templat ARM.
- Validasi file YAML dan JSON Anda untuk model kustom dengan menggunakan PowerShell.
- Validasi pengaturan daftar pengawasan Anda dan pastikan bahwa catatan perutean antar-domain tanpa kelas (CIDR) yang Anda tentukan mengikuti skema yang benar, misalnya, 10.1.0.0/16.
- Gunakan kueri bahasa kueri kata kunci (KQL), yang dapat Anda validasi pada tingkat sintaks, untuk aturan analitik, aturan perburuan, dan aturan streaming langsung, yang dapat Anda validasi pada tingkat sintaks.
- Jadikan opsi validasi lokal KQL sebagai salah satu opsi.
- Integrasikan alat validasi sebaris KQL di alur DevOps.
- Jika Anda menerapkan logika yang didasarkan pada PowerShell untuk Azure Automation, Anda dapat menyertakan validasi sintaks dan pengujian unit dengan menggunakan elemen berikut:
- Buat laporan metadata manifes MITRE berdasarkan file metadata yang disertakan dengan artefak.
Mengekspor artefak
Biasanya, beberapa tim bekerja atas beberapa instans Microsoft Azure Sentinel untuk menghasilkan artefak yang diperlukan dan memvalidasinya. Dengan tujuan menggunakan kembali artefak yang ada, perusahaan Anda dapat menyiapkan proses otomatis untuk mendapatkan definisi artefak dari lingkungan yang ada. Automation juga dapat menyediakan informasi tentang artefak apa pun yang dibuat oleh tim pengembangan yang berbeda selama penyiapan.
Diagram berikut menunjukkan contoh proses ekstraksi artefak.
Unduh file Visio arsitektur ini.
Mengembangkan artefak
Tujuan dari proses penyebaran Anda adalah untuk:
- Kurangi waktu ke pasar.
- Tingkatkan performa di beberapa tim yang terlibat dalam pengaturan dan pengelolaan solusi Anda.
- Siapkan pengujian integrasi untuk mengevaluasi kesehatan lingkungan.
Tim pengembangan menggunakan proses ini untuk memastikan mereka dapat menyebarkan, menguji, dan memvalidasi kasus penggunaan artefak yang sedang dikembangkan. Arsitektur dan tim SOC memvalidasi kualitas alur pada lingkungan QA dan bekerja dengan pengujian integrasi untuk skenario serangan. Pada kasus pengujian, tim biasanya menggabungkan artefak yang berbeda sebagai aturan analitik, playbook remediasi, daftar pengawasan, dan sebagainya. Bagian dari setiap kasus penggunaan mencakup simulasi serangan di mana seluruh rantai dievaluasi dari penyerapan, deteksi, dan remediasi.
Diagram berikut menunjukkan urutan proses penyebaran yang memastikan artefak Anda disebarkan dalam urutan yang tepat.
Unduh file Visio arsitektur ini.
Mengelola artefak Sentinel sebagai kode menawarkan cara fleksibel untuk mempertahankan operasi Anda dan mengotomatiskan penyebaran dalam alur CI/CD DevOps.
Solusi Microsoft menyediakan alur kerja otomatisasi untuk artefak berikut.
| Artefak | Alur kerja Automation |
|---|---|
| Daftar Pantau | Tinjauan kode Validasi skema Penyebaran Membuat, memperbarui, menghapus daftar tonton, dan item |
| Fusi aturan analitik Keamanan Microsoft Analitik perilaku ML Anomali Dijadwalkan |
Tinjauan kode Validasi Sintaks KQL Skema validasi Pester Penyebaran Membuat, Mengaktifkan, Memperbarui, Menghapus, Mengekspor Dukungan templat pemberitahuan |
| Aturan automasi | Tinjauan kode Skema validasi Penyebaran Membuat, mengaktifkan, memperbarui, menghapus, mengekspor |
| Konektor | Tinjauan kode Skema validasi Penyebaran Tindakan: aktifkan, hapus (nonaktifkan), perbarui |
| Aturan berburu | Tinjauan kode Validasi Sintaks KQL Skema validasi Pester Penyebaran Tindakan: membuat, mengaktifkan, memperbarui, menghapus, mengekspor |
| Pedoman | Tinjauan kode TTK Penyebaran Tindakan: membuat, mengaktifkan, memperbarui, menghapus, mengekspor |
| Buku kerja | Penyebaran Tindakan: membuat, memperbarui, menghapus |
| Runbook | Tinjauan kode Validasi sintaks PowerShell Pester Penyebaran Tindakan: membuat, mengaktifkan, memperbarui, menghapus, mengekspor |
Bergantung pada bahasa automasi yang Anda pilih, beberapa kemampuan otomatisasi mungkin tidak didukung. Diagram berikut menunjukkan kemampuan otomatisasi mana yang didukung oleh bahasa.
* Fitur dalam pengembangan yang belum didokumenkan
** Metode automasi yang didukung oleh Microsoft Operational Insights atau API Penyedia Sumber Daya Microsoft Insights
Otomatisasi Azure
Diagram berikut menunjukkan komponen penyederhanaan akses Microsoft Sentinel dengan identitas layanan terkelola.
Unduh file Visio arsitektur ini.
Jika Anda perlu memberikan akses ke sumber daya lain, gunakan identitas terkelola, yang memastikan identitas unik untuk semua operasi penting.
Gunakan Azure Automation untuk menyiapkan playbook. Gunakan skrip PowerShell untuk tugas kompleks dan fitur otomatisasi berikut:
- Mengintegrasikan dengan solusi pihak ketiga, di mana berbagai tingkat kredensial diperlukan dan berdasarkan ID Microsoft Entra atau kredensial kustom:
- Kredensial pengguna Microsoft Entra
- Kredensial perwakilan layanan Microsoft Entra
- Autentikasi sertifikat
- Kredensial kustom
- Identitas terkelola
- Menerapkan solusi yang menggunakan kembali skrip organisasi, atau solusi yang memerlukan penggunaan perintah PowerShell untuk menghindari terjemahan kompleks ke playbook:
- Solusi berbasis PowerShell
- Solusi berbasis Python
- Menerapkan solusi dalam skenario hibrid, di mana tindakan remediasi dapat memengaruhi sumber daya cloud dan lokal Anda.
Repositori Microsoft Azure Sentinel
Tim DevOps berpengalaman mungkin mempertimbangkan untuk mengelola Microsoft Azure Sentinel dalam infrastruktur sebagai kode (IaC) dengan alur CI/CD yang dibangun di Azure DevOps. Grup produk memahami tantangan yang dihadapi pelanggan dan mitra dalam membangun arsitektur keamanan Azure DevOps, sehingga dua inisiatif berikut dapat membantu:
- Mendokumen arsitektur referensi
- Mengembangkan solusi baru, diumumkan di Ignite 2021, yang disebut "Repositori Microsoft Sentinel"
Untuk mendukung pemilihan solusi yang sesuai dengan kebutuhan tim Anda, tabel berikut membandingkan kriteria fungsi dan teknis.
| Kasus penggunaan dan fitur | Pendekatan kustom Azure DevOps dan GitHub | Repositori Microsoft Azure Sentinel |
|---|---|---|
| Kami ingin dengan cepat mulai menyebarkan artefak Microsoft Azure Sentinel tanpa menghabiskan waktu menentukan komponen arsitektur Azure DevOps, seperti agen, alur, Git, dasbor, wiki, perwakilan layanan, RBAC, audit, dan sebagainya. | Tidak direkomendasikan | Disarankan |
| Kami memiliki tim kecil dan set keterampilan rendah untuk mengelola alur CI/CD. | Tidak direkomendasikan | Disarankan |
| Kami ingin mengontrol dan mengelola semua aspek keamanan alur CI/CD. | Didukung | Tidak didukung |
| Kita perlu mengintegrasikan gerbang dan percabangan untuk mengawasi integrasi, sebelum memungkinkan pengembang untuk memicu alur penyebaran, seperti kontrol sumber, tinjauan pengkodian, putar kembali, persetujuan alur kerja, dan sebagainya. | Didukung | Didukung sebagian |
| Kami memiliki struktur Git atau repositori yang disesuaikan. | Didukung | Didukung |
| Kami tidak menggunakan bahasa Resource Manager atau Bicep IaC untuk membangun artefak. | Didukung | Tidak didukung |
| Kami ingin mengelola penyebaran artefak secara terpusat ke beberapa ruang kerja Microsoft Sentinel dalam satu penyewa Microsoft Entra. | Didukung | Didukung |
| Kami ingin mengintegrasikan atau memperluas alur CI/CD di beberapa penyewa Microsoft Entra. | Didukung | Didukung |
| Kami memiliki playbook dengan parameterisasi yang berbeda tergantung pada langganan, lokasi, lingkungan, dan sebagainya. | Didukung | TBD, panduan yang akan didokumenkan |
| Kami ingin mengintegrasikan artefak yang berbeda pada repositori yang sama untuk menyusun kasus penggunaan. | Didukung | Didukung |
| Kami ingin kemampuan untuk menghapus artefak secara massal. | Didukung | Tidak Didukung |
Ketersediaan, performa, dan skalabilitas
Saat memilih arsitektur untuk agen Azure DevOps di perusahaan Anda untuk skenario Microsoft Azure Sentinel, pertimbangkan kebutuhan berikut:
- Lingkungan produksi mungkin memerlukan kumpulan agen khusus untuk operasi melalui lingkungan Microsoft Azure Sentinel.
- Lingkungan non-produksi mungkin berbagi kumpulan agen dengan sejumlah besar instans untuk menangani berbagai tuntutan dari tim, khususnya, untuk praktik CI/CD.
- Skenario simulasi serangan adalah kasus khusus di mana agen khusus dapat diperlukan. Pertimbangkan apakah kumpulan khusus diperlukan untuk kebutuhan pengujian Anda.
- Organisasi yang bekerja pada skenario jaringan hibrid mungkin mempertimbangkan untuk mengintegrasikan agen di dalam jaringan.
Organisasi dapat membuat gambar mereka sendiri untuk agen berdasarkan kontainer. Untuk informasi selengkapnya, lihat Menjalankan agen yang dihost sendiri di Docker.
Manajemen lintas penyewa Microsoft Azure Sentinel dengan Azure DevOps
Sebagai SOC global atau MSSP, Anda mungkin harus mengelola beberapa penyewa. Azure Lighthouse mendukung operasi berskala di beberapa penyewa Microsoft Entra secara bersamaan, membuat tugas manajemen Anda lebih efisien. Untuk informasi selengkapnya, lihat Gambaran Umum Azure Lighthouse.
Manajemen lintas penyewa sangat efektif dalam skenario berikut:
- Mengelola sumber daya Microsoft Azure Sentinel di penyewa pelanggan.
- Lacak serangan dan lihat pemberitahuan keamanan di beberapa penyewa.
- Lihat insiden di beberapa ruang kerja Microsoft Azure Sentinel yang tersebar di seluruh penyewa.
Metode untuk onboarding pelanggan
Anda memiliki dua opsi untuk onboard pelanggan, penawaran layanan terkelola, dan templat ARM.
Onboarding manual menggunakan templat ARM
Jika Anda tidak ingin menerbitkan penawaran untuk Marketplace Azure sebagai penyedia layanan, atau Anda tidak memenuhi semua persyaratan, Anda dapat melakukan onboarding pelanggan secara manual dengan menggunakan templat ARM. Ini adalah opsi yang paling mungkin dalam skenario perusahaan, di mana perusahaan yang sama memiliki beberapa penyewa.
Tabel berikut membandingkan metode onboarding.
| Pertimbangan | Penawaran layanan terkelola | Templat ARM |
|---|---|---|
| Memerlukan akun Pusat Mitra | Ya | Tidak |
| Memerlukan tingkat kompetensi platform cloud Silver atau Gold atau status Azure Expert Managed Services Provider (MSP) | Ya | Tidak |
| Tersedia untuk pelanggan baru melalui Marketplace Azure | Ya | Tidak |
| Dapat membatasi penawaran untuk pelanggan tertentu | Ya (hanya dengan penawaran privat, yang tidak dapat digunakan dengan langganan yang dibuat melalui penjual program CSP) | Ya |
| Membutuhkan penerimaan pelanggan di portal Azure | Ya | Tidak |
| Dapat menggunakan otomasi untuk onboarding beberapa langganan, grup sumber daya, atau pelanggan | Tidak | Ya |
| Menyediakan akses langsung ke peran bawaan baru dan fitur Azure Lighthouse | Tidak selalu (umumnya tersedia setelah beberapa penundaan) | Ya |
Untuk informasi selengkapnya tentang menerbitkan penawaran layanan terkelola, lihat Menerbitkan penawaran layanan terkelola ke Marketplace Azure.
Untuk informasi selengkapnya tentang cara membuat templat ARM, lihat Membuat dan menyebarkan templat ARM.
Diagram berikut menunjukkan integrasi arsitektur tingkat tinggi antara penyewa MSSP dan penyewa penyedia sumber daya pelanggan dengan Azure Lighthouse dan Microsoft Sentinel.
Unduh file Visio arsitektur ini.
- Penawaran MSP terintegrasi melalui templat ARM atau penawaran layanan Marketplace Azure.
- Manajemen sumber daya yang didelegasikan Azure memeriksa bahwa permintaan berasal dari penyewa mitra dan memanggil penyedia sumber daya layanan terkelola.
- Penyedia sumber daya layanan terkelola menggunakan RBAC untuk mengontrol akses MSP.
- MSP menyelesaikan tindakan SecOps pada sumber daya pelanggan.
- Proses penagihan memperlakukan pengeluaran sebagai biaya pelanggan. Tagihan terpisah dimungkinkan jika entitas pelanggan memiliki ruang kerja terpisah di penyewa Microsoft Entra yang sama.
- Keamanan dan kedaulatan data tergantung pada batas penyewa pelanggan.
Identitas di beberapa penyewa
Untuk mengelola Microsoft Azure Sentinel dengan Azure DevOps, evaluasi keputusan desain berikut untuk komponen.
| Gunakan huruf besar | Pro |
|---|---|
| Identitas global untuk mengelola tindakan DevOps, perwakilan layanan tunggal | Kasus ini berlaku untuk proses penyebaran global, yang melibatkan semua penyewa. Menggunakan identitas terpadu memfasilitasi akses untuk penyewa yang berbeda tetapi dapat membuat proses pengelolaan tindakan persetujuan untuk penyewa tertentu menjadi kompleks. Mekanisme perlindungan dan model otorisasi untuk identitas semacam ini juga sangat penting, untuk menghindari penggunaan yang tidak sah yang disebabkan oleh dampak global terkait. |
| Identitas khusus untuk mengelola tindakan DevOps, beberapa perwakilan layanan | Kasus ini berlaku ketika proses penyebaran didedikasikan untuk setiap tindakan penyewa atau penyewa memerlukan persetujuan. Dalam hal ini, rekomendasi untuk melindungi dan mengotorisasi penggunaan identitas ini sama seperti dalam kasus global, bahkan ketika dampaknya berkurang. |
Organisasi repositori kode
| Gunakan huruf besar | Pro |
|---|---|
| Repositori terpadu dengan satu versi kode untuk semua penyewa | Kasus ini memfasilitasi memiliki versi terpadu untuk kode di repositori. Dalam hal ini, versi terpadu dari kode yang mengelola versi tertentu untuk penyewa dapat memerlukan dukungan atas cabang untuk setiap kasus. |
| Repositori terpadu dengan folder kode tertentu menurut penyewa | Kasus ini melengkapi kasus repositori tunggal. Di sini, struktur folder dapat membagi artefak khusus dengan penyewa. |
| Repositori khusus oleh penyewa | Pendekatan ini memberikan isolasi saat mengelola artefak kode. Ini membuat evolusi lebih mudah antara penyewa dengan tim atau persyaratan yang berbeda. Mengonsolidasikan perubahan memerlukan pembentukan proses antara repositori, yang mungkin memerlukan upaya untuk dipertahankan. |
Proses build dan deployment
| Gunakan huruf besar | Pro |
|---|---|
| Proses build tunggal untuk semua penyewa | Ketika semua penyewa bekerja dengan versi artefak yang sama, ini adalah opsi yang paling mudah untuk mengimplementasikan pembuatan dan paket. |
| Membangun proses oleh Penyewa | Versi kode yang berbeda disebarkan ke setiap penyewa. |
| Proses penyebaran global untuk semua Penyewa | Penyebaran dan pembaruan baru untuk penyebaran berlaku untuk semua penyewa. Langkah-langkah proses penyebaran dan pembaruan digunakan untuk semua penyewa. |
| Penyewa proses penyebaran global oleh penyewa | Penyebaran dan pembaruan baru untuk penyebaran berlaku untuk satu atau beberapa penyewa. |
| Proses penyebaran khusus oleh penyewa | Proses penyebaran disesuaikan untuk setiap penyewa. |
Pengoptimalan biaya
Pengoptimalan biaya adalah tentang mengurangi pengeluaran yang tidak perlu dan meningkatkan efisiensi operasional. Untuk informasi selengkapnya, lihat Gambaran umum pilar pengoptimalan biaya.
Biaya solusi tergantung pada faktor-faktor berikut:
- Volume data yang disalurkan perusahaan Anda ke ruang kerja Analitik Log Microsoft Sentinel setiap bulan
- Tingkat komitmen atau metode penagihan yang Anda pilih, seperti bayar sesuai pemakaian (PAYG)
- Tingkat retensi kebijakan data pada tabel atau tingkat global
Untuk informasi selengkapnya, lihat Retensi jenis data Azure.
Untuk menghitung harga, lihat kalkulator harga Microsoft Azure Sentinel. Untuk informasi selengkapnya tentang pertimbangan dan contoh harga tingkat lanjut, lihat Merencanakan biaya untuk Microsoft Azure Sentinel..
Anda dapat dikenakan biaya tambahan jika Anda memperluas solusi dengan komponen berikut:
- Playbook - runtime untuk Azure Logic Apps dan Azure Functions. Untuk informasi selengkapnya, lihat Detail harga.
- Mengekspor ke penyimpanan eksternal seperti Azure Data Explorer, Azure Event Hubs, atau akun Azure Storage.
- Ruang kerja pembelajaran mesin dan komputasi yang digunakan komponen Jupyter Notebook.
Menyebarkan skenario ini
Bagian berikut menjelaskan langkah-langkah untuk menyebarkan skenario ini dalam bentuk kasus penggunaan sampel yang mencakup berbagai proses DevOps.
Membangun dan merilis kerangka kerja Microsoft Azure Sentinel
Pertama, siapkan komponen NuGet yang diperlukan dalam repositori khusus di mana proses yang berbeda dapat menggunakan rilis yang Anda hasilkan.
Jika Anda bekerja dengan Azure DevOps, Anda dapat membuat umpan komponen untuk menghosting paket NuGet yang berbeda dari kerangka kerja Microsoft Sentinel untuk PowerShell. Untuk informasi selengkapnya, lihat Mulai menggunakan paket NuGet.
Jika tim Anda memilih registri GitHub, Anda dapat menghubungkannya sebagai repositori NuGet, karena kompatibel dengan protokol umpan. Untuk informasi selengkapnya, lihat Pengenalan paket GitHub.
Ketika Anda memiliki repositori NuGet yang tersedia, alur berisi koneksi layanan untuk NuGet. Cuplikan layar ini menunjukkan konfigurasi untuk koneksi layanan baru yang bernama Microsoft Sentinel NuGet Framework Koneksi ion.
Setelah mengonfigurasi umpan, Anda dapat mengimpor alur untuk membangun kerangka kerja PowerShell langsung dari GitHub di fork tertentu. Untuk informasi selengkapnya, lihat Membangun repositori GitHub. Dalam hal ini, Anda membuat alur baru dan memilih GitHub sebagai sumber kode.
Opsi lain adalah mengimpor repositori Git sebagai repositori Azure DevOps yang didasarkan pada Git. Dalam kedua kasus, untuk mengimpor alur, tentukan jalur berikut:
src/Build/Framework/ADO/Microsoft.Sentinel.Framework.Build.yml
Sekarang Anda dapat menjalankan alur untuk pertama kalinya. Kemudian, kerangka kerja membangun dan merilis ke umpan NuGet.
Menentukan lingkungan Microsoft Azure Sentinel Anda
Saat dimulai dengan Microsoft Sentinel dan menggunakan sampel ini, tentukan lingkungan di perusahaan Anda, misalnya, Lingkungan sebagai Kode atau EaC. Anda menentukan berbagai elemen yang membentuk lingkungan dalam setiap kasus.
Arsitektur Microsoft Azure Sentinel menyertakan elemen berikut di Azure:
- Ruang Kerja Analitik Log - Ruang kerja ini membentuk fondasi solusi. Informasi terkait keamanan disimpan di sini dan ruang kerja adalah mesin untuk Bahasa Kueri Kusto (KQL).
- Solusi Microsoft Azure Sentinel melalui ruang kerja Analitik Log - Solusi ini memperluas fungsionalitas ruang kerja Analitik Log untuk menyertakan kemampuan SIEM dan SOAR.
- Key Vault - Brankas kunci menyimpan rahasia dan kunci yang digunakan selama proses remediasi.
- Akun Automation - Akun ini bersifat opsional dan digunakan untuk proses remediasi. Proses remediasi yang Anda gunakan didasarkan pada runbook PowerShell dan Python. Proses ini mencakup identitas yang dikelola sistem yang bekerja dengan sumber daya yang berbeda sesuai dengan praktik terbaik.
- Identitas yang dikelola pengguna - Fitur ini bertindak sebagai lapisan identitas terpadu Microsoft Azure Sentinel yang mengelola interaksi antara playbook dan runbook Microsoft Azure Sentinel.
- Koneksi Aplikasi Logika - Ini adalah koneksi untuk Microsoft Sentinel, brankas kunci, dan otomatisasi yang menggunakan identitas yang dikelola pengguna.
- Koneksi Aplikasi Logika Eksternal - Ini adalah koneksi untuk sumber daya eksternal yang terlibat dalam proses remediasi dan yang didasarkan pada playbook.
- Azure Event Hubs - Fitur ini bersifat opsional dan menangani integrasi antara Microsoft Sentinel dan solusi lainnya, seperti Splunk, Azure Databricks, dan pembelajaran mesin, dan Tangguh.
- Akun penyimpanan - Fitur ini bersifat opsional dan menangani integrasi antara Microsoft Sentinel dan solusi lainnya, seperti Splunk, Azure Databricks, dan pembelajaran mesin, dan Tangguh.
Dengan menggunakan contoh dari repositori, Anda dapat menentukan lingkungan dengan file JSON untuk menentukan konsep logis yang berbeda. Opsi yang tersedia untuk menentukan lingkungan bisa harfiah atau otomatis.
Dalam definisi harfiah, Anda menentukan nama dan elemen untuk setiap sumber daya di lingkungan seperti yang ditunjukkan dalam contoh ini.
{
{
"SubscriptionId": "<subscription-identifier-associated-with-service-connection>",
"Name": "<environment-name>",
"NamingConvention": "<naming-convention-template-for-automatic-cases>",
"Location": "<environment-location>",
"ResourceGroup": {
"Type": "Literal",
"ResourceGroupName": "<resource-group-name>"
}
},
"Resources":
{
"Sentinel":
{
"Type": "Literal",
"LogAnalyticsWorkspaceName": "<Log-Analytics-workspace-name>",
"ManagedIdentityName": "<user-managed-identity-name>",
"SentinelConnectionName": "<Sentinel-API-connection-name>",
"KeyVaultName": "<Key-Vault-name>",
"KeyVaultConnectionName": "<Key-Vault-API-connection-name>"
},
"Automation":
{
"Type": "Literal",
"AutomationAccountName": "<automation-account-name>",
"AutomationAccountConnectionName": "<automation-account-API-connection-name>"
},
"Integration":
{
"Type": "Literal",
"EventHubNamespaces": [
"<Event-Hubs-namespace-1-name>",
"<Event-Hubs-namespace-2-name>",
"<Event-Hubs-namespace-3-name>",
"<Event-Hubs-namespace-4-name>",
"<Event-Hubs-namespace-5-name>",
"<Event-Hubs-namespace-6-name>",
"<Event-Hubs-namespace-7-name>",
"<Event-Hubs-namespace-8-name>",
"<Event-Hubs-namespace-9-name>",
"<Event-Hubs-namespace-10-name>",
],
"StorageAccountName": "<storage-account-name>"
}
}
}
Dalam definisi otomatis, nama elemen dihasilkan secara otomatis berdasarkan konvensi penamaan, seperti yang ditunjukkan dalam contoh ini.
{
{
"SubscriptionId": "<subscription-identifier-associated-with-service-connection>",
"Name": "<environment-name>",
"NamingConvention": "<naming-convention-template-for-automatic-cases>",
"Location": "<environment-location>",
"ResourceGroup": {
"Type": "Automatic"
}
},
"Resources":
{
"Sentinel":
{
"Type": "Automatic"
},
"Automation":
{
"Type": "Automatic"
},
"Integration":
{
"Type": "Automatic",
"MaxEventHubNamespaces": 5
}
}
}
Anda dapat menemukan sampel di repositori GitHub di bawah jalur lingkungan Microsoft Sentinel dan menggunakan sampel sebagai referensi dalam menyiapkan kasus penggunaan Anda.
Menyebarkan lingkungan Microsoft Azure Sentinel Anda
Ketika Anda memiliki setidaknya satu lingkungan yang ditentukan, Anda dapat membuat koneksi layanan Azure untuk diintegrasikan dengan Azure DevOps. Setelah Anda membuat koneksi layanan, atur perwakilan layanan tertaut ke peran pemilik atau tingkat izin serupa di atas langganan target.
Impor alur untuk membuat lingkungan baru seperti yang didefinisikan dalam file ini.
src/Release/Sentinel Deployment/ADO/Microsoft.Sentinel.Environment.Deployment.ymlSelanjutnya, masukkan nama koneksi layanan yang mewakili lingkungan.
Pilih cabang untuk definisi lingkungan di repositori.
Masukkan nama koneksi layanan Azure DevOps untuk langganan Anda di kotak azure Environment Koneksi ion.
Masukkan nama lingkungan yang dapat digunakan koneksi layanan untuk mengatasi beberapa lingkungan dalam langganan yang sama.
Pilih tindakan yang akan diterapkan ke konektor.
Pilih Gunakan Artefak Pra-Rilis PowerShell jika Anda ingin menggunakan versi prarilis komponen kerangka kerja PowerShell.
Alur mencakup langkah-langkah berikut sebagai bagian dari alur penyebaran:
- Menyebarkan komponen NuGet.
- Koneksi dengan menggunakan alat NuGet dengan repositori artefak.
- Atasi umpan.
- Instal modul yang diperlukan.
- Dapatkan definisi lingkungan.
- Validasi sumber daya mana yang ada di tujuan.
- Tambahkan Analitik Log dan Microsoft Azure Sentinel jika tidak berada di ruang kerja.
- Jika Anda sudah memiliki Analitik Log, tambahkan Microsoft Azure Sentinel melalui instans Log Analytics Anda.
- Buat identitas terkelola untuk mewakili interaksi antara Microsoft Sentinel dan Logic Apps.
- Buat Azure Key Vault dan atur penetapan peran untuk mengelola rahasia dan kunci ke identitas terkelola.
- Jika berlaku, buat akun Azure Automation dan aktifkan identitas terkelola yang ditetapkan sistem.
- Atur penetapan peran di atas brankas kunci untuk identitas terkelola yang ditetapkan sistem.
- Buat definisi Azure Event Hubs jika tidak ada dan atur apakah definisi menyertakan elemen integrasi.
- Atur penetapan peran di atas brankas kunci untuk identitas terkelola yang ditetapkan sistem.
- Buat definisi akun penyimpanan jika tidak ada dan atur apakah definisi menyertakan elemen integrasi.
- Atur penetapan peran di atas brankas kunci untuk identitas terkelola yang ditetapkan sistem.
- Menyebarkan tindakan konektor.
- Sebarkan runbook integrasi di akun Automation.
- Sebarkan koneksi Logic Apps jika didefinisikan sebagai bagian dari lingkungan.
Menghancurkan lingkungan Microsoft Azure Sentinel
Ketika lingkungan tidak lagi diperlukan, seperti dalam kasus lingkungan pengembangan atau pengujian, Anda dapat menghancurkannya seperti yang didefinisikan dalam file ini.
src/Release/Sentinel Deployment/ADO/Microsoft.Sentinel.Environment.Destroy.yml
Seperti saat Anda menyebarkan alur lingkungan, Anda menentukan nama koneksi layanan yang mewakili lingkungan.
Bekerja dengan lingkungan Microsoft Azure Sentinel Anda
Setelah lingkungan Anda siap, Anda dapat mulai membuat artefak untuk menyiapkan berbagai kasus penggunaan.
Ekspor artefak dari lingkungan yang sedang Anda kerjakan seperti yang didefinisikan dalam file ini.
src/Release/Artifacts Deployment/ADO/Microsoft.Sentinel.Artifacts.Export.ymlPilih cabang untuk definisi lingkungan di repositori.
Masukkan nama koneksi layanan Azure DevOps untuk lingkungan yang sedang diekspor di kotak Koneksi ion Lingkungan Azure.
Pilih Gunakan Artefak Pra-Rilis PowerShell jika Anda ingin menggunakan versi prarilis komponen kerangka kerja PowerShell.
Pilih format untuk aturan analitik dan perburuan.
File output artefak tersedia dalam hasil. Setelah memiliki artefak, Anda dapat menyertakan file output di repositori Git.
Membangun artefak Anda di lingkungan Microsoft Azure Sentinel
Tempatkan artefak Anda di bawah jalur kasus penggunaan MITRE Microsoft Sentinel. Siapkan struktur folder Anda sesuai dengan berbagai jenis artefak.
Mulai proses build seperti yang didefinisikan dalam file ini.
src/Build/Artifacts/ADO/Microsoft.Sentinel.Artifacts.Build.yamlPilih cabang untuk definisi lingkungan di repositori.
Diagram cara memilih cabang untuk membangun artefak.] (./media/build-artifacts-pipeline.png)
Pilih Gunakan Artefak Pra-Rilis PowerShell jika Anda ingin menggunakan versi prarilis komponen kerangka kerja PowerShell.
Alur terdiri dari langkah-langkah berikut:
- Menyebarkan komponen NuGet.
- Koneksi alat NuGet ke repositori artefak.
- Atasi umpan.
- Instal modul yang diperlukan.
- Dapatkan kerangka kerja Toolkit Pengujian untuk memvalidasi templat ARM.
- Validasi templat ARM.
- Validasi kode PowerShell Runbooks dan lakukan validasi sintaks.
- Jalankan pengujian unit Pester jika berlaku.
- Validasi sintaks KQL dalam aturan berburu dan analitik.
Menyebarkan artefak Anda ke lingkungan Microsoft Azure Sentinel
Dalam menyebarkan artefak, Anda dapat menggunakan repositori Microsoft Azure Sentinel atau sampel alur penyebaran pada repositori ini. Untuk informasi selengkapnya, lihat Menyebarkan konten khusus dari repositori Anda.
Repositori Microsoft Azure Sentinel
Jika Anda menggunakan repositori Microsoft Azure Sentinel, Anda dapat menyiapkan proses rilis untuk menyertakan artefak dalam repositori yang terhubung ke setiap instans Microsoft Azure Sentinel. Setelah artefak diterapkan di repositori, beberapa langkah secara otomatis dilakukan sebagai bagian dari pembuatan alur dan mengaktifkan repositori Microsoft Azure Sentinel.
Selain itu, Anda dapat menyesuaikan proses penyebaran yang dilakukan repositori Microsoft Sentinel berdasarkan praktik yang dijelaskan dalam dokumen ini. Salah satu aspek penting yang perlu dipertimbangkan adalah persetujuan rilis, yang dapat Anda siapkan dengan mengikuti pendekatan ini:
- Persetujuan PR saat melakukan artefak. Untuk informasi selengkapnya, lihat Membuat permintaan pull.
- Rilis persetujuan alur saat menjalankan penyebaran. Untuk informasi selengkapnya, lihat Menentukan persetujuan dan pemeriksaan.
Sampel alur penyebaran Microsoft Azure Sentinel
Dengan menggunakan sampel alur penyebaran Microsoft Azure Sentinel, Anda dapat menyiapkan proses rilis.
Siapkan proses rilis Anda seperti yang didefinisikan dalam file ini.
src/Release/Artifacts Deployment/ADO/Microsoft.Sentinel.Artifacts.Deployment.ymlPilih cabang untuk definisi lingkungan di repositori.
Masukkan nama koneksi layanan Azure DevOps untuk lingkungan yang sedang diekspor di kotak Koneksi ion Lingkungan Azure.
Pilih Gunakan Artefak Pra-Rilis PowerShell jika Anda ingin menggunakan versi prarilis komponen kerangka kerja PowerShell.
Kontributor
Artikel ini dikelola oleh Microsoft. Ini awalnya ditulis oleh kontributor berikut.
Penulis utama:
- Kevin Kisoka | Mengaitkan Arsitek
Untuk melihat profil LinkedIn non-publik, masuk ke LinkedIn.
Langkah berikutnya
- Untuk mempelajari tentang Microsoft Azure Sentinel dengan DevOps untuk arsitektur penyewa tunggal, lihat Menyebarkan dan mengelola Microsoft Sentinel sebagai kode.
- Untuk mempelajari tentang arsitektur multi-penyewa MSSP, lihat Menggabungkan Azure Lighthouse dengan kemampuan DevOps Microsoft Sentinel.
- Untuk informasi tentang Identitas terkelola dengan Microsoft Sentinel, lihat Apa yang baru: Identitas terkelola untuk konektor Microsoft Azure Sentinel Logic Apps.
- Untuk mempelajari cara menyebarkan konten dari repositori Microsoft Azure Sentinel, lihat Menyebarkan konten kustom dari repositori Anda.
- Untuk mempelajari tentang pertimbangan Keamanan Azure DevOps, lihat Referensi cepat izin default.
- Untuk mempelajari cara melindungi repositori Azure DevOps, lihat Menambahkan perlindungan ke sumber daya repositori.
- Untuk informasi tentang cara mengelola keamanan koneksi layanan Azure DevOps, lihat Koneksi layanan di Azure Pipelines.