Omezení přístupu k tenantovi

Velké organizace, které zvýrazňují zabezpečení, chtějí přejít na cloudové služby, jako je Microsoft 365, ale potřebují vědět, že jejich uživatelé mají přístup jenom ke schváleným prostředkům. Společnosti tradičně omezují názvy domén nebo IP adresy, když chtějí spravovat přístup. Tento přístup selže ve světě, kde jsou aplikace typu software jako služba (nebo SaaS) hostované ve veřejném cloudu, které běží na názvech sdílených domén, jako jsou outlook.office.com a login.microsoftonline.com. Blokování těchto adres by uživatelům znemožňovalo přístup k Outlooku na webu zcela místo toho, aby je omezili na schválené identity a prostředky.

Řešení Azure Active Directory (Azure AD) pro tento problém je funkce označovaná jako omezení tenanta. S omezeními tenanta můžou organizace řídit přístup ke cloudovým aplikacím SaaS na základě tenanta Azure AD, který aplikace používají pro jednotné přihlašování. Můžete například chtít povolit přístup k aplikacím Microsoftu 365 vaší organizace a zároveň zabránit přístupu k instancím těchto stejných aplikací jiných organizací.

S omezeními tenantů můžou organizace určit seznam tenantů, ke kterým mají uživatelé ve své síti povolený přístup. Azure AD pak udělí přístup jenom k těmto povoleným tenantům – všechny ostatní tenanty jsou blokované, a to i ty, ve kterých mohou být vaši uživatelé hosty.

Tento článek se zaměřuje na omezení tenanta pro Microsoft 365, ale tato funkce chrání všechny aplikace, které odesílají uživatele do Azure AD pro jednotné přihlašování. Pokud používáte aplikace SaaS s jiným tenantem Azure AD od tenanta používaného microsoftem 365, ujistěte se, že jsou povoleni všichni požadovaná tenanta (např. ve scénářích spolupráce B2B). Další informace o cloudových aplikacích SaaS najdete na webu Active Directory Marketplace.

Kromě toho funkce omezení tenanta teď podporuje blokování používání všech uživatelských aplikací Microsoftu (aplikací MSA), jako jsou OneDrive, Hotmail a Xbox.com. To používá samostatnou hlavičku koncového login.live.com bodu a je podrobně popsáno na konci dokumentu.

Jak to funguje

Celkové řešení se skládá z následujících komponent:

  1. Azure AD: Pokud je hlavička Restrict-Access-To-Tenants: <permitted tenant list> k dispozici, Azure AD vydává pouze tokeny zabezpečení pro povolené tenanty.

  2. Infrastruktura místního proxy serveru: Tato infrastruktura je proxy zařízení schopné kontroly protokolu TLS (Transport Layer Security). Proxy server musíte nakonfigurovat tak, aby vložil hlavičku obsahující seznam povolených tenantů do provozu určeného pro Azure AD.

  3. Klientský software: Aby klientský software podporoval omezení tenanta, musí klientský software požadovat tokeny přímo ze služby Azure AD, aby infrastruktura proxy serveru mohl zachytit provoz. Aplikace Microsoft 365 založené na prohlížeči v současné době podporují omezení tenanta, stejně jako klienti Office, kteří používají moderní ověřování (například OAuth 2.0).

  4. Moderní ověřování: Cloudové služby musí používat moderní ověřování, aby používaly omezení tenanta a blokovaly přístup ke všem nepovoleným tenantům. Cloudové služby Microsoftu 365 musíte nakonfigurovat tak, aby ve výchozím nastavení používaly moderní ověřovací protokoly. Nejnovější informace o podpoře moderního ověřování v Microsoftu 365 najdete v článku Aktualizované moderní ověřování Office 365.

Následující diagram znázorňuje tok provozu vysoké úrovně. Omezení tenanta vyžadují kontrolu protokolu TLS jenom u provozu do Azure AD, nikoli do cloudových služeb Microsoftu 365. Tento rozdíl je důležitý, protože objem provozu pro ověřování do Azure AD je obvykle mnohem nižší než objem provozu do aplikací SaaS, jako je Exchange Online a SharePoint Online.

