Identiteits- en toegangsbeheer voor SaaS-workloads in Azure
Toepassingsidentiteit is een essentieel gebied voor SaaS-workloads, omdat deze fungeert als de eerste verdedigingslinie voor het beveiligen van gegevens. Het wordt vaak over het hoofd gezien tot laat in een project, maar veel beslissingen over andere elementen van de toepassing zijn afhankelijk van een solide identiteitsstrategie. Onderschat het belang van identiteit niet om de gegevens van uw klanten te beschermen.
In de context van SaaS-workloads zijn er twee verschillende typen identiteiten.
Met toepassingsidentiteit, ook wel bekend als klantidentiteit en toegangsbeheer (CIAM), kunnen eindgebruikers uw SaaS-toepassing verifiëren en gebruiken. Er zijn twee hoofdmethoden voor het aanmelden van gebruikers bij een toepassings-id-provider:
Federatieve identiteiten. Gebruikers melden zich aan met bestaande referenties die worden onderhouden door een andere id-provider. Deze provider kan een sociale id-provider zijn, zoals Google, Facebook of LinkedIn, of een zakelijke id-provider die uw klanten gebruiken, zoals Microsoft Entra of Okta. Het onderhoud van het gebruikersaccount is de verantwoordelijkheid van de federatieve id-provider.
Lokale identiteiten. Gebruikers maken alleen een account voor uw toepassing. Het account wordt beveiligd door gebruikersnaam en wachtwoord, wachtwoordsleutel of andere verificatiemethoden. Het onderhoud van het gebruikersaccount is uw verantwoordelijkheid.
Bedrijfsidentiteit is de identiteitsoplossing die wordt gebruikt om interne gebruikers en workloads te verifiëren bij hulpprogramma's voor bedrijfsproductiviteit, interne hulpprogramma's of services en Azure-services. U gebruikt een bedrijfsidentiteitsoplossing voor uw interne gebruikers en workloads om ze te verifiëren bij hulpprogramma's voor bedrijfsproductiviteit, interne hulpprogramma's of services en Azure-services.
Toepassings- en bedrijfsidentiteiten dienen verschillende doeleinden en kunnen verschillende id-providers gebruiken. Dit artikel is gericht op ontwerpoverwegingen voor toepassingsidentiteit, hoewel beide typen waarschijnlijk aanwezig zijn in uw SaaS-workloadomgeving.
Identiteitsbeheer omvat twee gerelateerde problemen: verificatie (verificatie van de identiteit van een gebruiker) en autorisatie (machtigingen verlenen op basis van identiteit). De eerste drie secties van dit artikel zijn gericht op verificatie voor SaaS. In de laatste sectie worden autorisatieoverwegingen voor SaaS-providers besproken.
Identiteit in een multitenant-toepassing
Het is essentieel om tenantgegevens gescheiden te houden in een multitenant-toepassing. Deze segmentatie wordt aangestuurd door uw keuze voor effectieve gebruikersverificatie en -autorisatie. Ook is de keuze van het tenancymodel van invloed op uw beslissingen over de id-provider. Prioriteit geven aan identiteit als uw primaire perimeter.
Ontwerpoverwegingen
Inzicht in de tenancy- en implementatiemodellen voor uw toepassing. Er kunnen nuances zijn die van invloed zijn op uw identiteitsstrategie. Het is bijvoorbeeld een misvatting dat voor het patroon Implementatiestempels een id-provider in elke zegel is vereist. Voor de meeste id-providers kunt u vaak een alternatief isolatiemodel gebruiken.
Wanneer u uw id-provider kiest voor multitenancy, evalueert u de impact van fouten. Onjuiste configuraties kunnen uw volledige toepassing voor alle tenants mogelijk omlaag brengen. Wegen de overheadkosten tegen het risico van de potentiële impactstraal.
Als u uw oplossing implementeert in de Azure-omgeving van een klant en deze namens hen beheert, moet u mogelijk integreren met hun zakelijke id-provider. Zorg voor een duidelijk begrip van deze aspecten:
- De typen gebruikers en hun toegangsbehoeften wanneer ze communiceren met uw toepassingstenants. Gebruiker A heeft bijvoorbeeld alleen toegang nodig om zich aan te melden bij tenant 1, maar gebruiker B heeft mogelijk toegang nodig om zich aan te melden bij zowel tenant 1 als tenant 2.
- Naleving van de regelgeving voor gegevenslocatie, als deze van toepassing zijn op uw id-provider. In sommige gevallen kunnen gegevens die door een id-provider worden opgeslagen, onderhevig zijn aan regelgeving. Veel id-providers bieden specifieke richtlijnen en mogelijkheden voor dit scenario. Beoordeel of dit scenario relevant is voor u en voer de nodige stappen uit om de naleving te waarborgen.
Ontwerpaanaanvelingen
| Aanbeveling | Voordeel |
|---|---|
| Volg de aanbevolen procedures en richtlijnen van uw id-provider voor het partitioneren van de oplossing voor meerdere tenants. | Tenantisolatie helpt u bij het bereiken van uw beveiligings- en nalevingsdoelen. |
| Vermijd meerdere accounts voor dezelfde gebruiker. Een gebruiker moet één account hebben met één set referenties, zelfs als ze toegang nodig hebben tot meerdere tenants. Verdeel indien nodig toegang tot elke tenant in plaats van meerdere accounts voor dezelfde gebruiker te maken. | Het maken van meerdere accounts voor dezelfde gebruiker verhoogt de beveiligingsrisico's en kan gebruikers verwarren die meerdere gebruikersnamen en wachtwoorden voor dezelfde software moeten onthouden. |
| Wanneer u gegevenslocatie overweegt, plant u hoe u gebruikersgegevens op afzonderlijke locaties opslaat. Als u een afzonderlijke implementatiestempel implementeert voor uw gebruikers in andere geografische gebieden, hebt u mogelijk ook afzonderlijke id-providers nodig. Zorg ervoor dat u een manier hebt om te bepalen waar de gegevens van gebruikers zijn opgeslagen, zodat u ze naar de juiste regio voor aanmelding kunt leiden, als dat nodig is. |
U kunt uw nalevingsvereisten ondersteunen en de gebruikerservaring verbeteren door gebruikers door te routeren naar de aanmeldingservaring die geschikt is voor hun locatie. |
Selectie van id-provider
Elke id-provider biedt unieke functies, beperkingen, prijsmodellen en implementatiepatronen. Microsoft Entra en Okta zijn populaire IDaaS-opties (Identity as a Service). Er zijn ook andere opensource-providers, zoals Keycloak en Authentik.
Ontwerpoverwegingen
Documenteer uw identiteitsvereisten. Begin met het vermelden van de functies die uw toepassing nu nodig heeft en die in de toekomst nodig zijn. Typische functies die u moet overwegen, zijn onder andere:
-
- Ondersteuning van federatieve id-providers voor integratie met identiteitsoplossingen van klanten. Met deze functie kunt u voorkomen dat er nieuwe identiteiten worden gemaakt.
- Aanpasbare aanmeldings-/registratiestroom om het uiterlijk te wijzigen om uw huisstijl te behouden. Deze functie biedt ook de mogelijkheid om aangepaste bedrijfslogica in te voeren in het aanmeldings-/registratieproces.
- Scheiding van tenantgegevens in afzonderlijke silo's om tenantisolatie te behouden.
- Controleer de ondersteuning voor het bewaren of exporteren van aanmeldingslogboeken voor beveiligingsbeheer.
Belangrijk
Houd rekening met de groei van uw geplande gebruikers wanneer u de kosten van een identiteitsoplossing evalueert. Een oplossing blijft mogelijk niet rendabel of schaalbaar op de lange termijn, maar kan voorlopig nuttig zijn. Een migratieplan hebben dat u kunt gebruiken als dat nodig is.
Een oplossing kan bijvoorbeeld betaalbaar zijn voor 500 gebruikers, maar niet duurzaam voor 5 miljoen. Als er minimale instellingen nodig zijn en gebruiksvriendelijk en eenvoudig vandaan kunnen worden gemigreerd, kan het nog steeds de juiste keuze zijn totdat het schalen van kosten rechtvaardigt om over te schakelen naar een andere oplossing.
Onderzoek de mogelijkheden van de id-provider grondig. Zorg ervoor dat de identiteitsoplossing overeenkomt met uw lijst met vereiste functies. Zelfs als u momenteel geen complexe scenario's zoals federatieve identiteit nodig hebt, moet u rekening houden met toekomstige behoeften. Voor SaaS-oplossingen (business-to-business) is federatieve identiteit waarschijnlijk uiteindelijk nodig.
Factor in beheeroverhead. Verschillende id-providers vereisen verschillende beheeroverheadsniveaus. Bekende IDaaS-oplossingen hebben meestal minder overhead omdat ze hosting, onderhoud en beveiliging verwerken. De extra overhead van een opensource-oplossing kan echter de moeite waard zijn als de oplossing beter past bij uw gespecialiseerde behoeften.
Ontwerpaanaanvelingen
| Aanbeveling | Voordeel |
|---|---|
| Maak geen eigen identiteitsoplossing. Identiteit is een zeer gespecialiseerd gebied en het maken van een identiteitsoplossing is complex en duur. Het is moeilijk om een identiteitsoplossing te maken die veilig en betrouwbaar is. | U voorkomt het antipatroon van het maken van uw eigen provider en verbetert de beveiliging, betrouwbaarheid en operationele efficiëntie van uw oplossing. |
| Maak een mogelijkheidsmatrix van de functies die door id-providers worden aangeboden en wijs deze toe aan uw identiteitsvereisten. | U zorgt ervoor dat u zich kunt ontwikkelen zonder dat u wordt beperkt door een beperkte set identiteitsfuncties. |
| Liever IDaaS-opties dan opensource-oplossingen. Als u een opensource-oplossing host, ondervindt u zelf aanzienlijke operationele overhead- en beveiligingsrisico's. U kunt deze optie echter kiezen om te voldoen aan specifieke vereisten voor naleving, gegevenslocatie of betrouwbaarheid waaraan een provider niet kan voldoen. Zie IDaaS-id-providers voor meer informatie. |
Door een IDaaS-id-provider te gebruiken, voorkomt u onnodige complexiteit en kunt u zich richten op uw kernactiviteiten. |
Federatieve identiteit
Federatieve identiteit, ook wel bekend als eenmalige aanmelding (SSO), stelt gebruikers in staat zich aan te melden met referenties die ze elders al gebruiken. U schakelt federatieve identiteit in door een vertrouwensrelatie tot stand te brengen tussen de id-provider van uw toepassing en de bestaande id-provider van de klant. Federatieve identiteit is een algemene vereiste voor SaaS-oplossingen, met name in B2B, omdat klanten de voorkeur geven aan zakelijke referenties. Het biedt verschillende voordelen voor B2B-oplossingen, zoals gecentraliseerd identiteitsbeheer en automatisch levenscyclusbeheer. In B2C SaaS-producten is integratie met sociale id-providers gebruikelijk om gebruikers toe te staan zich aan te melden met bestaande referenties.
Compromis: Complexiteit en operationele efficiëntie. Door samen te werken met federatieve id-providers, offload u de complexiteit van het beheren van de identiteiten van uw gebruikers. U neemt echter rekening met de kosten voor integratie met een andere id-provider. Bepaal waar u uw operationele inspanningen wilt richten.
Hoewel het implementeren van federatieve identiteit in eerste instantie eenvoudig is, wordt het complexer naarmate het aantal ondersteunde id-providers toeneemt. Zorgvuldige planning is essentieel, met name als elke klant een unieke id-provider gebruikt. Zelfs als ze dezelfde id-provider gebruiken, zijn unieke vertrouwensrelaties vaak vereist voor elke klant vanwege specifieke configuratiegegevens.
In deze afbeelding ziet u de relatie tussen uw toepassing, uw toepassings-id-provider en de downstream-id-providers die u kunt implementeren met behulp van identiteitsfederatie.
Ontwerpoverwegingen
Schat de typen en het aantal id-providers dat u moet ondersteunen. Mogelijk hebt u een statisch aantal sociale id-providers nodig of hebt u mogelijk unieke federatieve id-providers nodig voor elke klant. U moet weten of uw klanten OpenID Connect (OIDC), Security Assertion Markup Language (SAML) of beide gebruiken voor integratie.
Wijs de aanmeldingservaring toe. Visualiseer de gebruikersstroom van het registratie- en aanmeldingsproces. Let op eventuele speciale vereisten die het ontwerp van uw gebruikersstroom kunnen wijzigen. Voorbeeld:
Aangepaste huisstijl. White labeling of aangepaste aanmeldingsdomeinen per klant.
Aangepaste gegevens. Aanvullende gebruikersgegevens verzamelen tijdens het registreren of aanmelden, zoals tenantselectie voor gebruikers met toegang tot meerdere tenants.
Selectie van id-provider. Als u één id-provider van toepassingen gebruikt die veel federatieve id-providers vertrouwt, moet u beslissen hoe u een provider selecteert. Deze selectie kan handmatig worden uitgevoerd via een knop of automatisch op basis van bekende gebruikersgegevens. Naarmate het aantal providers toeneemt, wordt automatische selectie praktischer. Deze mogelijkheid staat bekend als Home Realm Discovery.
Ontwerpaanaanvelingen
| Aanbeveling | Voordeel |
|---|---|
| Kies een id-provider die kan worden geschaald voor het aantal federatieve id-providers dat u nodig hebt. Houd rekening met de vaste limieten van de provider, die niet kunnen worden overschreden. |
U zorgt ervoor dat uw identiteitsoplossing kan worden geschaald naarmate u groeit. |
| Plan de onboarding van elke federatieve id-provider en automatiseer het proces zoveel mogelijk. Deze samenwerking tussen uw organisatie en uw klanten omvat het uitwisselen van informatie om een vertrouwensrelatie tot stand te brengen, meestal via OIDC- of SAML-protocollen. |
Identiteitsintegratie kan tijd en moeite kosten voor zowel u als uw klanten. Door het proces te plannen, verbetert u uw operationele efficiëntie. |
| Weerspiegel de complexiteit en kosten van federatieve identiteit in uw prijzen en bedrijfsmodel. Klanten toestaan om hun eigen id-provider te gebruiken, verhoogt de operationele complexiteit en kosten vanwege de overhead van het onderhouden van meerdere federatieve identiteitsvertrouwensrelaties. Het is gebruikelijk in SaaS-oplossingen voor ondernemingen om te betalen voor een hogere laag die federatieve aanmelding mogelijk maakt. |
Federeren met de id-provider van een klant kan verborgen kosten zijn in SaaS-oplossingen. Door dit te plannen, voorkomt u onverwachte kosten tijdens de implementatie. |
| Plan hoe de id-provider van een gebruiker wordt geselecteerd tijdens de aanmeldingsstroom. Overweeg het gebruik van Home Realm Discovery. Microsoft Entra ID biedt ingebouwde Home Realm Discovery. |
U stroomlijnt uw klantervaring en zorgt ervoor dat gebruikers worden omgeleid naar het juiste aanmeldingsproces. |
Autorisatie
Gebruikersautorisatie is cruciaal voor SaaS-toepassingen, die vaak gegevens voor meerdere tenants opslaan. Definieer duidelijk hoe gebruikers alleen toegang krijgen tot hun gegevens zonder onbedoeld toegang te krijgen tot de gegevens van andere tenants. Daarnaast kunt u gedetailleerde autorisatie binnen een tenant bieden, zodat gebruikers bepaalde gegevens kunnen lezen of openen terwijl updates of toegang tot andere gegevens worden beperkt.
Ontwerpoverwegingen
Kies het juiste autorisatiemodel voor de use-case. Er zijn twee hoofdtypen:
- Autorisatie op basis van rollen. Gebruikers zijn toegewezen rollen of groepen en specifieke functies zijn beperkt tot bepaalde rollen. Beheerders kunnen bijvoorbeeld elke actie uitvoeren, maar gebruikers in andere rollen hebben beperkte machtigingen.
- Autorisatie op basis van resources. Elke resource heeft een eigen set machtigingen. Een gebruiker is mogelijk een beheerder voor de ene resource, maar heeft geen toegang tot een andere resource.
Bepaal waar autorisatiegegevens moeten worden opgeslagen. Autorisatiegegevens voor uw toepassing kunnen worden opgeslagen in:
- Uw id-provider. Profiteer van de ingebouwde groepen of rollen en maak gebruik van machtigingen als claims in het token dat is uitgegeven aan uw toepassing. Uw toepassing kan vervolgens autorisatieregels afdwingen met behulp van deze tokenclaims.
- Uw toepassing. Ontwikkel uw eigen autorisatielogica en sla gebruikersmachtigingen op in een database of vergelijkbaar systeem, zodat u gedetailleerde autorisatiecontroles op basis van rollen of op resourceniveau kunt uitvoeren.
Compromis: Complexiteit, flexibiliteit en beveiliging. Het opslaan van autorisatiegegevens in een id-provider en het doorlopen van tokenclaims is meestal eenvoudiger dan het beheren van uw eigen autorisatiesysteem. Autorisatie op basis van claims beperkt echter uw flexibiliteit en u moet accepteren dat claims alleen worden vernieuwd wanneer een token opnieuw wordt uitgegeven, wat een vertraging kan veroorzaken bij het toepassen van gewijzigde machtigingen.Beoordeel de impact van gedelegeerd beheer. In de meeste SaaS-toepassingen, met name in B2B-toepassingen, wordt rol- en machtigingsbeheer gedelegeerd aan klanten. Zonder deze functionaliteit kunt u uw beheeroverhead verhogen als klanten vaak de machtigingen van hun gebruikers wijzigen.
Multitenant-toegang evalueren. In sommige systemen moet één gebruiker mogelijk toegang hebben tot gegevens van meerdere tenants. Consultants moeten bijvoorbeeld toegang hebben tot gegevens van meerdere tenants. Plan hoe klanten toegang verlenen aan deze gebruikers en hoe uw aanmeldingsstroom ondersteuning biedt voor het selecteren en schakelen tussen tenants.
Ontwerpaanaanvelingen
| Aanbeveling | Voordeel |
|---|---|
| Voorkomen dat gebruikers toegang krijgen tot gegevens over tenantgrenzen, tenzij die toegang expliciet is toegestaan. | Onbevoegde toegang tot de gegevens van een andere tenant, zelfs onbedoelde toegang, kan worden gezien als een belangrijk beveiligingsincident en de vertrouwensrelatie van klanten in uw platform uitroderen. Als u onnodige toegang blokkeert, kunt u deze situaties voorkomen. |
| Als de gegevens statisch zijn en onregelmatig worden gewijzigd, slaat u deze op in de id-provider. Als er regelmatig wijzigingen nodig zijn terwijl de gebruiker de software gebruikt, slaat u de autorisatiegegevens op in uw toepassing. | Als u het beste gegevensarchief voor uw autorisatiegegevens selecteert, verbetert u uw operationele efficiëntie en kunt u voldoen aan uw schaalbaarheidsbehoeften. |
| Als u machtigingsbeheer delegeert aan klanten, geeft u een duidelijke methode op om machtigingen te beheren. Maak bijvoorbeeld een webportal die alleen toegankelijk is voor tenantbeheerders voor het wijzigen van gebruikersmachtigingen. | U geeft meer controle over uw klanten en voorkomt onnodige operationele lasten voor uw ondersteuningsteam. |
Aanvullende bronnen
Multitenancy is een kernbedrijfsmethodologie voor het ontwerpen van SaaS-workloads. Deze artikelen bieden meer informatie over identiteits- en toegangsbeheer:
- Architectuuroverwegingen voor identiteit in multitenant-oplossingen
- Architectuurbenaderingen voor identiteit in multitenant-oplossingen
Volgende stap
Meer informatie over het kiezen van uw rekenhostingmodel, de operationele aspecten en het optimaliseren van de technologieopties om u te helpen voldoen aan uw serviceovereenkomsten en -doelstellingen.