Delen via

Architectuuroverwegingen voor identiteit in een multitenant-oplossing

  • Artikel

Identiteit is een belangrijk aspect van elke multitenant-oplossing. De identiteitsonderdelen van uw toepassing zijn verantwoordelijk voor het volgende:

  • Controleren wie een gebruiker is (verificatie).
  • De machtigingen van de gebruiker afdwingen binnen het bereik van een tenant (autorisatie).

Uw klanten willen mogelijk ook externe toepassingen autoriseren om toegang te krijgen tot hun gegevens of om te integreren in uw oplossing. De identiteit van een gebruiker bepaalt tot welke gegevens een gebruiker of service toegang krijgt. Het is belangrijk dat u rekening houdt met uw identiteitsvereisten om uw toepassing en gegevens tussen tenants te isoleren.

Let op

Verificatie- en autorisatieservices, binnen multitenant- en SaaS-toepassingen, worden meestal geleverd door een externe id-provider (IdP). Een id-provider is meestal een integraal onderdeel van een IDaaS-platform (Identity as a Service).

Het bouwen van uw eigen IdP is complex, duur en moeilijk om veilig te bouwen. Het bouwen van uw eigen id-provider is een antipatroon. We raden het niet aan.

Voordat u een strategie voor meerdere tenants-identiteit definieert, moet u eerst rekening houden met de identiteitsvereisten op hoog niveau van uw service, waaronder de volgende vereisten:

  • Worden gebruikers- of workloadidentiteiten gebruikt voor toegang tot één toepassing of meerdere toepassingen binnen een productfamilie? Een retailproductfamilie kan bijvoorbeeld zowel een point-of-sale-toepassing als een voorraadbeheertoepassing hebben, die dezelfde identiteitsoplossing delen.
  • Bent u van plan moderne verificatie en autorisatie te implementeren, zoals OAuth2 en OpenID Connect?
  • Biedt uw oplossing alleen verificatie voor uw op gebruikersinterface gebaseerde toepassingen? Of biedt u ook API-toegang tot uw tenants en derden?
  • Moeten tenants federeren naar hun eigen IdP en moeten meerdere verschillende id-providers worden ondersteund voor elke tenant? U hebt bijvoorbeeld tenants met Microsoft Entra ID, Auth0 en Active Directory Federation Services (ADFS), waarbij elke tenant met uw oplossing wil federeren. U moet ook weten welke federatieprotocollen van de ID's van uw tenants u wilt ondersteunen, omdat de protocollen van invloed zijn op de vereisten voor uw eigen IdP.
  • Zijn er specifieke nalevingsvereisten waaraan ze moeten voldoen, zoals AVG?
  • Moeten de identiteitsgegevens van uw tenants zich binnen een specifieke geografische regio bevinden?
  • Hebben gebruikers van uw oplossing toegang nodig tot gegevens van één tenant of van meerdere tenants in uw toepassing? Hebben ze de mogelijkheid nodig om snel te schakelen tussen tenants of om geconsolideerde informatie van meerdere tenants weer te geven? Gebruikers die zich hebben aangemeld bij Azure Portal kunnen bijvoorbeeld eenvoudig schakelen tussen verschillende Microsoft Entra ID-directory's en abonnementen waartoe ze toegang hebben.

Wanneer u uw algemene vereisten hebt vastgesteld, kunt u beginnen met het plannen van specifiekere details en vereisten, zoals gebruikersdirectorybronnen en registratie-/aanmeldingsstromen.

Identiteitsmap

Voor een multitenant-oplossing om een gebruiker of service te verifiëren en autoriseren, moet deze een plaats hebben om identiteitsgegevens op te slaan. Een map kan gezaghebbende records bevatten voor elke identiteit of kan verwijzingen bevatten naar externe identiteiten die zijn opgeslagen in de directory van een andere id-provider.

