Een phishingbestendige verificatieimplementatie zonder wachtwoord plannen in Microsoft Entra-id
Wanneer u phishingbestendige verificatie zonder wachtwoord implementeert en operationeel maakt in uw omgeving, raden we een op gebruikers persoonlijk gebaseerde benadering aan. Verschillende phishingbestendige methoden zonder wachtwoord zijn effectiever dan andere methoden voor bepaalde gebruikerspersoons. Deze implementatiehandleiding helpt u te zien welke typen methoden en implementatieplannen zinvol zijn voor gebruikerspersoons in uw omgeving. De phishingbestendige implementatiemethode zonder wachtwoord heeft meestal 6 stappen, die ongeveer in volgorde stromen, maar niet 100% hoeven te worden voltooid voordat u verdergaat met andere stappen:
De persona's van uw gebruiker bepalen
Bepaal de persona's van de gebruiker die relevant zijn voor uw organisatie. Deze stap is essentieel voor uw project omdat verschillende persona's verschillende behoeften hebben. Microsoft raadt u aan om ten minste 4 algemene persona's van gebruikers in uw organisatie te overwegen en te evalueren.
| Gebruikerspersona | Beschrijving |
|---|---|
| Informatiemedewerkers | |
| Frontlinewerkers | |
| IT-professionals/DevOps-werknemers | |
| Sterk gereglementeerde werknemers |
Microsoft raadt u aan om phishingbestendige verificatie zonder wachtwoord breed te implementeren in uw organisatie. Informatiewerkers zijn traditioneel de eenvoudigste gebruikerspersoon om mee te beginnen. Stel de implementatie van beveiligde referenties voor informatiewerkers niet uit terwijl u problemen oplost die van invloed zijn op IT-professionals. Neem de aanpak van 'laat niet perfect de vijand van goed zijn' en implementeer zo veel mogelijk veilige referenties. Naarmate meer gebruikers zich aanmelden met phishingbestendige referenties zonder wachtwoord, vermindert u het kwetsbaarheid voor aanvallen van uw omgeving.
Microsoft raadt u aan uw persona's te definiëren en vervolgens elke persona in een Microsoft Entra-id-groep te plaatsen die specifiek is bedoeld voor die persona van de gebruiker. Deze groepen worden in latere stappen gebruikt om referenties uit te rollen voor verschillende typen gebruikers en wanneer u het gebruik van phishingbestendige referenties zonder wachtwoord afdwingt.
Apparaatgereedheid plannen
Apparaten zijn een essentieel aspect van een geslaagde, phishingbestendige implementatie zonder wachtwoord, omdat een van de doelen van phishingbestendige wachtwoordloze referenties is om referenties te beveiligen met de hardware van moderne apparaten. Maak eerst kennis met fido2-ondersteuning voor Microsoft Entra-id.
Zorg ervoor dat uw apparaten zijn voorbereid op phishing-bestendig wachtwoordloos door patches uit te voeren op de nieuwste ondersteunde versies van elk besturingssysteem. Microsoft raadt uw apparaten aan om deze versies minimaal uit te voeren:
- Windows 10 22H2 (voor Windows Hello voor Bedrijven)
- Windows 11 22H2 (voor de beste gebruikerservaring bij het gebruik van wachtwoordsleutels)
- macOS 13 Ventura
- iOS 17
- Android 14
Deze versies bieden de beste ondersteuning voor systeemeigen geïntegreerde functies, zoals wachtwoordsleutels, Windows Hello voor Bedrijven en macOS-platformreferenties. Oudere besturingssystemen vereisen mogelijk externe verificators, zoals FIDO2-beveiligingssleutels, ter ondersteuning van phishingbestendige verificatie zonder wachtwoord.
Gebruikers registreren voor phishingbestendige referenties
Referentieregistratie en bootstrapping zijn de eerste belangrijke activiteiten voor eindgebruikers in uw project voor phishing-bestendige implementatie zonder wachtwoord. In deze sectie wordt de implementatie van draagbare en lokale referenties beschreven.
| Referentie | Beschrijving | Vergoedingen |
|---|---|---|
| Draagbaar | Kan worden gebruikt op verschillende apparaten. U kunt draagbare referenties gebruiken om u aan te melden bij een ander apparaat of om referenties te registreren op andere apparaten. | Het belangrijkste type referentie dat voor de meeste gebruikers moet worden geregistreerd, omdat ze op meerdere apparaten kunnen worden gebruikt en phishingbestendige verificatie in veel scenario's kan bieden. |
| Lokaal | U kunt lokale referenties gebruiken om te verifiëren op een apparaat zonder gebruik te hoeven maken van externe hardware, zoals het gebruik van Windows Hello voor Bedrijven biometrische herkenning om u aan te melden bij een app in de Microsoft Edge-browser op dezelfde pc | Ze hebben twee belangrijke voordelen ten opzichte van de draagbare referenties: |
- Voor nieuwe gebruikers neemt het registratie- en bootstrappingproces een gebruiker zonder bestaande bedrijfsreferenties en verifieert de identiteit ervan. Het bootstrapt ze in hun eerste draagbare referentie en gebruikt die draagbare referentie om andere lokale referenties op elk van hun computerapparaten te bootstrapen. Na de registratie kan de beheerder phishingbestendige verificatie afdwingen voor gebruikers in Microsoft Entra ID.
- Voor bestaande gebruikers krijgt deze fase gebruikers de opdracht om zich rechtstreeks te registreren voor phishingbestendige wachtwoorden op hun bestaande apparaten of om bestaande MFA-referenties te gebruiken om phishingbestendige referenties zonder wachtwoord op te starten. Het einddoel is hetzelfde als nieuwe gebruikers: de meeste gebruikers moeten ten minste één draagbare referentie hebben en vervolgens lokale referenties op elk computerapparaat. Als u een beheerder bent die phishingbestendig wachtwoordloos implementeert voor bestaande gebruikers, kunt u misschien verdergaan met de onboardingstap 2: een sectie Overdraagbare referenties opstarten.
Voordat u begint, raadt Microsoft aan wachtwoordsleutel en andere referenties in te schakelen voor zakelijke gebruikers in de tenant. Als gebruikers gemotiveerd zijn om zich zelf te registreren voor sterke referenties, is het handig om dit toe te staan. U moet minimaal het FIDO2-beleid (Passkey) inschakelen, zodat gebruikers zich kunnen registreren voor wachtwoordsleutels en beveiligingssleutels als ze dat liever hebben.
Deze sectie is gericht op fasen 1-3:
Gebruikers moeten ten minste twee verificatiemethoden hebben geregistreerd. Wanneer een andere methode is geregistreerd, heeft de gebruiker een back-upmethode die beschikbaar is als er iets gebeurt met de primaire methode, bijvoorbeeld wanneer een apparaat verloren gaat of wordt gestolen. Het is bijvoorbeeld een goede gewoonte dat gebruikers wachtwoordsleutels hebben geregistreerd op hun telefoon en lokaal op hun werkstation in Windows Hello voor Bedrijven.
Notitie
Het wordt altijd aanbevolen dat gebruikers ten minste twee verificatiemethoden hebben geregistreerd. Dit zorgt ervoor dat de gebruiker een back-upmethode heeft die beschikbaar is als er iets gebeurt met de primaire methode, zoals in gevallen van apparaatverlies of diefstal. Het is bijvoorbeeld een goede gewoonte dat gebruikers wachtwoordsleutels hebben geregistreerd op hun telefoon en lokaal op hun werkstation in Windows Hello voor Bedrijven.
Notitie
Deze richtlijnen zijn afgestemd op bestaande ondersteuning voor wachtwoordsleutels in Microsoft Entra ID, waaronder apparaatgebonden wachtwoordsleutels in Microsoft Authenticator en apparaatgebonden wachtwoordsleutels op fysieke beveiligingssleutels. Microsoft Entra ID-abonnementen voor het toevoegen van ondersteuning voor gesynchroniseerde wachtwoordsleutels. Zie Openbare preview voor meer informatie : Uitbreiding van ondersteuning voor wachtwoordsleutels in Microsoft Entra-id. Deze handleiding wordt bijgewerkt met gesynchroniseerde richtlijnen voor wachtwoordsleutels zodra deze beschikbaar zijn. Veel organisaties kunnen bijvoorbeeld profiteren van synchronisatie voor fase 3 in het voorgaande diagram in plaats van volledig nieuwe referenties op te slaan.
Onboarding stap 1: Identiteitsverificatie
Voor externe gebruikers die hun identiteit niet hebben bewezen, is onboarding van ondernemingen een belangrijke uitdaging. Zonder de juiste identiteitsverificatie kan een organisatie niet volledig zeker zijn dat ze de persoon onboarden die ze van plan zijn. Microsoft Entra geverifieerde ID kan verificatie van identiteiten met hoge zekerheid bieden. Organisaties kunnen samenwerken met een idV (Identity Verification Partner) om de identiteiten van nieuwe externe gebruikers in het onboardingproces te verifiëren. Nadat de door de overheid uitgegeven id van een gebruiker is verwerkt, kan de IDV een geverifieerde id opgeven die de identiteit van de gebruiker bevestigt. De nieuwe gebruiker presenteert deze identiteit bevestigende geverifieerde id aan de wervingsorganisatie om een vertrouwensrelatie tot stand te brengen en te bevestigen dat de organisatie de juiste persoon onboardt. Organisaties kunnen Face Check toevoegen met Microsoft Entra geverifieerde ID waarmee een gezichtskoppelingslaag wordt toegevoegd aan de verificatie, zodat de vertrouwde gebruiker de geverifieerde id op dat moment presenteert.
Na het verifiëren van hun identiteit via het controleproces krijgen nieuwe medewerkers een tijdelijke toegangspas (TAP) die ze kunnen gebruiken om hun eerste draagbare referentie te bootstrapen.
Raadpleeg de volgende handleidingen om Microsoft Entra geverifieerde ID onboarding en TAP-uitgifte in te schakelen:
- Nieuwe externe werknemers onboarden met id-verificatie
- Face Check gebruiken met Microsoft Entra geverifieerde ID om verificaties met hoge zekerheid op schaal te ontgrendelen
- Het beleid voor tijdelijke toegangspas inschakelen
Raadpleeg de volgende koppelingen voor licentiedetails voor Microsoft Entra geverifieerde ID:
Sommige organisaties kunnen andere methoden kiezen dan Microsoft Entra geverifieerde ID om gebruikers te onboarden en hun eerste referentie uit te geven. Microsoft raadt deze organisaties aan nog steeds TAP's te gebruiken of een andere manier waarmee een gebruiker zonder wachtwoord kan onboarden. U kunt bijvoorbeeld FIDO2-beveiligingssleutels inrichten met behulp van Microsoft Graph API.
Onboarding stap 2: Bootstrap een draagbare referentie
Als u bestaande gebruikers wilt opstarten voor phishingbestendige referenties zonder wachtwoord, moet u eerst bepalen of uw gebruikers al zijn geregistreerd voor traditionele MFA. Gebruikers met traditionele MFA-methoden die zijn geregistreerd, kunnen worden gericht op phishingbestendig registratiebeleid zonder wachtwoord. Ze kunnen hun traditionele MFA gebruiken om zich te registreren voor hun eerste draagbare phishing-bestendige referentie en vervolgens zo nodig verder om zich te registreren voor lokale referenties.
Voor nieuwe gebruikers of gebruikers zonder MFA voert u een proces uit om gebruikers een tijdelijke toegangspas (TAP) uit te geven. U kunt een TAP op dezelfde manier uitgeven als u nieuwe gebruikers hun eerste referentie geeft of door gebruik te maken van Microsoft Entra geverifieerde ID-integraties. Zodra gebruikers een TAP hebben, kunnen ze hun eerste phishingbestendige referentie opstarten.
Het is belangrijk dat de eerste wachtwoordloze referentie van de gebruiker een draagbare referentie is die kan worden gebruikt voor verificatie op andere computerapparaten. Wachtwoordsleutels kunnen bijvoorbeeld worden gebruikt om lokaal te verifiëren op een iOS-telefoon, maar ze kunnen ook worden gebruikt om te verifiëren op een Windows-pc met behulp van een verificatiestroom voor meerdere apparaten. Met deze mogelijkheid voor meerdere apparaten kan draagbare wachtwoordsleutel worden gebruikt om Windows Hello voor Bedrijven op de Windows-pc te bootstrapen.
Het is ook belangrijk dat elk apparaat waarop de gebruiker regelmatig werkt, een lokaal beschikbare referentie heeft om de gebruiker de soepelste gebruikerservaring te bieden. Lokaal beschikbare referenties verminderen de tijd die nodig is om te verifiëren, omdat gebruikers niet meerdere apparaten hoeven te gebruiken en er minder stappen zijn. Als u de TAP van stap 1 gebruikt om een draagbare referentie te registreren waarmee deze andere referenties kunnen worden opgestart, kan de gebruiker phishingbestendige referenties gebruiken op de vele apparaten die ze mogelijk bezitten.
De volgende tabel bevat aanbevelingen voor verschillende persona's:
| Persona van gebruiker | Aanbevolen draagbare referentie | Alternatieve draagbare referenties |
|---|---|---|
| Informatieverwerking | Wachtwoordsleutel (Authenticator-app) | Beveiligingssleutel, smartcard |
| Eerstelijnsmedewerker | Beveiligingssleutel | Wachtwoordsleutel (Authenticator-app), smartcard |
| IT-professional/DevOps-werkrol | Wachtwoordsleutel (Authenticator-app) | Beveiligingssleutel, smartcard |
| Sterk gereglementeerde werknemer | Certificaat (smartcard) | Wachtwoordsleutel (Authenticator-app), beveiligingssleutel |
Gebruik de volgende richtlijnen om aanbevolen en alternatieve draagbare referenties in te schakelen voor de relevante gebruikerspersoons voor uw organisatie:
| Wijze | Richtlijn |
|---|---|
| Sleutels | |
| Beveiligingssleutels | |
| Smartcard/verificatie op basis van certificaten (CBA) |
Onboarding stap 3: Bootstrap lokale referenties op computerapparaten
Nadat gebruikers een draagbare referentie hebben geregistreerd, kunnen ze andere referenties opstarten op elk computerapparaat dat ze regelmatig gebruiken in een 1:1-relatie, wat hun dagelijkse gebruikerservaring ten goede komt. Dit type referentie is gebruikelijk voor informatiewerkers en IT-professionals, maar niet voor frontlinemedewerkers die apparaten delen. Gebruikers die alleen apparaten delen, mogen alleen draagbare referenties gebruiken.
Uw organisatie moet in deze fase bepalen welk type referentie de voorkeur heeft voor elke persona van de gebruiker. Microsoft raadt het volgende aan:
| Gebruikerspersona | Aanbevolen lokale referentie - Windows | Aanbevolen lokale referentie - macOS | Aanbevolen lokale referentie - iOS | Aanbevolen lokale referentie - Android | Aanbevolen lokale referentie - Linux |
|---|---|---|---|---|---|
| Informatieverwerking | Windows Hello voor Bedrijven | Secure Enclave-sleutel voor eenmalige aanmelding (SSO) van Platform | Wachtwoordsleutel (Authenticator-app) | Wachtwoordsleutel (Authenticator-app) | N/B (gebruik in plaats daarvan draagbare referenties) |
| Eerstelijnsmedewerker | N/B (gebruik in plaats daarvan draagbare referenties) | N/B (gebruik in plaats daarvan draagbare referenties) | N/B (gebruik in plaats daarvan draagbare referenties) | N/B (gebruik in plaats daarvan draagbare referenties) | N/B (gebruik in plaats daarvan draagbare referenties) |
| IT-professional/DevOps-werkrol | Windows Hello voor Bedrijven | Platform SSO Secure Enclave Key | Wachtwoordsleutel (Authenticator-app) | Wachtwoordsleutel (Authenticator-app) | N/B (gebruik in plaats daarvan draagbare referenties) |
| Sterk gereglementeerde werknemer | Windows Hello voor Bedrijven of CBA | Platform SSO Secure Enclave Key of CBA | Wachtwoordsleutel (Authenticator-app) of CBA | Wachtwoordsleutel (Authenticator-app) of CBA | N.u.b. (gebruik in plaats daarvan smartcard) |
Gebruik de volgende richtlijnen om de aanbevolen lokale referenties in uw omgeving in te schakelen voor de relevante persona's van gebruikers voor uw organisatie:
| Wijze | Richtlijn |
|---|---|
| Windows Hello voor Bedrijven | |
| Platform SSO Secure Enclave Key | |
| Sleutels |
Persona-specifieke overwegingen
Elke persona heeft zijn eigen uitdagingen en overwegingen die vaak optreden tijdens phishingbestendige implementaties zonder wachtwoord. Als u weet welke persona's u nodig hebt, moet u rekening houden met deze overwegingen in de planning van uw implementatieproject. De volgende koppelingen bevatten specifieke richtlijnen voor elke persona:
- Informatiewerkers
- Frontlinewerkers
- IT-professionals/DevOps-werknemers
- Sterk gereglementeerde werknemers
Gebruik van phishingbestendige referenties stimuleren
In deze stap wordt beschreven hoe gebruikers gemakkelijker phishing-bestendige referenties kunnen gebruiken. U moet uw implementatiestrategie testen, de implementatie plannen en het plan doorgeven aan eindgebruikers. Vervolgens kunt u rapporten maken en de voortgang bewaken voordat u phishingbestendige referenties in uw organisatie afdwingt.
Implementatiestrategie testen
Microsoft raadt u aan de implementatiestrategie te testen die in de vorige stap is gemaakt met een set test- en testgebruikers. Deze fase moet de volgende stappen bevatten:
- Maak een lijst met testgebruikers en early adopters. Deze gebruikers moeten uw verschillende persona's van gebruikers vertegenwoordigen, en niet alleen IT-beheerders.
- Maak een Microsoft Entra-id-groep en voeg uw testgebruikers toe aan de groep.
- Schakel het beleid voor verificatiemethoden in microsoft Entra-id in en beperk de testgroep tot de methoden die u inschakelt.
- Meet de registratie-implementatie voor uw testgebruikers met behulp van het rapport Verificatiemethodenactiviteit .
- Maak beleid voor voorwaardelijke toegang om de phishingbestendige referenties zonder wachtwoord af te dwingen voor elk type besturingssysteem en richt u op uw testgroep.
- Meet het succes van de afdwinging met behulp van Azure Monitor en Workbooks.
- Verzamel feedback van gebruikers over het succes van de implementatie.
Implementatiestrategie plannen
Microsoft raadt aan om het gebruik te stimuleren op basis van welke persona's van gebruikers het meest gereed zijn voor implementatie. Dit betekent doorgaans dat gebruikers in deze volgorde worden geïmplementeerd, maar dit kan veranderen, afhankelijk van uw organisatie:
- Informatiemedewerkers
- Frontlinewerkers
- IT-professionals/DevOps-werknemers
- Sterk gereglementeerde werknemers
Gebruik de volgende secties om communicatie van eindgebruikers te maken voor elke personagroep, het bereik en de implementatie van de registratiefunctie voor wachtwoordsleutels, en rapportage en bewaking van gebruikers om de voortgang van de implementatie bij te houden.
Communicatie van eindgebruikers plannen
Microsoft biedt communicatiesjablonen voor eindgebruikers. Het implementatiemateriaal voor verificatie omvat aanpasbare posters en e-mailsjablonen om gebruikers te informeren over de implementatie van verificatie zonder wachtwoorden die bestand zijn tegen phishing. Gebruik de volgende sjablonen om uw gebruikers te laten communiceren zodat ze inzicht hebben in de phishing-bestendige implementatie zonder wachtwoord:
- Aanmelden zonder wachtwoord met Microsoft Authenticator
- De verificatiemethode voor wachtwoordherstel registreren voor een werk- of schoolaccount
- Uw werk- of schoolwachtwoord opnieuw instellen met beveiligingsgegevens
- Een beveiligingssleutel instellen als uw verificatiemethode
- Meld u aan bij uw accounts met behulp van de Microsoft Authenticator-app
- Meld u aan bij uw werk- of schoolaccount met behulp van uw verificatiemethode in twee stappen
- Aanmelding van werk- of schoolaccount geblokkeerd door tenantbeperkingen
Communicatie moet meerdere keren worden herhaald om zoveel mogelijk gebruikers te helpen vangen. Uw organisatie kan er bijvoorbeeld voor kiezen om de verschillende fasen en tijdlijnen met een patroon als volgt te communiceren:
- 60 dagen na afdwingen: de waarde van phishingbestendige verificatiemethoden melden en gebruikers aanmoedigen om proactief in te schrijven
- 45 dagen na afdwingen: herhalingsbericht
- 30 dagen na afdwinging: bericht dat binnen 30 dagen phishingbestendige afdwinging begint, moedig gebruikers aan proactief in te schrijven
- 15 dagen na afdwinging: herhalingsbericht, hen informeren hoe ze contact kunnen opnemen met de helpdesk
- 7 dagen na afdwinging: herhaal het bericht, informeer hen over hoe ze contact kunnen opnemen met de helpdesk
- 1 dag van afdwinging: informeer hen over 24 uur, informeer hen over hoe ze contact kunnen opnemen met de helpdesk
Microsoft raadt aan gebruikers te communiceren via andere kanalen dan alleen e-mail. Andere opties zijn onder andere Berichten van Microsoft Teams, posters voor brainstormruimten en kampioenprogramma's waarbij bepaalde werknemers worden getraind om het programma aan hun collega's te bevorderen.
Rapportage en bewaking
Microsoft Entra ID-rapporten (zoals verificatiemethodenactiviteit en aanmeldingsgebeurtenisdetails voor Microsoft Entra multifactor-verificatie) bieden technische en zakelijke inzichten die u kunnen helpen bij het meten en stimuleren van acceptatie.
Via het activiteitendashboard verificatiemethoden kunt u de registratie en het gebruik bekijken.
- Registratie toont het aantal gebruikers dat geschikt is voor phishing-bestendige verificatie zonder wachtwoord en andere verificatiemethoden. U kunt grafieken zien die aangeven welke verificatiemethoden gebruikers hebben geregistreerd en recente registratie voor elke methode.
- In het gebruik ziet u welke verificatiemethoden zijn gebruikt voor aanmelding.
Eigenaren van zakelijke en technische toepassingen moeten eigenaar zijn van en rapporten ontvangen op basis van de vereisten van de organisatie.
- Houd de implementatie van phishingbestendige referenties zonder wachtwoord bij met registratieactiviteitenrapporten voor verificatiemethoden.
- Gebruikersacceptatie van phishingbestendige referenties zonder wachtwoord bijhouden met aanmeldingsactiviteitenrapporten van verificatiemethoden en aanmeldingslogboeken.
- Gebruik het rapport voor aanmeldactiviteit om de verificatiemethoden bij te houden die worden gebruikt voor aanmelding bij de verschillende toepassingen. Selecteer de gebruikersrij; selecteer Verificatiedetails om de verificatiemethode en de bijbehorende aanmeldingsactiviteit weer te geven.
Microsoft Entra ID voegt vermeldingen toe aan auditlogboeken wanneer deze voorwaarden optreden:
- Een beheerder wijzigt verificatiemethoden.
- Een gebruiker wijzigt elk soort wijziging in zijn referenties in Microsoft Entra-id.
Microsoft Entra ID bewaart de meeste controlegegevens gedurende 30 dagen. We raden u aan om langer te bewaren voor controle, trendanalyse en andere zakelijke behoeften.
Toegang tot controlegegevens in het Microsoft Entra-beheercentrum of API en download naar uw analysesystemen. Als u langere retentie nodig hebt, exporteert en gebruikt u logboeken in een SIEM-hulpprogramma (Security Information and Event Management), zoals Microsoft Sentinel, Splunk of Sumo Logic.
Helpdeskticketvolume bewaken
Uw IT-helpdesk kan een waardevol signaal geven over hoe goed uw implementatie vordert, dus Microsoft raadt u aan uw helpdeskticketvolume bij te houden bij het uitvoeren van een phishingbestendige implementatie zonder wachtwoord.
Naarmate uw helpdeskticketvolume toeneemt, moet u het tempo van uw implementaties, gebruikerscommunicatie en afdwingingsacties vertragen. Naarmate het ticketvolume afneemt, kunt u deze activiteiten weer omhoog instellen. Als u deze aanpak gebruikt, moet u de flexibiliteit in uw implementatieplan behouden.
U kunt bijvoorbeeld uw implementaties uitvoeren en vervolgens afdwingen in golven met datumbereiken in plaats van specifieke datums:
- 1 juni-15th: Wave 1 cohort registratie implementatie en campagnes
- 16 juni-30th: Wave 2 cohort registratie implementatie en campagnes
- 1 juli-15 juli: Implementatie en campagnes van cohortregistratie wave 3
- 16 juli-31 juli: Wave 1 cohort afdwinging ingeschakeld
- 1 augustus-15th: Wave 2 cohort afdwinging ingeschakeld
- 16 augustus-31 augustus: Wave 3 cohort afdwinging ingeschakeld
Wanneer u deze verschillende fasen uitvoert, moet u mogelijk vertragen, afhankelijk van het aantal geopende helpdesktickets en vervolgens hervatten wanneer het volume is afgebroken. Als u deze strategie wilt uitvoeren, raadt Microsoft u aan om voor elke golf een Microsoft Entra ID-beveiligingsgroep te maken en elke groep één voor één toe te voegen aan uw beleid. Deze aanpak helpt om te voorkomen dat uw ondersteuningsteams overweldigd worden.
Phishingbestendige methoden afdwingen voor aanmelding
Deze sectie is gericht op fase 4.
De laatste fase van een phishingbestendige implementatie zonder wachtwoord dwingt het gebruik van phishingbestendige referenties af. Het primaire mechanisme voor dit doen in Microsoft Entra ID is sterke punten voor voorwaardelijke toegangsverificatie. Microsoft raadt u aan om afdwinging voor elke persona te benaderen op basis van een methode voor het koppelen van gebruikers/apparaten. Een implementatie voor afdwinging kan bijvoorbeeld het volgende patroon volgen:
- Informatiewerkers in Windows en iOS
- Informatiewerkers op macOS en Android
- IT-professionals op iOS en Android
- FLW's op iOS en Android
- FLW's in Windows en macOS
- IT-professionals in Windows en macOS
Microsoft raadt u aan een rapport te maken van al uw gebruikers-/apparaatparen met behulp van aanmeldingsgegevens van uw tenant. U kunt query's zoals Azure Monitor en Workbooks gebruiken. Probeer minimaal alle gebruikers-/apparaatparen te identificeren die overeenkomen met deze categorieën.
Maak voor elke gebruiker een lijst met de besturingssystemen die ze regelmatig gebruiken voor werk. Wijs de lijst toe aan de gereedheid voor phishingbestendige afdwinging van aanmeldingen voor dat gebruiker/apparaatpaar.
| Type besturingssysteem | Gereed voor afdwinging | Niet gereed voor afdwinging |
|---|---|---|
| Windows | 10+ | 8.1 en eerder, Windows Server |
| iOS | 17+ | 16 en eerder |
| Android | 14+ | 13 en eerder |
| macOS | 13+ (Ventura) | 12 en eerder |
| VDI | Afhankelijk van1 | Afhankelijk van1 |
| Overige | Afhankelijk van1 | Afhankelijk van1 |
1Voor elk gebruiker/apparaatpaar waarbij de apparaatversie niet onmiddellijk gereed is voor afdwinging, bepaalt u hoe u moet omgaan met de noodzaak om phishing-weerstand af te dwingen. Bekijk de volgende opties voor oudere besturingssystemen, VDI (Virtual Desktop Infrastructure) en andere besturingssystemen, zoals Linux:
- Phishing-weerstand afdwingen met behulp van externe hardware - FIDO2-beveiligingssleutels
- Phishing-weerstand afdwingen met behulp van externe hardware - smartcards
- Phishing-weerstand afdwingen met behulp van externe referenties, zoals wachtwoordsleutels in de verificatiestroom voor meerdere apparaten
- Phishing-weerstand afdwingen met behulp van externe referenties in RDP-tunnels (met name voor VDI)
De belangrijkste taak is om te meten via gegevens die gebruikers en persona's gereed zijn voor afdwinging op bepaalde platforms. Begin met uw afdwingingsacties op gebruikers-/apparaatparen die gereed zijn voor afdwinging om het bloeden te stoppen en de hoeveelheid phishing-verificatie in uw omgeving te verminderen.
Ga vervolgens verder met andere scenario's waarbij de gebruikers-/apparaatparen gereedheidsinspanningen vereisen. Doorloop de lijst met gebruikers-/apparaatparen totdat u phishingbestendige verificatie aan de hele kant van het bord afdwingt.
Maak een set Microsoft Entra ID-groepen om afdwinging geleidelijk uit te rollen. Gebruik de groepen uit de vorige stap opnieuw als u de implementatiebenadering op basis van golf hebt gebruikt.
Richt elke groep op met een specifiek beleid voor voorwaardelijke toegang. Deze aanpak helpt u bij het geleidelijk implementeren van uw afdwingingsbesturingselementen per gebruiker/apparaatpaar.
| Beleid | Groepsnaam gericht op het beleid | Beleid : apparaatplatformvoorwaarde | Beleid : beheer verlenen |
|---|---|---|---|
| 1 | Windows phishing-bestendige gebruikers zonder wachtwoord | Windows | Verificatiesterkte vereisen : phishingbestendige MFA |
| 2 | phishingbestendige macOS-gebruikers zonder wachtwoord | macOS | Verificatiesterkte vereisen : phishingbestendige MFA |
| 3 | iOS-phishingbestendige gebruikers zonder wachtwoord | iOS | Verificatiesterkte vereisen : phishingbestendige MFA |
| 4 | Android-phishingbestendige gebruikers zonder wachtwoord | Android | Verificatiesterkte vereisen : phishingbestendige MFA |
| 5 | Andere phishingbestendige gebruikers zonder wachtwoord | Alle behalve Windows, macOS, iOS of Android | Verificatiesterkte vereisen : phishingbestendige MFA |
Voeg elke gebruiker toe aan elke groep terwijl u bepaalt of het apparaat en besturingssysteem gereed zijn of dat ze geen apparaat van dat type hebben. Aan het einde van de implementatie moet elke gebruiker zich in een van de groepen bevinden.
Reageren op risico voor gebruikers zonder wachtwoord
Microsoft Entra ID Protection helpt organisaties bij het detecteren, onderzoeken en oplossen van identiteitsrisico's. Microsoft Entra ID Protection biedt belangrijke en nuttige detecties voor uw gebruikers, zelfs nadat ze overschakelen naar het gebruik van phishingbestendige referenties zonder wachtwoord. Enkele relevante detecties voor phishingbestendige gebruikers zijn bijvoorbeeld:
- Activiteit vanaf anoniem IP-adres
- Door beheerder bevestigd misbruik van gebruiker
- Afwijkend token
- Schadelijk IP-adres
- Bedreigingsinformatie van Microsoft Entra
- Verdachte browser
- Aanvaller in het midden
- Mogelijke poging om toegang te krijgen tot primaire vernieuwingstoken (PRT)
- En andere: Risicodetecties die zijn toegewezen aan riskEventType
Microsoft raadt klanten van Microsoft Entra ID Protection aan de volgende acties uit te voeren om hun phishingbestendige gebruikers zonder wachtwoord te beschermen:
- Bekijk de implementatierichtlijnen voor Microsoft Entra ID Protection: Een id-beveiligingsimplementatie plannen
- Uw risicologboeken configureren om te exporteren naar een SIEM
- Onderzoek en actie ondernemen op risico's van middelgrote gebruikers
- Een beleid voor voorwaardelijke toegang configureren om gebruikers met een hoog risico te blokkeren
Nadat u Microsoft Entra ID Protection hebt geïmplementeerd, kunt u overwegen om beveiliging van tokens voor voorwaardelijke toegang te gebruiken. Wanneer gebruikers zich aanmelden met phishingbestendige referenties zonder wachtwoord, blijven aanvallen en detecties zich verder ontwikkelen. Wanneer gebruikersreferenties bijvoorbeeld niet meer eenvoudig kunnen worden gefprofiteerd, kunnen aanvallers doorgaan om tokens van gebruikersapparaten te exfiltreren. Tokenbeveiliging helpt dit risico te beperken door tokens te binden aan de hardware van het apparaat waarop ze zijn uitgegeven.