Framework en beleid voor voorwaardelijke toegang
Dit artikel biedt een framework voor het implementeren van een op persona gebaseerde architectuur voor voorwaardelijke toegang, zoals beschreven in de Zero Trust-architectuur voor voorwaardelijke toegang . In dit artikel vindt u meer informatie over het formulier en de naam van het beleid voor voorwaardelijke toegang. Er is ook een startpunt voor het maken van beleid.
Als u geen framework zoals hier gebruikt, inclusief een naamgevingsstandaard, worden beleidsregels meestal in de loop van de tijd gemaakt door verschillende personen op een ad-hoc manier. Dit kan leiden tot beleidsregels die elkaar overlappen. Als de persoon die een beleid heeft gemaakt niet meer beschikbaar is, kan het lastig zijn voor anderen om het doel van het beleid te kennen.
Door een gestructureerd framework te volgen, is het eenvoudiger om inzicht te krijgen in het beleid. Het maakt het ook eenvoudiger om alle scenario's te behandelen en conflicterende beleidsregels te voorkomen die moeilijk kunnen worden opgelost.
Naamgevingsconventies
Een correct gedefinieerde naamconventie helpt u en uw collega's inzicht te krijgen in het doel van een beleid, waardoor u eenvoudiger beleidsbeheer en probleemoplossing kunt uitvoeren. Uw naamconventie moet passen bij het framework dat u gebruikt om uw beleid te structureren.
Het aanbevolen naamgevingsbeleid is gebaseerd op persona's, beleidstypen en apps. Dit ziet er als volgt uit:
<CANumber>-<Persona>-<PolicyType>-<App>-<Platform>-<GrantControl>-<OptionalDescription>
De onderdelen van deze naam worden hier beschreven:
| Naamgevingsonderdeel | Beschrijving/voorbeeld |
|---|---|
| CA-nummer | Wordt gebruikt om het bereik en de volgorde van het beleidstype snel te identificeren. Voorbeeld: CA001-CA099. |
| Persona | Globaal, Beheerders, Interne gebruikers, Externe gebruikers, Gastgebruikers, Gastbeheerders, Microsoft365ServiceAccounts, AzureServiceAccounts, CorpServiceAccounts. |
| Beleidstype | Basisschutz, App-bescherming, Gegevensbescherming, Identiteitsbescherming, Aanvalsoppervlaktereductie, Naleving. |
| App | AllApps, O365 (voor alle Office 365-services), EXO (voor Exchange Online). |
| Perron | AnyPlatform, Onbekend, WindowsPhone, macOS, iOS, Android. |
| Bedieningstoegang verlenen | Blokkeren, ADHJ, Conform, Onbeheerd (waarbij onbeheerd is opgegeven in de status van het apparaat). |
| Beschrijving | Optionele beschrijving van het doel van het beleid. |
Nummeringsschema
Om het beheer eenvoudig te maken, raden we dit nummeringsschema aan:
| Persona-groep | Nummertoewijzing |
|---|---|
| CA-Persona-Global | CA001-CA099 |
| CA-Persona-Admins | CA100-CA199 |
| CA-Persona-Internals | CA200-CA299 |
| CA-Persona-Externals | CA300-CA399 |
| CA-Persona-GuestUsers | CA400-CA499 |
| CA-Persona-GuestAdmins | CA500-CA599 |
| CA-Persona-M365ServiceAccounts | CA600-CA699 |
| CA-Persona-AzureServiceAccounts | CA700-CA799 |
| CA-Persona-CorpServiceAccounts | CA800-CA899 |
| CA-Persona-WorkloadIdentities | CA900-CA999 |
| CA-Persona-Developers | CA1000-CA1099 |
Beleidstypen
Dit zijn de aanbevolen beleidstypen:
| Beleidstype | Beschrijving/voorbeelden |
|---|---|
| BaseProtection | Voor elke persona is er een basisbeveiliging die wordt gedekt door dit beleidstype. Voor gebruikers op beheerde apparaten is dit doorgaans een bekende gebruiker en een bekend apparaat. Voor externe gasten is het mogelijk bekende gebruikers- en meervoudige verificatie. De basisbeveiliging is het standaardbeleid voor alle apps voor gebruikers in de opgegeven persona. Als een specifieke app een ander beleid moet hebben, sluit u die app uit van het basisbeveiligingsbeleid en voegt u een expliciet beleid toe dat alleen op die app is gericht. Voorbeeld: Stel dat de basisbescherming voor interne systemen vereist dat bekende gebruikers en apparaten worden gebruikt voor alle cloud-apps, maar dat u Outlook op het web vanaf elk apparaat wilt toestaan. U kunt Exchange Online uitsluiten van het basisbeveiligingsbeleid en een afzonderlijk beleid voor Exchange Online toevoegen, waarbij u bekend apparaat OF meervoudige verificatie nodig hebt. |
| Identiteitsbescherming | Boven op de basisbeveiliging voor elke persona kunt u beleidsregels voor voorwaardelijke toegang hebben die betrekking hebben op identiteit. Voorbeelden: Verouderde verificatie blokkeren, extra meervoudige verificatie vereisen voor hoog gebruikers- of aanmeldingsrisico, vereisen een bekend apparaat voor meervoudige verificatieregistratie. |
| Gegevensbescherming | Dit beleidstype geeft deltabeleid aan waarmee gegevens worden beschermd als een extra laag boven op de basisbeveiliging. Voorbeelden:
|
| AppProtection | Dit beleidstype is een andere aanvulling op de basisbeveiliging. Voorbeelden:
|
| Aanvalsoppervlaktereductie | Het doel van dit type beleid is om verschillende aanvallen te beperken. Voorbeelden:
|
| Naleving | U kunt een nalevingsbeleid gebruiken om een gebruiker te verplichten de gebruiksvoorwaarden te bekijken voor gasten die toegang hebben tot klantenservices. |
App
In de volgende tabel wordt het app-onderdeel van een beleidsnaam beschreven:
| App-naam | Beschrijving/voorbeelden |
|---|---|
| AllApps | AllApps geeft aan dat alle cloud-apps zijn gericht op het beleid voor voorwaardelijke toegang. Alle eindpunten worden behandeld, inclusief eindpunten die ondersteuning bieden voor voorwaardelijke toegang en eindpunten die dat niet ondersteunen. In sommige scenario's werkt het niet goed om alle apps tegelijk aan te pakken. We raden aan om alle apps op te nemen in het basisbeleid, zodat alle eindpunten door dat beleid worden gedekt. Nieuwe apps die worden weergegeven in Microsoft Entra ID, voldoen ook automatisch aan het beleid. |
| <AppName> |
<AppName> is een tijdelijke aanduiding voor de naam van een app waarop het beleid betrekking heeft. Maak de naam niet te lang. Voorbeeldnamen:
|
Platformtype
In de volgende tabel wordt het platformonderdeel van een beleidsnaam beschreven:
| Platformtype | Beschrijving |
|---|---|
| AnyPlatform | Het beleid is gericht op elk platform. U configureert dit doorgaans door Any Devicete selecteren. (In beleid voor voorwaardelijke toegang worden zowel het woord platform als het woord apparaat gebruikt.) |
| Ios | Het beleid is gericht op Apple iOS-platforms. |
| Android | Het beleid is gericht op Google Android-platforms. |
| Ramen | Dit beleid is gericht op het Windows-platform. |
| Linux | Dit beleid is gericht op de Linux-platforms. |
| WindowsPhone | Het beleid is gericht op Windows Phone-platforms. |
| macOS | Het beleid is gericht op de macOS-platforms |
| iOSAndroid | Het beleid is gericht op zowel iOS- als Android-platforms. |
| Onbekend | Het beleid is gericht op elk platform dat niet eerder is vermeld. U configureert dit doorgaans door Any Device op te sluiten en alle afzonderlijke platforms uit te sluiten. |
Typen besturingselementen
In de volgende tabel wordt het onderdeel Grant Control van een beleidsnaam beschreven:
| Toekenningstype | Beschrijving/voorbeelden |
|---|---|
| Blokkeren | Aanmelden wordt geblokkeerd door het beleid |
| MFA (Multi-Factor Authenticatie) | Voor het beleid is meervoudige verificatie vereist. |
| Volgzaam | Het beleid vereist een compatibel apparaat, zoals bepaald door Endpoint Manager, dus het apparaat moet worden beheerd door Endpoint Manager. |
| CompliantorAADHJ | Voor het beleid is een conform apparaat of een hybride gekoppeld apparaat van Microsoft Entra vereist. Een standaard bedrijfscomputer die lid is van een domein, is ook verbonden met een hybride Microsoft Entra ID. Mobiele telefoons en Windows 10-computers die samen beheerd worden of aangesloten zijn bij Microsoft Entra, kunnen voldoen aan de vereisten. |
| CompliantandAADHJ | Voor het beleid is een apparaat vereist dat compatibel is én lid is van Microsoft Entra Hybrid. |
| MFAorCompliant | Voor het beleid is een compliant apparaat vereist of moet er gebruik worden gemaakt van multifactorauthenticatie als het apparaat niet compliant is. |
| MFAandCompliant | Voor het beleid is een compatibel apparaat en meervoudige verificatie vereist. |
| MFAorAADHJ | Voor dit beleid is een Microsoft Entra hybride gekoppelde computer vereist, of multi-factor authenticatie indien het geen Microsoft Entra hybride gekoppelde computer is. |
| MFAandAADHJ | Voor het beleid is zowel een hybride gekoppelde computer van Microsoft Entra als multi-factor authenticatie vereist. |
| GoedgekeurdeClientVereist | Voor het beleid is een goedgekeurde client-app vereist. |
| AppProtection | Voor het beleid is app-beveiliging vereist |
| Onbeheerde | Het beleid is gericht op apparaten die niet bekend zijn door Microsoft Entra-id. U kunt dit toekenningstype bijvoorbeeld gebruiken om vanaf elk apparaat toegang tot Exchange Online toe te staan. |
Benoemde locaties
U wordt aangeraden deze standaardlocaties te definiëren voor gebruik in beleid voor voorwaardelijke toegang:
- Vertrouwde IP-adressen/interne netwerken. Deze IP-subnetten vertegenwoordigen locaties en netwerken met fysieke toegangsbeperkingen of andere besturingselementen, zoals computersysteembeheer, verificatie op netwerkniveau of inbraakdetectie. Deze locaties zijn veiliger, zodat het afdwingen van voorwaardelijke toegang kan worden versoepeld. Overweeg of Azure- of andere datacenterlocaties (IP's) moeten worden opgenomen in deze locatie of dat ze hun eigen benoemde locaties moeten hebben.
- Citrix-vertrouwde IP-adressen. Als u Citrix on-premises hebt, kan het handig zijn om afzonderlijke uitgaande IPv4-adressen voor de Citrix-farms te configureren als u vanuit Citrix-sessies verbinding moet kunnen maken met cloudservices. In dat geval kunt u deze locaties uitsluiten van beleid voor voorwaardelijke toegang als dat nodig is.
- Zscaler-locaties, indien van toepassing. Op computers is een ZPA-agent geïnstalleerd en wordt al het verkeer doorgestuurd naar internet naar of via de Zscaler-cloud. Het is dus de moeite waard om Zscaler-bron-IP's in voorwaardelijke toegang te definiëren en alle aanvragen van niet-mobiele apparaten te vereisen om Zscaler te doorlopen.
- Landen/regio's waarmee zaken doen is toegestaan. Het kan handig zijn om landen/regio's te verdelen in twee locatiegroepen: een regio die gebieden van de wereld vertegenwoordigt waar werknemers doorgaans werken en een regio die andere locaties vertegenwoordigt. Hiermee kunt u aanvullende besturingselementen toepassen op aanvragen die afkomstig zijn van buiten de gebieden waar uw organisatie normaal werkt.
- Locaties waar meervoudige verificatie moeilijk of onmogelijk kan zijn. In sommige scenario's kan het vereisen van meervoudige verificatie het lastig maken voor werknemers om hun werk te doen. Medewerkers hebben bijvoorbeeld mogelijk niet de tijd of kans om te reageren op frequente multi-factor authentication-uitdagingen. Of op sommige locaties kan RF-screening of elektrische interferentie het gebruik van mobiele apparaten lastig maken. Normaal gesproken gebruikt u andere bedieningselementen op deze locaties, of worden ze mogelijk als betrouwbaar beschouwd.
Op locatie gebaseerde toegangsbeheer is afhankelijk van het bron-IP-adres van een aanvraag om de locatie van de gebruiker te bepalen op het moment van de aanvraag. Het is niet eenvoudig om spoofing uit te voeren op het openbare internet, maar beveiliging die wordt geboden door netwerkgrenzen, kan minder relevant worden geacht dan ooit. Het wordt niet aanbevolen om alleen te vertrouwen op locatie als voorwaarde voor toegang. Voor sommige scenario's is het echter mogelijk de beste controle die u kunt gebruiken, bijvoorbeeld als u de toegang beveiligt vanuit een serviceaccount van on-premises dat wordt gebruikt in een niet-interactief scenario.
Aanbevolen beleidsregels voor voorwaardelijke toegang
We hebben een spreadsheet gemaakt met aanbevolen beleidsregels voor voorwaardelijke toegang. U kunt het spreadsheet hier downloaden.
Gebruik het voorgestelde beleid als uitgangspunt.
Uw beleid verandert waarschijnlijk in de loop van de tijd om gebruiksvoorbeelden te kunnen gebruiken die belangrijk zijn voor uw bedrijf. Hier volgen enkele voorbeelden van scenario's waarvoor mogelijk wijzigingen zijn vereist:
- Implementeer alleen-lezentoegang tot Exchange Online voor werknemers die een onbeheerd apparaat gebruiken op basis van meervoudige verificatie, app-beveiliging en een goedgekeurde client-app.
- Implementeer gegevensbeveiliging om ervoor te zorgen dat gevoelige informatie niet wordt gedownload zonder verbeterde beveiliging van Azure Information Protection.
- Bescherming bieden tegen kopiëren en plakken door gasten.
Meerdere versies bevinden zich momenteel in de openbare preview, dus verwacht binnenkort updates van de voorgestelde set startbeleidsregels voor voorwaardelijke toegang (CA).
Richtlijnen voor voorwaardelijke toegang
Nu u een startersset met beleidsregels voor voorwaardelijke toegang hebt, moet u deze op een gecontroleerde en gefaseerde manier implementeren. U wordt aangeraden een implementatiemodel te gebruiken.
Hier volgt één benadering:
Het idee is om eerst beleidsregels te implementeren voor een klein aantal gebruikers binnen één personagroep. U kunt een gekoppelde Microsoft Entra-groep met de naam Persona Ring 0 gebruiken voor deze implementatie. Nadat u hebt gecontroleerd of alles werkt, wijzigt u de toewijzing in een groep, Persona Ring 1, met meer leden, enzovoort.
Vervolgens schakelt u het beleid in met behulp van dezelfde ringbenadering totdat alle beleidsregels zijn geïmplementeerd.
Doorgaans beheert u de leden van ring 0 en ring 1 handmatig. Een ring 2- of 3-groep die honderden of zelfs duizenden gebruikers bevat, kan worden beheerd via een dynamische groep die is gebaseerd op een percentage van de gebruikers in een bepaalde persona.
Het gebruik van ringen als onderdeel van een implementatiemodel is niet alleen voor de eerste implementatie. U kunt dit ook gebruiken wanneer nieuwe beleidsregels of wijzigingen in bestaande beleidsregels vereist zijn.
Met een voltooide implementatie moet u ook de controlecontroles ontwerpen en implementeren die zijn besproken in de principes voor voorwaardelijke toegang.
Naast het automatiseren van de eerste implementatie, wilt u mogelijk wijzigingen in beleid automatiseren met behulp van CI/CD-pijplijnen. U kunt Microsoft365DSC gebruiken voor deze automatisering.
Bijdragers
Dit artikel wordt onderhouden door Microsoft. Het is oorspronkelijk geschreven door de volgende inzenders.
Hoofdauteur:
- Claus Jespersen | Hoofdconsultant ID&Sec
Meld u aan bij LinkedIn als u niet-openbare LinkedIn-profielen wilt zien.
Volgende stappen
- Leertraject: Identiteit en toegang implementeren en beheren
- beleid voor voorwaardelijke toegang