Merencanakan penerapan Akses Bersyarat

Merencanakan penerapan Akses Bersyarat Sangat penting untuk mencapai strategi akses organisasi Anda untuk aplikasi dan sumber daya. Kebijakan Akses Bersyar memberikan fleksibilitas konfigurasi yang hebat. Namun, fleksibilitas ini juga berarti Anda harus merencanakan dengan hati-hati untuk menghindari hasil yang tidak diinginkan.

Akses Bersyarat Microsoft Entra menggabungkan sinyal seperti pengguna, perangkat, dan lokasi untuk mengotomatiskan keputusan dan menerapkan kebijakan akses organisasi untuk sumber daya. Kebijakan Akses Bersyariah ini membantu Anda menyeimbangkan keamanan dan produktivitas, memberlakukan kontrol keamanan saat diperlukan dan menjauh dari cara pengguna saat tidak.

Akses Bersyar adalah dasar dari mesin kebijakan keamanan Zero Trust Microsoft.

Microsoft menyediakan default keamanan yang memastikan tingkat keamanan dasar yang diaktifkan di penyewa yang tidak memiliki Microsoft Entra ID P1 atau P2. Dengan Akses Bersyarat, Anda dapat membuat kebijakan yang memberikan perlindungan yang sama dengan default keamanan, tetapi dengan granularitas. Akses Bersyarkat dan default keamanan tidak dimaksudkan untuk digabungkan sebagai membuat kebijakan Akses Bersyar mencegah Anda mengaktifkan default keamanan.

Prasyarat

• Penyewa Microsoft Entra yang berfungsi dengan lisensi Microsoft Entra ID P1, P2, atau uji coba diaktifkan. Jika perlu, buat secara gratis.
  • Microsoft Entra ID P2 diperlukan untuk menyertakan risiko Microsoft Entra ID Protection dalam kebijakan Akses Bersyarat.
• Administrator yang berinteraksi dengan Akses Bersyar harus memiliki salah satu penetapan peran berikut tergantung pada tugas yang mereka lakukan. Untuk mengikuti prinsip Zero Trust dengan hak istimewa paling sedikit, pertimbangkan untuk menggunakan Privileged Identity Management (PIM) untuk mengaktifkan penetapan peran istimewa just-in-time.
  • Membaca kebijakan dan konfigurasi Akses Bersyar
    • Pembaca Keamanan
  • Membuat atau mengubah kebijakan Akses Bersyar
    • Admin Akses Bersyarat
• Pengguna uji (bukan administrator) yang memungkinkan Anda memverifikasi kebijakan berfungsi seperti yang diharapkan sebelum menyebarkan ke pengguna nyata. Jika Anda perlu membuat pengguna, lihat Mulai Cepat: Menambahkan pengguna baru ke ID Microsoft Entra.
• Grup tempat pengguna uji adalah anggota. Jika Anda perlu membuat grup, lihat Membuat grup dan menambahkan anggota di ID Microsoft Entra.

Mengomunikasikan perubahan

Komunikasi sangat penting untuk keberhasilan fungsionalitas baru apa pun. Anda harus secara proaktif berkomunikasi dengan pengguna Anda bagaimana pengalaman mereka berubah, saat berubah, dan cara mendapatkan dukungan jika mereka mengalami masalah.

Komponen kebijakan Akses Bersyarat

Kebijakan Akses Bersyarkala menjawab pertanyaan tentang siapa yang dapat mengakses sumber daya Anda, sumber daya apa yang dapat mereka akses, dan dalam kondisi apa. Kebijakan dapat dirancang untuk memberikan akses, membatasi akses dengan kontrol sesi, atau untuk memblokir akses. Anda membuat kebijakan Akses Bersyar dengan menentukan pernyataan if-then seperti:

Jika tugas terpenuhi	Menerapkan kontrol akses
Jika Anda adalah pengguna di Finance yang mengakses aplikasi Payroll	Memerlukan autentikasi multifaktor dan perangkat yang sesuai
Jika Anda bukan anggota Keuangan yang mengakses aplikasi Payroll	Akses blok
Jika risiko pengguna Anda tinggi	Memerlukan autentikasi multifaktor dan perubahan kata sandi yang aman

Pengecualian pengguna

Kebijakan Akses Bersyarah adalah alat yang canggih, sebaiknya kecualikan akun berikut dari kebijakan Anda:

• Akses darurat atau akun pemecah kaca untuk mencegah penguncian akun di seluruh penyewa. Dalam skenario yang tidak mungkin saat semua administrator dikunci dari penyewa Anda, akun administratif akses darurat Anda dapat digunakan untuk masuk ke penyewa dan mengambil langkah-langkah pemulihan akses.
  • Informasi selengkapnya dapat ditemukan di artikel, Mengelola akun akses darurat di ID Microsoft Entra.
• Akun layanan dan perwakilan layanan, seperti Akun Microsoft Entra Koneksi Sync. Akun layanan adalah akun non-interaktif yang tidak terikat dengan pengguna tertentu. Akun tersebut biasanya digunakan oleh layanan back-end yang memungkinkan akses terprogram ke aplikasi, tetapi juga digunakan untuk masuk ke sistem guna tujuan administratif. Akun layanan seperti ini harus dikecualikan karena MFA tidak dapat diselesaikan secara terprogram. Panggilan yang dilakukan oleh perwakilan layanan tidak akan diblokir oleh kebijakan Akses Bersyar yang dilingkupkan kepada pengguna. Gunakan Akses Bersyarah untuk identitas beban kerja untuk menentukan kebijakan yang menargetkan perwakilan layanan.
  • Jika organisasi Anda memiliki akun ini yang digunakan dalam skrip atau kode, pertimbangkan untuk menggantinya dengan identitas terkelola. Sebagai solusi sementara, Anda dapat mengecualikan akun tertentu seperti ini dari kebijakan dasar.

Mengajukan pertanyaan yang tepat

Berikut adalah beberapa pertanyaan umum tentang Penugasan dan Kontrol Akses. Dokumentasikan jawaban atas pertanyaan untuk setiap kebijakan sebelum menyusunnya.

Identitas beban kerja atau pengguna

• Pengguna, grup, peran direktori, atau identitas beban kerja mana yang disertakan atau dikecualikan dari kebijakan?
• Akun atau grup akses darurat apa yang harus dikecualikan dari kebijakan?

Aplikasi atau tindakan cloud

Apakah kebijakan ini akan berlaku untuk konteks aplikasi, tindakan pengguna, atau autentikasi apa pun? Jika ya:

• Aplikasi atau layanan apa yang akan diterapkan kebijakan?
• Tindakan pengguna apa yang tunduk pada kebijakan ini?
• Konteks autentikasi apa yang akan diterapkan kebijakan ini?

Filter untuk aplikasi

Menggunakan filter untuk aplikasi untuk menyertakan atau mengecualikan aplikasi alih-alih menentukannya secara individual membantu organisasi:

• Menskalakan dan menargetkan sejumlah aplikasi dengan mudah.
• Kelola aplikasi dengan mudah dengan persyaratan kebijakan serupa.
• Kurangi jumlah kebijakan individual.
• Mengurangi kesalahan saat mengedit kebijakan: Tidak perlu menambahkan/menghapus aplikasi secara manual dari kebijakan. Cukup kelola atribut.
• Mengatasi batasan ukuran kebijakan.

Kondisi

• Platform perangkat mana yang disertakan atau dikecualikan dari kebijakan?
• Apa saja lokasi jaringan organisasi yang diketahui?
  • Lokasi apa yang disertakan atau dikecualikan dari kebijakan?
