Conditional access beleid: zo bouw je slimme toegangsregels
Een conditional access beleid beoordeelt bij elke aanmelding wie iemand is, met welk apparaat hij werkt en hoe risicovol die aanmelding is, en past daarna automatisch de juiste maatregel toe: toegang toestaan, MFA eisen of blokkeren. Voor MKB-organisaties betekent dit minder onnodige controles voor vertrouwde situaties en strengere eisen precies waar risico ontstaat. De enige voorwaarde is een geldige Microsoft Entra ID P1-licentie, en de eerste stap is altijd testen in report-only modus voordat je iets activeert.
Kort samengevat:
- Het beperken van legacy-authenticatie en het verplichten van MFA voor beheerders sluit het grootste deel van de risico’s zonder veel extra inspanning.
- Een succesvolle uitrol vereist een eerste testfase in report-only modus en een gefaseerde, veilige aanpak om organisatiebuitensluiting en supportproblemen te voorkomen.
- Beleid moet overzichtelijk blijven door app-groepering en duidelijke toewijzingen, met één beleidsverantwoordelijke voor continue controle en documentatie.
- Organisaties behalen de meeste beveiligingswinst door zich te richten op enkele kernregels zoals MFA voor beheerders en blokkering van oudere protocollen, voordat ze complexere regels toevoegen.
- ASTIA verzorgt volledige trajecten van inventarisatie tot monitoring, waardoor MKB-organisaties zonder extra werk een veilig conditional access beleid kunnen implementeren.
Inhoudsopgave
- Wat is conditional access precies?
- Welke beleidsregels zet je als eerste in?
- Hoe houd je beleid overzichtelijk en beheersbaar?
- Hoe rol je conditional access veilig uit?
- Hoe pakt ASTIA conditional access aan in de praktijk?
- Wat onderschatten IT-teams het meest bij dit onderwerp?
- Conditional access uitrollen zonder gedoe
Wat is conditional access precies?
Conditional access is de beleidsengine binnen Microsoft Entra ID die continu identiteitssignalen combineert en daar “als dit, dan dat”-regels op toepast. Het systeem verwerkt dagelijks meer dan 40 terabyte aan identiteitssignalen wereldwijd, en gebruikt die data om per aanmelding een risico-inschatting te maken. Elke beleidsregel bestaat uit twee bouwstenen: assignments en access controls. Een policy wordt in twee fasen geëvalueerd: eerst verzamelt het systeem alle sessiegegevens (wie, welk apparaat, welke locatie, welk risico), en pas daarna volgt de handhaving.
De assignments bepalen op wie en wat het beleid van toepassing is:
- Gebruikers en groepen: specifieke medewerkers, rollen (zoals beheerders) of hele afdelingen.
- Cloud-apps of acties: Microsoft 365, een specifieke SaaS-applicatie of gevoelige beheeracties.
- Voorwaarden: aanmeldingsrisico, apparaattype, netwerklocatie, client-app en authenticatiecontext.
De access controls bepalen wat er gebeurt zodra die voorwaarden matchen. Denk aan blokkeren, MFA verplichten, een compliant apparaat eisen, alleen goedgekeurde apps toestaan of app-protectie afdwingen. Deze combinatie van assignments en controls vormt de kern van elk beleid dat je opstelt. Belangrijk detail: conditional access grijpt in na de eerste authenticatiestap, niet als netwerkperimeter. Het is een identiteitslaag, geen firewall tegen DoS-aanvallen.
Welke beleidsregels zet je als eerste in?
De meeste MKB-organisaties beginnen niet met complexe scenario’s, maar met een paar hygiëneregels die het meeste risico wegnemen. Praktijkervaring uit Nederlandse implementaties bevestigt dat blokkeren van legacy-authenticatie, standaard-MFA en apparaatcompliance samen het grootste deel van de aanvalsoppervlakte dichten.
Een praktische volgorde:
- MFA voor beheerders en gevoelige Azure-taken. Richt eerst een regel in die multifactor-authenticatie verplicht voor iedereen met een beheerrol. Deze eerste stap heeft de grootste impact per uur werk.
- Blokkeer legacy-authenticatie. Protocollen zoals SMTP, IMAP, POP en oudere Basic-authenticatie ondersteunen geen MFA en zijn een favoriet doelwit bij wachtwoordaanvallen. Een blokkeerregel hierop sluit een groot lek zonder dat gebruikers het merken.
- Eén brede “all resources”-regel met uitzonderingen. In plaats van tientallen losse app-regels, groepeer je toegang tot Microsoft 365 als geheel en maak je gerichte uitzonderingen voor noodaccounts of specifieke integraties.
- Compliant device verplichten voor gevoelige apps. Koppel toegang tot financiële systemen of HR-data aan een Intune-compliance-check, zodat alleen beheerde apparaten er bij kunnen.
Pro-tip: Begin met één pilotregel voor een kleine adminsgroep in report-only modus. Zo zie je precies wat er zou gebeuren zonder dat iemand daadwerkelijk wordt geblokkeerd.
Hoe houd je beleid overzichtelijk en beheersbaar?
Meer beleidsregels lijkt veiliger, maar werkt vaak averechts. Elke extra policy is een extra plek waar iets kan conflicteren, vergeten worden of een gebruiker onterecht blokkeren. Microsoft raadt daarom aan om app-groepering te gebruiken in plaats van per-app regels, bijvoorbeeld door Office 365 als één groep te behandelen zodat Teams en SharePoint niet los van elkaar problemen geven.
Een aantal governanceprincipes maakt het verschil tussen beleid dat werkt en beleid dat na een half jaar niemand meer begrijpt:
- Wijs één policy-eigenaar aan. Iemand binnen IT of security die alle wijzigingen goedkeurt en documenteert.
- Werk met een simpel wijzigingsproces. Een korte testcase en een go/no-go beslissing voordat een regel van report-only naar actief gaat.
- Blijf onder de tenant-limiet. Elke tenant heeft een maximum van 240 beleidsregels; met groepering en filters kom je daar zelden in de buurt.
- Koppel beleid aan classificatie. Gevoelige data (financieel, HR, klantgegevens) krijgt strengere condities dan algemene bedrijfsinformatie, in lijn met je informatieclassificatie of compliance-eisen.
Voor structurele opvolging is een helder toegangsbeheerbeleid een goede basis om policy-eigenaarschap en reviewmomenten vast te leggen.
Hoe rol je conditional access veilig uit?
Een verkeerd geconfigureerde regel kan een hele organisatie buitensluiten, inclusief de beheerder die de fout moet herstellen. Daarom is de volgorde hier belangrijker dan bij vrijwel elk ander IT-project.
- Inventariseer eerst. Welke apps, groepen en apparaten bestaan er, en wie heeft een noodaccount nodig dat buiten elk beleid valt? Controleer ook of iedereen een Entra ID P1-licentie heeft; risicogebaseerde regels vereisen P2 met Entra ID Protection.
- Test in report-only. Elke nieuwe regel start in report-only modus, zodat je ziet wat er zou gebeuren zonder daadwerkelijk iemand te blokkeren.
- Gebruik de What If-tool. Simuleer een specifieke aanmelding (gebruiker, app, locatie) en zie precies welke policies zouden afgaan, vóórdat je live gaat.
- Rol gefaseerd uit naar een kleine pilotgroep. Bewaak gedurende zeven tot veertien dagen het aantal geblokkeerde aanmeldingen en supportmeldingen.
- Evalueer en stel bij. Breid pas uit naar de volledige organisatie als de pilot geen onverwachte blokkades laat zien.
De meeste implementatieproblemen ontstaan niet door te weinig beveiliging, maar door te veel strikte regels in één keer die elkaar tegenwerken. Klein beginnen en opschalen werkt beter dan alles in één weekend willen dichttimmeren.
Hoe pakt ASTIA conditional access aan in de praktijk?
Bij de implementaties die ASTIA begeleidt, staat scoping voorop: eerst een inventarisatie van apps en gebruikersgroepen, dan een pilot in report-only en pas daarna een gefaseerde rollout naar de hele organisatie. Die volgorde voorkomt de twee klassieke missers: een beheerder die zichzelf buitensluit, en gebruikers die de dag na invoering massaal de helpdesk bellen.
Bij klanten zoals Beachclub O. leidde deze aanpak tot minder supportmeldingen na livegang, doordat eventuele conflicten al in de testfase naar boven kwamen. Policy-coverage, oftewel het percentage apps en gebruikers dat daadwerkelijk onder actief beleid valt, is daarbij de belangrijkste maatstaf om voortgang te tonen tijdens een audit.
Een organisatie die conditional access goed inricht, merkt het vooral aan wat er niet gebeurt: geen onnodige MFA-prompts voor vertrouwde situaties, maar wel een harde stop zodra een aanmelding van een onbekend apparaat of een verdachte locatie komt.
Wat onderschatten IT-teams het meest bij dit onderwerp?
De meeste artikelen over conditional access blijven hangen in Zero Trust-theorie, terwijl de praktijk in het MKB om iets anders draait: discipline in de uitrolvolgorde. Ik zie regelmatig organisaties die meteen een streng “all resources”-beleid activeren zonder report-only test, met als resultaat een helpdesk die vol staat met lock-out meldingen op maandagochtend.
Wat onderschat wordt, is hoeveel winst je haalt uit slechts twee regels: MFA voor beheerders en een blokkade op legacy-authenticatie. Die twee alleen dichten al een groot deel van het risico dat organisaties via conditional access willen aanpakken, nog voordat je aan apparaatcompliance of locatieregels begint.
De conventionele aanpak overdrijft ook vaak het aantal beleidsregels dat nodig is. Meer regels betekent meer plekken waar iets kapot kan gaan. Prioriteer daarom niet volledigheid, maar een kleine set goed geteste regels die je daarna geleidelijk uitbreidt. Wie dat negeert, betaalt de prijs in supporturen, niet in extra beveiliging.
— Mick
Conditional access uitrollen zonder gedoe
Zelf een compleet conditional access beleid opzetten, testen in report-only en daarna blijven monitoren kost tijd die de meeste MKB-IT-teams naast dagelijks beheer simpelweg niet hebben. ASTIA neemt dat volledige traject over: van inventarisatie en pilotbeleid tot Intune-koppeling, monitoring en periodieke bijsturing, als onderdeel van het werkplekbeheer voor het MKB.
Onze aanpak combineert conditional access met bredere IT-beveiliging, zodat MFA-regels, apparaatcompliance en e-mailbeveiliging op elkaar aansluiten in plaats van los van elkaar te functioneren. Twijfel je of jouw huidige licenties en policy’s up-to-date zijn, of wil je gewoon dat iemand anders de rollout en de nazorg overneemt? Plan een kennismaking en we brengen binnen een week in kaart welke stappen bij jouw organisatie nodig zijn.