Mendesain arsitektur ruang kerja Microsoft Sentinel Anda

Artikel ini menyediakan pohon keputusan untuk membantu Anda membuat keputusan penting tentang cara merancang arsitektur ruang kerja Microsoft Sentinel Anda. Untuk mengetahui informasi selengkapnya, lihat, Rancangan ruang kerja sampel Microsoft Sentinel dan Praktik terbaik arsitektur ruang kerja Microsoft Sentinel. Artikel ini adalah bagian dari panduan Penyebaran untuk Microsoft Azure Sentinel.

Prasyarat

Sebelum bekerja melalui pohon keputusan, pastikan Anda memiliki informasi berikut:

Prasyarat	Deskripsi
Persyaratan peraturan yang terkait dengan residensi data Azure	Microsoft Sentinel dapat berjalan di sebagian besar ruang kerja, tetapi tidak semua wilayah yang didukung di GA untuk Analitik Log. Wilayah Analitik Log yang baru didukung mungkin membutuhkan waktu untuk onboarding layanan Microsoft Azure Sentinel. Data yang dihasilkan oleh Microsoft Azure Sentinel, seperti insiden, marka buku, dan aturan analitik, mungkin berisi beberapa data pelanggan yang bersumber dari ruang kerja Analitik Log pelanggan. Untuk informasi selengkapnya, lihat Ketersediaan wilayah dan residensi data.
Sumber data	Cari tahu sumber data mana yang perlu Anda sambungkan, termasuk konektor bawaan ke solusi Microsoft dan non-Microsoft. Anda juga dapat menggunakan Common Event Format (CEF), Syslog atau REST-API untuk menghubungkan sumber data Anda dengan Microsoft Sentinel. Jika Anda memiliki VM Azure di beberapa lokasi Azure tempat Anda mengambil log dari dan penghematan biaya data keluar adalah hal yang penting bagi Anda, Anda perlu menghitung biaya data keluar menggunakan Kalkulator harga bandwidth untuk setiap lokasi Azure.
Peran pengguna dan tingkat/izin akses data	Microsoft Sentinel menggunakan kontrol akses berbasis peran Azure (Azure RBAC) untuk menyediakan peran bawaan yang dapat ditetapkan ke pengguna, grup, dan layanan di Azure. Semua peran bawaan Microsoft Azure Sentinel memberikan akses baca ke data di ruang kerja Microsoft Azure Sentinel Anda. Oleh karena itu, Anda perlu mencari tahu apakah ada kebutuhan untuk mengontrol akses data per sumber data atau tingkat baris karena itu akan berdampak pada keputusan desain ruang kerja. Untuk informasi selengkapnya, lihat Peran kustom dan Azure RBAC tingkat lanjut.
Tingkat penyerapan harian	Tingkat konsumsi harian, biasanya dalam GB/hari, adalah salah satu faktor kunci dalam pengelolaan biaya dan pertimbangan perencanaan serta rancangan ruang kerja untuk Microsoft Sentinel. Di sebagian besar lingkungan cloud dan hibrida, perangkat jaringan, seperti firewall atau proksi, dan server Windows juga Linux menghasilkan paling banyak data yang terserap. Untuk mendapatkan hasil yang paling akurat, Microsoft merekomendasikan inventaris lengkap sumber data. Atau, kalkulator biaya Microsoft Sentinel mencakup tabel yang berguna dalam memperkirakan jejak sumber data. Penting: Perkiraan ini adalah titik awal, dan pengaturan verbositas log dan beban kerja akan menghasilkan varian. Disarankan agar Anda memantau sistem Anda secara berkala untuk melacak perubahan apa pun. Pemantauan rutin direkomendasikan berdasarkan skenario Anda. Untuk informasi selengkapnya, lihat detail harga Log Azure Monitor.

Hierarki keputusan

Gambar berikut menunjukkan bagan lengkap alur pohon keputusan untuk membantu Anda memahami cara terbaik mendesain ruang kerja Anda.

