Edit

Bagikan melalui

Pertimbangan keamanan untuk aplikasi IaaS yang sangat sensitif di Azure

Azure Disk Encryption
Azure Firewall
Azure Key Vault
Microsoft Defender for Cloud
Azure Virtual Network

Ada banyak pertimbangan keamanan untuk menyebarkan aplikasi infrastructure-as-a-service (IaaS) ke Azure. Artikel ini dibangun di atas arsitektur referensi untuk beban kerja berbasis mesin virtual dan infrastruktur jaringan hybrid untuk fokus pada keamanan untuk beban kerja IaaS yang sangat sensitif di Azure, berdasarkan dasar-dasar keamanan Azure.

Lihat juga Ringkasan Keamanan mesin virtual Azure dan praktik terbaik Keamanan untuk beban kerja IaaS di Azure.

Azure VM

Platform komputasi Azure didasarkan pada virtualisasi mesin. Hypervisor berjalan pada perangkat keras fisik masing-masing simpul Azure atau titik akhir jaringan, dan membuat sejumlah variabel mesin virtual Hyper-V tamu (VM) di simpul. Semua kode pengguna dijalankan pada VM. Untuk petunjuk penerapan Azure VM dasar, lihat Menjalankan VM Linux di Azure atau Menjalankan Windows VM di Azure. Sebagian besar proses penyebaran sama untuk dua sistem operasi (OS), tetapi alat khusus OS seperti enkripsi disk mungkin berbeda.

Anda dapat menggunakan Microsoft Defender untuk Cloud untuk manajemen patch VM dan untuk menyebarkan dan memantau alat antimalware. Atau, Anda dapat mengelola alat patching dan antimalware Anda sendiri atau pihak ketiga, yang umum saat memperluas atau memigrasikan infrastruktur yang ada ke Azure.

Microsoft menyediakan perlindungan Basic distributed denial of service (DDoS) sebagai bagian dari platform Azure. Aplikasi yang memiliki titik akhir publik dapat menggunakan Azure DDoS Protectio Standar untuk perlindungan tambahan. Namun, beban kerja yang sangat sensitif biasanya tidak memiliki titik akhir publik, dan hanya dapat diakses dari lokasi tertentu melalui jaringan pribadi virtual (VPN) atau leased line.

Arsitektur N-tier

Banyak aplikasi IaaS terdiri dari beberapa tingkatan, seperti tingkat web, tingkat bisnis, dan tingkat data, yang dihosting di beberapa VM. Aspek kunci penerapan arsitektur aplikasi n-tier di Azure VM meliputi:

  • Ketersediaan tinggi(HA), Aplikasi HA harus tersedia lebih dari 99,9% dari waktu. Menempatkan VM dalam tingkat di zona ketersediaan Azure yang berbeda memastikan KETERSEDIAAN TINGGI, karena zona ketersediaan mencakup satu atau beberapa pusat data, memberikan ketahanan melalui ketahanan terhadap kegagalan pusat data. Wilayah yang tidak mendukung zona ketersediaan dapat menggunakan set ketersediaan, yang mendistribusikan VM di beberapa simpul perangkat keras yang terisolasi.
  • Penyeimbangan beban. Penyeimbang beban mendistribusikan lalu lintas di antara VM, untuk menyeimbangkan beban dan ketahanan ketika VM gagal. Anda tidak memerlukan penyeimbang beban jika aplikasi mengelola penyeimbangan beban dan VM individual diketahui oleh penelepon.
  • Jaringan virtual. Jaringan virtual dan subnet menyegmentasikan jaringan Anda, memungkinkan manajemen keamanan yang lebih mudah dan perutean lanjutan.
  • Sistem Nama Domain (DNS). Azure DNS menyediakan layanan DNS yang sangat tersedia dan aman. Zona pribadidi Azure DNS memungkinkan Anda menggunakan domain kustom di dalam jaringan virtual Anda.

Pencadangan dan pemulihan

Untuk melindungi dari kesalahan manusia, penghapusan data berbahaya, dan ransomware, Anda harus mencadangkan setidaknya VM tingkat data Anda. Azure Backup dapat mencadangkan dan memulihkan VM terenkripsi jika dapat mengakses kunci enkripsi di Azure Key Vault.

