Delen via


Zero trust-configuratie voor multitenant defense-organisaties

In dit artikel worden multitenant-organisaties beschreven hoe u configuraties toepast in Microsoft Entra ID en voldoet aan algemene vereisten voor zero trust voor defensie. Volg deze aanbevelingen om de juiste multitenant-identiteitsarchitectuur in te stellen en nul vertrouwen in uw omgeving te implementeren.

Diagram met een voorbeeldarchitectuur met meerdere tenants met zero trust-configuraties. Er worden een primaire tenant en twee secundaire tenants weergegeven.Afbeelding 1: Voorbeeld van multitenant-verdedigingsarchitectuur met zero trust-configuraties.

Identiteitsarchitectuur bepalen

Microsoft Entra-tenants vormen de basis van uw identiteitsarchitectuur. Een tenant is een identiteitsgrens in Microsoft Entra-id. Een organisatie met één Microsoft Entra-tenant heeft één tenantarchitectuur. Organisaties die meer dan één Microsoft Entra-tenant gebruiken, hebben een architectuur met meerdere tenants.

Voordelen van één tenant. Eén tenant is eenvoudiger om de kosten te beheren en te verlagen via operationele efficiëntie. Hiermee kunt u een omgeving met nul vertrouwensrelaties eenvoudiger configureren. Eén tenant voorkomt dat de gebruikerservaring wordt gefragmenteerd met meerdere aanmeldingsreferenties. Het helpt ook om silooplossingen te voorkomen die u later moet integreren. U moet ernaar streven om uw gegevens, Microsoft 365 en Azure-cloudservices in één tenant te hebben. Als u al meerdere Microsoft Entra-tenants hebt, kunt u overwegen uw omgeving samen te voegen om één tenant te gebruiken. U kunt tenants consolideren door Azure-abonnementen van uw secundaire tenants over te dragen naar de primaire tenant. Zie Een Azure-abonnement overdragen naar een andere Microsoft Entra-directory voor meer informatie.

Gebruiksvoorbeelden voor meerdere tenants. Er zijn redenen voor een defensieorganisatie om een multitenant-architectuur te gebruiken. Grote en complexe defensieorganisaties hebben mogelijk meerdere Microsoft Entra-tenants nodig voor beveiliging, naleving en samenwerking (zie tabel 1).

Tabel 1. Redenen om meerdere tenants te hebben of te maken.

Reden Opmerking
Privacy of beveiliging vereist een diepere scheiding van gegevens Een bureau van inspecteur-generaal moet onafhankelijkheid hebben.
Delegering en segmentatie van het beheer De ene organisatie heeft niet de mogelijkheid om een andere organisatie te beheren.
Gegevenssoevereine en/of eigendom De ene organisatie heeft niet de wettelijke bevoegdheid om gegevens van een andere organisatie te beheren.
Netwerk- en IT-organisatie Het is niet mogelijk of gunstig om meerdere GROTE ZAKELIJKE IT-architecturen samen te vouwen in één bedrijfsarchitectuur.
SOC-bewaking en incidentrespons SOC heeft een afzonderlijke tenant nodig om hun rollen en verantwoordelijkheden te beheren.

Als u meerdere Microsoft Entra-tenants nodig hebt, moet u Microsoft Entra Externe ID (B2B) en Azure Lighthouse gebruiken. Deze functies helpen multitenant-verdedigingsomgevingen te ondersteunen. Zie Tenancy-modellen voor een multitenant-oplossing voor meer informatie.

Tenanttypen identificeren

Organisaties met meerdere tenants kunnen Microsoft Entra-exemplaren categoriseren die ze gebruiken als primaire of secundaire instantie. Elke organisatie moet één tenant identificeren en aanwijzen als de primaire tenant. Alle andere tenants zijn secundair. Afbeelding 1 toont een verdedigingsorganisatie met een primaire tenant en n secundaire tenants (twee secundaire tenants weergegeven).

Identificeer de primaire tenant. De meeste defensieorganisaties maken de primaire tenant wanneer ze zich registreren voor Microsoft 365. De primaire tenant bevat (1) alle gebruikersidentiteiten en Microsoft 365-licenties, (2) apparaten en (3) toepassingen (zie afbeelding 1). Defensieorganisaties gebruiken vaak Microsoft Entra Connect om de identiteiten van on-premises Active Directory te synchroniseren met de primaire Microsoft Entra-tenant.

