Redigera

Dela via

Inkommande och utgående Internetanslutningar för SAP på Azure

Azure Virtual Machines
Azure Virtual Network
Azure Application Gateway
Azure Load Balancer

Den här artikeln innehåller en uppsättning beprövade metoder för att förbättra säkerheten för inkommande och utgående Internetanslutningar för din SAP på Azure-infrastrukturen.

Arkitektur

Diagram som visar en lösning för internetuppkopplad kommunikation för SAP i Azure.

Ladda ned en Visio-fil med arkitekturerna i den här artikeln.

Den här lösningen illustrerar en gemensam produktionsmiljö. Du kan minska konfigurationens storlek och omfattning så att de passar dina behov. Den här minskningen kan gälla för SAP-liggande: färre virtuella datorer (VM), ingen hög tillgänglighet eller inbäddade SAP Web Dispatchers i stället för diskreta virtuella datorer. Det kan också gälla för alternativ till nätverksdesignen, enligt beskrivningen senare i den här artikeln.

Kundernas krav, som drivs av affärsprinciper, kräver anpassningar av arkitekturen, särskilt till nätverksdesignen. När det är möjligt har vi inkluderat alternativ. Många lösningar är livskraftiga. Välj en metod som passar ditt företag. Den måste hjälpa dig att skydda dina Azure-resurser men ändå tillhandahålla en högpresterande lösning.

Haveriberedskap (DR) beskrivs inte i den här arkitekturen. För nätverksdesignen gäller samma principer och design som gäller för primära produktionsregioner. I nätverksdesignen kan du, beroende på vilka program som skyddas av DR, överväga att aktivera DR i en annan Azure-region. Mer information finns i artikeln Översikt över haveriberedskap och riktlinjer för infrastruktur för SAP-arbetsbelastning

Arbetsflöde

  • Det lokala nätverket ansluter till en central hubb via Azure ExpressRoute. Det virtuella hubbnätverket innehåller ett gateway-undernät, ett Azure Firewall-undernät, ett undernät för delade tjänster och ett Azure Application Gateway-undernät.
  • Hubben ansluter till en SAP-produktionsprenumeration via peering för virtuella nätverk. Den här prenumerationen innehåller två virtuella ekernätverk:
    • Det virtuella SAP-perimeternätverket innehåller ett undernät för SAP-perimeterprogram.
    • Det virtuella SAP-produktionsnätverket innehåller ett programundernät och ett databasundernät.
  • Hubbprenumerationen och SAP-produktionsprenumerationen ansluter till Internet via offentliga IP-adresser.

Komponenter

Prenumerationer. Den här arkitekturen implementerar azure-landningszonens metod. En Azure-prenumeration används för varje arbetsbelastning. En eller flera prenumerationer används för centrala IT-tjänster som innehåller nätverkshubben och centrala, delade tjänster som brandväggar eller Active Directory och DNS. En annan prenumeration används för SAP-produktionsarbetsbelastningen. Använd beslutsguiden i Cloud Adoption Framework för Azure för att fastställa den bästa prenumerationsstrategin för ditt scenario.

Virtuella nätverk. Azure Virtual Network ansluter Azure-resurser till varandra med förbättrad säkerhet. I den här arkitekturen ansluter det virtuella nätverket till en lokal miljö via en ExpressRoute- eller VPN-gateway (Virtuellt privat nätverk) som distribueras i hubben för en hubb-ekertopologi. SAP-produktionslandskapet använder sina egna virtuella ekernätverk. Två distinkta virtuella ekernätverk utför olika uppgifter och undernät ger nätverkssegregering.

Genom att separera i undernät efter arbetsbelastning blir det enklare att använda nätverkssäkerhetsgrupper (NSG:er) för att ange säkerhetsregler för virtuella programdatorer eller Azure-tjänster som distribueras.

Zonredundant gateway. En gateway ansluter distinkta nätverk och utökar ditt lokala nätverk till det virtuella Azure-nätverket. Vi rekommenderar att du använder ExpressRoute för att skapa privata anslutningar som inte använder det offentliga Internet. Du kan också använda en plats-till-plats-anslutning . Använd zonredundanta Azure ExpressRoute- eller VPN-gatewayer för att skydda mot zonfel. Se Zonredundanta virtuella nätverksgatewayer för en förklaring av skillnaderna mellan en zonindelad distribution och en zonredundant distribution. För en zondistribution av gatewayerna måste du använda Standard SKU IP-adresser.