Untuk tingkatan web dan bisnis, Anda dapat menggunakan aturan autoscaling set skala mesin virtual untuk secara otomatis menghancurkan VM yang disusupi dan menerapkan instans VM baru dari gambar dasar.

Isolasi komputasi

Pada setiap simpul Azure atau titik akhir jaringan, hypervisor dan root OS khusus memastikan VM tamu tidak dapat mengakses server host fisik, dan kode pengguna hanya dijalankan pada VM tamu. Ini mencegah pengguna mendapatkan akses baca/tulis/eksekusi mentah ke sistem dan memitigasi risiko berbagi sumber daya. Azure melindungi terhadap semua serangan saluran samping yang diketahui dan tetangga yang berisik melalui hypervisor dan algoritma penempatan VM tingkat lanjutan. Untuk informasi selengkapnya, lihat Isolasi komputasi.

Untuk beban kerja yang sangat sensitif, Anda dapat menambahkan perlindungan tambahan terhadap serangan saluran samping dengan VM terisolasi atau host khusus.

VM terisolasi

VM ini diisolasi ke jenis perangkat keras tertentu dan didedikasikan untuk satu pelanggan. Menggunakan ukuran terisolasi menjamin bahwa VM Anda akan menjadi satu-satunya VM yang berjalan pada instans server tertentu. Anda dapat lebih lanjut membagi sumber daya VM yang terisolasi dengan menggunakan dukungan Azure untuk sarang mesin virtual.

Ukuran minimum VM yang terisolasi adalah 64 core CPU virtual dan 256 GiB memori. VM ini jauh lebih besar daripada yang dibutuhkan sebagian besar aplikasi n-tier, dan dapat membuat kelebihan biaya yang besar. Untuk mengurangi kelebihan, Anda dapat menjalankan beberapa tingkatan aplikasi pada satu VM dengan virtualisasi bersarang, atau dalam proses atau kontainer yang berbeda. Anda masih perlu menyebarkan VM yang berbeda di zona ketersediaan untuk ketahanan, dan menjalankan appliance zona demiliterisasi (DMZ) pada VM terpisah. Menggabungkan beberapa aplikasi pada satu infrastruktur karena alasan ekonomi mungkin juga bertentangan dengan kebijakan pemisahan aplikasi organisasi.

Seiring meningkatnya kemampuan wilayah Azure dari waktu ke waktu, Azure juga dapat menghapus jaminan isolasi dari ukuran VM tertentu, dengan pemberitahuan satu tahun.

Azure Dedicated Hosts

Azure Dedicated Host adalah solusi isolasi komputasi yang disukai untuk beban kerja yang sangat sensitif. Dedicated host adalah server fisik yang didedikasikan untuk satu pelanggan untuk menghosting beberapa VM. Selain mengisolasi VM, host khusus memungkinkan Anda mengontrol pemeliharaan dan penempatan VM untuk menghindari tetangga yang berisik.

Dedicated Host

Host khusus memiliki ukuran minimum yang sama dan banyak pertimbangan ukuran yang sama dengan VM yang terisolasi. Namun, host khusus dapat menghosting VM yang terletak di jaringan virtual yang berbeda, untuk memenuhi kebijakan segregasi aplikasi. Anda masih harus menjalankan DMZ VM pada host yang berbeda, untuk mencegah serangan saluran samping dari VM yang disusupi di DMZ.

Enkripsi

Enkripsi data adalah komponen penting untuk mengamankan beban kerja. Enkripsi mengkodekan informasi sehingga hanya penerima yang berwenang yang dapat memecahkan kode dengan menggunakan kunci atau sertifikat. Enkripsi termasuk enkripsi disk, untuk enkripsi data saat istirahat, dan Transport Level Security (TLS),, untuk enkripsi dalam transit melalui jaringan.

Azure Key Vault