Sommige defensieorganisaties gebruiken Microsoft 365 in een gedeelde tenant die eigendom is van en wordt beheerd door een externe instantie. Dit agentschap fungeert als een gedeelde serviceprovider voor Microsoft 365. Uw organisatie beheert of beheert de gedeelde tenant mogelijk niet, maar bevat de gelicentieerde Microsoft Entra-identiteiten die uw gebruikers waarschijnlijk gebruiken voor Office 365 en andere toepassingen. In dit scenario is de tenant van de gedeelde serviceprovider uw primaire tenant.

Identificeer alle secundaire tenants (indien multitenant). Alle andere tenants die door de organisatie worden beheerd, zijn secundaire tenants. Mogelijk hebt u secundaire tenants als u toepassingen naar de cloud hebt gemigreerd voordat u een Azure-landingszone op ondernemingsniveau instelt. Doorgaans gebruikt u secundaire tenants voor het beheren van (4) Azure-workloads met externe gebruikers (B2B-gasten) of (5) cloudaccounts (zie afbeelding 1).

Gebruik de beslissingsstructuur. De eenvoudigste manier om uw primaire tenant te vinden, is door rekening te houden met de identiteitslicenties die u hebt in Microsoft Entra-id.

De tenant met uw Microsoft 365-licenties is uw primaire tenant (zie afbeelding 2). De primaire tenant is mogelijk niet de eerste tenant die door uw organisatie is gemaakt, maar moet de hoofdtenant zijn met al uw gebruikers en Microsoft 365-licenties.

Als uw organisatie geen gebruik maakt van Microsoft 365, is een Microsoft Entra-tenant met EMS-licenties (Enterprise Mobility and Security) uw primaire tenant. Deze tenant is waar u de domeinnaam van uw organisatie hebt toegevoegd en geverifieerd. De tenant maakt vaak gebruik van een hybride identiteit of integreert met een HR-systeem (Human Resources) (zie afbeelding 2).

Diagram met een beslissingsstructuur om te bepalen of een Microsoft Entra-tenant primair of secundair is. Als het een Microsoft 365-tenant is, is dit de primaire tenant. Als de tenant een hybride identiteit heeft geconfigureerd en enterprise mobility- en beveiligingslicenties heeft, is dit een primaire tenant. Alle andere tenants zijn secundair.
Figuur 2. Een beslissingsstructuur om de primaire tenant en secundaire tenant van Microsoft Entra te bepalen.

Als u Microsoft Entra ID wilt instellen als een zero trust-platform, hebt u een tenant nodig die is gevuld met uw gebruikersidentiteiten en een licentie voor toegangsbeleid op basis van gebruikers en apparaten. Microsoft 365-licenties bundelen deze mogelijkheden voor vertrouwensrelaties met Office 365. Als u Microsoft 365 niet gebruikt, kunt u Enterprise Mobility + Security E5 overwegen om een identiteitsprovider in de cloud tot stand te brengen voor nul vertrouwen. Zie Uw identiteitsinstantie kiezen voor meer informatie.

Nul vertrouwensrelatie configureren

Bij het beheren van identiteiten in Microsoft Entra ID moet u rekening houden met de volgende aanbevelingen voor elk tenanttype. Er zijn algemene aanbevelingen voor alle tenanttypen die u eerst moet gebruiken. Nadat u deze algemene aanbevelingen hebt geïmplementeerd, zoekt u de aanbevelingen voor uw specifieke tenanttype (primair of secundair) en past u deze aanbevelingen toe.

Zie Zero Trust Rapid Modernization Plan en Security Rapid Modernization Plan voor snelle modernisering voor meer informatie over het beveiligen van Microsoft Entra-tenants met zero trust.

Alle tenants

U moet de volgende aanbevelingen implementeren in alle Microsoft Entra-tenants.

Accounts en procedures voor toegang tot noodgevallen instellen. Maak twee of meer accounts voor toegang tot noodgevallen om te voorkomen dat uw Microsoft Entra-tenant wordt vergrendeld. U moet de rol globale beheerder toewijzen aan deze accounts. De accounts moeten alleen cloudaccounts zijn. Cloudaccounts maken gebruik van het domein *.onmicrosoft.com . Zie Beheerdersaccounts voor noodtoegang beheren voor meer informatie.

