In dit artikel wordt een architectuur voor voorwaardelijke toegang beschreven die voldoet aan zero Trust-principes. De architectuur maakt gebruik van een op persona gebaseerde benadering om een gestructureerd framework voor voorwaardelijke toegang te vormen.
Architectuur van Zero Trust voor voorwaardelijke toegang
U moet eerst een architectuur kiezen. We raden u aan om een Targeted- of Zero Trust-architectuur voor voorwaardelijke toegang te overwegen. In dit diagram ziet u de bijbehorende instellingen:
De architectuur voor voorwaardelijke toegang van Zero Trust is de architectuur die het beste past bij de principes van Zero Trust. Als u de optie Alle cloud-apps in een beleid voor voorwaardelijke toegang selecteert, worden alle eindpunten beveiligd door de opgegeven besturingselementen voor toekenning, zoals bekende gebruiker en bekend of compatibel apparaat. Het beleid is echter niet alleen van toepassing op de eindpunten en apps die voorwaardelijke toegang ondersteunen. Het is van toepassing op elk eindpunt waarmee de gebruiker communiceert.
Een voorbeeld hiervan is een eindpunt voor apparaataanmeldingsstromen dat wordt gebruikt in verschillende nieuwe PowerShell- en Microsoft Graph-hulpprogramma's. De stroom voor apparaataanmelding biedt een manier om aanmelding toe te staan vanaf een apparaat waarop het niet mogelijk is om een aanmeldingsscherm weer te geven, zoals een IoT-apparaat.
Er wordt een aanmeldingsopdracht op basis van een apparaat uitgevoerd op het opgegeven apparaat en er wordt een code weergegeven voor de gebruiker. Deze code wordt op een ander apparaat gebruikt. De gebruiker gaat naar https://aka.ms/devicelogin en geeft de gebruikersnaam en het wachtwoord op. Nadat u zich hebt aangemeld vanaf het andere apparaat, slaagt de aanmelding op het IoT-apparaat in die gebruikerscontext.
De uitdaging bij deze aanmelding is dat deze geen ondersteuning biedt voor voorwaardelijke toegang op basis van apparaten. Dit betekent dat niemand de hulpprogramma's en opdrachten kan gebruiken als u een basislijnbeleid toepast waarvoor bekende gebruiker en bekend apparaat voor alle cloud-apps zijn vereist. Er zijn andere toepassingen met hetzelfde probleem met voorwaardelijke toegang op basis van apparaten.
De andere architectuur, de doelarchitectuur , is gebaseerd op het principe dat u alleen op afzonderlijke apps richt die u wilt beveiligen in beleid voor voorwaardelijke toegang. In dit geval wordt apparaataanmelding voor eindpunten die eerder worden gedekt door alle cloud-apps, zoals graph-aanroepen naar Microsoft Entra-id, niet beveiligd door het beleid voor voorwaardelijke toegang, zodat ze blijven werken.
Wanneer u apparaataanmelding als voorbeeld gebruikt om onderscheid te maken tussen de twee architecturen, kunt u zich verifiëren met apparaataanmelding. Apparaataanmelding kan mogelijk worden toegestaan voor een of enkele afzonderlijke toepassingen, aangezien elke toepassing kan worden gericht en daardoor kan worden uitgesloten in een beleid voor voorwaardelijke toegang waarvoor aanmelding op basis van apparaten is vereist.
De uitdaging met de beoogde architectuur is dat u misschien vergeet al uw cloud-apps te beveiligen. Bovendien kiest u alle selecteerbare toepassingen in het beleid voor voorwaardelijke toegang. U laat de toegang tot de toepassingen die niet kunnen worden geselecteerd, onbeveiligd. Voorbeelden hiervan zijn toegang tot de Office-portal, de Azure EA-portal (Enterprise Overeenkomst) en de beveiligingsinformatieportal, die allemaal zeer gevoelige portals zijn.
Een andere overweging is dat het aantal Office 365- en Microsoft Entra-apps in de loop van de tijd toeneemt, omdat Microsoft en partners nieuwe functies uitbrengen en naarmate uw IT-beheerders verschillende toepassingen integreren met Microsoft Entra ID. Toegang tot al deze toepassingen wordt alleen beveiligd als u een mechanisme hebt waarmee nieuwe apps worden gedetecteerd die voorwaardelijke toegang ondersteunen en waarop automatisch beleid wordt toegepast. Het maken en onderhouden van een dergelijk script kan lastig zijn.
Bovendien is het maximaal ondersteunde aantal apps voor elk beleid voor voorwaardelijke toegang ongeveer 250. Mogelijk kunt u maximaal 600 apps toevoegen voordat u een foutmelding krijgt over het overschrijden van de nettolading, maar dat aantal wordt niet ondersteund.
Persona's voor voorwaardelijke toegang
Er zijn veel manieren om beleidsregels voor voorwaardelijke toegang te structuren. Een benadering is om beleidsregels te structuren op basis van de gevoeligheid van de resource die wordt geopend. In de praktijk kan deze aanpak moeilijk te implementeren zijn op een manier die nog steeds de toegang tot resources voor verschillende gebruikers beveiligt.
U kunt bijvoorbeeld een beleid voor voorwaardelijke toegang definiëren waarvoor een bekende gebruiker en een bekend apparaat zijn vereist voor toegang tot een gevoelige resource die moet worden geopend door zowel gasten als werknemers. Wanneer gasten toegang proberen te krijgen vanaf een beheerd apparaat, werkt de toegangsaanvraag niet. U moet het beleid voor voorwaardelijke toegang aanpassen om aan beide vereisten te voldoen, wat meestal resulteert in een beleid dat voldoet aan de minder veilige vereiste.
Een andere benadering is om toegangsbeleid te definiëren op basis van waar een gebruiker zich in de organisatie bevindt. Deze benadering kan leiden tot veel beleidsregels voor voorwaardelijke toegang en kan onbeheerbaar zijn.
Een betere aanpak is het structureeren van beleid met betrekking tot algemene toegangsbehoeften en het bundelen van een set toegangsbehoeften in een persona voor een groep gebruikers die dezelfde behoeften hebben. Persona's zijn identiteitstypen die algemene ondernemingskenmerken, verantwoordelijkheden, ervaringen, doelstellingen en toegang delen.
Inzicht in hoe bedrijfsactiva en -resources worden geopend door verschillende persona's, is een integraal onderdeel van het ontwikkelen van een uitgebreide Zero Trust-strategie.
Enkele voorgestelde persona's voor voorwaardelijke toegang van Microsoft worden hier weergegeven:
Microsoft raadt ook aan om een afzonderlijke persona te definiëren voor identiteiten die geen deel uitmaken van een andere personagroep. Dit wordt de globale persona genoemd. Globaal is bedoeld om beleidsregels af te dwingen voor identiteiten die zich niet in een personagroep en -beleid bevinden die voor alle persona's moeten worden afgedwongen.
In de volgende secties worden enkele aanbevolen persona's beschreven.
Globale
Global is een persona/tijdelijke aanduiding voor beleidsregels die algemeen van aard zijn. Het wordt gebruikt om beleidsregels te definiëren die van toepassing zijn op alle persona's of die niet van toepassing zijn op één specifieke persona. Gebruik dit voor beleidsregels die niet worden gedekt door andere persona's. U hebt deze persona nodig om alle relevante scenario's te beveiligen.
Stel dat u één beleid wilt gebruiken om verouderde verificatie voor alle gebruikers te blokkeren. U kunt het een globaal beleid maken in plaats van een groep verouderde beleidsregels te gebruiken die voor verschillende persona's kunnen verschillen.
Een ander voorbeeld: u wilt een bepaald account of een bepaalde gebruiker blokkeren vanuit specifieke toepassingen en de gebruiker of het account maakt geen deel uit van een van de persona's. Als u bijvoorbeeld een cloudidentiteit maakt in de Microsoft Entra-tenant, maakt deze identiteit geen deel uit van een van de andere persona's omdat er geen Microsoft Entra-rollen aan zijn toegewezen. Mogelijk wilt u de identiteit nog steeds blokkeren voor toegang tot Office 365-services.
Mogelijk wilt u alle toegang blokkeren van identiteiten die niet worden gedekt door een personagroep. Of misschien wilt u meervoudige verificatie afdwingen.
Beheer s
In deze context is een beheerder een niet-gastidentiteit, cloud of gesynchroniseerd, met een Microsoft Entra-id of een andere Microsoft 365-beheerdersrol (bijvoorbeeld in Microsoft Defender voor Cloud Apps, Exchange, Defender voor Eindpunt of Compliancebeheer). Omdat gasten met deze rollen in een andere persona worden behandeld, worden gasten uitgesloten van deze persona.
Sommige bedrijven hebben afzonderlijke accounts voor de gevoelige beheerdersrollen waarop deze persona is gebaseerd. Beheerders gebruiken deze gevoelige accounts optimaal vanuit een Paw (Privileged Access Workstation). Maar we zien vaak dat beheerdersaccounts worden gebruikt op standaardwerkstations, waarbij de gebruiker gewoon schakelt tussen accounts op één apparaat.
U kunt onderscheid maken op basis van de gevoeligheid van cloudbeheerdersrollen en minder gevoelige Azure-rollen toewijzen aan de persona Internals in plaats van afzonderlijke accounts te gebruiken. Vervolgens kunt u JIT-uitbreiding (Just-In-Time) gebruiken. In dit geval is een gebruiker gericht op twee sets beleidsregels voor voorwaardelijke toegang, één voor elke persona. Als u PAW's gebruikt, wilt u mogelijk ook beleidsregels introduceren die gebruikmaken van apparaatfilters in voorwaardelijke toegang om de toegang te beperken, zodat beheerders alleen op PAW's zijn toegestaan.
Ontwikkelaars
De persona ontwikkelaars bevat gebruikers met unieke behoeften. Ze zijn gebaseerd op Active Directory-accounts die zijn gesynchroniseerd met Microsoft Entra ID, maar ze hebben speciale toegang nodig tot services zoals Azure DevOps, CI/CD-pijplijnen, apparaatcodestroom en GitHub. De persona van de ontwikkelaars kan gebruikers bevatten die als intern en door anderen als extern worden beschouwd, maar een persoon mag zich slechts in één van de persona's bevinden.
Internals
Interne instellingen bevatten alle gebruikers die een Active Directory-account hebben gesynchroniseerd met Microsoft Entra ID, die werknemers van het bedrijf zijn en die in een standaardrol voor eindgebruikers werken. Het is raadzaam interne gebruikers toe te voegen die ontwikkelaars zijn aan de persona ontwikkelaars.
Externen
Deze persona bevat alle externe consultants die een Active Directory-account hebben gesynchroniseerd met Microsoft Entra-id. Het is raadzaam externe gebruikers toe te voegen die ontwikkelaars zijn aan de persona ontwikkelaars.
Gasten
Gasten hebben alle gebruikers met een Microsoft Entra-gastaccount dat is uitgenodigd voor de tenant van de klant.
Gast Beheer s
De gast Beheer s persona bevat alle gebruikers met een Microsoft Entra-gastaccount waaraan een van de eerder genoemde beheerdersrollen is toegewezen.
Microsoft365ServiceAccounts
Deze persona bevat cloudserviceaccounts (Microsoft Entra ID) die worden gebruikt voor toegang tot Microsoft 365-services wanneer geen andere oplossing voldoet aan de behoefte, zoals het gebruik van een beheerde service-identiteit.
AzureServiceAccounts
Deze persona bevat cloudserviceaccounts (Microsoft Entra ID) die worden gebruikt voor toegang tot Azure-services (IaaS/PaaS) wanneer er geen andere oplossing aan de behoefte voldoet, zoals het gebruik van een beheerde service-identiteit.
CorpServiceAccounts
Deze persona bevat serviceaccounts op basis van gebruikers die al deze kenmerken hebben:
- Afkomstig van on-premises Active Directory.
- Worden gebruikt vanuit on-premises of vanuit een op IaaS gebaseerde virtuele machine in een ander (cloud) datacenter, zoals Azure.
- Worden gesynchroniseerd met een Microsoft Entra-exemplaar dat toegang heeft tot een Azure- of Microsoft 365-service.
Dit scenario moet worden vermeden.
WorkloadId-entiteiten
Deze persona bevat machine-id's, zoals Service-principals van Microsoft Entra en beheerde identiteiten. Voorwaardelijke toegang biedt nu ondersteuning voor het beveiligen van toegang tot resources van deze accounts, met enkele beperkingen met betrekking tot welke voorwaarden en toekenningsbeheer beschikbaar zijn.
Toegang tot sjabloonkaarten
U wordt aangeraden toegangssjabloonkaarten te gebruiken om de kenmerken voor elke persona te definiëren. Hier volgt een voorbeeld:
De sjabloonkaart voor elke persona biedt invoer voor het maken van het specifieke beleid voor voorwaardelijke toegang voor elke persona.
Richtlijnen voor voorwaardelijke toegang
Bekijk een framework voor voorwaardelijke toegang met een gestructureerde benadering voor het groeperen van beleidsregels op basis van de gemaakte persona's.
Bijdragers
Dit artikel wordt onderhouden door Microsoft. De tekst is oorspronkelijk geschreven door de volgende Inzenders.
Hoofdauteur:
- Claus Jespersen | Principal Consultant ID&Sec
Als u niet-openbare LinkedIn-profielen wilt zien, meldt u zich aan bij LinkedIn.
Volgende stappen
- Leertraject: Identiteit en toegang implementeren en beheren
- Wat is voorwaardelijke toegang?
- Algemeen beleid voor voorwaardelijke toegang