Anda dapat melindungi kunci dan sertifikat enkripsi dengan menyimpannya di Azure Key Vault, solusi Cloud Hardware Security Module (HSM) yang divalidasi untuk Standar Pemrosesan Informasi Federal (FIPS) 140-2 Level 2. Untuk praktik terbaik yang hanya mengizinkan aplikasi dan pengguna yang berwenang mengakses Key Vault, lihat Akses aman ke brankas utama.

Untuk melindungi kunci di Key Vault, Anda dapat mengaktifkan penghapusan lunak, yang memastikan kunci yang dihapus dapat dipulihkan. Untuk perlindungan tambahan, Anda dapat mencadangkan kunci individual ke file terenkripsi yang dapat Anda gunakan untuk memulihkan kunci, berpotensi ke wilayah Azure lain dalam geografi yang sama.

Saat menghosting SQL Server di VM, Anda dapat menggunakan SQL Server Connector untuk Microsoft Azure Key Vault untuk mendapatkan kunci untuk enkripsi data transparan (TDE), enkripsi tingkat kolom (CLE), dan enkripsi cadangan. Mengonfigurasi Integrasi Azure Key Vault untuk SQL Server di Azure Virtual Machines.

Azure Disk Encryption

Azure Disk Encryption menggunakan fitur BitLocker Windows untuk menyediakan enkripsi volume untuk OS dan disk data komputer virtual (VM) Azure, dan terintegrasi dengan Azure Key Vault untuk membantu Anda mengontrol dan mengelola kunci enkripsi dan rahasia disk. Setiap VM menghasilkan kunci enkripsinya sendiri dan menyimpannya di Azure Key Vault. Untuk mengonfigurasi Azure Key Vault untuk mengaktifkan Azure Disk Encryption, lihat Membuat dan mengonfigurasi vault kunci untuk Azure Disk Encryption.

Untuk beban kerja yang sangat sensitif, Anda juga harus menggunakan kunci enkripsi kunci (KEK) untuk lapisan keamanan tambahan. Saat kunci enkripsi kunci ditentukan, Azure Disk Encryption menggunakan kunci itu untuk membungkus rahasia enkripsi sebelum menulis ke Key Vault. Anda dapat membuat KEK di Azure Key Vault, tetapi metode yang lebih aman adalah membuat kunci di HSM lokal Anda dan mengimpornya ke Azure Key Vault. Skenario ini sering disebut sebagai membawa kunci Anda sendiri, atau BYOK. Karena kunci yang diimpor tidak dapat meninggalkan batas HSM, menghasilkan kunci di HSM Anda memastikan Anda memegang kendali penuh atas kunci enkripsi.

Enkripsi yang dilindungi HSM

Untuk informasi selengkapnya tentang kunci yang dilindungi HSM, lihat Cara membuat dan mentransfer kunci yang dilindungi HSM untuk Azure Key Vault.

Periksa enkripsi lalu lintas

Protokol jaringan seperti HTTPS mengenkripsi data dalam perjalanan dengan sertifikat. Lalu lintas klien-ke-aplikasi biasanya menggunakan sertifikat dariotoritas sertifikat tepercaya (CA). Aplikasi internal dapat menggunakan sertifikat dari CA internal atau CA publik seperti DigiCert atau GlobalSign. Komunikasi tingkat-ke-tingkat biasanya menggunakan sertifikat yang dikeluarkan oleh CA internal, atau sertifikat yang ditandatangani sendiri. Azure Key Vault dapat mengakomodasi salah satu jenis sertifikat ini. Untuk informasi selengkapnya tentang membuat jenis sertifikat yang berbeda, lihat Metode pembuatan sertifikat.

Azure Key Vault dapat bertindak sebagai CA sertifikat yang ditandatangani sendiri untuk lalu lintas tingkat-ke-tingkat. Ekstensi Key Vault VM menyediakan pemantauan dan penyegaran otomatis sertifikat tertentu pada VM, dengan atau tanpa kunci pribadi tergantung pada kasus penggunaan. Lihat Ekstensi komputer virtual Key Vault VM untuk Windows atau Ekstensi mesin virtual Key Vault untuk Linux.