NSG:er. Om du vill begränsa nätverkstrafiken till och från det virtuella nätverket skapar du NSG:er och tilldelar dem till specifika undernät. Ge säkerhet för enskilda undernät med hjälp av arbetsbelastningsspecifika NSG:er.

Programsäkerhetsgrupper. Om du vill definiera detaljerade nätverkssäkerhetsprinciper i dina NSG:er baserat på arbetsbelastningar som är centrerade på program använder du programsäkerhetsgrupper i stället för explicita IP-adresser. Genom att använda programsäkerhetsgrupper kan du gruppera virtuella datorer efter syfte, till exempel SAP SID. Programsäkerhetsgrupper hjälper till att skydda program genom att filtrera trafik från betrodda segment i nätverket.

Privat slutpunkt. Många Azure-tjänster fungerar som offentliga tjänster genom design som är tillgängliga via Internet. Om du vill tillåta privat åtkomst via ditt privata nätverksintervall kan du använda privata slutpunkter för vissa tjänster. Privata slutpunkter är nätverksgränssnitt i ditt virtuella nätverk. De tar effektivt in tjänsten i ditt privata nätverk.

Azure Application Gateway. Application Gateway är en lastbalanserare för webbtrafik. Med funktionen Brandvägg för webbprogram är det den perfekta tjänsten för att exponera webbprogram för Internet med förbättrad säkerhet. Application Gateway kan betjäna antingen offentliga (Internet) eller privata klienter, eller båda, beroende på konfigurationen.

I arkitekturen tillåter Application Gateway, med hjälp av en offentlig IP-adress, inkommande anslutningar till SAP-liggande via HTTPS. Dess serverdelspool är två eller flera virtuella SAP Web Dispatcher-datorer som används för resursallokering och ger hög tillgänglighet. Programgatewayen är en omvänd proxy och lastbalanserare för webbtrafik, men den ersätter inte SAP Web Dispatcher. SAP Web Dispatcher tillhandahåller programintegrering med dina SAP-system och innehåller funktioner som Application Gateway i sig inte tillhandahåller. Klientautentisering, när den når SAP-systemen, utförs av SAP-programskiktet internt eller via enkel inloggning. När du aktiverar Azure DDoS-skydd bör du överväga att använda SKU :n för DDoS-nätverksskydd eftersom du ser rabatter för Application Gateway Web Application Firewall.

För optimala prestanda aktiverar du HTTP/2-stöd för Application Gateway, SAP Web Dispatcher och SAP NetWeaver.

Azure Load Balancer. Azure Standard Load Balancer tillhandahåller nätverkselement för design med hög tillgänglighet för dina SAP-system. För klustrade system tillhandahåller Standard Load Balancer den virtuella IP-adressen för klustertjänsten, till exempel ASCS/SCS-instanser och databaser som körs på virtuella datorer. Du kan också använda Standard Load Balancer för att ange IP-adressen för det virtuella SAP-värdnamnet för icke-klustrade system när sekundära IP-adresser på Azure-nätverkskort inte är ett alternativ. Användningen av Standard Load Balancer i stället för Application Gateway för att hantera utgående Internetåtkomst beskrivs senare i den här artikeln.

Nätverksdesign

Arkitekturen använder två diskreta virtuella nätverk, båda virtuella ekernätverk som är peer-kopplade till det centrala virtuella hubbens virtuella nätverk. Det finns ingen eker-till-eker-peering. En stjärntopologi används, där kommunikationen passerar genom hubben. Separationen av nätverk hjälper till att skydda programmen mot överträdelser.

Ett programspecifikt perimeternätverk (även kallat DMZ) innehåller de Internetuppkopplade programmen, till exempel SAProuter, SAP Cloud Connector, SAP Analytics Cloud Agent med flera. I arkitekturdiagrammet heter perimeternätverket SAP-perimeter – virtuellt ekernätverk. På grund av beroenden i SAP-system utför SAP-teamet vanligtvis distribution, konfiguration och hantering av dessa tjänster. Därför finns dessa SAP-perimetertjänster ofta inte i en central hubbprenumeration och nätverk. Organisationsutmaningar beror ofta på en sådan central hubbplacering av arbetsbelastningsspecifika program eller tjänster.

