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:
Uw gebruikerspersona's 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 perfect niet de vijand van goed zijn" en implementeer zoveel mogelijk veilige toegangsinformatie. Naarmate meer gebruikers zich aanmelden met phishingbestendige wachtwoordloze inloggegevens, verkleint u het aanvalsoppervlak 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 inloggegevens
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.
| Referenties | 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 mobiele toegangsgegevens: |
- Voor nieuwe gebruikers neemt het registratie- en bootstrappingproces een gebruiker zonder bestaande bedrijfsgegevens en verifieert hun identiteit. 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 stelt deze fase gebruikers in staat zich rechtstreeks te registreren voor phishingbestendige, wachtwoordloze methoden op hun bestaande apparaten, of om bestaande MFA-referenties te gebruiken om phishingbestendige, wachtwoordloze referenties in te stellen. 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: Het opstarten van een overdraagbare referentie-sectie.
Voordat u begint, raadt Microsoft aan om toegangssleutels en andere inloggegevens 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 is van plan om ondersteuning voor gesynchroniseerde passkeys toe te voegen. Voor meer informatie, zie Public preview: 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 Verified ID", waarmee een gezichtsherkenningslaag wordt toegevoegd aan de verificatie. Dit zorgt ervoor dat de vertrouwde gebruiker op dat moment de identiteit-bevestigende Verified ID 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 de onboarding van Microsoft Entra Verified ID en de uitgifte van TAP 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: Initialiseer een draagbaar identificatiemiddel
Als u bestaande gebruikers wilt overschakelen naar phishingbestendige en wachtwoordloze referenties, moet u eerst bepalen of uw gebruikers al zijn geregistreerd voor traditionele tweefactorauthenticatie. Gebruikers met traditionele MFA-methoden die zijn geregistreerd, kunnen worden benaderd voor registratiebeleid zonder wachtwoord dat bestand is tegen phishing. 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 inloggegevens | Alternatieve draagbare inloggegevens |
|---|---|---|
| Informatiewerker | Wachtwoordsleutel (Authenticator-app) | Beveiligingssleutel, smartcard |
| Eerstelijnsmedewerker | Beveiligingssleutel | Wachtwoordsleutel (Authenticator-app), smartcard |
| IT-professional/DevOps-medewerker | Wachtwoordsleutel (Authenticator-app) | Beveiligingssleutel, smartcard |
| Sterk gereglementeerde werknemer | Certificaat (smartcard) | Wachtwoordsleutel (Authenticator-app), beveiligingssleutel |
Gebruik de volgende richtlijnen om aanbevolen en alternatieve draagbare inloggegevens te activeren voor de relevante gebruikerspersona's van uw organisatie.
| Wijze | Richtlijn |
|---|---|
| Toegangssleutels | |
| Beveiligingssleutels | |
| Smartcard/verificatie op basis van certificaten (CBA) |
Onboarding stap 3: Configureer lokale inloggegevens op computers
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 inloggegevens de voorkeur heeft voor elke gebruikerspersona. 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 |
|---|---|---|---|---|---|
| Informatiemedewerker | Windows Hello voor Bedrijven | Secure Enclave-sleutel voor eenmalige aanmelding (SSO) van Platform | Wachtwoordsleutel (Authenticator-app) | Wachtwoordsleutel (Authenticator-app) | N.v.t. (gebruik in plaats daarvan draagbare referenties) |
| Eerstelijnsmedewerker | N/B (gebruik in plaats daarvan draagbare referenties) | N/B (gebruik in plaats daarvan draagbare bevoegdheden) | N/B (gebruik in plaats daarvan draagbare referenties) | n.v.t. (gebruik in plaats daarvan draagbare inloggegevens) | N.V.T. (gebruik in plaats daarvan draagbare legitimatie) |
| IT-professional/DevOps-medewerker | Windows Hello voor Bedrijven | Platform SSO Beveiligde Enclave Sleutel | Wachtwoordsleutel (Authenticator-app) | Wachtwoordsleutel (Authenticator-app) | Niet beschikbaar (gebruik in plaats daarvan draagbare referenties) |
| Sterk gereglementeerde werknemer | Windows Hello voor Bedrijven of CBA | Platform SSO Secure Enclave Key en 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 aanmeldgegevens voor uw omgeving in te schakelen voor de relevante gebruikersprofielen van uw organisatie.
| Wijze | Richtlijn |
|---|---|
| Windows Hello voor Bedrijven | |
| Platform SSO Secure Enclave-sleutel | |
| Inlogsleutels |
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-uitrol voor uw pilotgebruikers met behulp van het rapport Authenticatiemethodenactiviteit.
- Maak beleid voor voorwaardelijke toegang om het gebruik van phishingbestendige, wachtwoordloze inlogmethoden af te dwingen voor elk type besturingssysteem, gericht op uw pilotgroep.
- 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 gewoonlijk dat wordt uitgerold naar gebruikers in deze volgorde, 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.
Gereedheid stimuleren met de Phishing-Resistant Werkmap zonder wachtwoord (preview)
Organisaties kunnen er eventueel voor kiezen om hun aanmeldingslogboeken voor Microsoft Entra-id's te exporteren naar Azure Monitor- voor langetermijnretentie, opsporing van bedreigingen en andere doeleinden. Microsoft heeft een werkmap uitgebracht die organisaties met logboeken in Azure Monitor kunnen gebruiken om te helpen bij verschillende fasen van een phishingbestendige implementatie zonder wachtwoord. De Phishing-Resistant werkmap zonder wachtwoord is hier toegankelijk: aka.ms/PasswordlessWorkbook. Kies de werkmap met de titel Phishing-Resistant Implementatie zonder wachtwoord (preview):
De werkmap heeft twee belangrijkste secties:
- Fase gereedheid voor inschrijving
- Fase van afdwingingsgereedheid
Fase gereedheid van inschrijving
Gebruik het tabblad Gereedheidsfase voor inschrijving om aanmeldingslogboeken in uw tenant te analyseren, te bepalen welke gebruikers gereed zijn voor registratie en welke gebruikers mogelijk niet kunnen worden geregistreerd. Met het tabblad Gereedheidsfase voor inschrijving kunt u bijvoorbeeld iOS selecteren als het besturingssysteemplatform en vervolgens Authenticator App Passkey als het type referentie waarvoor u de gereedheid wilt beoordelen. U kunt vervolgens op de werkmapvisualisaties klikken om te filteren op gebruikers die naar verwachting registratieproblemen hebben en de lijst exporteren:
Op het tabblad Inschrijvingsgereedheidsfase van de werkmap kunt u de gereedheid voor de volgende besturingssystemen en inloggegevens evalueren:
- Windows
- Windows Hello voor Bedrijven
- FIDO2-beveiligingssleutel
- Wachtwoordsleutel voor authenticator-app
- Certificate-Based Authenticatie / Smartcard
- macOS
- Platform Single Sign-On (SSO) Secure Enclave Key
- FIDO2-beveiligingssleutel
- Wachtwoordsleutel voor authenticator-app
- Certificate-Based Verificatie/Smartcard
- Ios
- FIDO2-beveiligingssleutel
- Wachtwoordsleutel voor authenticator-app
- Certificate-Based authenticatie/smartcard
- Android
- FIDO2-beveiligingssleutel
- Wachtwoordsleutel voor authenticator-app
- Certificate-Based Verificatie/Smartcard
Gebruik elke geëxporteerde lijst om gebruikers te classificeren die mogelijk registratieproblemen hebben. Antwoorden op registratieproblemen moeten betrekking hebben op het ondersteunen van gebruikers bij het upgraden van besturingssysteemversies van het apparaat, het vervangen van verouderde apparaten en het kiezen van alternatieve referenties waarbij de voorkeursoptie niet haalbaar is. Uw organisatie kan er bijvoorbeeld voor kiezen om fysieke FIDO2-beveiligingssleutels te bieden aan Android 13-gebruikers die geen wachtwoordsleutels kunnen gebruiken in de Microsoft Authenticator-app.
Gebruik ook het rapport gereedheid voor inschrijving om u te helpen bij het uitbouwen van lijsten met gebruikers die klaar zijn om communicatie en campagnes voor inschrijving te starten, in overeenstemming met uw algehele implementatiestrategie.
Gereedheidsfase voor afdwinging
De eerste stap van de fase voor afdwingingsgereedheid is het maken van beleid voor voorwaardelijke toegang in Report-Only modus. Met dit beleid worden uw aanmeldingslogboeken gevuld met gegevens over of de toegang al dan niet zou zijn geblokkeerd als u gebruikers/apparaten binnen het bereik van phishing-bestendige handhaving zou plaatsen. Maak een nieuw beleid voor voorwaardelijke toegang in uw tenant met deze instellingen:
| Instelling | Waarde |
|---|---|
| Toewijzing van gebruiker/groep | Alle gebruikers, met uitzondering van break glass-accounts |
| App-toewijzing | Alle resources |
| Beheerrechten toewijzen | Vereis authenticatiesterkte - Phishingbestendige MFA |
| Beleid inschakelen | Alleen rapport |
Maak dit beleid zo vroeg mogelijk in uw implementatie, bij voorkeur voordat u zelfs begint met uw inschrijvingscampagnes. Dit zorgt ervoor dat u een goede historische gegevensset hebt van gebruikers en aanmeldingen die door het beleid zouden zijn geblokkeerd, als dit was afgedwongen.
Gebruik vervolgens de werkmap om te analyseren waar gebruikers-/apparaatparen gereed zijn voor afdwinging. Download lijsten met gebruikers die klaar zijn voor afdwinging en voeg ze toe aan groepen die zijn gemaakt in overeenstemming met uw afdwingingsbeleid. Selecteer eerst het alleen-lezen beleid voor voorwaardelijke toegang in het beleidsfilter:
Het rapport geeft u een lijst met gebruikers die in staat zouden zijn geweest om de phishing-bestendige vereiste voor gebruik zonder wachtwoord op elk platform voor apparaten succesvol te doorstaan. Download elke lijst en plaats de juiste gebruikers in de afdwingingsgroep die is afgestemd op het apparaatplatform.
Herhaal dit proces na verloop van tijd totdat u het punt bereikt waar elke afdwingingsgroep de meeste of alle gebruikers bevat. Uiteindelijk moet u het beleid voor alleen rapporten kunnen inschakelen om afdwinging te bieden voor alle gebruikers en apparaatplatformen in de tenant. Zodra u deze voltooide status hebt bereikt, kunt u het afzonderlijke afdwingingsbeleid voor elk apparaatbesturingssystemen verwijderen, waardoor het aantal benodigde beleidsregels voor voorwaardelijke toegang wordt verminderd.
Het onderzoeken van gebruikers die niet gereed zijn voor handhaving
Gebruik het tabblad Verdere gegevensanalyse om te onderzoeken waarom bepaalde gebruikers niet klaar zijn voor afdwinging op verschillende platforms. Selecteer het vak Beleid niet tevreden om de gegevens te filteren op aanmeldingen van gebruikers die zouden zijn geblokkeerd door het beleid voor alleen voorwaardelijke toegang voor rapporten.
Gebruik de gegevens die in dit rapport worden verstrekt om te bepalen welke gebruikers zouden zijn geblokkeerd, op welke apparaatbesturingssystemen ze zich bevonden, welk type client-apps ze gebruikten en welke resources ze probeerden te openen. Met deze gegevens kunt u deze gebruikers richten op verschillende herstel- of inschrijvingsacties, zodat ze effectief kunnen worden verplaatst naar het bereik voor afdwinging.
Communicatie van eindgebruikers plannen
Microsoft biedt communicatiesjablonen voor eindgebruikers. Het verificatie-implementatiemateriaal bevat aanpasbare 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:
- Passkeys voor de helpdesk
- wachtwoordsleutels komen binnenkort beschikbaar
- Registreren voor de wachtwoordsleutel van authenticator-app
- Herinnering om u aan te melden voor de beveiligingssleutel van de Authenticator-app
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 voor de handhaving: herhalingsmelding
- 30 dagen voor handhaving: een bericht dat over 30 dagen de phishingbestendige handhaving begint, moedig gebruikers aan zich 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 voor de handhaving: informeer hen dat de handhaving binnen 24 uur zal plaatsvinden, 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 Microsoft Teams-berichten, posters voor pauzeruimtes en ambassadeursprogramma's waarbij bepaalde werknemers worden getraind om het programma aan hun collega's te promoten.
Rapportage en monitoring
Gebruik de eerder besproken Phishing-Resistant werkmap zonder wachtwoord om u te helpen bij het bewaken en rapporteren van uw implementatie. Gebruik ook de onderstaande rapporten of vertrouw erop als u de Phishing-Resistant werkmap zonder wachtwoord niet kunt gebruiken.
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.
- Gebruik toont welke verificatiemethoden zijn gebruikt voor inloggen.
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 wachtwoordloze, phishingbestendige aanmeldgegevens bij met registratieactiviteitenrapporten voor authenticatiemethoden.
- Bijhouden van gebruikersadoptie van phishingbestendige, wachtwoordloze referenties met rapporten en logboeken van aanmeldingsactiviteiten van Authentication Methods.
- 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 maakt een wijziging aan 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.
Helpdesk ticketvolume monitoren
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-15 juni: Uitrol van plaatsing van Wave 1 cohortregistratie en campagnes
- 16-30 juni: Registratie en implementatie van cohort groep 2 en campagnes
- 1 juli-15 juli: Cohortregistratie en campagnes voor de implementatie van Wave 3
- 16 juli-31 juli: Wave 1 cohort afdwingen ingeschakeld
- 1 augustus - 15 augustus: Handhaving van golf 2 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 het toepassen hiervan in Microsoft Entra ID is verificatiesterktes voor voorwaardelijke toegang. 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
- FLWs in Windows en macOS
- IT-professionals op 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 querytools zoals Azure Monitor en Workbooks gebruiken. Probeer minimaal alle gebruikers-/apparaatparen te identificeren die overeenkomen met deze categorieën.
Gebruik indien mogelijk de eerder behandelde Phishing-Resistant werkmap zonder wachtwoord om u te helpen bij de afdwingingsfase.
Maak voor elke gebruiker een lijst met de besturingssystemen die ze regelmatig gebruiken voor werk. Wijs de lijst toe aan de gereedheid voor phishingbestendige aanmeldingsafdwinging voor het gebruikers- en apparaatkoppel.
| Type besturingssysteem | Gereed voor handhaving | 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 inloggegevens in RDP-tunnels (met name voor VDI)
De belangrijkste taak is om door middel van gegevens te meten welke gebruikers en gebruikersprofielen klaar zijn voor handhaving 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. Werk de lijst met gebruikers-/apparaatparen af totdat u overal phishingbestendige authenticatie 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.
Aanbevolen afdwinging van beleidsregels voor voorwaardelijke toegang
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 waar het beleid op is gericht | Beleid : apparaatplatformvoorwaarde | Beleid : beheer verlenen |
|---|---|---|---|
| 1 | Windows-gebruikers die klaar zijn voor wachtwoordloos inloggen met phishing-bestendige middelen | Windows | Verificatiesterkte vereisen : phishingbestendige MFA |
| 2 | Gebruikers van macOS die klaar zijn voor wachtwoordloze, phishingbestendige oplossingen | macOS | Authenticiteitssterkte vereisen van – Phishing-bestendige meervoudige verificatie |
| 3 | iOS-phishingbestendige gebruikers zonder wachtwoord | iOS | Verificatiesterkte vereisen : phishingbestendige MFA |
| 4 | Android-gebruikers klaar voor phishingbestendige, wachtwoordloze omgeving | Android | Verificatiesterkte vereisen - phishing-resistente MFA |
| 5 | Andere phishingbestendige gebruikers die klaar zijn voor een wachtwoordloze aanpak | Alle behalve Windows, macOS, iOS of Android | Authenticatiesterkte vereisen – Phishingbestendige multifactorauthenticatie (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
- Beheerder bevestigde dat de gebruiker is gecompromitteerd
- Afwijkend token
- Schadelijk IP-adres
- Bedreigingsinformatie van Microsoft Entra
- Verdachte browser
- Aanvaller in het midden
- Mogelijke poging om toegang te krijgen tot Primary Refresh Token (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 een hoog risico te blokkeren gebruikers
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 phishingresistente, wachtwoordloze inloggegevens, blijven zich aanvallen en detecties ontwikkelen. Als gebruikersreferenties niet langer eenvoudig kunnen worden gevist, kunnen aanvallers in dat geval proberen 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.