Notitie
Voor toegang tot deze pagina is autorisatie vereist. U kunt proberen u aan te melden of de directory te wijzigen.
Voor toegang tot deze pagina is autorisatie vereist. U kunt proberen de mappen te wijzigen.
Wanneer u phishingbestendige verificatie zonder wachtwoord implementeert en operationeel maakt in uw omgeving, raden we een op gebruikerspersoon gebaseerde benadering aan, maar dit kan variëren, afhankelijk van andere aspecten, zoals de branche waarin u zich bevindt en het budget dat u mogelijk hebt. Deze implementatiehandleiding helpt u te zien welke typen methoden en implementatieplannen zinvol zijn voor gebruikers in uw organisatie. De phishingbestendige implementatiemethode zonder wachtwoord heeft meerdere stappen, maar hoeft niet 100% voltooid te zijn 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 de volgende gebruikerspersoons in uw organisatie te overwegen en te evalueren.
| Gebruikerspersona | Beschrijving |
|---|---|
| Beheerders en sterk gereglementeerde gebruikers | |
| Niet-beheerders |
Microsoft raadt u aan om phishingbestendige verificatie zonder wachtwoord breed te implementeren in uw organisatie. U wordt aangeraden eerst uw implementatie te starten met een van de persona's van de gebruiker.
Microsoft raadt u aan uw gebruikers te categoriseren op basis van deze persona's en vervolgens gebruikers 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.
Met behulp van groepen kunt u nieuwe onderdelen van de organisatie tegelijkertijd blijven onboarden. 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.
Apparaatgereedheid plannen
Apparaten zijn een essentieel aspect van een geslaagde, phishingbestendige implementatie zonder wachtwoord. Om ervoor te zorgen dat uw apparaten zijn voorbereid op phishingbestendig wachtwoordloos, patcht u de nieuwste ondersteunde versies van elk besturingssysteem. Als u phishingbestendige referenties wilt gebruiken, moeten op uw apparaten minimaal de volgende versies worden uitgevoerd:
- 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 zijn natuurlijk geïntegreerd met functies zoals passkeys, Windows Hello voor Bedrijven en macOS Platform Credential. Oudere besturingssystemen vereisen mogelijk externe verificators, zoals FIDO2-beveiligingssleutels, ter ondersteuning van phishingbestendige verificatie zonder wachtwoord.
Voor meer informatie kunt u vertrouwd raken met fido2-ondersteuning voor Microsoft Entra-id. U kunt het phishingbestendige wachtwoordloze werkboek (Voorbeeld) gebruiken om inzicht te krijgen in de gereedheid van apparaten binnen uw tenant.
Phishing-bestendig traject
Als onderdeel van uw implementatie van phishingbestendige referenties moet u overwegen hoe gebruikers worden toegevoegd, hoe ze hun draagbare en lokale referenties verkrijgen en hoe phishingbestendige referenties worden afgedwongen in uw organisatie.
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.
In de onderstaande tabel vindt u de verschillende typen referenties en de bijbehorende verificatiemethoden die kunnen worden geconfigureerd in Microsoft Entra-id.
| Inloggegevens | Beschrijving | Vergoedingen | Verificatiemethoden |
|---|---|---|---|
| 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 dat u op externe hardware hoeft te vertrouwen. | Lokale referenties bieden een uitstekende gebruikerservaring, omdat de gebruiker het apparaat niet hoeft te verlaten om succesvol te verifiëren met behulp van de ontgrendelingsbeweging van het eigen apparaat, zoals Face ID of Windows Hello voor Bedrijven met gezichtsherkenning/vingerafdruk/pincode. |
- Voor nieuwe gebruikers zorgt het registratie- en bootstrappingproces ervoor dat zij geen bestaande bedrijfsreferenties nodig hebben 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 moeten ze zich registreren voor phishingbestendig inloggen zonder wachtwoord op hun bestaande apparaten, of met behulp van bestaande MFA-gegevens om phishingbestendige, wachtwoordloze referenties op te zetten.
Het einddoel is hetzelfde voor beide typen gebruikers: de meeste gebruikers moeten ten minste één draagbare referentie hebben en vervolgens lokale referenties op elk computerapparaat.
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 voor gebruikers om een wachtwoordsleutel te registreren en een lokale referentie zoals Windows Hello voor Bedrijven op hun werkstation
Stap 1: Identiteitsverificatie
Voor externe gebruikers die hun identiteit niet hebben bewezen, zoals nieuwe medewerkers, is onboarding voor 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 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) waarmee ze hun eerste draagbare referentie kunnen opzetten.
Raadpleeg de volgende handleidingen om de onboarding van Microsoft Entra geverifieerde 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:
- Prijzen voor Face Check met Microsoft Entra geverifieerde ID
- Microsoft Entra-abonnementen en -prijzen
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.
Stap 2: Bootstrap een draagbare identiteit
Om bestaande gebruikers over te zetten naar phishingbestendige, wachtwoordloze referenties, moet u eerst vaststellen of uw gebruikers al zijn geregistreerd voor traditionele Multi-Factor Authenticatie (MFA). 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. Het is raadzaam om de integratie van geverifieerde id's van Microsoft Entra te gebruiken om een phishingbestendige verificatiemethode te registreren met behulp van een Tijdelijke Access Pass (TAP).
Voor nieuwe gebruikers of gebruikers zonder MFA voert u een proces uit om gebruikers een 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 inloggegevens initialiseren.
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 kunnen draagbare wachtwoordsleutels worden gebruikt om Windows Hello voor Bedrijven op de Windows-pc te bootstrapen wanneer u een apparaat gebruikt dat is gekoppeld aan Microsoft Entra ID en web-aanmelding voor Windows.
De volgende tabel bevat aanbevolen draagbare referenties voor verschillende persona's:
| Persona van gebruiker | Aanbevolen draagbare inloggegevens | Alternatieve draagbare inloggegevens |
|---|---|---|
| Beheerders en sterk gereglementeerde gebruikers | FIDO2-beveiligingssleutels | Wachtwoordsleutel voor Microsoft Authenticator, verificatie op basis van certificaten (smartcard) |
| Elke andere gebruiker | Gesynchroniseerde wachtwoordsleutel | FIDO2-beveiligingssleutel, wachtwoordsleutels voor Microsoft Authenticator-app |
De verificatiereferenties voor wachtwoordsleutels kunnen worden beperkt tot specifieke gebruikersgroepen met behulp van wachtwoordsleutelprofielen. Er moet een toegangssleutelprofiel worden ingesteld voor elke persona, waarbij de aanbevolen draagbare legitimatie wordt geselecteerd.
Gebruik de volgende richtlijnen om aanbevolen en alternatieve draagbare inloggegevens te activeren voor de relevante gebruikerspersona's van uw organisatie.
| Wijze | Richtlijn |
|---|---|
| FIDO2-beveiligingssleutels | |
| Gesynchroniseerde wachtwoordsleutel | |
| Wachtwoordsleutel in Microsoft Authenticator | |
| Smartcard/verificatie op basis van certificaten (CBA) |
Stap 3: Bootstrap lokale referenties
Het wordt aanbevolen dat elk apparaat waarop de gebruiker regelmatig werkt, een lokaal beschikbare referentie heeft, om de gebruiker de soepelste gebruikerservaring te geven. Lokaal beschikbare inloggegevens verminderen de tijd die nodig is voor verificatie, omdat gebruikers niet meerdere apparaten hoeven te gebruiken en het ontgrendelgebaar van het apparaat gebruiken om zich te verifiëren.
Zodra de gebruiker zijn draagbare referentie heeft verkregen, kan deze worden gebruikt om de lokale referentie te bootstrapen, zodat de gebruiker phishing-bestendige referenties kan gebruiken op andere apparaten waarvan ze eigenaar zijn.
Notitie
Gebruikers die apparaten delen, moeten alleen een Microsoft Entra-toegangssleutel in Windows of draagbare referenties gebruiken.
Gebruik de onderstaande tabel om te bepalen welk type lokale inloggegevens de voorkeur heeft voor elke gebruikerspersona.
| Gebruikerspersona | Aanbevolen lokale referentie - Windows | Aanbevolen lokale referentie - macOS | Aanbevolen lokale referentie - iOS | Aanbevolen lokale referentie - Android | Aanbevolen lokale referentie - Linux |
|---|---|---|---|---|---|
| Beheerders en sterk gereglementeerde werknemers | Windows Hello voor Bedrijven, Microsoft Entra-toegangssleutel op Windows, of CBA | Platform SSO Secure Enclave Key en CBA | Wachtwoordsleutel in Microsoft Authenticator of CBA | Wachtwoordsleutel in Microsoft Authenticator of CBA | N.u.b. (gebruik in plaats daarvan smartcard) |
| Niet-beheerders | Windows Hello voor Bedrijven of een Microsoft Entra passkey op Windows | Secure Enclave-sleutel voor eenmalige aanmelding (SSO) van Platform | Gesynchroniseerde wachtwoordsleutel | Gesynchroniseerde wachtwoordsleutel | N.v.t. (gebruik draagbare referenties in plaats daarvan) |
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 | |
| Microsoft Entra-wachtwoordsleutel in Windows | |
| Platformreferenties voor macOS | |
| Wachtwoordsleutel in Microsoft Authenticator |
Persona-specifieke overwegingen
Binnen elke persona kunnen er specifieke rolfuncties zijn, die hun eigen uitdagingen en overwegingen zullen hebben. U kunt de onderstaande tabel overwegen, die specifieke richtlijnen bevat voor bepaalde rollen binnen uw organisatie.
| Personage | Voorbeeldrollen |
|---|---|
| Beheerders | |
| Niet-beheerders |
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, niet alleen beheerders, en het gebruik van ondersteunde apparaattypen.
- 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 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 eerst een pilot met beheerders en vervolgens algemeen implementeren in niet-beheerdersgroepen, maar dit kan veranderen, afhankelijk van de behoeften van uw organisatie.
Gebruik de volgende secties om communicatie voor eindgebruikers te maken voor elke personagroep, het bereik en de implementatie van de functie voor wachtwoordsleutelregistratie, 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 de wachtwoordsleutel in Microsoft Authenticator 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 Inschrijf-gereedheidsfase van de werkmap kunt u de gereedheid voor de volgende besturingssystemen en referenties evalueren:
- Ramen
- Windows Hello voor Bedrijven
- FIDO2-beveiligingssleutel
- Certificate-Based Authenticatie / Smartcard
- macOS
- Platform SSO Sleutel voor Beveiligde Enclave
- FIDO2-beveiligingssleutel
- Certificate-Based Authenticatie / Smartcard
- Ios
- Gesynchroniseerde wachtwoordsleutel
- FIDO2-beveiligingssleutel
- Wachtwoordsleutel in Microsoft Authenticator
- Certificate-Based Authenticatie / Smartcard
- Android
- Gesynchroniseerde wachtwoordsleutel
- FIDO2-beveiligingssleutel
- Wachtwoordsleutel in Microsoft Authenticator
- Certificate-Based Authenticatie / 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 verstrekken aan Android 13-gebruikers die geen gesynchroniseerde wachtwoordsleutels kunnen gebruiken.
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
Zodra uw gebruikers klaar zijn voor phishing-bestendige verificatie, kunt u phishingbestendige verificatie afdwingen. Dit betekent dat ze MFA moeten uitvoeren met phishingbestendige referenties om toegang te krijgen tot resources in uw beleid.
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 |
| Besturing geven | Vereis een authenticatiesterkte - Phishingbestendige meervoudige-factorauthenticatie |
| Een beleid activeren | 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. Begin door het alleen-lezen beleid van de voorwaardelijke toegang in het beleidsfilter te selecteren.
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 een 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 selectievakje Beleid Niet Voldoet om de gegevens te filteren op aanmeldingen van gebruikers die zouden zijn geblokkeerd door het alleen-rapport-voorwaardelijk-toegangsbeleid.
Gebruik de gegevens die in dit rapport worden verstrekt om te bepalen welke gebruikers zouden zijn geblokkeerd, welk besturingssysteem van het apparaat ze gebruikten, welk type client-apps ze gebruikten en welke resources ze probeerden te openen. Met deze gegevens kunt u zich richten op deze gebruikers voor verschillende herstelacties of inschrijvingsprocedures, zodat ze effectief binnen de reikwijdte van afdwinging kunnen worden geplaatst.
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 wachtwoordsleutel in Authenticator
- Herinnering voor registratie voor wachtwoordsleutel in Authenticator
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: herhaalde boodschap
- 30 dagen voor handhaving: een bericht dat over 30 dagen de phishingresistente handhaving begint, moedig gebruikers aan zich proactief aan te melden.
- 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.
Verslaglegging en toezicht
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.
- Houd de gebruikersadoptie van wachtwoordloze, phishingbestendige referenties bij met behulp van aanmeldactiviteitsrapporten en aanmeldingslogboeken 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 enige soort wijziging aan in zijn of haar gegevens 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 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-31 juli: Wave 1 cohort enforcement geactiveerd
- 1 augustus - 15 augustus: Uitvoering van de tweede golf cohort ingeschakeld
- 16-31 augustus: Handhaving van cohort Wave 3 geactiveerd
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
De laatste fase van een phishingbestendige implementatie zonder wachtwoord dwingt het gebruik van phishingbestendige referenties af.
Stap 4: phishingweerstand afdwingen op resources
Als u phishingbestendige referenties wilt afdwingen in Microsoft Entra ID, is het primaire mechanisme sterke punten voor voorwaardelijke toegangsverificatie. Microsoft raadt u aan om de handhaving voor elke persona te benaderen op basis van een concept van gebruikers-/apparatenparen. Een implementatie voor afdwinging kan bijvoorbeeld het volgende patroon volgen:
- Beheerders op Windows en iOS
- Beheerders in macOS en Android
- Elke andere gebruiker in Windows en macOS
- Elke andere gebruiker in iOS en Android
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 |
|---|---|---|
| Ramen | 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 inloggegevens, zoals toegangssleutels in het authenticatieproces 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 opnieuw de groepen uit de vorige stap indien u de golfgebaseerde implementatiebenadering heeft 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: controle verlenen |
|---|---|---|---|
| 1 | Windows-gebruikers voorbereid op wachtwoordloos inloggen met phishing-bestendige technieken | Ramen | Verificatiesterkte vereisen : phishingbestendige MFA |
| 2 | Gebruikers van macOS die klaar zijn voor wachtwoordloze, phishingbestendige oplossingen | macOS | Verificatiesterkte vereisen : phishingbestendige MFA |
| 3 | iOS-gebruikers klaar voor phishingbestendige wachtwoordloze toegang | Ios | Verificatiesterkte vereisen : phishingbestendige MFA |
| 4 | Android-gebruikers klaar voor phishingbestendige, wachtwoordloze omgeving | Android | Verificatiesterkte vereisen : phishingbestendige MFA |
| 5 | Andere phishingbestendige gebruikers die klaar zijn voor een wachtwoordloze aanpak | 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-beveiliging helpt organisaties bij het detecteren, onderzoeken en oplossen van identiteitsrisico's. Microsoft Entra Id-beveiliging 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-beveiliging aan de volgende acties uit te voeren om hun phishingbestendige gebruikers zonder wachtwoord te beschermen:
- Bekijk de implementatierichtlijnen voor Microsoft Entra Id-beveiliging: 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-beveiliging 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 gebruikersgegevens niet langer eenvoudig kunnen worden gevist, kunnen aanvallers dan 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.