Verificatie met Azure AD

Verificatie is een proces waarbij toegang tot een systeem wordt toegekend of wordt ontkend door de identiteit van de accessoires te verifiëren. Gebruik een beheerde identiteitsservice voor alle resources om het algemene beheer (zoals wachtwoordbeleid) te vereenvoudigen en het risico op toezicht of menselijke fouten te minimaliseren. Azure Active Directory (Azure AD) is de one-stop-shop voor identiteits- en toegangsbeheerservice voor Azure.

Belangrijkste punten

• Beheerde identiteiten gebruiken voor toegang tot resources in Azure.
• Houd de cloud- en on-premises-directories gesynchroniseerd, met uitzondering van accounts met hoge bevoegdheden.
• Gebruik bij voorkeur methoden zonder wachtwoord of kies voor moderne wachtwoordmethoden.
• Schakel voorwaardelijke toegang van Azure AD in op basis van belangrijke beveiligingskenmerken bij het authenticeren van alle gebruikers, met name voor accounts met hoge bevoegdheden.

Verificatie op basis van identiteit gebruiken

Hoe wordt de toepassing geverifieerd tijdens de communicatie met Azure-platformservices?

Met beheerde identiteiten kunnen Azure-services bij elkaar worden geverifieerd zonder expliciete referenties via code te presenteren en de beveiliging te verbeteren.

Beheerde identiteiten voor Azure-resources is een functie van Azure Active Directory. Voor alle Azure-services die beheerde identiteiten voor Azure-resources ondersteunen, geldt een eigen tijdlijn. Controleer de beschikbaarheidsstatus van beheerde identiteiten voor uw resource en eventuele bekende problemen voordat u begint. De functie biedt Azure-services met een automatisch beheerde identiteit in Azure AD. U kunt de identiteit gebruiken voor verificatie bij alle services die ondersteuning bieden voor Azure AD-verificatie, inclusief Key Vault, zonder referenties in de code. De functie Beheerde identiteiten voor Azure-resources is gratis met Azure AD voor Azure-abonnementen. Er zijn geen extra kosten.

Er zijn twee typen beheerde identiteit:

• Een door het systeem toegewezen beheerde identiteit wordt rechtstreeks op een Azure-service-exemplaar ingeschakeld. Wanneer de identiteit is ingeschakeld, wordt een identiteit voor het service-exemplaar in de Azure AD-tenant gemaakt, dat wordt vertrouwd door het abonnement van het service-exemplaar. Nadat de identiteit is gemaakt, worden de referenties op het exemplaar ingericht. De levenscyclus van een door het systeem toegewezen identiteit is rechtstreeks gekoppeld aan de Azure-service-exemplaar waarop de identiteit is ingeschakeld. Als het exemplaar wordt verwijderd, ruimt Azure automatisch de referenties en de identiteit in Azure AD op.
• Een door de gebruiker toegewezen beheerde identiteit wordt gemaakt als een zelfstandige Azure-resource. Via een productieproces maakt Azure een identiteit in de Azure AD-tenant, die wordt vertrouwd door het gebruikte abonnement. Nadat de identiteit is gemaakt, kan deze worden toegewezen aan een of meer Azure-service-exemplaren. De levenscyclus van een door de gebruiker toegewezen identiteit wordt afzonderlijk beheerd van de levenscyclus van de Azure Service-exemplaren waaraan de identiteit is toegewezen.

Verifiëren met identiteitsservices in plaats van cryptografische sleutels. In Azure hoeven beheerde identiteiten geen referenties op te slaan die per ongeluk kunnen worden gelekt. Wanneer Beheerde identiteit is ingeschakeld voor een Azure-resource, wordt er een identiteit aan toegewezen die u kunt gebruiken om Azure AD-tokens te verkrijgen. Zie Door Azure AD beheerde identiteiten voor Azure-resources voor meer informatie.

Een AKS-cluster (Azure Kubernetes Service) moet bijvoorbeeld afbeeldingen van een Azure Container Registry (ACR) pullen. Voor toegang tot de afbeelding moet het cluster de ACR-referenties kennen. De aanbevolen manier is om beheerde identiteiten in teschakelen tijdens de clusterconfiguratie. Met deze configuratie wordt een identiteit toegewezen aan het cluster en kunnen Azure AD-tokens worden verkrijgen.

Deze aanpak is veilig omdat Azure het beheer van de onderliggende referenties voor u af handelen.

• De identiteit is gekoppeld aan de levenscyclus van de resource, in het AKS-clustervoorbeeld. Wanneer de resource wordt verwijderd, wordt de identiteit automatisch door Azure verwijderd.
• Azure AD beheert de tijdige roulatie van geheimen voor u.

Voorgestelde acties