• Jenis aplikasi klien apa yang disertakan atau dikecualikan dari kebijakan?
• Apakah Anda perlu menargetkan atribut perangkat tertentu?
• Jika menggunakan Microsoft Entra ID Protection, apakah Anda ingin menggabungkan masuk atau risiko pengguna?

Risiko kredensial masuk dan pengguna

Untuk organisasi dengan lisensi Microsoft Entra ID P2, mereka dapat menyertakan pengguna dan risiko masuk dalam kebijakan Akses Bersyarat mereka. Penambahan ini dapat membantu mengurangi gesekan langkah-langkah keamanan dengan memerlukan autentikasi multifaktor atau perubahan kata sandi yang aman hanya ketika pengguna atau masuk dianggap berisiko.

Untuk informasi selengkapnya tentang risiko dan penggunaannya dalam kebijakan, lihat artikel Apa itu risiko.

Memblokir atau memberikan kontrol

Apakah Anda ingin memberikan akses ke sumber daya dengan mengharuskan satu atau beberapa hal berikut ini?

• Autentikasi multifaktor
• Perangkat yang ditandai sebagai sesuai
• Menggunakan perangkat gabungan hibrid Microsoft Entra
• Menggunakan aplikasi klien yang disetujui
• kebijakan Perlindungan aplikasi diterapkan
• Perubahan kata sandi
• Ketentuan Penggunaan diterima

Blokir akses adalah kontrol kuat yang harus diterapkan dengan pengetahuan yang sesuai. Kebijakan dengan pernyataan blok dapat memiliki efek samping yang tidak diinginkan. Pengujian dan validasi yang tepat sangat penting sebelum Anda mengaktifkan kontrol dalam skala besar. Administrator harus menggunakan alat seperti mode khusus laporan Akses Bersyarat dan saat membuat perubahan alat yang bagaimana digunakan pada Akses Bersyarat.

Kontrol Sesi

Apakah Anda ingin menerapkan kontrol akses berikut ini pada aplikasi cloud?

• Gunakan pembatasan yang diberlakukan aplikasi
• Menggunakan Kontrol Aplikasi Akses Bersyarat
• Menerapkan frekuensi masuk
• Menggunakan sesi browser tetap
• Mengkustomasi evaluasi akses berkelanjutan

Menggabungkan kebijakan

Saat membuat dan menetapkan kebijakan, Anda harus memperhitungkan cara kerja token akses. Token akses memberikan atau menolak akses berdasarkan apakah pengguna yang membuat permintaan telah diotorisasi dan diautentikasi. Jika pemohon dapat membuktikan bahwa mereka adalah siapa yang mereka klaim, mereka dapat mengakses sumber daya atau fungsi yang dilindungi.

Token akses dikeluarkan secara default jika kondisi kebijakan Akses Bersyar tidak memicu kontrol akses.

Kebijakan ini tidak mencegah aplikasi memiliki kemampuannya sendiri untuk memblokir akses.

Misalnya, pertimbangkan contoh kebijakan yang disederhanakan di mana:

Pengguna: GRUP KEUANGAN
Mengakses: PAYROLL APP
Kontrol akses: Autentikasi multifaktor

• Pengguna A berada di GRUP KEUANGAN, mereka diharuskan melakukan autentikasi multifaktor untuk mengakses APLIKASI PAYROLL.
• Pengguna B tidak berada di GRUP KEUANGAN, dikeluarkan token akses dan diizinkan untuk mengakses APLIKASI PAYROLL tanpa melakukan autentikasi multifaktor.

Untuk memastikan pengguna di luar grup keuangan tidak dapat mengakses aplikasi penggajian, kebijakan terpisah dapat dibuat untuk memblokir semua pengguna lain, seperti kebijakan yang disederhanakan berikut:

Pengguna: Menyertakan Semua Pengguna / Mengecualikan GRUP KEUANGAN
Mengakses: PAYROLL APP
Kontrol akses: Memblokir akses

Sekarang ketika Pengguna B mencoba mengakses APLIKASI PAYROLL, mereka diblokir.