Det här är några av fördelarna med att använda ett separat virtuellt SAP-perimeternätverk:

  • Snabb och omedelbar isolering av komprometterade tjänster om ett intrång upptäcks. Om du tar bort peering för virtuella nätverk från SAP-perimetern till hubben isoleras omedelbart SAP-perimeterarbetsbelastningarna och SAP-programmets virtuella nätverksprogram från Internet. Att ändra eller ta bort en NSG-regel som tillåter åtkomst påverkar endast nya anslutningar och klipper inte ut befintliga anslutningar.
  • Strängare kontroller i det virtuella nätverket och undernätet, med en strikt låsning på kommunikationspartner in och ut ur SAP-perimeternätverket och SAP-programnätverk. Du kan utöka kontrollen till behöriga användare och åtkomstmetoder i SAP-perimeterprogram, med olika auktoriseringsserverdelar, privilegierad åtkomst eller inloggningsuppgifter för SAP-perimeterprogram.

Nackdelarna är ökad komplexitet och extra kostnader för peering av virtuella nätverk för internetbunden SAP-trafik (eftersom kommunikationen måste passera genom peering för virtuella nätverk två gånger). Svarstidens inverkan på peering-trafik med eker-hubb-ekrar beror på alla brandväggar som finns på plats och måste mätas.

Förenklad arkitektur

För att åtgärda rekommendationerna i den här artikeln men begränsa nackdelarna kan du använda ett virtuellt ekernätverk för både perimeter- och SAP-programmen. Följande arkitektur innehåller alla undernät i ett enda virtuellt SAP-produktionsnätverk. Fördelen med omedelbar isolering genom att avsluta peering för virtuella nätverk till SAP-perimetern om den komprometteras inte är tillgänglig. I det här scenariot påverkar ändringar av NSG:er endast nya anslutningar.

Diagram som visar en förenklad arkitektur för internetuppkopplad kommunikation för SAP på Azure.

Ladda ned en Visio-fil med arkitekturerna i den här artikeln.

För distributioner som är mindre i storlek och omfattning kan den förenklade arkitekturen passa bättre, och den följer fortfarande principerna för den mer komplexa arkitekturen. Den här artikeln refererar, om inget annat anges, till den mer komplexa arkitekturen.

Den förenklade arkitekturen använder en NAT-gateway i SAP-perimeterundernätet. Den här gatewayen tillhandahåller utgående anslutning för SAP Cloud Connector och SAP Analytics Cloud Agent- och OS-uppdateringar för de distribuerade virtuella datorerna. Eftersom SAProuter kräver både inkommande och utgående anslutningar går SAProuter-kommunikationsvägen genom brandväggen i stället för att använda NAT-gatewayen. Den förenklade arkitekturen placerar även Application Gateway med sitt eget avsedda undernät i det virtuella SAP-perimeternätverket, som en alternativ metod för hubb-virtuellt nätverk.

En NAT-gateway är en tjänst som tillhandahåller statiska offentliga IP-adresser för utgående anslutning. NAT-gatewayen tilldelas till ett undernät. All utgående kommunikation använder NAT-gatewayens IP-adresser för internetåtkomst. Inkommande anslutningar använder inte NAT-gatewayen. Program som SAP Cloud Connector eller VM OS-uppdateringstjänster som har åtkomst till lagringsplatser på Internet kan använda NAT-gatewayen i stället för att dirigera all utgående trafik via den centrala brandväggen. Ofta implementeras användardefinierade regler på alla undernät för att tvinga internetbunden trafik från alla virtuella nätverk via den centrala brandväggen.

Beroende på dina krav kan du kanske använda NAT-gatewayen som ett alternativ till den centrala brandväggen för utgående anslutningar. På så sätt kan du minska belastningen på den centrala brandväggen när du kommunicerar med NSG-tillåtna offentliga slutpunkter. Du får också utgående IP-kontroll eftersom du kan konfigurera målbrandväggsregler på en angivet IP-lista över NAT-gatewayen. Exempel är att nå offentliga Azure-slutpunkter som används av offentliga tjänster, os-korrigeringsdatabaser eller gränssnitt från tredje part.

För en konfiguration med hög tillgänglighet bör du tänka på att NAT-gatewayen endast distribueras i en enda zon och för närvarande inte är redundant i flera zoner. Med en enda NAT-gateway är det inte idealiskt för SAP-distributioner som använder zonredundant distribution (korszon) för virtuella datorer.

