Delen via

Architectuurbenaderingen voor netwerken in multitenant-oplossingen

  • Artikel

Voor alle oplossingen die zijn geïmplementeerd in Azure, is een netwerk van een soort vereist. Afhankelijk van het ontwerp van uw oplossing en de workload kunnen de manieren waarop u met de netwerkservices van Azure communiceert, verschillen. In dit artikel bieden we overwegingen en richtlijnen voor de netwerkaspecten van multitenant-oplossingen in Azure. We bevatten informatie over de netwerkonderdelen op lager niveau, zoals virtuele netwerken, tot benaderingen op hoger niveau en toepassingslaag.

Notitie

Azure zelf is een omgeving met meerdere tenants en de netwerkonderdelen van Azure zijn ontworpen voor multitenancy. Hoewel het niet vereist is om inzicht te krijgen in de details om uw eigen oplossing te ontwerpen, kunt u meer informatie krijgen over hoe Azure uw virtuele netwerkverkeer van verkeer van andere klanten isoleert.

Belangrijke overwegingen en vereisten

Infrastructuur- en platformservices

De zorgen voor uw netwerkonderdelen verschillen, afhankelijk van de categorie services die u gebruikt.

Infrastructuurservices

Wanneer u infrastructuurservices, zoals virtuele machines of Azure Kubernetes Service, gebruikt, moet u de virtuele netwerken, of VNets, overwegen en ontwerpen die de connectiviteit van uw services ondersteunen. U moet ook rekening houden met de andere beveiligings- en isolatielagen die u in uw ontwerp moet opnemen. Vermijd uitsluitend afhankelijk te zijn van netwerklaagbesturingselementen.

Platformservices

Als u de platformservices van Azure gebruikt, zoals App Service, Azure Cosmos DB of Azure SQL Database, bepaalt de specifieke architectuur die u gebruikt de netwerkservices die u nodig hebt.

Als u uw platformservices van internet wilt isoleren, moet u een VNet gebruiken. Afhankelijk van de specifieke services die u gebruikt, kunt u werken met privé-eindpunten of met VNet geïntegreerde resources, zoals Application Gateway. U kunt er echter ook voor kiezen om uw platformservices beschikbaar te maken via hun openbare IP-adressen en de eigen beveiliging van de services te gebruiken, zoals firewalls en identiteitsbeheer. In deze situaties hebt u mogelijk geen VNet nodig.

De beslissing of VNets voor platformservices moeten worden gebruikt, is gebaseerd op veel vereisten, waaronder de volgende factoren:

  • Nalevingsvereisten: Mogelijk moet u voldoen aan een specifieke nalevingsstandaard. Voor sommige standaarden moet uw Azure-omgeving op specifieke manieren worden geconfigureerd.
  • De vereisten van uw tenants: Zelfs als uw eigen organisatie geen specifieke vereisten heeft voor isolatie of besturingselementen in de netwerklaag, kunnen uw tenants. Zorg ervoor dat u duidelijk weet hoe uw tenants toegang hebben tot uw oplossing en of ze veronderstellingen hebben over het netwerkontwerp.
  • Complexiteit: het kan complexer zijn om te begrijpen en te werken met virtuele netwerken. Zorg ervoor dat uw team een duidelijk beeld heeft van de principes die betrokken zijn, of dat u waarschijnlijk een onveilige omgeving implementeert.

Zorg ervoor dat u begrijpt wat de gevolgen zijn van het gebruik van privénetwerken.

Grootte van subnetten aanpassen

Wanneer u een VNet moet implementeren, is het belangrijk dat u zorgvuldig rekening houdt met de grootte en adresruimte van het hele VNet en de subnetten in het VNet.

Zorg ervoor dat u duidelijk weet hoe u uw Azure-resources implementeert in VNets en het aantal IP-adressen dat elke resource verbruikt. Als u tenantspecifieke rekenknooppunten, databaseservers of andere resources implementeert, moet u ervoor zorgen dat u subnetten maakt die groot genoeg zijn voor de verwachte tenantgroei en horizontale automatische schaalaanpassing van resources.

