Delen via

Architectuurbenaderingen voor identiteit in multitenant-oplossingen

  • Artikel

Bijna alle multitenant-oplossingen vereisen een identiteitssysteem. In dit artikel bespreken we algemene onderdelen van identiteit, waaronder zowel verificatie als autorisatie, en bespreken we hoe deze onderdelen kunnen worden toegepast in een multitenant-oplossing.

Notitie

Bekijk architectuuroverwegingen voor identiteit in een multitenant-oplossing voor meer informatie over de belangrijkste vereisten en beslissingen die u moet nemen voordat u een identiteitssysteem voor een multitenant-oplossing gaat bouwen.

Verificatie

Verificatie is het proces waarmee de identiteit van een gebruiker tot stand wordt gebracht. Wanneer u een multitenant-oplossing bouwt, zijn er speciale overwegingen en benaderingen voor verschillende aspecten van het verificatieproces.

Federatie

Mogelijk moet u federeren met andere id-providers (IDP's). Federatie kan worden gebruikt om de volgende scenario's in te schakelen:

  • Sociale aanmelding, bijvoorbeeld door gebruikers in staat te stellen hun Google-, Facebook-, GitHub- of persoonlijke Microsoft-account te gebruiken.
  • Tenantspecifieke directory's, zoals door tenants in staat te stellen uw toepassing te federeren met hun eigen id-providers, zodat ze accounts niet op meerdere plaatsen hoeven te beheren.

Zie het patroon Federatieve identiteit voor algemene informatie over federatie.

Als u ervoor kiest om tenantspecifieke id-providers te ondersteunen, moet u aangeven welke services en protocollen u moet ondersteunen. Ondersteunt u bijvoorbeeld het OpenID-Verbinding maken-protocol en het SAML-protocol (Security Assertion Markup Language) ? Of biedt u alleen ondersteuning voor federatie met Microsoft Entra-exemplaren?

Wanneer u een id-provider implementeert, moet u rekening houden met de schaal en limieten die van toepassing kunnen zijn. Als u bijvoorbeeld Azure Active Directory (Azure AD) B2C als uw eigen id-provider gebruikt, moet u mogelijk aangepast beleid implementeren om te federeren met bepaalde typen tenant-id-providers. Azure AD B2C beperkt het aantal aangepaste beleidsregels dat u kunt implementeren, waardoor het aantal tenantspecifieke id-providers waarmee u kunt federeren, kan worden beperkt.

U kunt ook overwegen federatie op te geven als een functie die alleen van toepassing is op klanten in een hogere productlaag.

Eenmalige aanmelding

Met eenmalige aanmeldingservaringen kunnen gebruikers naadloos schakelen tussen toepassingen, zonder dat ze op elk moment opnieuw moeten worden geverifieerd.

Wanneer gebruikers een toepassing bezoeken, stuurt de toepassing deze naar een IdP. Als de IdP ziet dat ze een bestaande sessie hebben, geeft deze een nieuw token uit zonder dat de gebruikers hoeven te communiceren met het aanmeldingsproces. Een federatief identiteitsmodel biedt ondersteuning voor ervaringen met eenmalige aanmelding door gebruikers in staat te stellen één identiteit te gebruiken in meerdere toepassingen.

In een multitenant-oplossing kunt u ook een andere vorm van eenmalige aanmelding inschakelen. Als gebruikers gemachtigd zijn om met gegevens voor meerdere tenants te werken, moet u mogelijk een naadloze ervaring bieden wanneer de gebruikers hun context wijzigen van de ene tenant naar de andere. Overweeg of u naadloze overgangen tussen tenants moet ondersteunen en of uw id-provider tokens opnieuw moet uitgeven met specifieke tenantclaims. Een gebruiker die zich heeft aangemeld bij Azure Portal, kan bijvoorbeeld schakelen tussen verschillende Microsoft Entra-directory's, waardoor de verificatie opnieuw wordt uitgevoerd en het token opnieuw wordt uitgegeven vanuit het zojuist geselecteerde Microsoft Entra-exemplaar.

Evaluatie van aanmeldingsrisico's

Moderne identiteitsplatformen ondersteunen een risicoanalyse tijdens het aanmeldingsproces. Als een gebruiker zich bijvoorbeeld aanmeldt vanaf een ongebruikelijke locatie of een ongebruikelijk apparaat, kan het verificatiesysteem extra identiteitscontroles vereisen, zoals meervoudige verificatie (MFA), voordat de aanmeldingsaanvraag kan worden voortgezet.

Overweeg of uw tenants verschillende risicobeleidsregels kunnen hebben die moeten worden toegepast tijdens het verificatieproces. Als u bijvoorbeeld een aantal tenants in een sterk gereglementeerde branche hebt, hebben ze mogelijk verschillende risicoprofielen en vereisten voor tenants die in minder gereglementeerde omgevingen werken. U kunt er ook voor kiezen om tenants met hogere prijscategorieën toe te staan om meer beperkend aanmeldingsbeleid op te geven dan tenants die een lagere laag van uw service aanschaffen.

Als u verschillende risicobeleidsregels voor elke tenant moet ondersteunen, moet uw verificatiesysteem weten bij welke tenant de gebruiker zich aanmeldt, zodat deze het juiste beleid kan toepassen.

Als uw IdP deze mogelijkheden bevat, kunt u overwegen om de systeemeigen functies voor aanmeldingsrisico's van IdP te gebruiken. Deze functies kunnen complex en foutgevoelig zijn om uzelf te implementeren.

Als u de eigen id-providers van tenants federeert, kunnen ook hun eigen risicobeperkende beleidsregels voor aanmelding worden toegepast en kunnen ze het beleid en de besturingselementen beheren die moeten worden afgedwongen. Het is echter belangrijk om onbedoeld onnodige last te voorkomen van de gebruiker, zoals door twee MFA-uitdagingen te vereisen: één van de id-provider van de gebruiker en één van uw eigen gebruikers. Zorg ervoor dat u begrijpt hoe federatie communiceert met de id-providers van uw tenants en het beleid dat ze hebben toegepast.

Imitatie

Met imitatie kan een gebruiker de identiteit van een andere gebruiker aannemen zonder de referenties van die gebruiker te gebruiken.

Over het algemeen is imitatie gevaarlijk en kan het lastig zijn om te implementeren en te controleren. In sommige scenario's is imitatie echter een vereiste. Als u bijvoorbeeld Software as a Service (SaaS) uitvoert, moet uw helpdeskmedewerkers mogelijk de identiteit van een gebruiker aannemen, zodat ze zich kunnen aanmelden als de gebruiker en een probleem kunnen oplossen.

Als u imitatie wilt implementeren, kunt u overwegen hoe u het gebruik ervan controleert. Zorg ervoor dat uw logboeken zowel de werkelijke gebruiker bevatten die de actie heeft uitgevoerd als de id van de gebruiker die ze hebben geïmiteerd.

Sommige identiteitsplatformen ondersteunen imitatie, ofwel als een ingebouwde functie of met behulp van aangepaste code. In Azure AD B2C kunt u bijvoorbeeld een aangepaste claim toevoegen voor de geïmiteerde gebruikers-id of u kunt de claim voor de onderwerp-id vervangen in de tokens die worden uitgegeven.

Autorisatie

Autorisatie is het proces om te bepalen wat een gebruiker mag doen.

Autorisatiegegevens kunnen op verschillende plaatsen worden opgeslagen, waaronder op de volgende locaties:

  • In uw id-provider. Als u bijvoorbeeld Microsoft Entra-id als id-provider gebruikt, kunt u functies zoals app-rollen en -groepen gebruiken om autorisatiegegevens op te slaan. Uw toepassing kan vervolgens de bijbehorende tokenclaims gebruiken om uw autorisatieregels af te dwingen.
  • In uw toepassing. U kunt uw eigen autorisatielogica bouwen en vervolgens informatie opslaan over wat elke gebruiker in een database of vergelijkbaar opslagsysteem kan doen. Vervolgens kunt u verfijnde besturingselementen ontwerpen voor autorisatie op basis van rollen of resources.

In de meeste multitenant-oplossingen worden rol- en machtigingstoewijzingen beheerd door de tenant of klant, niet door u als leverancier van het multitenant-systeem.

Zie Toepassingsrollen voor meer informatie.

Tenantidentiteit en rolgegevens toevoegen aan tokens

Overweeg welk deel of welke onderdelen van uw oplossing autorisatieaanvragen moeten uitvoeren, inclusief het bepalen of een gebruiker mag werken met gegevens van een specifieke tenant.

Een veelvoorkomende benadering is dat uw identiteitssysteem een tenant-id-claim insluit in een token. Met deze methode kan uw toepassing de claim inspecteren en controleren of de gebruikers met de tenant werken waartoe ze toegang hebben. Als u het beveiligingsmodel op basis van rollen gebruikt, kunt u ervoor kiezen om het token uit te breiden met informatie over de rol die een gebruiker in de tenant heeft.

Als één gebruiker echter toegang heeft tot meerdere tenants, hebt u mogelijk een manier nodig voor uw gebruikers om aan te geven met welke tenant ze willen werken tijdens het aanmeldingsproces. Nadat ze hun actieve tenant hebben geselecteerd, kan de IdP de juiste tenant-id-claim en -rol voor die tenant opnemen, binnen het token dat het probleem veroorzaakt. U moet ook overwegen hoe gebruikers kunnen schakelen tussen tenants, waarvoor een nieuw token moet worden uitgegeven.

Autorisatie op basis van toepassingen

Een alternatieve benadering is om het identiteitssysteem agnostisch te maken voor tenant-id's en -rollen. De gebruikers worden geïdentificeerd met behulp van hun referenties of een federatierelatie, en tokens bevatten geen tenant-id-claim. Een afzonderlijke lijst of database bevat welke gebruikers toegang hebben gekregen tot elke tenant. Vervolgens kan de toepassingslaag controleren of de opgegeven gebruiker toegang moet hebben tot de gegevens voor een specifieke tenant, op basis van het opzoeken van die lijst.

Microsoft Entra-id of Azure AD B2C gebruiken

Microsoft biedt Microsoft Entra ID en Azure AD B2C, dat beheerde identiteitsplatforms zijn die u in uw eigen multitenant-oplossing kunt gebruiken.

Veel multitenant-oplossingen zijn SaaS (Software as a Service). Uw keuze of u Microsoft Entra ID of Azure AD B2C wilt gebruiken, is deels afhankelijk van de wijze waarop u uw tenants of klantenbestand definieert.

  • Als uw tenants of klanten organisaties zijn, gebruiken ze mogelijk al Microsoft Entra ID voor services zoals Office 365, Microsoft Teams of voor hun eigen Azure-omgevingen. U kunt een multitenant-toepassing maken in uw eigen Microsoft Entra-directory om uw oplossing beschikbaar te maken voor andere Microsoft Entra-directory's. U kunt uw oplossing zelfs vermelden in Azure Marketplace en deze gemakkelijk toegankelijk maken voor organisaties die gebruikmaken van Microsoft Entra-id.
  • Als uw tenants of klanten geen Microsoft Entra-id gebruiken of als ze individuen zijn in plaats van organisaties, kunt u overwegen Azure AD B2C te gebruiken. Azure AD B2C biedt een set functies om te bepalen hoe gebruikers zich registreren en aanmelden. U kunt bijvoorbeeld de toegang tot uw oplossing beperken tot gebruikers die u al hebt uitgenodigd, of u kunt selfserviceregistratie toestaan. Gebruik aangepaste beleidsregels in Azure AD B2C om volledig te bepalen hoe gebruikers communiceren met het identiteitsplatform. U kunt aangepaste huisstijl gebruiken en u kunt Azure AD B2C federeren met uw eigen Microsoft Entra-tenant, zodat uw eigen medewerkers zich kunnen aanmelden. Azure AD B2C maakt ook federatie mogelijk met andere id-providers.
  • Sommige multitenant-oplossingen zijn bedoeld voor beide situaties die hierboven worden vermeld. Sommige tenants hebben mogelijk hun eigen Microsoft Entra-tenants en andere niet. U kunt ook Azure AD B2C voor dit scenario gebruiken en aangepast beleid gebruiken om gebruikersaanmelding toe te staan vanuit de Microsoft Entra-directory van een tenant. Als u echter aangepast beleid gebruikt om federatie tussen tenants tot stand te brengen, moet u ervoor zorgen dat u rekening houdt met de limieten voor het aantal aangepaste beleidsregels dat één Azure AD B2C-directory kan gebruiken.

Zie Overwegingen voor het gebruik van Azure Active Directory B2C in een architectuur met meerdere tenants voor meer informatie.

Antipatroon om te voorkomen

Uw eigen identiteitssysteem bouwen of uitvoeren

Het bouwen van een modern identiteitsplatform is complex. Er zijn verschillende protocollen en standaarden ter ondersteuning en het is eenvoudig om een protocol onjuist te implementeren en een beveiligingsprobleem bloot te leggen. Standaarden en protocollen veranderen en u moet uw identiteitssysteem voortdurend bijwerken om aanvallen te beperken en recente beveiligingsfuncties te ondersteunen. Het is ook belangrijk om ervoor te zorgen dat een identiteitssysteem tolerant is, omdat downtime ernstige gevolgen kan hebben voor de rest van uw oplossing. Bovendien voegt het implementeren van een id-provider in de meeste gevallen geen voordeel toe aan het bedrijf en is het gewoon een noodzakelijk onderdeel van het implementeren van een multitenant-service. Het is beter om in plaats daarvan een gespecialiseerd identiteitssysteem te gebruiken dat wordt gebouwd, beheerd en beveiligd door experts.

Wanneer u uw eigen identiteitssysteem uitvoert, moet u wachtwoordhashes of andere vormen van referenties opslaan, die een verleidelijk doelwit worden voor aanvallers. Zelfs hashing en salting wachtwoorden is vaak onvoldoende beveiliging, omdat de rekenkracht die beschikbaar is voor aanvallers het mogelijk maken om deze vormen van referenties in gevaar te brengen.

Wanneer u een identiteitssysteem uitvoert, bent u ook verantwoordelijk voor het genereren en distribueren van MFA- of eenmalige wachtwoordcodes (OTP). Deze vereisten betekenen dan dat u een mechanisme nodig hebt om deze codes te distribueren, met behulp van sms of e-mail. Bovendien bent u verantwoordelijk voor het detecteren van zowel gerichte als brute-force-aanvallen, het beperken van aanmeldingspogingen, controle, enzovoort.

In plaats van uw eigen identiteitssysteem te bouwen of uit te voeren, is het een goede gewoonte om een off-the-shelf service of component te gebruiken. U kunt bijvoorbeeld Microsoft Entra ID of Azure AD B2C gebruiken. Dit zijn beheerde identiteitsplatforms. Leveranciers van het beheerde identiteitsplatform nemen de verantwoordelijkheid om de infrastructuur voor hun platforms te beheren en ondersteunen doorgaans de huidige identiteits- en verificatiestandaarden.

Kan niet rekening houden met de vereisten van uw tenants

Tenants hebben vaak sterke meningen over hoe identiteit moet worden beheerd voor de oplossingen die ze gebruiken. Veel zakelijke klanten hebben bijvoorbeeld federatie met hun eigen id-providers nodig om eenmalige aanmelding mogelijk te maken en om te voorkomen dat meerdere sets referenties worden beheerd. Andere tenants vereisen mogelijk meervoudige verificatie of andere vormen van beveiliging rond de aanmeldingsprocessen. Als u niet voor deze vereisten hebt ontworpen, kan het lastig zijn om ze later opnieuw aan te passen.

Zorg ervoor dat u de identiteitsvereisten van uw tenants begrijpt voordat u het ontwerp van uw identiteitssysteem voltooit. Bekijk architectuuroverwegingen voor identiteit in een multitenant-oplossing om inzicht te hebben in enkele specifieke vereisten die vaak ontstaan.

Gebruikers en tenants samenvoegen

Het is belangrijk om duidelijk te overwegen hoe uw oplossing een gebruiker en een tenant definieert. In veel situaties kan de relatie complex zijn. Een tenant kan bijvoorbeeld meerdere gebruikers bevatten en één gebruiker kan lid worden van meerdere tenants.

Zorg ervoor dat u een duidelijk proces hebt voor het bijhouden van de tenantcontext, binnen uw toepassing en aanvragen. In sommige gevallen moet u voor dit proces mogelijk een tenant-id opnemen in elk toegangstoken en de tenant-id voor elke aanvraag valideren. In andere situaties slaat u de tenantautorisatiegegevens afzonderlijk op van de gebruikersidentiteiten en gebruikt u een complexer autorisatiesysteem om te beheren welke gebruikers welke bewerkingen op welke tenants kunnen uitvoeren.

Het bijhouden van de tenantcontext van een gebruiker of token is van toepassing op elk tenancymodel, omdat een gebruikersidentiteit altijd een tenantcontext heeft binnen een multitenant-oplossing. Het is zelfs een goede gewoonte om tenantcontext bij te houden wanneer u onafhankelijke stempels voor één tenant implementeert, die uw codebasis toekomstbestendig maakt voor andere vormen van multitenancy.

Rol- en resourceautorisatie confisleren

Het is belangrijk dat u een geschikt autorisatiemodel voor uw oplossing selecteert. Op rollen gebaseerde beveiligingsmethoden kunnen eenvoudig te implementeren zijn, maar autorisatie op basis van resources biedt meer verfijnde controle. Houd rekening met de vereisten van uw tenants en of uw tenants bepaalde gebruikers moeten machtigen om toegang te krijgen tot specifieke onderdelen van uw oplossing en niet tot andere onderdelen.

Kan auditlogboeken niet schrijven

Auditlogboeken zijn een belangrijk hulpmiddel om inzicht te krijgen in uw omgeving en hoe gebruikers uw systeem implementeren. Door elke identiteitsgebeurtenis te controleren, kunt u vaak bepalen of uw identiteitssysteem wordt aangevallen en kunt u controleren hoe uw systeem wordt gebruikt. Zorg ervoor dat u auditlogboeken schrijft en opslaat in uw identiteitssysteem. Overweeg of de identiteitscontrolelogboeken van uw oplossing beschikbaar moeten worden gesteld voor tenants die moeten worden gecontroleerd.

Inzenders

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

Belangrijkste auteurs:

Andere Inzenders:

Volgende stappen

Bekijk architectuuroverwegingen voor identiteit in een multitenant-oplossing.