Dela via

Arkitekturmetoder för nätverk i lösningar för flera klientorganisationer

  • Artikel

Alla lösningar som distribueras till Azure kräver nätverk av något slag. Beroende på din lösningsdesign och arbetsbelastningen kan du interagera med Azures nätverkstjänster på olika sätt. I den här artikeln ger vi överväganden och vägledning för nätverksaspekter av lösningar för flera klienter i Azure. Vi inkluderar information om nätverkskomponenter på lägre nivå, till exempel virtuella nätverk, till metoder på högre nivå och programnivå.

Kommentar

Själva Azure är en miljö med flera klientorganisationer och Azures nätverkskomponenter är utformade för flera klientorganisationer. Även om det inte krävs för att förstå informationen för att utforma din egen lösning kan du lära dig mer om hur Azure isolerar din virtuella nätverkstrafik från andra kunders trafik.

Viktiga överväganden och krav

Infrastruktur- och plattformstjänster

De problem du har för dina nätverkskomponenter varierar beroende på vilken kategori av tjänster du använder.

Infrastrukturtjänster

När du använder infrastrukturtjänster, till exempel virtuella datorer eller Azure Kubernetes Service, måste du överväga och utforma de virtuella nätverk eller virtuella nätverk som ligger till grund för dina tjänsters anslutning. Du måste också ta hänsyn till de andra säkerhets- och isoleringsskikten som du behöver lägga till i din design. Undvik att enbart förlita dig på kontroller på nätverksnivå.

Plattformstjänster

Om du använder Azures plattformstjänster, till exempel App Service, Azure Cosmos DB eller Azure SQL Database, avgör den specifika arkitektur som du använder de nätverkstjänster du behöver.

Om du behöver isolera dina plattformstjänster från Internet måste du använda ett virtuellt nätverk. Beroende på vilka tjänster du använder kan du arbeta med privata slutpunkter eller VNet-integrerade resurser, till exempel Application Gateway. Men du kan också välja att göra dina plattformstjänster tillgängliga via sina offentliga IP-adresser och använda tjänsternas egna skydd som brandväggar och identitetskontroller. I dessa situationer kanske du inte behöver ett virtuellt nätverk.

Beslutet om att använda virtuella nätverk för plattformstjänster baseras på många krav, inklusive följande faktorer:

  • Efterlevnadskrav: Du kan behöva uppfylla en specifik efterlevnadsstandard. Vissa standarder kräver att din Azure-miljö konfigureras på specifika sätt.
  • Dina klientorganisationers krav: Även om din egen organisation inte har specifika krav för isolering eller kontroller på nätverksnivå kan dina klienter. Se till att du har en tydlig förståelse för hur dina klienter kommer åt din lösning och om de har några antaganden om nätverksdesignen.
  • Komplexitet: Det kan vara mer komplext att förstå och arbeta med virtuella nätverk. Se till att ditt team har en tydlig förståelse för de principer som ingår, eller att du sannolikt distribuerar en osäker miljö.

Se till att du förstår konsekvenserna av att använda privata nätverk.

Ändra storlek på undernät

När du behöver distribuera ett virtuellt nätverk är det viktigt att noga överväga storleks- och adressutrymmet för hela det virtuella nätverket och undernäten i det virtuella nätverket.

Se till att du har en tydlig förståelse för hur du distribuerar dina Azure-resurser till virtuella nätverk och antalet IP-adresser som varje resurs förbrukar. Om du distribuerar klientspecifika beräkningsnoder, databasservrar eller andra resurser ska du se till att du skapar undernät som är tillräckligt stora för din förväntade klienttillväxt och horisontell automatisk skalning av resurser.

På samma sätt är det viktigt att du förstår hur IP-adresser används när du arbetar med hanterade tjänster. När du till exempel använder Azure Kubernetes Service med Azure Container Networking Interface (CNI) baseras antalet IP-adresser som förbrukas från ett undernät på faktorer som antalet noder, hur du skalar horisontellt och den tjänstdistributionsprocess som du använder. När du använder Azure App Service och Azure Functions med VNet-integrering baseras antalet förbrukade IP-adresser på antalet planinstanser.

Granska vägledningen för undernätssegmentering när du planerar dina undernät.

Offentlig eller privat åtkomst

Fundera på om dina klienter kommer åt dina tjänster via Internet eller via privata IP-adresser.

För internetbaserad (offentlig) åtkomst kan du använda brandväggsregler, tillåtna IP-adresser och neka listor, delade hemligheter och nycklar samt identitetsbaserade kontroller för att skydda din tjänst.