Rekomendasi

Dengan mempertimbangkan pembelajaran kami dalam penggunaan Akses Bersyar dan mendukung pelanggan lain, berikut adalah beberapa rekomendasi berdasarkan pembelajaran kami.

Menerapkan kebijakan Akses Bersyarat ke setiap aplikasi

Memastikan bahwa setiap aplikasi memiliki setidaknya satu kebijakan Akses Bersyarat yang diterapkan. Dari perspektif keamanan, membuat kebijakan yang mencakup Semua aplikasi cloud, lalu mengecualikan aplikasi yang tidak ingin diterapkan kebijakan lebih direkomendasikan. Praktik ini memastikan Anda tidak perlu memperbarui kebijakan Akses Bersyarat setiap kali Anda melakukan onboarding aplikasi baru.

Tip

Berhati-hatilah dalam menggunakan blok dan semua aplikasi dalam satu kebijakan. Ini dapat mengunci admin, dan pengecualian tidak dapat dikonfigurasi untuk titik akhir penting seperti Microsoft Graph.

Meminimalkan jumlah kebijakan Akses Bersyarat

Membuat kebijakan untuk setiap aplikasi tidak efisien dan mengarah ke administrasi yang kompleks. Akses Bersyarat memiliki batas, yaitu 195 kebijakan per penyewa. Batas kebijakan 195 ini mencakup kebijakan Akses Bersyar dalam status apa pun termasuk mode khusus laporan, aktif, atau nonaktif.

Sebaiknya Anda menganalisis aplikasi dan mengelompokkannya ke dalam aplikasi yang memiliki persyaratan sumber daya yang sama untuk pengguna yang sama. Misalnya, jika semua aplikasi Microsoft 365 atau semua aplikasi SDM memiliki persyaratan yang sama untuk pengguna yang sama, buat satu kebijakan dan sertakan semua aplikasi yang menerapkannya.

Kebijakan Akses Bersyarah terkandung dalam file JSON dan file tersebut terikat pada batas ukuran, kami tidak mengharapkan satu kebijakan untuk tumbuh lebih jauh. Jika Anda menggunakan daftar panjang GUID dalam kebijakan Anda, Anda mungkin mencapai batas ini. Jika Anda mengalami batas ini, kami merekomendasikan alternatif seperti:

• Gunakan grup atau peran untuk menyertakan atau mengecualikan Pengguna alih-alih mencantumkan setiap pengguna satu per satu.
• Gunakan filter untuk aplikasi untuk menyertakan atau mengecualikan aplikasi alih-alih menentukannya secara individual.

Mengonfigurasi mode khusus laporan

Secara default, setiap kebijakan yang dibuat dari templat dibuat dalam mode khusus laporan. Kami menyarankan organisasi menguji dan memantau penggunaan, untuk memastikan hasil yang dimaksudkan, sebelum mengaktifkan setiap kebijakan.

Aktifkan kebijakan dalam mode khusus laporan. Setelah menyimpan kebijakan dalam mode khusus laporan, Anda dapat melihat efeknya pada rincian masuk real time di log masuk. Dari log masuk, pilih peristiwa dan navigasikan ke tab Khusus laporan untuk melihat hasil setiap kebijakan khusus laporan.

Anda bisa menampilkan pengaruh agregat dari kebijakan Akses Bersyar Anda di buku kerja Wawasan dan Pelaporan. Untuk mengakses buku kerja, Anda memerlukan langganan Azure Monitor dan Anda perlu mengalirkan log masuk Anda ke ruang kerja analitik log.

Merencanakan untuk mengatasi gangguan

Untuk mengurangi risiko penguncian selama gangguan yang tidak terduga, rencanakan strategi ketahanan untuk organisasi Anda.

Menetapkan standar penamaan untuk kebijakan Anda

