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

Alla lösningar som distribueras till Azure kräver någon form av nätverk. Hur du interagerar med Azure-nätverkstjänster beror på din lösnings design och arbetsbelastning. Den här artikeln innehåller överväganden och vägledning för nätverksaspekter av lösningar för flera klienter i Azure. Den innehåller information om nätverkskomponenter på lägre nivå, till exempel virtuella nätverk, och omfattar metoder på högre nivå och programnivå.

Viktiga överväganden och krav

Infrastruktur- och plattformstjänster

Överväganden för nätverkskomponenten beror på vilken kategori av tjänster du använder.

Infrastrukturtjänster

När du använder infrastrukturtjänster, till exempel virtuella datorer (VM) eller Azure Kubernetes Service (AKS), bör du överväga och utforma de virtuella nätverk som ligger till grund för dina tjänsters anslutning. Tänk också på de andra säkerhets- och isoleringsskikten som du behöver införliva i din design. Undvik att enbart förlita dig på kontroller på nätverksnivå.

Plattformstjänster

När du använder Azure-plattformstjänster, till exempel Azure App Service, Azure Cosmos DB eller Azure SQL Database, avgör arkitekturen de nätverkstjänster som du behöver.

Om du vill isolera dina plattformstjänster från Internet använder du ett virtuellt nätverk. Beroende på vilka tjänster du använder kan du arbeta med privata slutpunkter eller virtuella nätverksintegrerade resurser, till exempel Azure Application Gateway. Du kan också göra dina plattformstjänster tillgängliga via deras offentliga IP-adresser och använda tjänsternas egna skydd som brandväggar och identitetskontroller. I dessa situationer kanske du inte behöver distribuera och konfigurera ditt eget virtuella nätverk.

Bestäm om du vill använda virtuella nätverk för plattformstjänster baserat på följande faktorer:

• Efterlevnadskrav: Du kan behöva uppfylla en specifik efterlevnadsstandard. Vissa standarder kräver att du konfigurerar Din Azure-miljö på specifika sätt, till exempel med hjälp av specifika nätverkskontroller. Mer information finns i Arkitekturmetoder för styrning och efterlevnad i lösningar med flera klientorganisationer.

• Dina hyresgästers krav: Även om din organisation inte har definierade krav för isolering eller kontroller på nätverksnivå kan dina hyresgäster ha sådana krav. Förstå tydligt hur dina klienter planerar att komma åt din lösning och om de har några antaganden om nätverksdesignen.

• Komplexitet: Virtuella nätverk medför komplexitet. Se till att ditt team tydligt förstår de principer som ingår för att undvika att distribuera en osäker miljö.

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

Ändra storlek på dina undernät

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

Förstå hur du planerar att distribuera dina Azure-resurser till virtuella nätverk och antalet IP-adresser som varje resurs använder. Om du distribuerar klientspecifika beräkningsnoder, databasservrar eller andra resurser skapar du undernät som är tillräckligt stora för din förväntade klienttillväxt och horisontell autoskalning av resurser.

När du arbetar med hanterade tjänster förstår du på samma sätt hur de använder IP-adresser. När du till exempel använder AKS 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 distributionsprocessen för tjänsten. När du använder App Service och Azure Functions med nätverksintegrering baseras antalet förbrukade IP-adresser på antalet instanser i planen.

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

Offentlig eller privat åtkomst

Överväg om dina klienter behöver komma åt dina tjänster via Internet eller via privata IP-adresser.

Om du vill skydda din tjänst för internetbaserad (offentlig) åtkomst använder du brandväggsregler, tillåtna IP-adresser och nekalistning, delade hemligheter och nycklar samt identitetsbaserade kontroller.

Om du vill göra det möjligt för klienter att ansluta till tjänsten med hjälp av privata IP-adresser bör 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 hyresgästernas slutpunkter

Överväg om du behöver skicka data till slutpunkter i klientorganisationens nätverk, antingen i eller utanför Azure. Du kan till exempel anropa en webhook som tillhandahålls av kunden eller skicka realtidsmeddelanden till en klientorganisations system.

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 använda NAT (Network Address Translation) genom att distribuera Azure NAT Gateway, en brandvägg eller en lastbalanserare.