Wanneer u een identiteitssysteem ontwerpt voor uw multitenant-oplossing, moet u overwegen welke van de volgende typen IdP uw tenants en klanten nodig hebben:

  • Lokale id-provider. Met een lokale id-provider kunnen gebruikers zich aanmelden bij de service. Gebruikers geven een gebruikersnaam, een e-mailadres of een id op, zoals een rewards-kaartnummer. Ze geven ook een referentie op, zoals een wachtwoord. De IdP slaat zowel de gebruikers-id als de referenties op.
  • Sociale id-provider. Met een id-provider voor sociale netwerken kunnen gebruikers een identiteit gebruiken die ze hebben op een sociaal netwerk of een andere openbare id-provider, zoals Facebook, Google of een persoonlijk Microsoft-account.
  • Gebruik de map Microsoft Entra ID van de tenant. Tenants hebben mogelijk al hun eigen Microsoft Entra ID-map en ze willen mogelijk dat uw oplossing de map als idP gebruikt voor toegang tot uw oplossing. Deze aanpak is mogelijk wanneer uw oplossing is gebouwd als een Multitenant Microsoft Entra-toepassing.
  • Federatie met de id-provider van een tenant. Tenants hebben mogelijk hun eigen IdP, behalve Microsoft Entra-id, en ze willen mogelijk dat uw oplossing ermee kan worden gefedereerd. Federatie maakt eenmalige aanmelding (SSO) mogelijk en stelt tenants in staat om de levenscyclus en het beveiligingsbeleid van hun gebruikers te beheren, onafhankelijk van uw oplossing.

Overweeg of uw tenants ondersteuning moeten bieden voor meerdere id-providers. U moet bijvoorbeeld lokale identiteiten, sociale identiteiten en federatieve identiteiten ondersteunen, allemaal binnen één tenant. Deze vereiste is gebruikelijk wanneer bedrijven een oplossing gebruiken die zowel voor hun eigen werknemers als voor aannemers is. Ze kunnen federatie gebruiken voor de toegang van hun eigen werknemers tot de oplossing, terwijl ze ook toegang tot contractanten of gastgebruikers toestaan, die geen account hebben in de federatieve IdP.

Verificatie- en tenantautorisatiegegevens opslaan

In een multitenant-oplossing moet u overwegen waar verschillende typen identiteitsgegevens moeten worden opgeslagen, waaronder de volgende typen:

  • Details over gebruikers- en serviceaccounts, inclusief hun namen en andere informatie die vereist is voor uw tenants.
  • Informatie die vereist is om uw gebruikers veilig te verifiëren, inclusief informatie die vereist is om meervoudige verificatie (MFA) te bieden.
  • Tenantspecifieke informatie, zoals tenantrollen en machtigingen. Deze informatie wordt gebruikt voor autorisatie.

Let op

Het is niet raadzaam om zelf verificatieprocessen te bouwen. Moderne ID's bieden deze verificatieservices aan uw toepassing en bevatten ook andere belangrijke functies, zoals MFA en voorwaardelijke toegang. Het bouwen van uw eigen id-provider is een antipatroon. We raden het niet aan.

Houd rekening met de volgende opties voor het opslaan van identiteitsgegevens:

  • Sla alle identiteits- en autorisatiegegevens op in de IdP-map en deel deze tussen meerdere tenants.
  • Sla de gebruikersreferenties op in de IdP-map en sla de autorisatiegegevens op in de toepassingslaag, naast de tenantgegevens.

Het aantal identiteiten voor een gebruiker bepalen

