Nätverk för SaaS-arbetsbelastningar i Azure
Nätverket tillhandahåller stamnätet för hur kunder får åtkomst till ditt SaaS-program och möjliggör kommunikation mellan lösningens komponenter. Hur du utformar ditt nätverk har en direkt effekt på lösningens säkerhet, drift, kostnad, prestanda och tillförlitlighet. En strukturerad metod för din nätverksstrategi blir ännu viktigare när molnmiljön växer.
Besluta om en strategi och topologi för nätverksdistribution
SaaS-lösningar har unika nätverkskrav. När du registrerar fler kunder och deras användning ökar ändras nätverkskraven. Det kan vara svårt att hantera tillväxten på grund av begränsade resurser, till exempel IP-adressintervall. Nätverksdesignen påverkar säkerhet och kundisolering. Genom att planera din nätverksstrategi kan du hantera tillväxt, förbättra säkerheten och minska driftskomplexiteten.
Utformningsbeaktanden
Planera din strategi för nätverksdistribution baserat på din innehavarmodell. Bestäm om dina nätverksresurser ska delas mellan kunder, dedikerade till en enskild kund eller en kombination. Det här valet påverkar programmets funktioner, säkerhet och kundisolering.
Det är vanligt att dela nätverksresurser, till exempel virtuella nätverk och Azure Front Door-profiler, mellan flera kunder. Den här metoden minskar kostnaderna och driftkostnaderna. Det förenklar också anslutningen. Du kan enkelt ansluta en kunds resurser till delade resurser, till exempel delade lagringskonton eller ett kontrollplan.
Dedikerade nätverksresurser för varje kund kan dock vara nödvändiga för att upprätta hög säkerhet och efterlevnad. För att till exempel stödja en hög grad av nätverkssegmentering mellan kunder använder du virtuella nätverk som gräns. Dedikerade resurser kan vara nödvändiga när antalet nätverksresurser för alla kunder överskrider kapaciteten för ett enda delat nätverk.
Planera för antalet nätverksresurser som varje kund behöver genom att överväga omedelbara och framtida krav. Kundkrav och Azure-resursgränser kan tvinga fram specifika resultat. Olika resurser kan kräva olika distributionsstrategier, till exempel att använda separata nätverk för peering för virtuella nätverk med kundägda virtuella Azure-nätverk.
Mer information om hur du delar resurser i en SaaS-lösning finns i Resursorganisation för SaaS-arbetsbelastningar.
Förstå nätverkstopologier. Nätverkstopologier delas vanligtvis in i tre kategorier:
Platt nätverk: Ett enskilt, isolerat nätverk med undernät för segmentering. Lämplig när du har ett enda program med flera klientorganisationer med en enkel nätverkslayout. Platta nätverk kan nå resursgränser och kräva fler nätverk när du skalar, vilket ökar omkostnaderna och kostnaderna. Om du planerar att vara värd för flera program eller använda dedikerade distributionsstämplar i samma virtuella nätverk kan du behöva en komplex nätverkslayout.
Hubb och eker: Ett centraliserat hubbnätverk med peering till isolerade ekernätverk. Lämpar sig för hög skalbarhet och kundisolering eftersom varje kund eller program har en egen eker som endast kommunicerar med hubben. Du kan snabbt distribuera fler ekrar efter behov så att resurser i hubben kan användas av alla ekrar. Transitiv eller eker-till-eker-kommunikation via hubben är inaktiverad som standard, vilket hjälper till att upprätthålla kundisolering i SaaS-lösningar.
Inget nätverk: Används för Azure PaaS-tjänster där du kan vara värd för komplexa arbetsbelastningar utan att distribuera virtuella nätverk. Azure App Service möjliggör till exempel direkt integrering med andra PaaS-tjänster via Azure-stamnätverket. Även om den här metoden förenklar hanteringen begränsas flexibiliteten vid distribution av säkerhetskontroller och möjligheten att optimera prestanda. Den här metoden kan fungera bra för molnbaserade program. När din lösning utvecklas kan du förvänta dig att övergå till en topologi med hubb och eker över tid.
Kompromiss: Komplexitet och säkerhet. Om du startar utan en definierad nätverksgräns kan du minska driftbelastningen med att hantera nätverkskomponenter som säkerhetsgrupper, IP-adressutrymme och brandväggar. En nätverksperimeter är dock viktig för de flesta arbetsbelastningar. I avsaknad av nätverkssäkerhetskontroller förlitar du dig på stark identitets- och åtkomsthantering för att skydda din arbetsbelastning mot skadlig trafik.
Förstå hur arkitektur i flera regioner påverkar nätverkstopologier. I en arkitektur med flera regioner med virtuella nätverk distribueras de flesta nätverksresurser i varje region separat, eftersom brandväggar, virtuella nätverksgatewayer och nätverkssäkerhetsgrupper inte kan delas mellan regioner.
Designrekommendationer
Rekommendation | Förmån |
---|---|
Bestäm vilka nätverkskomponenter som delas och vilka komponenter som är dedikerade till kunden. Dela resurser som debiteras per instans, till exempel Azure Firewall, Azure Bastion och Azure Front Door. |
Upplev balanserat stöd mellan dina krav på säkerhet och isolering samtidigt som du minskar kostnaderna och driftbelastningen. |
Börja med en platt topologi eller ingen nätverksmetod. Granska alltid säkerhetskrav först, eftersom dessa metoder erbjuder begränsad isolering och trafikkontroller. |
Du kan minska komplexiteten och kostnaden för din lösning med hjälp av enklare nätverkstopologier. |
Överväg nav- och ekertopologier för komplexa behov eller när du distribuerar dedikerade virtuella nätverk per kund. Använd hubben för att vara värd för delade nätverksresurser i kundnätverk. | Du kan skala enklare och förbättra din kostnadseffektivitet genom att dela resurser via hubbnätverket. |
Utforma en säker nätverksperimeter
Nätverksperimetern upprättar säkerhetsgränsen mellan ditt program och andra nätverk, inklusive Internet. Genom att dokumentera nätverksperimetern kan du skilja mellan olika typer av trafikflöden:
- Inkommande trafik, som kommer till nätverket från en extern källa.
- Intern trafik, som går mellan komponenter i nätverket.
- Utgående trafik, som lämnar nätverket.
Varje flöde omfattar olika risker och kontroller. Till exempel krävs flera säkerhetskontroller för att inspektera och bearbeta inkommande trafik.
Viktigt!
Som en allmän metod bör du alltid följa en noll förtroendemetod. Kontrollera att all trafik kontrolleras och inspekteras, inklusive intern trafik.
Dina kunder kan också ha specifika efterlevnadskrav som påverkar din arkitektur. Om de till exempel behöver SOC 2-efterlevnad måste de implementera olika nätverkskontroller, inklusive en brandvägg, brandvägg för webbprogram och nätverkssäkerhetsgrupper, för att uppfylla säkerhetskraven. Även om du inte behöver följa dessa utökningsfaktorer omedelbart när du utformar din arkitektur.
Utformningsbeaktanden
Skydda och hantera inkommande trafik. Kontrollera den här trafiken efter inkommande hot.
Med brandväggar kan du blockera skadliga IP-adresser och slutföra avancerade analyser för att skydda mot intrångsförsök. Brandväggar kan dock vara kostsamma. Utvärdera dina säkerhetskrav för att avgöra om en brandvägg krävs.
Webbprogram är sårbara för vanliga attacker, till exempel SQL-inmatning, skript för flera webbplatser och andra OWASP:s 10 främsta sårbarheter. Azure Web Application Firewall skyddar mot dessa attacker och är integrerad med Application Gateway och Azure Front Door. Granska nivåerna för dessa tjänster för att förstå vilka WAF-funktioner som finns i vilka produkter.
DDoS-attacker är en risk för internetanslutna program. Azure tillhandahåller grundläggande skyddsnivå utan kostnad. Azure DDoS Protection ger avancerat skydd genom att lära dig dina trafikmönster och justera skyddet i enlighet med detta, även om de kostar något. Om du använder Front Door kan du dra nytta av de inbyggda DDoS-funktionerna.
Utöver säkerheten kan du också manipulera inkommande trafik för att förbättra programmets prestanda med hjälp av cachelagring och belastningsutjämning.
Överväg att använda en omvänd proxytjänst som Azure Front Door för global HTTP(S) trafikhantering. Du kan också använda Application Gateway eller andra Azure-tjänster för inkommande trafikkontroll. Mer information om alternativ för belastningsutjämning i Azure finns i Alternativ för belastningsutjämning.
Skydda intern trafik. Se till att trafiken mellan programmet och dess komponenter är säker för att förhindra skadlig åtkomst. Skydda dessa resurser och förbättra prestanda med hjälp av intern trafik i stället för routning via Internet. Azure Private Link används ofta för att ansluta till Azure-resurser via en intern IP-adress i nätverket. För vissa resurstyper kan tjänstslutpunkter vara ett mer kostnadseffektivt alternativ. Om du aktiverar offentlig Internetanslutning för dina resurser kan du förstå hur du begränsar trafiken med ip-adresser och programidentiteter, till exempel hanterade identiteter.
Skydda utgående trafik. I vissa lösningar kontrollerar du utgående trafik för att förhindra dataexfiltrering, särskilt för regelefterlevnad och företagskunder. Använd brandväggar för att hantera och granska utgående trafik och blockera anslutningar till obehöriga platser.
Planera hur du skalar utgående anslutningar och SNAT. SNAT-portöverbelastning (Source Network Address Translation) kan påverka program med flera klienter. Dessa program behöver ofta distinkta nätverksanslutningar för varje klientorganisation, och att dela resurser mellan kunder ökar risken för SNAT-överbelastning när kundbasen växer. Du kan minska SNAT-överbelastningen med hjälp av Azure NAT Gateway, brandväggar som Azure Firewall eller en kombination av de två metoderna.
Designrekommendationer
Rekommendation | Förmån |
---|---|
Underhålla en katalog över de nätverksslutpunkter som exponeras för Internet. Samla in information som IP-adress (om statisk), värdnamn, portar, protokoll som används och motivering för anslutningar. Dokumentera hur du planerar att skydda varje slutpunkt. |
Den här listan utgör grunden för din perimeterdefinition, så att du kan fatta explicita beslut om att hantera trafik via din lösning. |
Förstå Funktionerna i Azure-tjänsten för att begränsa åtkomsten och förbättra skyddet. Om du till exempel exponerar lagringskontoslutpunkter för kunder krävs ytterligare kontroller som signaturer för delad åtkomst, brandväggar för lagringskonton och användning av separata lagringskonton för intern och extern användning. |
Du kan välja kontroller som uppfyller dina säkerhets-, kostnads- och prestandabehov. |
För HTTP(S)-baserade program använder du en omvänd proxy, till exempel Azure Front Door eller Application Gateway. | Omvända proxyservrar ger ett brett utbud av funktioner för prestandaförbättringar, återhämtning, säkerhet och för att minska driftskomplexiteten. |
Inspektera inkommande trafik med hjälp av en brandvägg för webbprogram. Undvik att exponera webbaserade resurser som en App Service eller Azure Kubernetes Service (AKS) direkt till Internet. |
Du kan mer effektivt skydda dina webbprogram mot vanliga hot och minska lösningens totala exponering. |
Skydda ditt program mot DDoS-attacker. Använd Azure Front Door eller Azure DDoS Protection beroende på vilka protokoll som används av dina offentliga slutpunkter. |
Skydda din lösning mot en vanlig typ av angrepp. |
Om programmet kräver utgående anslutning i stor skala använder du NAT Gateway eller en brandvägg för att tillhandahålla ytterligare SNAT-portar. | Du kan stödja högre skalningsnivåer. |
Anslutning mellan nätverk
I vissa scenarier kan du behöva ansluta till resurser utanför Azure, till exempel data i kundens privata nätverk eller tillgångar på en annan molnleverantör i en konfiguration med flera moln. Dessa behov kan komplicera din nätverksdesign, vilket kräver olika metoder för att implementera anslutningar mellan nätverk baserat på dina specifika krav.
Utformningsbeaktanden
Identifiera de slutpunkter som programmet behöver anslutning till. Programmet kan behöva kommunicera med andra tjänster, till exempel lagringstjänster och databaser. Dokumentera ägaren, platsen och anslutningstypen. Du kan sedan välja lämplig metod för att ansluta till dessa slutpunkter. Vanliga metoder är:
Resursplats Ägare Anslutningsalternativ att överväga Azure Kund - Privat slutpunkt (över Microsoft Entra ID-klienter)
- Peering för virtuella nätverk (över Microsoft Entra ID-klienter)
- Tjänstslutpunkt (över Microsoft Entra ID-klienter)
Annan molnleverantör ISV eller kund - Plats-till-plats-VPN
- ExpressRoute
- Internet
Lokal ISV eller kund - Plats-till-plats-VPN
- ExpressRoute
- Internet
Private Link och privat slutpunkt. Tillhandahålla säker anslutning till olika Azure-resurser, inklusive interna lastbalanserare för virtuella datorer. De ger privat åtkomst till din SaaS-lösning för kunder, även om de har kostnadsöverväganden.
Kompromiss: Säkerhet och kostnad. Privat länk ser till att din trafik förblir inom ditt privata nätverk och rekommenderas för nätverksanslutning mellan Microsoft Entra-klienter. Varje privat slutpunkt medför dock kostnader som kan läggas till baserat på dina säkerhetsbehov. Tjänstslutpunkter kan vara ett kostnadseffektivt alternativ som behåller trafiken i Microsofts stamnätverk samtidigt som det ger en viss nivå av privat anslutning.
Tjänstslutpunkt. Dirigerar trafik till PaaS-resurser via Microsofts stamnätverk och skyddar kommunikation från tjänst till tjänst. De kan vara kostnadseffektiva för program med hög bandbredd men kräver att du konfigurerar och underhåller åtkomstkontrollistor för säkerhet. Stöd för tjänstslutpunkter mellan Microsoft Entra ID-klienter varierar beroende på Azure-tjänst. Kontrollera produktdokumentationen för varje tjänst du använder.
Peering för virtuella nätverk ansluter två virtuella nätverk, vilket gör att resurser i det ena nätverket kan komma åt IP-adresser i det andra. Det underlättar anslutningen till privata resurser i ett virtuellt Azure-nätverk. Åtkomst kan hanteras med hjälp av nätverkssäkerhetsgrupper, men det kan vara svårt att framtvinga isolering. Därför är det viktigt att planera nätverkstopologin baserat på specifika kundbehov.
Virtuella privata nätverk (VPN) skapar en säker tunnel via Internet mellan två nätverk, inklusive mellan molnleverantörer och lokala platser. Plats-till-plats-VPN använder nätverksinstallationer i varje nätverk för konfiguration. De erbjuder ett alternativ för lågkostnadsanslutning men kräver konfiguration och garanterar inte förutsägbart dataflöde.
ExpressRoute tillhandahåller en dedikerad, högpresterande, privat anslutning mellan Azure och andra molnleverantörer eller lokala nätverk. Det säkerställer förutsägbara prestanda och undviker Internettrafik men medför högre kostnader och kräver mer komplex konfiguration.
Planera baserat på målet. Du kan behöva ansluta till resurser i olika Microsoft Entra ID-klienter, särskilt om målresursen finns i en kunds Azure-prenumeration. Överväg att använda privata slutpunkter, ett plats-till-plats-VPN eller genom peering av virtuella nätverk. Mer information finns i Peering virtual networks in each Microsoft Entra ID tenant (Peering virtual networks in each Microsoft Entra ID tenant).
Om du vill ansluta till resurser som finns i en annan molnleverantör är det vanligt att använda offentlig Internetanslutning, ett plats-till-plats-VPN eller ExpressRoute. Mer information finns i Anslutning till andra molnleverantörer.
Förstå effekterna av anslutningen på nätverkstopologin. Ett virtuellt Azure-nätverk kan bara ha en virtuell nätverksgateway som kan ansluta till flera platser via plats-till-plats-VPN eller ExpressRoute. Men det finns gränser för antalet anslutningar via en gateway, och det kan vara svårt att isolera kundtrafiken. För flera anslutningar till olika platser planerar du nätverkstopologin i enlighet med detta, eventuellt genom att distribuera ett separat virtuellt nätverk för varje kund.
Förstå konsekvenserna för PLANERING av IP-adresser. Vissa anslutningsmetoder tillhandahåller automatiskt NAT (Network Address Translation) och undviker problem med överlappande IP-adresser. Virtuell nätverkspeering och ExpressRoute utför dock inte NAT. När du använder dessa metoder bör du planera dina nätverksresurser och IP-adressallokeringar noggrant för att undvika överlappande IP-adressintervall och säkerställa framtida tillväxt. IP-adressplanering kan vara komplext, särskilt när du ansluter till tredje part som kunder, så tänk på potentiella konflikter med deras IP-intervall.
Förstå fakturering av utgående nätverk. Azure fakturerar vanligtvis för utgående nätverkstrafik när den lämnar Microsoft-nätverket eller flyttas mellan Azure-regioner. När du utformar lösningar för flera regioner eller flera moln är det viktigt att förstå kostnadskonsekvenserna. Arkitekturalternativ, till exempel att använda Azure Front Door eller ExpressRoute, kan påverka hur du debiteras för nätverkstrafik.
Designrekommendationer
Rekommendation | Förmån |
---|---|
Föredrar privata nätverksmetoder för att ansluta mellan nätverk för att prioritera säkerhet. Överväg endast routning via Internet när du har utvärderat de associerade säkerhets- och prestandakonsekvenserna. |
Privat trafik passerar en säker nätverkssökväg, vilket bidrar till att minska många typer av säkerhetsrisker. |
När du ansluter till kundresurser som finns i deras Azure-miljöer använder du Private Link, tjänstslutpunkter eller peerings för virtuella nätverk. | Du kan behålla trafiken i Microsoft-nätverket, vilket bidrar till att minska kostnaderna och driftskomplexiteten jämfört med andra metoder. |
När du ansluter mellan molnleverantörer eller till lokala nätverk använder du plats-till-plats-VPN eller ExpressRoute. | Dessa tekniker ger säkra anslutningar mellan leverantörer. |
Distribuera till miljöer som ägs av kunder
Din affärsmodell kan kräva att du är värd för programmet eller dess komponenter i en kunds Azure-miljö. Kunden hanterar sin egen Azure-prenumeration och betalar direkt kostnaden för de resurser som krävs för att köra programmet. Som lösningsleverantör ansvarar du för att hantera lösningen, till exempel den första distributionen, tillämpa konfigurationen och distribuera uppdateringar till programmet.
I sådana situationer tar kunderna ofta med sig ett eget nätverk och distribuerar ditt program till ett nätverksutrymme som de definierar. Azure Managed Applications erbjuder funktioner för att underlätta den här processen. Mer information finns i Använda befintligt virtuellt nätverk med Azure Managed Applications.
Utformningsbeaktanden
IP-adressintervall och konflikter. När kunder distribuerar och hanterar virtuella nätverk ansvarar de för att hantera nätverkskonflikter och skalning. Du bör dock förutse olika kundanvändningsscenarier. Planera för distributioner i miljöer med minimalt IP-adressutrymme med hjälp av IP-adresser effektivt och undvik hårdkodade IP-adressintervall för att förhindra överlappningar med kundintervall.
Du kan också distribuera ett dedikerat virtuellt nätverk för din lösning. Du kan använda Private Link eller peering för virtuella nätverk för att göra det möjligt för kunder att ansluta till resurserna. Dessa metoder beskrivs i Anslutningar mellan nätverk. Om du har definierat ingress- och utgående punkter utvärderar du NAT som en metod för att eliminera problem som orsakas av överlappningar av IP-adresser.
Ge nätverksåtkomst i hanteringssyfte. Granska de resurser som du distribuerar till kundmiljöer och planera hur du kommer åt dem för att övervaka, hantera eller konfigurera om dem. När resurser distribueras med privata IP-adresser till en kundägd miljö kontrollerar du att du har en nätverkssökväg för att nå dem från ditt eget nätverk. Överväg hur du underlättar både program- och resursändringar, till exempel push-överföring av en ny version av programmet eller uppdatering av en Azure-resurskonfiguration.
I vissa lösningar kan du använda funktioner som tillhandahålls av Azure Managed Applications, till exempel just-in-time-åtkomst och distribution av uppdateringar till program. Om du behöver mer kontroll kan du vara värd för en slutpunkt i kundens nätverk som kontrollplanet kan ansluta till, vilket ger åtkomst till dina resurser. Den här metoden kräver ytterligare Azure-resurser och utveckling för att uppfylla kraven på säkerhet, drift och prestanda. Ett exempel på hur du implementerar den här metoden finns i Uppdateringsexempel för Azure-hanterade program.
Designrekommendationer
Rekommendation | Förmån |
---|---|
Använd Azure Managed Applications för att distribuera och hantera kunddistribuerade resurser. | Azure Managed Applications tillhandahåller en mängd funktioner som gör att du kan distribuera och hantera resurser i en kunds Azure-prenumeration. |
Minimera antalet IP-adresser som du använder i kundens virtuella nätverksutrymme. | Kunder har ofta begränsad IP-adresstillgänglighet. Genom att minimera ditt fotavtryck och koppla bort skalningen från ip-adressanvändningen kan du bredda antalet kunder som kan använda din lösning och möjliggöra högre tillväxtnivåer. |
Planera hur du får nätverksåtkomst för att hantera resurser i kundmiljöer, överväg övervakning, ändringar i resurskonfigurationen och programuppdateringar. | Du kan konfigurera de resurser som du hanterar direkt. |
Bestäm om du vill distribuera ett dedikerat virtuellt nätverk eller integrera med en kunds befintliga virtuella nätverk. | Genom att planera i förväg ser du till att du kan uppfylla kundernas krav på isolering, säkerhet och integrering med deras andra system. |
Inaktivera offentlig åtkomst på Azure-resurser som standard. Föredrar privat ingress där det är möjligt. | Du minskar omfattningen av de nätverksresurser som du och dina kunder behöver skydda. |
Ytterligare resurser
Multitenancy är en viktig affärsmetod för att utforma SaaS-arbetsbelastningar. De här artiklarna innehåller mer information om nätverksdesign:
- Arkitekturmetoder för nätverk i lösningar för flera klientorganisationer
- Innehavarmodeller
- Nätverkstopologi för nav och eker
- Överväganden för Azure NAT Gateway för flera klientorganisationer
- Arkitekturmetoder för klientintegrering och dataåtkomst
Gå vidare
Lär dig mer om dataplattformens överväganden för dataintegritet och prestanda för SaaS-arbetsbelastningar i Azure.