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 sdílených názvech domén, jako a outlook.office.comlogin.microsoftonline.com. Blokování těchto adres by uživatelům bránilo v přístupu k Outlook na webu zcela, místo pouhého omezení na schválené identity a prostředky.

Řešení Microsoft Entra pro tuto výzvu 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 Microsoft Entra, který aplikace používají pro jednotné přihlašování. Můžete například chtít povolit přístup k aplikacím Microsoft 365 vaší organizace a zároveň zabránit přístupu k instancím těchto stejných aplikací jiných organizací.

V případě omezení tenantů můžou organizace určit seznam tenantů, ke kterým mají uživatelé v síti povolený přístup. ID Microsoft Entra pak uděluje přístup pouze k těmto povoleným tenantům – všechny ostatní tenanty jsou blokované, 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 Microsoft Entra ID pro jednotné přihlašování. Pokud používáte aplikace SaaS s jiným tenantem Microsoft Entra od tenanta používaného vaším Microsoftem 365, ujistěte se, že jsou povoleni všichni požadovaná tenanti. (Například ve scénářích spolupráce B2B). Další informace o cloudových aplikacích SaaS najdete na webu Active Directory Marketplace.

Funkce omezení tenanta také podporuje blokování používání všech uživatelských aplikací Microsoftu (aplikací MSA), jako jsou OneDrive, Hotmail a Xbox.com. Tato funkce používá samostatnou hlavičku koncového login.live.com bodu a je podrobně popsána na konci tohoto článku.

Jak to funguje

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

1. ID Microsoft Entra: Pokud je hlavička Restrict-Access-To-Tenants: <permitted tenant list> přítomna, Microsoft Entra-only vydává 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 ID Microsoft Entra.

3. Klientský software: Aby bylo možné podporovat omezení klienta, musí klientský software požadovat tokeny přímo z ID Microsoft Entra, aby infrastruktura proxy serveru mohl zachycovat 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 negenerovaný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 pouze u provozu do Microsoft Entra ID, nikoli do cloudových služeb Microsoftu 365. Toto rozlišení je důležité, protože objem přenosů pro ověřování do Microsoft Entra ID je obvykle mnohem nižší než objem provozu pro aplikace SaaS, jako je Exchange Online a SharePoint Online.

Nastavení omezení tenanta

Začněte s omezeními tenanta dvěma kroky. Nejprve se ujistěte, že se vaši 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 Microsoft Entra, které se mají ověřit:

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

Pokud chcete získat přístup k Office 365, musí se klienti také moct připojit k plně kvalifikovaným názvům domén, 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 infrastruktury proxy serveru se vyžaduje následující konfigurace. Tyto pokyny jsou obecné, proto byste se měli podívat na dokumentaci 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 pomocí protokolu TLS. Pokud se například používají certifikáty z interní infrastruktury veřejných klíčů (PKI), musí být certifikát kořenové certifikační autority interního vydávajícího certifikátu důvěryhodný.

• Licence Microsoft Entra ID P1 nebo P2 se vyžadují pro použití omezení tenanta.

Konfigurace

Pro každý odchozí požadavek vložte login.microsoft.comlogin.windows.netlogin.microsoftonline.comdvě hlavičky HTTP: Restrict-Access-To-Tenants a Restrict-Access-Context.

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žívají ve scénářích registrace zařízení a podmíněného přístupu založeného na zařízeních. Nakonfigurujte proxy server tak, aby vyloučil a vyloučil device.login.microsoftonline.com injektáž enterpriseregistration.windows.net hlaviček protokolu TLS a z protokolu TLS.

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

• Pro omezení přístupu k tenantům použijte hodnotu seznamu povolených <tenantů>, což je čárkami oddělený seznam tenantů, ke kterým chcete uživatelům povolit přístup. Každou doménu zaregistrovanou v tenantovi je možné použít k identifikaci tenanta v tomto seznamu a id samotného 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-kontext použijte hodnotu ID jednoho adresáře deklarující, který tenant nastavuje omezení tenanta. Pokud například chcete deklarovat contoso jako tenanta, který nastavil zásady omezení tenanta, pár název/hodnota vypadá takto: Restrict-Access-Context: 456ff232-35l2-5h23-b3b3-3236w0826f3d. Pokud chcete získat protokoly pro tato ověřování, musíte tady použít vlastní ID adresáře. Pokud používáte jiné ID adresáře, než je vaše vlastní, přihlašovací protokoly *se zobrazí v tenantovi někoho jiného s odebranými všemi osobními údaji. Další informace najdete v Správa prostředí.

Vyhledání ID adresáře:

