Bagikan melalui

Praktik terbaik untuk semua arsitektur isolasi

  • Artikel

Berikut ini adalah pertimbangan desain untuk semua konfigurasi isolasi. Di seluruh konten ini, terdapat banyak tautan. Kami membuat tautan ke konten, alih-alih menduplikasinya di sini, sehingga Anda akan selalu memiliki akses ke informasi terbaru.

Untuk panduan umum tentang cara mengonfigurasi penyewa Microsoft Entra (terisolasi atau tidak), lihat panduan penyebaran fitur Microsoft Entra.

Catatan

Untuk semua penyewa yang terisolasi, kami sarankan Anda menggunakan branding yang jelas dan berbeda untuk membantu menghindari kesalahan manusia dalam bekerja di penyewa yang salah.

Prinsip keamanan isolasi

Saat merancang lingkungan yang terisolasi, penting untuk mempertimbangkan prinsip berikut:

  • Gunakan hanya autentikasi modern - Aplikasi yang disebarkan di lingkungan terisolasi harus menggunakan autentikasi modern berbasis klaim (misalnya, SAML, * Auth, OAuth2, dan OpenID Connect) untuk menggunakan kemampuan seperti federasi, kolaborasi Microsoft Entra B2B, delegasi, dan kerangka kerja persetujuan. Dengan cara ini, aplikasi lama yang memiliki dependensi pada metode autentikasi lama seperti NT LAN Manager (NTLM) tidak akan diteruskan di lingkungan yang terisolasi.

  • Menerapkan autentikasi yang kuat - Autentikasi yang kuat harus selalu digunakan saat mengakses layanan dan infrastruktur lingkungan yang terisolasi. Jika memungkinkan, autentikasi tanpa kata sandi seperti Windows untuk Business Hello atau kunci keamanan FIDO2 harus digunakan.

  • Menyebarkan stasiun kerja yang aman - Stasiun kerja yang aman menyediakan mekanisme untuk memastikan bahwa platform dan identitas yang diwakili platform dibuktikan dengan benar dan aman terhadap eksploitasi. Dua pendekatan lain yang perlu dipertimbangkan adalah:

    • Gunakan PC Cloud WINDOWS 365 (PC Cloud) dengan API Microsoft Graph.

    • Gunakan Akses Bersyarat dan filter untuk perangkat sebagai ketentuan.

  • Menghilangkan mekanisme kepercayaan lama - Direktori dan layanan terisolasi tidak boleh membangun hubungan kepercayaan dengan lingkungan lain melalui mekanisme lama seperti kepercayaan Active Directory. Semua kepercayaan antar lingkungan harus ditetapkan dengan konstruksi modern seperti federasi dan identitas berbasis klaim.

  • Mengisolasi layanan - Meminimalkan area serangan permukaan dengan melindungi identitas dan infrastruktur layanan yang mendasarinya dari paparan. Aktifkan akses hanya melalui autentikasi modern untuk layanan dan akses jarak jauh yang aman (juga dilindungi oleh autentikasi modern) untuk infrastruktur.

  • Penetapan peran tingkat direktori - Hindari atau kurangi jumlah penetapan peran tingkat direktori (Administrator Pengguna pada cakupan direktori alih-alih cakupan AU) atau peran direktori khusus layanan dengan tindakan sarana kontrol (Admin Knowledge dengan izin untuk mengelola keanggotaan kelompok keamanan).

Selain panduan dalam panduan operasi umum Microsoft Entra, kami juga merekomendasikan pertimbangan berikut untuk lingkungan yang terisolasi.

Provisi identitas manusia

Akun Istimewa

Memprovisikan akun di lingkungan terisolasi untuk personel administratif dan tim TI yang mengoperasikan lingkungan. Ini memungkinkan Anda menambahkan kebijakan keamanan yang lebih kuat seperti kontrol akses berbasis perangkat untuk stasiun kerja yang aman. Seperti yang dibahas di bagian sebelumnya, lingkungan nonproduksi berpotensi menggunakan kolaborasi Microsoft Entra B2B untuk onboard akun istimewa ke penyewa non-produksi menggunakan kontrol postur dan keamanan yang sama yang dirancang untuk akses istimewa di lingkungan produksi mereka.

Akun khusus cloud adalah cara paling sederhana untuk menyediakan identitas manusia di penyewa Microsoft Entra dan cocok untuk lingkungan lapangan hijau. Namun, jika terdapat infrastruktur lokal yang sudah ada yang sesuai dengan lingkungan yang terisolasi (misalnya, forest Active Directory pra-produksi atau manajemen), Anda dapat mempertimbangkan untuk menyinkronkan identitas dari sana. Ini berlaku terutama jika infrastruktur lokal yang dijelaskan di sini digunakan untuk solusi IaaS yang memerlukan akses server untuk mengelola sarana data solusi. Untuk informasi selengkapnya, lihat Melindungi Microsoft 365 dari serangan lokal. Menyinkronkan dari lingkungan lokal yang terisolasi mungkin juga diperlukan jika terdapat persyaratan kepatuhan peraturan tertentu seperti autentikasi khusus kartu pintar.

Catatan

Tidak ada kontrol teknis untuk melakukan pemeriksaan identitas untuk akun Microsoft Entra B2B. Identitas eksternal yang disediakan dengan Microsoft Entra B2B di-bootstrap dengan satu faktor. Mitigasi ini dilakukan agar organisasi memiliki proses untuk membuktikan identitas yang diperlukan sebelum undangan B2B dikeluarkan dan tinjauan akses reguler identitas eksternal untuk mengelola siklus hidup. Pertimbangkan untuk mengaktifkan kebijakan Akses Bersyarkat untuk mengontrol pendaftaran MFA.

Peran outsourcing berisiko tinggi

