Membuat strategi manajemen kontrol akses yang tangguh dengan MICROSOFT Entra ID

  • Artikel

Catatan

Informasi yang terkandung dalam dokumen ini menunjukkan tampilan Microsoft Corporation saat ini tentang masalah yang dibahas pada tanggal publikasi. Karena Microsoft harus menanggapi perubahan kondisi pasar, microsoft tidak boleh ditafsirkan sebagai komitmen di pihak Microsoft, dan Microsoft tidak dapat menjamin keakuratan informasi apa pun yang disajikan setelah tanggal publikasi.

Organisasi yang mengandalkan kontrol akses tunggal, seperti autentikasi multifaktor atau satu lokasi jaringan, untuk mengamankan sistem TI mereka rentan terhadap kegagalan akses ke aplikasi dan sumber daya mereka jika kontrol akses tunggal tersebut menjadi tidak tersedia atau salah dikonfigurasi. Misalnya, bencana alam dapat mengakibatkan tidak tersedianya segmen besar infrastruktur telekomunikasi atau jaringan perusahaan. Gangguan seperti itu dapat mencegah pengguna akhir dan administrator untuk masuk.

Dokumen ini memberikan panduan tentang strategi yang harus diadopsi organisasi untuk memberikan ketangguhan guna mengurangi risiko penguncian selama gangguan yang tidak terduga dengan skenario berikut:

  • Organisasi dapat meningkatkan ketangguhan mereka untuk mengurangi risiko penguncian sebelum gangguan dengan menerapkan strategi mitigasi atau rencana kontingensi.
  • Organisasi dapat terus mengakses aplikasi dan sumber daya yang mereka pilih selama gangguan dengan memiliki strategi mitigasi dan rencana kontingensi di tempat.
  • Organisasi harus memastikan mereka mempertahankan informasi, seperti log, setelah gangguan dan sebelum mereka melakukan gulung balik pada kontingensi apa pun yang mereka terapkan.
  • Organisasi yang belum menerapkan strategi pencegahan atau rencana alternatif mungkin dapat menerapkan opsi darurat untuk menangani gangguan tersebut.

Panduan Kunci

Ada empat kunci takeaways dalam dokumen ini:

  • Menghindari penguncian administrator dengan menggunakan akun akses darurat.
  • Menerapkan MFA menggunakan Akses Bersyarat daripada MFA per pengguna.
  • Melakukan mitigasi penguncian pengguna dengan menggunakan beberapa kontrol Akses Bersyarat.
  • Melakukan mitigasi penguncian pengguna dengan memprovisikan beberapa metode autentikasi atau yang setara untuk setiap pengguna.

Sebelum gangguan

Mengurangi gangguan aktual harus menjadi fokus utama organisasi dalam menangani masalah kontrol akses yang mungkin timbul. Mengurangi mencakup perencanaan untuk aktivitas aktual ditambah menerapkan strategi untuk memastikan kontrol akses dan operasi tidak terpengaruh selama gangguan.

Mengapa Anda membutuhkan kontrol akses yang tangguh?

Identitas adalah sarana kontrol pengguna yang mengakses aplikasi dan sumber daya. Sistem identitas Anda mengontrol pengguna mana dan dalam kondisi mana, seperti kontrol akses atau persyaratan autentikasi, pengguna mendapatkan akses ke aplikasi. Saat satu atau beberapa persyaratan autentikasi atau kontrol akses tidak tersedia bagi pengguna untuk mengautentikasi karena keadaan yang tidak terduga, organisasi dapat mengalami salah satu atau kedua masalah berikut ini:

  • Penguncian administrator: Administrator tidak dapat mengelola penyewa atau layanan.
  • Penguncian pengguna: Pengguna tidak dapat mengakses aplikasi atau sumber daya.

Kontingensi penguncian administrator

