Framework en beleid voor voorwaardelijke toegang
Dit artikel bevat een framework voor het implementeren van een op persona gebaseerde architectuur voor voorwaardelijke toegang, zoals die wordt beschreven in de architectuur van Zero Trust 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.
Naamconventies
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. Het 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 | Global, Beheer s, Internals, Externals, GuestUsers, Guest Beheer s, Microsoft365ServiceAccounts, AzureServiceAccounts, CorpServiceAccounts. |
| Beleidstype | BaseProtection, AppProtection, DataProtection, IdentityProtection, AttackSurfaceReduction, Compliance. |
| App | AllApps, O365 (voor alle Office 365-services), EXO (voor Exchange Online). |
| Platform | AnyPlatform, Unknown, Windows Telefoon, macOS, iOS, Android. |
| Besturingselement verlenen | Blokkeren, ADHJ, Compatibel, 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-Beheer s | CA100-CA199 |
| CA-Persona-Internals | CA200-CA299 |
| CA-Persona-Externals | CA300-CA399 |
| CA-Persona-GuestUsers | CA400-CA499 |
| CA-Persona-Guest Beheer s | 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 basisbeveiliging voor internals een bekende gebruiker en een bekend apparaat voor alle cloud-apps vereist, maar u wilt webversie van Outlook vanaf elk apparaat 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. |
| IdentityProtection | 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. |
| DataProtection | 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:
|
| AttackSurfaceReduction | 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 voor alle apps. We raden u aan alle apps in het basisbeleid te richten, zodat alle eindpunten worden gedekt door dat beleid. 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. Vermijd het maken van de naam 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 Elk apparaat te selecteren. (In beleid voor voorwaardelijke toegang worden zowel het woordplatform als het woordapparaat gebruikt.) |
| iOS | Het beleid is gericht op Apple iOS-platforms. |
| Android | Het beleid is gericht op Google Android-platforms. |
| Vensters | Dit beleid is gericht op het Windows-platform. |
| Linux | Dit beleid is gericht op de Linux-platforms. |
| Windows Telefoon | Het beleid is gericht op Windows Telefoon-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 een platform dat niet eerder wordt vermeld. U configureert dit doorgaans door Elk apparaat op te sluiten en alle afzonderlijke platforms uit te sluiten. |
Typen besturingselementen verlenen
In de volgende tabel wordt het onderdeel Grant Control van een beleidsnaam beschreven:
| Toekenningstype | Beschrijving/voorbeelden |
|---|---|
| Blokkeren | Aanmelden wordt geblokkeerd door het beleid |
| MFA | Voor het beleid is meervoudige verificatie vereist. |
| compatibel | 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 compatibel apparaat of een hybride apparaat van Microsoft Entra vereist. Een standaard bedrijfscomputer die lid is van een domein, is ook hybride Microsoft Entra ID gekoppeld. Mobiele telefoons en Windows 10-computers die gezamenlijk worden beheerd of Die lid zijn van Microsoft Entra, kunnen compatibel zijn. |
| CompliantandAADHJ | Voor het beleid is een apparaat vereist dat compatibel is met AND Microsoft Entra hybrid. |
| MFAorCompliant | Voor het beleid is een compatibel apparaat of meervoudige verificatie vereist als het niet compatibel is. |
| MFAandCompliant | Voor het beleid is een compatibel apparaat en meervoudige verificatie vereist. |
| MFAorAADHJ | Voor het beleid is een hybride computer of meervoudige verificatie van Microsoft Entra vereist als het geen hybride computer van Microsoft Entra is. |
| MFAandAADHJ | Voor het beleid is een hybride computer en meervoudige verificatie van Microsoft Entra vereist. |
| RequireApprovedClient | Voor het beleid is een goedgekeurde client-app vereist. |
| AppProtection | Voor het beleid is app-beveiliging vereist |
| Onbeheerd | 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 bedrijven kunnen worden 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 besturingselementen op deze locaties of worden ze mogelijk vertrouwd.
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.
Er gaan momenteel meerdere previews naar de openbare preview, dus verwacht binnenkort updates van de voorgestelde set beleidsregels 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. 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.