Untuk mengurangi ancaman di dalam, dimungkinkan untuk mengalihdayakan akses ke Administrator Global dan peran Administrator Peran Istimewa untuk dikelola penyedia layanan menggunakan kolaborasi Azure B2B atau mendelegasikan akses melalui mitra CSP atau mercusuar. Akses ini dapat dikontrol oleh staf internal melalui alur persetujuan di Azure Privileged Identity Management (PIM). Pendekatan ini dapat sangat mengurangi ancaman dari dalam. Ini adalah pendekatan yang dapat Anda gunakan untuk memenuhi tuntutan kepatuhan bagi pelanggan yang memiliki kekhawatiran.

Provisi identitas non-manusia

Akun akses darurat

Microsoft menyarankan agar organisasi memiliki dua akun akses darurat khusus cloud yang secara permanen menetapkan peran Administrator Global. Akun ini sangat istimewa dan tidak ditugaskan untuk individu tertentu. Akun terbatas pada skenario darurat atau "pecahkan kaca" di mana akun normal tidak dapat digunakan atau semua administrator lain secara tidak sengaja dikunci. Akun-akun ini harus dibuat mengikuti rekomendasi akun akses darurat.

Identitas terkelola Azure

Gunakan identitas terkelola Azure untuk sumber daya Azure yang memerlukan identitas layanan. Periksa daftar layanan yang mendukung identitas terkelola saat merancang solusi Azure Anda.

Jika identitas terkelola tidak didukung atau tidak memungkinkan, pertimbangkan untuk menyediakan objek perwakilan layanan.

Akun layanan hibrid

Beberapa solusi hibrid mungkin memerlukan akses ke sumber daya lokal dan cloud. Contoh kasus penggunaan adalah aplikasi yang menggunakan akun layanan di AD DS untuk akses ke server yang bergabung dengan domain lokal dan juga memiliki akun di ID Microsoft Entra karena memerlukan akses ke Microsoft Online Services.

Akun layanan lokal biasanya tidak memiliki kemampuan untuk masuk secara interaktif, yang berarti bahwa dalam skenario cloud mereka tidak dapat memenuhi persyaratan kredensial yang kuat seperti autentikasi multifaktor. Dalam skenario ini, jangan gunakan akun layanan yang telah disinkronkan dari lokal, tetapi sebaliknya gunakan identitas terkelola \ perwakilan layanan. Untuk perwakilan layanan (SP), gunakan sertifikat sebagai info masuk, atau lindungi SP dengan Akses Bersyarat.

Jika terdapat batasan teknis yang tidak memungkinkan hal ini dan akun yang sama harus digunakan untuk lokal dan cloud, maka terapkan kontrol kompensasi seperti Akses Bersyarat untuk mengunci akun hibrid yang berasal dari lokasi jaringan tertentu.

Penetapan Sumber Daya

Solusi perusahaan dapat terdiri dari beberapa sumber daya Azure dan aksesnya harus dikelola dan diatur sebagai unit penugasan logis - grup sumber daya. Dalam skenario tersebut, grup keamanan Microsoft Entra dapat dibuat dan dikaitkan dengan izin dan penetapan peran yang tepat di semua sumber daya solusi, sehingga menambahkan atau menghapus pengguna dari grup tersebut mengakibatkan mengizinkan atau menolak akses ke seluruh solusi.

Sebaiknya Gunakan lisensi berbasis grup dan grup keamanan untuk layanan Microsoft yang mengandalkan pengguna yang memiliki penetapan kursi lisensi sebagai prasyarat sebelum memberikan akses (misalnya, Dynamics 365, Power BI).

Grup asli cloud Microsoft Entra dapat diatur secara asli dari cloud jika dikombinasikan dengan tinjauan akses Microsoft Entra dan pengelolaan pemberian hak Microsoft Entra.

MICROSOFT Entra ID juga mendukung penetapan pengguna langsung ke layanan SaaS pihak ketiga (misalnya, Salesforce, Service Now) dan aplikasi lokal untuk akses menyeluruh dan provisi identitas. Penugasan langsung ke sumber daya dapat diatur secara asli dari cloud jika dikombinasikan dengan tinjauan akses Microsoft Entra dan pengelolaan pemberian hak Microsoft Entra. Penugasan langsung mungkin sesuai untuk penugasan sisi pengguna akhir.

Beberapa skenario mungkin memerlukan pemberian akses ke sumber daya lokal melalui kelompok keamanan Active Directory lokal. Untuk kasus tersebut, pertimbangkan siklus sinkronisasi ke ID Microsoft Entra saat merancang proses SLA.

Manajemen autentikasi

Bagian ini menjelaskan pemeriksaan yang harus dilakukan dan tindakan yang harus diambil untuk manajemen info masuk serta kebijakan akses berdasarkan postur keamanan organisasi Anda.

Manajemen info masuk yang kuat

Info masuk yang kuat

Semua identitas manusia (akun lokal dan identitas eksternal yang disediakan melalui kolaborasi B2B) di lingkungan terisolasi harus disediakan dengan kredensial autentikasi yang kuat seperti autentikasi multifaktor atau kunci FIDO. Lingkungan dengan infrastruktur lokal yang mendasar dengan autentikasi yang kuat seperti autentikasi kartu pintar dapat terus menggunakan autentikasi kartu pintar di cloud.

Info masuk tanpa kata sandi

Solusi tanpa kata sandi adalah solusi terbaik untuk memastikan metode autentikasi yang paling nyaman dan aman. Info masuk tanpa kata sandi seperti kunci keamanan FIDO dan Windows Hello untuk Bisnis direkomendasikan untuk identitas manusia dengan peran istimewa.

Perlindungan kata sandi

Jika lingkungan disinkronkan dari forest Active Directory lokal, Anda harus menyebarkan perlindungan kata sandi Microsoft Entra untuk menghilangkan kata sandi yang lemah di organisasi Anda. Penguncian cerdas Microsoft Entra juga harus digunakan di lingkungan hibrid atau khusus cloud untuk mengunci pelaku jahat yang mencoba menebak kata sandi pengguna Anda atau menggunakan metode brute-force untuk masuk.

Manajemen kata sandi layanan mandiri

