Artikel ini menjelaskan arsitektur Akses Bersyariah yang mematuhi prinsip Zero Trust. Arsitektur ini menggunakan pendekatan berbasis persona untuk membentuk kerangka kerja Akses Bersyar terstruktur.
Arsitektur Zero Trust Akses Bersyar
Anda harus memilih arsitektur terlebih dahulu. Kami menyarankan agar Anda mempertimbangkan arsitektur Akses Bersayarat Targeted atau Zero Trust. Diagram ini memperlihatkan pengaturan yang sesuai:
Arsitektur Akses Bersyarat Zero Trust adalah salah satu yang paling sesuai dengan prinsip Zero Trust. Jika Anda memilih opsi Semua aplikasi cloud dalam kebijakan Akses Bersyar, semua titik akhir dilindungi oleh kontrol pemberian yang disediakan, seperti pengguna yang diketahui dan perangkat yang diketahui atau sesuai. Namun, kebijakan ini tidak hanya berlaku untuk titik akhir dan aplikasi yang mendukung Akses Bersyarat. Kebijakan tersebut berlaku untuk titik akhir apa pun yang berinteraksi dengan pengguna.
Contohnya adalah titik akhir alur masuk perangkat yang digunakan di berbagai alat PowerShell dan Microsoft Graph baru. Alur masuk perangkat menyediakan cara untuk mengizinkan masuk dari perangkat yang tidak dimungkinkan untuk menampilkan layar masuk, seperti perangkat IoT.
Perintah masuk berbasis perangkat dijalankan pada perangkat tertentu, dan kode ditampilkan kepada pengguna. Kode ini digunakan pada perangkat lain. Pengguna masuk ke https://aka.ms/devicelogin dan menentukan nama pengguna dan kata sandi mereka. Setelah masuk dari perangkat lain, rincian masuk berhasil pada perangkat IoT dalam konteks pengguna tersebut.
Masalah dengan kredensial masuk ini adalah opsi tersebut tidak mendukung Akses Bersyarat berbasis perangkat. Ini berarti bahwa tidak ada yang dapat menggunakan alat dan perintah jika Anda menerapkan kebijakan dasar yang memerlukan pengguna yang diketahui dan perangkat yang diketahui untuk semua aplikasi cloud. Ada aplikasi lain yang memiliki masalah yang sama dengan Akses Bersyarah berbasis perangkat.
Arsitektur lain, yang ditargetkan , dibangun berdasarkan prinsip bahwa Anda hanya menargetkan aplikasi individual yang ingin Anda lindungi dalam kebijakan Akses Bersyariah. Dalam hal ini, masuk perangkat untuk titik akhir yang sebelumnya dicakup oleh semua aplikasi cloud, seperti panggilan grafik ke ID Microsoft Entra, tidak dilindungi oleh kebijakan Akses Bersyarkat, sehingga terus berfungsi.
Saat menggunakan masuk perangkat sebagai contoh untuk membedakan dua arsitektur, Anda dapat mengautentikasi dengan masuk perangkat. Login perangkat berpotensi diizinkan untuk satu atau beberapa aplikasi individu, mengingat bahwa setiap aplikasi dapat ditargetkan dan dengan demikian dapat dikecualikan dalam kebijakan Akses Bersyarat yang memerlukan login berbasis perangkat.
Tantangan dengan arsitektur yang ditargetkan adalah Anda mungkin lupa melindungi semua aplikasi cloud Anda. Meskipun demikian, Anda akan memilih semua aplikasi yang dapat dipilih dalam kebijakan Akses Bersyar. Anda membiarkan akses ke aplikasi yang tidak dapat dipilih tanpa perlindungan. Contohnya termasuk akses ke portal Office, portal Azure EA (Perjanjian Enterprise), dan portal informasi keamanan, yang semuanya adalah portal yang sangat sensitif.
Pertimbangan lain adalah bahwa jumlah aplikasi Office 365 dan Microsoft Entra meningkat dari waktu ke waktu, karena Microsoft dan mitra merilis fitur baru dan sebagai admin TI Anda mengintegrasikan berbagai aplikasi dengan ID Microsoft Entra. Akses ke semua aplikasi tersebut dilindungi hanya jika Anda memiliki mekanisme yang mendeteksi aplikasi baru yang mendukung Akses Bersyar dan yang secara otomatis menerapkan kebijakan untuk aplikasi tersebut. Membuat dan memelihara skrip seperti itu mungkin sulit.
Selain itu, jumlah maksimum aplikasi yang didukung untuk satu kebijakan Akses Bersyar adalah sekitar 250. Anda mungkin dapat menambahkan sebanyak 600 aplikasi sebelum mendapatkan kesalahan tentang payload yang terlampaui, tetapi jumlah tersebut tidak didukung.
Persona Akses Bersyarah
Ada banyak cara untuk menyusun kebijakan Akses Bersyarat. Salah satu pendekatannya adalah menyusun kebijakan berdasarkan sensitivitas sumber daya yang diakses. Dalam praktiknya, pendekatan ini bisa sulit diterapkan dengan cara yang masih melindungi akses ke sumber daya untuk berbagai pengguna.
Misalnya, Anda dapat menentukan kebijakan Akses Bersyarat yang memerlukan pengguna yang dikenal dan perangkat yang dikenal untuk akses ke sumber daya sensitif yang perlu diakses oleh tamu dan karyawan. Saat tamu mencoba akses dari perangkat terkelola, permintaan akses tidak akan berfungsi. Anda harus menyesuaikan kebijakan Akses Bersyarat untuk memenuhi kedua persyaratan, yang biasanya akan menghasilkan kebijakan yang memenuhi persyaratan yang kurang aman.
Pendekatan lain adalah mencoba menentukan kebijakan akses berdasarkan tempat pengguna berada di organisasi. Pendekatan ini dapat mengakibatkan banyak kebijakan Akses Bersyarat dan mungkin tidak dapat dikelola.
Pendekatan yang lebih baik adalah menyusun kebijakan yang terkait dengan kebutuhan akses umum dan menggabungkan serangkaian kebutuhan akses dalam persona untuk sekelompok pengguna yang memiliki kebutuhan yang sama. Persona adalah jenis identitas yang berbagi atribut, tanggung jawab, pengalaman, tujuan, dan akses perusahaan umum.
Memahami cara aset dan sumber daya perusahaan diakses oleh berbagai persona adalah integral untuk mengembangkan strategi Zero Trust yang menyeluruh.
Beberapa persona Akses Bersyarat yang disarankan dari Microsoft diperlihatkan di sini:
Microsoft juga merekomendasikan guna menentukan persona terpisah untuk identitas yang bukan bagian dari grup persona lainnya. Ini disebut persona Global. Global dimaksudkan untuk menegakkan kebijakan pada identitas yang tidak berada dalam grup persona dan kebijakan yang harus diberlakukan pada semua persona.
Bagian berikut ini menjelaskan beberapa persona yang direkomendasikan.
Global
Global adalah persona/tempat penampung untuk kebijakan yang bersifat umum. Global ini digunakan untuk menentukan kebijakan yang berlaku untuk semua persona atau yang tidak berlaku untuk satu persona tertentu. Gunakan global ini untuk kebijakan yang tidak dicakup oleh persona lain. Anda memerlukan persona ini untuk melindungi semua skenario yang relevan.
Misalnya, asumsikan bahwa Anda ingin menggunakan satu kebijakan untuk memblokir autentikasi warisan untuk semua pengguna. Anda dapat menjadikannya kebijakan global alih-alih menggunakan sekelompok kebijakan warisan yang mungkin berbeda untuk berbagai persona.
Contoh lain: Anda ingin memblokir akun atau pengguna tertentu dari aplikasi tertentu, dan pengguna atau akun bukan bagian dari persona mana pun. Misalnya, jika Anda membuat identitas cloud di penyewa Microsoft Entra, identitas ini bukan bagian dari persona lain karena tidak diberi peran Microsoft Entra apa pun. Anda mungkin masih ingin memblokir identitas dari akses ke layanan Office 365.
Anda mungkin ingin memblokir semua akses dari identitas yang tidak dicakup oleh grup persona apa pun. Atau Anda mungkin hanya ingin menerapkan autentikasi multifaktor.
Admin
Dalam konteks ini, admin adalah identitas non-tamu, cloud, atau disinkronkan, yang memiliki ID Microsoft Entra atau peran admin Microsoft 365 lainnya (misalnya, di Microsoft Defender untuk Cloud Apps, Exchange, Defender for Endpoint, atau Compliance Manager). Karena tamu yang memiliki peran ini tercakup dalam persona yang berbeda, tamu dikecualikan dari persona ini.
Beberapa perusahaan memiliki akun terpisah untuk peran admin sensitif yang didasarkan pada persona ini. Secara optimal, admin menggunakan akun sensitif ini dari Stasiun Kerja Akses Istimewa (PAW). Tetapi kita sering melihat bahwa akun admin digunakan pada stasiun kerja standar, di mana pengguna hanya beralih antar akun pada satu perangkat.
Anda mungkin ingin membedakan berdasarkan sensitivitas peran admin cloud dan menetapkan peran Azure yang kurang sensitif ke persona Internal daripada menggunakan akun terpisah. Anda kemudian dapat menggunakan elevasi Just-In-Time (JIT) sebagai gantinya. Dalam hal ini, pengguna ditargetkan oleh dua set kebijakan Akses Bersyar, satu untuk setiap persona. Jika Anda menggunakan PAW, Anda mungkin juga ingin memperkenalkan kebijakan yang menggunakan filter perangkat di Akses Bersyar untuk membatasi akses sehingga admin hanya diizinkan pada PAW.
Pengembang
Persona Pengembang berisi pengguna yang memiliki kebutuhan unik. Mereka didasarkan pada akun Direktori Aktif yang disinkronkan ke ID Microsoft Entra, tetapi mereka memerlukan akses khusus ke layanan seperti Azure DevOps, alur CI/CD, alur kode perangkat, dan GitHub. Persona Pengembang dapat mencakup pengguna yang dianggap internal dan orang lain dianggap eksternal, tetapi seseorang hanya boleh berada di salah satu persona.
Internal
Internal berisi semua pengguna yang memiliki akun Direktori Aktif yang disinkronkan ke ID Microsoft Entra, yang merupakan karyawan perusahaan, dan yang bekerja dalam peran pengguna akhir standar. Sebaiknya Anda menambahkan pengguna internal yang merupakan pengembang ke persona Pengembang.
Eksternal
Persona ini menyimpan semua konsultan eksternal yang memiliki akun Direktori Aktif yang disinkronkan ke ID Microsoft Entra. Sebaiknya Anda menambahkan pengguna eksternal yang merupakan pengembang ke persona Pengembang.
Tamu
Tamu menampung semua pengguna yang memiliki akun tamu Microsoft Entra yang telah diundang ke penyewa pelanggan.
GuestAdmins
Persona GuestAdmins menampung semua pengguna yang memiliki akun tamu Microsoft Entra yang diberi salah satu peran admin yang disebutkan sebelumnya.
Microsoft365ServiceAccounts
Persona ini berisi akun layanan berbasis pengguna cloud (MICROSOFT Entra ID) yang digunakan untuk mengakses layanan Microsoft 365 saat tidak ada solusi lain yang memenuhi kebutuhan, seperti menggunakan identitas layanan terkelola.
AzureServiceAccounts
Persona ini berisi akun layanan berbasis pengguna cloud (Microsoft Entra ID) yang digunakan untuk mengakses layanan Azure (IaaS/PaaS) ketika tidak ada solusi lain yang memenuhi kebutuhan, seperti menggunakan identitas layanan terkelola.
CorpServiceAccounts
Persona ini berisi akun layanan berbasis pengguna yang memiliki semua karakteristik ini:
- Berasal dari Active Directory lokal.
- Digunakan dari lokal atau dari komputer virtual berbasis IaaS di pusat data (cloud) lain, seperti Azure.
- Disinkronkan ke instans Microsoft Entra yang mengakses layanan Azure atau Microsoft 365 apa pun.
Skenario ini harus dihindari.
Identitas Beban Kerja
Persona ini berisi identitas mesin, seperti perwakilan layanan Microsoft Entra dan identitas terkelola. Akses Bersyar sekarang mendukung perlindungan akses ke sumber daya dari akun-akun ini, dengan beberapa batasan sehubungan dengan kondisi dan kontrol pemberian mana yang tersedia.
Mengakses kartu template
Kami menyarankan agar Anda menggunakan kartu templat akses untuk menentukan karakteristik untuk setiap persona. Berikut contohnya:
Kartu template untuk setiap persona menyediakan input untuk membuat kebijakan Akses Bersyarat tertentu bagi setiap persona.
Panduan Akses Bersyarah
Tinjau kerangka kerja Akses Bersyar yang menyertakan pendekatan terstruktur untuk kebijakan pengelompokan berdasarkan persona yang dibuat.
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
- jalur Pembelajaran: Menerapkan dan mengelola identitas dan akses
- Apa yang dimaksud dengan Akses Bersyarat?
- Kebijakan Akses Bersyarat Umum