Key Vault juga dapat menyimpan kunci untuk protokol jaringan yang tidak menggunakan sertifikat. Beban kerja kustom dapat memerlukan skrip ekstensi skrip kustom yang mengambil kunci dari Key Vault dan menyimpannya untuk digunakan aplikasi. Aplikasi juga dapat menggunakan identitas terkelola VM untuk mengambil rahasia langsung dari Key Vault.

Keamanan jaringan

Grup keamanan jaringan (NSGs) memfilter lalu lintas antar sumber daya di jaringan virtual Azure. Aturan keamanan NSG memungkinkan atau menolak lalu lintas jaringan ke atau dari sumber daya Azure berdasarkan alamat IP dan port. Secara default, NSGs memblokir lalu lintas masuk dari internet, tetapi memungkinkan koneksi keluar dari VM ke internet. Untuk mencegah lalu lintas keluar yang tidak disengaja, tambahkan aturan khusus dengan prioritas serendah mungkin, 4096, untuk memblokir semua lalu lintas masuk dan keluar. Anda kemudian dapat menambahkan aturan prioritas yang lebih tinggi untuk memungkinkan lalu lintas tertentu.

NSGs membuat rekaman alur untuk koneksi yang ada, dan mengizinkan atau menolak komunikasi berdasarkan status koneksi rekaman aliran. Catatan alur memungkinkan NSG untuk menjadi stateful. Jika Anda menentukan aturan keamanan keluar ke alamat mana pun di atas port 443, misalnya, Anda tidak perlu menentukan aturan keamanan masuk untuk respons terhadap lalu lintas keluar. Anda hanya perlu menentukan aturan keamanan masuk jika komunikasi dimulai secara eksternal.

Sebagian besar layanan Azure memungkinkan Anda menggunakan tag layanan jaringan virtual alih-alih NSG. Tag layanan mewakili sekelompok awalan alamat IP dari layanan Azure, dan membantu meminimalkan kompleksitas dari pembaruan aturan keamanan jaringan yang sering. Tag layanan Azure Key Vault dapat memungkinkan VM untuk mengambil sertifikat, kunci, dan rahasia dari Azure Key Vault.

Cara lain untuk mengontrol keamanan jaringan adalah melalui routing lalu lintas jaringan virtual dan penerowongan paksa. Azure membuat rute sistem secara otomatis dan menetapkan rute ke setiap subnet dalam jaringan virtual. Anda tidak dapat membuat atau menghapus rute sistem, tetapi Anda dapat mengganti beberapa rute sistem dengan rute kustom. Perutean kustom memungkinkan Anda merutekan lalu lintas melalui alat virtual jaringan (NVA) seperti firewall atau proxy, atau menjatuhkan lalu lintas yang tidak diinginkan, yang memiliki efek serupa dengan memblokir lalu lintas dengan NSG.

Anda dapat menggunakan NVAs seperti Azure Firewall untuk mengizinkan, memblokir, dan memeriksa lalu lintas jaringan. Azure Firewall adalah layanan firewall platform yang dikelola dan sangat tersedia. Anda juga dapat menyebarkan NVAs pihak ketiga dari Azure Marketplace. Untuk membuat NVAs ini sangat tersedia, lihat Menyebarkan peralatan virtual jaringan yang sangat tersedia.

Kelompok keamanan aplikasi

Untuk memfilter lalu lintas antar tingkatan aplikasi dalam jaringan virtual, gunakan Grup keamanan aplikasi (ASG). ASG memungkinkan Anda mengonfigurasi keamanan jaringan sebagai perpanjangan dari struktur aplikasi, memungkinkan Anda mengelompokkan VM dan menentukan kebijakan keamanan jaringan berdasarkan grup. Anda dapat menggunakan kembali kebijakan keamanan Anda dengan skala tanpa pemeliharaan manual alamat IP eksplisit.

Kelompok keamanan aplikasi

Karena ASG diterapkan ke antarmuka jaringan, bukan subnet, mereka mengaktifkan segmentasi mikro. Anda dapat mengontrol dengan ketat VM mana yang dapat berbicara satu sama lain, bahkan memblokir lalu lintas antara VM di tingkat yang sama, dan membuatnya mudah untuk mengkarantina VM dengan menghapus ASG dari VM itu.