Pengguna yang perlu mengubah atau menyetel ulang kata sandi mereka adalah salah satu sumber volume dan biaya panggilan staf dukungan terbesar. Selain biaya, mengubah kata sandi sebagai alat untuk mengurangi risiko pengguna adalah langkah mendasar dalam meningkatkan postur keamanan organisasi Anda. Minimal, sebarkan Manajemen Kata Sandi Mandiri untuk akun pengujian dan manusia dengan kata sandi untuk mengalihkan panggilan staf dukungan.

Kata sandi identitas eksternal

Dengan menggunakan kolaborasi Microsoft Entra B2B, proses undangan dan penukaran memungkinkan pengguna eksternal seperti mitra, pengembang, dan subkontraktor menggunakan kredensial mereka sendiri untuk mengakses sumber daya perusahaan Anda. Hal ini mengurangi kebutuhan untuk memperkenalkan lebih banyak kata sandi ke dalam penyewa yang terisolasi.

Catatan

Beberapa aplikasi, infrastruktur, atau alur kerja mungkin memerlukan info masuk lokal. Evaluasi hal ini berdasarkan kasus per kasus.

Info masuk perwakilan layanan

Untuk skenario di mana perwakilan layanan diperlukan, gunakan info masuk sertifikat untuk perwakilan layanan atau Akses Bersyarat untuk identitas beban kerja. Jika perlu, gunakan rahasia klien sebagai pengecualian untuk kebijakan organisasi.

Dalam kedua kasus, Azure Key Vault dapat digunakan bersama dengan identitas terkelola Azure, sehingga lingkungan runtime (misalnya, fungsi Azure) dapat mengambil info masuk dari Azure Key Vault.

Periksa contoh berikut untuk membuat perwakilan layanan dengan sertifikat yang ditandatangani sendiri untuk autentikasi perwakilan layanan dengan info masuk sertifikat.

Kebijakan akses

Di bagian berikut adalah rekomendasi untuk solusi Azure. Untuk panduan umum tentang kebijakan Akses Bersyar untuk masing-masing lingkungan, periksa Praktik Terbaik Akses Bersyar, Panduan Operasi Microsoft Entra, dan Akses Bersyarah untuk Zero Trust:

  • Tentukan kebijakan Akses Bersyar untuk aplikasi cloud WINDOWS Azure Service Management API untuk memberlakukan postur keamanan identitas saat mengakses Azure Resource Manager. Ini harus mencakup kontrol pada MFA dan kontrol berbasis perangkat untuk mengaktifkan akses hanya melalui stasiun kerja yang aman (lebih lanjut tentang hal ini di bagian Peran Istimewa di bawah Tata Kelola Identitas). Selain itu, gunakan Akses Bersyarat untuk memfilter perangkat.

  • Semua aplikasi yang di-onboard ke lingkungan terisolasi harus memiliki kebijakan Akses Bersyarat eksplisit yang diterapkan sebagai bagian dari proses onboarding.

  • Tentukan kebijakan Akses Bersyarat untuk pendaftaran informasi keamanan yang mencerminkan akar aman proses kepercayaan lokal (misalnya, untuk stasiun kerja di lokasi fisik, dapat diidentifikasi oleh alamat IP, yang harus dikunjungi karyawan secara langsung untuk verifikasi).

  • Pertimbangkan untuk menggunakan Akses Bersyarat guna membatasi identitas beban kerja. Buat kebijakan untuk membatasi atau mengontrol akses dengan lebih baik berdasarkan lokasi atau keadaan relevan lainnya.

Tantangan Autentikasi

  • Identitas eksternal yang disediakan dengan Microsoft Entra B2B mungkin perlu memprovisikan ulang kredensial autentikasi multifaktor di penyewa sumber daya. Hal ini mungkin diperlukan jika kebijakan akses lintas penyewa belum disiapkan dengan penyewa sumber daya. Hal ini berarti bahwa proses onboarding ke sistem di-bootstrap dengan satu faktor. Dengan pendekatan ini, mitigasi risikonya adalah agar organisasi memiliki proses untuk membuktikan profil risiko info masuk dan pengguna sebelum undangan B2B dikeluarkan. Selain itu, tentukan Akses Bersyarat ke proses pendaftaran seperti yang dijelaskan sebelumnya.

  • Gunakan pengaturan akses lintas penyewa Identitas eksternal untuk mengelola cara mereka berkolaborasi dengan organisasi Microsoft Entra lainnya dan cloud Microsoft Azure lainnya melalui kolaborasi B2B dan koneksi langsung B2B.

  • Untuk konfigurasi dan kontrol perangkat tertentu, Anda dapat menggunakan filter perangkat dalam kebijakan Akses Bersyarat untuk menargetkan atau mengecualikan perangkat tertentu. Hal ini memungkinkan Anda membatasi akses ke alat manajemen Azure dari stasiun kerja admin aman (SAW) yang ditunjuk. Pendekatan lain yang dapat Anda ambil termasuk menggunakan Azure Virtual Desktop, Azure Bastion, atau PC Cloud.

  • Aplikasi manajemen penagihan seperti portal Azure EA atau akun penagihan MCA tidak direpresentasikan sebagai aplikasi cloud untuk penargetan Akses Bersyarat. Sebagai kontrol kompensasi, tentukan akun administrasi terpisah dan targetkan kebijakan Akses Bersyarat ke akun tersebut menggunakan ketentuan "Semua Aplikasi".

Tata Kelola Identitas

Peran istimewa

