Redigera

Dela via

Mappa begäranden till klienter i en lösning med flera klienter

Azure

När en begäran kommer till ditt program måste du fastställa klientorganisationen som begäran är avsedd för. När du har en klientspecifik infrastruktur som till och med kan finnas i olika geografiska regioner måste du matcha den inkommande begäran till en klientorganisation. Sedan måste du vidarebefordra begäran till den fysiska infrastruktur som är värd för klientorganisationens resurser, enligt nedan:

Diagram som visar mappning av en begäran från klientorganisationer till distributioner.

På den här sidan ger vi vägledning till tekniska beslutsfattare om de metoder som du kan överväga för att mappa begäranden till lämplig klientorganisation och de kompromisser som ingår i metoderna.

Kommentar

På den här sidan diskuteras främst HTTP-baserade program, till exempel webbplatser och API:er. Många av samma underliggande principer gäller dock för program med flera klienter som använder andra kommunikationsprotokoll.

Metoder för att identifiera klienter

Det finns flera sätt att identifiera klientorganisationen för en inkommande begäran.

Domännamn

Om du använder klientspecifika domän- eller underdomännamn är det troligt att begäranden enkelt kan mappas till klienter med hjälp Host av huvudet eller ett annat HTTP-huvud som innehåller det ursprungliga värdnamnet för varje begäran.

Tänk dock på följande frågor:

  • Hur vet användarna vilket domännamn som ska användas för att komma åt tjänsten?
  • Har du en central startpunkt, till exempel en landningssida eller inloggningssida, som alla klienter använder? Om du gör det, hur identifierar användarna den klientorganisation som de behöver åtkomst till?
  • Vilken annan information använder du för att verifiera åtkomsten till klientorganisationen, till exempel auktoriseringstoken? Innehåller auktoriseringstoken de klientspecifika domännamnen?

Egenskaper för HTTP-begäran

Om du inte använder klientspecifika domännamn kanske du fortfarande kan använda aspekter av HTTP-begäran för att identifiera klientorganisationen som en viss begäran gäller. Du kan till exempel överväga en HTTP-begäran som identifierar klientnamnet som tailwindtraders. Detta kan kommuniceras med hjälp av följande:

  • URL-sökvägsstrukturen, till exempel https://app.contoso.com/tailwindtraders/.
  • En frågesträng i URL:en, till exempel https://contoso.com/app?tenant=tailwindtraders.
  • Ett anpassat HTTP-begärandehuvud, till exempel Tenant-Id: tailwindtraders.

Viktigt!

Anpassade HTTP-begärandehuvuden är inte användbara när HTTP GET-begäranden utfärdas från en webbläsare eller där begäranden hanteras av vissa typer av webbproxy. Du bör bara använda anpassade HTTP-huvuden för GET-åtgärder när du skapar ett API, eller om du styr klienten som utfärdar begäran och det inte finns någon webbproxy i bearbetningskedjan för begäran.

När du använder den här metoden bör du överväga följande frågor:

  • Vet användarna hur de ska komma åt tjänsten? Om du till exempel använder en frågesträng för att identifiera klienter måste en central landningssida dirigera användare till rätt klientorganisation genom att lägga till frågesträngen?
  • Har du en central startpunkt, till exempel en landningssida eller inloggningssida, som alla klienter använder? Om du gör det, hur identifierar användarna den klientorganisation som de behöver åtkomst till?
  • Tillhandahåller ditt program API:er? Är ditt webbprogram till exempel ett ensidesprogram (SPA) eller ett mobilprogram med en API-serverdel? I så fall kanske du kan använda en API-gateway eller omvänd proxy för att utföra klientmappning.

Tokenanspråk

Många program använder anspråksbaserad autentisering och auktoriseringsprotokoll, till exempel OAuth 2.0 eller SAML. Dessa protokoll tillhandahåller auktoriseringstoken till klienten. En token innehåller en uppsättning anspråk, som är information om klientprogrammet eller användaren. Anspråk kan användas för att kommunicera information som en användares e-postadress. Systemet kan sedan inkludera användarens e-postadress, leta upp mappningen mellan användare och klientorganisation och sedan vidarebefordra begäran till lämplig distribution. Eller så kan du till och med inkludera klientmappningen i ditt identitetssystem och lägga till ett klient-ID-anspråk i token.