Jaringan hibrid

Arsitektur hibrida menghubungkan jaringan lokal dengan cloud publik seperti Azure. Ada beberapa cara untuk menghubungkan jaringan lokal ke aplikasi yang berjalan di Azure:

  • Titik akhir publik melalui internet. Anda dapat mengandalkan identitas, keamanan tingkat transportasi (HTTPS), dan gateway aplikasi untuk melindungi aplikasi, berpotensi dalam kombinasi dengan firewall. Namun, untuk beban kerja yang sangat sensitif, mengekspos titik akhir publik melalui internet tidak disarankan.
  • Azure atau gateway VPN pihak ketiga. Anda dapat menghubungkan jaringan lokal ke Azure dengan menggunakan gateway Azure VPN. Lalu lintas masih berjalan melalui internet, tetapi melalui terowongan terenkripsi yang menggunakan TLS. Anda juga dapat menjalankan gateway pihak ketiga di VM, jika Anda memiliki persyaratan khusus yang tidak didukung oleh gateway Azure VPN.
  • ExpressRoute. Koneksi ExpressRoute menggunakan koneksi privat dan khusus melalui penyedia konektivitas pihak ketiga. Koneksi pribadi memperluas jaringan lokal Anda ke Azure, dan menyediakan skalabilitas dan perjanjian tingkat layanan (SLA) yang andal.
    • ExpressRoute dengan failover VPN. Opsi ini menggunakan ExpressRoute dalam kondisi normal, tetapi gagal ke koneksi VPN jika ada kehilangan konektivitas di sirkuit ExpressRoute, memberikan ketersediaan yang lebih tinggi.
    • VPN melalui ExpressRoute. Opsi ini adalah yang terbaik untuk beban kerja yang sangat sensitif. ExpressRoute menyediakan sirkuit pribadi dengan skalabilitas dan keandalan, dan VPN menyediakan lapisan perlindungan tambahan yang mengakhiri koneksi terenkripsi dalam jaringan virtual Azure tertentu.

Untuk panduan selengkapnya tentang memilih antara berbagai jenis konektivitas hibrid, lihat Memilih solusi untuk menghubungkan jaringan lokal ke Azure.

Menyebarkan DMZ

Menghubungkan lingkungan lokal dan Azure memberi pengguna lokal akses ke aplikasi Azure. Jaringan perimeter atau zona demiliterisasi (DMZ) memberikan perlindungan tambahan untuk beban kerja yang sangat sensitif.

Arsitektur seperti yang ada di Network DMZ antara Azure dan pusat data lokal menyebarkan semua DMZ dan layanan aplikasi di jaringan virtual yang sama, dengan aturan NSG dan rute yang ditentukan pengguna untuk mengisolasi subnet DMZ dan aplikasi. Arsitektur ini dapat membuat subnet manajemen tersedia melalui internet publik, untuk mengelola aplikasi bahkan jika gateway lokal tidak tersedia. Namun, untuk beban kerja yang sangat sensitif, Anda hanya boleh membiarkan melewati gateway dalam skenario pecahan kaca. Solusi yang lebih baik adalah menggunakan Azure Bastion, yang memungkinkan akses langsung dari portal Microsoft Azure sambil membatasi paparan alamat IP publik.

Anda juga dapat menggunakan akses VM Just-In-Time (JIT) untuk manajemen jarak jauh sambil membatasi paparan alamat IP publik. Dengan akses JIT VM, NSG memblokir port manajemen jarak jauh seperti remote desktop protocol (RDP) dan secure shell (SSH) secara default. Atas permintaan, akses JIT VM memungkinkan port hanya untuk jendela waktu tertentu, dan berpotensi untuk alamat atau rentang IP tertentu. Akses JIT juga berfungsi untuk VM yang hanya memiliki alamat IP pribadi. Anda dapat menggunakan Azure Bastion untuk memblokir lalu lintas ke VM hingga akses JIT VM diaktifkan.

