Conditional access basics voor mid-market IT-teams
Conditional access basics uitgelegd: de kern-Entra ID-policies die mid-market Microsoft-organisaties nodig hebben voordat ze verder bouwen aan identity.
Conditional access basics zijn de policies waar de meeste mid-market IT-teams als eerste naar grijpen zodra ze verder willen dan gebruikersnaam-en-wachtwoord als enige poort naar Microsoft 365 en Entra ID. Goed opgezet blokkeert een kleine, goed begrepen set conditional access-policies het grootste deel van de dagelijkse pogingen tot accountovername, zonder dat inloggen een dagelijkse hindernisbaan wordt voor je gebruikers. Verkeerd opgezet, doordat je het overslaat of een policylijst kopieert uit een blogpost zonder te begrijpen wat elke regel doet, wordt het óf een vals gevoel van veiligheid óf een bron van constante servicedesktickets.
Dit artikel loopt door de conditional access-policies die er echt toe doen in een mid-market Microsoft-omgeving, in de volgorde waarin de meeste teams ze het beste kunnen opbouwen, en waar de gebruikelijke gaten ontstaan zodra de eerste policies eenmaal draaien. Ook kijken we naar waar conditional access ophoudt en access governance begint, want de twee horen bij elkaar maar lossen verschillende problemen op.
Wat conditional access daadwerkelijk doet
Conditional access is de Entra ID-engine die een inlogpoging toetst aan een set voorwaarden (wie logt in, vanaf waar, op welk apparaat, in welke applicatie) en daarna een maatregel toepast: toestaan, blokkeren, of iets extra's vereisen zoals multi-factor authenticatie. Het is geen access management-systeem in de zin dat het bepaalt tot welke groepen of applicaties een gebruiker zou moeten behoren. Het bepaalt, op het moment van inloggen, of die specifieke inlogpoging mag doorgaan zoals gevraagd.
Waarom het meer doet dan een sterk wachtwoordbeleid alleen
Wachtwoorden lekken. Ze worden gephisht, hergebruikt tussen diensten, of geraden. Een wachtwoord op zichzelf, hoe complex het beleid het ook vereist, is een single point of failure. Conditional access voegt context toe aan de beslissing: een inlog vanaf een herkend apparaat op het bedrijfsnetwerk is een heel ander risico dan diezelfde gebruikersnaam en dat wachtwoord gebruikt vanaf een onbekende locatie om drie uur 's nachts. Conditional access laat je op dat verschil reageren in plaats van elke inlog identiek te behandelen.
De licentierealiteit
Conditional access vereist Entra ID P1 (inbegrepen bij de meeste Microsoft 365 Business Premium- en E3/E5-bundels). Draait je tenant nog op Microsoft 365 Business Standard of een vergelijkbaar plan zonder P1, dan is dat meestal het eerste licentiegat dat de moeite waard is om te dichten, want vrijwel alles hieronder is daarvan afhankelijk.
De kernpolicies die elke mid-market tenant zou moeten hebben
De meeste mid-market omgevingen hebben geen tientallen conditional access-policies nodig. Een kleine, goed geteste kernset dekt het grootste deel van het reële risico.
1. MFA verplichten voor alle gebruikers
Dit is de policy met de hoogste impact die er is. MFA verplichten voor elke gebruiker, bij elke inlog tenzij een andere voorwaarde al een veiliger pad toestaat, sluit de meest gebruikte route af die aanvallers nemen zodra ze een gestolen of geraden wachtwoord hebben.
2. Legacy authenticatie blokkeren
Legacy authenticatieprotocollen (oudere mailclients, sommige gescripte verbindingen) ondersteunen geen moderne authenticatie en kunnen geen MFA afdwingen. Ze zijn een bekend omleidingspad langs precies de bescherming die de MFA-policy hierboven moet bieden. Legacy authenticatie volledig blokkeren is inmiddels standaardpraktijk, geen avant-gardistische stap.
3. Compliant of hybrid-joined apparaten vereisen voor gevoelige toegang
Voor toegang tot gevoelige systemen of data voegt het vereisen dat het apparaat zelf compliant is (beheerd en voldoet aan je security-baseline via Intune) of hybrid Azure AD joined een extra laag toe bovenop "de juiste persoon, met het juiste wachtwoord en de juiste MFA-code". Het beantwoordt een andere vraag: is dit ook een apparaat dat je vertrouwt.
4. MFA specifiek vereisen bij risicovolle inlogpogingen
Entra ID kan inlogpogingen als risicovol markeren op basis van signalen zoals onmogelijk reizen, ongebruikelijke inlogkenmerken, of matches met gelekte credentials. Een policy die specifiek bij verhoogd risico MFA vereist (of toegang volledig blokkeert) voegt een gerichte laag toe bovenop de basis-MFA-policy, nuttig voor organisaties met Entra ID P2 en Identity Protection.
5. Toegang vanaf onbeheerde apparaten blokkeren of beperken voor adminrollen
Bevoorrechte rollen verdienen strakkere voorwaarden dan standaardgebruikers. Een compliant apparaat vereisen, en vaak een strengere MFA-methode, voor iedereen met een administratieve rol beperkt de impact als een adminaccount ooit doelwit wordt.
Aanbevolen opbouwvolgorde
| Volgorde | Policy | Waarom deze volgorde |
|---|---|---|
| 1 | MFA verplichten voor alle gebruikers | Hoogste impact, laagste drempel om te rechtvaardigen |
| 2 | Legacy authenticatie blokkeren | Sluit de belangrijkste MFA-omweg af |
| 3 | Compliant apparaat vereisen voor gevoelige apps | Vereist eerst een Intune compliance-baseline |
| 4 | MFA bij risicovolle inlogpogingen | Vereist Entra ID P2 / Identity Protection |
| 5 | Strengere controles voor adminrollen | Bouwt voort op bovenstaande apparaat- en risicopolicies |
Veelvoorkomende gaten nadat de eerste policies live staan
De kernpolicies op orde krijgen is vooruitgang, maar een paar gaten komen keer op keer terug in mid-market tenants zodra de eerste uitrol klaar is.
Break-glass accounts verkeerd uitgesloten
Elke conditional access-opzet heeft minstens één break-glass account nodig dat is uitgesloten van de policies, zodat een misconfiguratie niet alle admins tegelijk uit de tenant kan sluiten. Het gat zit niet in het ontbreken van een break-glass account. Het zit erin dat niemand het monitort, waardoor een account dat alleen bedoeld is voor noodgevallen ongezien blijft staan.
Gast- en externe gebruikers buiten scope gelaten
Policies die zijn opgebouwd rond het inlogpatroon van medewerkers sluiten gastaccounts of B2B-samenwerkingsgebruikers vaak stilzwijgend uit, hetzij per ongeluk, hetzij omdat de policies zijn gebouwd voordat die accounts bestonden. Gasten zouden in elk geval onder een basis-MFA-vereiste moeten vallen, passend geschaald naar hun toegangsniveau.
Policies die nooit meer herzien zijn
Conditional access-policies worden meestal één keer opgebouwd, tijdens een securityproject of als reactie op een audit, en daarna met rust gelaten. Rollen veranderen, nieuwe applicaties komen erbij, en de policyset groeit niet mee. Een korte periodieke review van welke policies er zijn, wat ze dekken en wat ze moesten voorkomen, houdt de opzet in lijn met de omgeving.
Conditional access behandeld als het hele toegangsverhaal
Dit is het gat dat het meest relevant is voor de rest van je identity-opzet. Conditional access bepaalt of een inlog mag plaatsvinden. Het heeft niets te maken met de vraag of de gebruiker in de eerste plaats aan die Entra ID-groep, die on-prem AD security-groep, of die applicatierol toegewezen had moeten worden. Een perfect geconfigureerde conditional access-policy laat een correct geauthenticeerde gebruiker met alle plezier een applicatie in waar hij nooit toegang toe had mogen hebben.
Waar conditional access ophoudt en access governance begint
Zie conditional access als de poort en toegangstoewijzing als de gastenlijst. Conditional access bepaalt wie er nu, onder deze voorwaarden, door de poort mag. Het bepaalt niet wie er in de eerste plaats op de lijst hoort te staan, of hoe lang.
Die tweede vraag, of iemands groepslidmaatschappen en applicatietoegang nog kloppen met zijn of haar werkelijke rol, afdeling en dienstverband, is een access governance-vraagstuk, geen conditional access-vraagstuk. Dat vereist:
- Groep- en roltoewijzingen die accuraat blijven terwijl mensen instromen, doorstromen en uitstromen.
- Een manier om te zien en periodiek te bevestigen wie toegang heeft tot wat, en waarom.
- Een vastgelegd proces om toegang in te trekken zodra die niet meer gerechtvaardigd is, in plaats van alleen risicovolle inlogpogingen te blokkeren voor toegang die allang ingetrokken had moeten worden.
Hoe ServiceChanger hierin past
ServiceChanger vervangt conditional access niet. Het pakt de laag op die conditional access nooit heeft moeten dekken: ervoor zorgen dat de toegang die een correct geauthenticeerde gebruiker daadwerkelijk heeft, ook de toegang is die hij of zij zou moeten hebben. De ABAC-engine wijst gebruikers automatisch toe aan Entra ID- en on-prem Active Directory-groepen op basis van attributen zoals afdeling, locatie en functie, waardoor toegang aansluit bij iemands werkelijke rol in plaats van te verwateren naarmate diegene van functie verandert. Group mining brengt de groepsstructuur in kaart die al besloten ligt in bestaande toegangspatronen, nuttig als voorwerk voordat je conditional access-policies rond gevoelige groepen aanscherpt. Ingebouwde access reviews geven je de periodieke bevestiging dat groepslidmaatschap nog klopt, dezelfde discipline die conditional access toepast op apparaatcompliance en risicosignalen, hier toegepast op de groep- en rolkant van het verhaal.
Voor het bredere plaatje van identity- en accessbeheer binnen Entra ID en on-prem AD, lees onze gids over identity access management. Voor meer over de securitykant, bekijk onze Security artikelen, of lees in onze Access Control berichten hoe attribuut-gebaseerde regels groepslidmaatschap accuraat houden.
FAQ
Wat is conditional access in Entra ID? Conditional access is een policy-engine in Entra ID die inlogpogingen toetst aan voorwaarden zoals gebruiker, locatie, apparaat en risiconiveau, en daarna een maatregel toepast zoals toestaan, blokkeren, of multi-factor authenticatie vereisen. Het bepaalt of een specifieke inlogpoging mag doorgaan, niet tot welke applicaties of groepen een gebruiker toegang zou moeten hebben.
Welke licentie heb ik nodig voor conditional access? Conditional access vereist Entra ID P1, inbegrepen bij de meeste Microsoft 365 Business Premium- en E3/E5-bundels. Geavanceerde functies zoals risicogebaseerde policies vereisen Entra ID P2, doorgaans inbegrepen in E5 of beschikbaar als add-on.
Wat is de belangrijkste conditional access-policy om mee te beginnen? MFA verplichten voor alle gebruikers bij elke inlog is over het algemeen de policy met de hoogste impact om als eerste in te voeren, omdat die de meest gebruikte aanvalsroute afsluit zodra een wachtwoord is gelekt of geraden. Legacy authenticatie blokkeren volgt daar snel op, want legacy protocollen omzeilen MFA volledig.
Vervangt conditional access access reviews of groepsgovernance? Nee. Conditional access bepaalt of een inlog mag plaatsvinden op basis van context zoals apparaat en risico. Het beoordeelt niet of iemands groepslidmaatschappen of applicatietoegang nog kloppen met zijn of haar rol. Daarvoor zijn aparte access governance-praktijken nodig, zoals periodieke access reviews en attribuut-gebaseerde groepstoewijzing.
Staan je conditional access-policies, maar ben je minder zeker over wat ze eigenlijk beschermen op de groep- en rolkant, dan is het de moeite waard om beide samen te bekijken. Neem contact op om te zien hoe ServiceChanger de toegang binnen Entra ID en on-prem AD in lijn houdt met wie mensen werkelijk zijn.
Ook interessant
Just-in-Time Privileged Access voor Mid-Market IT
Just in time access uitgelegd: hoe mid-market Microsoft-organisaties met PIM standing privilege-risico verlagen, zonder een volledig PAM-traject.
Break glass account in Entra ID: opzet en monitoring
Break glass account best practices voor Entra ID: hoe je noodtoegangsaccounts correct opzet en monitort zonder een verborgen risico te creëren.
Service account governance in Entra ID en AD
Service account governance in Entra ID en Active Directory: waarom non-human identities dezelfde regels nodig hebben als mensen, en hoe je grip krijgt.