Op dezelfde manier is het belangrijk dat u begrijpt hoe IP-adressen worden gebruikt wanneer u met beheerde services werkt. Wanneer u bijvoorbeeld Azure Kubernetes Service met Azure Container Networking Interface (CNI) gebruikt, wordt het aantal IP-adressen dat wordt verbruikt vanuit een subnet gebaseerd op factoren zoals het aantal knooppunten, hoe u horizontaal schaalt en het service-implementatieproces dat u gebruikt. Wanneer u Azure-app Service en Azure Functions gebruikt met VNet-integratie, is het aantal gebruikte IP-adressen gebaseerd op het aantal planexemplaren.

Bekijk de richtlijnen voor subnetsegmentatie bij het plannen van uw subnetten.

Openbare of persoonlijke toegang

Overweeg of uw tenants toegang hebben tot uw services via internet of via privé-IP-adressen.

Voor toegang via internet (openbaar) kunt u firewallregels, IP-adres toestaan en weigeren, gedeelde geheimen en sleutels, en besturingselementen op basis van identiteiten gebruiken om uw service te beveiligen.

Als u connectiviteit met uw service wilt inschakelen met behulp van privé-IP-adressen, kunt u overwegen om Azure Private Link Service of peering voor virtuele netwerken tussen tenants te gebruiken. Voor sommige beperkte scenario's kunt u ook overwegen om Azure ExpressRoute of Azure VPN Gateway te gebruiken om privétoegang tot uw oplossing mogelijk te maken. We raden u alleen aan deze benadering te gebruiken wanneer u een klein aantal tenants hebt en toegewezen VNets voor elke tenant implementeert.

Toegang tot de eindpunten van tenants

Overweeg of u gegevens moet verzenden naar eindpunten binnen de netwerken van de tenants, binnen of buiten Azure. Moet u bijvoorbeeld een webhook aanroepen die wordt geleverd door een klant, of moet u realtime berichten verzenden naar een tenant?

Als u gegevens moet verzenden naar de eindpunten van tenants, kunt u de volgende algemene benaderingen overwegen:

  • Start verbindingen van uw oplossing met de eindpunten van tenants via internet. Overweeg of de verbindingen afkomstig moeten zijn van een statisch IP-adres. Afhankelijk van de Azure-services die u gebruikt, moet u mogelijk een NAT-gateway, firewall of load balancer implementeren.
  • Implementeer een agent om connectiviteit mogelijk te maken tussen uw door Azure gehoste services en de netwerken van uw klanten, ongeacht waar ze zich bevinden.
  • Voor berichten in één richting kunt u overwegen een service zoals Azure Event Grid te gebruiken, met of zonder gebeurtenisdomeinen.

Benaderingen en patronen om rekening mee te houden

In deze sectie beschrijven we enkele van de belangrijkste netwerkmethoden die u in een multitenant-oplossing kunt overwegen. We beschrijven eerst de benaderingen op lager niveau voor kernnetwerkonderdelen en volgen vervolgens de benaderingen die u kunt overwegen voor HTTP- en andere problemen in de toepassingslaag.

Tenantspecifieke VNets met door de serviceprovider geselecteerde IP-adressen

In sommige gevallen moet u namens een tenant toegewezen VNet-verbonden resources uitvoeren in Azure. U kunt bijvoorbeeld een virtuele machine uitvoeren voor elke tenant of u moet privé-eindpunten gebruiken voor toegang tot tenantspecifieke databases.

U kunt een VNet voor elke tenant implementeren met behulp van een IP-adresruimte die u bepaalt. Met deze benadering kunt u de VNets voor uw eigen doeleinden koppelen, bijvoorbeeld als u een hub- en spoke-topologie moet opzetten om verkeer voor inkomend en uitgaand verkeer centraal te beheren.

Door de serviceprovider geselecteerde IP-adressen zijn echter niet geschikt als tenants rechtstreeks verbinding moeten maken met het VNet dat u hebt gemaakt, zoals met behulp van VNet-peering. Waarschijnlijk is de adresruimte die u selecteert niet compatibel met hun eigen adresruimten.

Tenantspecifieke VNets met door tenant geselecteerde IP-adressen