Het is gebruikelijk dat multitenant-oplossingen een gebruikers- of workloadidentiteit toegang geven tot de toepassing en gegevens van meerdere tenants. Overweeg of deze aanpak vereist is voor uw oplossing. Als dat het geval is, moet u rekening houden met de volgende vragen:

  • Moet u één gebruikersidentiteit maken voor elke persoon of afzonderlijke identiteiten maken voor elke combinatie van tenantgebruikers?
    • U kunt het beste één identiteit gebruiken voor elke persoon, waar mogelijk. Het wordt moeilijk om meerdere gebruikersaccounts te beheren, zowel voor u als de leverancier van de oplossing, en ook voor uw gebruikers. Daarnaast zijn veel van de intelligente bedreigingsbeveiligingen die door een moderne IdP worden aangeboden, afhankelijk van elke persoon met één gebruikersaccount.
    • In sommige situaties kan het echter nodig zijn dat een gebruiker meerdere afzonderlijke identiteiten heeft. Als mensen uw systeem bijvoorbeeld zowel gebruiken voor werk- als persoonlijke doeleinden, willen ze mogelijk hun gebruikersaccounts scheiden. Als uw tenants strikte wettelijke of geografische gegevensopslagvereisten hebben, moeten ze mogelijk meerdere identiteiten hebben, zodat ze aan regelgeving of wetten kunnen voldoen.
  • Als u identiteiten per tenant gebruikt, moet u voorkomen dat referenties meerdere keren worden opgeslagen. Gebruikers moeten hun referenties hebben opgeslagen op één identiteit en u moet functies zoals gastidentiteiten gebruiken om te verwijzen naar dezelfde gebruikersreferenties uit de identiteitsrecords van meerdere tenants.

Gebruikers toegang verlenen tot tenantgegevens

Overweeg hoe gebruikers worden toegewezen aan een tenant. Tijdens het registratieproces kunt u bijvoorbeeld een unieke uitnodigingscode gebruiken die ze voor het eerst invoeren wanneer ze toegang hebben tot een tenant. In sommige oplossingen kunt u de domeinnaam van de aanmeldings-e-mailadressen van de gebruikers gebruiken als een manier om de tenant te identificeren waartoe ze behoren. U kunt ook een ander kenmerk van de identiteitsrecord van de gebruiker gebruiken om de gebruiker toe te wijzen aan een tenant. Vervolgens moet u de toewijzing opslaan op basis van de onderliggende onveranderbare unieke id's voor zowel de tenant als de gebruiker.

Als uw oplossing zo is ontworpen dat één gebruiker alleen toegang heeft tot de gegevens voor één tenant, kunt u de volgende beslissingen nemen:

  • Hoe detecteert de IdP welke tenant een gebruiker gebruikt?
  • Hoe communiceert de IdP de tenant-id met de toepassing? Meestal wordt een tenant-id-claim toegevoegd aan het token.

Als één gebruiker toegang moet krijgen tot meerdere tenants, moet u rekening houden met de volgende beslissingen:

  • Hoe identificeert en verleent uw oplossing machtigingen aan een gebruiker die toegang heeft tot meerdere tenants? Kan een gebruiker bijvoorbeeld een beheerder zijn in een trainingstenant en alleen-lezentoegang hebben tot een productietenant? Of, kunt u afzonderlijke tenants hebben voor verschillende afdelingen in een organisatie, maar u moet consistente gebruikersidentiteiten onderhouden voor alle tenants?
  • Hoe schakelt een gebruiker tussen tenants?
  • Als u workloadidentiteiten gebruikt, hoe geeft een workloadidentiteit de tenant op waartoe deze toegang moet hebben?
  • Is er tenantspecifieke informatie opgeslagen in de identiteitsrecord van de gebruiker die informatie tussen tenants kan lekken? Stel dat een gebruiker zich heeft geregistreerd met een sociale identiteit en vervolgens toegang heeft gekregen tot twee tenants. Tenant A heeft de identiteit van de gebruiker verrijkt met meer informatie. Moet tenant B toegang hebben tot de verrijkte informatie?

Registratieproces van gebruikers voor lokale identiteiten of sociale identiteiten

