Kerangka kerja dan kebijakan Akses Bersyarat
Artikel ini menyediakan kerangka kerja untuk menerapkan arsitektur Akses Bersyarkat berbasis persona, seperti yang dijelaskan dalam arsitektur Akses Bersyarah Zero Trust. Dalam artikel ini, ada detail tentang cara membentuk dan memberi nama kebijakan Akses Bersyar. Ada juga titik awal untuk membuat kebijakan.
Jika Anda tidak menggunakan kerangka kerja seperti yang disediakan di sini, termasuk standar penamaan, kebijakan cenderung dibuat dari waktu ke waktu oleh orang yang berbeda dengan cara ad-hoc. Ini dapat mengakibatkan kebijakan yang tumpang tindih. Jika orang yang membuat kebijakan tidak lagi tersedia, mungkin sulit bagi orang lain untuk mengetahui tujuan kebijakan.
Mengikuti kerangka kerja terstruktur membuatnya lebih mudah untuk memahami kebijakan. Ini juga memudahkan untuk mencakup semua skenario dan menghindari kebijakan yang bertentangan yang sulit untuk memecahkan masalah.
Konvensi penamaan
Konvensi penamaan yang ditentukan dengan benar membantu Anda dan rekan kerja Anda memahami tujuan kebijakan, yang memungkinkan manajemen dan pemecahan masalah kebijakan menjadi lebih mudah. Konvensi penamaan Anda harus sesuai dengan kerangka kerja yang digunakan untuk menyusun kebijakan.
Kebijakan penamaan yang direkomendasikan didasarkan pada persona, jenis kebijakan, dan aplikasi. Terlihat seperti di bawah ini:
<CANumber-Persona-PolicyType-App-Platform-GrantControl-OptionalDescription><><><><><><>
Komponen nama ini dijelaskan di sini:
| Komponen penamaan | Deskripsi/Contoh |
|---|---|
| Nomor CA | Digunakan untuk mengidentifikasi cakupan dan urutan Jenis Kebijakan dengan cepat. Contoh: CA001-CA099. |
| Persona | Global, Admin, Internal, Eksternal, GuestUsers, GuestAdmins, Microsoft365ServiceAccounts, AzureServiceAccounts, CorpServiceAccounts. |
| Jenis Kebijakan | BaseProtection, AppProtection, DataProtection, IdentityProtection, AttackSurfaceReduction, Compliance. |
| App | AllApps, O365 (untuk semua layanan Office 365), EXO (untuk Exchange Online). |
| Platform | AnyPlatform, Unknown, Windows Telepon, macOS, iOS, Android. |
| Kontrol Pemberian | Block, ADHJ, Compliant, Unmanaged (di mana tidak terkelola ditentukan dalam kondisi status perangkat). |
| Deskripsi | Deskripsi opsional tentang tujuan kebijakan. |
Skema penomoran
Untuk memudahkan administrasi, kami menyarankan skema penomoran ini:
| Grup persona | Alokasi angka |
|---|---|
| CA-Persona-Global | CA001-CA099 |
| CA-Persona-Admins | CA100-CA199 |
| CA-Persona-Internals | CA200-CA299 |
| CA-Persona-Externals | CA300-CA399 |
| CA-Persona-GuestUsers | CA400-CA499 |
| CA-Persona-GuestAdmins | CA500-CA599 |
| CA-Persona-M365ServiceAccounts | CA600-CA699 |
| CA-Persona-AzureServiceAccounts | CA700-CA799 |
| CA-Persona-CorpServiceAccounts | CA800-CA899 |
| IDENTITAS CA-Persona-Workload | CA900-CA999 |
| CA-Persona-Developers | CA1000-CA1099 |
Jenis kebijakan
Ini adalah jenis kebijakan yang direkomendasikan:
| Jenis kebijakan | Deskripsi/Contoh |
|---|---|
| BaseProtection | Untuk setiap persona, ada perlindungan garis besar yang dicakup oleh jenis kebijakan ini. Untuk pengguna di perangkat terkelola, ini biasanya diketahui pengguna dan perangkat yang dikenal. Untuk tamu eksternal, mungkin autentikasi pengguna dan multifaktor yang diketahui. Perlindungan dasar adalah kebijakan default untuk semua aplikasi untuk pengguna dalam persona tertentu. Jika aplikasi tertentu harus memiliki kebijakan yang berbeda, kecualikan aplikasi tersebut dari kebijakan perlindungan dasar dan tambahkan kebijakan eksplisit yang hanya menargetkan aplikasi tersebut. Contoh: Asumsikan perlindungan dasar untuk Internal adalah mewajibkan pengguna yang diketahui dan perangkat yang dikenal untuk semua aplikasi cloud, tetapi Anda ingin mengizinkan Outlook di web dari perangkat apa pun. Anda dapat mengecualikan Exchange Online dari kebijakan perlindungan dasar dan menambahkan kebijakan terpisah untuk Exchange Online, di mana Anda memerlukan perangkat atau autentikasi multifaktor yang diketahui. |
| IdentitasPerlindungan | Selain perlindungan dasar untuk setiap persona, Anda dapat memiliki kebijakan Akses Bersyar yang terkait dengan identitas. Contoh: Memblokir autentikasi lama, memerlukan autentikasi multifaktor tambahan untuk pengguna tinggi atau risiko masuk, memerlukan perangkat yang diketahui untuk pendaftaran autentikasi multifaktor. |
| Perlindungan Data | Jenis kebijakan ini menunjukkan kebijakan delta yang melindungi data sebagai lapisan tambahan di atas perlindungan dasar. Contoh:
|
| AppProtection | Jenis kebijakan ini adalah tambahan lain untuk perlindungan dasar. Contoh:
|
| AttackSurfaceReduction | Tujuan dari jenis kebijakan ini adalah untuk mengurangi berbagai serangan. Contoh:
|
| Kepatuhan | Anda dapat menggunakan kebijakan kepatuhan untuk mengharuskan pengguna melihat ketentuan penggunaan bagi tamu yang mengakses layanan pelanggan. |
App
Tabel berikut ini menjelaskan komponen Aplikasi dari nama kebijakan:
| Nama aplikasi | Deskripsi/Contoh |
|---|---|
| AllApps | AllApps menunjukkan bahwa semua aplikasi cloud ditargetkan dalam kebijakan Akses Bersyar. Semua titik akhir tercakup, termasuk titik akhir yang mendukung Akses Bersyar dan titik akhir yang tidak. Dalam beberapa skenario, menargetkan semua aplikasi tidak berfungsi dengan baik. Sebaiknya targetkan semua aplikasi dalam kebijakan dasar sehingga semua titik akhir tercakup dalam kebijakan tersebut. Aplikasi baru yang muncul di ID Microsoft Entra juga akan secara otomatis mematuhi kebijakan. |
| <NamaAplikasi> | <AppName> adalah tempat penampung untuk nama aplikasi yang ditangani kebijakan. Hindari membuat nama terlalu panjang. Contoh nama:
|
Jenis platform
Tabel berikut menjelaskan komponen Platform dari nama kebijakan:
| Jenis platform | Deskripsi |
|---|---|
| AnyPlatform | Kebijakan ini menargetkan platform apa pun. Anda biasanya mengonfigurasi ini dengan memilih Perangkat Apa Pun. (Dalam kebijakan Akses Bersyar, baik platform kata maupun perangkat kata digunakan.) |
| iOS | Kebijakan ini menargetkan platform Apple iOS. |
| Android | Kebijakan ini menargetkan platform Google Android. |
| Jendela | Kebijakan ini menargetkan platform Windows. |
| Linux | Kebijakan ini menargetkan platform Linux. |
| Windows Telepon | Kebijakan ini menargetkan platform windows Telepon. |
| macOS | Kebijakan ini menargetkan platform macOS |
| iOSAndroid | Kebijakan ini menargetkan platform iOS dan Android. |
| Tidak dikenal | Kebijakan ini menargetkan platform apa pun yang tidak tercantum sebelumnya. Anda biasanya mengonfigurasi ini dengan menyertakan Perangkat Apa pun dan mengecualikan semua platform individual. |
Memberikan jenis kontrol
Tabel berikut ini menjelaskan komponen Grant Control dari nama kebijakan:
| Jenis hibah | Deskripsi/Contoh |
|---|---|
| Blokir | Kebijakan memblokir rincian masuk |
| MFA | Kebijakan ini memerlukan autentikasi multifaktor. |
| Sesuai | Kebijakan ini memerlukan perangkat yang sesuai, seperti yang ditentukan oleh Endpoint Manager, sehingga perangkat perlu dikelola oleh Endpoint Manager. |
| CompliantorAADHJ | Kebijakan ini memerlukan perangkat yang sesuai ATAU perangkat gabungan hibrid Microsoft Entra. Komputer perusahaan standar yang bergabung dengan domain juga bergabung dengan ID Microsoft Entra Hibrid. Ponsel dan komputer Windows 10 yang dikelola bersama atau bergabung dengan Microsoft Entra dapat mematuhinya. |
| CompliantandAADHJ | Kebijakan ini memerlukan perangkat yang mematuhi dan bergabung dengan hibrid Microsoft Entra. |
| MFAorCompliant | Kebijakan ini memerlukan perangkat yang sesuai ATAU autentikasi multifaktor jika tidak sesuai. |
| MFAandCompliant | Kebijakan ini memerlukan perangkat yang sesuai dan autentikasi multifaktor. |
| MFAorAADHJ | Kebijakan ini memerlukan komputer gabungan hibrid Microsoft Entra ATAU autentikasi multifaktor jika bukan komputer gabungan hibrid Microsoft Entra. |
| MFAandAADHJ | Kebijakan ini memerlukan komputer gabungan hibrid Microsoft Entra DAN autentikasi multifaktor. |
| RequireApprovedClient | Kebijakan ini memerlukan aplikasi klien yang disetujui. |
| AppProtection | Kebijakan ini memerlukan perlindungan aplikasi |
| Tidak terkelola | Kebijakan ini menargetkan perangkat yang tidak diketahui oleh ID Microsoft Entra. Misalnya, Anda dapat menggunakan jenis pemberian ini untuk mengizinkan akses ke Exchange Online dari perangkat apa pun. |
Lokasi bernama
Kami menyarankan agar Anda menentukan lokasi standar ini untuk digunakan dalam kebijakan Akses Bersyar:
- IP Tepercaya/Jaringan internal. Subnet IP ini mewakili lokasi dan jaringan yang memiliki pembatasan akses fisik atau kontrol lain di tempat, seperti manajemen sistem komputer, autentikasi tingkat jaringan, atau deteksi intrusi. Lokasi-lokasi ini lebih aman, sehingga penegakan Akses Bersyar dapat dilonggarkan. Pertimbangkan apakah Azure atau lokasi pusat data (IP) lainnya harus disertakan di lokasi ini atau memiliki lokasi bernama mereka sendiri.
- IP tepercaya Citrix. Jika Anda memiliki Citrix lokal, mungkin berguna untuk mengonfigurasi alamat IPv4 keluar terpisah untuk farm Citrix, jika Anda perlu dapat terhubung ke layanan cloud dari sesi Citrix. Dalam hal ini, Anda dapat mengecualikan lokasi tersebut dari kebijakan Akses Bersyarah jika perlu.
- Lokasi Zscaler, jika berlaku. Komputer memiliki agen ZPA yang diinstal dan meneruskan semua lalu lintas ke internet ke atau melalui cloud Zscaler. Jadi ada baiknya menentukan IP sumber Zscaler dalam Akses Bersyarat dan mengharuskan semua permintaan dari perangkat non-seluler melalui Zscaler.
- Negara/wilayah yang memungkinkan bisnis. Hal ini dapat berguna untuk membagi negara/wilayah menjadi dua grup lokasi: satu yang mewakili area dunia di mana karyawan biasanya bekerja dan satu yang mewakili lokasi lain. Ini memungkinkan Anda menerapkan kontrol tambahan ke permintaan yang berasal dari luar area tempat organisasi Anda biasanya beroperasi.
- Lokasi di mana autentikasi multifaktor mungkin sulit atau tidak mungkin. Dalam beberapa skenario, membutuhkan autentikasi multifaktor dapat menyulitkan karyawan untuk melakukan pekerjaan mereka. Misalnya, staf mungkin tidak memiliki waktu atau kesempatan untuk menanggapi tantangan autentikasi multifaktor yang sering terjadi. Atau, di beberapa lokasi, penyaringan RF atau gangguan listrik dapat menyulitkan penggunaan perangkat seluler. Biasanya, Anda akan menggunakan kontrol lain di lokasi ini, atau mungkin tepercaya.
Kontrol akses berbasis lokasi bergantung pada IP sumber permintaan untuk menentukan lokasi pengguna pada saat permintaan. Tidak mudah untuk melakukan spoofing di internet publik, tetapi perlindungan yang diberikan oleh batas jaringan mungkin dianggap kurang relevan daripada dulu. Kami tidak menyarankan untuk hanya mengandalkan lokasi sebagai kondisi untuk akses. Tetapi untuk beberapa skenario, mungkin kontrol terbaik yang dapat Anda gunakan, seperti jika Anda mengamankan akses dari akun layanan dari lokal yang digunakan dalam skenario non-interaktif.
Kebijakan Akses Bersyar yang Direkomendasikan
Kami telah membuat spreadsheet yang berisi kebijakan Akses Bersyar yang direkomendasikan. Anda dapat mengunduh spreadsheet di sini.
Gunakan kebijakan yang disarankan sebagai titik awal.
Kebijakan Anda mungkin akan berubah dari waktu ke waktu untuk mengakomodasi kasus penggunaan yang penting untuk bisnis Anda. Berikut adalah beberapa contoh skenario yang mungkin memerlukan perubahan:
- Terapkan akses baca-saja ke Exchange Online untuk karyawan menggunakan perangkat yang tidak dikelola berdasarkan autentikasi multifaktor, perlindungan aplikasi, dan aplikasi klien yang disetujui.
- Terapkan perlindungan informasi untuk memastikan bahwa informasi sensitif tidak diunduh tanpa perlindungan yang ditingkatkan yang disediakan oleh Perlindungan Informasi Azure.
- Berikan perlindungan terhadap penyalinan dan tempel oleh tamu.
Beberapa pratinjau saat ini masuk ke pratinjau publik, jadi harapkan pembaruan untuk kumpulan kebijakan pemula Akses Bersyarat (CA) yang disarankan segera.
Panduan Akses Bersyarah
Sekarang setelah Anda memiliki sekumpulan kebijakan Akses Bersyarkat pemula, Anda perlu menyebarkannya dengan cara yang terkontrol dan bertahap. Kami menyarankan agar Anda menggunakan model penyebaran.
Berikut adalah salah satu pendekatan:
Idenya adalah untuk terlebih dahulu menyebarkan kebijakan ke sejumlah kecil pengguna dalam satu grup persona. Anda dapat menggunakan grup Microsoft Entra terkait yang disebut Persona Ring 0 untuk penyebaran ini. Setelah Anda memverifikasi bahwa semuanya berfungsi, Anda mengubah tugas menjadi grup, Persona Ring 1, yang memiliki lebih banyak anggota, dan sebagainya.
Anda kemudian mengaktifkan kebijakan dengan menggunakan pendekatan berbasis cincin yang sama hingga semua kebijakan disebarkan.
Anda biasanya mengelola anggota ring 0 dan ring 1 secara manual. Grup cincin 2 atau 3 yang berisi ratusan atau bahkan ribuan pengguna dapat dikelola melalui grup dinamis yang didasarkan pada persentase pengguna dalam persona tertentu.
Penggunaan cincin sebagai bagian dari model penyebaran bukan hanya untuk penyebaran awal. Anda juga dapat menggunakannya saat kebijakan baru atau perubahan pada kebijakan yang ada diperlukan.
Dengan penyebaran yang sudah selesai, Anda juga harus merancang dan mengimplementasikan kontrol pemantauan yang dibahas dalam prinsip Akses Bersyariah.
Selain mengotomatiskan penyebaran awal, Anda mungkin ingin mengotomatiskan perubahan pada kebijakan dengan menggunakan alur CI/CD. Anda dapat menggunakan Microsoft365DSC untuk otomatisasi ini.
Kontributor
Artikel ini dikelola oleh Microsoft. Ini awalnya ditulis oleh kontributor berikut.
Penulis utama:
- Claus Jespersen | ID Konsultan Utama&s
Untuk melihat profil LinkedIn non-publik, masuk ke LinkedIn.
Langkah berikutnya
Sumber daya terkait
Saran dan Komentar
Segera hadir: Sepanjang tahun 2024 kami akan menghentikan penggunaan GitHub Issues sebagai mekanisme umpan balik untuk konten dan menggantinya dengan sistem umpan balik baru. Untuk mengetahui informasi selengkapnya, lihat: https://aka.ms/ContentUserFeedback.
Kirim dan lihat umpan balik untuk