Conditional Access-basis voor het mkb in Entra ID

Wat Conditional Access doet

Conditional Access in Microsoft Entra ID beoordeelt elke aanmelding op signalen: wie meldt zich aan, bij welke app, vanaf welk apparaat en welke locatie, en met welk risico. Op basis daarvan sta je de aanmelding toe, eis je extra controles (zoals MFA of een beheerd apparaat) of blokkeer je haar.

Licenties: P1, P2 of Security Defaults

Voor Conditional Access heb je minimaal Microsoft Entra ID P1 nodig voor de gebruikers op wie het beleid van toepassing is. P1 zit onder meer in Microsoft 365 Business Premium en in Microsoft 365 E3. Risicogebaseerd beleid (aanmeldrisico en gebruikersrisico) vraagt Entra ID P2, dat bijvoorbeeld in Microsoft 365 E5 zit of als losse licentie of add-on beschikbaar is. Licentiebundels veranderen geregeld, dus controleer de actuele inhoud van je abonnement in het Microsoft 365-beheercentrum.

Heb je geen P1? Gebruik dan Security Defaults. Dat is een gratis, vaste set instellingen die MFA-registratie afdwingt, legacy authenticatie blokkeert en beheerders extra beschermt. Security Defaults en eigen Conditional Access-beleid gaan niet samen: zodra je eigen beleid inschakelt, zet je Security Defaults uit.

De basisset beleidsregels

Ik begin bij mkb-klanten altijd met deze set.

1. Legacy authenticatie blokkeren

Oude protocollen zoals POP, IMAP en SMTP AUTH met basisauthenticatie ondersteunen geen MFA en zijn een favoriet doelwit voor password spraying. Maak een regel voor alle gebruikers en alle resources, met als voorwaarde de clientapps “Exchange ActiveSync-clients” en “Andere clients”, en als actie blokkeren. Kijk eerst in de aanmeldlogboeken welke apparaten of applicaties nog legacy authenticatie gebruiken. Multifunctionals die scannen naar e-mail zijn de klassieke boosdoener. Microsoft faseert basisauthenticatie voor SMTP AUTH in Exchange Online verder uit; het actuele tijdpad staat in het Message Center.

2. MFA voor alle gebruikers

Eis MFA voor alle gebruikers bij alle resources. Gebruik bij voorkeur een verificatiesterkte (authentication strength) in plaats van de algemene MFA-eis, zodat je bepaalt welke methoden tellen. Sms en spraakoproep zijn de zwakste opties; de Microsoft Authenticator-app met number matching of passkeys zijn sterker. Vergeet gastgebruikers niet: neem ze bewust op of maak er een aparte regel voor.

3. Phishingbestendige MFA voor beheerders

Accounts met beheerrollen verdienen meer dan gewone MFA. Richt een regel op de directory-rollen (minimaal Globale beheerder, Beveiligingsbeheerder, Exchange-beheerder, SharePoint-beheerder, Gebruikersbeheerder, Beheerder voor bevoorrechte rollen en Intune-beheerder) en eis de ingebouwde verificatiesterkte phishingbestendige MFA: FIDO2-sleutels, passkeys, Windows Hello for Business of certificaatgebaseerde verificatie. Het beste is dat beheerders aparte, niet-gelicentieerde beheeraccounts hebben, los van hun dagelijkse account met mail.

4. Beheerd apparaat voor beheerportalen of gevoelige apps (optioneel)

Als je apparaten in Intune beheert, kun je voor de resource “Microsoft-beheerportalen” eisen dat het apparaat compatibel (compliant) of Microsoft Entra hybrid joined is. Hetzelfde kun je doen voor gevoelige apps, zoals je boekhoudpakket of HR-systeem als die via Entra ID aanmelden. Zet dit pas aan als je compliancebeleid op orde is; anders blokkeer je mensen op basis van een half ingericht beleid.

5. Risicobeleid (alleen met P2)

Met Entra ID P2 maak je twee regels: bij gemiddeld of hoog aanmeldrisico MFA eisen, en bij hoog gebruikersrisico een veilige wachtwoordwijziging of risicoherstel eisen. Configureer deze in Conditional Access. De oude risicobeleidsregels in ID Protection zelf zijn door Microsoft uitgefaseerd; heb je die nog, migreer ze dan.