Sommige tenants moeten mogelijk toestaan dat gebruikers zich registreren voor een identiteit in uw oplossing. Selfserviceregistratie is mogelijk vereist als u geen federatie met de id-provider van een tenant nodig hebt. Als u een zelfregistratieproces nodig hebt, moet u rekening houden met de volgende vragen:

  • Van welke identiteitsbronnen mogen gebruikers zich aanmelden? Kan een gebruiker bijvoorbeeld een lokale identiteit maken en ook een id-provider voor sociale netwerken gebruiken?
  • Als alleen lokale identiteiten zijn toegestaan, worden alleen specifieke e-maildomeinen toegestaan? Kan een tenant bijvoorbeeld opgeven dat alleen gebruikers met een @contoso.com e-mailadres zich mogen registreren?
  • Wat is de UPN (User Principal Name) die moet worden gebruikt om elke lokale identiteit uniek te identificeren tijdens het aanmeldingsproces? Een e-mailadres, gebruikersnaam, telefoonnummer en rewards-kaartnummer zijn bijvoorbeeld allemaal algemene opties voor UPN's. UPN's kunnen echter in de loop van de tijd veranderen. Wanneer u verwijst naar de identiteit in de autorisatieregels of auditlogboeken van uw toepassing, is het een goed idee om de onderliggende onveranderbare unieke id van de identiteit te gebruiken. Microsoft Entra ID biedt een object-id (OID), een onveranderbare id.
  • Moet een gebruiker zijn of haar UPN verifiëren? Als het e-mailadres of telefoonnummer van de gebruiker bijvoorbeeld wordt gebruikt als UPN, hoe controleert u of de gegevens juist zijn?
  • Moeten tenantbeheerders registraties goedkeuren?
  • Hebben tenants een tenantspecifieke aanmeldingservaring of URL nodig? Hebben uw tenants bijvoorbeeld een merk-registratie-ervaring nodig wanneer gebruikers zich registreren? Moeten uw tenants een registratieaanvraag onderscheppen en extra validatie uitvoeren voordat deze wordt voortgezet?

Tenanttoegang voor zelfregistratiegebruikers

Wanneer gebruikers zich mogen registreren voor een identiteit, moet er meestal een proces zijn om hen toegang te geven tot een tenant. De registratiestroom kan een toegangstoezegewijs proces bevatten, of kan worden geautomatiseerd op basis van de informatie over de gebruikers, zoals hun e-mailadressen. Het is belangrijk om dit proces te plannen en rekening te houden met de volgende vragen:

  • Hoe bepaalt de registratiestroom dat een gebruiker toegang moet krijgen tot een specifieke tenant?
  • Als gebruikers geen toegang meer hebben tot een tenant, wordt de toegang door uw oplossing automatisch ingetrokken? Wanneer gebruikers bijvoorbeeld een organisatie verlaten, moet er een handmatig of geautomatiseerd proces zijn waarmee de toegang van de tenant wordt verwijderd.
  • Moet u een manier bieden voor tenants om de gebruikers te controleren die toegang hebben tot hun tenants en hun machtigingen?

Geautomatiseerd accountlevenscyclusbeheer

Een veelvoorkomende vereiste voor zakelijke of zakelijke klanten van een oplossing is een set functies waarmee ze onboarding en off-onboarding van accounts kunnen automatiseren. Open protocollen, zoals System for Cross-Domain Identity Management (SCIM), bieden een industriestandaard benadering voor automatisering. Dit geautomatiseerde proces omvat meestal niet alleen het maken en verwijderen van identiteitsrecords, maar ook het beheer van tenantmachtigingen. Houd rekening met de volgende vragen wanneer u geautomatiseerd levenscyclusbeheer voor accounts implementeert in een multitenant-oplossing:

  • Moeten uw klanten een geautomatiseerd levenscyclusproces per tenant configureren en beheren? Wanneer een gebruiker bijvoorbeeld wordt voorbereid, moet u mogelijk de identiteit maken binnen meerdere tenants in uw toepassing, waarbij elke tenant een andere set machtigingen heeft.
  • Moet u SCIM implementeren of kunt u in plaats daarvan tenantsfederatie opgeven om de bron van waarheid voor gebruikers onder controle van de tenant te houden, in plaats van lokale gebruikers te beheren?

Gebruikersverificatieproces