Om du använder anspråk för att mappa begäranden till klientorganisationer bör du överväga följande frågor:

  • Kommer du att använda ett anspråk för att identifiera en klientorganisation? Vilket anspråk ska du använda?
  • Kan en användare vara medlem i flera klientorganisationer? Om detta är möjligt, hur väljer användarna de klienter som de vill arbeta med?
  • Finns det ett centralt autentiserings- och auktoriseringssystem för alla klienter? Om inte, hur ser du till att alla tokenmyndigheter utfärdar konsekventa token och anspråk?

API-nycklar

Många program exponerar API:er. Dessa kan vara för internt bruk i din organisation eller för extern användning av partner eller kunder. En vanlig autentiseringsmetod för API:er är att använda en API-nyckel. API-nycklar tillhandahålls med varje begäran och de kan användas för att leta upp klientorganisationen.

API-nycklar kan genereras på flera sätt. En vanlig metod är att generera ett kryptografiskt slumpmässigt värde och lagra det i en uppslagstabell, tillsammans med klientorganisations-ID:t. När en begäran tas emot hittar systemet API-nyckeln i uppslagstabellen och matchar den sedan med ett klient-ID. En annan metod är att skapa en meningsfull sträng med ett klient-ID som ingår i den, och sedan signera nyckeln digitalt med hjälp av en metod som HMAC. När du bearbetar varje begäran verifierar du signaturen och extraherar sedan klientorganisations-ID:t.

Kommentar

API-nycklar ger ingen hög säkerhetsnivå eftersom de måste skapas och hanteras manuellt och eftersom de inte innehåller anspråk. En modernare och säkrare metod är att använda en anspråksbaserad auktoriseringsmekanism med kortlivade token, till exempel OAuth 2.0 eller OpenID Connect.

Överväg följande frågor:

  • Hur genererar och utfärdar du API-nycklar?
  • Hur tar dina API-klienter emot och lagrar API-nyckeln på ett säkert sätt?
  • Behöver du att dina API-nycklar upphör att gälla efter en viss tidsperiod? Hur roterar du dina klienters API-nycklar utan att orsaka stilleståndstid?
  • Ger bara förlitande av kundvalsade API-nycklar en lämplig säkerhetsnivå för dina API:er?

Kommentar

API-nycklar är inte samma som lösenord. API-nycklar måste genereras av systemet och de måste vara unika för alla klienter, så att varje API-nyckel kan mappas unikt till en enda klientorganisation. API-gatewayer, till exempel Azure API Management, kan generera och hantera API-nycklar, verifiera nycklar på inkommande begäranden och mappa nycklar till enskilda API-prenumeranter.

Klientcertifikat

Klientcertifikatautentisering, som ibland kallas ömsesidig TLS (mTLS), används ofta för tjänst-till-tjänst-kommunikation. Klientcertifikat är ett säkert sätt att autentisera klienter. På samma sätt som token och anspråk tillhandahåller klientcertifikat attribut som kan användas för att fastställa klientorganisationen. Certifikatets ämne kan till exempel innehålla användarens e-postadress, som kan användas för att söka efter klientorganisationen.

När du planerar att använda klientcertifikat för klientmappning bör du tänka på följande:

  • Hur kan du på ett säkert sätt utfärda och förnya klientcertifikaten som är betrodda av din tjänst? Klientcertifikat kan vara komplexa att arbeta med, eftersom de kräver särskild infrastruktur för att hantera och utfärda certifikat.
  • Kommer klientcertifikat endast att användas för inledande inloggningsbegäranden eller kopplas till alla begäranden till din tjänst?
  • Kommer processen med att utfärda och hantera certifikat att bli ohanterlig när du har ett stort antal klienter?
  • Hur implementerar du mappningen mellan klientcertifikatet och klientorganisationen?

Omvända proxyservrar

En omvänd proxy, även kallad programproxy, kan användas för att dirigera HTTP-begäranden. En omvänd proxy accepterar en begäran från en ingressslutpunkt och kan vidarebefordra begäran till en av många serverdelsslutpunkter. Omvända proxyservrar är användbara för program med flera klienter eftersom de kan utföra mappningen mellan viss information om begäranden och avlasta uppgiften från programinfrastrukturen.

Många omvända proxyservrar kan använda egenskaperna för en begäran för att fatta ett beslut om klientdirigering. De kan granska måldomännamnet, URL-sökvägen, frågesträngen, HTTP-huvuden och till och med anspråk inom token.

