Catatan
Akses ke halaman ini memerlukan otorisasi. Anda dapat mencoba masuk atau mengubah direktori.
Akses ke halaman ini memerlukan otorisasi. Anda dapat mencoba mengubah direktori.
Artikel ini menyediakan praktik terbaik untuk mempertahankan keandalan dan keamanan estat cloud Azure Anda. Keandalan memastikan layanan cloud Anda tetap beroperasi dengan waktu henti minimal. Keamanan melindungi kerahasiaan, integritas, dan ketersediaan sumber daya Anda. Keandalan dan keamanan sangat penting untuk keberhasilan operasi cloud.
Mengelola keandalan
Manajemen keandalan melibatkan penggunaan redundansi, replikasi, dan strategi pemulihan yang ditentukan untuk meminimalkan waktu henti dan melindungi bisnis Anda. Tabel 1 menyediakan contoh tiga prioritas beban kerja, persyaratan keandalan (SLO waktu aktif, waktu henti maks, redundansi, penyeimbangan beban, replikasi), dan contoh skenario yang selaras dengan tujuan tingkat layanan (SLO)
Tabel 1. Contoh prioritas beban kerja dan persyaratan keandalan.
Prioritas | Dampak bisnis | Waktu operasional minimum SLO | Waktu henti maks per bulan | Arsitektur yang Redundan | Penyeimbangan beban | Replikasi dan pencadangan data | Contoh skenario |
---|---|---|---|---|---|---|---|
Tinggi (sangat penting untuk misi) | Efek langsung dan parah pada reputasi atau pendapatan perusahaan. | 99,99% | 4.32 menit | Banyak wilayah & Banyak zona ketersediaan di dalam setiap wilayah | Aktif-aktif | Replikasi data yang sinkron lintas wilayah dan pencadangan & untuk pemulihan | landasan kritis misi |
Menengah | Efek terukur pada reputasi atau pendapatan perusahaan. | 99,9% | 43.20 menit | Beberapa wilayah & Beberapa zona ketersediaan di setiap wilayah | Aktif-pasif | Replikasi data lintas wilayah secara asinkron & untuk pencadangan dalam pemulihan | Pola aplikasi web yang andal |
Rendah | Tidak berpengaruh pada reputasi, proses, atau laba perusahaan. | 99% | 7,20 jam | Wilayah tunggal & Beberapa zona ketersediaan | Redundansi pada zona ketersediaan | Replikasi data sinkron di seluruh wilayah ketersediaan untuk pencadangan dan pemulihan &. |
Garis Dasar App Service standar mesin virtual |
Mengidentifikasi tanggung jawab keandalan
Tanggung jawab keandalan bervariasi menurut model penyebaran. Gunakan tabel berikut untuk mengidentifikasi tanggung jawab manajemen Anda untuk penyebaran infrastruktur (IaaS), platform (PaaS), perangkat lunak (SaaS), dan lokal.
Tanggung jawab | Di lokasi | IaaS (Azure) | PaaS (Azure) | SaaS |
---|---|---|---|---|
Data | ✔️ | ✔️ | ✔️ | ✔️ |
Kode dan runtime | ✔️ | ✔️ | ✔️ | |
Sumber daya cloud | ✔️ | ✔️ | ✔️ | |
Perangkat keras fisik | ✔️ |
Untuk informasi selengkapnya, lihat Tanggung jawab bersama untuk keandalan.
Menentukan persyaratan keandalan
Persyaratan keandalan yang ditentukan dengan jelas sangat penting untuk target waktu aktif, pemulihan, dan toleransi kehilangan data. Ikuti langkah-langkah ini untuk menentukan persyaratan keandalan:
Prioritaskan beban kerja. Tetapkan prioritas tinggi, sedang (default), atau rendah untuk beban kerja berdasarkan tingkat kekritisan bisnis dan investasi keuangan. Tinjau prioritas secara teratur untuk menjaga keselarasan dengan tujuan bisnis.
Tetapkan tujuan tingkat layanan waktu aktif (SLO) ke semua beban kerja. SLO Anda memengaruhi arsitektur, strategi manajemen data, proses pemulihan, dan biaya Anda. Menetapkan target waktu aktif sesuai dengan prioritas beban kerja. Beban kerja dengan prioritas lebih tinggi memerlukan sasaran waktu operasional yang lebih ketat.
Mengidentifikasi indikator tingkat layanan (SLI). Gunakan SLI untuk mengukur performa ketersediaan terhadap SLO Anda. Contohnya termasuk pemantauan kesehatan layanan dan tingkat kesalahan .
Tetapkan tujuan waktu pemulihan (RTO) ke semua beban kerja. RTO menentukan waktu henti maksimum yang dapat diterima untuk beban kerja Anda. RTO harus lebih pendek dari jatah waktu henti tahunan Anda. Misalnya, waktu aktif SLO 99,99% memerlukan waktu henti tahunan kurang dari 52 menit (4,32 menit per bulan). Untuk menetapkan RTO, ikuti langkah-langkah berikut:
Perkirakan jumlah kegagalan per tahun. Untuk beban kerja dengan riwayat operasional, gunakan SLI Anda. Untuk beban kerja baru, lakukan analisis mode kegagalan untuk mendapatkan perkiraan yang akurat.
Perkirakan RTO. Bagi waktu henti tahunan yang diizinkan dengan frekuensi kegagalan yang diperkirakan. Jika Anda memperkirakan empat kegagalan per tahun, RTO Anda harus 13 menit atau kurang (52 menit / 4 kegagalan = 13 menit RTO).
Uji waktu pemulihan Anda. Lacak waktu rata-rata yang diperlukan untuk pulih selama pengujian failover dan kegagalan langsung. Waktu yang dibutuhkan Anda untuk pulih dari kegagalan harus kurang dari RTO Anda.
Tentukan tujuan titik pemulihan (RPO) untuk semua beban kerja. RPO Anda memengaruhi seberapa sering Anda mereplikasi dan mencadangkan data Anda. Tentukan berapa banyak kehilangan data yang dapat ditoleransi bisnis Anda.
Menentukan target keandalan beban kerja. Untuk target keandalan beban kerja, lihat Rekomendasi Well-Architected Framework untuk menentukan target keandalan.
Mengelola keandalan data
Keandalan data melibatkan replikasi data (replika) dan cadangan (salinan titik waktu) untuk menjaga ketersediaan dan konsistensi. Lihat Tabel 2 untuk contoh prioritas beban kerja yang selaras dengan target keandalan data.
Tabel 2. Prioritas beban kerja dengan contoh konfigurasi keandalan data.
Prioritas beban kerja | Waktu Aktif Sistem SLO | Replikasi data | Pencadangan data | Contoh skenario |
---|---|---|---|---|
Tinggi | 99,99% | Replikasi data sinkron di seluruh wilayah Replikasi data sinkron di seluruh zona ketersediaan |
Pencadangan lintas wilayah dengan frekuensi tinggi. Frekuensi harus mendukung RTO dan RPO. | platform data misi penting |
Menengah | 99,9% | Replikasi data sinkron di seluruh wilayah Replikasi data sinkron di seluruh zona ketersediaan |
Pencadangan lintas wilayah. Frekuensi harus mendukung RTO dan RPO. | Solusi basis data dan penyimpanan dalam pola Aplikasi Web Andal |
Rendah | 99% | Replikasi data sinkron di seluruh zona ketersediaan | Pencadangan lintas wilayah. Frekuensi harus mendukung RTO dan RPO. | Ketahanan data di aplikasi web dasar dengan redundansi zona |
Anda harus menyelaraskan konfigurasi keandalan data dengan persyaratan RTO dan RPO beban kerja Anda. Untuk membuat perataan tersebut, ikuti langkah-langkah berikut:
Mengelola replikasi data. Replikasi data Anda secara sinkron atau asinkron sesuai dengan persyaratan RTO dan RPO beban kerja Anda.
Distribusi data Replikasi data Konfigurasi penyeimbangan beban Di seluruh zona ketersediaan Sinkron (mendekati nyata-waktu) Sebagian besar layanan PaaS menangani penyeimbangan beban lintas zona secara asli Lintas wilayah (mode aktif-aktif) Sinkronis Penyeimbangan beban aktif-aktif Di seluruh wilayah (pasif aktif) Asinkron (berkala) Konfigurasi aktif-pasif Untuk informasi selengkapnya, lihat Replikasi : Redundansi untuk data.
Mengelola cadangan data. Backup adalah untuk pemulihan bencana (kegagalan layanan), pemulihan data (penghapusan atau kerusakan), dan respons insiden (keamanan). Cadangan harus mendukung persyaratan RTO dan RPO Anda untuk setiap beban kerja. Lebih suka solusi cadangan bawaan untuk layanan Azure Anda, seperti fitur cadangan asli di Azure Cosmos DB dan Azure SQL Database. Jika cadangan asli tidak tersedia, termasuk data lokal, gunakan Azure Backup. Untuk informasi selengkapnya, lihat Pusat Pencadangan dan Kelangsungan Bisnis Azure.
Mendesain keandalan data beban kerja. Untuk desain keandalan data beban kerja, lihat panduan Well-Architected Framework Pemartisian data dan panduan layanan Azure (dimulai dengan bagian Keandalan).
Mengelola keandalan kode dan runtime
Keandalan kode dan runtime merupakan tanggung jawab yang berkaitan dengan beban kerja. Ikuti panduan penyembuhan diri dan pelestarian diri sesuai Well-Architected Framework.
Mengelola keandalan sumber daya cloud
Mengelola keandalan sumber daya cloud Anda sering memerlukan redundansi arsitektur (instans layanan duplikat) dan strategi penyeimbangan beban yang efektif. Lihat Tabel 3 untuk contoh redundansi arsitektur yang selaras dengan prioritas beban kerja.
Tabel 3. Contoh prioritas beban kerja dan redundansi arsitektur.
Prioritas beban kerja | Arsitektur yang Redundan | Pendekatan penyeimbangan beban | Solusi penyeimbangan beban Azure | Contoh skenario |
---|---|---|---|---|
Tinggi | Dua zona ketersediaan di wilayah & | Aktif-aktif | Azure Front Door (HTTP) Azure Traffic Manager (non-HTTP) |
platform dasar untuk aplikasi misi-kritis |
Menengah | Dua zona ketersediaan di wilayah & | Aktif-pasif | Azure Front Door (HTTP) Azure Traffic Manager (non-HTTP) |
Panduan arsitektur pola aplikasi web andal |
Rendah | Zon ketersediaan di wilayah tunggal & | Di seluruh zona ketersediaan | Azure Application Gateway Menambahkan Azure Load Balancer untuk komputer virtual |
Garis Dasar App Service standar mesin virtual |
Pendekatan Anda harus menerapkan redundansi arsitektur untuk memenuhi persyaratan keandalan beban kerja Anda. Ikuti langkah-langkah ini:
Perkirakan waktu aktif arsitektur Anda. Untuk setiap beban kerja, hitung SLA komposit. Hanya menyertakan layanan yang dapat menyebabkan beban kerja gagal (jalur kritis).
Cantumkan setiap layanan di jalur penting beban kerja. Kumpulkan SLA Microsoft tentang waktu aktif setiap layanan dari dokumen resmi.
Tentukan apakah beban kerja menyertakan jalur kritis independen. Jalur independen dapat gagal dan beban kerja tetap tersedia.
Jika Anda memiliki satu jalur penting, gunakan rumus wilayah tunggal: N = S1 × S2 × S3 × ... × Sn.
Jika Anda memiliki dua jalur penting atau lebih, gunakan rumus jalur independen: N = S1 x 1 - [(1 - S2) × (1 - S3)].
Beban kerja yang kompleks sering menggabungkan kedua jenis rumus. Contoh: N = S1 × S2 × S3 × (S4 x 1 - [(1 - S5) × (1 - S6)]).
Untuk aplikasi multi-wilayah, gunakan rumus untuk rumus multi-wilayah: M = 1 - (1 - N)^R
Bandingkan uptime terhitung Anda dengan SLO uptime Anda. Defisit membutuhkan SLA tingkat lebih tinggi atau redundansi tambahan. Hitung ulang setelah setiap perubahan. Berhenti setelah waktu aktif terhitung melebihi SLO.
Studi kasus Rumus Variabel Contoh Penjelasan Wilayah tunggal N = S1 × S2 × S3 × ... × Sn N = SLA Komposit.
S = SLA layanan Azure.
n = jumlah layanan pada jalur penting.N = 99,99% (aplikasi) × 99,95% (database) × 99,9% (cache) Beban kerja sederhana dengan aplikasi (99,99%), database (99,95%), dan cache (99,9%) dalam satu jalur kritis. Jalur independen S1 x 1 - [(1 - S2) × (1 - S3)] S = SLA layanan Azure. 99,99% (aplikasi) × (1 - [(1 - 99,95% database) × (1 - 99,9% cache)]) Dalam aplikasi, database (99,95%) atau cache (99,9%) dapat gagal tanpa menyebabkan waktu henti. Multi-daerah M = 1 - (1 - N)^R M = SLA multi-wilayah.
N = SLA wilayah tunggal.
R = Jumlah wilayah.Jika N = 99,95% dan R = 2, maka M = 1 - (1 - 99,95%)^2 Beban kerja disebarkan di dua wilayah. Sesuaikan tingkat layanan. Sebelum memodifikasi arsitektur, evaluasi apakah tingkat layanan (SKU) Azure yang berbeda dapat memenuhi persyaratan keandalan Anda. Beberapa tingkat layanan Azure dapat memiliki SLA waktu aktif yang berbeda, seperti Azure Managed Disks.
Tambahkan redundansi arsitektur. Jika perkiraan waktu aktif Anda saat ini kurang dari SLO Anda, tingkatkan redundansi:
Gunakan beberapa zona ketersediaan. Mengonfigurasi beban kerja Anda untuk menggunakan beberapa zona ketersediaan. Memperkirakan bagaimana zona ketersediaan meningkatkan waktu aktif Anda bisa sulit. Hanya sejumlah layanan tertentu yang memiliki SLA ketersediaan yang memperhitungkan zona ketersediaan. Jika SLA memperhitungkan zona ketersediaan, gunakanlah dalam memperkirakan waktu aktif Anda. Lihat tabel berikut untuk beberapa contoh.
Jenis layanan Azure Layanan Azure dengan SLA Zona Ketersediaan Platform Komputasi Layanan Aplikasi
Azure Kubernetes Service
Komputer VirtualDatastore Azure Service Bus (Layanan Bus oleh Azure)
Akun Penyimpanan Azure
Cache Azure untuk Redis (Azure Cache for Redis)
Tingkat Premium Azure FilesBasis data Azure Cosmos DB (layanan basis data global dari Microsoft)
Azure SQL Database
Basis Data Azure untuk MySQL
Basis Data Azure untuk PostgreSQL
Azure Managed Instance untuk Apache CassandraPenyeimbang Beban Application Gateway Keamanan Azure Firewall Gunakan beberapa wilayah. Beberapa wilayah sering diperlukan untuk memenuhi SLO uptime. Gunakan load balancer global (Azure Front Door atau Traffic Manager) untuk distribusi lalu lintas. Arsitektur multi-wilayah memerlukan manajemen konsistensi data yang cermat.
Mengelola redundansi arsitektur. Memutuskan cara menggunakan redundansi: Anda dapat menggunakan redundansi arsitektur sebagai bagian dari operasi harian (aktif). Atau Anda dapat menggunakan redundansi arsitektur dalam skenario pemulihan bencana (pasif). Misalnya, lihat tabel 3.
Penyeimbangan beban di seluruh zona ketersediaan. Gunakan semua zona ketersediaan secara aktif. Banyak layanan Azure PaaS mengelola penyeimbangan beban di seluruh zona ketersediaan secara otomatis. Beban kerja IaaS harus menggunakan penyeimbang beban internal untuk menyeimbangkan beban di antara zona ketersediaan.
Penyeimbangan beban di seluruh wilayah. Menentukan apakah pekerjaan multi-wilayah harus berjalan dalam mode aktif-aktif atau aktif-pasif sesuai kebutuhan keandalan.
Mengelola konfigurasi layanan. Menerapkan konfigurasi secara konsisten di seluruh instans redundan sumber daya Azure, sehingga sumber daya bertingkah sama. Gunakan infrastruktur sebagai kode untuk menjaga konsistensi. Untuk informasi selengkapnya, lihat Konfigurasi sumber daya duplikat.
Mendesain keandalan beban kerja. Untuk desain keandalan beban kerja, lihat kerangka kerja Well-Architected:
Keandalan beban kerja Bimbingan Pilar keandalan Desain multiregion dengan ketersediaan tinggi
Merancang Redundansi
Menggunakan zona ketersediaan dan wilayahPanduan layanan panduan layanan Azure (dimulai dengan bagian Keandalan)
Untuk informasi selengkapnya, lihat Redundansi.
Mengelola kelangsungan bisnis
Memulihkan dari kegagalan memerlukan strategi yang jelas untuk memulihkan layanan dengan cepat dan meminimalkan gangguan untuk menjaga kepuasan pengguna. Ikuti langkah-langkah ini:
Bersiap untuk kegagalan. Buat prosedur pemulihan terpisah untuk beban kerja berdasarkan prioritas tinggi, sedang, dan rendah. Keandalan data, keandalan kode dan runtime, dan keandalan sumber daya cloud adalah dasar untuk mempersiapkan kegagalan. Pilih alat pemulihan lainnya untuk membantu persiapan kelangsungan bisnis. Misalnya, gunakan Azure Site Recovery untuk beban kerja server lokal dan berbasis komputer virtual.
Uji dan rencanakan pemulihan dokumen. Ujilah proses failover dan failback Anda secara teratur untuk memastikan beban kerja Anda memenuhi sasaran waktu pemulihan (RTO) dan sasaran titik pemulihan (RPO). Dokumentasikan dengan jelas setiap langkah rencana pemulihan untuk referensi mudah selama insiden. Verifikasi bahwa alat pemulihan, seperti Azure Site Recovery, secara konsisten memenuhi RTO yang Anda tentukan.
Mendeteksi kegagalan sistem. Mengadopsi pendekatan proaktif untuk mengidentifikasi gangguan layanan dengan cepat, meskipun ini dapat meningkatkan jumlah positif palsu. Prioritaskan pengalaman pelanggan dengan meminimalkan waktu henti dan mempertahankan kepercayaan pengguna.
Memantau kegagalan. Memantau beban kerja untuk mendeteksi pemadaman dalam waktu satu menit. Gunakan Azure Service Health dan Azure Resources Health dan gunakan pemberitahuan Azure Monitor untuk memberitahukan tim yang relevan. Integrasikan pemberitahuan ini dengan alat Azure DevOps atau IT Service Management (ITSM).
Kumpulkan indikator tingkat layanan (SLI). Melacak performa dengan menentukan dan mengumpulkan metrik yang berfungsi sebagai SLI. Pastikan tim Anda menggunakan metrik ini untuk mengukur performa beban kerja terhadap tujuan tingkat layanan (SLA) Anda.
Merespons kegagalan. Selaraskan respons pemulihan Anda dengan prioritas beban kerja. Terapkan prosedur failover untuk mengalihkan permintaan ke infrastruktur redundan dan replika data segera. Setelah sistem stabil, atasi akar penyebabnya, sinkronkan data, dan jalankan prosedur failback. Untuk informasi selengkapnya, lihat Failover dan failback.
Menganalisis kegagalan. Identifikasi akar penyebab masalah lalu atasi masalahnya. Dokumentasikan pelajaran apa pun dan buat perubahan yang diperlukan.
Mengelola kegagalan beban kerja. Untuk pemulihan bencana beban kerja, lihat panduan pemulihan bencana Well-Architected Framework dan panduan layanan Azure (dimulai dengan bagian Keandalan).
Alat keandalan Azure
Studi kasus | Solusi |
---|---|
Replikasi data, pencadangan, dan kelangsungan bisnis |
panduan layanan Azure (dimulai dengan bagian Keandalan) Referensi cepat: Azure Cosmos DB Azure SQL Database Azure Blob Storage Azure Files |
Pencadangan data | Azure Backup |
Kelangsungan bisnis (IaaS) | Azure Site Recovery |
Penyeimbang beban multi-wilayah |
Azure Front Door (HTTP) Azure Traffic Manager (non-HTTP) |
Penyeimbang beban dengan banyak zona ketersediaan |
Azure Application Gateway (HTTP) Azure Load Balancer (bukan HTTP) |
Mengelola keamanan
Gunakan proses keamanan berulang untuk mengidentifikasi dan mengurangi ancaman di lingkungan cloud Anda. Ikuti langkah-langkah ini:
Mengelola operasi keamanan
Kelola kontrol keamanan Anda untuk mendeteksi ancaman terhadap estat cloud Anda. Ikuti langkah-langkah ini:
Menstandarkan alat keamanan. Gunakan alat standar untuk mendeteksi ancaman, memperbaiki kerentanan, menyelidiki masalah, mengamankan data, memperkuat sumber daya, dan menerapkan kepatuhan dalam skala besar. Lihat alat keamanan Azure.
Standarisasikan lingkungan Anda. Dokumentasikan kondisi normal aset cloud Anda. Memantau keamanan dan mendokumen pola lalu lintas jaringan dan perilaku pengguna. Gunakan garis besar keamanan Azure dan panduan layanan Azure untuk mengembangkan konfigurasi dasar untuk layanan. Garis besar ini memudahkan untuk mendeteksi anomali dan potensi kelemahan keamanan.
Terapkan kontrol keamanan. Menerapkan langkah-langkah keamanan, seperti kontrol akses, enkripsi, dan autentikasi multifaktor, memperkuat lingkungan dan mengurangi kemungkinan kompromi. Untuk informasi selengkapnya, lihat Mengelola keamanan.
Menetapkan tanggung jawab keamanan. Menunjuk tanggung jawab untuk pemantauan keamanan di seluruh lingkungan cloud Anda. Pemantauan dan perbandingan rutin dengan garis besar memungkinkan identifikasi cepat insiden, seperti akses yang tidak sah atau transfer data yang tidak biasa. Pembaruan dan audit rutin menjaga garis besar keamanan Anda tetap efektif terhadap ancaman yang berkembang.
Untuk informasi selengkapnya, lihat CAF Aman .
Mengelola insiden keamanan
Mengadopsi proses dan alat untuk pulih dari insiden keamanan, seperti ransomware, penolakan layanan, atau gangguan aktor ancaman. Ikuti langkah-langkah ini:
Bersiap untuk insiden. Mengembangkan rencana respons insiden yang dengan jelas mendefinisikan peran untuk penyelidikan, mitigasi, dan komunikasi. Uji efektivitas rencana Anda secara teratur. Mengevaluasi dan menerapkan alat manajemen kerentanan, sistem deteksi ancaman, dan solusi pemantauan infrastruktur. Kurangi permukaan serangan Anda melalui penguatan infrastruktur dan buat strategi pemulihan khusus beban kerja. Lihat Gambaran Umum Respons Insiden dan Playbook Respons Insiden.
Mendeteksi insiden. Gunakan alat manajemen informasi dan peristiwa keamanan (SIEM), seperti Microsoft Azure Sentinel, untuk memusatkan data keamanan Anda. Gunakan Microsoft Sentinel kemampuan orkestrasi, otomatisasi, dan respons keamanan (SOAR) untuk mengotomatiskan tugas keamanan rutin. Integrasikan umpan inteligensi ancaman ke SIEM Anda untuk mendapatkan wawasan tentang taktik lawan yang relevan dengan lingkungan cloud Anda. Gunakan Microsoft Defender for Cloud untuk memindai Azure secara teratur untuk kerentanan. Microsoft Defender mengintegrasikan dengan Microsoft Sentinel untuk memberikan tampilan terpadu tentang peristiwa keamanan.
Merespons insiden. Segera aktifkan rencana respons insiden Anda setelah mendeteksi insiden. Mulai prosedur investigasi dan mitigasi dengan cepat. Aktifkan rencana pemulihan bencana Anda untuk memulihkan sistem yang terpengaruh, dan komunikasikan detail insiden dengan jelas kepada tim Anda.
Menganalisis insiden keamanan. Setelah setiap insiden, tinjau inteligensi ancaman dan perbarui rencana respons insiden Anda berdasarkan pelajaran yang dipelajari dan wawasan dari sumber daya publik, seperti pangkalan pengetahuan MITRE ATT&CK. Evaluasi efektivitas alat manajemen dan deteksi kerentanan Anda dan perbaiki strategi berdasarkan analisis pasca-insiden.
Untuk informasi selengkapnya, lihat Mengelola respons insiden (CAF Secure).
Alat keamanan Azure
Kemampuan keamanan | Solusi Microsoft |
---|---|
Manajemen identitas dan akses | Microsoft Entra ID |
Kontrol akses berbasis peran | Kontrol akses berbasis peran Azure |
Deteksi ancaman | Microsoft Defender untuk Awan |
Manajemen informasi keamanan | Microsoft Sentinel |
Keamanan dan tata kelola data | Microsoft Purview |
Keamanan sumber daya cloud | garis besar keamanan Azure |
Pemerintahan cloud | Kebijakan Azure |
Keamanan titik akhir | Microsoft Defender untuk Endpoint |
Keamanan jaringan | Azure Network Watcher |
Keamanan industri | Pertahanan Microsoft untuk IoT |
Keamanan pencadangan data | Keamanan Azure Backup |