Om du behöver aktivera anslutningen till tjänsten med hjälp av privata IP-adresser kan du överväga att använda Azure Private Link-tjänsten eller peering för virtuella nätverk mellan klientorganisationer. I vissa begränsade scenarier kan du också överväga att använda Azure ExpressRoute eller Azure VPN Gateway för att aktivera privat åtkomst till din lösning. Vanligtvis är den här metoden bara meningsfull när du har ett litet antal klienter och när du distribuerar dedikerade virtuella nätverk för varje klientorganisation.

Åtkomst till klientorganisationens slutpunkter

Fundera på om du behöver skicka data till slutpunkter i klientorganisationens nätverk, antingen inom eller utanför Azure. Behöver du till exempel anropa en webhook som tillhandahålls av en kund, eller behöver du skicka realtidsmeddelanden till en klientorganisation?

Om du behöver skicka data till klientorganisationens slutpunkter bör du överväga följande vanliga metoder:

  • Initiera anslutningar från din lösning till klientorganisationens slutpunkter via Internet. Överväg om anslutningarna måste komma från en statisk IP-adress. Beroende på vilka Azure-tjänster du använder kan du behöva distribuera en NAT Gateway, brandvägg eller lastbalanserare.
  • Distribuera en agent för att aktivera anslutning mellan dina Azure-värdbaserade tjänster och dina kunders nätverk, oavsett var de finns.
  • För enkelriktade meddelanden bör du överväga att använda en tjänst som Azure Event Grid, eventuellt tillsammans med händelsedomäner.

Metoder och mönster att tänka på

I det här avsnittet beskriver vi några av de viktiga nätverksmetoder som du kan tänka på i en lösning med flera klientorganisationer. Vi börjar med att beskriva de lägre metoderna för kärnnätverkskomponenter och följer sedan med de metoder som du kan överväga för HTTP och andra problem med programnivå.

Klientspecifika virtuella nätverk med tjänstproviderns valda IP-adresser

I vissa situationer måste du köra dedikerade VNet-anslutna resurser i Azure för en klientorganisations räkning. Du kan till exempel köra en virtuell dator för varje klientorganisation, eller så kan du behöva använda privata slutpunkter för att få åtkomst till klientspecifika databaser.

Överväg att distribuera ett virtuellt nätverk för varje klientorganisation med hjälp av ett IP-adressutrymme som du styr. Med den här metoden kan du peer-koppla ihop de virtuella nätverken för dina egna syften, till exempel om du behöver upprätta en nav- och ekertopologi för att centralt kontrollera trafik ingress och utgående trafik.

Men de IP-adresser som valts av tjänstprovidern är inte lämpliga om klientorganisationer behöver ansluta direkt till det virtuella nätverk som du skapade, till exempel genom att använda VNet-peering. Det är troligt att adressutrymmet som du väljer är inkompatibelt med deras egna adressutrymmen.

Klientspecifika virtuella nätverk med klientvalda IP-adresser

Om klientorganisationer behöver peer-koppla sina egna virtuella nätverk till det virtuella nätverk som du hanterar åt dem kan du överväga att distribuera klientspecifika virtuella nätverk med ett IP-adressutrymme som klienten väljer. Det här systemet gör det möjligt för varje klientorganisation att se till att IP-adressintervallen i systemets virtuella nätverk inte överlappar deras egna virtuella nätverk. Genom att använda ip-adressintervall som inte överlappar varandra kan de se till att deras nätverk är kompatibla för peering.

Den här metoden innebär dock att det är osannolikt att du kan peerkoppla klientorganisationens virtuella nätverk eller använda en nav- och ekertopologi, eftersom det sannolikt finns överlappande IP-adressintervall mellan virtuella nätverk för olika klientorganisationer.

Topologi med nav och ekrar

Med nav- och eker-VNet-topologin kan du peerkoppla ett centraliserat virtuellt hubbnätverk med flera virtuella ekernätverk . Du kan centralt styra in- och utgående trafik för dina virtuella nätverk och styra om resurserna i varje ekers virtuella nätverk kan kommunicera med varandra. Varje virtuellt ekernätverk kan också komma åt delade komponenter, till exempel Azure Firewall, och det kanske kan använda tjänster som Azure DDoS Protection.

När du använder en nav- och ekertopologi ska du planera runt gränserna, till exempel det maximala antalet peer-kopplade virtuella nätverk, och se till att du inte använder överlappande adressutrymmen för varje klientorganisations virtuella nätverk.

Nav- och ekertopologin kan vara användbar när du distribuerar klientspecifika virtuella nätverk med IP-adresser som du väljer. Varje klientorganisations virtuella nätverk blir en eker och kan dela dina gemensamma resurser i det virtuella hubbnätverket. Du kan också använda topologin hubb och eker när du skalar delade resurser över flera virtuella nätverk i skalningssyfte eller när du använder mönstret Distributionsstämplar.

Dricks