Belangrijk

Microsoft raadt u aan rollen te gebruiken met de minste machtigingen. Dit helpt de beveiliging voor uw organisatie te verbeteren. Globale beheerder is een zeer bevoorrechte rol die moet worden beperkt tot scenario's voor noodgevallen wanneer u geen bestaande rol kunt gebruiken.

Beveilig Microsoft Entra-id tegen on-premises aanvallen. Volg de aanbevolen procedures die worden beschreven in Het beveiligen van bevoegde toegang. Wijs alleen Microsoft Entra-machtigingen toe aan cloudgebruikersaccounts met phishingbestendige referenties, zoals hardwarewachtwoordsleutel of verificatie op basis van certificaten. Gebruik geen federatieve identiteiten voor administratieve doeleinden. Zie Microsoft 365 beschermen tegen on-premises aanvallen voor meer informatie.

Gebruik Privileged Identity Management. Gebruik Microsoft Entra Privileged Identity Management (PIM) om roltoewijzingen voor Microsoft Entra ID en Azure-rollen te beheren. U moet PIM ook gebruiken om in aanmerking komend groepslidmaatschap te beheren voor bevoegde beveiligingsgroepen. Stel periodieke toegangsbeoordelingen in voor in aanmerking komende beheerders en externe gebruikers (B2B-gasten).

Schakel cloudverificatie in voor alle gebruikers. Cloudgebaseerde verificatiemethoden zijn veiliger dan federatieve verificatie. Ze bieden een betere ervaring voor eenmalige aanmelding in combinatie met aan Microsoft Entra gekoppelde apparaten. Federatieve verificatie maakt Microsoft Entra-id beschikbaar voor on-premises Active Directory-inbreuk.

Verificatie op basis van Microsoft Entra-certificaten (CBA) maakt het onnodig om Microsoft Entra-domeinen te federeren. Microsoft Entra-verificatie ondersteunt de volgende verificatiemethoden zonder wachtwoord:

  • Wachtwoordsleutels (FIDO2-beveiligingssleutels)
  • Verificatie op basis van certificaten
  • Microsoft Authenticator
  • Windows Hello voor Bedrijven

Basislijnbeleid voor voorwaardelijke toegang tot stand brengen. De basislijn voor voorwaardelijke toegang verschilt per organisatie en vereisten. Stel een kernset met beleidsregels voor voorwaardelijke toegang in voor alle Microsoft Entra-tenants. Gebruik identiteits-, apparaat-, toepassings- en risicovoorwaarden binnen uw beleidsset. Sluit accounts voor toegang tot noodgevallen uit van uw beleid voor voorwaardelijke toegang.

Microsoft Entra ID Protection helpt organisaties bij het detecteren, onderzoeken en oplossen van identiteitsrisico's. Als u riskante aanmeldingen en gebruikers wilt beschermen, maakt u beleid voor voorwaardelijke toegang met risicovoorwaarden. Gebruik afzonderlijke beleidsregels voor riskante gebruikers en riskante aanmeldingen. Verhoog toegepaste controles met risiconiveau voor elk risicotype. Als u de productiviteit van gebruikers met beveiliging wilt verdelen, vermijdt u het gebruik van het blokbeheer in beleid op basis van risico's.

Notitie

Gebruikers kunnen zelf aanmeldingsrisico's oplossen met MFA. Als u wilt toestaan dat gebruikers zelf aanmeldingsrisico's herstellen, configureert u MFA of Verificatiesterktebeheer in een beleid voor voorwaardelijke toegang op basis van aanmeldingsrisico's.

Gebruikers kunnen zelf risico's van gebruikers oplossen door hun wachtwoorden te wijzigen. Als u gebruikers wilt toestaan om zelf gebruikersrisico's op te lossen, configureert u een beleid op basis van gebruikersrisico's met Het verlenen van wachtwoordwijziging vereisen.

Let op

Gebruikers zonder wachtwoord die zich alleen aanmelden met methoden zonder wachtwoord, zoals verificatie op basis van certificaten, wachtwoordsleutels of Windows Hello voor Bedrijven, kunnen worden geblokkeerd door het besturingselement Wachtwoordwijziging vereisen als ze hun wachtwoord niet opnieuw kunnen instellen in Microsoft Entra-id.