Wanneer een gebruiker zich aanmeldt bij een toepassing met meerdere tenants, verifieert uw identiteitssysteem de gebruiker. Houd rekening met de volgende vragen wanneer u uw verificatieproces plant:

  • Moeten uw tenants hun eigen MFA-beleid (MultiFactor Authentication) configureren? Als uw tenants zich bijvoorbeeld in de financiële dienstverlening bevinden, moeten ze strikte MFA-beleidsregels implementeren, terwijl een kleine onlinewinkel mogelijk niet dezelfde vereisten heeft.
  • Moeten uw tenants hun eigen regels voor voorwaardelijke toegang configureren? Verschillende tenants moeten bijvoorbeeld aanmeldingspogingen van specifieke geografische regio's blokkeren.
  • Moeten uw tenants het aanmeldingsproces voor elke tenant aanpassen? Moet u bijvoorbeeld het logo van een klant weergeven? Of moet informatie over elke gebruiker worden geëxtraheerd uit een ander systeem, zoals een beloningsnummer, en worden geretourneerd aan de id-provider om toe te voegen aan het gebruikersprofiel?
  • Moeten uw gebruikers andere gebruikers imiteren? Een ondersteuningsteamlid kan bijvoorbeeld een probleem onderzoeken dat een andere gebruiker heeft door zich te imiteren als gebruikersaccount zonder dat hij zich hoeft te verifiëren als de gebruiker.
  • Moeten uw gebruikers toegang krijgen tot de API's voor uw oplossing? Gebruikers of toepassingen van derden moeten uw API's bijvoorbeeld rechtstreeks aanroepen om uw oplossing uit te breiden, zonder een gebruikersinterface om een verificatiestroom te bieden.

Workloadidentiteiten

In de meeste oplossingen vertegenwoordigt een identiteit vaak een gebruiker. Bij sommige systemen met meerdere tenants kunnen ook workloadidentiteiten worden gebruikt door services en toepassingen, om toegang te krijgen tot uw toepassingsresources. Uw tenants moeten bijvoorbeeld toegang hebben tot een API die door uw oplossing wordt geleverd, zodat ze enkele beheertaken kunnen automatiseren.

Workloadidentiteiten zijn vergelijkbaar met gebruikersidentiteiten, maar vereisen meestal verschillende verificatiemethoden, zoals sleutels of certificaten. Workloadidentiteiten maken geen gebruik van MFA. In plaats daarvan zijn voor workloadidentiteiten meestal andere beveiligingscontroles vereist, zoals het regelmatig verlopen van sleutels en het verlopen van certificaten.

Als uw tenants verwachten dat ze toegang tot de workloadidentiteit tot uw multitenant-oplossing kunnen inschakelen, moet u rekening houden met de volgende vragen:

  • Hoe worden workloadidentiteiten in elke tenant gemaakt en beheerd?
  • Hoe worden identiteitsaanvragen voor workloads afgestemd op de tenant?
  • Moet u het aantal workloadidentiteiten beperken dat door elke tenant wordt gemaakt?
  • Moet u besturingselementen voor voorwaardelijke toegang opgeven voor workloadidentiteiten voor elke tenant? Een tenant kan bijvoorbeeld een workloadidentiteit beperken voor verificatie van buiten een specifieke regio.
  • Welke beveiligingsmaatregelen biedt u aan tenants om ervoor te zorgen dat workloadidentiteiten veilig blijven? Geautomatiseerde sleutelverloop, verlooptijd van sleutels, certificaatverloop en aanmeldingsrisicobewaking zijn bijvoorbeeld allemaal methoden om het risico te verminderen, waarbij een workloadidentiteit mogelijk wordt misbruikt.

Federatie met een id-provider voor eenmalige aanmelding (SSO)

Tenants, die al hun eigen gebruikersmappen hebben, willen mogelijk dat uw oplossing federatief is voor hun directory's. Met federatie kan uw oplossing de identiteiten in hun directory gebruiken in plaats van een andere map met afzonderlijke identiteiten te beheren.

Federatie is met name belangrijk wanneer sommige tenants hun eigen identiteitsbeleid willen opgeven of als ze ervaringen met eenmalige aanmelding (SSO) willen inschakelen.

