Membatasi akses ke penyewa

Organisasi besar yang menekankan keamanan ingin beralih ke layanan cloud seperti Microsoft 365, tetapi perlu mengetahui bahwa pengguna mereka hanya dapat mengakses sumber daya yang disetujui. Biasanya, perusahaan membatasi nama domain atau alamat IP ketika mereka ingin mengelola akses. Pendekatan ini gagal di dunia di mana aplikasi perangkat lunak sebagai layanan (atau SaaS) dihosting di cloud publik, berjalan pada nama domain bersama seperti outlook.office.com dan login.microsoftonline.com. Memblokir alamat ini akan mencegah pengguna mengakses Outlook di web sepenuhnya, bukannya hanya membatasi mereka ke identitas dan sumber daya yang disetujui.

Solusi Microsoft Entra untuk tantangan ini adalah fitur yang disebut pembatasan penyewa. Dengan pembatasan penyewa, organisasi dapat mengontrol akses ke aplikasi cloud SaaS, berdasarkan penyewa Microsoft Entra yang digunakan aplikasi untuk akses menyeluruh. Misalnya, Anda mungkin ingin mengizinkan akses ke aplikasi Microsoft 365 organisasi Anda, sambil mencegah akses ke instans organisasi lain dari aplikasi yang sama ini.

Dengan pembatasan penyewa, organisasi dapat menentukan daftar penyewa yang diizinkan untuk diakses oleh pengguna di jaringan mereka. ID Microsoft Entra kemudian hanya memberikan akses ke penyewa yang diizinkan ini - semua penyewa lain diblokir, bahkan penyewa tempat pengguna Anda mungkin menjadi tamu.

Artikel ini berfokus pada pembatasan penyewa untuk Microsoft 365, tetapi fitur ini melindungi semua aplikasi yang mengirim pengguna ke ID Microsoft Entra untuk akses menyeluruh. Jika Anda menggunakan aplikasi SaaS dengan penyewa Microsoft Entra yang berbeda dari penyewa yang digunakan oleh Microsoft 365 Anda, pastikan bahwa semua penyewa yang diperlukan diizinkan. (Misalnya, dalam skenario kolaborasi B2B). Untuk informasi selengkapnya tentang aplikasi cloud SaaS, lihat Active Directory Marketplace.

Fitur pembatasan penyewa juga mendukung pemblokiran penggunaan semua aplikasi konsumen Microsoft (aplikasi MSA) seperti OneDrive, Hotmail, dan Xbox.com. Fungsionalitas ini menggunakan header terpisah ke login.live.com titik akhir, dan dirinci di akhir artikel ini.

Cara kerjanya

Solusi keseluruhan terdiri dari komponen-komponen berikut:

1. ID Microsoft Entra: Jika Restrict-Access-To-Tenants: <permitted tenant list> header ada, Microsoft Entra-only mengeluarkan token keamanan untuk penyewa yang diizinkan.

2. Infrastruktur server proksi lokal: Infrastruktur ini adalah perangkat proksi yang mampu melakukan inspeksi Transport Layer Security (TLS). Anda harus mengonfigurasi proksi untuk menyisipkan header yang berisi daftar penyewa yang diizinkan ke dalam lalu lintas yang ditujukan untuk ID Microsoft Entra.

3. Perangkat lunak klien: Untuk mendukung pembatasan penyewa, perangkat lunak klien harus meminta token langsung dari ID Microsoft Entra, sehingga infrastruktur proksi dapat mencegat lalu lintas. Aplikasi Microsoft 365 berbasis browser saat ini mendukung pembatasan penyewa, seperti halnya klien Office yang menggunakan autentikasi modern (seperti OAuth 2.0).

4. Autentikasi Modern: Layanan cloud harus menggunakan autentikasi modern untuk menggunakan pembatasan penyewa dan memblokir akses ke semua penyewa yang tidak diizinkan. Anda harus mengonfigurasi layanan cloud Microsoft 365 untuk menggunakan protokol autentikasi modern secara default. Untuk informasi terbaru tentang dukungan Microsoft 365 untuk autentikasi modern, baca Pembaruan autentikasi modern Office 365.