Di bawah ini adalah beberapa prinsip tata kelola identitas yang perlu dipertimbangkan di semua konfigurasi penyewa untuk isolasi.

  • Tidak ada akses tetap - Tidak ada identitas manusia yang memiliki akses tetap untuk melakukan operasi istimewa di lingkungan yang terisolasi. Kontrol akses berbasis Peran Azure (RBAC) terintegrasi dengan Microsoft Entra Privileged Identity Management (PIM). PIM menyediakan aktivasi just-in-time yang ditentukan oleh gerbang keamanan seperti autentikasi multifaktor, alur kerja persetujuan, dan durasi terbatas.

  • Jumlah admin - Organisasi harus menentukan jumlah minimum dan maksimum manusia yang memegang peran istimewa untuk mengurangi risiko kelangsungan bisnis. Dengan peran istimewa yang terlalu sedikit, mungkin tidak ada cukup cakupan zona waktu. Mitigasi risiko keamanan dengan memiliki administrator sesedikit mungkin, mengikuti prinsip hak istimewa paling sedikit.

  • Membatasi akses istimewa - Buat grup khusus cloud dan peran yang dapat ditetapkan untuk hak istimewa tinggi atau hak istimewa sensitif. Hal ini menawarkan perlindungan pengguna yang ditetapkan dan objek grup.

  • Akses dengan hak istimewa paling sedikit - Identitas hanya boleh diberikan izin sesuai yang diperlukan untuk melakukan operasi istimewa sesuai perannya dalam organisasi.

    • Peran kustom RBAC Azure memungkinkan Anda untuk merancang peran dengan hak istimewa paling sedikit berdasarkan kebutuhan organisasi. Kami menyarankan agar definisi peran kustom ditulis atau ditinjau oleh tim keamanan khusus dan mengurangi risiko hak istimewa yang tidak diinginkan. Penulisan peran kustom dapat diaudit melalui Azure Policy.

    • Untuk mengurangi penggunaan peran yang tidak disengaja yang tidak dimaksudkan untuk penggunaan yang lebih luas dalam organisasi, gunakan Azure Policy untuk menentukan secara eksplisit definisi peran mana yang dapat digunakan untuk menetapkan akses. Pelajari lebih lanjut dari Sampel GitHub ini.

  • Akses istimewa dari stasiun kerja yang aman - Semua akses istimewa harus dilakukan dari perangkat yang aman dan terkunci. Memisahkan tugas dan akun sensitif ini dari stasiun kerja dan perangkat penggunaan sehari-hari memberikan perlindungan yang sangat kuat dari serangan pengelabuan, kerentanan aplikasi dan OS, berbagai serangan penyamaran identitas, serta serangan pencurian info masuk seperti pengelogan keystroke, Pass-the-Hash, dan Pass-The-Ticket.

Beberapa pendekatan yang dapat Anda gunakan untuk menggunakan perangkat aman sebagai bagian dari cerita akses istimewa Anda termasuk menggunakan kebijakan Akses Bersyarat untuk menargetkan atau mengecualikan perangkat tertentu, menggunakan Azure Virtual Desktop, Azure Bastion, atau PC Cloud, atau membuat stasiun kerja yang dikelola Azure atau stasiun kerja akses istimewa.

  • Pagar pembatas proses peran istimewa - Organisasi harus menentukan proses dan pagar pembatas teknis untuk memastikan bahwa operasi istimewa dapat dijalankan kapan pun saat diperlukan sambil mematuhi persyaratan peraturan. Contoh kriteria pagar pembatas meliputi:

    • Kualifikasi manusia dengan peran istimewa (misalnya, karyawan/vendor penuh waktu, tingkat izin, kewarganegaraan)

    • Ketidaksesuaian eksplisit dari peran (juga dikenal sebagai pemisahan tugas). Contohnya termasuk tim dengan peran direktori Microsoft Entra tidak boleh bertanggung jawab untuk mengelola peran istimewa Azure Resource Manager, dan sebagainya.

    • Baik penetapan grup atau pengguna langsung lebih disukai untuk peran yang mana.

  • Memantau penugasan IAM di luar Microsoft Entra PIM tidak diotomatisasi melalui Kebijakan Azure. Mitigasinya adalah tidak memberikan peran Pemilik Langganan atau Administrator Akses Pengguna kepada tim teknik. Sebagai gantinya, buat grup yang ditetapkan ke peran dengan hak istimewa paling sedikit seperti Kontributor dan delegasikan manajemen grup tersebut ke tim teknik.

Akses sumber daya

  • Pengesahan - Identitas yang memegang peran istimewa harus ditinjau secara berkala untuk menjaga keanggotaan tetap terkini dan terjustifikasi. Tinjauan akses Microsoft Entra terintegrasi dengan peran Azure RBAC, keanggotaan grup, dan identitas eksternal Microsoft Entra B2B.

  • Siklus hidup - Operasi istimewa mungkin memerlukan akses ke beberapa sumber daya seperti lini aplikasi bisnis, Aplikasi SaaS, dan grup sumber daya Azure juga langganan. Microsoft Entra Entitlement Management memungkinkan penentuan paket akses yang mewakili sumber daya yang ditetapkan untuk pengguna sebagai unit, menetapkan periode validitas, alur kerja persetujuan, dan sebagainya.

Manajemen siklus hidup langganan dan penyewa

Siklus hidup penyewa

  • Sebaiknya terapkan proses untuk meminta penyewa Microsoft Entra perusahaan baru. Proses ini harus memperhitungkan:

    • Pembenaran bisnis untuk membuatnya. Membuat penyewa Microsoft Entra baru akan meningkatkan kompleksitas secara signifikan, jadi kunci untuk memastikan apakah penyewa baru diperlukan.

    • Cloud Azure tempat cloud harus dibuat (misalnya, Komersial, Pemerintah, dan sebagainya).

    • Apakah ini adalah produksi atau non-produksi

    • Persyaratan residensi data direktori

    • Siapa yang akan mengelolanya

    • Pelatihan dan pemahaman tentang persyaratan keamanan umum.

  • Setelah disetujui, penyewa Microsoft Entra akan dibuat, dikonfigurasi dengan kontrol garis besar yang diperlukan, dan di-onboarding di bidang penagihan, pemantauan, dan sebagainya.

  • Tinjauan rutin penyewa Microsoft Entra di bidang penagihan perlu diterapkan untuk mendeteksi dan menemukan pembuatan penyewa di luar proses yang diatur. Lihat bagian Inventori dan Visibilitas dokumen ini untuk detail lebih lanjut.

  • Pembuatan penyewa Azure AD B2C dapat dikontrol menggunakan Azure Policy. Kebijakan dijalankan saat langganan Azure dikaitkan dengan penyewa B2C (prasyarat untuk penagihan). Pelanggan dapat membatasi pembuatan penyewa Azure AD B2C ke grup manajemen tertentu.

  • Tidak ada kontrol teknis untuk melakukan subordinasi pembuatan penyewa ke organisasi. Namun, aktivitas tercatat dalam Log audit. Proses onboarding ke bidang penagihan adalah kontrol kompensasi di awal. Hal ini perlu dilengkapi dengan pemantauan dan pemberitahuan sebagai gantinya.