Användning av nätverkskomponenter i ett SAP-landskap

Ett arkitekturdokument visar vanligtvis bara ett SAP-system eller liggande. Detta gör dem lättare att förstå. Resultatet är att den större bilden ofta, hur arkitekturen passar in i ett större SAP-landskap som innehåller flera systemspår och nivåer, inte åtgärdas.

Centrala nätverkstjänster, som brandväggen, NAT-gatewayen och proxyservrarna om de distribueras, används bäst i hela SAP-landskapet på alla nivåer: produktion, förproduktion, utveckling och sandbox-miljö. Beroende på dina krav, organisationens storlek och affärsprinciper kanske du vill överväga separata implementeringar per nivå, eller en produktions- och en sandbox-/testmiljö.

Tjänster som vanligtvis hanterar ett SAP-system är bäst avgränsade enligt beskrivningen här:

  • Lastbalanserare bör vara dedikerade till enskilda tjänster. Företagspolicyn dikterar namngivning och gruppering av resurser. Vi rekommenderar en lastbalanserare för ASCS/SCS och ERS och en annan för databasen, avgränsad för varje SAP SID. En enskild lastbalanserare för både (A)SCS- och ERS- och DB-kluster i ett SAP-system är också en bra design. Den här konfigurationen hjälper till att säkerställa att felsökningen inte blir komplex, med många klientdels- och serverdelspooler och belastningsutjämningsregler på en enda lastbalanserare. En enskild lastbalanserare per SAP SID säkerställer också att placeringen i resursgrupper matchar andra infrastrukturkomponenters placering.
  • Application Gateway, som en lastbalanserare, tillåter flera serverdelar, klientdelar, HTTP-inställningar och regler. Beslutet att använda en programgateway för flera användningsområden är vanligare här eftersom inte alla SAP-system i miljön kräver offentlig åtkomst. Flera användningsområden i den här kontexten omfattar olika web dispatcher-portar för samma SAP S/4HANA-system eller olika SAP-miljöer. Vi rekommenderar minst en programgateway per nivå (produktion, icke-produktion och sandbox-miljö) om inte komplexiteten och antalet anslutna system blir för hög.
  • SAP-tjänster som SAProuter, Cloud Connector och Analytics Cloud Agent distribueras baserat på programkrav, antingen centralt eller uppdelat. Det är ofta önskvärt att separera produktion och icke-produktion.

Storlek och design för undernät

När du utformar undernät för ditt SAP-landskap bör du följa storleks- och designprinciperna:

  • Flera PaaS-tjänster (Plattform som en tjänst) i Azure kräver egna utsedda undernät.
  • Application Gateway rekommenderar ett /24-undernät för skalning. Om du väljer att begränsa Application Gateway-skalan kan ett mindre undernät användas, minst /26 eller större. Du kan inte använda båda versionerna av Application Gateway (1 och 2) i samma undernät.
  • Om du använder Azure NetApp Files för dina NFS/SMB-resurser eller databaslagring krävs ett särskilt undernät. Ett /24-undernät är standard. Använd dina krav för att fastställa rätt storlek.
  • Om du använder virtuella SAP-värdnamn behöver du mer adressutrymme i dina SAP-undernät, inklusive SAP-perimetern.
  • Centrala tjänster som Azure Bastion eller Azure Firewall, som vanligtvis hanteras av ett centralt IT-team, kräver egna dedikerade undernät av tillräcklig storlek.

Genom att använda dedikerade undernät för SAP-databaser och program kan du ange att NSG:er ska vara striktare, vilket hjälper till att skydda båda programtyperna med sina egna uppsättningar regler. Du kan sedan begränsa databasåtkomsten till SAP-program enklare, utan att behöva använda programsäkerhetsgrupper för detaljerad kontroll. Om du separerar SAP-programmet och databasundernäten blir det också enklare att hantera dina säkerhetsregler i NSG:er.

SAP-tjänster

SAProuter