Untuk membuka akses admin ke penyewa, Anda harus membuat akun akses darurat. Akun akses darurat ini, juga dikenal sebagai akun break glass , memungkinkan akses untuk mengelola konfigurasi Microsoft Entra ketika prosedur akses akun istimewa normal tidak tersedia. Setidaknya dua akun akses darurat harus dibuat mengikuti rekomendasi akun akses darurat.

Melakukan mitigasi penguncian pengguna

Untuk mengurangi risiko penguncian pengguna, gunakan kebijakan Akses Bersyar dengan beberapa kontrol untuk memberi pengguna pilihan tentang cara mereka mengakses aplikasi dan sumber daya. Dengan memberi pengguna pilihan antara, misalnya, masuk dengan MFA atau masuk dari perangkat yang dikelola atau masuk dari jaringan perusahaan, jika salah satu kontrol akses tidak tersedia pengguna memiliki opsi lain untuk terus bekerja.

Rekomendasi Microsoft

Menggabungkan kontrol akses berikut ini dalam kebijakan Akses Bersyarat yang sudah ada untuk organisasi:

  • Provisikan beberapa metode autentikasi untuk setiap pengguna yang mengandalkan saluran komunikasi yang berbeda, misalnya, aplikasi Microsoft Authenticator (berbasis internet), token OATH (dihasilkan di perangkat), dan SMS (telefonik).
  • Terapkan Windows Hello untuk Bisnis di perangkat Windows 10 untuk memenuhi persyaratan MFA langsung dari masuk perangkat.
  • Gunakan perangkat tepercaya melalui gabungan hibrid Microsoft Entra atau Microsoft Intune. Perangkat tepercaya meningkatkan pengalaman pengguna karena perangkat tepercaya itu sendiri dapat memenuhi persyaratan autentikasi kebijakan yang kuat tanpa tantangan MFA kepada pengguna. MFA kemudian akan diperlukan saat mendaftarkan perangkat baru dan ketika mengakses aplikasi atau sumber daya dari perangkat yang tidak tepercaya.
  • Gunakan kebijakan berbasis risiko Microsoft Entra ID Protection yang mencegah akses saat pengguna atau rincian masuk berisiko menggantikan kebijakan MFA tetap.
  • Jika Anda melindungi akses VPN menggunakan ekstensi NPS autentikasi multifaktor Microsoft Entra, pertimbangkan untuk menggabungkan solusi VPN Anda sebagai aplikasi SAML dan tentukan kategori aplikasi seperti yang direkomendasikan di bawah ini.

Catatan

Kebijakan berbasis risiko memerlukan lisensi Microsoft Entra ID P2 .

Contoh berikut menjelaskan kebijakan yang harus Anda buat untuk menyediakan kontrol akses yang tangguh bagi pengguna untuk mengakses aplikasi dan sumber daya mereka. Dalam contoh ini, Anda memerlukan AppUsers grup keamanan dengan pengguna target yang ingin Anda beri akses, grup bernama CoreAdmins dengan administrator inti, dan grup bernama EmergencyAccess dengan akun akses darurat. Contoh kumpulan kebijakan ini akan memberikan pengguna yang dipilih di AppUsers, akses ke aplikasi yang dipilih jika mereka terhubung dari perangkat tepercaya ATAU menyediakan autentikasi yang kuat, misalnya MFA. Contoh ini tidak termasuk akun darurat dan administrator inti.

Kebijakan mitigasi Akses Bersyar yang ditetapkan:

  • Kebijakan 1: Memblokir akses ke orang di luar grup target
    • Pengguna dan Grup: Menyertakan semua pengguna. Mengecualikan AppUsers, CoreAdmins, dan EmergencyAccess
    • Aplikasi Cloud: menyertakan semua aplikasi
    • Ketentuan: (Tidak Ada)
    • Kontrol Grant: Blokir
  • Kebijakan 2: Memberikan akses ke AppUsers yang memerlukan MFA ATAU perangkat tepercaya.
    • Pengguna dan Grup: Menyertakan AppUsers. Mengecualikan CoreAdmins, dan EmergencyAccess
    • Aplikasi Cloud: menyertakan semua aplikasi
    • Ketentuan: (Tidak Ada)
    • Kontrol Pemberian: Memberikan akses, memerlukan autentikasi multifaktor, mengharuskan perangkat untuk mematuhinya. Untuk beberapa kontrol: Memerlukan salah satu kontrol yang dipilih.