Diagram berikut menggambarkan alur lalu lintas tingkat tinggi. Pembatasan penyewa hanya memerlukan inspeksi TLS pada lalu lintas ke ID Microsoft Entra, bukan ke layanan cloud Microsoft 365. Perbedaan ini penting, karena volume lalu lintas untuk autentikasi ke ID Microsoft Entra biasanya jauh lebih rendah daripada volume lalu lintas ke aplikasi SaaS seperti Exchange Online dan SharePoint Online.

Menyiapkan pembatasan penyewa

Ada dua langkah untuk memulai pembatasan penyewa. Pertama, pastikan bahwa klien Anda dapat tersambung ke alamat yang tepat. Kedua, konfigurasikan infrastruktur proksi Anda.

URL dan alamat IP

Untuk menggunakan pembatasan penyewa, klien Anda harus dapat tersambung ke URL Microsoft Entra berikut untuk mengautentikasi:

• login.microsoftonline.com
• login.microsoft.com
• login.windows.net

Selain itu, untuk mengakses Office 365, klien Anda juga harus dapat tersambung ke nama domain yang sepenuhnya memenuhi syarat (FQDN), URL, dan alamat IP yang ditentukan di URL Office 365 dan rentang alamat IP.

Konfigurasi dan persyaratan proksi

Konfigurasi berikut diperlukan untuk mengaktifkan pembatasan penyewa melalui infrastruktur proksi Anda. Panduan ini bersifat umum, sehingga Anda harus melihat dokumentasi vendor proksi Anda untuk langkah implementasi spesifik.

Prasyarat

• Proksi harus dapat melakukan intersepsi TLS, penyisipan header HTTP, dan memfilter tujuan menggunakan FQDN/URL.

• Klien harus mempercayai rantai sertifikat yang disajikan oleh proksi untuk komunikasi TLS. Misalnya, jika sertifikat dari infrastruktur kunci publik (PKI) internal digunakan, sertifikat otoritas sertifikat akar penerbit internal harus dipercaya.

• Lisensi Microsoft Entra ID P1 atau P2 diperlukan untuk penggunaan pembatasan penyewa.

Konfigurasi

Untuk setiap permintaan keluar ke login.microsoftonline.com, , dan login.windows.net, sisipkan dua header HTTP: Restrict-Access-To-Tenants dan Restrict-Access-Contextlogin.microsoft.com.

Catatan

Jangan sertakan subdomain di bawah *.login.microsoftonline.com dalam konfigurasi proksi Anda. Melakukannya akan mencakup device.login.microsoftonline.com dan akan mengganggu autentikasi Sertifikat Klien, yang digunakan dalam skenario Pendaftaran Perangkat dan Akses Bersyarat berbasis Perangkat. Konfigurasikan server proksi Anda untuk mengecualikan device.login.microsoftonline.com dan enterpriseregistration.windows.net dari pemecahan dan injeksi header TLS.

Header harus menyertakan elemen berikut:

• Untuk Batasi-Akses-Ke-Penyewa, gunakan nilai <daftar penyewa yang diizinkan>, yang merupakan daftar penyewa yang dipisahkan koma yang ingin Anda izinkan untuk diakses pengguna. Domain apa pun yang terdaftar di penyewa dapat digunakan untuk mengidentifikasi penyewa dalam daftar ini, dan ID direktori itu sendiri. Untuk contoh dari ketiga cara mendeskripsikan penyewa, pasangan nama/nilai untuk mengizinkan Contoso, Fabrikam, dan Microsoft terlihat seperti ini: Restrict-Access-To-Tenants: contoso.com,fabrikam.onmicrosoft.com,72f988bf-86f1-41af-91ab-2d7cd011db47

• Untuk Restrict-Access-Context, gunakan nilai dari satu ID direktori, yang menyatakan penyewa mana yang mengatur batasan penyewa. Misalnya, untuk menyatakan Contoso sebagai penyewa yang mengatur kebijakan pembatasan penyewa, pasangan nama/nilai terlihat seperti: Restrict-Access-Context: 456ff232-35l2-5h23-b3b3-3236w0826f3d. Anda harus menggunakan ID direktori Anda sendiri di tempat ini agar mendapatkan log untuk autentikasi ini. Jika Anda menggunakan ID direktori selain ID Anda sendiri, log masuk *muncul di penyewa orang lain, dengan semua informasi pribadi dihapus. Untuk informasi selengkapnya, lihat Pengalaman admin.