Standar penamaan membantu Anda menemukan kebijakan dan memahami tujuannya tanpa harus membukanya di portal admin Azure. Kami menyarankan agar Anda menamai kebijakan Anda untuk ditampilkan dengan:

• Nomor Urut
• Aplikasi cloud yang berlaku untuk
• Respons
• Berlaku untuk siapa
• Ketika berlaku

Contoh: Kebijakan untuk mewajibkan MFA bagi pengguna pemasaran yang mengakses aplikasi Dynamics CRP dari jaringan eksternal mungkin:

Nama deskriptif membantu Anda mempertahankan gambaran umum implementasi Akses Bersyarat Anda. Nomor Urut sangat membantu jika Anda perlu mereferensikan kebijakan dalam percakapan. Misalnya, ketika Anda berbicara dengan administrator di telepon, Anda dapat meminta mereka untuk membuka kebijakan CA01 untuk menyelesaikan masalah.

Standar penamaan untuk kontrol akses darurat

Selain kebijakan aktif Anda, terapkan kebijakan yang dinonaktifkan yang bertindak sebagai kontrol akses tangguh sekunder dalam skenario pemadaman atau darurat. Standar penamaan Anda untuk kebijakan kontinjensi harus mencakup:

• AKTIFKAN DALAM KEADAAN DARURAT di awal untuk membuat nama menonjol di antara kebijakan lainnya.
• Nama gangguan tersebut harus berlaku untuk.
• Nomor urut pemesanan digunakan untuk membantu administrator mengetahui kebijakan urutan mana yang harus diaktifkan.

Contoh: Nama berikut menunjukkan bahwa kebijakan ini adalah kebijakan pertama dari empat kebijakan yang diaktifkan jika ada gangguan MFA:

• EM01 - AKTIFKAN DALAM KEADAAN DARURAT: Gangguan MFA [1/4] - Exchange SharePoint: Memerlukan gabungan hibrid Microsoft Entra Untuk pengguna VIP.

Memblokir negara/wilayah tempat Anda tidak pernah mengharapkan masuk

MICROSOFT Entra ID memungkinkan Anda membuat lokasi bernama. Buat daftar negara/wilayah yang diizinkan, lalu buat kebijakan blok jaringan dengan "negara/wilayah yang diizinkan" ini sebagai pengecualian. Opsi ini membuat lebih sedikit overhead untuk pelanggan yang berbasis di lokasi geografis yang lebih kecil. Pastikan untuk membebaskan akun akses darurat Anda dari kebijakan ini.

Menyebarkan kebijakan Akses Bersyar

Saat Anda siap, sebarkan kebijakan Akses Bersyar anda secara bertahap.

Membangun kebijakan Akses Bersyar Anda

Lihat templat kebijakan Akses Bersyar dan Kebijakan keamanan umum untuk organisasi Microsoft 365 untuk memulai. Templat ini adalah cara mudah untuk menyebarkan rekomendasi Microsoft. Pastikan Anda mengecualikan akun akses darurat Anda.

Mengevaluasi dampak kebijakan

Kami menyarankan agar Anda menggunakan alat berikut untuk mengevaluasi efek kebijakan Anda baik sebelum maupun sesudah membuat perubahan. Eksekusi yang disimulasikan memberi Anda gambaran yang baik tentang efek yang dimiliki kebijakan Akses Bersyariah, itu tidak menggantikan eksekusi pengujian aktual di lingkungan pengembangan yang dikonfigurasi dengan benar.

• Mode khusus laporan dan wawasan Akses Bersyar dan buku kerja Pelaporan.
• Alat Bagaimana Jika

Menguji kebijakan Anda

Pastikan Anda menguji kriteria pengecualian kebijakan. Misalnya, Anda mungkin mengecualikan pengguna atau grup dari kebijakan yang memerlukan MFA. Uji apakah pengguna yang dikecualikan diminta untuk MFA, karena kombinasi kebijakan lain mungkin memerlukan MFA untuk pengguna tersebut.

