De meeste incidenten in MKB-omgevingen beginnen niet met een geavanceerde aanval op de firewall, maar met een geldig wachtwoord in verkeerde handen. Multifactorauthenticatie is daar het antwoord op, en veel organisaties hebben het inmiddels aan staan. Toch verschilt de bescherming die u eraan overhoudt sterk per implementatie: de ene vorm van MFA houdt een phishingaanval tegen, de andere niet.
Wat MFA wel en niet oplost
MFA zorgt ervoor dat een gestolen wachtwoord op zichzelf niet genoeg is om binnen te komen. Dat is een grote stap, want wachtwoorden lekken doorlopend via datasets van andere diensten en via nagemaakte inlogpagina’s. Wat MFA niet oplost: malware op een werkplek die een geldige sessie meeneemt, protocollen die de tweede factor helemaal niet ondersteunen, en uitzonderingen die iemand ooit “tijdelijk” heeft aangezet. Wie MFA inricht, richt dus vooral het geheel eromheen in. Dat valt onder identity en access management.
Niet elke tweede factor is even sterk
Er zijn grofweg drie niveaus in gebruik. Het verschil zit in de vraag of een aanvaller de tweede factor kan onderscheppen of aan de gebruiker kan ontfutselen.
Code via sms of e-mail
De zwakste variant. Een code is net zo goed door te geven aan een nagemaakte inlogpagina als een wachtwoord, en sms is gevoelig voor simkaartfraude.
- Beter dan alleen een wachtwoord
- Onderschepbaar en phishbaar
- Alleen als tijdelijke tussenstap
Authenticator met nummermatching
De gebruiker neemt een nummer over van het inlogscherm naar de app. Blind op “goedkeuren” tikken kan niet meer, en dat blokkeert de meeste massale pogingen.
- Geen blinde goedkeuring
- Werkt ook zonder mobiel bereik
- Inbegrepen in Microsoft 365
Passkey of hardwaresleutel
De sleutel is cryptografisch gebonden aan het echte inlogdomein. Een nagemaakte pagina krijgt niets bruikbaar, ook niet als de gebruiker meewerkt.
- Phishing-resistent
- Geen code om over te typen
- Begin hiermee bij beheerders
MFA-moeheid en pushmeldingen
Zodra een aanvaller een wachtwoord heeft, is een veelgebruikte tactiek om eindeloos inlogpogingen te doen tot de gebruiker de melding uit ergernis goedkeurt, vaak midden in de nacht. Nummermatching haalt die tactiek onderuit, omdat er geen knop meer is om zomaar op te tikken. Vertel gebruikers daarbij expliciet wat ze doen bij een melding die ze niet zelf hebben veroorzaakt: niet negeren, maar melden bij de helpdesk, want het betekent dat hun wachtwoord bekend is.
Conditional access: voorwaarden in plaats van alles of niets
MFA bij elke aanmelding op elk apparaat levert weerstand op bij gebruikers en dus creatieve omwegen. Met conditional access maakt u de eis afhankelijk van de situatie: wie, waarvandaan, op welk apparaat en naar welke data. Onderstaande set regels werkt voor de meeste organisaties met tien tot tweehonderdvijftig werkplekken.
| Situatie | Regel | Gevolg voor de gebruiker |
|---|---|---|
| Beheerd apparaat, bekende locatie | Apparaat moet compliant zijn | Aanmelden zonder extra stappen |
| Onbekend of prive-apparaat | MFA verplicht, geen download van bestanden | Webtoegang, lezen en bewerken in de browser |
| Beheerdersrol gebruiken | Phishing-resistente MFA verplicht | Passkey of hardwaresleutel |
| Aanmelding uit een land waar u niet werkt | Blokkeren | Melding bij de beheerder |
Zet elke nieuwe regel eerst in rapportagemodus. U ziet dan een week mee wie erdoor geraakt zou worden, zonder dat iemand buitengesloten raakt. Voor de inrichting binnen Microsoft 365 gaat dit hand in hand met de beveiliging van uw Microsoft 365-omgeving.
Wat u minimaal regelt
- MFA voor alle accounts, dus ook voor beheerders, directie en accounts die u zelden gebruikt.
- Verouderde aanmeldprotocollen blokkeren. Blijft POP, IMAP of SMTP met alleen een wachtwoord open, dan is uw MFA omzeilbaar. Dit hoort bij e-mailbeveiliging.
- Twee noodaccounts buiten de regels, met lange unieke wachtwoorden in een kluis en een alarm zodra ze gebruikt worden. Zonder die accounts sluit een foute regel u buiten uw eigen omgeving.
- Toegang tot bedrijfsdata koppelen aan de staat van het apparaat, wat vraagt om centraal endpoint management.
- Uitzonderingen alleen met einddatum en met een naam erbij, en elk kwartaal opnieuw langs.
Licenties en randvoorwaarden
Basis-MFA zit in elke Microsoft 365-omgeving. Voor conditional access heeft u Entra ID P1 nodig, dat onderdeel is van Microsoft 365 Business Premium. Voor de meeste MKB-organisaties is dat voldoende; u heeft geen enterprise-licentie nodig om bovenstaande regels in te voeren. Houd er rekening mee dat u de inrichting moet kunnen aantonen, bijvoorbeeld richting een verzekeraar of in het kader van de NIS2-richtlijn en uw AVG-verplichtingen.
Invoeren zonder chaos op de helpdesk
De praktische kant wordt vaak onderschat. Reken op een korte registratieperiode waarin gebruikers zelf hun app of sleutel koppelen, met een duidelijke einddatum en een instructie van een half A4. Begin met de IT-beheerders, dan een afdeling die meedenkt, daarna de rest. Plan de uitrol niet in een week met een deadline of een vakantiepiek, en zorg dat de helpdesk vooraf weet hoe een gebruiker weer toegang krijgt als de telefoon stuk of kwijt is. Die herstelprocedure is het onderdeel waar het in de praktijk op vastloopt, niet de techniek.
Van invoering naar beheer
Een eenmalige uitrol verliest binnen een jaar zijn waarde: er komen accounts bij, uitzonderingen blijven staan en apparaten vallen buiten beheer. Het onderhouden van deze regels hoort daarom bij proactief beheer, net als het opvolgen van meldingen. Gaat het ondanks alles mis, dan bepaalt uw voorbereiding hoe snel u weer werkt; dat leest u terug in ons artikel over herstel na een ransomware-aanval.
Wilt u weten welke van deze regels in uw omgeving al actief zijn en welke uitzonderingen er nog open staan? Wij lopen uw aanmeldbeleid door en leveren een overzicht met concrete stappen, zonder dat uw mensen er iets van merken.
Geef een reactie