Kontingensi untuk penguncian pengguna

Atau, organisasi Anda juga dapat membuat kebijakan kontingensi. Untuk membuat kebijakan kontingensi, Anda harus menentukan kriteria tradeoff antara kelangsungan bisnis, biaya operasional, biaya keuangan, dan risiko keamanan. Misalnya, Anda dapat mengaktifkan kebijakan kontingensi hanya ke subset pengguna, untuk subset aplikasi, untuk subset klien, atau dari subset lokasi. Kebijakan kontingensi memberi administrator dan pengguna akhir akses ke aplikasi dan sumber daya, selama gangguan ketika tidak ada metode mitigasi yang diterapkan. Microsoft merekomendasikan untuk mengaktifkan kebijakan kontingensi dalam mode hanya laporan saat tidak digunakan sehingga administrator dapat memantau dampak potensial dari kebijakan jika perlu diaktifkan.

Memahami paparan Anda selama gangguan membantu mengurangi risiko Anda dan merupakan bagian penting dari proses perencanaan Anda. Untuk membuat rencana kontingensi Anda, pertama tentukan persyaratan bisnis organisasi Anda berikut:

  1. Menentukan aplikasi dengan misi penting Anda sebelumnya: Aplikasi apa yang harus Anda beri akses, bahkan dengan risiko/kondisi keamanan yang lebih rendah? Membuat daftar aplikasi ini dan memastikan pemangku kepentingan Anda yang lain (bisnis, keamanan, hukum, kepemimpinan) semua setuju bahwa jika semua kontrol akses hilang, aplikasi ini masih harus terus berjalan. Anda mungkin akan berakhir dengan kategori:
    • Aplikasi penting misi Kategori 1 yang tidak dapat tersedia selama lebih dari beberapa menit, misalnya Aplikasi yang secara langsung memengaruhi pendapatan organisasi.
    • Aplikasi penting Kategori 2 yang bisnisnya harus dapat diakses dalam beberapa jam.
    • Aplikasi prioritas rendah Kategori 3 yang dapat menahan gangguan beberapa hari.
  2. Untuk aplikasi dalam kategori 1 dan 2, Microsoft menyarankan Anda merencanakan terlebih dahulu jenis akses apa yang ingin Anda izinkan:
    • Apakah Anda ingin memperbolehkan akses penuh atau sesi terbatas, seperti membatasi pengunduhan?
    • Apakah Anda ingin mengizinkan akses ke sebagian aplikasi tetapi tidak ke seluruh aplikasi?
    • Apakah Anda ingin mengizinkan akses informasi pekerja dan memblokir akses administrator hingga kontrol akses dipulihkan?
  3. Untuk aplikasi tersebut, Microsoft juga menyarankan Anda merencanakan jalan akses mana yang sengaja Anda buka dan mana yang akan Anda tutup:
    • Apakah Anda ingin mengizinkan akses khusus browser dan memblokir klien mandiri yang memiliki banyak fitur, yang dapat menyimpan data offline?
    • Apakah Anda ingin mengizinkan akses hanya untuk pengguna di dalam jaringan perusahaan dan memblokir pengguna luar?
    • Apakah Anda hanya ingin mengizinkan akses dari negara atau wilayah tertentu selama gangguan?
    • Apakah Anda ingin kebijakan terhadap kebijakan kontingensi, terutama untuk aplikasi misi penting, gagal atau berhasil jika kontrol akses alternatif tidak tersedia?

Rekomendasi Microsoft