1. Přihlaste se do Centra pro správu Microsoft Entra jako aspoň globální čtenář.
2. Přejděte do přehledu> identit.>
3. Zkopírujte hodnotu ID tenanta.

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 vkládat vlastní hlavičku HTTP s neschválené tenanty, proxy server musí nahradit hlavičku Restrict-Access-To-Tenants , pokud už je v příchozím požadavku.

Klienti musí být nuceni používat proxy pro všechny požadavky na login.microsoftonline.com, login.microsoft.coma 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 upravovat ani zakázat soubory PAC.

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 snaží se získat přístup k instanci Fabrikam sdílené aplikace SaaS, jako je Outlook Online. Pokud je Fabrikam pro instanci Contoso nepotvrzený tenant, zobrazí se uživateli zpráva o odepření přístupu. Zpráva o odepření říká, že se pokoušíte získat přístup k prostředku, který patří do organizace, kterou neschválí vaše IT oddělení.

Prostředí správce

I když se konfigurace omezení tenanta provádí v infrastruktuře podnikového proxy serveru, můžou správci přistupovat k sestavám omezení tenanta přímo v Centru pro správu Microsoft Entra. Zobrazení sestav:

1. Přihlaste se do Centra pro správu Microsoft Entra jako aspoň globální čtenář.
2. Přejděte na omezení tenanta přehledu>identit>.

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 zahrnutá, pokud je nastavením tenanta omezení tenant 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ě jsou identifikovatelné informace uživatele, jako je jméno a hlavní název uživatele, maskovány za účelem ochrany uživatelských dat v jiných tenantech (například "{PII Removed}@domain.com" or 00000000-0000-0000-0000-000000000000 místo uživatelských jmen a ID objektů podle potřeby).

Stejně jako jiné sestavy v Centru pro správu Microsoft Entra můžete pomocí filtrů určit rozsah sestavy. Můžete filtrovat podle konkrétního časového intervalu, uživatele, aplikace, klienta nebo stavu. Pokud vyberete tlačítko Sloupce , můžete zvolit zobrazení dat s libovolnou kombinací následujících polí:

• Uživatel – toto pole může mít odebrané osobní údaje, kde je jeho hodnota nastavena na 00000000-0000-0000-0000-000000000000.
• Aplikace
• Stav
• Date
• Datum (UTC) – kde UTC je koordinovaný univerzální čas
• IP Address
• Klient
• Uživatelské jméno – toto pole může obsahovat odebrání osobních údajů, kde je jeho hodnota nastavená na {PII Removed}@domain.com
• Místo
• 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, kteří klienti Office aktuálně podporují moderní ověřování, najdete v tématu Aktualizované moderní ověřování Office 365. Tato stránka obsahuje také odkazy na pokyny pro povolení moderního ověřování pro konkrétní tenanty Exchange Online a Skype pro firmy Online. SharePoint Online už ve výchozím nastavení umožňuje moderní ověřování. Teams podporuje jenom moderní ověřování a nepodporuje starší ověřování, takže se tento problém s obejitím nevztahuje na Teams.

Aplikace založené na prohlížeči Microsoftu 365 (například portál Office, Yammer, sharepointové weby a Outlook na webu) 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 Skype pro firmy, kteří podporují moderní ověřování, můžou stále používat starší protokoly pro tenanty, u kterých není povolené moderní ověřování, a efektivně obcházet omezení tenanta. Omezení tenanta můžou blokovat aplikace, které používají starší protokoly, pokud kontaktují login.microsoftonline.com, login.microsoft.comnebo login.windows.net během ověřování.

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álené e-mailové účty do svých profilů. Podívejte se například na nastavení Zásad skupiny zabránit přidávání nedefaultních účtů Exchange.

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

Funkce služby 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ískaly dešifrovací klíče pro šifrované dokumenty. Vzhledem k tomu, že omezení tenanta blokují přístup k jiným tenantům, nejsou šifrované e-maily a dokumenty odesílané 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, zahrnuje vkládání hlaviček HTTP. Pokud chcete fiddleru nakonfigurovat na testování omezení tenanta, proveďte následující kroky:

1. Stáhněte a nainstalujte Fiddler.

2. Nakonfigurujte Fiddler tak, aby dešifroval provoz HTTPS podle dokumentace nápovědy k Fiddleru.

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. Do funkce přidejte následující řádky OnBeforeRequest . 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 Microsoft Entra vašeho tenanta. Aby se protokoly zobrazily 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.

Jakmile fiddler nakonfigurujete, 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é zfázovat zavedení nastavení pro vaše uživatele. Projděte si následující základní možnosti, které je potřeba vzít v úvahu:

1. Soubory PAC slouží k nasměrování testovacích uživatelů na testovací infrastrukturu proxy serveru, zatímco normální uživatelé nadále používají 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í uživatelské účty i účty organizace, jako je OneDrive, můžou být někdy hostované na stejné adrese URL. To znamená, že uživatelé, kteří musí získat přístup k této adrese URL pro pracovní účely, mají k ní také přístup pro osobní použití. Tato možnost nemusí být povolená podle vašich provozních pokynů.

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

1. Blokování login.live.com blokuje používání osobních účtů ve scénářích hosta B2B, které můžou ruš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 uživatelské aplikace

I když 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 se uživatelé nepřihlašovali k aplikacím příjemců. Pokud chcete tento signál odeslat, hlavička sec-Restrict-Tenant-Access-Policy se vloží do provozu, který login.live.com navštíví pomocí stejného podnikového proxy serveru nebo brány firewall, jak je uvedeno v části Konfigurace proxy serveru a požadavky tohoto článku. Hodnota hlavičky musí být restrict-msa. Když je záhlaví k dispozici a aplikace příjemce se pokouší přihlásit uživatele přímo, toto přihlášení se zablokuje.

V tomto okamžiku se ověřování u uživatelských aplikací nezobrazuje v protokolech správců, protože login.live.com je hostované odděleně od Microsoft Entra ID.

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í. Tato možnost zahrnuje provoz pro Autopilot, služba Windows Update a telemetrii 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í v login.live.com, aby mohli přistupovat k tenantovi prostředků.
   1. Tento přístup se řídí pomocí hlavičky Restrict-Access-To-Tenants , která umožňuje nebo odepře přístup k tomuto tenantovi prostředků.
3. Předávací ověřování, které používá mnoho aplikací Azure a Office.com, kde aplikace používají Id Microsoft Entra k přihlašování uživatelů v kontextu příjemce.
   1. Tento přístup se také řídí pomocí hlavičky Restrict-Access-To-Tenants , 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, Microsoft Entra ID blokuje uživatelské účty v přihlášení k těmto aplikacím.

Platformy, které nepodporují přerušení protokolu TLS a kontrolu

Omezení tenanta závisí na injektáži seznamu povolených tenantů v hlavičce HTTPS. Tato závislost vyžaduje kontrolu protokolu TLSI (Transport Layer Security Inspection) k přerušení a kontrole provozu. V prostředích, kde není možné přerušit a kontrolovat provoz, aby se přidaly hlavičky, nefungují omezení tenanta.

Podívejte se na příklad Androidu 7.0 a dále. Android změnil způsob, jakým zpracovává důvěryhodné certifikační autority (CA), aby poskytoval bezpečnější výchozí hodnoty zabezpečeného provozu aplikací. Další informace najdete v tématu Změny důvěryhodných certifikačních autorit v Androidu Nougat.

Podle doporučení od Googlu klientské aplikace Microsoftu ve výchozím nastavení ignorují uživatelské certifikáty. Díky této zásadě tyto aplikace nemůžou pracovat s omezeními tenanta, protože certifikáty používané síťovým proxy serverem jsou nainstalované v úložišti uživatelských certifikátů, kterým klientské aplikace nedůvěřují.

Pro taková prostředí, která nemůžou přerušit a kontrolovat provoz, aby se do hlavičky přidaly parametry omezení tenanta, můžou poskytovat ochranu další funkce Microsoft Entra ID. Následující seznam obsahuje další informace o takových funkcích Microsoft Entra.

• Podmíněný přístup: Povolit pouze používání spravovaných nebo vyhovujících zařízení
• Podmíněný přístup: Správa přístupu pro hosta nebo externí uživatele
• Spolupráce B2B: Omezení odchozích pravidel pro přístup mezi tenanty pro stejné tenanty uvedené v parametru Omezit přístup k tenantům
• Spolupráce B2B: Omezení pozvánek na uživatele B2B na stejné domény uvedené v parametru Restrict-Access-To-Tenants
• Správa aplikací: Omezení souhlasu uživatelů s aplikacemi
• Intune: Použijte zásady aplikací prostřednictvím Intune, abyste omezili používání spravovaných aplikací jenom na hlavní název uživatele (UPN) účtu, který zaregistroval zařízení – Podívejte se do oddílu v části Povolit pouze nakonfigurované účty organizace v podnadpisu aplikací .

Některé konkrétní scénáře ale můžou být pokryty pouze pomocí omezení tenanta.

Další kroky

• Přečtěte si o aktualizovaném moderním ověřování Office 365
• Kontrola adres URL a rozsahů IP adres Office 365