Als u verwacht dat tenants federeren met uw oplossing, moet u rekening houden met de volgende vragen:

  • Wat is het proces voor het configureren van de federatie voor een tenant? Kunnen tenants federatie zelf configureren of vereist het proces handmatige configuratie en onderhoud door uw team?
  • Welke federatieprotocollen worden ondersteund?
  • Welke processen zijn er om ervoor te zorgen dat federatie niet onjuist kan worden geconfigureerd, om toegang te verlenen tot een andere tenant?
  • Moet de id-provider van één tenant worden gefedereerd naar meer dan één tenant in uw oplossing? Als klanten bijvoorbeeld zowel een trainings- als productietenant hebben, moeten ze mogelijk dezelfde id-provider federeren voor beide tenants.

Autorisatiemodellen

Beslis over het autorisatiemodel dat het meest zinvol is voor uw oplossing. Twee veelvoorkomende autorisatiemethoden zijn:

  • Autorisatie op basis van rollen. Gebruikers worden toegewezen aan rollen. Sommige functies van de toepassing zijn beperkt tot specifieke rollen. Een gebruiker in de beheerdersrol kan bijvoorbeeld elke actie uitvoeren, terwijl een gebruiker in een lagere rol mogelijk een subset machtigingen heeft in het hele systeem.
  • Autorisatie op basis van resources. Uw oplossing biedt een set afzonderlijke resources, die elk een eigen set machtigingen hebben. Een specifieke gebruiker kan een beheerder van één resource zijn en geen toegang hebben tot een andere resource.

Deze modellen zijn verschillend en de methode die u selecteert, is van invloed op uw implementatie en de complexiteit van het autorisatiebeleid dat u kunt implementeren.

Rechten en licenties

In sommige oplossingen kunt u licenties per gebruiker gebruiken als onderdeel van uw commerciële prijsmodel. U zou verschillende lagen van gebruikerslicenties met verschillende mogelijkheden bieden. Gebruikers met één licentie kunnen bijvoorbeeld een subset van de functies van de toepassing gebruiken. De mogelijkheden waartoe specifieke gebruikers toegang hebben, op basis van hun licenties, worden ook wel rechten genoemd.

Hoewel het bijhouden en afdwingen van rechten vergelijkbaar is met autorisatie, wordt deze doorgaans verwerkt door de toepassingscode of door een toegewezen rechtensysteem, in plaats van beheerd door het identiteitssysteem.

Identiteitsschaal en verificatievolume

Naarmate multitenant-oplossingen toenemen, neemt het aantal gebruikers en aanmeldingsaanvragen dat door de oplossing moet worden verwerkt toe. Houd rekening met de volgende vragen:

  • Wordt de gebruikersmap geschaald naar het aantal gebruikers dat vereist is?
  • Verwerkt het verificatieproces het verwachte aantal aanmeldingen en aanmeldingen?
  • Zijn er pieken die het verificatiesysteem niet kan verwerken? Zo kan iedereen in de westelijke Verenigde Staten regio om 9:00 uur pst werken en zich aanmelden bij uw oplossing, waardoor er een piek in aanmeldingsaanvragen ontstaat. Deze situaties worden ook wel aanmeldingsstormen genoemd.
  • Kan een hoge belasting in andere onderdelen van uw oplossing van invloed zijn op de prestaties van het verificatieproces? Als voor uw verificatieproces bijvoorbeeld het aanroepen van een API op de toepassingslaag is vereist, veroorzaakt een groot aantal verificatieaanvragen problemen voor de rest van uw oplossing?
  • Wat gebeurt er als uw IdP niet meer beschikbaar is? Is er een back-upverificatieservice die kan worden overgenomen om bedrijfscontinuïteit te bieden, terwijl de IdP niet beschikbaar is?

Medewerkers

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

Belangrijkste auteurs:

Andere Inzenders:

Volgende stappen

Bekijk de architectuurbenaderingen voor identiteit in multitenant-oplossingen.