Ontwerp beleid voor voorwaardelijke toegang voor uw organisatie met behulp van de controlelijst voor beleid voor voorwaardelijke toegang (zie tabel 2). Gebruik de modus Alleen-rapporten om beleid voor voorwaardelijke toegang te testen voordat u implementeert in productie.

Tabel 2: Voorbeeld van controlelijst voor beleid voor voorwaardelijke toegang.

Beleidsnaam Gebruikers Toepassingen Voorwaarden Besturingselement verlenen
MFA voor alle gebruikers Alle gebruikers Alle apps Geen - Phishingbestendige MFA
Beheerd apparaat vereisen Alle gebruikers Alle apps Geen - Vereisen dat microsoft Entra hybride gekoppeld of compatibel apparaat is
Aanmeldingen met gemiddeld risico beveiligen Alle gebruikers Alle apps Gemiddeld aanmeldingsrisico - Phishingbestendige MFA
- Compatibel apparaat vereisen
- Aanmeldingsfrequentie: 1 uur (aanpassen op basis van de risicotolerantie van uw organisatie)
Aanmeldingen met een hoog risico beveiligen Alle gebruikers Alle apps Hoog aanmeldingsrisico - Phishingbestendige MFA
- Compatibel apparaat vereisen
- Aanmeldingsfrequentie: elke keer
Gebruikers met een hoog risico beschermen Alle gebruikers Alle apps Hoog gebruikersrisico - Phishingbestendige MFA
- Compatibel apparaat vereisen
- Aanmeldingsfrequentie: elke keer
Microsoft Entra-beheer beveiligen Microsoft Entra-rollen Alle apps Geen - Phishingbestendige MFA
- Nalevings-PAW (Privileged Access Workstation ) vereisen met behulp van apparaatfilters
Cloudbeheer beveiligen Alle gebruikers Azure-beheer
Google Cloud Platform
Amazon Web Services
Geen - Phishingbestendige MFA
- Nalevings-PAW (Privileged Access Workstation ) vereisen met behulp van apparaatfilters

Het voorbeeldbeleid dat is ingesteld in tabel 2 , is bedoeld voor organisaties zonder wachtwoord, waarbij alle gebruikers alleen phishingbestendig MFA van beheerde apparaten gebruiken. Bevoegde gebruikers maken gebruik van door Intune beheerde Privileged Access Workstations (PAW). In plaats van een wachtwoordwijziging te vereisen voor gebruikers met een hoog risico, dwingt het riskante gebruikersbeleid verificatiesterkte en aanmeldingsfrequentiebesturingselementen af. Deze besturingselementen bieden enkele beveiligingen, maar herstellen het risiconiveau van de gebruiker niet in Microsoft Entra ID Protection. Uw beveiligingsteam moet gebruikers met een hoog risico onderzoeken en herstellen .

Zie Een implementatie van voorwaardelijke toegang plannen voor meer informatie over de implementatie van voorwaardelijke toegang.

Gebruik primaire tenant-identiteiten voor toegang tot alle toepassingen. Gebruikers moeten toegang hebben tot toepassingen met hun identiteit in de primaire tenant. U moet toepassingen registreren in de primaire tenant. Stel een beleid in voor het registreren van toepassingen bij de primaire tenant, ongeacht de hostinglocatie van de toepassingsinfrastructuur.

Gebruik de Microsoft Entra-toepassingsproxyservice in de primaire tenant voor verouderde toepassingen die geen ondersteuning bieden voor moderne verificatieprotocollen. Microsoft Entra-toepassingsproxy brengt Microsoft Entra zero trust-functies naar bestaande verouderde toepassingen zonder codewijzigingen.

Wanneer een gedeelde serviceprovider of een extern bureau uw primaire tenant beheert, moeten ze registratiemachtigingen voor toepassingen delegeren. Als de serviceprovider deze overdracht niet aanbiedt, moet u in plaats daarvan toepassingen registreren bij de secundaire tenant die door uw organisatie wordt beheerd. Gebruikers moeten echter nog steeds toegang krijgen tot deze toepassingen zonder een nieuwe identiteit te maken in de secundaire tenant. Wijs voor deze instelling gebruikerstoegang toe met behulp van externe identiteiten (B2B-gasten) voor uw gebruikers in de primaire tenant. Zie Secure applications with zero trust (Beveiligde toepassingen met nul vertrouwen) voor meer informatie.