• Controleer de workloadverificatie en identificeer mogelijkheden om expliciete referenties te converteren (bijvoorbeeld connection string api-sleutel) om beheerde identiteiten te gebruiken.
• Standaardiseer voor alle nieuwe Azure-workloads het gebruik van beheerde identiteiten, indien van toepassing.

Meer informatie

Wat zijn beheerde identiteiten voor Azure-resources?

Wat voor soort verificatie is vereist voor toepassings-API's?

Ga er niet van uit dat API-URL's die worden gebruikt door een workload, verborgen zijn en niet kunnen worden blootgesteld aan aanvallers. JavaScript-code op een website kan bijvoorbeeld worden bekeken. Een mobiele toepassing kan worden gecompileerd en geïnspecteerd. Zelfs voor interne API's die alleen op de back-end worden gebruikt, kan een verificatievereiste de moeilijkere lateral movement verhogen als een aanvaller netwerktoegang krijgt. Typische mechanismen zijn API-sleutels, autorisatietokens, IP-beperkingen.

Beheerde identiteit kan een API veiliger maken omdat deze het gebruik van door mensen beheerde service-principals vervangt en autorisatietokens kan aanvragen.

Hoe wordt gebruikersverificatie verwerkt in de toepassing?

Gebruik geen aangepaste implementaties om gebruikersreferenties te beheren. Gebruik in plaats daarvan Azure AD of andere providers van beheerde identiteiten, zoals Microsoft-account Azure B2C. Providers van beheerde identiteiten bieden aanvullende beveiligingsfuncties, zoals moderne wachtwoordbeveiliging, meervoudige verificatie (MFA) en opnieuw instellen. Over het algemeen heeft beveiliging zonder wachtwoord de voorkeur. Moderne protocollen zoals OAuth 2.0 maken ook gebruik van verificatie op basis van een token met een beperkte periode.

Worden verificatietokens veilig in de cache opgeslagen en versleuteld bij het delen tussen webservers?

Toepassingscode moet eerst proberen OAuth-toegangstokens op de silently op te halen uit een cache voordat u een token van de id-provider probeert te verkrijgen, om de prestaties te optimaliseren en de beschikbaarheid te maximaliseren. Tokens moeten veilig worden opgeslagen en verwerkt als andere referenties. Wanneer het nodig is om tokens te delen tussen toepassingsservers (in plaats van elke server die de eigen tokens in de opslag opeist en in de opslag in de opslag op te nemen), moet versleuteling worden gebruikt.

Zie Tokens verkrijgen en cachen voor meer informatie.

Kies een systeem met platformoverschrijdende ondersteuning