Untuk menemukan ID direktori Anda:

1. Masuk ke pusat admin Microsoft Entra sebagai setidaknya Pembaca Global.
2. Telusuri Ringkasan Ikhtisar> Identitas.>
3. Salin nilai ID Penyewa.

Untuk memvalidasi bahwa ID direktori atau nama domain merujuk ke penyewa yang sama, gunakan ID atau domain tersebut sebagai ganti <penyewa> di URL ini: https://login.microsoftonline.com/<tenant>/v2.0/.well-known/openid-configuration. Jika hasil dengan domain dan ID sama, hasil tersebut merujuk ke penyewa yang sama.

Untuk mencegah pengguna menyisipkan header HTTP mereka sendiri dengan penyewa yang tidak disetujui, proksi perlu mengganti header Restrict-Access-To-Tenants jika sudah ada dalam permintaan masuk.

Klien harus dipaksa untuk menggunakan proksi untuk semua permintaan ke login.microsoftonline.com, login.microsoft.com, dan login.windows.net. Misalnya, jika file PAC digunakan untuk mengarahkan klien untuk menggunakan proksi, pengguna akhir seharusnya tidak dapat mengedit atau menonaktifkan file PAC.

Pengalaman pengguna

Bagian ini menjelaskan pengalaman untuk pengguna akhir dan admin.

Pengalaman pengguna akhir

Contoh pengguna ada di jaringan Contoso, tetapi mencoba mengakses instans Fabrikam dari aplikasi SaaS bersama seperti Outlook online. Jika Fabrikam adalah penyewa yang tidak diizinkan untuk instans Contoso, pengguna akan melihat pesan penolakan akses. Pesan penolakan mengatakan Anda mencoba mengakses sumber daya milik organisasi yang tidak disetujui oleh departemen TI Anda.

Pengalaman admin

Meskipun konfigurasi pembatasan penyewa dilakukan pada infrastruktur proksi perusahaan, admin dapat mengakses laporan pembatasan penyewa di pusat admin Microsoft Entra secara langsung. Untuk melihat laporan:

1. Masuk ke pusat admin Microsoft Entra sebagai setidaknya Pembaca Global.
2. Telusuri pembatasan Penyewa Gambaran Umum>Identitas.>

Admin untuk penyewa yang ditentukan sebagai penyewa Restricted-Access-Context dapat menggunakan laporan ini untuk melihat upaya masuk yang diblokir karena kebijakan pembatasan penyewa, termasuk identitas yang digunakan dan ID direktori target. Proses masuk disertakan jika penyewa yang mengatur pembatasan adalah penyewa pengguna atau penyewa sumber daya untuk masuk.

Laporan mungkin berisi informasi terbatas, seperti ID direktori target, saat pengguna yang berada di penyewa selain penyewa Restricted-Access-Context masuk. Dalam hal ini, informasi yang dapat diidentifikasi pengguna, seperti nama dan nama prinsipal pengguna, ditutupi untuk melindungi data pengguna di penyewa lain (Misalnya, "{PII Removed}@domain.com" or 00000000-0000-0000-0000-000000000000 menggantikan nama pengguna dan ID objek sebagaimana mestinya).

Seperti laporan lain di pusat admin Microsoft Entra, Anda dapat menggunakan filter untuk menentukan cakupan laporan Anda. Anda dapat memfilter pada interval waktu, pengguna, aplikasi, klien, atau status tertentu. Jika Anda memilih tombol Kolom, Anda bisa memilih untuk menampilkan data dengan kombinasi bidang berikut:

• Pengguna - bidang ini dapat menghapus data pribadi, di mana nilainya diatur ke 00000000-0000-0000-0000-000000000000.
• Aplikasi
• Keadaan
• Tanggal
• Tanggal (UTC) - di mana UTC adalah Waktu Universal Terkoordinasi
• Alamat IP
• Klien
• Nama pengguna - bidang ini dapat menghapus data pribadi, di mana nilainya diatur ke {PII Removed}@domain.com
• Location
• ID penyewa target