Lakukan setiap pengujian dalam rencana pengujian Anda dengan uji pengguna. Rencana pengujian penting untuk memiliki perbandingan antara hasil yang diharapkan dan hasil aktual. Tabel berikut menguraikan beberapa contoh kasus pengujian. Sesuaikan skenario dan hasil yang diharapkan berdasarkan bagaimana kebijakan Akses Bersyarat Anda dikonfigurasi.

Kebijakan	Skenario	Hasil yang diharapkan
Proses masuk riskan	Pengguna masuk ke Aplikasi menggunakan browser yang tidak disetujui	Menghitung skor risiko berdasarkan peluang bahwa proses masuk tidak dilakukan oleh pengguna. Mengharuskan pengguna untuk memulihkan secara mandiri menggunakan MFA
Manajemen perangkat	Pengguna yang berwenang mencoba masuk dari perangkat yang diotorisasi	Akses diberikan
Manajemen perangkat	Pengguna yang berwenang mencoba masuk dari perangkat yang tidak sah	Akses diblokir
Perubahan kata sandi untuk pengguna berisiko	Pengguna yang berwenang mencoba masuk dengan info masuk yang disusupi (rincian masuk berisiko tinggi)	Pengguna diminta untuk mengubah kata sandi atau akses diblokir berdasarkan kebijakan Anda

Menyebarkan dalam produksi

Setelah Anda mengonfirmasi dampak menggunakan mode khusus laporan, administrator dapat memindahkan tombol Aktifkan kebijakan dari Hanya Laporan ke Aktif.

Membatalkan kebijakan

Jika Anda perlu membatalkan kebijakan yang baru diterapkan, gunakan satu atau beberapa opsi berikut:

• Nonaktifkan kebijakan. Menonaktifkan kebijakan akan memastikan kebijakan tidak berlaku saat pengguna mencoba masuk. Anda selalu dapat kembali dan mengaktifkan kebijakan ketika Anda ingin menggunakannya.

• Kecualikan pengguna atau grup dari kebijakan. Jika pengguna tidak dapat mengakses aplikasi, Anda dapat memilih untuk mengecualikan pengguna dari kebijakan tersebut.

  Perhatian

  Pengecualian harus digunakan dengan hemat, hanya dalam situasi di mana pengguna dipercaya. Pengguna harus ditambahkan kembali ke dalam kebijakan atau grup sesegera mungkin.

• Jika kebijakan dinonaktifkan dan tidak lagi diperlukan, hapus kebijakan tersebut.

Memecahkan masalah kebijakan Akses Bersyar

Jika pengguna mengalami masalah dengan kebijakan Akses Bersyarah, kumpulkan informasi berikut untuk memfasilitasi pemecahan masalah.

• Nama Utama Pengguna
• Nama tampilan Pengguna
• Nama sistem operasi
• Stempel waktu (perkiraan tidak masalah)
• Aplikasi target
• Tipe aplikasi klien (browser vs klien)
• ID Korelasi (ID ini unik untuk masuk)

Jika pengguna menerima pesan dengan link Detail selengkapnya, mereka dapat mengumpulkan sebagian besar informasi ini untuk Anda.

Setelah Anda mengumpulkan informasi, lihat sumber daya berikut:

• Masalah masuk dengan Akses Bersyarat – Memahami hasil masuk tak terduga yang terkait dengan Akses Bersyarat menggunakan pesan kesalahan dan log masuk Microsoft Entra.
• Menggunakan alat What-If - Pahami mengapa kebijakan atau tidak diterapkan kepada pengguna dalam keadaan tertentu atau jika kebijakan akan berlaku dalam keadaan yang diketahui.

Konten terkait

• Pelajari selengkapnya tentang Autentikasi multifaktor
• Pelajari selengkapnya tentang Microsoft Entra ID Protection
• Kelola kebijakan Akses Bersyarat dengan Microsoft Graph API