Als tenants hun eigen VNets moeten koppelen aan het VNet dat u namens hen beheert, kunt u overwegen tenantspecifieke VNets te implementeren met een IP-adresruimte die de tenant selecteert. Met dit systeem kan elke tenant ervoor zorgen dat de IP-adresbereiken in het VNet van uw systeem niet overlappen met hun eigen VNets. Door niet-overlappende IP-adresbereiken te gebruiken, kunnen ze ervoor zorgen dat hun netwerken compatibel zijn met peering.

Deze benadering betekent echter dat het onwaarschijnlijk is dat u de VNets van uw tenants aan elkaar kunt koppelen of een hub- en spoke-topologie kunt gebruiken, omdat er waarschijnlijk overlappende IP-adresbereiken tussen VNets van verschillende tenants zijn.

Stertopologie

Met de hub- en spoke-VNet-topologie kunt u een gecentraliseerd hub-VNet koppelen aan meerdere spoke-VNets . U kunt het verkeer voor inkomend en uitgaand verkeer centraal voor uw VNet's beheren en bepalen of de resources in het VNet van elke spoke met elkaar kunnen communiceren. Elk spoke-VNet heeft ook toegang tot gedeelde onderdelen, zoals Azure Firewall, en het kan services zoals Azure DDoS Protection gebruiken.

Wanneer u een hub- en spoke-topologie gebruikt, moet u de limieten plannen, zoals het maximum aantal gekoppelde VNets, en ervoor zorgen dat u geen overlappende adresruimten gebruikt voor het VNet van elke tenant.

De hub- en spoke-topologie kan nuttig zijn wanneer u tenantspecifieke VNets implementeert met IP-adressen die u selecteert. Het VNet van elke tenant wordt een spoke en kan uw algemene resources delen in het hub-VNet. U kunt ook de hub- en spoke-topologie gebruiken wanneer u gedeelde resources in meerdere VNets schaalt voor schaaldoeleinden of wanneer u het patroon Implementatiestempels gebruikt.

Tip

Als uw oplossing wordt uitgevoerd in meerdere geografische regio's, is het meestal een goed idee om afzonderlijke hubs en hub-resources in elke regio te implementeren. Hoewel bij deze procedure hogere resourcekosten in rekening worden gebracht, voorkomt u onnodig verkeer dat meerdere Azure-regio's doorloopt, waardoor de latentie van aanvragen kan worden verhoogd en globale peeringkosten in rekening worden gebracht.

Statische IP-adressen

Overweeg of uw tenants uw service nodig hebben om statische openbare IP-adressen te gebruiken voor inkomend verkeer, uitgaand verkeer of beide. Verschillende Azure-services maken statische IP-adressen op verschillende manieren mogelijk.

Wanneer u met virtuele machines en andere infrastructuuronderdelen werkt, kunt u overwegen om een load balancer of firewall te gebruiken voor zowel binnenkomende als uitgaande statische IP-adressering. Overweeg nat-gateway te gebruiken om het IP-adres van uitgaand verkeer te beheren. Zie Overwegingen voor Azure NAT Gateway voor multitenancy voor meer informatie over het gebruik van NAT Gateway in een multitenant-oplossing.

Wanneer u met platformservices werkt, bepaalt de specifieke service die u gebruikt of en hoe u IP-adressen kunt beheren. Mogelijk moet u de resource op een specifieke manier configureren, bijvoorbeeld door de resource in een VNet te implementeren en met behulp van een NAT-gateway of firewall. U kunt ook de huidige set IP-adressen aanvragen die door de service worden gebruikt voor uitgaand verkeer. App Service biedt bijvoorbeeld een API en webinterface om de huidige uitgaande IP-adressen voor uw toepassing te verkrijgen.

Agents

Als u uw tenants in staat wilt stellen berichten te ontvangen die door uw oplossing worden geïnitieerd, of als u toegang nodig hebt tot gegevens die zich in de eigen netwerken van tenants bevinden, kunt u overwegen om een agent (ook wel een on-premises gateway genoemd) op te geven die ze binnen hun netwerk kunnen implementeren. Deze benadering kan werken of de netwerken van uw tenants zich in Azure, in een andere cloudprovider of on-premises bevinden.