Dukungan Microsoft 365

Aplikasi Microsoft 365 harus memenuhi dua kriteria untuk mendukung sepenuhnya pembatasan penyewa:

1. Klien yang digunakan mendukung autentikasi modern.
2. Autentikasi modern diaktifkan sebagai protokol autentikasi default untuk layanan cloud.

Untuk informasi terbaru tentang klien Office yang saat ini mendukung autentikasi modern, lihat Memperbarui autentikasi modern Office 365. Halaman tersebut juga menyertakan tautan ke instruksi untuk mengaktifkan autentikasi modern pada penyewa Exchange Online dan Skype for Business Online tertentu. SharePoint Online sudah mengaktifkan Autentikasi modern secara default. Teams hanya mendukung autentikasi modern, dan tidak mendukung autentikasi warisan, sehingga masalah bypass ini tidak berlaku untuk Teams.

Aplikasi berbasis browser Microsoft 365 (seperti Portal Office, Yammer, situs SharePoint, dan Outlook di Web.) saat ini mendukung pembatasan penyewa. Klien tebal (Outlook, Skype for Business, Word, Excel, PowerPoint, dan lainnya) bisa memberlakukan pembatasan penyewa hanya saat menggunakan autentikasi modern.

Klien Outlook dan Skype for Business yang mendukung autentikasi modern mungkin masih dapat menggunakan protokol warisan terhadap penyewa di mana autentikasi modern tidak diaktifkan, secara efektif melewati pembatasan penyewa. Pembatasan penyewa dapat memblokir aplikasi yang menggunakan protokol warisan jika mereka menghubungi login.microsoftonline.com, , login.microsoft.comatau login.windows.net selama autentikasi.

Untuk Outlook di Windows, pelanggan mungkin memilih untuk menerapkan pembatasan yang mencegah pengguna akhir menambahkan akun email yang tidak disetujui ke profil mereka. Misalnya, lihat pengaturan kebijakan Mencegah penambahan grup akun Exchange nondefault.

Ketidakcocokan Azure RMS dan Enkripsi Pesan Office

Fitur Azure Rights Management Service (RMS) dan Office Message Encryption tidak kompatibel dengan pembatasan penyewa. Fitur-fitur ini bergantung pada penandatanganan pengguna Anda ke penyewa lain untuk mendapatkan kunci dekripsi untuk dokumen terenkripsi. Karena pembatasan penyewa memblokir akses ke penyewa lain, email dan dokumen terenkripsi yang dikirim ke pengguna Anda dari penyewa yang tidak tepercaya tidak dapat diakses.

Pengujian

Jika Anda ingin mencoba pembatasan penyewa sebelum menerapkannya untuk seluruh organisasi, Anda memiliki dua opsi: pendekatan berbasis host menggunakan alat seperti Fiddler, atau peluncuran bertahap pengaturan proksi.

Fiddler untuk pendekatan berbasis host

Fiddler adalah proksi penelusuran kesalahan web gratis yang dapat digunakan untuk mengambil dan memodifikasi lalu lintas HTTP/HTTPS, termasuk menyisipkan header HTTP. Untuk mengonfigurasi Fiddler untuk menguji pembatasan penyewa, lakukan langkah-langkah berikut:

1. Unduh dan pasang paket.

2. Konfigurasikan Fiddler untuk mendekripsi lalu lintas HTTPS, sesuai dengan Dokumentasi bantuan Fiddler.