• Distribuera en agent för att aktivera anslutning mellan dina Azure-värdbaserade tjänster och dina kunders nätverk, oavsett var de befinner sig.

• Överväg att använda en tjänst som Azure Event Grid, eventuellt med händelsedomäner, för enkelriktade meddelanden.

Metoder och mönster att tänka på

I det här avsnittet beskrivs några viktiga nätverksmetoder att tänka på i en lösning med flera klientorganisationer. Den börjar med metoder på lägre nivå för kärnnätverkskomponenter och beskriver sedan metoder för HTTP och andra problem på programnivå.

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

I vissa scenarier måste du köra dedikerade virtuella nätverksanslutna 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 ansluta de virtuella nätverken för dina egna syften, till exempel att upprätta en topologi för nav och eker för att centralt kontrollera inkommande och utgående trafik.

Undvik att använda tjänstproviderns valda IP-adresser om klientorganisationer behöver ansluta direkt till det virtuella nätverk som du skapar, till exempel genom att använda peering för virtuella nätverk. Det adressutrymme som du väljer står sannolikt i konflikt med deras befintliga adressutrymmen.

Klientspecifika virtuella nätverk med klientvalda IP-adresser

Om hyresgäster behöver koppla sina egna virtuella nätverk till det virtuella nätverk som du hanterar för dem, överväg att distribuera hyresgästspecifika virtuella nätverk med hjälp av ett IP-adressutrymme som hyresgästen väljer. Med den här konfigurationen kan varje klientorganisation se till att IP-adressintervallen i systemets virtuella nätverk inte överlappar deras egna virtuella nätverk, vilket möjliggör kompatibilitet för peering.

Men den här metoden förhindrar sannolikt att du kopplar ihop dina klientorganisationers virtuella nätverk eller använder en nav-och-ekertopologi. Peer-kopplade virtuella nätverk kan inte använda överlappande IP-adressintervall, och när hyresgäster väljer sina egna IP-adressintervall väljer de sannolikt intervall som överlappar varandra.

Topologi för nav och eker

Med topologin för det virtuella nätverket hub-and-spoke kan du peerkoppla ett centralt 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 spoks virtuella nätverk kan kommunicera med varandra. Varje virtuellt spoke-nätverk kan också komma åt delade komponenter, såsom Azure Firewall, och kan dra nytta av tjänster som Azure DDoS Protection.

När du använder en topologi med nav och eker planerar du för gränser , till exempel det maximala antalet peer-kopplade virtuella nätverk. Använd inte överlappande adressutrymmen för varje klientorganisations virtuella nätverk.

Överväg att använda topologin hub-and-spoke när du distribuerar klientspecifika virtuella nätverk som använder IP-adresser som du väljer. Varje klientorganisations virtuella nätverk blir ett nav och kan dela gemensamma resurser i det virtuella hubbnätverket. Du kan också använda topologin hub-and-spoke när du skalar delade resurser över flera virtuella nätverk eller när du använder mönstret Distributionsstämplar.

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 Azure NAT Gateway för att styra IP-adressen för utgående trafik. Mer information finns i Azure NAT Gateway-överväganden för flera klientorganisationer.

När du arbetar med plattformstjänster avgör den specifika tjänst som du använder 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.

Agenter

Om du vill att dina klienter ska kunna ta emot meddelanden som initierats av din lösning eller komma åt data i klientorganisationens nätverk kan du överväga att tillhandahålla en agent, ibland kallad en lokal gateway, som de distribuerar 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. Det håller antingen långvariga anslutningar vid liv eller omröstningar 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 eliminerar behovet av att hyresgäster tar den här risken.

Microsoft-tjänster som tillhandahåller agenter för anslutning till klientorganisationens nätverk innehåller följande exempel:

• Azure Data Factory lokalt installerad integrationskörning
• Hybridanslutningar för App Service
• Microsofts lokala datagateway, som används för Azure Logic Apps, Power BI och andra tjänster

Private Link-tjänst

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 ett eget virtuellt nätverk för att få åtkomst till tjänsten från en lokal miljö. Azure dirigerar trafiken till tjänsten på ett säkert sätt med hjälp av privata IP-adresser.

Mer information finns i Multitenancy och Private Link.

Domännamn, underdomäner och TLS