Siklus hidup langganan

Di bawah ini adalah beberapa pertimbangan saat merancang proses siklus hidup langganan yang diatur:

  • Tentukan taksonomi aplikasi dan solusi yang memerlukan sumber daya Azure. Semua tim yang meminta langganan harus menyediakan "pengidentifikasi produk" mereka saat meminta langganan. Taksonomi informasi ini akan menentukan:

    • Penyewa Microsoft Entra untuk menyediakan langganan

    • Akun Azure EA yang akan digunakan untuk pembuatan langganan

    • Konvensi penamaan

    • Penetapan grup manajemen

    • Aspek lain seperti penandaan, pengisian silang, penggunaan tampilan produk, dan sebagainya.

  • Jangan izinkan pembuatan langganan ad-hoc melalui portal atau dengan cara lainnya. Sebagai gantinya pertimbangkan untuk mengelola langganan secara terprogram menggunakan Azure Resource Manager dan menarik laporan konsumsi serta penagihan secara terprogram. Hal ini dapat membantu membatasi provisi langganan kepada pengguna yang berwenang serta memberlakukan tujuan kebijakan dan taksonomi Anda. Panduan tentang prinsipal AZOps berikut dapat digunakan untuk membantu menciptakan solusi praktis.

  • Saat langganan disediakan, buat grup cloud Microsoft Entra untuk menyimpan Peran Azure Resource Manager standar yang diperlukan oleh tim aplikasi seperti Kontributor, Pembaca, dan peran kustom yang disetujui. Hal ini memungkinkan Anda mengelola penetapan peran RBAC Azure dengan akses istimewa yang diatur dalam skala besar.

    1. Konfigurasikan grup agar memenuhi syarat untuk peran Azure RBAC menggunakan Microsoft Entra PIM dengan kontrol yang sesuai seperti kebijakan aktivasi, tinjauan akses, pemberi izin, dan sebagainya.

    2. Kemudian delegasikan manajemen grup kepada pemilik solusi.

    3. Sebagai pagar pembatas, jangan tetapkan pemilik produk ke peran Administrator Akses Pengguna atau Pemilik untuk menghindari penetapan peran langsung yang tidak disengaja di luar Microsoft Entra PIM, atau berpotensi mengubah langganan ke penyewa yang berbeda sama sekali.

    4. Bagi pelanggan yang memilih untuk mengaktifkan manajemen langganan lintas penyewa di penyewa non-produksi melalui Azure Lighthouse, pastikan bahwa kebijakan akses yang sama dari akun istimewa produksi (misalnya, akses istimewa hanya dari stasiun kerja aman) diberlakukan saat mengautentikasi untuk mengelola langganan.

  • Jika organisasi Anda memiliki arsitektur referensi yang telah disetujui sebelumnya, provisi langganan dapat diintegrasikan dengan alat penyebaran sumber daya seperti Azure Blueprints atau Terraform.

  • Mengingat afinitas penyewa untuk Langganan Azure, provisi langganan harus mengetahui beberapa identitas untuk aktor manusia yang sama (karyawan, mitra, vendor, dan sebagainya) di beberapa penyewa dan menetapkan akses yang sesuai.

Peran EA dan MCA

  • Portal Perjanjian Enterprise Azure (Azure EA) tidak berintegrasi dengan RBAC Azure atau Akses Bersyarat. Mitigasi untuk hal ini adalah menggunakan akun administrasi khusus yang dapat ditargetkan dengan kebijakan dan pemantauan tambahan.

  • Portal Enterprise Azure EA tidak menyediakan log audit. Sebagai mitigasi, pertimbangkan proses yang diatur otomatis untuk memprovisikan langganan dengan pertimbangan yang dijelaskan di atas dan gunakan akun khusus EA serta audit log autentikasi.

  • Peran Perjanjian Pelanggan Microsoft (MCA) tidak berintegrasi secara asli dengan PIM. Sebagai mitigasi, gunakan akun khusus MCA dan pantau penggunaan akun ini.

Penyewa Azure AD B2C

  • Dalam penyewa Azure AD B2C, peran bawaan tidak mendukung PIM. Untuk meningkatkan keamanan, sebaiknya gunakan kolaborasi Microsoft Entra B2B untuk onboarding tim teknik yang mengelola Customer Identity Access Management (CIAM) dari penyewa Azure Anda, tetapkan ke peran istimewa Azure AD B2C dan terapkan kebijakan Akses Bersyariah ke akun administrasi khusus ini.

  • Peran istimewa penyewa Azure AD B2C tidak terintegrasi dengan tinjauan akses Microsoft Entra. Mitigasinya adalah membuat akun khusus di penyewa Microsoft Entra organisasi, menambahkan akun ini ke grup dan melakukan tinjauan akses reguler pada grup ini.

  • Mengikuti panduan akses darurat untuk ID Microsoft Entra di atas, pertimbangkan untuk membuat akun akses darurat yang setara selain administrator eksternal yang dijelaskan di atas.

  • Kami merekomendasikan kepemilikan logis dari langganan Microsoft Entra yang mendasari penyewa B2C selaras dengan tim teknik CIAM, dengan cara yang sama seperti langganan Azure lainnya digunakan untuk solusi B2C.