De agent initieert een uitgaande verbinding met een eindpunt dat u opgeeft en beheert, en houdt langdurige verbindingen actief of pollt af en toe. Overweeg het gebruik van Azure Relay om verbindingen tussen uw agent en uw service tot stand te brengen en te beheren. Wanneer de agent de verbinding tot stand brengt, verifieert en bevat deze informatie over de tenant-id, zodat uw service de verbinding kan toewijzen aan de juiste tenant.

Agents vereenvoudigen doorgaans de beveiligingsconfiguratie voor uw tenants. Het kan complex en riskant zijn om binnenkomende poorten te openen, met name in een on-premises omgeving. Een agent voorkomt dat tenants dit risico moeten nemen.

Voorbeelden van Microsoft-services die agents bieden voor connectiviteit met de netwerken van tenants zijn onder andere:

De Azure Private Link-service biedt privéconnectiviteit vanuit de Azure-omgeving van een tenant naar uw oplossing. Tenants kunnen ook de Private Link-service met hun eigen VNet gebruiken om toegang te krijgen tot uw service vanuit een on-premises omgeving. Azure routeert het verkeer veilig naar de service met behulp van privé-IP-adressen.

Zie Multitenancy en Azure Private Link voor meer informatie over Private Link en multitenancy.

Domeinnamen, subdomeinen en TLS

Wanneer u werkt met domeinnamen en TLS (Transport Layer Security) in een multitenant-oplossing, zijn er een aantal overwegingen. Bekijk de overwegingen voor multitenancy en domeinnamen.

Gatewayrouterings- en gateway-offloadpatronen

Het gatewayrouteringspatroon en het gateway-offloadingpatroon omvatten het implementeren van een omgekeerde proxy of gateway op laag 7. Gateways zijn handig om kernservices te bieden voor een multitenant-toepassing, waaronder de volgende mogelijkheden:

  • Routeringsaanvragen naar tenantspecifieke back-ends of implementatiestempels.
  • Tenantspecifieke domeinnamen en TLS-certificaten verwerken.
  • Het inspecteren van aanvragen voor beveiligingsrisico's met behulp van een Web Application Firewall (WAF).
  • Reacties in de cache opslaan om de prestaties te verbeteren.

Azure biedt verschillende services die kunnen worden gebruikt om een of meer van deze doelen te bereiken, waaronder Azure Front Door, Azure-toepassing Gateway en Azure API Management. U kunt ook uw eigen aangepaste oplossing implementeren met behulp van software zoals NGINX of HAProxy.

Als u van plan bent om een gateway voor uw oplossing te implementeren, is het raadzaam eerst een volledig prototype te bouwen dat alle functies bevat die u nodig hebt en om te controleren of uw toepassingsonderdelen blijven functioneren zoals verwacht. U moet ook begrijpen hoe het gatewayonderdeel wordt geschaald om uw verkeer en tenantgroei te ondersteunen.

Patroon voor hosting van statische inhoud

Het patroon Static Content Hosting omvat het leveren van webinhoud vanuit een cloudeigen opslagservice en het gebruik van een CDN (Content Delivery Network) om de inhoud in de cache op te slaan.

U kunt Azure Front Door of een ander CDN gebruiken voor de statische onderdelen van uw oplossing, zoals JavaScript-toepassingen met één pagina, en voor statische inhoud, zoals afbeeldingsbestanden en documenten.

Afhankelijk van hoe uw oplossing is ontworpen, kunt u mogelijk ook tenantspecifieke bestanden of gegevens opslaan in een CDN, zoals api-antwoorden met JSON-indeling. Met deze procedure kunt u de prestaties en schaalbaarheid van uw oplossing verbeteren, maar het is belangrijk om na te gaan of tenantspecifieke gegevens voldoende zijn geïsoleerd om te voorkomen dat gegevens over tenants worden gelekt. Overweeg hoe u tenantspecifieke inhoud uit uw cache wilt opschonen, bijvoorbeeld wanneer gegevens worden bijgewerkt of een nieuwe toepassingsversie wordt geïmplementeerd. Door de tenant-id op te slaan in het URL-pad, kunt u bepalen of u een specifiek bestand opschoont, alle bestanden die betrekking hebben op een specifieke tenant of alle bestanden voor alle tenants.

Antipatroon om te voorkomen

Kan geen VNet-connectiviteit plannen