Kebijakan Akses Bersyarat kontingensi adalah kebijakan pencadangan yang menghilangkan autentikasi multifaktor Microsoft Entra, MFA pihak ketiga, kontrol berbasis risiko atau berbasis perangkat. Untuk meminimalkan gangguan tak terduga ketika kebijakan kontingensi diaktifkan, kebijakan harus tetap dalam mode hanya laporan saat tidak digunakan. Administrator dapat memantau dampak potensial dari kebijakan kontingensi mereka menggunakan buku kerja Wawasan Akses Bersyarat. Saat organisasi Anda memutuskan untuk mengaktifkan rencana kontingensi Anda, administrator dapat mengaktifkan kebijakan dan menonaktifkan kebijakan berbasis kontrol reguler.

Penting

Menonaktifkan kebijakan yang memberlakukan keamanan pada pengguna Anda, bahkan untuk sementara, akan mengurangi kondisi keamanan Anda saat rencana kontingensi berada di tempat.

  • Mengonfigurasikan serangkaian kebijakan cadangan jika gangguan dalam satu jenis info masuk atau satu mekanisme kontrol akses memengaruhi akses ke aplikasi Anda. Mengonfigurasi kebijakan dalam status hanya laporan yang memerlukan Domain Join sebagai kontrol, sebagai cadangan untuk kebijakan aktif yang memerlukan penyedia MFA pihak ketiga.
  • Kurangi risiko pelaku jahat menebak kata sandi, ketika MFA tidak diperlukan, dengan mengikuti praktik dalam laporan resmi panduan kata sandi.
  • Sebarkan Microsoft Entra Self-Service Password Reset (SSPR) dan Microsoft Entra Password Protection untuk memastikan pengguna tidak menggunakan kata sandi umum dan istilah yang Anda pilih untuk melarang.
  • Gunakan kebijakan yang membatasi akses dalam aplikasi jika tingkat autentikasi tertentu tidak dicapai alih-alih hanya kembali ke akses penuh. Misalnya:
    • Mengonfigurasi kebijakan cadangan yang mengirim klaim sesi terbatas ke Exchange dan SharePoint.
    • Jika organisasi Anda menggunakan Aplikasi Microsoft Defender untuk Cloud, pertimbangkan untuk kembali ke kebijakan yang melibatkan Aplikasi Defender untuk Cloud lalu izinkan akses baca-saja, tetapi tidak dengan pengunggahan.
  • Beri nama kebijakan Anda untuk memastikan mudah untuk menemukannya selama gangguan. Sertakan elemen berikut dalam nama kebijakan:
    • Nomor label untuk kebijakan.
    • Teks untuk ditampilkan, kebijakan ini hanya untuk keadaan darurat. Misalnya: AKTIFKAN DALAM KEADAAN DARURAT
    • Kebijakan diberlakukan saat terjadi gangguan tertentu. Misalnya: Selama Gangguan MFA
    • Nomor urut untuk menunjukkan urutan saat mengaktifkan kebijakan.
    • Nomor urut Aplikasi yang berlaku.
    • Kontrol yang akan diterapkan.
    • Ketentuan yang dibutuhkan.

Standar penamaan untuk kebijakan kontingensi ini adalah sebagai berikut:

EMnnn - ENABLE IN EMERGENCY: [Disruption][i/n] - [Apps] - [Controls] [Conditions]

Contoh berikut: Contoh A - Kebijakan Akses Bersyarat Kontingensi untuk memulihkan Akses ke Aplikasi Kolaborasi dengan misi penting, adalah kontingensi perusahaan yang umum. Dalam skenario ini, organisasi biasanya memerlukan MFA untuk semua akses Exchange Online dan SharePoint Online, dan gangguan dalam hal ini adalah penyedia MFA untuk pelanggan mengalami pemadaman (baik autentikasi multifaktor Microsoft Entra, penyedia MFA lokal, atau MFA pihak ketiga). Kebijakan ini mengurangi pemadaman ini dengan memungkinkan pengguna tertentu yang ditargetkan mengakses aplikasi ini dari perangkat Windows tepercaya hanya ketika mereka mengakses aplikasi dari jaringan perusahaan tepercaya mereka. Kebijakan ini juga akan mengecualikan akun darurat dan administrator inti dari pembatasan ini. Pengguna yang ditargetkan kemudian akan mendapatkan akses ke Exchange Online dan SharePoint Online, sementara pengguna lain masih tidak akan memiliki akses ke aplikasi karena pemadaman. Contoh ini memerlukan lokasi jaringan bernama CorpNetwork dan grup keamanan ContingencyAccess dengan pengguna target, grup bernama CoreAdmins dengan administrator inti, dan grup bernama EmergencyAccess dengan akun akses darurat. Kontingensi ini memerlukan empat kebijakan untuk menyediakan akses yang diinginkan.