Tenant restrictions traffic flow - diagram

Nastavení omezení tenanta

Začněte s omezeními tenanta dvěma kroky. Nejprve se ujistěte, že se klienti můžou připojit ke správným adresům. Za druhé nakonfigurujte infrastrukturu proxy serveru.

Adresy URL a IP adresy

Pokud chcete použít omezení tenanta, musí být vaši klienti schopni se připojit k následujícím adresám URL služby Azure AD, které se mají ověřit:

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

Kromě toho musí mít klienti přístup k Office 365 i k plně kvalifikovaným názvům domén (FQDN), adresám URL a IP adresám definovaným v adresách URL a rozsahech IP adres Office 365.

Konfigurace a požadavky proxy serveru

K povolení omezení tenanta prostřednictvím vaší infrastruktury proxy serveru se vyžaduje následující konfigurace. Tyto doprovodné materiály jsou obecné, proto byste se měli podívat na dokumentaci od dodavatele proxy serveru ke konkrétním krokům implementace.

Požadavky

  • Proxy server musí být schopný provádět zachycování protokolu TLS, vkládání hlaviček HTTP a filtrování cílů pomocí plně kvalifikovaných názvů domén a adres URL.

  • Klienti musí důvěřovat řetězu certifikátů předaný proxy serverem pro komunikaci tls. Pokud se například používají certifikáty z interní infrastruktury veřejných klíčů (PKI), musí být důvěryhodný interní certifikát kořenové certifikační autority.

  • Licence Azure AD Premium 1 se vyžadují pro použití omezení tenanta.

Konfigurace

Pro každý odchozí požadavek pro login.microsoftonline.com, login.microsoft.com a login.windows.net vložte dvě hlavičky HTTP: Omezit přístup k tenantům a omezit kontext přístupu.

Poznámka

Do konfigurace proxy serveru nezahrnujte subdomény *.login.microsoftonline.com . To bude zahrnovat device.login.microsoftonline.com a bude kolidovat s ověřováním klientských certifikátů, který se používá ve scénářích registrace zařízení a podmíněného přístupu na základě zařízení. Nakonfigurujte proxy server tak, aby vyloučil device.login.microsoftonline.com a enterpriseregistration.windows.net z injektáže a injektáže hlaviček protokolu TLS.

Hlavičky by měly obsahovat následující prvky:

  • V případě omezení přístupu k tenantům použijte hodnotu seznamu povolených <tenantů>, což je seznam tenantů oddělených čárkami, ke kterým chcete uživatelům povolit přístup. Libovolnou doménu, která je zaregistrovaná v tenantovi, se dá použít k identifikaci tenanta v tomto seznamu a také k samotnému ID adresáře. Příklad všech tří způsobů popisu tenanta, dvojice název/hodnota, která umožňuje společnosti Contoso, Fabrikam a Microsoft, vypadá takto: Restrict-Access-To-Tenants: contoso.com,fabrikam.onmicrosoft.com,72f988bf-86f1-41af-91ab-2d7cd011db47

  • Pro omezení přístupu do kontextu použijte hodnotu ID jednoho adresáře deklarující, který tenant nastavuje omezení tenanta. Pokud chcete například deklarovat contoso jako tenanta, který nastavil zásady omezení tenanta, pár name/value vypadá takto: Restrict-Access-Context: 456ff232-35l2-5h23-b3b3-3236w0826f3d. Pokud chcete získat protokoly pro tato ověřování, musíte zde použít vlastní ID adresáře. Pokud použijete jiné ID adresáře než vlastní, zobrazí se tyto protokoly přihlašování v tenantovi někoho jiného s odebranými osobními údaji. Další informace najdete v tématu Prostředí pro správu.

Tip

