Een volledig beheerd identiteitsserviceplatform gebruiken

  • Artikel

Bijna elke cloudtoepassing moet werken met gebruikersidentiteiten. Identiteit is de basis van moderne beveiligingsprocedures, zoals nul vertrouwen, en gebruikersidentiteit voor toepassingen is een essentieel onderdeel van de architectuur van uw oplossing.

Voor de meeste oplossingen raden we u ten zeerste aan om een IDaaS-platform (Identity as a Service), een volledig beheerde identiteitsoplossing te gebruiken in plaats van uw eigen identiteit te bouwen of te gebruiken. In dit artikel beschrijven we de uitdagingen van het bouwen of uitvoeren van uw eigen identiteitssysteem.

Aanbevelingen

Belangrijk

Met behulp van een IDaaS, zoals Microsoft Entra ID, Azure AD B2C of een ander vergelijkbaar systeem, kunt u veel van de problemen beperken die in dit artikel worden beschreven. We raden deze aanpak aan waar mogelijk.

Uw oplossingsvereisten kunnen ertoe leiden dat u een framework of externe identiteitsoplossing gebruikt die u host en zelf uitvoert. Hoewel het gebruik van een vooraf samengesteld identiteitsplatform enkele van de problemen die in dit artikel worden beschreven, beperkt, is het afhandelen van veel van deze problemen nog steeds uw verantwoordelijkheid met een dergelijke oplossing.

Vermijd het gebruik van een volledig nieuw identiteitssysteem dat u bouwt.

Voorkomen dat referenties worden opgeslagen

Wanneer u uw eigen identiteitssysteem uitvoert, moet u een database met referenties opslaan. U moet nooit referenties opslaan in duidelijke tekst of zelfs als versleutelde gegevens.

In plaats daarvan kunt u overwegen om cryptografische hash- en salting-referenties te gebruiken voordat u ze opslaat, waardoor ze moeilijker kunnen worden aangevallen. Zelfs gehashte en gezouten referenties zijn echter kwetsbaar voor verschillende soorten aanvallen.

Ongeacht hoe u de afzonderlijke referenties beveiligt, maakt het onderhouden van een database met referenties u een doelwit voor aanvallen. De afgelopen jaren hebben zowel grote als kleine organisaties aangetoond dat hun referentiesdatabases zijn gericht op aanvallen.

Overweeg referentieopslag als aansprakelijkheid, geen asset. Met behulp van een IDaaS besteedt u het probleem van referentieopslag uit aan experts die de tijd en resources kunnen investeren in het veilig beheren van referenties.

Identiteits- en federatieprotocollen implementeren

Moderne identiteitsprotocollen zijn complex. Brancheexperts hebben OAuth 2, OpenID Verbinding maken en andere protocollen ontworpen om ervoor te zorgen dat ze echte aanvallen en beveiligingsproblemen beperken. De protocollen ontwikkelen zich ook om zich aan te passen aan veranderingen in technologieën, aanvalsstrategieën en verwachtingen van gebruikers. Identiteitsspecialisten, met expertise in de protocollen en hoe ze worden gebruikt, zijn de beste positie om systemen die volgen op deze protocollen te implementeren en te valideren. Zie OAuth 2.0 en OpenID Verbinding maken (OIDC) in het Microsoft Identity Platform voor meer informatie over de protocollen en het platform.

Het is ook gebruikelijk om identiteitssystemen te federeren. Identiteitsfederatieprotocollen zijn complex om gespecialiseerde kennis en ervaring op te stellen, te beheren en te onderhouden. Zie Federatieve identiteitspatronen voor meer informatie.

Moderne identiteitsfuncties gebruiken

Gebruikers verwachten dat een identiteitssysteem een reeks geavanceerde functies heeft, waaronder:

  • Verificatie zonder wachtwoord, waarbij veilige methoden worden gebruikt om u aan te melden waarvoor gebruikers geen referenties hoeven in te voeren.

  • Eenmalige aanmelding (SSO), waarmee gebruikers zich kunnen aanmelden met behulp van een identiteit van hun werkgever, school of een andere organisatie.

  • Meervoudige verificatie (MFA), waarmee gebruikers op meerdere manieren wordt gevraagd zich te verifiëren. Een gebruiker kan zich bijvoorbeeld aanmelden met een wachtwoord en ook met behulp van een verificator-app op een mobiel apparaat of een code die via e-mail wordt verzonden.

  • Controle, die elke gebeurtenis bijhoudt die plaatsvindt in het identiteitsplatform, inclusief geslaagde, mislukte en afgebroken aanmeldingspogingen. Om een aanmeldingspoging later forensisch te analyseren, is mogelijk een gedetailleerd logboek vereist.

  • Voorwaardelijke toegang, waardoor een risicoprofiel ontstaat rond een aanmeldingspoging die is gebaseerd op verschillende factoren. De factoren kunnen bestaan uit de identiteit van de gebruiker, de locatie van de aanmeldingspoging, de vorige aanmeldingsactiviteit en de gevoeligheid van de gegevens of toepassing.

  • Just-In-Time-toegangsbeheer, waardoor gebruikers zich tijdelijk kunnen aanmelden op basis van een goedkeuringsproces en vervolgens de autorisatie automatisch kunnen verwijderen.

