Identitets- och åtkomsthantering för SaaS-arbetsbelastningar i Azure
Programidentitet är ett kritiskt område för SaaS-arbetsbelastningar eftersom det fungerar som den första försvarslinjen för att skydda data. Det förbises ofta till sent i ett projekt, men många beslut om andra delar av programmet beror på en solid identitetsstrategi. Underskatta inte vikten av identitet för att skydda dina kunders data.
När det gäller SaaS-arbetsbelastningar finns det två olika typer av identiteter.
Programidentitet, även kallat kundidentitets- och åtkomsthantering (CIAM), gör det möjligt för slutanvändare att autentisera och använda ditt SaaS-program. Det finns två huvudsakliga metoder för att logga in användare till en programidentitetsprovider:
Federerade identiteter. Användare loggar in med befintliga autentiseringsuppgifter som underhålls av en annan identitetsprovider. Leverantören kan vara en leverantör av sociala identiteter som Google, Facebook eller LinkedIn eller en företagsidentitetsprovider som dina kunder använder, till exempel Microsoft Entra eller Okta. Underhållet av användarens konto är den federerade identitetsproviderns ansvar.
Lokala identiteter. Användare skapar ett konto bara för ditt program. Kontot skyddas med användarnamn och lösenord, nyckel eller andra autentiseringsmetoder. Underhåll av användarens konto är ditt ansvar.
Företagsidentitet är den identitetslösning som används för att autentisera interna användare och arbetsbelastningar till affärsproduktivitetsverktyg, interna verktyg eller tjänster och Azure-tjänster. Du använder en företagsidentitetslösning för dina interna användare och arbetsbelastningar för att autentisera dem till affärsproduktivitetsverktyg, interna verktyg eller tjänster och Azure-tjänster.
Program- och företagsidentiteter har olika syften och kan använda olika identitetsprovidrar. Den här artikeln fokuserar på designöverväganden för programidentitet, även om båda typerna sannolikt finns i din SaaS-arbetsbelastningsmiljö.
Identitetshantering omfattar två relaterade problem: autentisering (verifiera en användares identitet) och auktorisering (bevilja behörigheter baserat på identitet). De första tre avsnitten i den här artikeln fokuserar på autentisering för SaaS. Det sista avsnittet behandlar auktoriseringsöverväganden för SaaS-leverantörer.
Identitet i ett program med flera klientorganisationer
Det är viktigt att hålla klientdata åtskilda i ett program med flera klienter. Segmenteringen drivs av ditt val av effektiv användarautentisering och auktorisering. Valet av innehavarmodell påverkar också avsevärt dina beslut om identitetsprovidern. Prioritera identiteten som din primära perimeter.
Utformningsbeaktanden
Förstå klient- och distributionsmodellerna för ditt program. Det kan finnas nyanser som påverkar din identitetsstrategi. Det är till exempel en missuppfattning att mönstret Distributionsstämplar kräver en identitetsprovider i varje stämpel. För de flesta identitetsprovidrar kan du ofta använda en alternativ isoleringsmodell.
När du väljer din identitetsprovider för flera klientorganisationer utvärderar du effekten av fel. Felkonfigurationer kan potentiellt sänka hela programmet för alla klienter. Väg omkostnaderna mot risken för den potentiella påverkansradien.
Om du distribuerar din lösning till en kunds Azure-miljö och hanterar den åt dem kan du behöva integrera med företagets identitetsprovider. Ha en tydlig förståelse för dessa aspekter:
- Typerna av användare och deras åtkomstbehov när de interagerar med dina programklientorganisationer. Användare A kanske till exempel bara behöver åtkomst för att logga in på klientorganisation 1, men användare B kan behöva åtkomst för att logga in på både klient 1 och klient 2.
- Efterlevnad av regler för datahemvist, om de gäller för din identitetsprovider. I vissa fall kan data som lagras av en identitetsprovider omfattas av regler. Många identitetsprovidrar ger specifik vägledning och funktioner för det här scenariot. Utvärdera om det här scenariot är relevant för dig och vidta nödvändiga åtgärder för att säkerställa efterlevnad.
Designrekommendationer
| Rekommendation | Förmån |
|---|---|
| Följ din identitetsproviders metodtips och riktlinjer för partitionering av lösningen för flera klienter. | Klientisolering hjälper dig att uppnå dina säkerhets- och efterlevnadsmål. |
| Undvik att ha flera konton för samma användare. En användare bör ha ett enda konto med en uppsättning autentiseringsuppgifter, även om de behöver åtkomst till flera klienter. Bevilja åtkomst till varje klientorganisation efter behov i stället för att skapa flera konton för samma användare. | Att skapa flera konton för samma användare ökar säkerhetsriskerna och kan förvirra användare som behöver komma ihåg flera användarnamn och lösenord för samma programvara. |
| När du överväger datahemvist bör du planera hur du lagrar användardata på separata platser. Om du distribuerar en separat distributionsstämpel för dina användare i andra geografiska områden kan du också behöva separata identitetsprovidrar. Se till att du har ett sätt att identifiera var användarnas data lagras så att du kan dirigera dem till rätt region för inloggning om du behöver det. |
Du kommer att kunna stödja dina efterlevnadskrav och förbättra användarupplevelsen genom att dirigera användare till den inloggningsupplevelse som är lämplig för deras plats. |
Val av identitetsprovider
Varje identitetsprovider erbjuder unika funktioner, begränsningar, prismodeller och implementeringsmönster. Microsoft Entra och Okta är populära IDaaS-alternativ (identitet som en tjänst). Det finns också andra öppen källkod leverantörer, till exempel Keycloak och Authentik.
Utformningsbeaktanden
Dokumentera dina identitetskrav. Börja med att visa de funktioner som ditt program behöver nu och kommer att behöva i framtiden. Vanliga funktioner att tänka på är:
-
- Stöd för federerad identitetsprovider för att integrera med kundernas identitetslösningar. Med den här funktionen kan du undvika att skapa nya identiteter.
- Anpassningsbart inloggnings-/registreringsflöde för att ändra utseendet och känslan för att behålla ditt varumärke. Den här funktionen ger också möjlighet att mata in anpassad affärslogik i inloggnings-/registreringsprocessen.
- Separation av klientdata till distinkta silor för att upprätthålla klientisolering.
- Granska stöd för att behålla eller exportera inloggningsloggar för säkerhetshantering.
Viktigt!
Tänk på din planerade användartillväxt när du utvärderar kostnaden för en identitetslösning. En lösning kanske inte är kostnadseffektiv eller skalbar på lång sikt, men den kan vara användbar för tillfället. Ha en migreringsplan som du kan använda om behovet uppstår.
En lösning kan till exempel vara prisvärd för 500 användare men ohållbar för 5 miljoner. Om det kräver minimal konfiguration och är användarvänligt och enkelt att migrera från kan det fortfarande vara rätt val tills skalningskostnaderna motiverar växling till en annan lösning.
Undersöka identitetsproviderns funktioner noggrant. Kontrollera att identitetslösningen matchar din lista över nödvändiga funktioner. Även om du för närvarande inte behöver komplexa scenarier som federerad identitet bör du överväga framtida behov. För SaaS-lösningar (business-to-business) (B2B) kommer federerad identitet förmodligen att behövas så småningom.
Räkna in hanteringskostnader. Olika identitetsprovidrar kräver olika nivåer av hanteringskostnader. Välkända IDaaS-lösningar har vanligtvis mindre omkostnader eftersom de hanterar värdtjänster, underhåll och säkerhet. Den extra kostnaden för en öppen källkod lösning kan dock vara värdefull om lösningen passar bättre för dina särskilda behov.
Designrekommendationer
| Rekommendation | Förmån |
|---|---|
| Skapa inte en egen identitetslösning. Identitet är ett mycket specialiserat område, och att skapa en identitetslösning är komplext och dyrt. Det är svårt att skapa en identitetslösning som är säker och tillförlitlig. | Du undviker antimönstret för att skapa en egen leverantör och förbättra säkerheten, tillförlitligheten och drifteffektiviteten för din lösning. |
| Skapa en funktionsmatris för de funktioner som erbjuds av identitetsprovidrar och mappa den mot dina identitetskrav. | Du ser till att du kan utvecklas utan att begränsas av en begränsad uppsättning identitetsfunktioner. |
| Föredrar IDaaS-alternativ framför öppen källkod lösningar. Att vara värd för en öppen källkod lösning själv medför betydande driftkostnader och säkerhetsrisker. Du kan dock välja det alternativet för att uppfylla specifika krav för efterlevnad, datahemvist eller tillförlitlighet som en leverantör inte kan uppfylla. Mer information finns i IDaaS-identitetsprovidrar. |
Genom att använda en IDaaS-identitetsprovider undviker du onödig komplexitet och kan fokusera dina ansträngningar på kärnverksamheten. |
Federerad identitet
Federerad identitet, även kallad enkel inloggning (SSO), gör det möjligt för användare att logga in med autentiseringsuppgifter som de redan använder någon annanstans. Du aktiverar federerad identitet genom att upprätta en förtroenderelation mellan din programidentitetsprovider och kundens befintliga identitetsprovider. Federerad identitet är ett vanligt krav för SaaS-lösningar, särskilt i B2B, eftersom kunderna föredrar att deras anställda använder företagets autentiseringsuppgifter. Det erbjuder flera fördelar för B2B-lösningar, till exempel centraliserad identitetshantering och automatisk livscykelhantering. I B2C SaaS-produkter är integrering med sociala identitetsprovidrar vanligt för att tillåta användare att logga in med befintliga autentiseringsuppgifter.
Kompromiss: Komplexitet och driftseffektivitet. Genom att arbeta med federerade identitetsprovidrar avlastar du komplexiteten i att hantera användarnas identiteter. Men du tar på dig kostnaden för att integrera med en annan identitetsprovider. Bestäm var du vill fokusera ditt operativa arbete.
Även om det till en början är enkelt att implementera federerad identitet blir det mer komplext när antalet identitetsprovidrar som stöds ökar. Noggrann planering är viktigt, särskilt om varje kund använder en unik identitetsprovider. Även om de använder samma identitetsprovider krävs ofta unika förtroenderelationer för varje kund på grund av specifik konfigurationsinformation.
Den här bilden visar relationen mellan ditt program, din programidentitetsprovider och de underordnade identitetsprovidrar som du kan välja att implementera med hjälp av identitetsfederation.
Utformningsbeaktanden
Uppskatta vilka typer och antal identitetsprovidrar som du behöver stöd för. Du kan behöva ett statiskt antal sociala identitetsprovidrar, eller så kan du behöva unika federerade identitetsprovidrar för varje kund. Du bör veta om dina kunder kommer att använda OpenID Connect (OIDC), SAML (Security Assertion Markup Language) eller båda för integrering.
Mappa ut inloggningsupplevelsen. Visualisera användarflödet för registrering och inloggning. Observera eventuella särskilda krav som kan ändra användarflödesdesignen. Till exempel:
Anpassad varumärkesanpassning. Vit etikettering eller anpassade inloggningsdomäner per kund.
Anpassad information. Samla in ytterligare användarinformation under registrering eller inloggning, till exempel val av klientorganisation för användare med åtkomst till flera klienter.
Val av identitetsprovider. Om du använder en enda programidentitetsprovider som har många federerade identitetsprovidrar som litar på den bestämmer du hur du väljer en provider. Det här valet kan göras manuellt via en knapp eller automatiskt baserat på känd användarinformation. I takt med att antalet leverantörer ökar blir det automatiska urvalet mer praktiskt. Den här funktionen kallas för Identifiering av hemsfär.
Designrekommendationer
| Rekommendation | Förmån |
|---|---|
| Välj en identitetsprovider som kan skalas för att hantera det antal federerade identitetsprovidrar som du behöver. Tänk på leverantörens hårda gränser, som inte kan överskridas. |
Du ser till att din identitetslösning kan skalas när du växer. |
| Planera registrering av varje federerad identitetsprovider och automatisera processen så mycket som möjligt. Det här samarbetet mellan din organisation och dina kunder innebär att utbyta information för att upprätta en förtroenderelation, vanligtvis via OIDC- eller SAML-protokoll. |
Identitetsintegrering kan ta tid och arbete för både dig och dina kunder. Genom att planera processen förbättrar du drifteffektiviteten. |
| Återspegla komplexiteten och kostnaden för federerad identitet i din prissättning och affärsmodell. Att tillåta kunder att använda sin egen identitetsprovider ökar driftkomplexiteten och kostnaderna på grund av omkostnaderna för att upprätthålla flera federerade identitetsförtroenderelationer. Det är vanligt i SaaS-lösningar att företag betalar för en högre nivå som möjliggör federerad inloggning. |
Att federera med en kunds identitetsprovider kan vara en dold kostnad i SaaS-lösningar. Genom att planera för det undviker du oväntade kostnader under implementeringen. |
| Planera hur en användares identitetsprovider ska väljas under inloggningsflödet. Överväg att använda Home Realm Discovery. Microsoft Entra ID tillhandahåller inbyggd Identifiering av hemsfär. |
Du effektiviserar din kundupplevelse och ser till att användarna dirigeras till rätt inloggningsprocess. |
Auktorisering
Användarauktorisering är avgörande för SaaS-program, som ofta lagrar data för flera klienter. Definiera tydligt hur användarna ska ha behörighet att endast komma åt sina data utan att oavsiktligt komma åt andra klientorganisationers data. Ge dessutom detaljerad auktorisering i en klientorganisation, så att användarna kan läsa eller komma åt viss information samtidigt som uppdateringar eller åtkomst till andra data begränsas.
Utformningsbeaktanden
Välj rätt auktoriseringsmodell för användningsfallet. Det finns två huvudtyper:
- Rollbaserad auktorisering. Användare tilldelas roller eller grupper och specifika funktioner är begränsade till vissa roller. Administratörer kan till exempel utföra alla åtgärder, men användare i andra roller har begränsade behörigheter.
- Resursbaserad auktorisering. Varje resurs har en egen uppsättning behörigheter. En användare kan vara administratör för en resurs men har ingen åtkomst till en annan.
Bestäm var auktoriseringsdata ska lagras. Auktoriseringsdata för ditt program kan lagras i:
- Din identitetsprovider. Dra nytta av de inbyggda grupperna eller rollerna och visa behörigheter som anspråk i den token som utfärdats till ditt program. Ditt program kan sedan framtvinga auktoriseringsregler med hjälp av dessa tokenanspråk.
- Ditt program. Utveckla din egen auktoriseringslogik och lagra användarbehörigheter i en databas eller liknande system, vilket möjliggör detaljerade rollbaserade eller resursnivåauktoriseringskontroller.
Kompromiss: Komplexitet, flexibilitet och säkerhet. Att lagra auktoriseringsdata i en identitetsprovider och dyka upp via tokenanspråk är vanligtvis enklare än att hantera ditt eget auktoriseringssystem. Anspråksbaserad auktorisering begränsar dock din flexibilitet och du måste acceptera att anspråk endast uppdateras när en token utfärdas på nytt, vilket kan orsaka en fördröjning i tillämpningen av ändrade behörigheter.Utvärdera effekten av delegerad hantering. I de flesta SaaS-program, särskilt i B2B-program, delegeras roll- och behörighetshantering till kunder. Utan den här funktionen kan du öka hanteringskostnaderna om kunderna ofta ändrar sina användares behörigheter.
Utvärdera åtkomst för flera klientorganisationer. I vissa system kan en enskild användare behöva komma åt data från flera klienter. Konsulter kan till exempel behöva komma åt data från flera klienter. Planera hur kunderna ska bevilja åtkomst till dessa användare och hur ditt inloggningsflöde ska stödja val och växling mellan klienter.
Designrekommendationer
| Rekommendation | Förmån |
|---|---|
| Hindra användare från att komma åt data över klientorganisationens gränser om inte den åtkomsten uttryckligen tillåts. | Obehörig åtkomst till en annan klients data, även oavsiktlig åtkomst, kan ses som en större säkerhetsincident och urholka kundernas förtroende för din plattform. Om du blockerar onödig åtkomst kan du undvika dessa situationer. |
| Om data är statiska och ändras sällan lagrar du dem i identitetsprovidern. Om det behövs frekventa ändringar när användaren använder programvaran lagrar du auktoriseringsdata i ditt program. | Om du väljer det bästa datalagret för dina auktoriseringsdata ökar du drifteffektiviteten och hjälper dig att uppfylla dina skalbarhetsbehov. |
| Om du delegerar behörighetshantering till kunder anger du en tydlig metod för att hantera behörigheter. Skapa till exempel en webbportal som endast är tillgänglig för klientadministratörer för att ändra användarbehörigheter. | Du ger dina kunder mer kontroll och undviker onödig driftbelastning för supportteamet. |
Ytterligare resurser
Multitenancy är en viktig affärsmetod för att utforma SaaS-arbetsbelastningar. De här artiklarna innehåller mer information om identitets- och åtkomsthantering:
- Arkitekturöverväganden för identitet i lösningar med flera klienter
- Arkitekturmetoder för identitet i lösningar för flera klientorganisationer
Gå vidare
Lär dig mer om att välja din beräkningsvärdmodell, driftaspekterna och hur du optimerar teknikalternativen för att hjälpa dig att uppfylla dina serviceavtal och mål.