Bagian berikut menyediakan versi teks lengkap dari pohon keputusan ini, termasuk catatan berikut yang dirujuk dari gambar:

Catatan #1 | Catatan #2 | Catatan #3 | Catatan #4 | Catatan #5 | Catatan #6 | Catatan #7 | Catatan #8 | Catatan #9 | Catatan #10

Langkah 1: Ruang kerja baru atau yang sudah ada?

Apakah Anda memiliki ruang kerja yang sudah ada yang dapat digunakan untuk Microsoft Sentinel?

• Jika tidak, dan Anda akan membuat ruang kerja baru dalam kasus apa pun, langsung lanjutkan dengan langkah 2.

• Jika Anda memiliki ruang kerja yang sudah ada yang mungkin Anda gunakan, pertimbangkan berapa banyak data yang akan Anda serap.

  • Jika Anda akan menyerap lebih dari 100 GB / hari, disarankan agar Anda menggunakan ruang kerja terpisah demi efisiensi biaya.

  • Jika Anda akan menyerap kurang dari 100 GB / hari, lanjutkan dengan langkah 2 untuk evaluasi lebih lanjut. Pertimbangkan pertanyaan ini lagi saat muncul di langkah 5.

Langkah 2: Menyimpan data di geografi Azure yang berbeda?

• Jika Anda memiliki persyaratan peraturan untuk menyimpan data di geografi Azure yang berbeda, gunakan ruang kerja Microsoft Sentinel terpisah untuk setiap wilayah Azure yang memiliki persyaratan kepatuhan. Untuk informasi selengkapnya, lihat Pertimbangan wilayah.

• Jika Anda tidak perlu menyimpan data di geografi Azure yang berbeda, lanjutkan dengan langkah 3.

Langkah 3: Apakah Anda memiliki beberapa penyewa Azure?

• Jika Anda hanya memiliki satu penyewa, langsung lanjutkan dengan langkah 4.

• Jika Anda memiliki beberapa penyewa Azure, pertimbangkan apakah Anda mengumpulkan log yang khusus untuk batas penyewa, seperti Office 365 atau Microsoft Defender XDR.

  • Jika Anda tidak memiliki log khusus penyewa, langsung lanjutkan dengan langkah 4.

  • Jika Anda mengumpulkan log khusus penyewa, gunakan ruang kerja Microsoft Sentinel terpisah untuk setiap penyewa Microsoft Entra. Lanjutkan dengan langkah 4 untuk pertimbangan lain.

    Catatan pohon keputusan #1: Log khusus untuk batas penyewa, seperti dari Office 365 dan Pertahanan Microsoft untuk Cloud, hanya dapat disimpan di ruang kerja dalam penyewa yang sama.

    Meskipun dimungkinkan untuk menggunakan kolektor kustom untuk mengumpulkan log khusus penyewa dari ruang kerja di penyewa lain, kami tidak merekomendasikan ini karena kerugian berikut:

    • Data yang dikumpulkan oleh konektor kustom akan diserap ke dalam tabel kustom. Oleh karena itu, Anda tidak akan dapat menggunakan semua aturan dan buku kerja bawaan.
    • Tabel kustom tidak dipertimbangkan oleh beberapa fitur bawaan, seperti UEBA dan aturan pembelajaran mesin.
    • Biaya dan upaya tambahan yang diperlukan untuk konektor khusus, seperti menggunakan Azure Functions dan Logic Apps.

    Jika kerugian ini tidak menjadi perhatian organisasi Anda, lanjutkan dengan langkah 4 alih-alih menggunakan ruang kerja Microsoft Azure Sentinel terpisah.

Langkah 4: Membagi penagihan / menarik pembayaran?

Jika Anda perlu membagi tagihan atau menarik pembayaran, pertimbangkan apakah pelaporan penggunaan atau biaya silang manual sesuai bagi Anda.

• Jika Anda tidak perlu membagi tagihan atau menarik pembayaran, lanjutkan dengan langkah 5.