Untuk menyebarkan lebih banyak aplikasi, Anda dapat menggunakan topologi jaringan hub-spoke di Azure, dengan DMZ di jaringan virtual hub dan aplikasi di jaringan virtual spoke. Jaringan virtual hub dapat berisi VPN dan/atau gateway ExpressRoute, firewall NVA, host manajemen, infrastruktur identitas, dan layanan bersama lainnya. Jaringan virtual spoke terhubung ke hub dengan peering jaringan virtual. Jaringan virtual Azure tidak mengizinkan perutean transitif melalui hub dari satu yang berbicara dengan yang lain. Lalu lintas spoke-to-spoke hanya dimungkinkan melalui peralatan firewall di hub. Arsitektur ini secara efektif mengisolasi aplikasi satu sama lain.

Penyebaran multi-wilayah

Kelangsungan bisnis dan pemulihan bencana mungkin memerlukan penerapan aplikasi Anda di beberapa wilayah Azure, yang dapat memengaruhi residensi dan keamanan data. Arsitektur referensi untuk penerapan multi-wilayah, lihat Menjalankan aplikasi N-tier di beberapa wilayah Azure untuk ketersediaan tinggi.

Pasangan regional

Geografi Azure adalah area yang ditentukan di dunia yang berisi setidaknya satu Wilayah Azure, masing-masing dengan satu atau lebih pusat data Masing-masing wilayah Azure dipasangkan dengan wilayah lain dalam geografi yang sama, bersama-sama membuat pasangan regional. Pasangan regional tidak diperbarui pada saat yang sama, dan jika bencana melanda kedua wilayah, salah satu wilayah diprioritaskan untuk kembali online terlebih dahulu. Untuk kelangsungan bisnis, Anda harus menerapkan aplikasi yang sangat sensitif setidaknya ke pasangan regional jika Anda menyebarkan di beberapa wilayah.

Untuk informasi selengkapnya, lihat Kelangsungan bisnis dan pemulihan bencana (Business Continuity and Disaster Recovery/BCDR): Wilayah Berpasangan Azure. Whitepaper Mencapai residensi dan keamanan data sesuai dengan Azure membahas residensi data, dan apa yang harus dilakukan untuk memenuhi persyaratan residensi data.

Replikasi antar wilayah

Dalam arsitektur IaaS, mereplikasi data antar wilayah adalah tanggung jawab aplikasi. Skenario replikasi yang paling umum menggunakan teknologi replikasi database yang dibangun ke dalam produk server database, seperti SQL Server Always On Availability Groups, Oracle Data Guard, atau MySQL Replication.

Menyiapkan replikasi antara server database IaaS tidak mudah, dan Anda perlu mempertimbangkan persyaratan kelangsungan bisnis. Layanan database Azure seperti Azure SQL Database, Azure Database for MySQL, dan Azure Cosmos DB membuat replikasi antar wilayah lebih mudah, tetapi mungkin tidak memenuhi persyaratan keamanan untuk beban kerja yang sangat sensitif.

Untuk informasi dan panduan selengkapnya untuk penyebaran SQL Server multi-wilayah dan Oracle, lihat:

Peering lintas wilayah

Anda dapat mengaktifkan komunikasi yang aman antara jaringan virtual di berbagai wilayah dengan menggunakan peering jaringan virtual global. Peering global bekerja sama dengan peering dalam wilayah. Lalu lintas antar wilayah berjalan di atas backbone Microsoft, tidak melintasi internet, dan terisolasi dari lalu lintas lainnya. Untuk keamanan lebih lanjut, Anda dapat menerapkan NVAs VPN di kedua wilayah, dan menggunakan rute yang ditentukan pengguna untuk memaksa lalu lintas antar wilayah melalui NVAs, mirip dengan menyebarkan DMZ.

Perutean lalu lintas Failover

Dengan titik akhir publik, Anda dapat menggunakan Traffic Manager atau Azure Front Door untuk mengarahkan lalu lintas ke wilayah aktif atau wilayah terdekat dalam konfigurasi failover aktif-aktif. Namun, Traffic Manager dan Azure Front Door keduanya memerlukan titik akhir publik untuk memantau ketersediaan, dan entri DNS yang sesuai bersifat publik. Untuk beban kerja yang sangat sensitif, solusi alternatifnya adalah menerapkan DNS lokal, dan mengubah entri ke wilayah aktif untuk failover.