3. Konfigurasikan Fiddler untuk menyisipkan header Restrict-Access-To-Tenants dan Restrict-Access-Context menggunakan aturan kustom:

   1. Di alat Fiddler Web Debugger, pilih menu Aturan dan pilih Sesuaikan Aturan untuk membuka file CustomRules.

   2. Tambahkan baris berikut dalam OnBeforeRequest fungsi . Ganti <Daftar pengidentifikasi penyewa> dengan domain yang terdaftar dengan penyewa Anda (misalnya, contoso.onmicrosoft.com). Ganti <ID> direktori dengan pengidentifikasi Microsoft Entra GUID penyewa Anda. Anda harus menyertakan pengidentifikasi GUID yang benar agar log muncul di penyewa Anda.

    // Allows access to the listed tenants.
      if (
          oSession.HostnameIs("login.microsoftonline.com") ||
          oSession.HostnameIs("login.microsoft.com") ||
          oSession.HostnameIs("login.windows.net")
      )
      {
          oSession.oRequest["Restrict-Access-To-Tenants"] = "<List of tenant identifiers>";
          oSession.oRequest["Restrict-Access-Context"] = "<Your directory ID>";
      }
   
    // Blocks access to consumer apps
      if (
          oSession.HostnameIs("login.live.com")
      )
      {
          oSession.oRequest["sec-Restrict-Tenant-Access-Policy"] = "restrict-msa";
      }
   

   Jika Anda perlu mengizinkan beberapa penyewa, gunakan koma untuk memisahkan nama penyewa. Contohnya:

   oSession.oRequest["Restrict-Access-To-Tenants"] = "contoso.onmicrosoft.com,fabrikam.onmicrosoft.com";

4. Simpan dan tutup file CustomRules.

Setelah mengonfigurasi Fiddler, Anda dapat menangkap lalu lintas dengan masuk ke menu File dan memilih Capture Traffic.

Peluncuran bertahap pengaturan proksi

Bergantung pada kemampuan infrastruktur proksi, Anda mungkin dapat melakukan peluncuran pengaturan kepada pengguna Anda. Lihat opsi tingkat tinggi berikut untuk pertimbangan:

1. Gunakan file PAC untuk mengarahkan pengguna pengujian ke infrastruktur proksi pengujian, sementara pengguna normal terus menggunakan infrastruktur proksi produksi.
2. Beberapa server proksi mungkin mendukung konfigurasi yang berbeda menggunakan grup.

Untuk detail spesifik, lihat dokumentasi server proksi Anda.

Memblokir aplikasi konsumen

Aplikasi dari Microsoft yang mendukung akun konsumen dan akun organisasi, seperti OneDrive terkadang dapat dihosting di URL yang sama. Ini berarti bahwa pengguna yang harus mengakses URL tersebut untuk tujuan kerja juga memiliki akses ke URL tersebut untuk penggunaan pribadi. Opsi ini mungkin tidak diizinkan berdasarkan pedoman operasi Anda.

Beberapa organisasi mencoba memperbaiki masalah ini dengan memblokir login.live.com untuk memblokir akun pribadi agar tidak mengautentikasi. Perbaikan ini memiliki beberapa kelemahan:

1. Pemblokiran login.live.com memblokir penggunaan akun pribadi dalam skenario tamu B2B, yang dapat mengganggu pengunjung dan kolaborasi.
2. Autopilot memerlukan penggunaan login.live.com untuk menyebarkan. Skenario Intune dan Autopilot dapat gagal login.live.com saat diblokir.
3. Telemetri organisasi dan pembaruan Windows yang mengandalkan layanan login.live.com untuk ID perangkat berhenti berfungsi.

Konfigurasi untuk aplikasi konsumen

Sementara header Restrict-Access-To-Tenants berfungsi sebagai daftar yang diizinkan, blokir akun Microsoft (MSA) berfungsi sebagai sinyal penolakan, memberi tahu platform akun Microsoft untuk tidak mengizinkan pengguna masuk ke aplikasi konsumen. Untuk mengirim sinyal ini, sec-Restrict-Tenant-Access-Policy header disuntikkan ke lalu lintas yang login.live.com mengunjungi menggunakan proksi perusahaan atau firewall yang sama seperti yang disebutkan di bagian konfigurasi dan persyaratan proksi di artikel ini. Nilai header ini harus restrict-msa. Saat header ada dan aplikasi konsumen mencoba memasukkan pengguna secara langsung, proses masuk tersebut diblokir.

Saat ini, autentikasi ke aplikasi konsumen tidak muncul di log admin, karena login.live.com dihosting secara terpisah dari ID Microsoft Entra.

Apa yang dilakukan header dan tidak memblokir