Du kan använda SAProuter för att göra det möjligt för tredje part som SAP-support eller dina partner att komma åt ditt SAP-system. SAProuter körs på en virtuell dator i Azure. Routningsbehörigheter för att använda SAProuter lagras i en platt fil med namnet saprouttab. Saprouttab-posterna tillåter anslutning från valfri TCP/IP-port till ett nätverksmål bakom SAProuter, vanligtvis dina virtuella SAP-systemdatorer. Fjärråtkomst från SAP-stöd förlitar sig på SAProuter. Huvudarkitekturen använder den design som beskrivs tidigare, med en virtuell SAProuter-dator som körs i det avsedda virtuella SAP-perimeternätverket. Via peering för virtuella nätverk kommunicerar SAProuter sedan med dina SAP-servrar som körs i deras egna virtuella ekernätverk och undernät.

SAProuter är en tunnel till SAP eller till dina partner. Den här arkitekturen beskriver användningen av SAProuter med SNC för att upprätta en krypterad programtunnel (nätverksnivå 7) till SAP/partners. Användningen av IPSEC-baserad tunnel omfattas för närvarande inte av den här arkitekturen.

Följande funktioner hjälper till att skydda kommunikationsvägen via Internet:

  • Azure Firewall eller en NVA från tredje part tillhandahåller den offentliga IP-startpunkten i dina Azure-nätverk. Brandväggsregler begränsar kommunikationen till endast auktoriserade IP-adresser. För din anslutning till SAP-stöd noterar SAP 48243 – Integrering av SAProuter-programvaran i en brandväggsmiljö dokumenterar IP-adresserna för SAP-routrar.
  • Precis som brandväggsregler tillåter nätverkssäkerhetsregler kommunikation på SAProuters port, vanligtvis 3299 med det avsedda målet.
  • Du underhåller SAProuters regler för att tillåta/neka i saprouttab-filen och anger vem som kan kontakta SAProuter och vilket SAP-system som kan nås.
  • Ytterligare NSG-regler finns på respektive undernät i SAP-produktionsundernätet som innehåller SAP-systemen.

Anvisningar för hur du konfigurerar SAProuter med Azure Firewall finns i SAProuter-konfiguration med Azure Firewall.

Säkerhetsöverväganden för SAProuter

Eftersom SAProuter inte fungerar i samma programundernät som dina SAP-system kan inloggningsmekanismerna för operativsystemet vara olika. Beroende på dina principer kan du använda en separat inloggningsdomän eller helt värdbaserade autentiseringsuppgifter för SAProuter. Om det finns en säkerhetsöverträdelse är det inte möjligt att ansluta till de interna SAP-systemen på grund av den olika autentiseringsbasen. Nätverksavgränsning i ett sådant fall, som beskrevs tidigare, kan frikoppla ytterligare åtkomst från en komprometterad SAProuter till dina programundernät. Du kan utföra den här isoleringen genom att koppla från peering för virtuella SAP-perimeternätverk.

Överväganden för hög tillgänglighet i SAProuter

Eftersom SAProuter är en enkel körbar fil med en filbaserad routningsbehörighetstabell kan den enkelt startas. Programmet har ingen inbyggd hög tillgänglighet. Om det uppstår ett fel på en virtuell dator eller ett program måste tjänsten starta på en annan virtuell dator. Det är idealiskt att använda ett virtuellt värdnamn för SAProuter-tjänsten. Det virtuella värdnamnet är bundet till en IP-adress som tilldelas som en sekundär IP-konfiguration med den virtuella datorns nätverkskort eller till en intern lastbalanserare som är ansluten till den virtuella datorn. Om SAProuter-tjänsten behöver flyttas till en annan virtuell dator i den här konfigurationen kan det virtuella värdnamnets IP-konfiguration tas bort. Sedan lägger du till det virtuella värdnamnet på en annan virtuell dator utan att behöva ändra routningstabellerna eller brandväggskonfigurationen. De är alla konfigurerade för att använda den virtuella IP-adressen. Mer information finns i Använda virtuella SAP-värdnamn med Linux i Azure.

Sammanhängande SAProuters

Om du vill implementera sammanhängande SAProuters kan du definiera så många som två SAProuters för SAP-supportanslutningar. Den första SAProuter som körs i SAP-perimeterprogrammets undernät ger åtkomst från den centrala brandväggen och från SAP eller SAProuters partner. De enda tillåtna destinationerna är andra SAProuters som körs med specifika arbetsbelastningar. Sammanhängande SAProuters kan använda per nivå, per region eller per SID-separation, beroende på din arkitektur. Den andra SAProuter accepterar endast interna anslutningar från den första SAProuter och ger åtkomst till enskilda SAP-system och virtuella datorer. Med den här designen kan du separera åtkomst och hantering mellan olika team om du behöver det. Ett exempel på en sammanhängande SAProuters finns i SAProuter-konfiguration med Azure Firewall.