Operasional

Berikut ini adalah pertimbangan operasional tambahan untuk ID Microsoft Entra, khusus untuk beberapa lingkungan yang terisolasi. Periksa Azure Cloud Adoption Framework, tolok ukur keamanan cloud Microsoft, dan panduan Operasi Microsoft Entra untuk panduan terperinci untuk mengoperasikan lingkungan individual.

Peran dan tanggung jawab lintas lingkungan

Arsitektur SecOps di seluruh perusahaan - Anggota tim operasi dan keamanan dari semua lingkungan dalam organisasi harus bersama-sama menentukan hal berikut:

  • Prinsip untuk menentukan kapan lingkungan perlu dibuat, dikonsolidasikan, atau tidak digunakan lagi.

  • Prinsip untuk menentukan hierarki grup manajemen pada setiap lingkungan.

  • Postur keamanan bidang penagihan (portal EA/MCA), postur operasional, dan pendekatan delegasi.

  • Proses pembuatan penyewa.

  • Taksonomi aplikasi Enterprise.

  • Proses provisi langganan Azure.

  • Batas otonomi isolasi dan administrasi serta penilaian risiko di seluruh tim dan lingkungan.

  • Konfigurasi garis besar umum dan kontrol keamanan (teknis dan kompensasi) serta garis besar operasional yang akan digunakan di semua lingkungan.

  • Prosedur dan alat operasional standar umum yang mencakup beberapa lingkungan (misalnya, pemantauan, provisi).

  • Delegasi peran yang disepakati di beberapa lingkungan.

  • Pemisahan tugas di seluruh lingkungan.

  • Manajemen rantai pasokan umum untuk stasiun kerja istimewa.

  • Konvensi penamaan.

  • Mekanisme korelasi lintas lingkungan.

Pembuatan penyewa - Tim tertentu harus dimiliki terkait pembuatan penyewa mengikuti prosedur standar yang ditentukan oleh arsitektur SecOps di seluruh perusahaan. Drive ini termasuk:

  • Penyediaan lisensi yang mendasar (misalnya, Microsoft 365).

  • Onboarding ke paket penagihan perusahaan (misalnya, Azure EA atau MCA).

  • Pembuatan hierarki grup manajemen Azure.

  • Konfigurasi kebijakan manajemen untuk berbagai perimeter termasuk identitas, perlindungan data, Azure, dan sebagainya.

  • Penyebaran tumpukan keamanan per disepakati pada arsitektur keamanan cyber, termasuk pengaturan diagnostik, onboarding SIEM, onboarding CASB, onboarding PIM, dan sebagainya.

  • Konfigurasi peran Microsoft Entra berdasarkan delegasi yang disepakati.

  • Konfigurasi dan distribusi stasiun kerja istimewa awal.

  • Provisi akun akses darurat.

  • Konfigurasi tumpukan provisi identitas.

Arsitektur alat lintas lingkungan - Beberapa alat seperti provisi identitas dan alur kontrol sumber mungkin harus berfungsi di beberapa lingkungan. Alat ini harus dianggap penting bagi infrastruktur dan harus dirancang, didesain, diimplementasikan, dan dikelola secara demikian. Sehingga arsitek dari semua lingkungan harus terlibat setiap kali alat lintas lingkungan perlu didefinisikan.

Inventaris dan visibilitas

Penemuan langganan Azure - Untuk setiap penyewa yang ditemukan, Administrator Global Microsoft Entra dapat meningkatkan akses untuk mendapatkan visibilitas semua langganan di lingkungan. Elevasi ini akan menetapkan peran bawaan Administrator Akses Pengguna kepada mereka di grup manajemen akar.

Catatan

Tindakan ini sangat istimewa dan mungkin memberi admin akses ke langganan yang menyimpan informasi yang sangat sensitif jika data tersebut belum diisolasi dengan benar.

Mengaktifkan akses baca untuk menemukan sumber daya - Grup manajemen memungkinkan penugasan RBAC dalam skala besar di beberapa langganan. Pelanggan dapat memberikan peran Pembaca ke tim IT terpusat dengan mengonfigurasi penetapan peran di grup manajemen akar, yang akan disebarluaskan ke semua langganan di lingkungan.

Penemuan sumber daya - Setelah mendapatkan akses Baca sumber daya di lingkungan, Azure Resource Graph dapat digunakan untuk mengkueri sumber daya di lingkungan.

Pengelogan dan pemantauan

Manajemen log keamanan pusat - Menyerap log dari setiap lingkungan dengan cara terpusat, mengikuti praktik terbaik yang konsisten di seluruh lingkungan (misalnya, pengaturan diagnostik, retensi log, penyerapan SIEM, dan sebagainya). Azure Monitor dapat digunakan untuk menyerap log dari berbagai sumber seperti perangkat titik akhir, jaringan, log keamanan sistem operasi, dan sebagainya.

Informasi terperinci tentang menggunakan proses dan alat otomatis atau manual untuk memantau log sebagai bagian dari operasi keamanan Anda tersedia di panduan operasi keamanan Microsoft Entra.

Beberapa lingkungan mungkin memiliki persyaratan peraturan yang membatasi data mana (jika ada) yang dapat meninggalkan lingkungan tertentu. Jika pemantauan terpusat di seluruh lingkungan tidak dimungkinkan, tim harus memiliki prosedur operasional untuk menghubungkan aktivitas identitas di seluruh lingkungan untuk tujuan audit dan forensik seperti upaya gerakan lateral lintas lingkungan. Disarankan agar pengidentifikasi unik objek identitas manusia milik orang yang sama dapat ditemukan, berpotensi sebagai bagian dari sistem provisi identitas.

Strategi log harus menyertakan log Microsoft Entra berikut untuk setiap penyewa yang digunakan dalam organisasi:

  • Aktivitas rincian masuk

  • Log audit

  • kejadian risiko