Gebruik Microsoft Entra ID om andere cloudomgevingen te beheren. Microsoft Entra ID is niet alleen een identiteitsplatform voor Azure en Microsoft 365. Gebruik Microsoft Entra ID om toegang te krijgen tot andere cloudomgevingen. Deze omgevingen omvatten populaire SaaS-producten (software-as-a-service) en cloudplatforms zoals Amazon Web Services (AWS) en Google Cloud Platform (GCP). Zie de galerie met Microsoft Entra-toepassingen voor meer informatie.

Gebruik een beveiligde cloudcomputingarchitectuur (SCCA). Elke defensieorganisatie moet een architectuur voor de landingszone implementeren die compatibel is met SCCA. De landingszone moet zich in Azure-abonnementen bevinden die zijn gekoppeld aan de primaire tenant.

Segmenteer Azure-resourcebeheer in één tenant. U moet Azure-rollen gebruiken voor resource- en beheerisolatie voor abonnementen binnen een Azure-landingszone op ondernemingsniveau. Overweeg abonnementen over te dragen van secundaire tenants naar de primaire tenant.

Gebruik Microsoft Entra-machtigingsbeheer. Microsoft Entra-machtigingsbeheer is de CIEM-oplossing (Cloud Infrastructure Entitlement Management) van Microsoft. U moet Microsoft Entra-machtigingsbeheer gebruiken om inzicht te krijgen in machtigingen die zijn toegewezen aan alle identiteiten. U moet deze ook gebruiken om machtigingen bij te houden die zich in de omgeving met meerdere clouds van uw organisatie bevinden.

Gebruik Microsoft Entra ID-governance. Gebruik Microsoft Entra ID-governance om de levenscyclus van toegangstoewijzingen voor gebruikers en gasten te automatiseren. Voer toegangsbeoordelingen uit om de toegang tot uw cloudomgeving te verwijderen voor gebruikers die deze niet meer nodig hebben.

Identiteiten van werkbelastingen beveiligen. Gebruik Microsoft Entra Workload-ID functies om adaptief nul-vertrouwensbeleid te beheren en toe te passen voor toepassingsidentiteiten (service-principals) in Microsoft Entra-id.

Schakel Defender voor Cloud in voor uw onderneming. Gebruik Defender voor Cloud voor uw omgeving met meerdere clouds. Zorg ervoor dat u de verbeterde beveiligingsfuncties inschakelt om Azure-resources te bewaken en configuratierisico's op te lossen. Defender voor Cloud beveiliging gaat verder dan Azure om u te helpen hybride en multicloudomgevingen te beveiligen.

Implementeer Sentinel en verbind alle beschikbare gegevensbronnen. Aggregaties van beveiligingssignalen in een SIEM zoals Microsoft Sentinel. Implementeer Sentinel en verbind alle gegevensbronnen voor beveiligingssignalen door gegevensconnectors te configureren.

Primaire tenants

Implementeer alleen de volgende aanbevelingen in de primaire tenant.

Eindgebruikers hebben slechts één identiteit in Entra-id. Synchroniseer on-premises Active Directory-domein Services met de primaire Microsoft Entra-tenant. De synchronisatie vult Microsoft Entra-id in met gebruikers, groepen en apparaten voor de organisatie. Externe B2B-gasten kunnen bestaan in secundaire tenants, maar gebruikers hoeven slechts één gebruikersnaam te onthouden voor alle toepassingen en services. De gebruikerservaring en resultaten van nul vertrouwen zijn het beste wanneer u de identiteiten in de primaire tenant gebruikt voor aanmelding bij Windows en toegang tot toepassingen.

Apparaten koppelen en beheren met de primaire tenant. De primaire Microsoft Entra-tenant bevat alle gebruikers en apparaten binnen de organisatie. Windows-apparaten met Microsoft Entra join (of Hybride deelname van Microsoft Entra) aan de primaire tenant en beheren met Microsoft Intune. Gebruik Intune-beleid om Microsoft Defender voor Eindpunt de mogelijkheid voor uitgebreide detectie en respons (XDR) in te schakelen.