SAP Fiori och WebGui

SAP Fiori och andra HTTPS-klientdelar för SAP-program används ofta utanför det interna företagsnätverket. Behovet av att vara tillgängligt på Internet kräver en högsäkerhetslösning för att skydda SAP-programmet. Application Gateway med Brandvägg för webbaserade program är den perfekta tjänsten för detta ändamål.

För användare och program som har åtkomst till det offentliga värdnamnet för den offentliga IP-adress som är kopplad till Application Gateway avslutas HTTPS-sessionen på Application Gateway. En serverdelspool med två eller flera virtuella SAP Web Dispatcher-datorer hämtar resursallokeringssessioner från Application Gateway. Den här interna trafikprogramgatewayen till Web Dispatcher kan vara antingen HTTP eller HTTPS, beroende på krav. Med HTTPS mellan virtuella Application Gateway- och Web Dispatcher-datorer använder du en certifikat- och certifikatkedja som är välkänd för SAP-teamet för varje periodisk certifikatrotation. Brandväggen för webbprogram hjälper till att skydda SAP Web Dispatcher från attacker som kommer via Internet med OWASP-huvudregeluppsättningen. SAP NetWeaver, som ofta är kopplat till Microsoft Entra-ID via enkel inloggning (SSO) utför användarautentisering. De steg som krävs för att konfigurera enkel inloggning för Fiori med hjälp av Application Gateway finns i Enkel inloggning Configuration using SAML and Microsoft Entra ID for Public and Internal URLS (Enkel inloggning Configuration using SAML and Microsoft Entra ID for Public and Internal URL:er).

Tänk på att du måste skydda SAP Web Dispatcher i alla situationer, även om den endast är öppen internt, nås via Application Gateway via offentlig IP-adress eller nås via andra nätverksmedel. Mer information finns i Säkerhetsinformation för SAP Web Dispatcher.

Azure Firewall och Application Gateway

All webbtrafik som tillhandahålls av Application Gateway är HTTPS-baserad och krypterad med det angivna TLS-certifikatet. Du kan använda Azure Firewall som en startpunkt till företagsnätverket via dess offentliga IP-adress och sedan dirigera SAP Fiori-trafik från brandväggen till Application Gateway via en intern IP-adress. Mer information finns i Application Gateway efter brandväggen. Eftersom TCP/IP layer-7-kryptering redan finns på plats via TLS finns det begränsad fördel med att använda en brandvägg i det här scenariot och du kan inte utföra paketgranskning. Fiori kommunicerar via samma externa IP-adress för både inkommande och utgående trafik, vilket vanligtvis inte krävs för SAP Fiori-distributioner.

Det finns några fördelar med en tandem-application gateway och layer-4-brandväggsdistribution:

  • Möjlig integrering med företagsomfattande hantering av säkerhetsprinciper.
  • Nätverkstrafik som bryter mot säkerhetsreglerna ignoreras redan, så den kräver ingen inspektion.

Den här kombinerade distributionen är en bra arkitektur. Metoden för att hantera inkommande Internettrafik beror på din övergripande företagsarkitektur. Du måste också överväga hur den övergripande nätverksarkitekturen passar med åtkomstmetoder från det interna IP-adressutrymmet, till exempel lokala klienter. Det här övervägandet beskrivs i nästa avsnitt.

Application Gateway för interna IP-adresser (valfritt)

Den här arkitekturen fokuserar på internetuppkopplade program. Det finns olika alternativ för klienter som har åtkomst till SAP Fiori, webbgränssnittet för ett SAP NetWeaver-system eller ett annat SAP HTTPS-gränssnitt via en intern, privat IP-adress. Ett scenario är att behandla all åtkomst till Fiori som offentlig åtkomst via den offentliga IP-adressen. Ett annat alternativ är att använda direkt nätverksåtkomst via det privata nätverket till SAP Web Dispatchers, vilket kringgår Application Gateway helt och hållet. Ett tredje alternativ är att använda både privata och offentliga IP-adresser på Application Gateway, vilket ger åtkomst till både Internet och det privata nätverket.

