Bewerken

Aanvragen toewijzen aan tenants in een multitenant-oplossing

Azure

Wanneer een aanvraag binnenkomt in uw toepassing, moet u de tenant bepalen waarvoor de aanvraag is bedoeld. Wanneer u een tenantspecifieke infrastructuur hebt die zelfs in verschillende geografische regio's kan worden gehost, moet u de binnenkomende aanvraag aan een tenant koppelen. Vervolgens moet u de aanvraag doorsturen naar de fysieke infrastructuur die als host fungeert voor de resources van die tenant, zoals hieronder wordt geïllustreerd:

Diagram showing mapping a request from tenants to deployments.

Op deze pagina bieden we richtlijnen voor technische besluitvormers over de benaderingen die u kunt overwegen om aanvragen toe te wijzen aan de juiste tenant en de compromissen die betrokken zijn bij de benaderingen.

Notitie

Op deze pagina worden voornamelijk HTTP-toepassingen besproken, zoals websites en API's. Veel van dezelfde onderliggende principes zijn echter van toepassing op multitenant-toepassingen die gebruikmaken van andere communicatieprotocollen.

Methoden voor het identificeren van tenants

Er zijn meerdere manieren waarop u de tenant kunt identificeren voor een binnenkomende aanvraag.

Domeinnamen

Als u tenantspecifieke domein- of subdomeinnamen gebruikt, kunnen aanvragen waarschijnlijk eenvoudig worden toegewezen aan tenants met behulp van de Host header of een andere HTTP-header die de oorspronkelijke hostnaam voor elke aanvraag bevat.

Houd echter rekening met de volgende vragen:

  • Hoe weten gebruikers welke domeinnaam moet worden gebruikt voor toegang tot de service?
  • Hebt u een centraal toegangspunt, zoals een landingspagina of aanmeldingspagina, die alle tenants gebruiken? Als u dit doet, hoe identificeren gebruikers de tenant waartoe ze toegang nodig hebben?
  • Welke andere informatie gebruikt u om de toegang tot de tenant te verifiëren, zoals autorisatietokens? Bevatten de autorisatietokens de tenantspecifieke domeinnamen?

Eigenschappen van HTTP-aanvraag

Als u geen tenantspecifieke domeinnamen gebruikt, kunt u mogelijk nog steeds aspecten van de HTTP-aanvraag gebruiken om de tenant te identificeren waarvoor een bepaalde aanvraag is bedoeld. Denk bijvoorbeeld aan een HTTP-aanvraag die de naam van de tenant identificeert als tailwindtraders. Dit kan worden gecommuniceerd met behulp van het volgende:

  • De URL-padstructuur, zoals https://app.contoso.com/tailwindtraders/.
  • Een queryreeks in de URL, zoals https://contoso.com/app?tenant=tailwindtraders.
  • Een aangepaste HTTP-aanvraagheader, zoals X-Tenant-Id: tailwindtraders.

Belangrijk

Aangepaste HTTP-aanvraagheaders zijn niet handig wanneer HTTP GET-aanvragen worden uitgegeven vanuit een webbrowser of waarbij de aanvragen worden verwerkt door bepaalde typen webproxy. Gebruik alleen aangepaste HTTP-headers voor GET-bewerkingen wanneer u een API bouwt of als u de client beheert die de aanvraag uitgeeft en er geen webproxy is opgenomen in de aanvraagverwerkingsketen.

Wanneer u deze methode gebruikt, moet u rekening houden met de volgende vragen:

  • Weten gebruikers hoe ze toegang hebben tot de service? Als u bijvoorbeeld een queryreeks gebruikt om tenants te identificeren, moet een centrale landingspagina gebruikers doorsturen naar de juiste tenant door de querytekenreeks toe te voegen?
  • Hebt u een centraal toegangspunt, zoals een landingspagina of aanmeldingspagina, die alle tenants gebruiken? Als u dit doet, hoe identificeren gebruikers de tenant waartoe ze toegang nodig hebben?
  • Biedt uw toepassing API's? Is uw webtoepassing bijvoorbeeld een toepassing met één pagina (SPA) of een mobiele toepassing met een API-back-end? Als dat zo is, kunt u mogelijk een API-gateway of omgekeerde proxy gebruiken om tenanttoewijzing uit te voeren.

Tokenclaims

Veel toepassingen gebruiken verificatie- en autorisatieprotocollen op basis van claims, zoals OAuth 2.0 of SAML. Deze protocollen bieden autorisatietokens aan de client. Een token bevat een set claims, die stukjes informatie over de clienttoepassing of gebruiker zijn. Claims kunnen worden gebruikt om informatie te communiceren, zoals het e-mailadres van een gebruiker. Uw systeem kan vervolgens het e-mailadres van de gebruiker bevatten, de toewijzing van de gebruiker naar tenant opzoeken en vervolgens de aanvraag doorsturen naar de juiste implementatie. Of u kunt zelfs de tenanttoewijzing opnemen in uw identiteitssysteem en een tenant-id-claim toevoegen aan het token.