Granska de viktigaste övervägandena när du arbetar med domännamn och TLS (Transport Layer Security) i en lösning med flera klienter.

Gatewayroutning och gateway-avlastningsmönster

Gateway-ruttningsmönstret och Gateway-avlastningsmönstret omfattar distribution av en omvänd Layer-7-proxy eller gateway. Gatewayer tillhandahåller 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)
• Svar på cachelagring för att förbättra prestanda

Azure tillhandahåller flera tjänster som kan uppnå vissa eller alla dessa mål, inklusive Azure Front Door, 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. Inkludera alla nödvändiga funktioner och kontrollera att dina programkomponenter fungerar som förväntat. Du bör också förstå hur gatewaykomponenten skalar för att stödja din trafik- och klienttillväxt.

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

Värdmönstret för statiskt innehåll hanterar webbinnehåll från en molnbaserad lagringstjänst och använder ett nätverk för innehållsleverans för att cachelagra innehållet.

Du kan använda Azure Front Door eller ett annat nätverk för innehållsleverans 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å lösningens design kanske du också kan cachelagrar klientspecifika filer eller data i ett nätverk för innehållsleverans, till exempel JSON-formaterade API-svar. Den här metoden kan hjälpa dig att förbättra lösningens prestanda och skalbarhet. Se till att klientspecifika data förblir tillräckligt isolerade för att förhindra dataläckage 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 anslutning till virtuellt nätverk

När du distribuerar resurser till virtuella nätverk får du betydande kontroll över hur trafiken flödar genom lösningens komponenter. Men integrering av virtuella nätverk medför också mer komplexitet, kostnader och andra faktorer som du behöver tänka på, särskilt för PaaS-komponenter (Plattform som en tjänst).

Testa och planera din nätverksstrategi för att identifiera eventuella problem innan du implementerar den i en produktionsmiljö.

Planerar inte för gränser

Azure tillämpar många 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 App Service och Azure Functions, kan du behöva överväga antalet TCP-anslutningar (Transmission Control Protocol) och SNAT-portar (Source Network Address Translation). När du arbetar med virtuella datorer och lastbalanserare måste du också överväga begränsningar för utgående regler och SNAT-portar.

Små undernät

Ändra storlek på varje undernät för att stödja antalet resurser eller instanser av resurser som du planerar att distribuera, särskilt när du skalar. När du arbetar med PaaS-resurser kan du förstå hur resursens konfiguration och skalning påverkar antalet IP-adresser som krävs i dess undernät.

Felaktig nätverkssegmentering

Om din lösning kräver virtuella nätverk bör du överväga hur du konfigurerar nätverkssegmentering för att styra inkommande och utgående trafik (kallas för trafik mellan nord och syd) samt trafik inom din lösning (kallas för trafik mellan öst och 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å tänk noga på alla krav innan du väljer 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 bör du kombinera säkerhet på nätverksnivå med andra säkerhetskontroller. Förlita dig inte bara på brandväggar eller nätverkssegmentering. Den här metoden kallas ibland för Zero Trust-nä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 extra skyddslager. Dina alternativ 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 tillämpa 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 ändra rubriken på 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.

Men Host ändringar av sidhuvudet kan orsaka problem för vissa bakgrundstjä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 körs på infrastruktur för flera klientorganisationer, till exempel App Service och Azure Functions. Mer information finns i Metodtips för bevarande av värdnamn.

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

Bidragsgivare

Microsoft ansvarar för den här artikeln. Följande deltagare skrev den här artikeln.

Huvudförfattare:

• John Downs | Principal Software Engineer, Azure Patterns &Practices

Övriga medarbetare:

• Arsen Vladimirskiy | Huvudkundtekniker, FastTrack för Azure
• Joshua Waddell | Senior kundtekniker, FastTrack för Azure

Om du vill se linkedin-profiler som inte är offentliga loggar du in på LinkedIn.

Relaterade resurser

• Domännamnsöverväganden i lösningar med flera klienter.
• Granska tjänstspecifik vägledning för dina nätverkstjänster:
  • Använda Azure Front Door i en lösning med flera klientorganisationer
  • Överväganden för Azure NAT Gateway för flera klientorganisationer
  • Multitenancy och Private Link