Contoh A - Kebijakan Akses Bersyarat Kontingensi untuk memulihkan Akses ke Aplikasi Kolaborasi dengan misi penting:

  • Kebijakan 1: Memerlukan perangkat Gabungan Domain untuk Exchange dan SharePoint
    • Nama: EM001 - AKTIFKAN DALAM KEADAAN DARURAT: Gangguan MFA[1/4] - Exchange SharePoint - Memerlukan gabungan hibrid Microsoft Entra
    • Pengguna dan Grup: Termasuk ContingencyAccess. Mengecualikan CoreAdmins, dan EmergencyAccess
    • Aplikasi Cloud: Exchange Online dan SharePoint Online
    • Ketentuan: Apapun
    • Kontrol Grant: Memerlukan Domain Join
    • Status: Hanya laporan
  • Kebijakan 2: Memblokir platform selain Windows
    • Nama: EM002 - AKTIFKAN DALAM KEADAAN DARURAT: Gangguan MFA[2/4] - Exchange SharePoint - Blokir akses kecuali Windows
    • Pengguna dan Grup: Menyertakan semua pengguna. Mengecualikan CoreAdmins, dan EmergencyAccess
    • Aplikasi Cloud: Exchange Online dan SharePoint Online
    • Ketentuan: Platform Perangkat menyertakan Semua Platform, kecualikan Windows
    • Kontrol Grant: Blokir
    • Status: Hanya laporan
  • Kebijakan 3: Memblokir jaringan selain CorpNetwork
    • Nama: EM003 - AKTIFKAN DALAM KEADAAN DARURAT: Gangguan MFA[3/4] - Exchange SharePoint - Blokir akses kecuali Windows
    • Pengguna dan Grup: Menyertakan semua pengguna. Mengecualikan CoreAdmins, dan EmergencyAccess
    • Aplikasi Cloud: Exchange Online dan SharePoint Online
    • Ketentuan: Lokasi Menyertakan lokasi apa pun, kecuali CorpNetwork
    • Kontrol Grant: Blokir
    • Status: Hanya laporan
  • Kebijakan 4: Blokir EAS Secara Eksplisit
    • Nama: EM004 - AKTIFKAN DALAM KEADAAN DARURAT: Gangguan MFA[4/4] - Exchange - Blokir EAS untuk semua pengguna
    • Pengguna dan Grup: Menyertakan semua pengguna
    • Aplikasi Cloud: Sertakan Exchange Online
    • Ketentuan: Aplikasi klien: Exchange Active Sync
    • Kontrol Grant: Blokir
    • Status: Hanya laporan