6. Locatie- en landenbeleid (met kanttekeningen)

Benoemde locaties en landen kunnen nuttig zijn, bijvoorbeeld om aanmeldingen te blokkeren uit landen waar je geen zakelijke activiteiten hebt. Wees wel realistisch. IP-geolocatie is niet altijd nauwkeurig, aanvallers gebruiken gewoon VPN’s en hostingproviders in je eigen land, en medewerkers op reis of op een mobiel netwerk kunnen onverwacht geblokkeerd raken. Gebruik locatie als extra laag, nooit als vervanging van MFA.

Aanvullend: device code flow beperken

Onder de voorwaarde voor verificatiestromen kun je de device code flow blokkeren. Die wordt steeds vaker misbruikt voor phishing.

Break-glass-accounts

Maak minimaal twee noodtoegangsaccounts: alleen-cloudaccounts op het .onmicrosoft.com-domein, met de rol Globale beheerder, niet gekoppeld aan een persoon. Sluit ze uit van je Conditional Access-beleid, zodat een verkeerde regel je niet volledig buitensluit. Omdat Microsoft voor de beheerportalen MFA verplicht stelt, hebben ook deze accounts een sterke methode nodig. Een FIDO2-sleutel die fysiek veilig wordt bewaard, is daarvoor een gebruikelijke keuze.

Uitgesloten betekent niet onbewaakt. Stel een waarschuwing in die afgaat bij elke aanmelding van deze accounts, bijvoorbeeld via een waarschuwingsregel op de aanmeldlogboeken in Log Analytics of Microsoft Sentinel. Test de accounts periodiek en leg vast wie erbij mag en hoe.

Naamgeving

Een vaste naamconventie maakt je beleid leesbaar in logboeken en bij overdracht. Bijvoorbeeld: CA001-Alle-BlokkeerLegacyAuth, CA002-Alle-MFA en CA010-Admins-PhishingbestendigeMFA. Werk met groepen voor uitsluitingen, zoals een groep “CA-Uitsluiting-Noodtoegang”, zodat je in één oogopslag ziet wie waarvan is uitgesloten.

Wil je snel zien welke regels er staan en in welke status, dan helpt Microsoft Graph PowerShell (scope Policy.Read.All):

Get-MgIdentityConditionalAccessPolicy -All | Select-Object DisplayName, State | Sort-Object DisplayName

Veelgemaakte fouten

• Jezelf buitensluiten. Een regel voor alle gebruikers zonder uitsluiting van de noodtoegangsaccounts is de bekendste fout. Test altijd eerst in de modus Alleen rapporteren.
• Serviceaccounts vergeten. Accounts voor scan-naar-mail, synchronisatie of oude koppelingen kunnen geen MFA doen. Breng ze in kaart, vervang ze waar mogelijk door app-registraties of beheerde identiteiten, en sluit wat overblijft gericht uit, met een locatievoorwaarde.
• Te veel uitsluiten. Elke uitsluiting is een gat. Een groep “Uitsluitingen” waar na een jaar dertig mensen in zitten, ondermijnt het hele beleid. Geef uitsluitingen een eigenaar en een einddatum.
• Geen MFA-registratie geregeld. Als gebruikers nog niet geregistreerd zijn, worden ze bij de eerste aanmelding gevraagd dat te doen. Overweeg om het registreren van beveiligingsgegevens te beschermen, bijvoorbeeld met een Tijdelijke toegangspas.

Uitrolplan

1. Inventariseer licenties, beheerrollen, serviceaccounts en apparaten die legacy authenticatie gebruiken.
2. Maak de noodtoegangsaccounts, test ze en stel monitoring in.
3. Zorg dat alle gebruikers MFA hebben geregistreerd.
4. Maak alle regels aan in de modus Alleen rapporteren en laat ze minimaal een tot twee weken meelopen.
5. Analyseer de resultaten in de aanmeldlogboeken en met de What If-tool; los serviceaccounts en uitzonderingen op.
6. Communiceer naar gebruikers wat er verandert en wanneer.
7. Zet de regels gefaseerd aan: eerst legacy-blokkade en beheerdersbeleid, dan MFA voor een pilotgroep, daarna voor iedereen.
8. Schakel Security Defaults uit op het moment dat je eigen beleid actief wordt, niet eerder.