Machtigingen voor toepassingsregistratie delegeren. Enterprise-apps, inclusief toepassingscode die wordt uitgevoerd in een Azure-abonnement, gebruiken de primaire Microsoft Entra ID-tenant voor gebruikersidentiteit. Zorg ervoor dat ontwikkelaars in aanmerking komen voor de Microsoft Entra-rol van toepassingsontwikkelaar of een aangepaste app-registratierol met Behulp van Privileged Identity Management. Met deze configuratie kunnen ontwikkelaars toepassingen in secundaire tenants bouwen om ze te registreren bij de primaire tenant voor identiteit.

Koppel PaaS-services (Platform-as-a-Service) die de identiteit van eindgebruikers nodig hebben. Sommige PaaS-services, zoals Azure Files en Azure Virtual Desktop, zijn afhankelijk van de configuratie van hybride identiteit of licentierechten. U moet deze services implementeren in Azure-abonnementen in de primaire tenant.

Secundaire tenants

Implementeer de volgende aanbevelingen in de secundaire tenant.

Licenties aanschaffen die vereist zijn voor Microsoft Entra-beheer. U hebt licenties nodig om geavanceerde beveiligingsfuncties in te schakelen in secundaire tenants. Houd rekening met de licenties die u nodig hebt voor gebruikers, workloads en apparaten.

Gebruikersidentiteiten. U moet Beschikken over Microsoft Entra ID Premium P2-licenties voor tenantbeheerders en accounts voor toegang tot noodgevallen. Als u een beheermodel voor externe identiteit (B2B-gast) gebruikt, moet u ten minste één Microsoft Entra ID Premium P2-licentie toewijzen aan een lokale gebruiker in de tenant. Met deze instelling kunt u premium-functies inschakelen, zoals voorwaardelijke toegang en identiteitsbeveiliging. Zie Algemene overwegingen voor multitenant gebruikersbeheer voor meer informatie.

Workloadidentiteiten. Gebruik workloadidentiteiten premium om workloadidentiteiten te beveiligen met toegang tot resources in de primaire tenant, zoals MS Graph API.

Apparaatbeheer. Mogelijk moet u apparaten beheren met Microsoft Intune in de secundaire tenant. Zo ja, dan moet u Enterprise Mobility and Security-licenties (EMS) aanschaffen.

Beleid voor toegang tussen tenants (XTAP) configureren. Microsoft Entra Externe ID (Microsoft Entra B2B-samenwerking) staat een secundaire tenant toegangsinstellingen toe om bepaalde claims van de primaire tenant thuis te vertrouwen. Voeg de primaire Microsoft Entra-tenant toe als een organisatie en werk de instellingen voor binnenkomende vertrouwensrelaties bij om het volgende op te nemen:

  • Meervoudige verificatie (MFA) vertrouwen van Microsoft Entra-tenants
  • Compatibele apparaten vertrouwen
  • Hybride gekoppelde Microsoft Entra-apparaten vertrouwen
  • Optioneel: Uitnodigingen automatisch inwisselen met de tenant

Beheer de secundaire tenant met identiteiten van de primaire tenant. Verminder administratieve overhead en kosten met behulp van externe gebruikers (B2B-gasten) van de primaire tenant om de secundaire tenant en Azure-resources te beheren. Wijs Microsoft Entra-rollen toe aan de hand van de rol Microsoft Entra entra Privileged Identity Management. Gebruik door de eindgebruiker geïnitieerde toegang of synchronisatie tussen tenants om de onboarding van externe identiteiten in de secundaire tenant te verminderen.

Gebruik Azure Lighthouse om Sentinel-toegang vanuit de primaire tenant te vergemakkelijken. Azure Lighthouse biedt u een andere manier om Azure te beheren tussen tenants. Azure Lighthouse maakt gebruik van ARM-sjablonen (Azure Resource Manager) om Azure-rollen toe te wijzen aan identiteiten in een externe tenant. Deze benadering maakt geen gebruik van B2B-gastgebruikersobjecten. Wanneer een beheerder zich aanmeldt bij de portal om Azure te beheren, zien ze alle resources in alle tenants. Deze geconsolideerde weergave bevat abonnementen met machtigingen die zijn toegewezen door Azure Lighthouse. Omdat er geen B2B-gastobject is, hoeft de beheerder niet van directory te wisselen. Gebruik Azure Lighthouse om het beheer van Microsoft Sentinel tussen tenants te vergemakkelijken.

Volgende stap