Du kan använda en liknande konfiguration med en privat IP-adress på Application Gateway för endast privat nätverksåtkomst till SAP-liggande. Den offentliga IP-adressen används i det här fallet endast i hanteringssyfte och har ingen lyssnare associerad med den.

Som ett alternativ till att använda Application Gateway kan du använda en lastbalanserare internt. Du kan använda en intern standardlastbalanserare med virtuella Web Dispatcher-datorer som konfigurerats som en resursallokeringsserverdel. I det här scenariot placeras standardlastbalanseraren med de virtuella web dispatcher-datorerna i SAP-undernätet för produktionsprogram och ger aktiv/aktiv belastningsutjämning mellan virtuella Web Dispatcher-datorer.

För internetuppkopplade distributioner rekommenderar vi Application Gateway med Brandvägg för webbprogram i stället för en lastbalanserare med en offentlig IP-adress.

SAP Business Technology Platform (BTP)

SAP BTP är en stor uppsättning SAP-program, SaaS eller PaaS, som vanligtvis nås via en offentlig slutpunkt via Internet. SAP Cloud Connector används ofta för att tillhandahålla kommunikation för program som körs i privata nätverk, till exempel ett SAP S/4HANA-system som körs i Azure. SAP Cloud Connector körs som ett program på en virtuell dator. Det kräver utgående Internetåtkomst för att upprätta en TLS-krypterad HTTPS-tunnel med SAP BTP. Det fungerar som en omvänd anropa proxy mellan det privata IP-intervallet i ditt virtuella nätverk och SAP BTP-program. På grund av den här omvända anropssupporten behöver du inte öppna brandväggsportar eller annan åtkomst för inkommande anslutningar, eftersom anslutningen från det virtuella nätverket är utgående.

Som standard har virtuella datorer utgående Internetåtkomst internt i Azure. Den offentliga IP-adress som används för utgående trafik, när det inte finns någon dedikerad offentlig IP-adress som är associerad med den virtuella datorn, väljs slumpmässigt från poolen med offentliga IP-adresser i den specifika Azure-regionen. Du kan inte kontrollera det. För att säkerställa att utgående anslutningar görs via en kontrollerad och identifierbar tjänst och IP-adress kan du använda någon av följande metoder:

  • En NAT-gateway som är associerad med undernätet eller lastbalanseraren och dess offentliga IP-adress.
  • HTTP-proxyservrar som du använder.
  • En användardefinierad väg som tvingar nätverkstrafiken att flöda till en nätverksinstallation som en brandvägg.

Arkitekturdiagrammet visar det vanligaste scenariot: dirigera internetbunden trafik till det virtuella hubbnätverket och via den centrala brandväggen. Du måste konfigurera ytterligare inställningar i SAP Cloud Connector för att ansluta till ditt SAP BTP-konto.

Hög tillgänglighet för SAP Cloud Connector

Hög tillgänglighet är inbyggd i SAP Cloud Connector. Cloud Connector är installerat på två virtuella datorer. Huvudinstansen är aktiv och skugginstansen är ansluten till den. De delar konfigurationen och hålls synkroniserade internt. Om huvudinstansen inte är tillgänglig försöker den sekundära virtuella datorn ta över huvudrollen och återupprätta TLS-tunneln till SAP BTP. En molnanslutningsmiljö med hög tillgänglighet visas i arkitekturen. Du behöver ingen annan Azure-teknik, till exempel en lastbalanserare eller klusterprogramvara, för konfigurationen. Mer information om konfiguration och drift finns i SAP-dokumentationen.

SAP Analytics Cloud Agent

I vissa programscenarier är SAP Analytics Cloud Agent ett program som är installerat på en virtuell dator. Den använder SAP Cloud Connector för SAP BTP-anslutning. I den här arkitekturen körs den virtuella SAP Analytics Cloud Agent-datorn i SAP-perimeterprogrammets undernät, tillsammans med de virtuella SAP Cloud Connector-datorerna. Information om trafikflödet från privata nätverk som ett virtuellt Azure-nätverk till SAP BTP via SAP Analytics Cloud Agent finns i SAP-dokumentationen.