Om din lösning körs i flera geografiska regioner är det vanligtvis en bra idé att distribuera separata hubbar och hubbresurser i varje region. Även om den här metoden medför en högre resurskostnad undviker den trafik som går igenom flera Azure-regioner i onödan, vilket kan öka svarstiden för begäranden och medföra globala peeringavgifter.

Statiska IP-adresser

Fundera på om dina klienter behöver din tjänst för att använda statiska offentliga IP-adresser för inkommande trafik, utgående trafik eller både och. Olika Azure-tjänster aktiverar statiska IP-adresser på olika sätt.

När du arbetar med virtuella datorer och andra infrastrukturkomponenter bör du överväga att använda en lastbalanserare eller brandvägg för både inkommande och utgående statisk IP-adressering. Överväg att använda NAT Gateway för att styra IP-adressen för utgående trafik. Mer information om hur du använder NAT Gateway i en lösning med flera klienter finns i Överväganden för Azure NAT Gateway för flera klientorganisationer.

När du arbetar med plattformstjänster avgör den specifika tjänst du använder om och hur du kan styra IP-adresser. Du kan behöva konfigurera resursen på ett visst sätt, till exempel genom att distribuera en resurs som en virtuell dator till ett virtuellt nätverk och sedan använda en NAT Gateway eller brandvägg. Eller så kan du begära den aktuella uppsättningen IP-adresser som tjänsten använder för utgående trafik. App Service tillhandahåller till exempel ett API och ett webbgränssnitt för att hämta de aktuella utgående IP-adresserna för ditt program.

Handläggare

Om du behöver göra så att dina klienter kan ta emot meddelanden som initieras av din lösning, eller om du behöver komma åt data som finns i klientorganisationens egna nätverk, kan du överväga att tillhandahålla en agent (kallas ibland en lokal gateway) som de kan distribuera i sitt nätverk. Den här metoden kan fungera oavsett om klientorganisationens nätverk finns i Azure, i en annan molnleverantör eller lokalt.

Agenten initierar en utgående anslutning till en slutpunkt som du anger och kontrollerar, och håller antingen långvariga anslutningar vid liv eller avsöker tillfälligt. Överväg att använda Azure Relay för att upprätta och hantera anslutningar från din agent till din tjänst. När agenten upprättar anslutningen autentiserar den och innehåller viss information om klientidentifieraren så att tjänsten kan mappa anslutningen till rätt klientorganisation.

Agenter förenklar vanligtvis säkerhetskonfigurationen för dina klienter. Det kan vara komplext och riskabelt att öppna inkommande portar, särskilt i en lokal miljö. En agent undviker behovet av att klientorganisationer tar den här risken.

Exempel på Microsoft usluge som tillhandahåller agenter för anslutning till klientorganisationens nätverk är:

Azure Private Link-tjänsten tillhandahåller privat anslutning från en klients Azure-miljö till din lösning. Klienter kan också använda Private Link-tjänsten med sitt eget virtuella nätverk för att få åtkomst till din tjänst från en lokal miljö. Azure dirigerar på ett säkert sätt trafiken till tjänsten med hjälp av privata IP-adresser.

Mer information om Private Link och flera klientorganisationer finns i Multitenancy och Azure Private Link.

Domännamn, underdomäner och TLS

När du arbetar med domännamn och säkerhet på transportnivå (TLS) i en lösning med flera klienter finns det ett antal saker att tänka på. Granska övervägandena för flera klient- och domännamn.

Gatewayroutning och gateway-avlastningsmönster

Mönstret gatewayroutning och gatewayens avlastningsmönster omfattar distribution av en omvänd layer 7-proxy eller gateway. Gatewayer är användbara för att tillhandahålla kärntjänster för ett program med flera klientorganisationer, inklusive följande funktioner:

  • Routningsbegäranden till klientspecifika serverdelar eller distributionsstämplar.
  • Hantera klientspecifika domännamn och TLS-certifikat.
  • Inspektera begäranden om säkerhetshot med hjälp av en brandvägg för webbprogram (WAF).
  • Cachelagringssvar för att förbättra prestanda.

Azure tillhandahåller flera tjänster som kan användas för att uppnå vissa eller alla dessa mål, inklusive Azure Front Door, Azure Application Gateway och Azure API Management. Du kan också distribuera en egen anpassad lösning med hjälp av programvara som NGINX eller HAProxy.

Om du planerar att distribuera en gateway för din lösning är det bra att först skapa en komplett prototyp som innehåller alla funktioner som du behöver och kontrollera att dina programkomponenter fortsätter att fungera som förväntat. Du bör också förstå hur gatewaykomponenten kommer att skalas för att stödja din trafik- och klienttillväxt.

Mönster för värddator för statiskt innehåll