• Jika Anda perlu membagi tagihan atau penagihan balik, pertimbangkan untuk menggunakan biaya silang manual. Untuk mendapatkan biaya yang akurat per entitas, Anda dapat menggunakan versi buku kerja Biaya Microsoft Sentinel yang dimodifikasi yang memecah biaya menurut entitas.

  • Jika pelaporan penggunaan atau biaya silang manual sesuai untuk Anda, lanjutkan dengan langkah 5.

  • Jika pelaporan penggunaan dan biaya silang manual tidak sesuai untuk Anda, gunakan ruang kerja Microsoft Sentinel yang terpisah untuk setiap pemilik.

  Catatan pohon keputusan #2: Untuk mengetahui informasi selengkapnya, lihat Biaya dan tagihan Microsoft Sentinel.

Langkah 5: Mengumpulkan data non-SOC?

• Jika Anda tidak mengumpulkan data non-SOC, seperti data operasional, Anda dapat langsung melompat ke langkah 6.

• Jika Andaakan mengumpulkan data non-SOC, pertimbangkan apakah ada yang tumpang tindih, di mana sumber data yang sama diperlukan untuk data SOC dan non-SOC.

  Jika ada tumpang tindih antara data SOC dan non-SOC, perlakukan data tumpang tindih seperti data SOC saja. Kemudian, pertimbangkan apakah penyerapan untuk kedua data SOC dan non-SOC secara individual kurang dari 100 GB / hari, tetapi lebih dari 100 GB / hari bila digabungkan:

  • Ya: Lanjutkan dengan langkah 6 untuk evaluasi lebih lanjut.
  • Tidak: Kami tidak merekomendasikan penggunaan ruang kerja yang sama demi efisiensi biaya. Lanjutkan dengan langkah 6 untuk evaluasi lebih lanjut.

  Di kasus mana pun, untuk informasi selengkapnya, lihat catatan 10.

  Jika Anda tidak memiliki data yang tumpang tindih, pertimbangkan apakah penyerapan untuk kedua data SOC dan non-SOC masing-masing kurang 100 GB / hari, tetapi lebih dari 100 GB / hari jika digabungkan:

  • Ya: Lanjutkan dengan langkah 6 untuk evaluasi lebih lanjut. Untuk informasi selengkapnya, lihat catatan 3.
  • Tidak: Kami tidak merekomendasikan penggunaan ruang kerja yang sama demi efisiensi biaya. Lanjutkan dengan langkah 6 untuk evaluasi lebih lanjut.

Menggabungkan data SOC dan non-SOC Anda

Catatan pohon keputusan #3: Meskipun kami umumnya menyarankan agar pelanggan menyimpan ruang kerja terpisah untuk data non-SOC mereka sehingga data non-SOC tidak dikenakan biaya Microsoft Azure Sentinel, mungkin ada situasi di mana menggabungkan data SOC dan non-SOC lebih murah daripada memisahkannya.

Misalnya, anggap sebuah organisasi yang memiliki log keamanan yang menyerap 50 GB/hari, log operasi menelan pada 50 GB/hari, dan ruang kerja di wilayah US Timur.

Tabel berikut membandingkan opsi ruang kerja dengan dan tanpa ruang kerja terpisah.

Catatan

Biaya dan istilah yang tercantum dalam tabel berikut adalah palsu, dan digunakan hanya untuk tujuan ilustrasi. Untuk informasi biaya terbaru, lihat kalkulator harga Microsoft Sentinel.

Arsitektur ruang kerja	Deskripsi
Tim SOC memiliki ruang kerja sendiri, dengan Microsoft Sentinel yang diaktifkan. Tim Ops memiliki ruang kerja sendiri, tanpa Microsoft Sentinel yang diaktifkan.	Tim SOC: Biaya Microsoft Sentinel untuk 50GB/hari adalah $6.500 per bulan. Tiga bulan pertama retensi gratis. Tim operasional: - Biaya Analitik Log pada 50GB/hari adalah sekitar $3.500 per bulan. - 31 hari pertama retensi gratis. Total biaya untuk keduanya sama dengan $10.000 per bulan.
Tim SOC dan Ops berbagi ruang kerja yang sama dengan Microsoft Sentinel yang diaktifkan.	Dengan menggabungkan kedua log, konsumsi akan menjadi 100 GB/hari, memenuhi syarat untuk kelayakan untuk Commitment Tier (50% untuk Sentinel dan 15% untuk LA). Biaya Microsoft Sentinel untuk 100 GB/hari sama dengan $9.000 per bulan.