ID adresáře najdete na portálu Azure Active Directory. Přihlaste se jako správce, vyberte Azure Active Directory a pak vyberte Vlastnosti.

Pokud chcete ověřit, že ID adresáře nebo název domény odkazuje na stejného tenanta, použijte toto ID nebo doménu místo <tenanta> v této adrese URL: https://login.microsoftonline.com/<tenant>/v2.0/.well-known/openid-configuration. Pokud jsou výsledky s doménou a ID stejné, odkazují na stejného tenanta.

Aby uživatelé nemohli vložit vlastní hlavičku HTTP s neschválnými tenanty, musí proxy nahradit hlavičku Restrict-Access-To-Tenants , pokud už v příchozím požadavku existuje.

Klienti musí být nuceni používat proxy server pro všechny požadavky na login.microsoftonline.com, login.microsoft.com a login.windows.net. Pokud se například soubory PAC používají k nasměrování klientů na používání proxy serveru, koncoví uživatelé by neměli moct soubory PAC upravovat ani zakázat.

Uživatelské prostředí

Tato část popisuje prostředí pro koncové uživatele i správce.

Prostředí koncového uživatele

Ukázkový uživatel je v síti Contoso, ale pokouší se získat přístup k instanci Fabrikam sdílené aplikace SaaS, jako je Outlook Online. Pokud je Fabrikam pro instanci Contoso nepovolený tenant, zobrazí se uživateli zpráva o odepření přístupu, která říká, že se pokoušíte získat přístup k prostředku, který patří do organizace neschválené vaším IT oddělením.

Tenant restrictions error message, from April 2021

Prostředí pro správu

I když se konfigurace omezení tenanta provádí v infrastruktuře podnikového proxy serveru, mají správci přístup k sestavám omezení tenanta přímo na webu Azure Portal. Zobrazení sestav:

  1. Přihlaste se k portálu Azure Active Directory. Zobrazí se řídicí panel Centra pro správu Azure Active Directory .

  2. V levém podokně vyberte Azure Active Directory. Zobrazí se stránka přehledu Služby Azure Active Directory.

  3. Na stránce Přehled vyberte omezení tenanta.

Správce tenanta zadaného jako tenant s omezeným přístupem a kontextem může tuto sestavu použít k zobrazení blokovaných přihlášení kvůli zásadám omezení tenanta, včetně identity použité a ID cílového adresáře. Přihlášení jsou zahrnuta v případě, že se jedná o nastavení tenanta uživatele nebo tenanta prostředku pro přihlášení.