MICROSOFT Entra ID menyediakan integrasi Azure Monitor untuk log aktivitas masuk dan log audit. Kejadian risiko dapat diproses melalui API Microsoft Graph.

Diagram berikut menunjukkan berbagai sumber data yang perlu dimasukkan sebagai bagian dari strategi pemantauan:

Penyewa Azure AD B2C dapat diintegrasikan dengan Azure Monitor. Sebaiknya pantau Azure AD B2C menggunakan kriteria yang sama yang dibahas di atas untuk ID Microsoft Entra.

Langganan yang telah mengaktifkan manajemen lintas penyewa dengan Azure Lighthouse dapat mengaktifkan pemantauan lintas penyewa jika log dikumpulkan oleh Azure Monitor. Ruang kerja Analitik Log terkait dapat berada di penyewa sumber daya dan dapat dianalisis secara terpusat di penyewa pengelola menggunakan buku kerja Azure Monitor. Untuk mempelajari selengkapnya, periksa Memantau sumber daya yang didelegasikan dalam skala besar - Azure Lighthouse.

Log keamanan OS infrastruktur hibrid

Semua log OS infrastruktur identitas hibrid harus diarsipkan dan dipantau dengan hati-hati sebagai sistem Tingkat 0, mengingat implikasi area permukaan. Drive ini termasuk:

  • Proksi Aplikasi Web dan server Active Directory Federation Services

  • Microsoft Entra Connect

  • Agen Proksi Aplikasi

  • Agen tulis balik kata sandi

  • Komputer Gateway Proteksi Kata Sandi

  • NPS yang memiliki ekstensi RADIUS autentikasi multifaktor Microsoft Entra

Microsoft Entra Connect Health harus disebarkan untuk memantau sinkronisasi identitas dan federasi (jika berlaku) untuk semua lingkungan.

Retensi penyimpanan log - Semua lingkungan harus memiliki implementasi, desain, dan strategi retensi penyimpanan log kohesif untuk memfasilitasi toolset yang konsisten (misalnya, sistem SIEM seperti Azure Sentinel), kueri umum, investigasi, dan playbook forensik. Azure Policy dapat digunakan untuk menyiapkan pengaturan diagnostik.

Pemantauan dan peninjauan log - Tugas operasional terkait pemantauan identitas harus konsisten dan memiliki pemilik di setiap lingkungan. Seperti yang dijelaskan di atas, berusahalah untuk mengonsolidasikan tanggung jawab ini di seluruh lingkungan sejauh yang diizinkan oleh persyaratan isolasi dan kepatuhan peraturan.

Skenario berikut harus dipantau dan diselidiki secara eksplisit:

  • Aktivitas mencurigakan - Semua peristiwa risiko Microsoft Entra harus dipantau untuk aktivitas yang mencurigakan. Semua penyewa harus menentukan lokasi bernama jaringan untuk menghindari deteksi berisik pada sinyal berbasis lokasi. Microsoft Entra ID Protection terintegrasi secara asli dengan Azure Security Center. Setiap investigasi deteksi risiko disarankan agar mencakup semua lingkungan yang disediakan identitas (misalnya, jika identitas manusia memiliki deteksi risiko aktif di penyewa perusahaan, tim yang mengoperasikan penyewa yang dihadapi pelanggan juga harus menyelidiki aktivitas akun yang sesuai di lingkungan tersebut).

  • Pemberitahuan analitik perilaku entitas pengguna (UEBA) - UEBA harus digunakan untuk mendapatkan informasi yang berguna berdasarkan deteksi anomali. Aplikasi Defender untuk Cloud Microsoft 365 Microsoft menyediakan UEBA di cloud. Pelanggan dapat mengintegrasikan UEBA lokal dari Pertahanan Microsoft 365 untuk Identitas Microsoft. MCAS membaca sinyal dari Microsoft Entra ID Protection.

  • Aktivitas akun akses darurat - Akses apa pun yang menggunakan akun akses darurat harus dipantau dan pemberitahuan dibuat untuk penyelidikan. Pemantauan ini harus mencakup:

    • Rincian masuk

    • Manajemen info masuk yang kuat

    • Setiap pembaruan pada keanggotaan grup

    • Penugasan Aplikasi

  • Akun manajemen penagihan - Mengingat sensitivitas akun dengan peran manajemen penagihan di Azure EA atau MCA, serta hak istimewanya yang signifikan, disarankan untuk memantau dan membuat pemberitahuan terkait:

    • Upaya masuk yang dilakukan akun dengan peran penagihan.

    • Setiap upaya untuk mengautentikasi ke aplikasi selain Portal EA.

    • Setiap upaya untuk mengautentikasi ke aplikasi selain Manajemen Sumber Daya Azure jika menggunakan akun khusus untuk tugas penagihan MCA.

    • Penugasan ke sumber daya Azure menggunakan akun khusus untuk tugas penagihan MCA.

  • Aktivitas peran istimewa - Mengonfigurasi dan meninjau pemberitahuan keamanan yang dihasilkan oleh Microsoft Entra PIM. Jika mengunci penetapan RBAC langsung tidak sepenuhnya dapat diberlakukan dengan kontrol teknis (misalnya, peran Pemilik harus diberikan kepada tim produk untuk melakukan pekerjaan mereka), maka pantau penugasan langsung peran istimewa di luar PIM dengan menghasilkan pemberitahuan setiap kali pengguna ditetapkan secara langsung untuk mengakses langganan dengan RBAC Azure.

  • Penetapan peran klasik - Organisasi harus menggunakan infrastruktur peran RBAC Azure modern alih-alih peran klasik. Sehingga, peristiwa berikut harus dipantau:

    • Penugasan ke peran klasik di tingkat langganan

  • Konfigurasi di seluruh penyewa - Layanan konfigurasi di seluruh penyewa apa pun harus menghasilkan pemberitahuan di dalam sistem.

    • Memperbarui Domain Kustom

    • Memperbarui branding

    • Daftar izinkan/blokir Microsoft Entra B2B

    • Penyedia identitas yang diizinkan Microsoft Entra B2B (IDP SAML melalui federasi langsung atau Masuk Sosial)

    • Perubahan Kebijakan Akses Bersyarat

  • Objek aplikasi dan objek perwakilan layanan

    • Aplikasi atau perwakilan layanan baru yang mungkin memerlukan kebijakan Akses Bersyarat

    • Aktivitas Izin aplikasi

  • Aktivitas grup manajemen - Aspek Identitas grup manajemen berikut harus dipantau:

    • Penetapan peran RBAC di MG

    • Kebijakan Azure yang diterapkan di MG

    • Langganan yang dipindahkan antar MG

    • Setiap perubahan pada kebijakan keamanan pada MG Akar

  • Peran kustom

    • Pembaruan definisi peran kustom

    • Peran kustom baru dibuat

  • Pemisahan kustom aturan tugas - Jika organisasi Anda menetapkan pemisahan aturan tugas, gunakan paket akses tidak kompatibel Microsoft Entra Entitlement Management untuk memberlakukan pemisahan tugas, dan membuat pemberitahuan atau mengonfigurasi tinjauan berkala untuk mendeteksi pelanggaran oleh administrator.

