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 lingkungan di mana aplikasi perangkat lunak sebagai layanan (atau SaaS) dihosting di cloud publik, berjalan di 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 Azure Active Directory (Azure AD) untuk tantangan ini adalah fitur yang disebut pembatasan penyewa. Dengan pembatasan penyewa, organisasi dapat mengontrol akses ke aplikasi cloud SaaS, berdasarkan penyewa Azure AD yang digunakan aplikasi untuk akses menyeluruh. Misalnya, Anda mungkin ingin mengizinkan akses ke aplikasi Microsoft 365 organisasi Anda, sekaligus 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. Azure AD kemudian hanya memberikan akses ke penyewa yang diizinkan ini - semua penyewa lainnya diblokir, bahkan penyewa yang mungkin menjadi tamu pengguna Anda.

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

Selain itu, fitur pembatasan penyewa kini mendukung pemblokiran penggunaan semua aplikasi konsumen Microsoft (aplikasi MSA) seperti OneDrive, Hotmail, dan Xbox.com. Ini menggunakan header terpisah ke titik akhir login.live.com, dan dirinci di akhir dokumen.

Cara kerjanya

Solusi keseluruhan terdiri dari komponen-komponen berikut:

  1. Azure Active Directory: Jika header ada, Azure AD hanya 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 Azure Active Directory.

  3. Perangkat lunak klien: Untuk mendukung pembatasan penyewa, perangkat lunak klien harus meminta token langsung dari Azure Active Directory, sehingga infrastruktur proksi dapat menahan 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 pemeriksaan TLS pada lalu lintas ke Azure Active Directory, bukan ke layanan cloud Microsoft 365. Perbedaan ini penting, karena volume lalu lintas untuk autentikasi ke Azure Active Directory biasanya jauh lebih rendah daripada volume lalu lintas ke aplikasi SaaS seperti Exchange Online dan SharePoint Online.

Tenant restrictions traffic flow - diagram

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 terhubung ke URL Azure AD berikut untuk mengautentikasi:

  • http://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 Azure Active Directory Premium 1 diperlukan untuk penggunaan Pembatasan Penyewa.

Konfigurasi

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

Catatan

Jangan sertakan subdomain di bawah *.login.microsoftonline.com dalam konfigurasi proksi Anda. Melakukannya akan menyertakan 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 TLS break-and-inspect dan injeksi header.

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 dengan penyewa dapat digunakan untuk mengidentifikasi penyewa dalam daftar ini, serta 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 menggunakan ID direktori selain milik Anda sendiri, log masuk tersebut akan muncul di penyewa orang lain, dengan semua informasi pribadi dihapus. Untuk informasi selengkapnya, lihat Pengalaman admin.

Tip

Anda dapat menemukan ID direktori Anda di portal Azure Active Directory. Masuk sebagai administrator, pilih Azure Active Directory, lalu pilih Properti.

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 untuk 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, yang mengatakan Anda mencoba mengakses sumber daya milik organisasi yang tidak disetujui oleh departemen TI Anda.

Tenant restrictions error message, from April 2021

Pengalaman admin

Saat konfigurasi pembatasan penyewa dilakukan pada infrastruktur proksi perusahaan, admin dapat mengakses laporan pembatasan penyewa di portal Microsoft Azure secara langsung. Untuk melihat laporan:

  1. Masuk ke portal Microsoft Azure Active Directory. Dasbor pusat admin Azure Active Directory muncul.

  2. Di panel kiri, pilih Azure Active Directory. Halaman gambaran umum Azure Active Directory muncul.

  3. Pada halaman Gambaran Umum, pilih Pembatasan penyewa.

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 tersebut mungkin berisi informasi terbatas, seperti ID direktori target, saat pengguna yang berada di penyewa selain penyewa Restricted-Access-Context masuk. Dalam hal ini, informasi pengenal pengguna, seperti nama dan nama utama pengguna, disembunyikan untuk melindungi data pengguna di penyewa lain ("{PII Dihapus}@domain.com" atau 00000000-0000-0000-0000-000000000000 sebagai ganti nama pengguna dan ID objek yang sesuai).

Seperti laporan lain di portal Microsoft Azure, Anda bisa 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 dan akan diatur ke 00000000-0000-0000-0000-000000000000.
  • Aplikasi
  • Status
  • Tanggal
  • Tanggal (UTC) - di mana UTC adalah Waktu Universal Terkoordinasi
  • Alamat IP
  • Klien
  • Nama pengguna - bidang ini dapat menghapus data pribadi, yang akan diatur ke {PII Removed}@domain.com
  • Lokasi
  • 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.

Lihat Pembaruan autentikasi modern Office 365 untuk informasi terbaru di mana klien Office saat ini mendukung autentikasi modern. 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 lama, jadi masalah pengabaian ini tidak berlaku untuk Teams.

Aplikasi berbasis browser Microsoft 365 (Portal Office, Yammer, situs SharePoint, Outlook di Web, dan lainnya) 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 bisa 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.com, atau login.windows.net selama autentikasi.

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

Ketidakcocokan Azure RMS dan Enkripsi Pesan Office

Fitur Azure Rights Management Service (RMS) dan Enkripsi Pesan Office tidak kompatibel dengan batasan 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, surat dan dokumen terenkripsi yang dikirim ke pengguna Anda dari penyewa yang tidak tepercaya tidak akan 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 debugging web gratis yang dapat digunakan untuk menangkap 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 di awal fungsi OnBeforeRequest. Ganti <Daftar pengidentifikasi penyewa> dengan domain yang terdaftar dengan penyewa Anda (misalnya, contoso.onmicrosoft.com). Ganti <ID direktori> dengan pengidentifikasi GUID Azure Active Directory 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 secara bertahap kepada pengguna Anda. Berikut adalah beberapa opsi tingkat tinggi untuk dipertimbangkan:

  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, atau Microsoft Learn, terkadang dapat dihosting di URL yang sama. Ini berarti bahwa pengguna yang harus mengakses URL tersebut untuk tujuan kerja juga memiliki akses ke sana untuk penggunaan pribadi, yang mungkin tidak diizinkan berdasarkan pedoman operasi Anda.

Beberapa organisasi berusaha memperbaikinya dengan memblokir login.live.com untuk memblokir akun pribadi agar tidak mengautentikasi. 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 login.live.com layanan untuk KARTU perangkat akan 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, header sec-Restrict-Tenant-Access-Policy dimasukkan ke lalu lintas yang mengunjungi login.live.com menggunakan proksi atau firewall perusahaan yang sama seperti di atas. Nilai header ini harus restrict-msa. Ketika header ada dan aplikasi konsumen mencoba untuk masuk ke pengguna secara langsung, upaya masuk itu akan diblokir.

Saat ini, autentikasi ke aplikasi konsumen tidak muncul di log admin, karena login.live.com dihosting secara terpisah dari Azure Active Directory.

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. Ini termasuk 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 serta Office.com, di mana aplikasi menggunakan Azure Active Directory 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 di daftar Restrict-Access-To-Tenants domain yang diizinkan, akun konsumen akan diblokir oleh Azure Active Directory untuk masuk ke aplikasi ini.

Langkah berikutnya