Als u claims gebruikt om aanvragen toe te wijzen aan tenants, moet u rekening houden met de volgende vragen:

  • Gebruikt u een claim om een tenant te identificeren? Welke claim gebruikt u?
  • Kan een gebruiker lid zijn van meerdere tenants? Als dit mogelijk is, hoe selecteren gebruikers dan de tenants waarmee ze willen werken?
  • Is er een centraal verificatie- en autorisatiesysteem voor alle tenants? Zo niet, hoe zorgt u ervoor dat alle tokenautoriteiten consistente tokens en claims uitgeven?

API-sleutels

Veel toepassingen maken API's beschikbaar. Dit kan zijn voor intern gebruik binnen uw organisatie of voor extern gebruik door partners of klanten. Een veelgebruikte verificatiemethode voor API's is het gebruik van een API-sleutel. API-sleutels worden geleverd bij elke aanvraag en kunnen worden gebruikt om de tenant op te zoeken.

API-sleutels kunnen op verschillende manieren worden gegenereerd. Een veelvoorkomende benadering is het genereren van een cryptografische willekeurige waarde en het opslaan in een opzoektabel, naast de tenant-id. Wanneer een aanvraag wordt ontvangen, zoekt uw systeem de API-sleutel in de opzoektabel en komt deze vervolgens overeen met een tenant-id. Een andere benadering is het maken van een zinvolle tekenreeks met daarin een tenant-id en vervolgens zou u de sleutel digitaal ondertekenen met behulp van een benadering zoals HMAC. Wanneer u elke aanvraag verwerkt, controleert u de handtekening en extraheert u vervolgens de tenant-id.

Notitie

API-sleutels bieden geen hoog beveiligingsniveau omdat ze handmatig moeten worden gemaakt en beheerd en omdat ze geen claims bevatten. Een modernere en veilige benadering is het gebruik van een autorisatiemechanisme op basis van claims met kortstondige tokens, zoals OAuth 2.0 of OpenID Verbinding maken.

Denk na over de volgende vragen:

  • Hoe genereert en geeft u API-sleutels uit?
  • Hoe ontvangen en opslaan uw API-clients de API-sleutel veilig?
  • Hebt u uw API-sleutels nodig om na een bepaalde periode te verlopen? Hoe draait u de API-sleutels van uw clients zonder downtime te veroorzaken?
  • Vertrouwt u alleen op door de klant gerollde API-sleutels voor voldoende beveiliging voor uw API's?

Notitie

API-sleutels zijn niet hetzelfde als wachtwoorden. API-sleutels moeten worden gegenereerd door het systeem en moeten uniek zijn in alle tenants, zodat elke API-sleutel uniek kan worden toegewezen aan één tenant. API-gateways, zoals Azure API Management, kunnen API-sleutels genereren en beheren, sleutels valideren voor binnenkomende aanvragen en sleutels toewijzen aan afzonderlijke API-abonnees.

Clientcertificaten

Verificatie van clientcertificaten, ook wel wederzijdse TLS (mTLS) genoemd, wordt vaak gebruikt voor service-naar-service-communicatie. Clientcertificaten bieden een veilige manier om clients te verifiëren. Net als bij tokens en claims bieden clientcertificaten kenmerken die kunnen worden gebruikt om de tenant te bepalen. Het onderwerp van het certificaat kan bijvoorbeeld het e-mailadres van de gebruiker bevatten, dat kan worden gebruikt om de tenant op te zoeken.

Houd rekening met het volgende bij het gebruik van clientcertificaten voor tenanttoewijzing:

  • Hoe kunt u de clientcertificaten die worden vertrouwd door uw service veilig uitgeven en vernieuwen? Clientcertificaten kunnen complex zijn om mee te werken, omdat ze speciale infrastructuur nodig hebben om certificaten te beheren en uit te geven.
  • Worden clientcertificaten alleen gebruikt voor initiële aanmeldingsaanvragen of worden deze gekoppeld aan alle aanvragen voor uw service?
  • Wordt het proces voor het uitgeven en beheren van certificaten onbeheerbaar wanneer u een groot aantal clients hebt?
  • Hoe implementeert u de toewijzing tussen het clientcertificaat en de tenant?

Omgekeerde proxy's

Een omgekeerde proxy, ook wel een toepassingsproxy genoemd, kan worden gebruikt om HTTP-aanvragen te routeren. Een omgekeerde proxy accepteert een aanvraag van een inkomend eindpunt en kan de aanvraag doorsturen naar een van de vele back-endeindpunten. Omgekeerde proxy's zijn handig voor toepassingen met meerdere tenants, omdat ze de toewijzing tussen een deel van de aanvraaggegevens kunnen uitvoeren, waarbij de taak wordt offload vanuit uw toepassingsinfrastructuur.

Veel omgekeerde proxy's kunnen de eigenschappen van een aanvraag gebruiken om een beslissing te nemen over tenantroutering. Ze kunnen de doeldomeinnaam, het URL-pad, de querytekenreeks, HTTP-headers en zelfs claims binnen tokens inspecteren.