Följande vanliga omvända proxyservrar används i Azure:

  • Azure Front Door är en global lastbalanserare och brandvägg för webbprogram. Det använder Microsofts globala edge-nätverk för att skapa snabba, säkra och mycket skalbara webbprogram.
  • Azure Application Gateway är en hanterad lastbalanserare för webbtrafik som du distribuerar till samma fysiska region som serverdelstjänsten.
  • Azure API Management är optimerat för API-trafik.
  • Kommersiella tekniker och tekniker med öppen källkod (som du är värd för själv) omfattar nginx, Traefik och HAProxy.

Begäran om validering

Det är viktigt att ditt program verifierar att alla begäranden som det tar emot är auktoriserade för klientorganisationen. Om ditt program till exempel använder ett anpassat domännamn för att mappa begäranden till klientorganisationen måste programmet fortfarande kontrollera att varje begäran som tas emot av programmet är auktoriserad för den klientorganisationen. Även om begäran innehåller ett domännamn eller annan klientidentifierare betyder det inte att du automatiskt ska bevilja åtkomst. När du använder OAuth 2.0 utför du verifieringen genom att granska målgrupps- och omfångsanspråken.

Kommentar

Detta är en del av principen för att anta noll förtroende för säkerhetsdesign i Microsoft Azure Well-Architected Framework.

När du implementerar validering av begäranden bör du överväga följande:

  • Hur kommer du att auktorisera alla begäranden till ditt program? Du måste auktorisera begäranden, oavsett vilken metod du använder för att mappa dem till fysisk infrastruktur.
  • Använd betrodda, allmänt använda och väl underhållna autentiserings- och auktoriseringsramverk och mellanprogram, i stället för att implementera all valideringslogik själv. Skapa till exempel inte valideringslogik för tokensignatur eller kryptografibibliotek för klientcertifikat. Använd i stället funktioner för din programplattform (eller kända betrodda paket) som har verifierats och testats.

Prestanda

Logik för klientmappning körs troligen på varje begäran till ditt program. Fundera på hur väl klientmappningsprocessen kommer att skalas i takt med att lösningen växer. Om du till exempel kör frågor mot en databastabell som en del av klientmappningen, kommer databasen att ha stöd för en stor mängd belastning? Kommer beräkningskraven att bli för höga över tid om klientmappningen kräver dekryptering av en token? Om din trafik är ganska blygsam kommer detta sannolikt inte att påverka din övergripande prestanda. När du har ett storskaligt program kan dock kostnaderna för den här mappningen bli betydande.

Sessionstillhörighet

En metod för att minska prestandakostnaderna för klientmappningslogik är att använda sessionstillhörighet. I stället för att utföra mappningen på varje begäran bör du överväga att endast beräkna informationen på den första begäran för varje session. Ditt program tillhandahåller sedan en sessionscookie till klienten. Klienten skickar sessionscookien tillbaka till din tjänst med alla efterföljande klientbegäranden inom den sessionen.

Kommentar

Många nätverk och programtjänster i Azure kan utfärda sessionscookies och dirigera inbyggda begäranden med hjälp av sessionstillhörighet.

Överväg följande frågor:

  • Kan du använda sessionstillhörighet för att minska kostnaderna för att mappa begäranden till klientorganisationer?
  • Vilka tjänster använder du för att dirigera begäranden till de fysiska distributionerna för varje klientorganisation? Stöder dessa tjänster cookiebaserad sessionstillhörighet?

Klientmigrering

Klienter behöver ofta flyttas till ny infrastruktur som en del av klientorganisationens livscykel. När en klientorganisation flyttas till en ny distribution kan DE HTTP-slutpunkter som de kommer åt ändras. När detta händer bör du tänka på att processen för klientmappning måste uppdateras. Du kan behöva tänka på följande:

  • Om ditt program använder domännamn för mappningsbegäranden kan det också kräva en DNS-ändring vid tidpunkten för migreringen. DNS-ändringen kan ta tid att sprida till klienter, beroende på tidsåtgången för DNS-posterna i DNS-tjänsten.
  • Om din migrering ändrar adresserna för alla slutpunkter under migreringsprocessen kan du överväga att tillfälligt omdirigera begäranden för klientorganisationen till en underhållssida som uppdateras automatiskt.

Deltagare

Den här artikeln underhålls av Microsoft. Det har ursprungligen skrivits av följande medarbetare.

Huvudförfattare:

Övriga medarbetare:

Om du vill se icke-offentliga LinkedIn-profiler loggar du in på LinkedIn.

Nästa steg

Lär dig mer om överväganden när du arbetar med domännamn i ett program med flera klienter.