Sestava může obsahovat omezené informace, například ID cílového adresáře, pokud se uživatel, který je v jiném tenantovi než tenant s omezeným přístupem, přihlásí. V tomto případě se identifikovatelné informace uživatele, jako je jméno a hlavní název uživatele, maskují za účelem ochrany uživatelských dat v jiných tenantech ({PII Removed}@domain.com" nebo 0000000-0000-0000-00000-000000000000 místo uživatelských jmen a ID objektů podle potřeby).

Stejně jako jiné sestavy na webu Azure Portal můžete pomocí filtrů určit rozsah sestavy. Můžete filtrovat podle určitého časového intervalu, uživatele, aplikace, klienta nebo stavu. Pokud vyberete tlačítko Sloupce , můžete se rozhodnout zobrazit data s libovolnou kombinací následujících polí:

  • Uživatel – toto pole může mít odebrané osobní údaje, kde budou nastaveny na 00000000-0000-0000-0000-000000000000.
  • Aplikace
  • Stav
  • Date (Datum)
  • Datum (UTC) – kde UTC je koordinovaný univerzální čas
  • IP adresa
  • Klient
  • Uživatelské jméno – toto pole může obsahovat odebrání osobních údajů, kde se nastaví na {PII Removed}@domain.com
  • Umístění
  • ID cílového tenanta

Podpora Microsoftu 365

Aplikace Microsoft 365 musí splňovat dvě kritéria, aby plně podporovaly omezení tenanta:

  1. Použitý klient podporuje moderní ověřování.
  2. Moderní ověřování je povolené jako výchozí ověřovací protokol cloudové služby.

Nejnovější informace o tom, na kterých klienti Office aktuálně podporují moderní ověřování, najdete v části Aktualizované moderní ověřování Office 365 . Tato stránka obsahuje také odkazy na pokyny pro povolení moderního ověřování u konkrétních tenantů Exchange Online a Online Skypu pro firmy. SharePoint Online už ve výchozím nastavení povoluje moderní ověřování. Teams podporuje pouze moderní ověřování a nepodporuje starší ověřování, takže se tento problém o obejití nevztahuje na Teams.

Aplikace založené na prohlížeči Microsoftu 365 (portál Office, Yammer, sharepointové weby, Outlook na webu a další) v současné době podporují omezení tenanta. Silní klienti (Outlook, Skype pro firmy, Word, Excel, PowerPoint a další) můžou vynutit omezení tenanta jenom při použití moderního ověřování.

Klienti Outlooku a Skypu pro firmy, kteří podporují moderní ověřování, můžou stále používat starší protokoly vůči tenantům, u kterých není povolené moderní ověřování a efektivně obchází omezení tenanta. Omezení tenanta můžou blokovat aplikace, které používají starší protokoly, pokud během ověřování kontaktují login.microsoftonline.com, login.microsoft.com nebo login.windows.net.

U Outlooku ve Windows se zákazníci můžou rozhodnout implementovat omezení, která koncovým uživatelům brání v přidávání neschváliných poštovních účtů do svých profilů. Podívejte se například na nastavení zásad skupiny Zabránit přidání jiných než výchozích účtů Exchange .

Nekompatibility šifrování zpráv Azure RMS a Office

Funkce Azure Rights Management Service (RMS) a Office Message Encryption nejsou kompatibilní s omezeními tenanta. Tyto funkce spoléhají na podepisování uživatelů do jiných tenantů, aby získali dešifrovací klíče pro šifrované dokumenty. Vzhledem k tomu, že omezení tenantů blokuje přístup k jiným tenantům, nebudou šifrované e-maily a dokumenty odeslané uživatelům z nedůvěryhodných tenantů přístupné.

Testování

Pokud chcete vyzkoušet omezení tenanta před implementací pro celou organizaci, máte dvě možnosti: přístup založený na hostiteli pomocí nástroje, jako je Fiddler, nebo postupné zavedení nastavení proxy serveru.

Fiddler pro přístup založený na hostiteli

Fiddler je bezplatný proxy webových ladění, které lze použít k zachycení a úpravě provozu HTTP/HTTPS, včetně vkládání hlaviček HTTP. Pokud chcete nakonfigurovat Fiddler pro testování omezení tenanta, proveďte následující kroky:

  1. Stáhněte a nainstalujte Fiddler.

  2. Nakonfigurujte Fiddler k dešifrování provozu HTTPS podle dokumentace nápovědy fiddler.

  3. Nakonfigurujte Fiddler tak, aby vložil hlavičky Restrict-Access-To-Tenants a Restrict-Access-Context pomocí vlastních pravidel:

    1. V nástroji Fiddler Web Debugger vyberte nabídku Pravidla a vyberte Přizpůsobit pravidla... a otevřete soubor CustomRules.

    2. Na začátek OnBeforeRequest funkce přidejte následující řádky. Nahraďte <seznam identifikátorů tenanta> doménou zaregistrovanou ve vašem tenantovi (například contoso.onmicrosoft.com). Nahraďte <ID> adresáře identifikátorem GUID azure AD vašeho tenanta. Aby se protokoly zobrazovaly ve vašem tenantovi, musíte zahrnout správný identifikátor GUID.

     // 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";
       }
    

    Pokud potřebujete povolit více tenantů, oddělte názvy tenantů čárkou. Příklad:

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

  4. Uložte a zavřete soubor CustomRules.

