Bewerken

Delen via

Binnenkomende en uitgaande internetverbinding voor SAP in Azure

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

Dit artikel bevat een aantal bewezen procedures voor het verbeteren van de beveiliging van binnenkomende en uitgaande internetverbinding voor uw SAP on Azure-infrastructuur.

Architectuur

Diagram met een oplossing voor internetgerichte communicatie voor SAP in Azure.

Download een Visio-bestand met de architecturen in dit artikel.

Deze oplossing illustreert een algemene productieomgeving. U kunt de grootte en het bereik van de configuratie aanpassen aan uw vereisten. Deze vermindering kan van toepassing zijn op het SAP-landschap: minder virtuele machines (VM's), geen hoge beschikbaarheid of ingesloten SAP Web Dispatchers in plaats van discrete VM's. Het kan ook van toepassing zijn op alternatieven voor het netwerkontwerp, zoals verderop in dit artikel wordt beschreven.

Klantvereisten, op basis van bedrijfsbeleid, vereisen aanpassingen aan de architectuur, met name aan het netwerkontwerp. Indien mogelijk hebben we alternatieven opgenomen. Veel oplossingen zijn haalbaar. Kies een benadering die geschikt is voor uw bedrijf. Het moet u helpen uw Azure-resources te beveiligen, maar nog steeds een goed presterende oplossing te bieden.

Herstel na noodgevallen (DR) wordt niet behandeld in deze architectuur. Voor het netwerkontwerp gelden dezelfde principes en hetzelfde ontwerp als voor primaire productieregio's. In uw netwerkontwerp kunt u, afhankelijk van de toepassingen die worden beveiligd door herstel na noodgeval, dr inschakelen in een andere Azure-regio. Zie het artikel Overzicht van herstel na noodgevallen en richtlijnen voor infrastructuur voor SAP-workload voor meer informatie

Workflow

  • Het on-premises netwerk maakt verbinding met een centrale hub via Azure ExpressRoute. Het virtuele hubnetwerk bevat een gatewaysubnet, een Azure Firewall-subnet, een subnet voor gedeelde services en een Azure-toepassing Gateway-subnet.
  • De hub maakt verbinding met een SAP-productieabonnement via peering voor virtuele netwerken. Dit abonnement bevat twee virtuele spoke-netwerken:
    • Het virtuele SAP-perimeternetwerk bevat een SAP-perimetertoepassingssubnet.
    • Het virtuele SAP-productienetwerk bevat een toepassingssubnet en een databasesubnet.
  • Het hubabonnement en het SAP-productieabonnement maken verbinding met internet via openbare IP-adressen.

Onderdelen

Abonnementen. Deze architectuur implementeert de benadering van de Azure-landingszone. Er wordt één Azure-abonnement gebruikt voor elke workload. Een of meer abonnementen worden gebruikt voor centrale IT-services die de netwerkhub en centrale gedeelde services bevatten, zoals firewalls of Active Directory en DNS. Er wordt een ander abonnement gebruikt voor de SAP-productieworkload. Gebruik de handleiding voor beslissingen in het Cloud Adoption Framework voor Azure om de beste abonnementsstrategie voor uw scenario te bepalen.

Virtuele netwerken. Azure Virtual Network verbindt Azure-resources met elkaar met verbeterde beveiliging. In deze architectuur maakt het virtuele netwerk verbinding met een on-premises omgeving via een ExpressRoute- of VPN-gateway (Virtual Private Network) die is geïmplementeerd in de hub van een stertopologie. Het SAP-productielandschap maakt gebruik van eigen virtuele spoke-netwerken. Twee afzonderlijke virtuele spoke-netwerken voeren verschillende taken uit en subnetten bieden netwerkscheiding.

Door scheiding in subnetten per workload kunt u eenvoudiger netwerkbeveiligingsgroepen (NSG's) gebruiken om beveiligingsregels in te stellen voor toepassings-VM's of Azure-services die worden geïmplementeerd.

Zone-redundante gateway. Een gateway verbindt afzonderlijke netwerken en breidt uw on-premises netwerk uit naar het virtuele Azure-netwerk. U wordt aangeraden ExpressRoute te gebruiken om privéverbindingen te maken die geen gebruik maken van het openbare internet. U kunt ook een site-naar-site-verbinding gebruiken. Gebruik zone-redundante Azure ExpressRoute- of VPN-gateways om te voorkomen dat er zonefouten optreden. Zie zone-redundante virtuele netwerkgateways voor een uitleg van de verschillen tussen een zonegebonden implementatie en een zone-redundante implementatie. Voor een zone-implementatie van de gateways moet u IP-adressen van standard-SKU's gebruiken.

NSG's. Als u netwerkverkeer van en naar het virtuele netwerk wilt beperken, maakt u NSG's en wijst u deze toe aan specifieke subnetten. Bied beveiliging voor afzonderlijke subnetten met behulp van workloadspecifieke NSG's.

Toepassingsbeveiligingsgroepen. Als u fijnmazige netwerkbeveiligingsbeleidsregels in uw NSG's wilt definiëren op basis van workloads die zijn gecentreerd op toepassingen, gebruikt u toepassingsbeveiligingsgroepen in plaats van expliciete IP-adressen. Met behulp van toepassingsbeveiligingsgroepen kunt u VM's groeperen op doel, bijvoorbeeld SAP SID. Toepassingsbeveiligingsgroepen helpen toepassingen te beveiligen door verkeer van vertrouwde segmenten van uw netwerk te filteren.

Privé-eindpunt. Veel Azure-services werken als openbare services, per ontwerp toegankelijk via internet. Als u privétoegang wilt toestaan via uw privénetwerkbereik, kunt u privé-eindpunten gebruiken voor sommige services. Privé-eindpunten zijn netwerkinterfaces in uw virtuele netwerk. Ze brengen de service effectief in uw privénetwerkruimte.

Azure-toepassing Gateway. Application Gateway is een load balancer voor webverkeer. Met de Web Application Firewall-functionaliteit is het de ideale service om webtoepassingen beschikbaar te maken op internet met verbeterde beveiliging. Application Gateway kan openbare (internet) of privéclients of beide gebruiken, afhankelijk van de configuratie.

In de architectuur staat Application Gateway, met behulp van een openbaar IP-adres, binnenkomende verbindingen met het SAP-landschap via HTTPS toe. De back-endpool is twee of meer SAP Web Dispatcher-VM's, die toegang hebben tot round robin en hoge beschikbaarheid bieden. De toepassingsgateway is een omgekeerde proxy en een load balancer voor webverkeer, maar vervangt de SAP Web Dispatcher niet. SAP Web Dispatcher biedt toepassingsintegratie met uw SAP-systemen en bevat functies die Application Gateway zelf niet biedt. Clientverificatie, wanneer deze de SAP-systemen bereikt, wordt uitgevoerd door de SAP-toepassingslaag systeemeigen of via eenmalige aanmelding. Wanneer u Azure DDoS-beveiliging inschakelt, kunt u overwegen om DDoS-netwerkbeveiligings-SKU te gebruiken, omdat u kortingen ziet voor Application Gateway Web Application Firewall.

Voor optimale prestaties schakelt u HTTP/2-ondersteuning in voor Application Gateway, SAP Web Dispatcher en SAP NetWeaver.

Azure Load Balancer. Azure Standard Load Balancer biedt netwerkelementen voor het ontwerp van hoge beschikbaarheid van uw SAP-systemen. Voor geclusterde systemen biedt Standard Load Balancer het virtuele IP-adres voor de clusterservice, zoals ASCS/SCS-exemplaren en databases die worden uitgevoerd op VM's. U kunt Standard Load Balancer ook gebruiken om het IP-adres op te geven voor de virtuele SAP-hostnaam van niet-geclusterde systemen wanneer secundaire IP-adressen op Azure-netwerkkaarten geen optie zijn. Het gebruik van Standard Load Balancer in plaats van Application Gateway om uitgaande internettoegang aan te pakken, wordt verderop in dit artikel besproken.

Netwerkontwerp

De architectuur maakt gebruik van twee afzonderlijke virtuele netwerken, beide spoke-virtuele netwerken die zijn gekoppeld aan het virtuele netwerk van de centrale hub. Er is geen spoke-to-spoke-peering. Er wordt een stertopologie gebruikt, waarin communicatie via de hub verloopt. De scheiding van netwerken helpt de toepassingen te beschermen tegen schendingen.

Een toepassingsspecifiek perimeternetwerk (ook wel dmZ genoemd) bevat de internetgerichte toepassingen, zoals SAProuter, SAP Cloud Connector, SAP Analytics Cloud Agent en andere. In het architectuurdiagram heeft het perimeternetwerk de naam SAP-perimeter - virtueel spoke-netwerk. Vanwege afhankelijkheden van SAP-systemen voert het SAP-team doorgaans de implementatie, configuratie en het beheer van deze services uit. Daarom bevinden deze SAP-perimeterservices zich vaak niet in een centraal hubabonnement en -netwerk. Vaak zijn organisatorische uitdagingen te wijten aan een dergelijke centrale hubplaatsplaatsing van workloadspecifieke toepassingen of services.

Dit zijn enkele voordelen van het gebruik van een afzonderlijk virtueel SAP-perimeternetwerk:

  • Snelle en onmiddellijke isolatie van gecompromitteerde services als er een inbreuk wordt gedetecteerd. Door peering van virtuele netwerken van de SAP-perimeter naar de hub te verwijderen, worden de SAP-perimeterworkloads en virtuele sap-toepassingsnetwerktoepassingen van internet onmiddellijk geïsoleerd. Het wijzigen of verwijderen van een NSG-regel die toegang toestaat, is alleen van invloed op nieuwe verbindingen en knipt bestaande verbindingen niet.
  • Strengere controles op het virtuele netwerk en subnet, met een strikte vergrendeling van communicatiepartners in en uit het SAP-perimeternetwerk en SAP-toepassingsnetwerken. U kunt uitgebreide controle uitbreiden naar geautoriseerde gebruikers en toegangsmethoden voor SAP-perimetertoepassingen, met verschillende back-ends voor autorisatie, bevoegde toegang of aanmeldingsreferenties voor SAP-perimetertoepassingen.

De nadelen zijn toegenomen complexiteit en extra peeringkosten voor virtuele netwerken voor internetgebonden SAP-verkeer (omdat communicatie tweemaal via peering van virtuele netwerken moet worden doorgegeven). De latentie van invloed op spoke-hub-spoke-peeringverkeer is afhankelijk van elke firewall die aanwezig is en moet worden gemeten.

Vereenvoudigde architectuur

Als u de aanbevelingen in dit artikel wilt aanpakken, maar de nadelen wilt beperken, kunt u een virtueel netwerk met één spoke gebruiken voor zowel de perimeter als de SAP-toepassingen. De volgende architectuur bevat alle subnetten in één virtueel SAP-productienetwerk. Het voordeel van onmiddellijke isolatie door beëindiging van peering van virtuele netwerken met de SAP-perimeter als deze niet beschikbaar is. In dit scenario zijn wijzigingen in NSG's alleen van invloed op nieuwe verbindingen.

Diagram met een vereenvoudigde architectuur voor internetgerichte communicatie voor SAP in Azure.

Download een Visio-bestand met de architecturen in dit artikel.

Voor implementaties die kleiner en kleiner zijn dan het bereik, is de vereenvoudigde architectuur mogelijk beter geschikt en voldoet deze nog steeds aan de principes van de complexere architectuur. Dit artikel verwijst, tenzij anders vermeld, naar de complexere architectuur.

De vereenvoudigde architectuur maakt gebruik van een NAT-gateway in het SAP-perimetersubnet. Deze gateway biedt uitgaande connectiviteit voor SAP Cloud Connector en SAP Analytics Cloud Agent en besturingssysteemupdates voor de geïmplementeerde VM's. Omdat SAProuter zowel binnenkomende als uitgaande verbindingen vereist, gaat het SAProuter-communicatiepad via de firewall in plaats van de NAT-gateway te gebruiken. De vereenvoudigde architectuur plaatst de Application Gateway ook met een eigen aangewezen subnet in het virtuele SAP-perimeternetwerk, als een alternatieve benadering voor het virtuele hubnetwerk.

Een NAT-gateway is een service die statische openbare IP-adressen biedt voor uitgaande connectiviteit. De NAT-gateway wordt toegewezen aan een subnet. Alle uitgaande communicatie maakt gebruik van de IP-adressen van de NAT-gateway voor internettoegang. Inkomende verbindingen maken geen gebruik van de NAT-gateway. Toepassingen zoals SAP Cloud Connector of updateservices voor VM-besturingssysteem die toegang hebben tot opslagplaatsen op internet, kunnen de NAT-gateway gebruiken in plaats van al het uitgaande verkeer via de centrale firewall te routeren. Vaak worden door de gebruiker gedefinieerde regels geïmplementeerd op alle subnetten om internetverkeer van alle virtuele netwerken via de centrale firewall af te dwingen.

Afhankelijk van uw vereisten kunt u de NAT-gateway mogelijk gebruiken als alternatief voor de centrale firewall voor uitgaande verbindingen. Hierdoor kunt u de belasting van de centrale firewall verminderen terwijl u communiceert met openbare eindpunten die door NSG zijn toegestaan. U krijgt ook uitgaand IP-beheer, omdat u doelfirewallregels kunt configureren op een ingestelde IP-lijst van de NAT-gateway. Voorbeelden hiervan zijn het bereiken van openbare Azure-eindpunten die worden gebruikt door openbare services, opslagplaatsen voor besturingssysteempatchs of interfaces van derden.

Voor een configuratie met hoge beschikbaarheid moet u er rekening mee houden dat de NAT-gateway alleen in één zone wordt geïmplementeerd en momenteel niet redundant is voor meerdere zones. Met één NAT-gateway is het niet ideaal voor SAP-implementaties die gebruikmaken van zone-redundante implementatie (cross-zone) voor virtuele machines.

Gebruik van netwerkonderdelen in een SAP-landschap

Een architectuurdocument geeft doorgaans slechts één SAP-systeem of landschap weer. Dit maakt ze gemakkelijker te begrijpen. Het resultaat is dat vaak het grotere geheel, hoe de architectuur past in een groter SAP-landschap dat verschillende systeemsporen en lagen bevat, niet wordt aangepakt.

Centrale netwerkservices, zoals de firewall, NAT-gateway en proxyservers als ze worden geïmplementeerd, worden het beste gebruikt in het hele SAP-landschap van alle lagen: productie, preproductie, ontwikkeling en sandbox. Afhankelijk van uw vereisten, de grootte van uw organisatie en bedrijfsbeleid, kunt u afzonderlijke implementaties per laag overwegen, of één productie- en één sandbox-/testomgeving.

Services die doorgaans een SAP-systeem bedienen, worden het beste gescheiden, zoals hier wordt beschreven:

  • Load balancers moeten worden toegewezen aan afzonderlijke services. Bedrijfsbeleid bepaalt naamgeving en groepering van resources. We raden één load balancer aan voor ASCS/SCS en ERS en een andere voor database, gescheiden voor elke SAP-SID. U kunt ook één load balancer gebruiken voor zowel (A)SCS-, ERS- als DB-clusters van één SAP-systeem. Deze configuratie helpt ervoor te zorgen dat probleemoplossing niet complex wordt, met veel front-end- en back-endpools en taakverdelingsregels allemaal op één load balancer. Eén load balancer per SAP SID zorgt er ook voor dat plaatsing in resourcegroepen overeenkomt met die van andere infrastructuuronderdelen.
  • Application Gateway, zoals een load balancer, staat meerdere back-ends, front-ends, HTTP-instellingen en regels toe. De beslissing om één toepassingsgateway te gebruiken voor meerdere toepassingen is hier gebruikelijker omdat niet alle SAP-systemen in de omgeving openbare toegang vereisen. Meerdere toepassingen in deze context omvatten verschillende webdispatcherpoorten voor dezelfde SAP S/4HANA-systemen of verschillende SAP-omgevingen. We raden ten minste één toepassingsgateway per laag aan (productie, niet-productie en sandbox), tenzij de complexiteit en het aantal verbonden systemen te hoog worden.
  • SAP-services, zoals SAProuter, Cloud Connector en Analytics Cloud Agent, worden geïmplementeerd op basis van toepassingsvereisten, hetzij centraal of gesplitst. Productie- en niet-productiescheiding is vaak gewenst.

Grootte en ontwerp van subnet

Wanneer u subnetten voor uw SAP-landschap ontwerpt, moet u de grootte en ontwerpprincipes volgen:

  • Voor verschillende PaaS-services (Platform as a Service) van Azure zijn hun eigen aangewezen subnetten vereist.
  • Application Gateway raadt een /24-subnet aan om te schalen. Als u ervoor kiest om de schaal van Application Gateway te beperken, kan een kleiner subnet worden gebruikt, minimaal /26 of groter. U kunt niet beide versies van Application Gateway (1 en 2) in hetzelfde subnet gebruiken.
  • Als u Azure NetApp Files gebruikt voor uw NFS-/SMB-shares of databaseopslag, is een aangewezen subnet vereist. Een /24-subnet is de standaardinstelling. Gebruik uw vereisten om de juiste grootte te bepalen.
  • Als u virtuele SAP-hostnamen gebruikt, hebt u meer adresruimte nodig in uw SAP-subnetten, inclusief de SAP-perimeter.
  • Centrale services, zoals Azure Bastion of Azure Firewall, die doorgaans worden beheerd door een centraal IT-team, vereisen hun eigen toegewezen subnetten van voldoende grootte.

Door speciale subnetten te gebruiken voor SAP-databases en -toepassingen, kunt u NSG's instellen op strenger, wat helpt om beide toepassingstypen te beveiligen met hun eigen set regels. U kunt vervolgens de databasetoegang tot SAP-toepassingen eenvoudiger beperken, zonder dat u gebruik hoeft te maken van toepassingsbeveiligingsgroepen voor gedetailleerd beheer. Door uw SAP-toepassings- en databasesubnetten te scheiden, is het ook eenvoudiger om uw beveiligingsregels in NSG's te beheren.

SAP-services

SAProuter

U kunt SAProuter gebruiken om derden, zoals SAP-ondersteuning of uw partners, toegang te geven tot uw SAP-systeem. SAProuter wordt uitgevoerd op één VM in Azure. Routemachtigingen voor het gebruik van SAProuter worden opgeslagen in een plat bestand met de naam saprouttab. De saprouttab-vermeldingen staan verbinding vanaf elke TCP/IP-poort toe naar een netwerkbestemming achter SAProuter, meestal uw SAP-systeem-VM's. Externe toegang door SAP-ondersteuning is afhankelijk van SAProuter. De hoofdarchitectuur maakt gebruik van het ontwerp dat eerder is beschreven, met een SAProuter-VM die wordt uitgevoerd binnen het aangewezen virtuele SAP-perimeternetwerk. Via peering van virtuele netwerken communiceert SAProuter vervolgens met uw SAP-servers die worden uitgevoerd in hun eigen virtuele spoke-netwerk en subnetten.

SAProuter is een tunnel naar SAP of uw partners. In deze architectuur wordt het gebruik van SAProuter met SNC beschreven om een versleutelde toepassingstunnel (netwerklaag 7) tot stand te brengen voor SAP/partners. Het gebruik van op IPSEC gebaseerde tunnel wordt momenteel niet behandeld in deze architectuur.

De volgende functies helpen het communicatiepad via internet te beveiligen:

  • Azure Firewall of een NVA van derden biedt het openbare IP-toegangspunt in uw Azure-netwerken. Firewallregels beperken de communicatie tot alleen geautoriseerde IP-adressen. Voor uw verbinding met SAP-ondersteuning , SAP note 48243 - De SAProuter-software integreren in een firewallomgeving documenteert de IP-adressen van SAP-routers.
  • Net als firewallregels staan netwerkbeveiligingsregels communicatie toe op de poort van SAProuter, meestal 3299 met de aangewezen bestemming.
  • U onderhoudt SAProuter-regels voor toestaan/weigeren in het saprouttab-bestand , waarbij u opgeeft wie contact kan opnemen met SAProuter en welk SAP-systeem toegankelijk is.
  • Er zijn verdere NSG-regels aanwezig op de respectieve subnetten in het SAP-productiesubnet dat de SAP-systemen bevat.

Zie SAProuter-configuratie met Azure Firewall voor stappen voor het configureren van SAProuter met Azure Firewall.

Beveiligingsoverwegingen voor SAProuter

Omdat SAProuter niet werkt in hetzelfde toepassingssubnet als uw SAP-systemen, kunnen aanmeldingsmechanismen voor het besturingssysteem afwijken. Afhankelijk van uw beleid kunt u een afzonderlijk aanmeldingsdomein of volledig hostgebruikersreferenties voor SAProuter gebruiken. Als er sprake is van een beveiligingsschending, is trapsgewijze toegang tot de interne SAP-systemen niet mogelijk vanwege de verschillende referentiebasis. Netwerkscheiding in een dergelijk geval, zoals eerder beschreven, kan verdere toegang loskoppelen van een gecomprouterde SAProuter in uw toepassingssubnetten. U kunt deze isolatie bereiken door de peering van het virtuele SAP-perimeternetwerk los te koppelen.

Overwegingen voor hoge beschikbaarheid van SAProuter

Omdat SAProuter een eenvoudig uitvoerbaar bestand is met een routemachtigingstabel op basis van bestanden, kan het eenvoudig worden gestart. De toepassing heeft geen ingebouwde hoge beschikbaarheid. Als er een VM- of toepassingsfout opgetreden is, moet de service worden gestart op een andere VIRTUELE machine. Het gebruik van een virtuele hostnaam voor de SAProuter-service is ideaal. De naam van de virtuele host is gebonden aan een IP,die is toegewezen als een secundair IP-adres dat is geconfigureerd met de NIC van de VIRTUELE machine of aan een interne load balancer die is verbonden met de VIRTUELE machine. Als in deze configuratie de SAProuter-service naar een andere VIRTUELE machine moet worden verplaatst, kan de IP-configuratie van de virtuele hostnaam van de service worden verwijderd. Vervolgens voegt u de naam van de virtuele host toe op een andere VIRTUELE machine zonder dat u de routetabellen of firewallconfiguratie hoeft te wijzigen. Ze zijn allemaal geconfigureerd voor het gebruik van het virtuele IP-adres. Zie Sap Virtual Host Names gebruiken met Linux in Azure voor meer informatie.

Trapsgewijze SAProuters

Als u trapsgewijze SAProuters wilt implementeren, kunt u zo veel als twee SAProuters definiëren voor SAP-ondersteuningsverbindingen. De eerste SAProuter, die wordt uitgevoerd in het subnet van de SAP-perimetertoepassing, biedt toegang vanaf de centrale firewall en van SAP of partner SAProuters. De enige toegestane bestemmingen zijn andere SAProuters, die worden uitgevoerd met specifieke workloads. Trapsgewijze SAProuters kunnen per laag, per regio of per SID-scheiding gebruiken, afhankelijk van uw architectuur. De tweede SAProuter accepteert alleen interne verbindingen van de eerste SAProuter en biedt toegang tot afzonderlijke SAP-systemen en VM's. Met dit ontwerp kunt u desgewenst toegang en beheer tussen verschillende teams scheiden. Zie SAProuter-configuratie met Azure Firewall voor een voorbeeld van een trapsgewijze SAProuters.

SAP Fiori en WebGui

SAP Fiori en andere HTTPS-front-ends voor SAP-toepassingen worden vaak gebruikt buiten het interne bedrijfsnetwerk. De noodzaak om op internet beschikbaar te zijn, vereist een oplossing met hoge beveiliging om de SAP-toepassing te beveiligen. Application Gateway met Web Application Firewall is hiervoor de ideale service.

Voor gebruikers en toepassingen die toegang hebben tot de openbare hostnaam van het openbare IP-adres dat is gekoppeld aan Application Gateway, wordt de HTTPS-sessie beëindigd op Application Gateway. Een back-endpool van twee of meer SAP Web Dispatcher-VM's krijgt round robin-sessies van de Application Gateway. Deze toepassingsgateway voor intern verkeer naar Web Dispatcher kan HTTP of HTTPS zijn, afhankelijk van de vereisten. Gebruik met HTTPS tussen Application Gateway en Web Dispatcher-VM's een certificaat en certificaatketen die bekend is bij het SAP-team, voor elke periodieke certificaatrotatie. De Web Application Firewall helpt de SAP Web Dispatcher te beschermen tegen aanvallen die via internet binnenkomen met de OWASP-kernregelset. SAP NetWeaver, vaak gekoppeld aan Microsoft Entra ID via eenmalige aanmelding (SSO), voert gebruikersverificatie uit. Zie Single sign-on Configuration met behulp van SAML en Microsoft Entra ID voor openbare en interne URL's voor de stappen die nodig zijn voor het configureren van eenmalige aanmelding voor Fiori met behulp van Application Gateway.

Houd er rekening mee dat u de SAP Web Dispatcher in elke situatie moet beveiligen, zelfs als deze alleen intern is geopend, toegankelijk is via Application Gateway via een openbaar IP-adres of toegankelijk is via een ander netwerk. Zie Beveiligingsinformatie voor SAP Web Dispatcher voor meer informatie.

Azure Firewall en Application Gateway

Al het webverkeer dat door Application Gateway wordt geleverd, is op HTTPS gebaseerd en versleuteld met het opgegeven TLS-certificaat. U kunt Azure Firewall gebruiken als toegangspunt voor het bedrijfsnetwerk, via het openbare IP-adres en vervolgens SAP Fiori-verkeer routeren van de firewall naar Application Gateway via een intern IP-adres. Zie Application Gateway na de firewall voor meer informatie. Omdat de TCP/IP-laag-7-versleuteling al is geïmplementeerd via TLS, is er beperkte voordelen voor het gebruik van een firewall in dit scenario en kunt u pakketinspectie niet uitvoeren. Fiori communiceert via hetzelfde externe IP-adres voor zowel inkomend als uitgaand verkeer, wat doorgaans niet vereist is voor SAP Fiori-implementaties.

Er zijn enkele voordelen van een tandem Application Gateway- en layer-4-firewallimplementatie:

  • Mogelijke integratie met het beheer van beveiligingsbeleid voor het hele bedrijf.
  • Netwerkverkeer dat in strijd is met beveiligingsregels , wordt al verwijderd, dus er is geen inspectie vereist.

Deze gecombineerde implementatie is een goede architectuur. De methode voor het verwerken van inkomend internetverkeer is afhankelijk van uw algemene bedrijfsarchitectuur. U moet ook overwegen hoe de algehele netwerkarchitectuur past bij toegangsmethoden van de interne IP-adresruimte, zoals on-premises clients. Deze overweging wordt behandeld in de volgende sectie.

Application Gateway voor interne IP-adressen (optioneel)

Deze architectuur richt zich op internetgerichte toepassingen. Er zijn verschillende opties beschikbaar voor clients die toegang hebben tot SAP Fiori, de webgebruikersinterface van een SAP NetWeaver-systeem of een andere SAP HTTPS-interface via een intern, privé-IP-adres. Eén scenario is het behandelen van alle toegang tot Fiori als openbare toegang, via het openbare IP-adres. Een andere optie is het gebruik van directe netwerktoegang via het privénetwerk naar de SAP Web Dispatchers, waardoor Application Gateway volledig wordt overgeslagen. Een derde optie is het gebruik van zowel privé- als openbare IP-adressen op Application Gateway, die toegang bieden tot zowel internet als het particuliere netwerk.

U kunt een vergelijkbare configuratie gebruiken met een privé-IP-adres in Application Gateway voor alleen-privénetwerktoegang tot het SAP-landschap. Het openbare IP-adres in dit geval wordt alleen gebruikt voor beheerdoeleinden en er is geen listener aan gekoppeld.

Als alternatief voor het gebruik van Application Gateway kunt u intern een load balancer gebruiken. U kunt een standaard interne load balancer gebruiken met Web Dispatcher-VM's die zijn geconfigureerd als round robin-back-end. In dit scenario wordt de standaard load balancer geplaatst met de webverzender-VM's in het subnet van de SAP-productietoepassing en biedt actieve/actieve taakverdeling tussen webverzender-VM's.

Voor internetgerichte implementaties raden we Application Gateway aan met Web Application Firewall in plaats van een load balancer met een openbaar IP-adres.

SAP Business Technology Platform (BTP)

SAP BTP is een grote set SAP-toepassingen, SaaS of PaaS, meestal toegankelijk via een openbaar eindpunt via internet. SAP Cloud Connector wordt vaak gebruikt om communicatie te bieden voor toepassingen die worden uitgevoerd in privénetwerken, zoals een SAP S/4HANA-systeem dat wordt uitgevoerd in Azure. SAP Cloud Connector wordt uitgevoerd als een toepassing in een VIRTUELE machine. Hiervoor is uitgaande internettoegang vereist om een MET TLS versleutelde HTTPS-tunnel met SAP BTP tot stand te brengen. Het fungeert als een omgekeerde aanroepproxy tussen het privé-IP-bereik in uw virtuele netwerk en SAP BTP-toepassingen. Vanwege deze ondersteuning voor reverse-aanroepen is er geen behoefte aan open firewallpoorten of andere toegang voor binnenkomende verbindingen, omdat de verbinding vanuit uw virtuele netwerk uitgaand is.

VM's hebben standaard toegang tot uitgaand internet in Azure. Het openbare IP-adres dat wordt gebruikt voor uitgaand verkeer, wanneer er geen toegewezen openbaar IP-adres is gekoppeld aan de virtuele machine, wordt willekeurig gekozen uit de groep openbare IP-adressen in de specifieke Azure-regio. Je kunt het niet regelen. Om ervoor te zorgen dat uitgaande verbindingen worden gemaakt via een beheerde en identificeerbare service en IP-adres, kunt u een van de volgende methoden gebruiken:

  • Een NAT-gateway die is gekoppeld aan het subnet of de load balancer en het bijbehorende openbare IP-adres.
  • HTTP-proxyservers die u gebruikt.
  • Een door de gebruiker gedefinieerde route waarmee het netwerkverkeer wordt gestroomd naar een netwerkapparaat, zoals een firewall.

Het architectuurdiagram toont het meest voorkomende scenario: internetverkeer routeren naar het virtuele hubnetwerk en via de centrale firewall. U moet verdere instellingen configureren in SAP Cloud Connector om verbinding te maken met uw SAP BTP-account.

Hoge beschikbaarheid voor SAP Cloud Connector

Hoge beschikbaarheid is ingebouwd in SAP Cloud Connector. Cloudconnector is geïnstalleerd op twee VM's. Het hoofdexemplaren zijn actief en het schaduwexemplaren zijn verbonden. Ze delen de configuratie en worden systeemeigen gesynchroniseerd. Als het hoofdexemplaren niet beschikbaar is, probeert de secundaire VM de hoofdrol over te nemen en de TLS-tunnel opnieuw tot stand te brengen naar SAP BTP. In de architectuur wordt een cloudconnectoromgeving met hoge beschikbaarheid weergegeven. Voor de configuratie hebt u geen andere Azure-technologieën nodig, zoals een load balancer of clustersoftware. Zie de SAP-documentatie voor meer informatie over configuratie en bewerking.

SAP Analytics Cloud Agent

Voor sommige toepassingsscenario's is SAP Analytics Cloud Agent een toepassing die in een VIRTUELE machine is geïnstalleerd. Het maakt gebruik van SAP Cloud Connector voor SAP BTP-connectiviteit. In deze architectuur wordt de SAP Analytics Cloud Agent-VM uitgevoerd in het subnet van de SAP-perimetertoepassing, naast de VM's van de SAP Cloud Connector. Zie de SAP-documentatie voor de verkeersstroom van privénetwerken zoals een virtueel Azure-netwerk naar SAP BTP via SAP Analytics Cloud Agent.

SAP biedt de Private Link-service voor SAP BTP. Hiermee kunt u privéverbindingen tussen geselecteerde SAP BTP-services en geselecteerde services in uw Azure-abonnement en virtueel netwerk inschakelen. Wanneer u de Private Link-service gebruikt, wordt de communicatie niet gerouteerd via het openbare internet. Het blijft op de wereldwijde netwerk-backbone van Azure met hoge beveiliging. Communicatie met Azure-services vindt plaats via een privéadresruimte. Verbeterde beveiliging tegen gegevensexfiltratie is ingebouwd wanneer u de Private Link-service gebruikt, omdat het privé-eindpunt de specifieke Azure-service toe wijst aan een IP-adres. Toegang is beperkt tot de toegewezen Azure-service.

Voor sommige SAP BTP-integratiescenario's heeft de Private Link-service de voorkeur. Voor anderen is SAP Cloud Connector beter. Zie Uitvoeren van cloudconnector en SAP Private Link naast elkaar voor informatie over het bepalen welke cloudconnector moet worden gebruikt.

SAP RISE/ECS

Als SAP uw SAP-systeem onder een SAP RISE/ECS-contract uitvoert, is SAP de partner van de beheerde service. De SAP-omgeving wordt geïmplementeerd door SAP. In de architectuur van SAP is de hier weergegeven architectuur niet van toepassing op uw systemen die worden uitgevoerd in RISE met SAP/ECS. Zie de Documentatie van Azure voor informatie over het integreren van dit type SAP-landschap met Azure-services en uw netwerk.

Andere SAP-communicatievereisten

Aanvullende overwegingen met betrekking tot internetcommunicatie kunnen van toepassing zijn op een SAP-landschap dat op Azure werkt. De verkeersstroom in deze architectuur maakt gebruik van een centrale Azure-firewall voor dit uitgaande verkeer. Door de gebruiker gedefinieerde regels in de virtuele spoke-netwerken routeren internetverkeersaanvragen naar de firewall. U kunt ook NAT-gateways gebruiken op specifieke subnetten, standaard uitgaande Azure-communicatie, openbare IP-adressen op VM's (niet aanbevolen) of een openbare load balancer met uitgaande regels. Typische scenario's bereiken openbare eindpunten van Microsoft Entra ID, Azure-beheer-API's op management.azure.com en services van toepassingen van derden of overheidstoepassingen via uitgaande netwerktoegang.

Vanwege wijzigingen in standaard uitgaande toegang in Azure, moet u ervoor zorgen dat er een schaalbare uitgaande toegang is gedefinieerd. Voor VM's die zich achter een standaard interne load balancer bevinden, zoals die in geclusterde omgevingen, moet u er rekening mee houden dat Standard Load Balancer het gedrag voor openbare connectiviteit wijzigt. Zie Openbare eindpuntconnectiviteit voor VM's met behulp van Azure Standard Load Balancer in scenario's met hoge beschikbaarheid van SAP voor meer informatie.

Zie Routeringsopties voor VM's van privésubnetten op de Azure-netwerkblog voor meer informatie over standaard uitgaande connectiviteit van VM's.

Updates van het besturingssysteem

Updates van besturingssystemen bevinden zich vaak achter een openbaar eindpunt en worden geopend via internet. Als er geen bedrijfsopslagplaats en updatebeheer aanwezig zijn, moet uw SAP-workload toegang hebben tot de updateopslagplaatsen van de leveranciers van de leveranciers.

Voor Linux-besturingssystemen hebt u toegang tot de volgende opslagplaatsen als u de besturingssysteemlicentie van Azure verkrijgt. Als u licenties rechtstreeks aanschaft en naar Azure (BYOS) brengt, neemt u contact op met de leverancier van het besturingssysteem over manieren om verbinding te maken met opslagplaatsen van het besturingssysteem en de bijbehorende IP-adresbereiken.

Clusterbeheer met hoge beschikbaarheid

Maximaal beschikbare systemen, zoals geclusterde SAP ASCS/SCS of databases, kunnen gebruikmaken van een clusterbeheerder met azure fence-agent als een STONITH-apparaat. Deze systemen zijn afhankelijk van het bereiken van Azure Resource Manager. Resource Manager wordt gebruikt voor statusquery's over Azure-resources en voor bewerkingen om VM's te stoppen en te starten. Omdat Resource Manager een openbaar eindpunt is, dat beschikbaar is onder management.azure.com, moet uitgaande communicatie van vm's het kunnen bereiken. Deze architectuur is afhankelijk van een centrale firewall met door de gebruiker gedefinieerde regels voor het routeren van verkeer van virtuele SAP-netwerken. Zie de voorgaande secties voor alternatieven.

Medewerkers

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

Belangrijkste auteurs:

Andere inzender:

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

Community's

Overweeg het gebruik van deze community's om antwoorden te krijgen op vragen en voor hulp bij het instellen van een implementatie:

Volgende stappen