Manajemen dan tata kelola

Mengamankan aplikasi IaaS Anda yang sangat sensitif membutuhkan lebih dari sekadar menerapkan arsitektur yang benar dan menerapkan aturan keamanan jaringan. Karena lingkungan cloud mudah diubah, sangat penting untuk memastikan perubahan hanya dapat dilakukan dengan izin tertentu, dan dalam batas-batas kebijakan keamanan. Misalnya, Anda harus mencegah aktor jahat untuk dapat mengubah aturan keamanan jaringan untuk memungkinkan lalu lintas dari internet.

Untuk menerapkan beban kerja di Azure, Anda memerlukan satu atau beberapa akun manajemen. Mengamankan akun manajemen sangat penting untuk mengamankan beban kerja Anda. Untuk informasi selengkapnya, lihat Mengamankan akses istimewa untuk penyebaran hibrid dan cloud di ID Microsoft Entra.

Gunakan sumber daya di subnet manajemen Anda untuk memberikan akses tingkat aplikasi hanya kepada orang-orang yang perlu mengelola tingkat tersebut. Misalnya, Anda dapat menggunakan Microsoft Identity Manager dengan ID Microsoft Entra. Namun, untuk skenario cloud-native, Microsoft Entra Privileged Identity Management (PIM) lebih disukai.

Ada beberapa cara lain untuk mengontrol peran dan kebijakan Azure:

  • Kontrol akses berbasis peran Azure (Azure RBAC) untuk sumber daya Azure memungkinkan Anda menetapkan peran bawaan atau kustom kepada pengguna, sehingga mereka hanya memiliki hak istimewa yang mereka butuhkan. Anda dapat menggabungkan Azure RBAC dengan PIM untuk menerapkan alur kerja persetujuan yang diaudit yang meningkatkan hak istimewa untuk jangka waktu terbatas.
  • Kebijakan menegakkan aturan perusahaan, standar, dan SLA. Azure Policy adalah layanan Azure yang membuat, menetapkan, dan mengelola kebijakan, serta mengevaluasi sumber daya Anda untuk kepatuhan kebijakan.
  • Azure Blueprints menggabungkan penetapan peran, penetapan kebijakan, dan templat penerapan untuk menentukan sekumpulan sumber daya Azure yang dapat ditiru yang menerapkan dan mengikuti standar, pola, dan persyaratan organisasi. Cetak biru adalah cara deklaratif untuk mengatur penyebaran berbagai template sumber daya dan artefak lain. Anda dapat membuat cetak biru sendiri, atau memanfaatkan cetak biru yang ada. Misalnya, cetak biru Layanan Bersama ISO 27001 menerapkan hub layanan bersama yang dapat Anda ubah dan perpanjang ke persyaratan organisasi Anda.

Pemantauan

Microsoft Defender untuk Cloud menyediakan pemantauan dan peringatan yang membantu Anda menjaga keamanan lingkungan Anda. Layanan gratis secara otomatis memeriksa kerentanan seperti patch OS yang hilang, kesalahan konfigurasi keamanan, dan keamanan jaringan dasar. Versi berbayar Standar memberi Anda fitur tambahan, seperti analitik perilaku, Pengerasan Jaringan Adaptif, dan akses JIT VM. Untuk daftar lengkap fitur, lihat Cakupan fitur untuk mesin. Microsoft Defender untuk Cloud juga menyediakan perlindungan ancaman untuk sumber daya lain seperti Azure Key Vault.

Anda dapat menggunakan Azure Monitor untuk pemantauan dan analisis lebih lanjut. Untuk memantau identitas dan akses, Anda dapat merutekan log aktivitas Microsoft Entra ke Azure Monitor. Anda juga dapat memantau VM, jaringan, dan Azure Firewall, dan menganalisis log yang diimpor dengan kemampuan kueri log yang kuat. Anda dapat mengintegrasikan Azure Monitor dengan Security Information and Event Manager (SIEM), yang dapat menjadi SIEM atauMicrosoft Sentinel pihak ketiga.