Dalam contoh ini, Anda akan memiliki penghematan biaya sebesar $1.000 per bulan dengan menggabungkan kedua ruang kerja, dan tim Ops juga akan menikmati 3 bulan retensi gratis, bukan hanya 31 hari.

Contoh ini hanya relevan saat data baik SOC dan non-SOC masing-masing memiliki ukuran penyerapan >=50 GB/hari dan <100GB/hari.

Catatan pohon keputusan #10: Direkomendasikan untuk menggunakan ruang kerja terpisah untuk data non-SOC sehingga data non-SOC tidak dikenakan biaya Microsoft Sentinel.

Namun, rekomendasi ini untuk ruang kerja terpisah untuk data non-SOC berasal dari perspektif berbasis biaya murni, dan ada faktor desain penting lainnya yang perlu diperiksa ketika menentukan apakah akan menggunakan satu atau beberapa ruang kerja. Untuk menghindari biaya penyerapan ganda, pertimbangkan untuk mengumpulkan data yang tumpang tindih pada satu ruang kerja hanya dengan RBAC Azure tingkat tabel.

Langkah 6: Beberapa wilayah?

• Jika Anda mengumpulkan log dari VM Azure hanya di satu wilayah, langsung lanjutkan dengan langkah 7.

• Jika Anda mengumpulkan log dari VM Azure di beberapa wilayah, seberapa cemas Anda akan biaya data keluar?

  Catatan pohon keputusan #4: Data keluar merujuk ke biaya bandwith untuk memindahkan data keluar dari pusat data Azure. Untuk informasi selengkapnya, lihat Pertimbangan wilayah.

  • Jika mengurangi jumlah upaya yang diperlukan untuk mempertahankan ruang kerja terpisah adalah prioritas, lanjutkan dengan langkah 7.

  • Jika biaya keluar data cukup menjadi perhatian untuk mempertahankan ruang kerja terpisah, gunakan ruang kerja Microsoft Sentinel terpisah untuk setiap wilayah tempat Anda perlu mengurangi biaya data keluar.

    Catatan pohon keputusan #5: Kami sarankan Anda memiliki ruang kerja sesedikit mungkin. Gunakan kalkulator harga Azure untuk memperkirakan biaya dan menentukan wilayah mana yang benar-benar Anda butuhkan, dan gabungkan ruang kerja untuk wilayah dengan biaya keluar rendah. Biaya bandwidth mungkin hanya sebagian kecil dari tagihan Azure Anda jika dibandingkan dengan biaya penyerapan Microsoft Azure Sentinel dan Analitik Log terpisah.

    Misalnya, biaya Anda dapat diperkirakan sebagai berikut:

    • 1.000 VM, masing-masing menghasilkan 1 GB/hari;
    • Mengirim data dari wilayah AS ke wilayah Eropa;
    • Menggunakan tingkat pemadatan 2:1 di agen

    Perhitungan untuk perkiraan biaya ini adalah: 1000 VMs * (1GB/day ÷ 2) * 30 days/month * $0.05/GB = $750/month bandwidth cost

    Biaya sampel ini akan jauh lebih murah jika dibandingkan dengan biaya bulanan ruang kerja Microsoft Sentinel dan Analitik Log yang terpisah.

    Catatan

    Biaya yang tercantum adalah palsu dan hanya digunakan untuk tujuan ilustrasi. Untuk informasi biaya terbaru, lihat kalkulator harga Microsoft Sentinel.

Langkah 7: Memisahkan data atau menentukan batas-batas berdasarkan kepemilikan?