De volgende algemene omgekeerde proxy's worden gebruikt in Azure:

  • Azure Front Door is een globale load balancer en web application firewall. Het maakt gebruik van het wereldwijde edge-netwerk van Microsoft om snelle, veilige en zeer schaalbare webtoepassingen te maken.
  • Azure-toepassing Gateway is een load balancer voor beheerd webverkeer die u implementeert in dezelfde fysieke regio als uw back-endservice.
  • Azure API Management is geoptimaliseerd voor API-verkeer.
  • Commerciële en opensourcetechnologieën (die u zelf hosten) omvatten nginx, Traefik en HAProxy.

Aanvraagvalidatie

Het is belangrijk dat uw toepassing valideert dat aanvragen die worden ontvangen, zijn geautoriseerd voor de tenant. Als uw toepassing bijvoorbeeld een aangepaste domeinnaam gebruikt om aanvragen toe te wijzen aan de tenant, moet uw toepassing nog steeds controleren of elke aanvraag die door de toepassing is ontvangen, is geautoriseerd voor die tenant. Hoewel de aanvraag een domeinnaam of andere tenant-id bevat, betekent dit niet dat u automatisch toegang moet verlenen. Wanneer u OAuth 2.0 gebruikt, voert u de validatie uit door de doelgroep en bereikclaims te inspecteren.

Notitie

Dit maakt deel uit van het principe van zero trust security design in het Microsoft Azure Well-Architected Framework.

Bij het implementeren van aanvraagvalidatie moet u rekening houden met het volgende:

  • Hoe autoriseert u alle aanvragen voor uw toepassing? U moet aanvragen autoriseren, ongeacht de benadering die u gebruikt om deze toe te wijzen aan de fysieke infrastructuur.
  • Gebruik vertrouwde, veelgebruikte en goed onderhouden verificatie- en autorisatieframeworks en middleware in plaats van alle validatielogica zelf te implementeren. Bouw bijvoorbeeld geen validatielogica voor tokenhandtekeningen of cryptografiebibliotheken van clientcertificaten. Gebruik in plaats daarvan functies van uw toepassingsplatform (of bekende vertrouwde pakketten) die zijn gevalideerd en getest.

Prestaties

Tenanttoewijzingslogica wordt waarschijnlijk uitgevoerd op elke aanvraag voor uw toepassing. Bedenk hoe goed het tenanttoewijzingsproces schaalt, naarmate uw oplossing groeit. Als u bijvoorbeeld een query uitvoert op een databasetabel als onderdeel van uw tenanttoewijzing, ondersteunt de database een grote hoeveelheid belasting? Als uw tenanttoewijzing het ontsleutelen van een token vereist, worden de rekenvereisten na verloop van tijd te hoog? Als uw verkeer redelijk bescheiden is, is dit waarschijnlijk niet van invloed op uw algehele prestaties. Wanneer u echter een toepassing op grote schaal hebt, kan de overhead die betrokken is bij deze toewijzing aanzienlijk worden.

Sessieaffiniteit

Eén benadering om de prestatieoverhead van tenanttoewijzingslogica te verminderen, is door sessieaffiniteit te gebruiken. In plaats van de toewijzing voor elke aanvraag uit te voeren, kunt u overwegen om alleen de informatie op de eerste aanvraag voor elke sessie te berekenen. Uw toepassing biedt vervolgens een sessiecooky aan de client. De client geeft de sessiecooky weer door aan uw service met alle volgende clientaanvragen binnen die sessie.

Notitie

Veel netwerk- en toepassingsservices in Azure kunnen sessiecookies uitgeven en aanvragen systeemeigen routeren met behulp van sessieaffiniteit.

Denk na over de volgende vragen:

  • Kunt u sessieaffiniteit gebruiken om de overhead van toewijzingsaanvragen aan tenants te verminderen?
  • Welke services gebruikt u om aanvragen naar de fysieke implementaties voor elke tenant te routeren? Ondersteunen deze services sessieaffiniteit op basis van cookies?

Tenantmigratie

Tenants moeten vaak worden verplaatst naar een nieuwe infrastructuur als onderdeel van de levenscyclus van de tenant. Wanneer een tenant wordt verplaatst naar een nieuwe implementatie, kunnen de HTTP-eindpunten die ze openen, worden gewijzigd. Wanneer dit gebeurt, moet uw tenanttoewijzingsproces worden bijgewerkt. Mogelijk moet u rekening houden met het volgende:

  • Als uw toepassing domeinnamen gebruikt voor toewijzingsaanvragen, is mogelijk ook een DNS-wijziging vereist op het moment van de migratie. Het kan even duren voordat de DNS-wijziging wordt doorgegeven aan clients, afhankelijk van de time-to-live van de DNS-vermeldingen in uw DNS-service.
  • Als uw migratie de adressen van eindpunten tijdens het migratieproces wijzigt, kunt u overwegen om aanvragen voor de tenant tijdelijk om te leiden naar een onderhoudspagina die automatisch wordt vernieuwd.

Bijdragers

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

Hoofdauteur:

Andere Inzenders:

Als u niet-openbare LinkedIn-profielen wilt zien, meldt u zich aan bij LinkedIn.

Volgende stappen

Meer informatie over overwegingen bij het werken met domeinnamen in een multitenant-toepassing.