SAP tillhandahåller Private Link-tjänsten för SAP BTP. Det möjliggör privata anslutningar mellan valda SAP BTP-tjänster och valda tjänster i din Azure-prenumeration och ditt virtuella nätverk. När du använder Private Link-tjänsten dirigeras inte kommunikationen via det offentliga Internet. Det finns kvar i det globala Azure-nätverkets stamnät med hög säkerhet. Kommunikation till Azure-tjänster sker via ett privat adressutrymme. Förbättrat dataexfiltreringsskydd är inbyggt när du använder Private Link-tjänsten, eftersom den privata slutpunkten mappar den specifika Azure-tjänsten till en IP-adress. Åtkomsten är begränsad till den mappade Azure-tjänsten.

För vissa SAP BTP-integreringsscenarier är private link-tjänsten att föredra. För andra är SAP Cloud Connector bättre. Information som hjälper dig att bestämma vilken du ska använda finns i Köra Cloud Connector och SAP Private Link sida vid sida.

SAP RISE/ECS

Om SAP använder SAP-systemet enligt ett SAP RISE/ECS-kontrakt är SAP den hanterade tjänstpartnern. SAP-miljön distribueras av SAP. I SAP:s arkitektur gäller inte arkitekturen som visas här för dina system som körs i RISE med SAP/ECS. Information om hur du integrerar den här typen av SAP-landskap med Azure-tjänster och ditt nätverk finns i Azure-dokumentationen.

Andra KRAV för SAP-kommunikation

Ytterligare överväganden när det gäller internetbunden kommunikation kan gälla för ett SAP-landskap som körs i Azure. Trafikflödet i den här arkitekturen använder en central Azure-brandvägg för den här utgående trafiken. Användardefinierade regler i de virtuella ekernätverken dirigerar internetbundna trafikbegäranden till brandväggen. Du kan också använda NAT-gatewayer på specifika undernät, azure-utgående standardkommunikation, offentliga IP-adresser på virtuella datorer (rekommenderas inte) eller en offentlig lastbalanserare med utgående regler. Vanliga scenarier når offentliga slutpunkter för Microsoft Entra-ID, Azure-hanterings-API:er på management.azure.com och tjänster för program från tredje part eller myndighetsprogram via utgående nätverksåtkomst.

På grund av ändringar i standardåtkomsten för utgående trafik i Azure kontrollerar du att en skalbar utgående åtkomst har definierats. För virtuella datorer som ligger bakom en intern standardlastbalanserare, som de i klustrade miljöer, bör du tänka på att Standard Load Balancer ändrar beteendet för offentlig anslutning. Mer information finns i Offentlig slutpunktsanslutning för virtuella datorer med Azure Standard Load Balancer i SAP-scenarier med hög tillgänglighet.

Mer information om utgående standardanslutningar från virtuella datorer finns i Routningsalternativ för virtuella datorer från privata undernät på Azure Networking-bloggen.

Uppdateringar av operativsystemet

Operativsystemuppdateringar finns ofta bakom en offentlig slutpunkt och nås via Internet. Om ingen företagslagringsplats och uppdateringshantering finns på plats, vilket speglar OS-uppdateringar från leverantörer på privata IP-adresser/virtuella datorer, måste SAP-arbetsbelastningen komma åt leverantörernas uppdateringsdatabaser.

För Linux-operativsystem kan du komma åt följande lagringsplatser om du hämtar OS-licensen från Azure. Om du köper licenser direkt och tar dem till Azure (BYOS) kontaktar du OS-leverantören om olika sätt att ansluta till OS-lagringsplatser och deras respektive IP-adressintervall.

Klusterhantering med hög tillgänglighet

System med hög tillgänglighet som klustrade SAP ASCS/SCS eller databaser kan använda en klusterhanterare med Azure Fence Agent som en STONITH-enhet. Dessa system är beroende av att nå Azure Resource Manager. Resource Manager används för statusfrågor om Azure-resurser och för åtgärder för att stoppa och starta virtuella datorer. Eftersom Resource Manager är en offentlig slutpunkt måste den utgående kommunikationen för den virtuella datorn kunna nås under management.azure.com. Den här arkitekturen förlitar sig på en central brandvägg med användardefinierade regler som dirigerar trafik från virtuella SAP-nätverk. Alternativ finns i föregående avsnitt.

Deltagare

Den här artikeln underhålls av Microsoft. Det har ursprungligen skrivits av följande medarbetare.

Huvudsakliga författare:

Annan deltagare:

Om du vill se icke-offentliga LinkedIn-profiler loggar du in på LinkedIn.

Communities

Överväg att använda dessa communities för att få svar på frågor och för hjälp med att konfigurera en distribution:

Nästa steg