Kebijakan restrict-msa memblokir penggunaan aplikasi konsumen, tetapi mengizinkan melalui beberapa jenis lalu lintas dan autentikasi lainnya:

1. Lalu lintas tanpa pengguna untuk perangkat. Opsi ini mencakup lalu lintas untuk Autopilot, Windows Update, dan telemetri organisasi.
2. Autentikasi B2B akun konsumen. Pengguna dengan akun Microsoft yang diundang untuk berkolaborasi dengan penyewa mengautentikasi ke login.live.com untuk mengakses penyewa sumber daya.
   1. Akses ini dikontrol menggunakan header Restrict-Access-To-Tenants untuk mengizinkan atau menolak akses ke penyewa sumber daya tersebut.
3. Autentikasi "Passthrough", digunakan oleh banyak aplikasi Azure dan Office.com, di mana aplikasi menggunakan ID Microsoft Entra untuk memasukkan pengguna konsumen dalam konteks konsumen.
   1. Akses ini juga dikontrol menggunakan header Restrict-Access-To-Tenants untuk mengizinkan atau menolak akses ke penyewa khusus "passthrough" (f8cdef31-a31e-4b4a-93e4-5f571e91255a). Jika penyewa ini tidak muncul dalam Restrict-Access-To-Tenants daftar domain yang diizinkan, ID Microsoft Entra memblokir akun konsumen agar tidak masuk ke aplikasi ini.

Platform yang tidak mendukung pemutusan dan inspeksi TLS

Pembatasan penyewa tergantung pada injeksi daftar penyewa yang diizinkan di header HTTPS. Dependensi ini mengharuskan Pemeriksaan Keamanan Lapisan Transportasi (TLSI) untuk memecah dan memeriksa lalu lintas. Untuk lingkungan di mana sisi klien tidak dapat merusak dan memeriksa lalu lintas untuk menambahkan header, pembatasan penyewa tidak berfungsi.

Ambil contoh Android 7.0 dan seterusnya. Android mengubah caranya menangani otoritas sertifikat tepercaya (CA) untuk menyediakan default yang lebih aman untuk lalu lintas aplikasi yang aman. Untuk informasi selengkapnya, lihat Perubahan pada Otoritas Sertifikat Tepercaya di Android Nougat.

Mengikuti rekomendasi dari Google, aplikasi klien Microsoft mengabaikan sertifikat pengguna secara default. Kebijakan ini membuat aplikasi tersebut tidak dapat bekerja dengan pembatasan penyewa, karena sertifikat yang digunakan oleh proksi jaringan diinstal di penyimpanan sertifikat pengguna, yang tidak dipercaya oleh aplikasi klien.

Untuk lingkungan seperti itu yang tidak dapat merusak dan memeriksa lalu lintas untuk menambahkan parameter pembatasan penyewa ke header, fitur lain dari ID Microsoft Entra dapat memberikan perlindungan. Daftar berikut ini menyediakan informasi selengkapnya tentang fitur Microsoft Entra tersebut.

• Akses Bersyar: Hanya izinkan penggunaan perangkat terkelola/patuh
• Akses Bersyar: Mengelola akses untuk pengguna tamu/eksternal
• Kolaborasi B2B: Membatasi aturan keluar dengan akses Lintas penyewa untuk penyewa yang sama yang tercantum dalam parameter "Restrict-Access-To-Tenants"
• Kolaborasi B2B: Membatasi undangan untuk pengguna B2B ke domain yang sama yang tercantum dalam parameter "Batasi Akses-ke-Penyewa"
• Manajemen aplikasi: Membatasi bagaimana pengguna menyetujui aplikasi
• Intune: Terapkan Kebijakan Aplikasi melalui Intune untuk membatasi penggunaan aplikasi terkelola hanya ke UPN akun yang mendaftarkan perangkat - Periksa bagian di bawah, Izinkan hanya akun organisasi yang dikonfigurasi di subjudul aplikasi .

Namun, beberapa skenario tertentu hanya dapat dibahas menggunakan pembatasan penyewa.

Langkah berikutnya

• Membaca tentang Pembaruan autentikasi modern Office 365
• Meninjau URL Office 365 dan rentang alamat IP