Urutan aktivasi:

  1. Kecualikan ContingencyAccess, CoreAdmins, dan EmergencyAccess dari kebijakan MFA yang ada. Melakukan verifikasi pengguna di ContingencyAccess dapat mengakses SharePoint Online dan Exchange Online.
  2. Aktifkan Kebijakan 1: Memverifikasi pengguna di perangkat Gabungan Domain yang tidak berada dalam grup pengecualian dapat mengakses Exchange Online dan SharePoint Online. Memverifikasi pengguna dalam grup Pengecualian dapat mengakses SharePoint Online dan Exchange dari perangkat apa pun.
  3. Aktifkan Kebijakan 2: Verifikasi pengguna yang tidak berada dalam grup pengecualian tidak bisa masuk ke SharePoint Online dan Exchange Online dari perangkat seluler mereka. Memverifikasi pengguna dalam grup Pengecualian dapat mengakses SharePoint Online dan Exchange dari perangkat apa pun (Windows/iOS/Android).
  4. Aktifkan Kebijakan 3: Memverifikasi pengguna yang tidak berada dalam grup pengecualian tidak dapat mengakses SharePoint dan Exchange dari jaringan perusahaan, bahkan dengan komputer yang bergabung dengan domain. Memverifikasi pengguna dalam grup Pengecualian dapat mengakses SharePoint Online dan Exchange dari jaringan apa pun.
  5. Aktifkan Kebijakan 4: Verifikasi semua pengguna tidak bisa mendapatkan Exchange Online dari aplikasi email asli di perangkat seluler.
  6. Nonaktifkan kebijakan MFA yang sudah ada untuk SharePoint Online dan Exchange Online.

Dalam contoh berikutnya, Contoh B - Kebijakan Akses Bersyarat Kontingensi untuk mengizinkan akses seluler ke Salesforce, akses aplikasi bisnis dipulihkan. Dalam skenario ini, pelanggan biasanya memerlukan akses karyawan penjualan mereka ke Salesforce (dikonfigurasi untuk akses menyeluruh dengan MICROSOFT Entra ID) dari perangkat seluler agar hanya diizinkan dari perangkat yang sesuai. Gangguan dalam hal ini adalah bahwa ada masalah dengan mengevaluasi kepatuhan perangkat dan pemadaman terjadi pada waktu sensitif di mana tim penjualan membutuhkan akses ke Salesforce untuk menutup kesepakatan. Kebijakan kontingensi ini memberikan akses pengguna penting ke Salesforce dari perangkat seluler sehingga mereka dapat terus menutup kesepakatan dan tidak mengganggu bisnis. Dalam contoh ini, SalesforceContingency berisi semua karyawan Penjualan yang perlu mempertahankan akses dan SalesAdmins berisi admin Salesforce yang diperlukan.

Contoh B - Kebijakan Akses Bersyarat Kontingensi:

  • Kebijakan 1: Memblokir semua orang yang tidak berada di tim SalesContingency
    • Nama: EM001 - AKTIFKAN DALAM KEADAAN DARURAT: Gangguan Kepatuhan Perangkat[1/2] - Salesforce - Blokir Semua pengguna kecuali SalesforceContingency
    • Pengguna dan Grup: Menyertakan semua pengguna. Mengecualikan SalesAdmins dan SalesforceContingency
    • Aplikasi Cloud: Salesforce.
    • Ketentuan: Tidak Ada
    • Kontrol Grant: Blokir
    • Status: Hanya laporan
  • Kebijakan 2: Blokir tim Penjualan dari platform apa pun selain seluler (untuk mengurangi area permukaan serangan)
    • Nama: EM002 - AKTIFKAN DALAM KEADAAN DARURAT: Gangguan Kepatuhan Perangkat[2/2] - Salesforce - Blokir Semua platform kecuali iOS dan Android
    • Pengguna dan Grup: Menyertakan SalesforceContingency. Mengecualikan SalesAdmins
    • Aplikasi Cloud: Salesforce
    • Ketentuan: Platform Perangkat Menyertakan Semua Platform, kecuali iOS dan Android
    • Kontrol Grant: Blokir
    • Status: Hanya laporan

Urutan aktivasi:

  1. Kecualikan SalesAdmins dan SalesforceContingency dari kebijakan kepatuhan perangkat yang ada untuk Salesforce. Memverifikasi pengguna di grup SalesforceContingency dapat mengakses Salesforce.
  2. Aktifkan Kebijakan 1: Memverifikasi pengguna di luar SalesContingency tidak dapat mengakses Salesforce. Memverifikasi pengguna di SalesAdmins dan SalesforceContingency dapat mengakses Salesforce.
  3. Aktifkan Kebijakan 2: Verifikasi pengguna di grup SalesContingency tidak dapat mengakses Salesforce dari laptop Windows/Mac mereka tetapi masih dapat mengakses dari perangkat seluler mereka. Memverifikasi SalesAdmin masih dapat mengakses Salesforce dari perangkat apa pun.
  4. Nonaktifkan kebijakan kepatuhan perangkat yang ada untuk Salesforce.