Mönstret Värd för statiskt innehåll omfattar servering av webbinnehåll från en molnbaserad lagringstjänst och användning av ett nätverk för innehållsleverans (CDN) för att cachelagrar innehållet.

Du kan använda Azure Front Door eller ett annat CDN för lösningens statiska komponenter, till exempel JavaScript-program med en enda sida, och för statiskt innehåll som bildfiler och dokument.

Beroende på hur din lösning är utformad kan du också cachelagrar klientspecifika filer eller data i ett CDN, till exempel JSON-formaterade API-svar. Den här metoden kan hjälpa dig att förbättra prestanda och skalbarhet för din lösning, men det är viktigt att överväga om klientspecifika data är tillräckligt isolerade för att undvika att läcka data mellan klienter. Överväg hur du planerar att rensa klientspecifikt innehåll från cacheminnet, till exempel när data uppdateras eller en ny programversion distribueras. Genom att inkludera klientidentifieraren i URL-sökvägen kan du styra om du rensar en specifik fil, alla filer som är relaterade till en specifik klientorganisation eller alla filer för alla klienter.

Antimönster att undvika

Det går inte att planera för VNet-anslutning

Genom att distribuera resurser till virtuella nätverk har du stor kontroll över hur trafiken flödar genom lösningens komponenter. Men VNet-integrering ger också ytterligare komplexitet, kostnader och andra faktorer som du behöver tänka på. Den här effekten gäller särskilt paaS-komponenter (platform as a service).

Det är viktigt att testa och planera din nätverksstrategi, så att du upptäcker eventuella problem innan du implementerar den i en produktionsmiljö.

Planerar inte för gränser

Azure tillämpar ett antal gränser som påverkar nätverksresurser. Dessa gränser omfattar Azure-resursgränser och grundläggande protokoll- och plattformsgränser. När du till exempel skapar en storskalig lösning för flera klientorganisationer på plattformstjänster, till exempel Azure App Service och Azure Functions, kan du behöva överväga antalet TCP-anslutningar och SNAT-portar. När du arbetar med virtuella datorer och lastbalanserare måste du också överväga begränsningar för regler för utgående trafik och för SNAT-portar.

Små undernät

Det är viktigt att tänka på storleken på varje undernät för att tillåta antalet resurser eller instanser av resurser som du ska distribuera, särskilt när du skalar. När du arbetar med PaaS-resurser (Plattform som en tjänst) ser du till att du förstår hur resursens konfiguration och skalning påverkar antalet IP-adresser som krävs i dess undernät.

Felaktig nätverkssegmentering

Om lösningen kräver virtuella nätverk bör du överväga hur du konfigurerar nätverkssegmentering så att du kan styra inkommande och utgående trafikflöden (nord-syd) och flödena i din lösning (öst-väst). Bestäm om klientorganisationer ska ha egna virtuella nätverk eller om du ska distribuera delade resurser i delade virtuella nätverk. Det kan vara svårt att ändra metoden, så se till att du överväger alla dina krav och välj sedan en metod som fungerar för dina framtida tillväxtmål.

Endast förlita sig på säkerhetskontroller på nätverksnivå

I moderna lösningar är det viktigt att kombinera säkerhet på nätverksnivå med andra säkerhetskontroller, och du bör inte bara förlita dig på brandväggar eller nätverkssegmentering. Detta kallas ibland för nollförtroendenätverk. Använd identitetsbaserade kontroller för att verifiera klienten, anroparen eller användaren i varje lager i din lösning. Överväg att använda tjänster som gör att du kan lägga till ytterligare skyddslager. Vilka alternativ du har tillgängliga beror på vilka Azure-tjänster du använder. I AKS bör du överväga att använda ett tjänstnät för ömsesidig TLS-autentisering och nätverksprinciper för att styra trafiken mellan öst och väst. Överväg att använda det inbyggda stödet för autentisering och auktorisering och åtkomstbegränsningar i App Service.

Skriva om värdhuvuden utan testning

När du använder mönstret Gateway-avlastning kan du överväga att skriva om huvudet för Host HTTP-begäranden. Den här metoden kan förenkla konfigurationen av serverdelswebbprogramtjänsten genom att avlasta den anpassade domänen och TLS-hanteringen till gatewayen.

Rubrikomskrivningar kan dock Host orsaka problem för vissa serverdelstjänster. Om ditt program utfärdar HTTP-omdirigeringar eller cookies kan felmatchningen i värdnamnen bryta programmets funktioner. I synnerhet kan det här problemet uppstå när du använder serverdelstjänster som själva är multitenanta, till exempel Azure App Service, Azure Functions och Azure Spring Apps. Mer information finns i bästa praxis för bevarande av värdnamn.

Kontrollera att du testar programmets beteende med den gatewaykonfiguration som du planerar att använda.

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