Pertimbangan pemantauan lainnya - Langganan Azure yang berisi sumber daya yang digunakan untuk Manajemen Log harus dianggap sebagai infrastruktur penting (Tingkat 0) dan dikunci ke tim Operasi Keamanan dari lingkungan yang sesuai. Pertimbangkan untuk menggunakan alat seperti Azure Policy untuk menerapkan kontrol tambahan ke langganan ini.

Alat operasional

Pertimbangan desain alat lintas lingkungan:

  • Jika memungkinkan, alat operasional yang akan digunakan di beberapa penyewa harus dirancang untuk berjalan sebagai aplikasi multi-penyewa Microsoft Entra untuk menghindari penyebaran ulang beberapa instans pada setiap penyewa dan menghindari inefisiensi operasional. Implementasi harus mencakup logika otorisasi guna memastikan bahwa isolasi antara pengguna dan data dipertahankan.

  • Tambahkan pemberitahuan dan deteksi untuk memantau otomatisasi lintas lingkungan (misalnya, provisi identitas) dan ambang batas untuk fail-safe. Misalnya, Anda mungkin menginginkan pemberitahuan jika deprovisi akun pengguna mencapai tingkat tertentu, karena mungkin menunjukkan bug atau kesalahan operasional yang dapat berdampak luas.

  • Otomatisasi apa pun yang mengatur tugas lintas lingkungan harus dioperasikan sebagai sistem yang sangat istimewa. Sistem ini harus ditempatkan di lingkungan keamanan tertinggi dan melakukan penarikan dari sumber luar jika data dari lingkungan lain diperlukan. Ambang batas dan validasi data perlu diterapkan untuk menjaga integritas sistem. Tugas lintas lingkungan yang umum adalah manajemen siklus hidup identitas guna menghapus identitas dari semua lingkungan untuk karyawan yang diberhentikan.

Alat manajemen layanan TI - Organisasi yang menggunakan sistem IT Service Management (ITSM) seperti ServiceNow harus mengonfigurasi pengaturan aktivasi peran Microsoft Entra PIM untuk meminta nomor tiket sebagai bagian dari tujuan aktivasi.

Demikian pula, Azure Monitor dapat diintegrasikan dengan sistem ITSM melalui Konektor Manajemen Layanan TI.

Praktik operasional - Minimalkan aktivitas operasional yang memerlukan akses langsung ke lingkungan ke identitas manusia. Sebagai gantinya, model mereka sebagai Azure Pipelines yang menjalankan operasi umum (misalnya, menambahkan kapasitas ke solusi PaaS, menjalankan diagnostik, dan sebagainya) dan memodelkan akses langsung ke antarmuka Azure Resource Manager untuk skenario "pecah kaca".

Tantangan operasi

  • Aktivitas Pemantauan Perwakilan Layanan terbatas untuk beberapa skenario

  • Pemberitahuan Microsoft Entra PIM tidak memiliki API. Mitigasinya adalah memiliki tinjauan rutin terhadap pemberitahuan PIM tersebut.

  • Portal Azure EA tidak menyediakan kemampuan pemantauan. Mitigasinya adalah memiliki akun administrasi khusus dan memantau aktivitas akun.

  • MCA tidak menyediakan log audit untuk tugas penagihan. Mitigasinya adalah memiliki akun administrasi khusus dan memantau aktivitas akun.

  • Beberapa layanan di Azure yang diperlukan untuk mengoperasikan lingkungan perlu disebarkan ulang dan dikonfigurasi ulang di seluruh lingkungan karena tidak boleh multi-penyewa atau multi-cloud.

  • Tidak ada cakupan API penuh di seluruh Layanan Online Microsoft untuk sepenuhnya mencapai infrastruktur sebagai kode. Mitigasinya adalah menggunakan API sebanyak mungkin dan menggunakan portal untuk sisanya. Inisiatif Sumber Terbuka ini membantu menentukan pendekatan yang mungkin berfungsi untuk lingkungan Anda.

  • Tidak ada kemampuan terprogram untuk menemukan penyewa sumber daya yang telah mendelegasikan akses langganan ke identitas di penyewa pengelola. Misalnya, jika alamat email mengaktifkan grup keamanan di penyewa contoso.com untuk mengelola langganan di penyewa fabrikam.com, administrator di contoso.com tidak memiliki API untuk menemukan bahwa delegasi ini dilakukan.

  • Pemantauan aktivitas akun tertentu (misalnya, akun break-glass, akun manajemen penagihan) tidak disediakan secara instan. Mitigasinya adalah pelanggan membuat aturan pemberitahuan mereka sendiri.

  • Pemantauan konfigurasi di seluruh penyewa tidak disediakan secara instan. Mitigasinya adalah pelanggan membuat aturan pemberitahuan mereka sendiri.

Langkah berikutnya