Conditional Access voorwaarden opstellen: beleidsregels die echt beschermen
Conditional Access valt of staat bij de regels die je zelf schrijft. Dit artikel geeft zeven voorbeeldbeleidsregels met concrete instellingen, legt uit welke regel wint bij een botsing en laat zien hoe je test zonder jezelf buiten te sluiten.
Wat Conditional Access-beleid concreet regelt
Conditional Access is de laag in Microsoft 365 die per aanmeldpoging beslist of iemand naar binnen mag, en onder welke voorwaarden. In plaats van een simpele ja of nee kijkt het systeem naar de context: wie meldt zich aan, vanaf welk apparaat, op welke locatie, en hoe risicovol de poging lijkt. Op basis daarvan dwingt een regel iets af, bijvoorbeeld een tweede factor of een beheerd apparaat, of blokkeert de toegang volledig.
Voor een bedrijf met 15 tot 250 werkplekken is dit het scharnierpunt tussen gemak en veiligheid. Zonder beleid staat de voordeur open zodra iemand het wachtwoord kent. Met te strak beleid lopen medewerkers vast en groeit de druk om uitzonderingen te maken. Het doel is een set van 5 tot 10 regels die samen dekking geven zonder dat 20 procent van je mensen dagelijks tegen een muur loopt.
Het idee past in een bredere beweging naar zero trust security, waarbij je geen enkele verbinding automatisch vertrouwt. Conditional Access is daarvan de praktische motor: elke sessie wordt opnieuw beoordeeld. Meer achtergrond over de rol binnen Microsoft 365 vind je in ons artikel over zero trust in Microsoft 365.
Een regel bestaat telkens uit twee delen: de voorwaarden (wanneer geldt de regel) en de controls (wat gebeurt er dan). Die tweedeling is de kern van alles wat volgt.
| Onderdeel | Wat je invult | Voorbeeld |
|---|---|---|
| Toewijzing | Wie en wat de regel raakt | Alle gebruikers, cloud-app Exchange Online |
| Voorwaarden | Signalen die de regel activeren | Aanmelding buiten Nederland |
| Controls | Wat wordt afgedwongen | Blokkeren of MFA vereisen |
De belangrijkste signalen: locatie, apparaat, risico en app
Voordat je regels schrijft, moet je weten met welke signalen je speelt. Vier daarvan doen het meeste werk voor een doorsnee MKB-omgeving.
Locatie werkt met benoemde locaties: IP-reeksen van je kantoor of landen die je als vertrouwd markeert. Je kunt een regel maken die aanmeldingen van buiten Nederland en Belgie strenger behandelt. Let op dat een medewerker die 2 weken op vakantie in het buitenland is anders wordt beoordeeld dan iemand op kantoor.
Apparaat kijkt of een toestel bekend is bij je organisatie. Een apparaat dat is aangemeld bij Entra ID of beheerd wordt via Intune telt als vertrouwd. Een onbekende laptop uit een internetcafe niet. Ongeveer 40 procent van de incidenten begint op een apparaat dat niemand beheert.
Risico komt van de ingebouwde detectie. Microsoft berekent een gebruikersrisico en een aanmeldrisico op basis van signalen zoals onmogelijk reizen (aanmelden in Amsterdam en 15 minuten later in Manilla) of lekgegevens. Deze risicosignalen vereisen doorgaans een hogere licentie.
App bepaalt welke cloud-toepassing de regel raakt. Je kunt Exchange en SharePoint anders behandelen dan een intern dashboard.
| Signaal | Sterk in | Beperking |
|---|---|---|
| Locatie | Snel breed afschermen | VPN en reizen vertroebelen het beeld |
| Apparaat | Onbekende toestellen weren | Vereist beheer via Intune of Entra |
| Risico | Reageren op verdacht gedrag | Vraagt vaak een duurdere licentie |
| App | Gericht aanscherpen per dienst | Kost meer regels en onderhoud |
De sterkste bescherming ontstaat niet uit een enkel signaal, maar uit een combinatie. Multifactorauthenticatie blijft de basislaag; hoe je die per situatie afdwingt lees je in ons artikel over MFA in Microsoft 365.
Zeven voorbeeldbeleidsregels met instellingen
Hieronder staan zeven regels die samen een werkbaar fundament vormen. Behandel ze als sjabloon, niet als kant-en-klare kopie: elke omgeving heeft eigen uitzonderingen.
Regel 1: MFA voor alle gebruikers
De basisregel. Iedereen die zich aanmeldt bij een cloud-app moet een tweede factor gebruiken. Toewijzing: alle gebruikers, alle cloud-apps. Control: MFA vereisen. Sluit je noodaccount uit (daarover later meer). Dit ene beleid blokkeert naar schatting 99 procent van de geautomatiseerde wachtwoordaanvallen.
Regel 2: MFA verplicht voor beheerders bij elke aanmelding
Beheerdersaccounts verdienen strengere regels. Richt deze op de directoryrollen (zoals globaal beheerder) en zet de sessieduur op 4 uur, zodat een beheerder na een halve werkdag opnieuw bevestigt. Voor deze groep, vaak 2 tot 5 personen in een MKB, weegt de extra stap ruim op tegen het risico.
Regel 3: Onbekende landen blokkeren
Werken je 30 medewerkers alleen in Nederland en soms Belgie? Blokkeer dan aanmeldingen van alle overige landen. Maak een benoemde locatie met beide landen en blokkeer de rest. Houd een uitzonderingsgroep voor wie tijdelijk in het buitenland zit, met een terugzetmoment na 4 weken.
Regel 4: Beheerd apparaat vereisen voor gevoelige apps
Voor SharePoint met personeelsdossiers of een financieel pakket eis je een apparaat dat compliant is via Intune. Onbeheerde toestellen krijgen geen toegang tot deze data. Dit voorkomt dat gevoelige bestanden op een privelaptop belanden die je nooit kunt wissen.
Regel 5: Verhoogd aanmeldrisico afdwingen met MFA
Bij een middelhoog of hoog aanmeldrisico dwing je MFA af, ook als de gebruiker die net al deed. Zo vang je gekaapte sessies op. Deze regel steunt op de risicodetectie en vraagt daarom vaak een licentie die per gebruiker rond de 8 euro tot 10 euro per maand extra kost.
Regel 6: Verouderde protocollen blokkeren
Legacy-authenticatie (oude mailprotocollen zonder MFA-ondersteuning) is een geliefd aanvalspad. Blokkeer deze clients volledig. In veel omgevingen raakt dit minder dan 5 procent van de aanmeldingen, maar het sluit een gat dat anders alle andere regels omzeilt.
Regel 7: Sessielimiet op onbeheerde apparaten
Sta toegang op een onbeheerd apparaat toe, maar beperk de sessie: geen bestanden downloaden en na 1 uur opnieuw aanmelden. Zo kan iemand vanaf een geleende computer wel snel iets bekijken zonder dat data blijft staan.
| Regel | Voorwaarde | Control |
|---|---|---|
| 1 MFA algemeen | Alle aanmeldingen | MFA vereisen |
| 2 Beheerders | Rol is beheerder | MFA plus sessie 4 uur |
| 3 Landen | Buiten NL en BE | Blokkeren |
| 4 Gevoelige app | SharePoint HR of finance | Compliant apparaat |
| 5 Risico | Aanmeldrisico middel of hoog | MFA vereisen |
| 6 Legacy | Oude protocollen | Blokkeren |
| 7 Sessie | Onbeheerd apparaat | Geen download, 1 uur |
Een uitgebreidere bespreking van deze aanpak voor kleinere organisaties staat in ons artikel over conditional access voor het MKB.
Volgorde en prioriteit: welke regel wint
Conditional Access werkt anders dan een firewall. Er is geen genummerde lijst waarbij de eerste passende regel wint. In plaats daarvan worden alle regels die van toepassing zijn samengevoegd, en geldt een simpele hoofdregel: blokkeren wint altijd. Als een blokkeerregel en een toestaanregel allebei van toepassing zijn, gaat de deur dicht.
Voor de overige controls stapelen de eisen. Vereist de ene regel MFA en de andere een compliant apparaat, dan moet de gebruiker aan beide voldoen. Dat verklaart waarom te veel losse regels snel tot frustratie leiden: een medewerker kan onbedoeld drie eisen tegelijk krijgen.
| Situatie | Wat er gebeurt | Uitkomst |
|---|---|---|
| Blokkeren plus toestaan | Blokkeren heeft voorrang | Toegang geweigerd |
| MFA plus compliant apparaat | Eisen stapelen | Beide nodig |
| Twee keer MFA | Zelfde eis, geen dubbeling | Een keer MFA |
Denk daarom in lagen. Zet je blokkeerregels (legacy, landen) als vangnet, en gebruik toestaanregels met controls voor het dagelijkse verkeer. Test na elke nieuwe regel wat een gewone medewerker en een beheerder concreet ervaren. Een goede vuistregel: houd het aantal actieve regels onder de 12, zodat je overzicht bewaart. Zodra je richting 20 regels gaat, wordt de kans op onbedoelde botsingen groter dan de winst.
Plan ook een vast onderhoudsmoment, bijvoorbeeld elke 3 maanden, om regels die niemand meer triggeren op te ruimen. Beleid dat 6 maanden ongewijzigd niets doet, mag weg.
Testen zonder jezelf buiten te sluiten
De grootste angst bij Conditional Access is de lockout: een regel die per ongeluk ook jou als beheerder buitensluit. Dat is een reeel risico, want een blokkeerregel op alle gebruikers raakt ook jou. Er zijn drie maatregelen die dit vrijwel altijd voorkomen.
Maak eerst een noodaccount. Dit is een globaal beheerder die je uitsluit van elke Conditional Access-regel, met een lang en uniek wachtwoord dat je fysiek opbergt in een kluis. Je gebruikt dit account minder dan 1 keer per jaar, alleen als alles vastloopt. Documenteer wie het wachtwoord kent, bij voorkeur 2 personen.
Gebruik de rapportagemodus. Elke regel kun je op "alleen rapporteren" zetten. De regel doet dan niets, maar logt wat er zou gebeuren. Laat een nieuwe regel 1 tot 2 weken meelopen in deze modus en bekijk in de aanmeldlogboeken hoeveel gebruikers geraakt zouden zijn. Zie je onverwacht dat 25 procent van je mensen zou worden geblokkeerd, dan is er iets mis met je voorwaarden.
Test met het what-if-hulpmiddel. Hiermee simuleer je een aanmelding: kies een gebruiker, een app en een locatie, en zie welke regels afgaan. Doe dit voor minstens 4 scenario's: een gewone medewerker op kantoor, dezelfde thuis, een beheerder, en iemand vanaf een onbeheerd apparaat.
| Testmethode | Wat je ziet | Risico |
|---|---|---|
| Noodaccount | Altijd een terugweg | Geen, mits goed bewaard |
| Rapportagemodus | Impact zonder gevolgen | Geen, regel is inactief |
| What-if | Uitkomst per scenario | Geen, alleen simulatie |
Rol een regel pas volledig uit nadat rapportagemodus en what-if geen verrassingen tonen. Begin bij een pilotgroep van 5 tot 10 medewerkers voordat je naar de volle organisatie gaat. Zo beperk je de schade van een fout tot een handvol mensen in plaats van alle 200.
Veelgemaakte fouten bij het opstellen van beleid
Een paar valkuilen komen telkens terug bij bedrijven die zelf aan de slag gaan.
Geen noodaccount. Wie zonder terugweg een blokkeerregel op alle gebruikers zet, kan zichzelf buitensluiten en heeft dan Microsoft-ondersteuning nodig, wat dagen kan duren.
Te veel uitzonderingen. Elke uitzonderingsgroep is een gaatje. Als 30 procent van je mensen is uitgezonderd van MFA, beschermt de regel weinig. Houd uitzonderingslijsten kort en zet een einddatum, bijvoorbeeld na 4 weken opnieuw beoordelen.
Regels op elkaar stapelen zonder overzicht. Zonder documentatie weet na 12 maanden niemand meer waarom een regel bestaat. Houd per regel een korte notitie bij: doel, wie geraakt wordt, en de datum.
Locatie als enige slot. Alleen op land filteren is zwak, want een aanvaller huurt eenvoudig een server in Nederland. Combineer locatie altijd met MFA of apparaatvereisten.
MFA overslaan voor beheerders. Juist de accounts met de meeste rechten worden soms als eerste uitgezonderd "voor het gemak". Dat is precies verkeerd om.
Nooit testen na wijzigingen. Een regel die vorige maand werkte, kan botsen met een nieuwe. Loop na elke aanpassing je 4 testscenario's opnieuw door.
| Fout | Gevolg | Correctie |
|---|---|---|
| Geen noodaccount | Lockout, dagen offline | Kluisaccount, uitgezonderd |
| Te veel uitzonderingen | Beleid werkt niet | Kort houden, einddatum |
| Geen documentatie | Onbeheerbaar na 12 maanden | Notitie per regel |
| Alleen locatie | Makkelijk te omzeilen | Combineer met MFA |
| Beheerders vrijgesteld | Grootste risico open | Strengere regel juist hier |
Het opzetten van dit fundament kost een geoefende beheerder ongeveer 8 uur, plus 2 weken meekijken in rapportagemodus. Meer over de plaats van Conditional Access binnen een breder beveiligingsprogramma lees je in onze categorie cybersecurity.
Veelgestelde vragen
Hoeveel Conditional Access-regels heeft een MKB gemiddeld nodig?
Voor een bedrijf van 15 tot 250 werkplekken is een set van 5 tot 8 regels meestal genoeg om de belangrijkste risico's af te dekken. Meer dan 12 actieve regels maakt het beheer al snel onoverzichtelijk en vergroot de kans op botsingen zonder dat de bescherming veel toeneemt.
Wat is een noodaccount en waarom is het verplicht?
Een noodaccount is een globaal beheerder die je uitsluit van alle Conditional Access-regels, met een lang wachtwoord dat fysiek opgeborgen ligt. Het bestaat om jezelf terug naar binnen te helpen als een regel iedereen buitensluit. Zonder zo'n account riskeer je dagen wachten op Microsoft-ondersteuning.
Kan ik nieuwe regels testen zonder gebruikers te raken?
Ja. Zet een nieuwe regel eerst op rapportagemodus, dan logt hij wel wat zou gebeuren zonder iets te blokkeren. Laat dit 1 tot 2 weken lopen en gebruik daarnaast het what-if-hulpmiddel om losse aanmeldingen te simuleren voordat je de regel echt inschakelt.
Heb ik voor alle regels een duurdere licentie nodig?
Nee. Basisregels zoals MFA voor iedereen en het blokkeren van verouderde protocollen werken met de meeste zakelijke abonnementen. Regels op basis van gebruikers- of aanmeldrisico vragen wel een hogere licentie, die vaak rond de 8 euro tot 10 euro per gebruiker per maand extra kost.
Wat gebeurt er als twee regels elkaar tegenspreken?
Conditional Access voegt alle van toepassing zijnde regels samen. Blokkeren wint altijd van toestaan. Bij verschillende controls stapelen de eisen: vraagt de ene regel MFA en de andere een beheerd apparaat, dan moet de gebruiker aan beide voldoen.
Dit artikel is informatief bedoeld en vormt geen advies toegesneden op jouw specifieke omgeving. Laat je beleidsregels voor je eigen situatie toetsen door een gekwalificeerde IT-adviseur voordat je ze breed uitrolt.