Door resources in VNets te implementeren, hebt u veel controle over de wijze waarop verkeer door de onderdelen van uw oplossing stroomt. VNet-integratie introduceert echter ook extra complexiteit, kosten en andere factoren die u moet overwegen. Dit effect geldt met name voor PaaS-onderdelen (Platform as a Service).

Het is belangrijk om uw netwerkstrategie te testen en te plannen, zodat u eventuele problemen ontdekt voordat u deze implementeert in een productieomgeving.

Geen planning voor limieten

Azure dwingt een aantal limieten af die van invloed zijn op netwerkresources. Deze limieten omvatten Azure-resourcelimieten en fundamentele protocol- en platformlimieten. Wanneer u bijvoorbeeld een grootschalige multitenant-oplossing bouwt op platformservices, zoals Azure-app Service en Azure Functions, moet u mogelijk rekening houden met het aantal TCP-verbindingen en SNAT-poorten. Wanneer u met virtuele machines en load balancers werkt, moet u ook rekening houden met beperkingen voor uitgaande regels en voor SNAT-poorten.

Kleine subnetten

Het is belangrijk om rekening te houden met de grootte van elk subnet om het aantal resources of exemplaren van resources toe te staan dat u gaat implementeren, met name wanneer u schaalt. Wanneer u met PaaS-resources (Platform as a Service) werkt, moet u weten hoe de configuratie en schaal van uw resource van invloed zijn op het aantal IP-adressen dat vereist is in het subnet.

Onjuiste netwerksegmentatie

Als voor uw oplossing virtuele netwerken zijn vereist, kunt u overwegen hoe u netwerksegmentatie configureert om binnenkomende en uitgaande verkeerstromen (noord-zuid) en de stromen binnen uw oplossing (oost-west) te beheren. Bepaal of tenants hun eigen VNets moeten hebben of of dat u gedeelde resources implementeert in gedeelde VNets. Het wijzigen van de aanpak kan lastig zijn, dus zorg ervoor dat u rekening houdt met al uw vereisten en selecteer vervolgens een benadering die geschikt is voor uw toekomstige groeidoelen.

Alleen afhankelijk van beveiligingsmaatregelen op de netwerklaag

In moderne oplossingen is het belangrijk om netwerklaagbeveiliging te combineren met andere beveiligingsmechanismen. U moet niet alleen vertrouwen op firewalls of netwerksegmentatie. Dit wordt ook wel zero-trust-netwerken genoemd. Gebruik besturingselementen op basis van identiteit om de client, beller of gebruiker te controleren op elke laag van uw oplossing. Overweeg het gebruik van services waarmee u extra beveiligingslagen kunt toevoegen. De beschikbare opties zijn afhankelijk van de Azure-services die u gebruikt. In AKS kunt u overwegen om een service-mesh te gebruiken voor wederzijdse TLS-verificatie en netwerkbeleid om verkeer in oost-west te beheren. Overweeg in App Service de ingebouwde ondersteuning te gebruiken voor verificatie- en autorisatie - en toegangsbeperkingen.

Hostheaders herschrijven zonder te testen

Wanneer u het offloadingpatroon van de gateway gebruikt, kunt u overwegen om de Host header van HTTP-aanvragen te herschrijven. Met deze procedure kunt u de configuratie van uw back-endwebtoepassingsservice vereenvoudigen door het aangepaste domein en TLS-beheer naar de gateway te offloaden.

Host Het herschrijven van headers kan echter problemen veroorzaken voor sommige back-endservices. Als uw toepassing HTTP-omleidingen of cookies uitgeeft, kan de functionaliteit van de toepassing worden verbroken door de niet-overeenkomende hostnamen. Dit probleem kan zich met name voordoen wanneer u back-endservices gebruikt die zelf multitenant zijn, zoals Azure-app Service, Azure Functions en Azure Spring Apps. Zie de best practice voor het behoud van hostnamen voor meer informatie.

Zorg ervoor dat u het gedrag van uw toepassing test met de gatewayconfiguratie die u wilt gebruiken.

Medewerkers

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

Hoofdauteur:

  • John Downs | Principal Customer Engineer, FastTrack voor Azure

Andere Inzenders:

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

Volgende stappen