Als u zelf een identiteitsonderdeel bouwt als onderdeel van uw bedrijfsoplossing, is het onwaarschijnlijk dat u het werk dat betrokken is bij het implementeren van deze functies kunt rechtvaardigen en bij het onderhouden ervan. Voor sommige van deze functies is ook extra werk vereist, zoals integratie met berichtenproviders om MFA-codes te verzenden en auditlogboeken gedurende een voldoende periode op te slaan en te bewaren.

IDaaS-platforms kunnen ook een verbeterde set beveiligingsfuncties bieden die zijn gebaseerd op het aantal aanmeldingsaanvragen dat ze ontvangen. De volgende functies werken bijvoorbeeld het beste wanneer er een groot aantal klanten is die één identiteitsplatform gebruiken:

  • Detectie van riskante aanmeldingsgebeurtenissen, zoals aanmeldingspogingen van botnets
  • Detectie van onmogelijke reizen tussen de activiteiten van een gebruiker
  • Detectie van veelvoorkomende referenties, zoals wachtwoorden die vaak worden gebruikt door andere gebruikers, die daarom worden blootgesteld aan een verhoogd risico op inbreuk
  • Gebruik van machine learning-technieken voor het classificeren van aanmeldingspogingen als geldig of ongeldig
  • Bewaking van het zogenaamde donkere web voor gelekte referenties en het voorkomen van hun exploitatie
  • Doorlopende bewaking van het bedreigingslandschap en de huidige vectoren die aanvallers gebruiken

Als u uw eigen identiteitssysteem bouwt of uitvoert, kunt u niet profiteren van deze functies.

Een betrouwbaar identiteitssysteem met hoge prestaties gebruiken

Omdat identiteitssystemen zo'n belangrijk onderdeel zijn van moderne cloudtoepassingen, moeten ze betrouwbaar zijn. Als uw identiteitssysteem niet beschikbaar is, kan de rest van uw oplossing worden beïnvloed en werken ze op een gedegradeerde manier of werken ze helemaal niet. Door een IDaaS met een service level agreement te gebruiken, kunt u uw vertrouwen vergroten dat uw identiteitssysteem operationeel blijft wanneer u dit nodig hebt. Microsoft Entra ID biedt bijvoorbeeld een SLA voor uptime voor de Basic- en Premium-servicelagen, die betrekking hebben op zowel de aanmeld- als het token verlenende processen. Zie SLA voor Microsoft Entra ID voor meer informatie.

Op dezelfde manier moet een identiteitssysteem goed presteren en kunnen worden geschaald naar het groeiniveau dat uw systeem kan ervaren. Afhankelijk van uw toepassingsarchitectuur is het mogelijk dat elke aanvraag interactie met uw identiteitssysteem vereist en dat eventuele prestatieproblemen zichtbaar zijn voor uw gebruikers. IDaaS-systemen worden geïncentiveerd om te schalen naar grote gebruikersbelastingen. Ze zijn ontworpen om grote hoeveelheden verkeer te absorberen, inclusief verkeer dat wordt gegenereerd door verschillende vormen van aanvallen.

Uw beveiliging testen en strakke besturingselementen toepassen

Als u een identiteitssysteem uitvoert, is het uw verantwoordelijkheid om het te beveiligen. Voorbeelden van de besturingselementen die u moet implementeren, zijn:

  • Periodieke penetratietests, waarvoor gespecialiseerde expertise is vereist.
  • Het controleren van werknemers en iedereen met toegang tot het systeem.
  • Nauw beheer van alle wijzigingen in uw oplossing met alle wijzigingen die door experts worden beoordeeld.

Deze controles zijn vaak duur en moeilijk te implementeren.

Cloudeigen beveiligingscontroles gebruiken

Wanneer u Microsoft Entra ID als id-provider van uw oplossing gebruikt, kunt u gebruikmaken van cloudeigen beveiligingsfuncties, zoals beheerde identiteiten voor Azure-resources.

Als u ervoor kiest om een afzonderlijk identiteitsplatform te gebruiken, moet u overwegen hoe uw toepassing kan profiteren van beheerde identiteiten en andere Microsoft Entra-functies terwijl u tegelijkertijd integreert met uw eigen identiteitsplatform.

Focus op uw kernwaarde

Het is duur en complex om een veilig, betrouwbaar en responsief identiteitsplatform te onderhouden. In de meeste gevallen is een identiteitssysteem geen onderdeel dat waarde toevoegt aan uw oplossing, of die u onderscheidt van uw concurrenten. Het is goed om uw identiteitsvereisten uit te besteden aan een systeem dat is gebouwd door experts. Op die manier kunt u zich richten op het ontwerpen en bouwen van de onderdelen van uw oplossing die bedrijfswaarde voor uw klanten toevoegen.

Inzenders

Dit artikel wordt onderhouden door Microsoft. De tekst is oorspronkelijk geschreven door de volgende Inzenders.

Hoofdauteur:

  • John Downs | Senior klanttechnicus, FastTrack voor Azure

Andere Inzenders:

Als u niet-openbare LinkedIn-profielen wilt zien, meldt u zich aan bij LinkedIn.

Volgende stappen