• Jika Anda tidak perlu memisahkan data atau menentukan batas kepemilikan, langsung lanjutkan dengan langkah 8.

• Jika Anda perlu memisahkan data atau menentukan batas kepemilikan, apakah masing-masing pemilik data perlu menggunakan portal Microsoft Sentinel?

  • Jika setiap pemilik data harus memiliki akses ke portal Microsoft Sentinel, gunakan ruang kerja Microsoft Sentinel yang terpisah untuk setiap pemilik.

    Catatan pohon keputusan #6: Akses ke portal Microsoft Sentinel mengharuskan setiap pengguna memiliki setidaknya peran Pembaca Microsoft Sentinel, dengan izin Pembaca pada semua tabel di ruang kerja. Jika pengguna tidak memiliki akses ke semua tabel di ruang kerja, mereka harus menggunakan Analitik Log untuk mengakses log dalam kueri pencarian.

  • Jika akses ke log melalui Analitik Log cukup untuk setiap pemilik tanpa akses ke portal Microsoft Sentinel, lanjutkan dengan langkah 8.

  Untuk informasi selengkapnya, lihat Izin di Microsoft Azure Sentinel.

Langkah 8: Mengontrol akses data berdasarkan tabel / sumber data?

• Jika Anda tidak perlu mengontrol akses data berdasarkan sumber atau tabel, gunakan ruang kerja Microsoft Sentinel tunggal.

• Jika Anda perlu mengontrol data berdasarkan sumber atau tabel, pertimbangkan menggunakan RBAC dengan konteks sumber daya dalam situasi berikut:

  • Jika Anda perlu mengontrol akses di tingkat baris, seperti menyediakan beberapa pemilik pada setiap sumber data atau tabel

  • Jika Anda memiliki beberapa, tabel/sumber data kustom, di mana masing-masing membutuhkan izin terpisah

  Dalam kasus lain, ketika Anda tidak perlu mengontrol akses di tingkat baris, berikan beberapa sumber/tabel data kustom dengan izin terpisah, gunakan satu ruang kerja Microsoft Azure Sentinel, dengan RBAC tingkat tabel untuk kontrol akses data.

Pertimbangan untuk RBAC konteks sumber daya atau tingkat tabel

Saat berencana untuk menggunakan RBAC tingkat tabel atau konteks sumber daya, pertimbangkan hal berikut:

• Catatan pohon keputusan #7: Untuk mengonfigurasi RBAC konteks sumber daya untuk sumber daya non-Azure, Anda mungkin ingin mengaitkan ID Sumber Daya ke data saat mengirim ke Microsoft Azure Sentinel, sehingga izin dapat dilingkup menggunakan RBAC konteks sumber daya. Untuk informasi selengkapnya, lihat Mengonfigurasi RBAC konteks sumber daya secara eksplisit dan Mode akses berdasarkan penyebaran.

• Catatan pohon keputusan 8: Izin sumber daya or konteks sumber daya memungkinkan pengguna untuk melihat log saja untuk sumber daya yang mereka miliki aksesnya. Mode akses ruang kerja harus diatur ke Sumber daya pengguna atau izin ruang kerja. Hanya tabel yang relevan dengan sumber daya tempat pengguna memiliki izin yang akan disertakan dalam hasil pencarian dari halaman Log di Microsoft Sentinel.

• Catatan pohon keputusan #9: RBAC Tingkat Tabel memungkinkan Anda menentukan kontrol yang lebih terperinci terhadap data di ruang kerja Analitik Log selain izin lainnya. Kontrol ini memungkinkan Anda menentukan jenis data tertentu yang hanya dapat diakses oleh sekumpulan pengguna tertentu. Untuk mengetahui informasi selengkapnya, lihat RBAC tingkat tabel di Microsoft Sentinel.

Langkah berikutnya

Dalam artikel ini, Anda meninjau pohon keputusan untuk membantu Anda membuat keputusan utama tentang cara merancang arsitektur ruang kerja Microsoft Azure Sentinel Anda.

Sampel desain ruang kerja Microsoft Sentinel