Po nakonfigurování Fiddler můžete zaznamenat provoz tak, že přejdete do nabídky Soubor a vyberete Zachytit provoz.

Postupné zavedení nastavení proxy serveru

V závislosti na možnostech vaší infrastruktury proxy může být možné nastavit nastavení uživatelům. Tady je několik možností vysoké úrovně, které je potřeba vzít v úvahu:

  1. Pomocí souborů PAC můžete nasměrovat testovací uživatele na testovací proxy infrastrukturu, zatímco normální uživatelé budou dál používat produkční infrastrukturu proxy serveru.
  2. Některé proxy servery můžou podporovat různé konfigurace pomocí skupin.

Konkrétní podrobnosti najdete v dokumentaci k proxy serveru.

Blokování uživatelských aplikací

Aplikace od Microsoftu, které podporují účty uživatelů i účty organizace, jako je OneDrive nebo Microsoft Learn, můžou být někdy hostované na stejné adrese URL. To znamená, že uživatelé, kteří musí k této adrese URL přistupovat pro pracovní účely, mají také přístup k osobnímu použití, což nemusí být povoleno podle vašich provozních pokynů.

Některé organizace se snaží tento problém vyřešit tím, že zablokují login.live.com ověřování osobních účtů. To má několik nevýhod:

  1. Blokování blokuje login.live.com používání osobních účtů ve scénářích hosta B2B, které můžou narušit návštěvníky a spolupráci.
  2. Autopilot vyžaduje použití login.live.com k nasazení. Scénáře Intune a Autopilotu můžou selhat, když login.live.com jsou zablokované.
  3. Telemetrie organizace a aktualizace Windows, které spoléhají na službu login.live.com pro ID zařízení , přestanou fungovat.

Konfigurace pro aplikace pro spotřebitele

Zatímco hlavička Restrict-Access-To-Tenants funguje jako seznam povolených, blok účtu Microsoft (MSA) funguje jako signál odepření, který platformě účtu Microsoft říká, aby uživatelům nepovolil přihlášení k uživatelským aplikacím. Pokud chcete tento signál odeslat, vloží se hlavička sec-Restrict-Tenant-Access-Policy do provozu, který login.live.com navštívíte pomocí stejného podnikového proxy serveru nebo brány firewall jako výše. Hodnota hlavičky musí být restrict-msa. Když je hlavička přítomná a aplikace příjemce se pokouší přihlásit uživatele přímo, bude toto přihlášení zablokováno.

V tuto chvíli se v protokolech správců nezobrazuje ověřování pro aplikace příjemců, protože login.live.com je hostované odděleně od Azure AD.

Co záhlaví dělá a neblokuje

Zásady restrict-msa blokují používání uživatelských aplikací, ale umožňují prostřednictvím několika dalších typů provozu a ověřování:

  1. Provoz bez uživatele pro zařízení. To zahrnuje provoz pro telemetrii Autopilotu, Windows Update a organizace.
  2. Ověřování B2B uživatelských účtů Uživatelé s účty Microsoft, kteří jsou pozvaní ke spolupráci s tenantem , se ověřují pro login.live.com s cílem získat přístup k tenantovi prostředků.
    1. Tento přístup se řídí pomocí Restrict-Access-To-Tenants hlavičky, která povolí nebo zakáže přístup k tomuto tenantovi prostředku.
  3. Předávací ověřování používané mnoha aplikacemi Azure a také Office.com, kde aplikace používají Azure AD k přihlašování uživatelů uživatelů v kontextu příjemce.
    1. Tento přístup se řídí také pomocí Restrict-Access-To-Tenants hlavičky, která povolí nebo zakáže přístup ke speciálnímu tenantovi "passthrough" (f8cdef31-a31e-4b4a-93e4-5f571e91255a). Pokud se tento tenant nezobrazuje ve vašem Restrict-Access-To-Tenants seznamu povolených domén, služba Azure AD zablokuje přihlášení k těmto aplikacím účty uživatelů.

Další kroky