Gebruik één id-provider voor verificatie op alle platforms (besturingssystemen, cloudproviders en services van derden.

Azure AD kan worden gebruikt om Windows, Linux, Azure, Office 365, andere cloudproviders en services van derden te verifiëren als serviceproviders.

Verbeter bijvoorbeeld de beveiliging van virtuele Linux-machines (VM's) in Azure met Azure AD-integratie. Zie Aanmelden bij een virtuele Linux-machine in Azuremet behulp van Azure Active Directory verificatie voor meer informatie.

Alle identiteitssystemen centraliseren

Zorg ervoor dat uw cloudidentiteit gesynchroniseerd blijft met de bestaande identiteitssystemen om consistentie te garanderen en menselijke fouten te verminderen.

Consistentie van identiteiten in de cloud en on-premises vermindert menselijke fouten en het resulterende beveiligingsrisico. Teams het beheren van resources in beide omgevingen is een consistente gezaghebbende bron nodig om beveiligingsgaranties te bereiken. Voor bewaking wordt de beveiligingsefficiëntie verbeterd als de identiteit kan worden bepaald zonder een tussenliggend toewijzingsproces.

Synchronisatie gaat over het verstrekken van een identiteit aan gebruikers in de cloud op basis van hun on-premises identiteit. Of ze nu een gesynchroniseerd account gebruiken voor verificatie of federatieverificatie, de gebruikers hebben nog steeds een identiteit in de cloud nodig. Deze identiteit moet regelmatig worden onderhouden en bijgewerkt. De updates kunnen veel vormen aannemen, van titelwijzigingen tot wachtwoordwijzigingen.

Begin met het evalueren van de on-premises identiteitsoplossing en gebruikersvereisten van de organisatie. Deze evaluatie is belangrijk, omdat deze de technische vereisten definieert voor de manier waarop gebruikersidentiteiten in de cloud worden gemaakt en onderhouden. Voor de meeste organisaties wordt Active Directory on-premises ingesteld en wordt dit de on-premises directory van waaruit gebruikers worden gesynchroniseerd, maar dit is niet altijd het geval.

Overweeg het gebruik van Azure AD Verbinding maken voor het synchroniseren van Azure AD met uw bestaande on-premises directory. Voor migratieprojecten moet u deze taak voltooien voordat een Azure-migratie- en -ontwikkelingsprojecten beginnen.

Zie hybride id-providers voor meer informatie.

Meer informatie

De hybride identiteitssystemen synchroniseren

Verificatie zonder wachtwoord gebruiken

Aanvallers scannen voortdurend ip-adresbereiken van openbare cloud op open beheerpoorten. Ze proberen zwakke referenties(wachtwoordlak) en niet-gepatchte beveiligingsproblemen in beheerprotocollen zoals SSH en RDP te misbruiken. Als u directe internettoegang tot virtuele machines voorkomt, wordt een onjuiste configuratie of toezicht ernstiger.

Aanvalsmethoden hebben zich ontwikkeld tot het punt waarop wachtwoorden alleen een account niet betrouwbaar kunnen beveiligen. Moderne verificatieoplossingen, waaronder wachtwoordloze en meervoudige verificatie, verhogen de beveiligingsstatus door middel van sterke verificatie.

Verwijder waar mogelijk het gebruik van wachtwoorden. U moet ook dezelfde set referenties vereisen om u aan te melden en toegang te krijgen tot de resources on-premises of in de cloud. Deze vereiste is van cruciaal belang voor accounts waarvoor wachtwoorden zijn vereist, zoals beheerdersaccounts.

Met moderne verificatie- en beveiligingsfuncties in Azure AD moet dat basiswachtwoord worden aangevuld of vervangen door veiligere verificatiemethoden. Elke organisatie heeft andere behoeften op het gebied van verificatie. Microsoft biedt de volgende drie verificatieopties zonder wachtwoord die kunnen worden geïntegreerd met Azure Active Directory (Azure AD):

• Windows Hello voor Bedrijven
• Microsoft Authenticator-app
• FIDO2-beveiligingssleutels

Het is raadzaam om een plan met vier fases te volgen om wachtwoordloos te worden:

• Aanbieding voor wachtwoordvervanging ontwikkelen
• Het aantal gebruikers zichtbare wachtwoorden surface area
• Overstappen op een implementatie die geen wachtwoord vereist
• Wachtwoorden verwijderen uit de identiteitsmap

De volgende verificatiemethoden zijn geordend op de hoogste kosten/lastigste aanvalsmethoden (sterkste/voorkeursopties) naar de laagste kosten/moeilijk aan te vallen:

• Verificatie zonder wachtwoord. Enkele voorbeelden van deze methode zijn Windows Hello of Authenticator App.
• MFA. Hoewel deze methode effectiever is dan wachtwoorden, raden we u aan om niet te vertrouwen op MFA op basis van sms-berichten. Zie Enable per-user Azure Active Directory MFA to secure sign-in events (MFAper gebruiker inschakelen om aanmeldingsgebeurtenissen te beveiligen) voor meer informatie.
• Beheerde identiteiten. Zie Verificatie op basis van identiteit gebruiken.

Deze methoden zijn van toepassing op alle gebruikers, maar moeten als eerste en sterkste worden toegepast op accounts met beheerdersbevoegdheden.

Een implementatie van deze strategie is het inschakelen van eenmalige aanmelding (SSO) voor apparaten, apps en services. Door u eenmaal aan te melden met één gebruikersaccount, kunt u toegang verlenen tot alle toepassingen en resources per bedrijfsbehoeften. Gebruikers hoeven niet meerdere sets gebruikersnamen en wachtwoorden te beheren. U kunt de toegang tot toepassingen automatisch inrichten of de inrichting ervan inrichten. Zie Een aanmelding voor meer informatie.

Voorgestelde acties

• Ontwikkel een strategie zonder wachtwoord die MFA vereist voor alle gebruikers zonder dat dit bewerkingen aanzienlijk beïnvloedt.
• Zorg ervoor dat beleid en processen de directe internetverbinding door virtuele machines beperken en bewaken.

Meer informatie

• Strategie zonder wachtwoord
• Directe internetverbinding van virtuele machine (VM) verwijderen

Moderne wachtwoordbeveiliging gebruiken

Moderne beveiliging vereisen via methoden om het gebruik van wachtwoorden te verminderen. Moderne verificatieprotocollen ondersteunen sterke besturingselementen zoals MFA en moeten worden gebruikt in plaats van verouderde verificatiemethoden. Het gebruik van verouderde methoden verhoogt het risico op referentieblootstelling.

Moderne verificatie is een methode voor identiteitsbeheer die veiligere gebruikersverificatie en -autorisatie biedt. Het is beschikbaar voor Office 365 hybride implementaties van Skype voor Bedrijven server on-premises en Exchange server on-premises, en Skype voor Bedrijven hybride domeinen.

Moderne verificatie is een overkoepelende term voor een combinatie van verificatie- en autorisatiemethoden tussen een client (bijvoorbeeld uw laptop of telefoon) en een server, evenals enkele beveiligingsmaatregelen die afhankelijk zijn van toegangsbeleid dat u mogelijk al kent. Het omvat:

• Verificatiemethoden: MFA; smartcardverificatie; verificatie op basis van clientcertificaten
• Autorisatiemethoden: Microsoft's implementatie van Open Authorization (OAuth)
• Beleid voor voorwaardelijke toegang: voorwaardelijke toegang voor Mobile Application Management (MAM) en Azure Active Directory (Azure AD)

Bekijk workloads die geen gebruikmaken van moderne verificatieprotocollen en converteert deze waar mogelijk. Bovendien standaardiseer het gebruik van moderne verificatieprotocollen voor alle toekomstige workloads.

Schakel voor Azure beveiligingen in Azure AD in:

1. Configureer Azure AD Verbinding maken wachtwoordhashes te synchroniseren. Zie Synchronisatie van wachtwoordhashs implementeren met Azure ADvoor meer informatie Verbinding maken synchronisatie.

2. Kies of u problemen in een rapport automatisch of handmatig wilt oplossen. Zie Identiteitsrisico's bewaken voor meer informatie.

Zie de volgende artikelen voor meer informatie over het ondersteunen van moderne wachtwoorden in Azure AD:

• Wat is Identity Protection?
• On-premises Azure AD-wachtwoordbeveiliging afdwingen voor Active Directory Domain Services
• Beveiligingsrapport over gebruikers die risico lopen
• Beveiligingsrapport riskante aanmeldingen

Zie het volgende artikel voor meer informatie Office 365 het ondersteunen van moderne wachtwoorden in Office 365:

Wat is moderne verificatie?

Voorwaardelijke toegang inschakelen (Engelstalig artikel)

Moderne cloudtoepassingen zijn doorgaans toegankelijk via internet, waardoor toegang op basis van netwerklocatie inflexibele en enkelvoudige wachtwoorden een aansprakelijkheid is. Voorwaardelijke toegang beschrijft uw verificatiebeleid voor een toegangsbeslissing. Als een gebruiker bijvoorbeeld verbinding maakt vanaf een door InTune beheerde zakelijke pc, wordt deze mogelijk niet elke keer gevraagd om MFA, maar als de gebruiker plotseling verbinding maakt vanaf een ander apparaat in een andere geografie, is MFA vereist.

Verleen toegangsaanvragen op basis van het vertrouwensniveau van de aanvraager en de gevoeligheid van de doelbronnen.

Zijn er vereisten voor voorwaardelijke toegang voor de toepassing?

Workloads kunnen worden blootgesteld via openbaar internet en locatiegebaseerde netwerkbesturingselementen zijn niet van toepassing. Als u voorwaardelijke toegang wilt inschakelen, moet u weten welke beperkingen vereist zijn voor de use-case. MFA is bijvoorbeeld noodzakelijk voor externe toegang; Filteren op basis van IP kan worden gebruikt om ad-hoc-debugging in teschakelen (VPN's hebben de voorkeur).

Configureer voorwaardelijke toegang van Azure AD door toegangsbeleid in te stellen voor Azure-beheer op basis van uw operationele behoeften. Zie Toegang tot Azure-beheer beheren met voorwaardelijke toegang voor meer informatie.

Voorwaardelijke toegang kan een effectieve manier zijn om verouderde verificatie en bijbehorende protocollen uit te schakelen. Het beleid moet worden afgedwongen voor alle beheerders en andere accounts met kritieke gevolgen. Begin met het gebruik van metrische gegevens en logboeken om te bepalen welke gebruikers zich nog steeds verifiëren bij oude clients. Schakel vervolgens alle protocollen op downniveau uit die niet worden gebruikt en stel voorwaardelijke toegang in voor alle gebruikers die geen verouderde protocollen gebruiken. Ten slotte geeft u gebruikers een kennisgeving en richtlijnen over het upgraden voordat u verouderde verificatie volledig blokkeert. Zie Ondersteuning voor voorwaardelijke toegang van Azure AD voor het blokkeren van verouderde auth voor meer informatie.

Voorgestelde acties

Implementeert beleid voor voorwaardelijke toegang voor deze workload.

Meer informatie over voorwaardelijke toegang van Azure AD.

Volgende

Verleen of weiger toegang tot een systeem door de identiteit van de accessoires te verifiëren.

Verwante koppelingen

Terug naar het hoofdartikel: Aandachtspunten voor Identiteits- en toegangsbeheer van Azure