Kontingensi untuk penguncian pengguna dari sumber daya lokal (ekstensi NPS)

Jika Anda melindungi akses VPN menggunakan ekstensi NPS autentikasi multifaktor Microsoft Entra, pertimbangkan untuk menggabungkan solusi VPN Anda sebagai aplikasi SAML dan tentukan kategori aplikasi seperti yang direkomendasikan di bawah ini.

Jika Anda telah menyebarkan ekstensi NPS autentikasi multifaktor Microsoft Entra untuk melindungi sumber daya lokal, seperti VPN dan Gateway Desktop Jauh, dengan MFA - Anda harus mempertimbangkan terlebih dahulu jika Anda siap untuk menonaktifkan MFA dalam keadaan darurat.

Dalam hal ini, Anda dapat menonaktifkan ekstensi NPS, akibatnya, server NPS hanya akan memverifikasi autentikasi utama dan tidak akan memberlakukan MFA pada pengguna.

Menonaktifkan ekstensi NPS:

  • Ekspor kunci registri HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\AuthSrv\Parameters sebagai cadangan.
  • Hapus nilai registri untuk "AuthorizationDLLs" dan "ExtensionDLLs", bukan kunci Parameter.
  • Mulai ulang Layanan Kebijakan Jaringan (IAS) agar perubahan tersebut berlaku
  • Tentukan apakah autentikasi utama untuk VPN berhasil.

Setelah layanan pulih dan Anda siap untuk memberlakukan MFA pada pengguna Anda lagi, aktifkan ekstensi NPS:

  • Impor kunci registri dari cadangan HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\AuthSrv\Parameters
  • Mulai ulang Layanan Kebijakan Jaringan (IAS) agar perubahan tersebut berlaku
  • Tentukan apakah autentikasi utama dan autentikasi sekunder untuk VPN berhasil.
  • Tinjau server NPS dan log VPN untuk menentukan pengguna mana yang telah masuk selama masa darurat.

Menyebarkan sinkronisasi hash kata sandi meskipun Anda federasi atau menggunakan autentikasi pass-through

Penguncian pengguna juga dapat terjadi jika ketentuan berikut ini benar:

  • Organisasi Anda menggunakan solusi identitas hibrid dengan autentikasi atau federasi pass-through.
  • Sistem identitas lokal Anda (seperti Active Directory, AD FS, atau komponen dependen) tidak tersedia.

Agar lebih tangguh, organisasi Anda harus mengaktifkan sinkronisasi hash sandi, karena memungkinkan Anda untuk beralih menggunakan sinkronisasi hash sandi jika sistem identitas lokal Anda nonaktif.

Rekomendasi Microsoft

Aktifkan sinkronisasi hash kata sandi menggunakan wizard Microsoft Entra Koneksi, terlepas dari apakah organisasi Anda menggunakan federasi atau autentikasi pass-through.

Penting

Tidak diperlukan untuk mengonversi pengguna dari federasi ke autentikasi terkelola untuk menggunakan sinkronisasi hash kata sandi.

Selama gangguan

Jika Anda memilih untuk menerapkan rencana mitigasi, Anda dapat secara otomatis bertahan dari gangguan kontrol akses tunggal. Namun, jika Anda memilih untuk membuat rencana kontingensi, Anda dapat mengaktifkan kebijakan kontingensi selama gangguan kontrol akses:

  1. Mengaktifkan kebijakan kontingensi yang memberikan pengguna yang ditargetkan, akses ke aplikasi tertentu, dari jaringan tertentu.
  2. Menonaktifkan kebijakan berbasis kontrol reguler Anda.

Rekomendasi Microsoft

Bergantung pada mitigasi atau kontingensi mana yang digunakan selama gangguan, organisasi Anda mungkin memberikan akses hanya dengan sandi. Tidak memiliki perlindungan adalah risiko keamanan yang cukup besar, yang harus dipertimbangkan dengan hati-hati. Organisasi harus:

  1. Sebagai bagian dari strategi kontrol perubahan Anda, mendokumentasikan setiap perubahan dan status sebelumnya untuk dapat melakukan roll back kontingensi apa pun yang Anda terapkan segera setelah kontrol akses beroperasi penuh.
  2. Asumsikan bahwa orang jahat akan mencoba mengambil sandi melalui spray sandi atau serangan phishing saat Anda menonaktifkan MFA. Selain itu, pelaku jahat mungkin sudah memiliki kata sandi yang sebelumnya tidak memberikan akses ke sumber daya apa pun yang dapat dicoba selama jendela ini. Untuk pengguna penting seperti eksekutif, Anda dapat memitigasi sebagian risiko ini dengan mengatur ulang sandi mereka sebelum menonaktifkan MFA untuk mereka.
  3. Arsipkan semua aktivitas masuk untuk mengidentifikasi siapa saja yang mengakses apa saja selama MFA dinonaktifkan.
  4. Lakukan penugasan ulang semua deteksi risiko yang dilaporkan selama masa ini.

Setelah gangguan

Batalkan perubahan yang Anda buat sebagai bagian dari rencana kontingensi aktif setelah layanan dipulihkan yang menyebabkan gangguan.

  1. Aktifkan kebijakan reguler
  2. Nonaktifkan kebijakan kontingensi Anda kembali ke mode hanya laporan.
  3. Roll back perubahan lain yang Anda buat dan dokumentasikan selama gangguan.
  4. Jika Anda menggunakan akun akses darurat, ingatlah untuk melakukan regenerasi info masuk dan mengamankan detail info masuk baru secara fisik sebagai bagian dari prosedur akun akses darurat Anda.
  5. Lanjutkan ke Penugasan ulang semua deteksi risiko yang dilaporkan setelah gangguan untuk aktivitas yang mencurigakan.
  6. Cabut semua token refresh yang dikeluarkan untuk menargetkan sekumpulan pengguna. Mencabut semua token refresh penting untuk akun dengan hak istimewa yang digunakan selama gangguan dan melakukannya akan memaksa mereka untuk mengautorisasi ulang dan memenuhi kontrol kebijakan yang dipulihkan.

Opsi darurat

Dalam keadaan darurat dan organisasi Anda sebelumnya tidak menerapkan rencana mitigasi atau kontingensi, lalu ikuti rekomendasi di bagian Kontingensi untuk penguncian pengguna jika mereka sudah menggunakan kebijakan Akses Bersyarat untuk memberlakukan MFA. Jika organisasi Anda menggunakan kebijakan lama MFA per pengguna, maka Anda dapat mempertimbangkan alternatif berikut:

  • Jika Anda memiliki alamat IP outbound jaringan perusahaan, Anda dapat menambahkannya sebagai IP tepercaya untuk mengaktifkan autentikasi hanya ke jaringan perusahaan.
  • Jika Anda tidak memiliki inventaris alamat IP outbound, atau Anda diharuskan mengaktifkan akses di dalam dan di luar jaringan perusahaan, Anda dapat menambahkan seluruh ruang alamat IPv4 sebagai IP tepercaya dengan menentukan 0.0.0.0/1 dan 128.0.0.0/1.

Penting

Jika Anda memperluas alamat IP tepercaya untuk membuka blokir akses, deteksi risiko yang terkait dengan alamat IP (misalnya, perjalanan tidak mungkin atau lokasi yang tidak dikenal) tidak akan dihasilkan.

Catatan

Mengonfigurasi IP tepercaya untuk autentikasi multifaktor Microsoft Entra hanya tersedia dengan lisensi Microsoft Entra ID P1 atau P2.

Pelajari selengkapnya