Bearbeiten

Freigeben über

Eingehende und ausgehende Internetverbindungen für SAP in Azure

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

In diesem Artikel finden Sie eine Reihe bewährter Methoden zur Verbesserung der Sicherheit von ein- und ausgehenden Internetverbindungen für Ihre „SAP in Azure“-Infrastruktur.

Architektur

Diagramm, das eine Lösung für die Kommunikation mit Internetzugriff für SAP in Azure zeigt.

Laden Sie eine Visio-Datei mit den Architekturen in diesem Artikel herunter.

Diese Lösung veranschaulicht eine allgemeine Produktionsumgebung. Sie können die Größe und den Umfang der Konfiguration gemäß Ihren Anforderungen reduzieren. Diese Reduzierung kann sich auf die SAP-Landschaft beziehen: weniger virtuelle Computer (VMs), keine Hochverfügbarkeit oder eingebettete SAP Web Dispatcher anstelle von diskreten VMs. Sie kann auch für Alternativen zum Netzwerkentwurf gelten, wie später in diesem Artikel beschrieben.

Die Kundenanforderungen, die sich aus den Geschäftsrichtlinien ergeben, erfordern Anpassungen der Architektur, insbesondere des Netzwerkentwurfs. Wenn möglich, haben wir Alternativen einbezogen. Viele Lösungen sind geeignet. Wählen Sie einen Ansatz, der für Ihr Unternehmen geeignet ist. Er muss Ihnen helfen, Ihre Azure-Ressourcen zu sichern, aber dennoch eine leistungsstarke Lösung bieten.

Die Notfallwiederherstellung (Disaster Recovery, DR) wird in dieser Architektur nicht behandelt. Für den Netzwerkentwurf gelten die gleichen Prinzipien und das gleiche Design, das auch für die primären Produktionsregionen gilt. Abhängig von den Anwendungen, die durch die Notfallwiederherstellung geschützt werden sollen, sollten Sie beim Netzwerkentwurf die Aktivierung der Notfallwiederherstellung in einer anderen Azure-Region in Betracht ziehen. Weitere Informationen finden Sie im Artikel Übersicht über die Notfallwiederherstellung und Leitlinien für die Infrastruktur für SAP-Workloads.

Workflow

  • Das lokale Netzwerk ist über Azure ExpressRoute mit einem zentralen Hub verbunden. Das virtuelle Hubnetzwerk enthält ein Gatewaysubnetz, ein Azure Firewall-Subnetz, ein Subnetz für gemeinsame Dienste und ein Azure Application Gateway-Subnetz.
  • Der Hub stellt über das Peering virtueller Netzwerke eine Verbindung mit einem SAP-Produktionsabonnement her. Dieses Abonnement enthält zwei virtuelle Spoke-Netzwerke:
    • Das virtuelle SAP-Umkreisnetzwerk enthält ein SAP-Umkreisanwendungssubnetz.
    • Das virtuelle SAP-Produktionsnetzwerk enthält ein Anwendungssubnetz und ein Datenbanksubnetz.
  • Das Hubabonnement und das SAP-Produktionsabonnement stellen eine Verbindung mit dem Internet über öffentliche IP-Adressen her.

Komponenten

Abonnements. Diese Architektur implementiert den Azure-Ansatz Zielzone. Es wird ein Azure-Abonnement für jede Workload verwendet. Ein oder mehrere Abonnements werden für zentrale IT-Dienste verwendet, die den Netzwerkhub und zentrale, freigegebene Dienste wie Firewalls oder Active Directory und DNS enthalten. Ein weiteres Abonnement wird für die SAP-Produktionsworkload verwendet. Verwenden Sie den Entscheidungsleitfaden im Cloud Adoption Framework für Azure, um die beste Abonnementstrategie für Ihr Szenario zu ermitteln.

Virtuelle Netzwerke. Azure Virtual Network verbindet Azure-Ressourcen miteinander und bietet erweiterte Sicherheit. In dieser Architektur wird das virtuelle Netzwerk über ein ExpressRoute- oder VPN-Gateway, das im Hub einer Hub-Spoke-Topologie bereitgestellt wird, mit einer lokalen Umgebung verbunden. Die SAP-Produktionslandschaft verwendet ihre eigenen virtuellen Spoke-Netzwerke. Zwei unterschiedliche virtuelle Spoke-Netzwerke führen unterschiedliche Aufgaben aus, und Subnetze sorgen für die Netzwerktrennung.

Die Aufteilung in Subnetze nach Workload gestaltet es einfacher, Netzwerksicherheitsgruppen (NSGs) zu verwenden, um Sicherheitsregeln für Anwendungs-VMs oder Azure-Dienste festzulegen, die bereitgestellt werden.

Zonenredundantes Gateway: Mit einem Gateway werden einzelne Netzwerke verbunden, um Ihr lokales Netzwerk auf das virtuelle Azure-Netzwerk zu erweitern. Wir empfehlen, dass Sie ExpressRoute verwenden, um private Verbindungen zu erstellen, die nicht das öffentliche Internet verwenden. Sie können auch eine Site-to-Site-Verbindung verwenden. Verwenden Sie zonenredundante Azure ExpressRoute- oder VPN-Gateways, um vor Zonenfehlern zu schützen. Eine Erläuterung zu den Unterschieden zwischen einer zonenorientierten und zonenredundanten Bereitstellung finden Sie unter Zonenredundante Gateways für virtuelle Netzwerke. Für eine Zonenbereitstellung der Gateways müssen Sie IP-Adressen der Standard-SKU verwenden.

NSGs. Um den Datenverkehr zum und vom virtuellen Netzwerk einzuschränken, erstellen Sie NSGs (Netzwerksicherheitsgruppen) und weisen sie bestimmten Subnetzen zu. Bieten Sie Sicherheit für einzelne Subnetze mithilfe von workloadspezifischen Netzwerksicherheitsgruppen.

Anwendungssicherheitsgruppen: Verwenden Sie Anwendungssicherheitsgruppen anstelle von expliziten IP-Adressen, um detaillierte Netzwerksicherheitsrichtlinien in Ihren Netzwerksicherheitsgruppen basierend auf Workloads zu definieren, die auf Anwendungen ausgerichtet sind. Mithilfe von Anwendungssicherheitsgruppen können Sie VMs nach Zweck gruppieren, z. B. SAP SID. Anwendungssicherheitsgruppen helfen beim Schützen von Anwendungen, indem sie den Datenverkehr aus vertrauenswürdigen Segmenten Ihres Netzwerks filtern.

Privater Endpunkt. Viele Azure-Dienste werden als öffentliche Dienste betrieben, die standardmäßig über das Internet zugänglich sind. Um privaten Zugriff über Ihren privaten Netzwerkbereich zu ermöglichen, können Sie für einige Dienste private Endpunkte verwenden. Private Endpunkte sind Netzwerkschnittstellen in Ihrem virtuellen Netzwerk. Sie integrieren den Dienst effektiv in Ihren privaten Netzwerkbereich.

Azure Application Gateway. Application Gateway ist ein Lastenausgleich für Webdatenverkehr. Mit seiner Web Application Firewall-Funktionalität ist es der ideale Dienst, um Webanwendungen mit verbesserter Sicherheit für das Internet verfügbar zu machen. Application Gateway kann entweder öffentliche (Internet) oder private Clients oder beides versorgen, je nach Konfiguration.

In der Architektur ermöglicht Application Gateway mithilfe einer öffentlichen IP-Adresse eingehende Verbindungen mit der SAP-Landschaft über HTTPS. Sein Back-End-Pool besteht aus zwei oder mehr SAP Web Dispatcher-VMs, auf die im Roundrobin-Verfahren zugegriffen wird und die Hochverfügbarkeit bieten. Das Anwendungsgateway ist ein Reverseproxy und ein Lastenausgleich für den Webdatenverkehr, aber es ersetzt nicht den SAP Web Dispatcher. SAP Web Dispatcher bietet Anwendungsintegration mit Ihren SAP-Systemen und enthält Features, die Application Gateway allein nicht bietet. Die Clientauthentifizierung, wenn sie die SAP-Systeme erreicht, wird von der SAP-Ebene nativ oder über einmaliges Anmelden (Single Sign-On, SSO) durchgeführt. Wenn Sie den Azure DDoS-Schutz aktivieren, sollten Sie die DDoS-Netzwerkschutz-SKU verwenden, da dann Rabatte für Application Gateway Web Application Firewall gewährt werden.

Für eine optimale Leistung aktivieren Sie die HTTP/2-Unterstützung für Application Gateway, SAP Web Dispatcher und SAP NetWeaver.

Azure Load Balancer: Azure Load Balancer Standard bietet Netzwerkelemente für den Hochverfügbarkeitsentwurf Ihrer SAP-Systeme. Für gruppierte Systeme stellt Load Balancer Standard die virtuelle IP-Adresse für den Clusterdienst bereit, wie ASCS/SCS-Instanzen und Datenbanken, die auf virtuellen Computern ausgeführt werden. Sie können Load Balancer Standard auch verwenden, um die IP-Adresse für den virtuellen SAP-Hostnamen von nicht gruppierten Systemen bereitzustellen, wenn sekundäre IP-Adressen auf Azure-Netzwerkkarten keine Option sind. Die Verwendung von Load Balancer Standard anstelle von Application Gateway für den ausgehenden Zugriff auf das Internet wird später in diesem Artikel behandelt.

Netzwerkentwurf.

Die Architektur verwendet zwei diskrete virtuelle Netzwerke, beides virtuelle Spoke-Netzwerke, die mittels Peering mit dem zentralen virtuellen Hubnetzwerk verbunden werden. Es gibt kein Spoke-to-Spoke-Peering. Es wird eine Sterntopologie verwendet, bei der die Kommunikation über den Hub verläuft. Die Trennung der Netzwerke trägt dazu bei, die Anwendungen vor Sicherheitsverletzungen zu schützen.

Ein anwendungsspezifisches Umkreisnetzwerk (auch als DMZ bezeichnet) enthält die Anwendungen mit Internetzugriff, z. B. SAProuter, SAP Cloud Connector, SAP Analytics Cloud Agent und andere Anwendungen. Im Architekturdiagramm wird das Umkreisnetzwerk mit dem Namen SAP-Umkreis – virtuelles Spoke-Netzwerk bezeichnet. Aufgrund der Abhängigkeiten von SAP-Systemen übernimmt in der Regel das SAP-Team die Bereitstellung, Konfiguration und Verwaltung dieser Dienste. Aus diesem Grund befinden sich diese SAP-Dienste häufig nicht in einem zentralen Hubabonnement und Netzwerk. Häufig sind organisatorische Herausforderungen auf eine solche zentrale Hubplatzierung von workloadspezifischen Anwendungen oder Diensten zurückzuführen.

Dies sind einige der Vorteile der Verwendung eines separaten virtuellen SAP-Umkreisnetzwerks:

  • Schnelle und sofortige Isolation von kompromittierten Diensten, wenn eine Sicherheitsverletzung erkannt wird. Durch das Entfernen des Peerings virtueller Netzwerke vom SAP-Umkreis zum Hub werden die Workloads des SAP-Umkreises und die Anwendungen des virtuellen SAP-Anwendungsnetzwerks sofort vom Internet isoliert. Das Ändern oder Entfernen einer NSG-Regel, die den Zugriff erlaubt, wirkt sich nur auf neue Verbindungen aus und unterbricht nicht die bestehenden Verbindungen.
  • Strengere Kontrollen des virtuellen Netzwerks und Subnetzes, mit einem festen Sperrmodus für Kommunikationspartner in und aus dem SAP-Umkreisnetzwerk und den SAP-Anwendungen. Sie können die verstärkte Kontrolle auf autorisierte Benutzer und Zugriffsmethoden auf SAP-Umkreisanwendungen ausweiten, mit verschiedenen Autorisierungs-Back-Ends, privilegiertem Zugriff oder Anmeldeinformationen für SAP-Umkreisanwendungen.

Die Nachteile sind eine höhere Komplexität und zusätzliche Kosten für das Peering virtueller Netzwerke für den internetgestützten SAP-Datenverkehr (da die Kommunikation zweimal virtuelle Netzwerke durchlaufen muss). Die Auswirkung der Wartezeit auf den Spoke-Hub-Spoke-Datenverkehr für Peering hängt von der Firewall ab und muss gemessen werden.

Vereinfachte Architektur

Um die Empfehlungen in diesem Artikel zu behandeln, aber die Nachteile zu begrenzen, können Sie ein einzelnes virtuelles Spoke-Netzwerk sowohl für den Umkreis als auch für die SAP-Anwendungen verwenden. Die folgende Architektur enthält alle Subnetze in einem einzelnen virtuellen SAP-Produktionsnetzwerk. Der Vorteil einer sofortigen Isolation durch Beendigung des Peerings virtueller Netzwerke zum SAP-Umkreis, wenn dieser kompromittiert wird, ist nicht verfügbar. In diesem Szenario wirken sich Änderungen an Netzwerksicherheitsgruppen nur auf neue Verbindungen aus.

Diagramm, das eine vereinfachte Architektur für die Kommunikation mit Internetzugriff für SAP in Azure zeigt.

Laden Sie eine Visio-Datei mit den Architekturen in diesem Artikel herunter.

Für Bereitstellungen, die kleiner sind und einen geringeren Umfang haben, ist die vereinfachte Architektur möglicherweise besser geeignet, da sie die Prinzipien der komplexeren Architektur beibehält. Dieser Artikel bezieht sich, sofern nicht anders angegeben, auf die komplexere Architektur.

Die vereinfachte Architektur verwendet ein NAT-Gateway im SAP-Umkreissubnetz. Dieses Gateway bietet ausgehende Konnektivität für SAP Cloud Connector und SAP Analytics Cloud Agent sowie Betriebssystemupdates für die bereitgestellten virtuellen Computer. Da SAProuter sowohl ein- als auch ausgehende Verbindungen erfordert, verläuft der Kommunikationspfad von SAProuter durch die Firewall, anstatt das NAT-Gateway zu verwenden. Die vereinfachte Architektur platziert auch das Application Gateway mit einem eigenen Subnetz im virtuellen SAP-Perimeternetzwerk, als alternativen Ansatz zum virtuellen Hub-Netzwerk.

Ein NAT-Gateway ist ein Dienst, der statische öffentliche IP-Adressen für ausgehende Konnektivität bereitstellt. Das NAT-Gateway wird einem Subnetz zugewiesen. Die gesamte ausgehende Kommunikation verwendet die IP-Adressen des NAT-Gateways für den Zugriff auf das Internet. Eingehende Verbindungen verwenden das NAT-Gateway nicht. Anwendungen wie SAP Cloud Connector oder VM-Dienste für Betriebssystemupdates, die auf Repositorys im Internet zugreifen, können das NAT-Gateway verwenden, anstatt den gesamten ausgehenden Datenverkehr über die zentrale Firewall zu leiten. Häufig werden in allen Subnetzen benutzerdefinierte Regeln implementiert, um den internetgebundenen Datenverkehr aus allen virtuellen Netzwerken durch die zentrale Firewall zu leiten.

Je nach Ihren Anforderungen können Sie das NAT-Gateway als Alternative zur zentralen Firewall für ausgehende Verbindungen verwenden. Dadurch können Sie die Last der zentralen Firewall verringern, während Sie mit öffentlichen Endpunkten kommunizieren, für die Netzwerksicherheitsgruppen zulässig sind. Sie erhalten auch die Kontrolle über die ausgehende IP-Adresse, denn Sie können die Firewallregeln für das Ziel auf einer festgelegten IP-Liste des NAT-Gateways konfigurieren. Beispiele sind das Erreichen öffentlicher Azure-Endpunkte, die mithilfe von öffentlichen Diensten, Betriebssystempatch-Repositorys oder Schnittstellen von Drittanbietern verwendet werden.

Beachten Sie bei einer Konfiguration mit hoher Verfügbarkeit, dass das NAT-Gateway nur in einer einzelnen Zone bereitgestellt wird und derzeit nicht zonenübergreifend redundant ist. Bei einem einzelnen NAT-Gateway ist es nicht ideal für SAP-Bereitstellungen, die zonenredundante (zonenübergreifende) Bereitstellung für virtuelle Computer verwenden.

Verwenden von Netzwerkkomponenten in einer SAP-Landschaft

Ein Architekturdokument stellt in der Regel nur ein SAP-System oder eine SAP-Landschaft dar. Dadurch sind sie leichter zu verstehen. Das Ergebnis ist, dass das Gesamtbild, d. h. wie sich die Architektur in eine größere SAP-Landschaft einfügt, die mehrere Systempfade und -ebenen umfasst, häufig nicht berücksichtigt wird.

Zentrale Netzwerkdienste, wie Firewall, NAT-Gateway und Proxyserver, falls sie bereitgestellt werden, werden am besten in der gesamten SAP-Landschaft aller Ebenen verwendet: Produktion, Vorproduktion, Entwicklung und Sandbox. Je nach Ihren Anforderungen, der Größe und den Richtlinien Ihres Unternehmens möchten Sie vielleicht getrennte Implementierungen pro Ebene oder eine Produktions- und eine Sandbox-/Testumgebung in Betracht ziehen.

Dienste, die typischerweise ein SAP-System versorgen, werden am besten wie hier beschrieben getrennt:

  • Lastenausgleiche sollten einzelnen Diensten vorbehalten sein. Die Unternehmensrichtlinie schreibt die Benennung und Gruppierung von Ressourcen vor. Wir empfehlen einen Lastenausgleich für ASCS/SCS und ERS und einen weiteren für die Datenbank, getrennt für jede SAP SID. Alternativ dazu eignet sich auch ein einzelner Lastenausgleich für (A)SCS-, ERS- und DB-Cluster eines einzigen SAP-Systems. Diese Konfiguration trägt dazu bei, dass die Problembehandlung mit vielen Front-End- und Back-End-Pools und Lastenausgleichsregeln, die alle auf einem einzigen Lastenausgleich basieren, nicht zu komplex wird. Ein einzelner Lastenausgleich pro SAP SID stellt außerdem sicher, dass die Platzierung in Ressourcengruppen mit der anderer Infrastrukturkomponenten übereinstimmt.
  • Application Gateway ermöglicht wie ein Lastenausgleich mehrere Back-Ends, Front-Ends, HTTP-Einstellungen und Regeln. Die Entscheidung, ein Anwendungsgateway für mehrere Verwendungszwecke einzusetzen, ist hier üblicher, da nicht alle SAP-Systeme in der Umgebung einen öffentlichen Zugriff erfordern. Mehrere Verwendungsmöglichkeiten in diesem Zusammenhang sind z. B. verschiedene Web Dispatcher-Ports für gleiche SAP S/4HANA-Systeme oder verschiedene SAP-Umgebungen. Wir empfehlen mindestens ein Anwendungsgateway pro Ebene (Produktion, Nichtproduktion und Sandbox), es sei denn, die Komplexität und Anzahl der vernetzten Systeme wird zu hoch.
  • SAP-Dienste wie SAProuter, Cloud Connector und Analytics Cloud Agent werden je nach Anwendungsanforderungen entweder zentral oder getrennt bereitgestellt. Die Trennung von Produktion und Nichtproduktion ist häufig gewünscht.

Subnetzdimensionierung und -entwurf

Wenn Sie Subnetze für Ihre SAP-Landschaft entwerfen, sollten Sie die Dimensionierungs- und Entwurfsprinzipien beachten:

  • Mehrere PaaS-Dienste (Platform as a Service) von Azure benötigen ihre eigenen designierten Subnetze.
  • Application Gateway empfiehlt ein /24-Subnetz für die Skalierung. Wenn Sie den Application Gateway-Umfang begrenzen, kann ein kleineres Subnetz mit mindestens /26 oder höher verwendet werden. Sie können nicht beide Versionen von Application Gateway (1 und 2) in demselben Subnetz verwenden.
  • Wenn Sie Azure NetApp Files für Ihre NFS/SMB-Freigaben oder Ihren Datenbankspeicher verwenden, ist ein bestimmtes Subnetz erforderlich. Ein /24-Subnetz ist die Standardeinstellung. Verwenden Sie Ihre Anforderungen, um die richtige Dimensionierung zu ermitteln.
  • Wenn Sie virtuelle SAP-Hostnamen verwenden, benötigen Sie einen größeren Adressraum in Ihren SAP-Subnetzen, einschließlich des SAP-Umkreises.
  • Zentrale Dienste wie Azure Bastion oder Azure Firewall, die in der Regel von einem zentralen IT-Team verwaltet werden, benötigen ihre eigenen dedizierten Subnetze von ausreichender Größe.

Mithilfe dedizierter Subnetze für SAP-Datenbanken und -Anwendungen können Sie Netzwerksicherheitsgruppen strikter festlegen, was dazu beiträgt, beide Anwendungstypen mit ihren eigenen Regelsätzen zu schützen. Sie können dann den Datenbankzugriff auf SAP-Anwendungen einfacher einschränken, ohne für eine differenzierte Kontrolle auf Anwendungssicherheitsgruppen zurückgreifen zu müssen. Die Trennung von SAP-Anwendungen und Datenbanksubnetzen erleichtert auch die Verwaltung Ihrer Sicherheitsregeln in Netzwerksicherheitsgruppen.

SAP-Dienste

SAProuter

Sie können SAProuter verwenden, um Drittanbieter wie den SAP-Support oder Ihre Partner in die Lage zu versetzen, auf Ihr SAP-System zuzugreifen. SAProuter wird auf einer VM in Azure ausgeführt. Die Routenberechtigungen für die Verwendung von SAProuter werden in einer Flatfile namens saprouttab gespeichert. Die saprouttab-Einträge ermöglichen eine Verbindung von einem beliebigen TCP/IP-Port zu einem Netzwerkziel hinter SAProuter, in der Regel Ihre SAP-System-VMs. Der Remotezugriff durch den SAP-Support basiert auf SAProuter. Die Hauptarchitektur verwendet das bereits beschriebene Design, bei dem eine SAProuter-VM innerhalb des vorgesehenen virtuellen SAP-Umkreisnetzwerks ausgeführt wird. Über das Peering virtueller Netzwerke kommuniziert SAProuter dann mit Ihren SAP-Servern, die in ihrem eigenen virtuellen Spoke-Netzwerk und den Subnetzen ausgeführt werden.

SAProuter ist ein Tunnel zu SAP oder zu Ihren Partnern. Diese Architektur beschreibt die Verwendung von SAProuter mit SNC, um einen verschlüsselten Anwendungstunnel (Netzwerkschicht 7) für SAP/Partner einzurichten. Die Verwendung des IPSEC-basierten Tunnels wird in dieser Architektur derzeit nicht behandelt.

Die folgenden Features schützen den Kommunikationspfad über das Internet:

  • Azure Firewall oder eine NVA eines Drittanbieters bietet den öffentlichen IP-Einstiegspunkt in Ihre Azure-Netzwerke. Firewallregeln grenzen die Kommunikation auf autorisierte IP-Adressen ein. Für Ihre Verbindung mit dem SAP-Support dokumentiert der SAP-Hinweis 48243 – Integrieren der SAProuter-Software in eine Firewallumgebung die IP-Adressen der SAP-Router.
  • Wie Firewallregeln erlauben auch Netzwerksicherheitsregeln die Kommunikation am SAProuter-Port, normalerweise 3299, mit dem angegebenen Ziel.
  • In der Datei saprouttab verwalten Sie SAProuter-Zulassungs-/Verweigerungsregeln, die festlegen, wer SAProuter kontaktieren kann und auf welches SAP-System der Zugriff gestattet ist.
  • Weitere NSG-Regeln gelten für die jeweiligen Subnetze im SAP-Produktionssubnetz, das die SAP-Systeme enthält.

Schritte zur Konfiguration von SAProuter mit Azure Firewall finden Sie unter SAProuter-Konfiguration mit Azure Firewall.

Überlegungen zur Sicherheit von SAProuter

Da SAProuter nicht in demselben Anwendungssubnetz wie Ihre SAP-Systeme betrieben wird, können die Anmeldemechanismen für das Betriebssystem unterschiedlich sein. Je nach Ihren Richtlinien können Sie eine separate Domäne für die Anmeldung oder Anmeldeinformationen für SAProuter verwenden, die nur für den Host gelten. Im Falle einer Sicherheitsverletzung ist ein kaskadierender Zugriff auf die internen SAP-Systeme aufgrund der unterschiedlichen Anmeldeinformationen nicht möglich. Die bereits beschriebene Trennung des Netzwerks in einem solchen Fall kann den weiteren Zugriff von einem kompromittierten SAProuter auf die Anwendungssubnetze entkoppeln. Sie können diese Isolation erreichen, indem Sie das Peering virtueller Netzwerke des SAP-Umkreisnetzwerks trennen.

Überlegungen zu Hochverfügbarkeit von SAProuter

Da SAProuter eine einfache ausführbare Datei mit einer dateibasierten Routenberechtigungstabelle ist, lässt es sich leicht starten. Die Anwendung weist keine integrierte Hochverfügbarkeit auf. Wenn ein VM- oder Anwendungsfehler auftritt, muss der Dienst auf einem anderen virtuellen Computer gestartet werden. Die Verwendung eines virtuellen Hostnamens für den SAProuter-Dienst ist ideal. Der virtuelle Hostname ist an eine IP-Adresse gebunden, die als sekundäre IP-Konfiguration mit der NIC der VM oder einem internen Lastenausgleich zugewiesen wird, der mit der VM verbunden ist. In dieser Konfiguration kann die IP-Konfiguration des virtuellen Hostnamens des Diensts entfernt werden, wenn der SAProuter-Dienst auf eine andere VM verschoben werden muss. Sie fügen dann den virtuellen Hostnamen auf einer anderen VM hinzu, ohne die Routingtabellen oder die Firewallkonfiguration ändern zu müssen. Sie sind alle so konfiguriert, dass sie die virtuelle IP-Adresse verwenden. Weitere Informationen finden Sie unter Verwenden von virtuellen SAP-Hostnamen mit Linux in Azure.

Kaskadierende SAProuter

Um kaskadierende SAProuter zu implementieren, können Sie bis zu zwei SAProuter für SAP-Supportverbindungen definieren. Der erste SAProuter, der im Subnetz der SAP-Umkreisanwendung ausgeführt wird, ermöglicht den Zugriff von der zentralen Firewall und von SAP- oder Partner-SAProuter-Instanzen. Die einzigen zulässigen Ziele sind andere SAProuter, die mit bestimmten Workloads ausgeführt werden. Kaskadierende SAProuter können je nach Ihrer Architektur eine Trennung pro Ebene, pro Region oder pro SID verwenden. Der zweite SAProuter akzeptiert nur interne Verbindungen vom ersten SAProuter und bietet Zugriff auf einzelne SAP-Systeme und VMs. So können Sie bei Bedarf den Zugriff und die Verwaltung zwischen verschiedenen Teams aufteilen. Ein Beispiel für kaskadierende SAProuter finden Sie unter SAProuter-Konfiguration mit Azure Firewall.

SAP Fiori und WebGui

SAP Fiori und andere HTTPS-Front-Ends für SAP-Anwendungen werden oft von außerhalb des internen Unternehmensnetzwerks genutzt. Die Notwendigkeit, im Internet verfügbar zu sein, erfordert eine Hochsicherheitslösung, um die SAP Anwendung zu schützen. Application Gateway mit Web Application Firewall ist der ideale Dienst für diesen Zweck.

Für Benutzer und Anwendungen, die auf den öffentlichen Hostnamen der öffentlichen IP zugreifen, die an das Anwendungsgateway gebunden ist, wird die HTTPS-Sitzung auf dem Anwendungsgateway beendet. Ein Back-End-Pool mit zwei oder mehr SAP Web Dispatcher-VMs erhält Roundrobin-Sitzungen von der Application Gateway-Instanz. Dieses Anwendungsgateway für den internen Datenverkehr zu Web Dispatcher kann je nach Bedarf entweder HTTP oder HTTPS verwenden. Verwenden Sie mit HTTPS zwischen Anwendungsgateway und Web Dispatcher-VMs eine Zertifikat- und Zertifikatkette, die dem SAP-Team bekannt ist, für jede regelmäßige Zertifikatdrehung. Die Web Application Firewall hilft, den SAP Web Dispatcher vor Angriffen aus dem Internet mit dem OWASP-Kernregelsatz zu schützen. SAP NetWeaver, das häufig über einmaliges Anmelden (Single Sign-On, SSO) mit Microsoft Entra ID verbunden ist, übernimmt die Authentifizierung der Benutzer. Die erforderlichen Schritte zur Konfiguration von SSO für Fiori mithilfe von Application Gateway finden Sie unter Konfiguration des einmaligen Anmeldens mithilfe von SAML und Microsoft Entra ID für öffentliche und interne URLs.

Denken Sie daran, dass Sie den SAP Web Dispatcher in jeder Situation schützen müssen, auch wenn er nur intern geöffnet ist, über das Anwendungsgateway über öffentliche IP oder über andere Netzwerkmittel zugänglich ist. Weitere Informationen finden Sie unter Sicherheitsinformationen für SAP Web Dispatcher.

Azure Firewall und Application Gateway

Der gesamte von Application Gateway bereitgestellte Datenverkehr ist HTTPS-basiert und mit dem bereitgestellten TLS-Zertifikat verschlüsselt. Sie können Azure Firewall über die öffentliche IP-Adresse als Einstiegspunkt in das Unternehmensnetzwerk verwenden und dann den SAP Fiori-Datenverkehr von der Firewall über eine interne IP-Adresse zum Application Gateway leiten. Weitere Informationen finden Sie unter Application Gateway hinter Firewall. Da die Verschlüsselung auf TCP/IP-Ebene-7 bereits über TLS erfolgt, ist der Nutzen einer Firewall in diesem Szenario begrenzt, und Sie können keine Paketprüfung durchführen. Fiori kommuniziert über dieselbe externe IP-Adresse für den ein- und ausgehenden Datenverkehr, was bei SAP Fiori-Bereitstellungen normalerweise nicht erforderlich ist.

Die kombinierte Bereitstellung von Application Gateway und einer Ebene-4-Firewall bietet einige Vorteile:

  • Mögliche Integration in die unternehmensweite Verwaltung von Sicherheitsrichtlinien.
  • Netzwerkdatenverkehr, der gegen Sicherheitsregeln verstößt, wird bereits verworfen, sodass er keine Überprüfung erfordert.

Diese kombinierte Bereitstellung ist eine gute Architektur. Die Methode für die Behandlung des eingehenden Internetdatenverkehrs hängt von Ihrer gesamten Unternehmensarchitektur ab. Sie müssen auch berücksichtigen, wie die gesamte Netzwerkarchitektur mit Zugriffsmethoden aus dem internen IP-Adressraum zusammenpasst, z. B. mit lokalen Clients. Diese Überlegung wird im nächsten Abschnitt behandelt.

Application Gateway für interne IP-Adressen (optional)

Diese Architektur konzentriert sich auf Anwendungen mit Internetzugriff. Für Clients, die über eine interne, private IP-Adresse auf SAP Fiori, die Web-UI eines SAP NetWeaver-Systems oder eine andere SAP HTTPS-Schnittstelle zugreifen, stehen verschiedene Optionen zur Verfügung. Ein Szenario ist die Behandlung aller Zugriffe auf Fiori als öffentlichen Zugriff über die öffentliche IP-Adresse. Eine andere Möglichkeit besteht darin, einen direkten Netzwerkzugriff über das private Netzwerk auf SAP Web Dispatcher zu verwenden und dabei Application Gateway vollständig zu umgehen. Eine dritte Möglichkeit besteht darin, sowohl private als auch öffentliche IP-Adressen für Application Gateways zu verwenden, die den Zugriff sowohl auf das Internet als auch auf das private Netzwerk ermöglichen.

Sie können eine ähnliche Konfiguration mit einer privaten IP-Adresse für Application Gateway für einen rein privaten Netzwerkzugriff auf die SAP-Landschaft verwenden. Die öffentliche IP-Adresse wird in diesem Fall nur zu Verwaltungszwecken verwendet und ist keinem Listener zugeordnet.

Alternativ zur Verwendung von Application Gateway können Sie intern einen Lastenausgleich verwenden. Sie können einen standardmäßigen internen Lastenausgleich mit Web Dispatcher-VMs verwenden, die als Roundrobin-Back-End konfiguriert sind. In diesem Szenario wird der Load Balancer Standard mit den Web Dispatcher-VMs im Subnetz der SAP-Produktionsanwendung platziert und sorgt für einen aktiven/aktiven Lastenausgleich zwischen den Web Dispatcher-VMs.

Für die Bereitstellung im Internet empfehlen wir ein Application Gateway mit Web Application Firewall anstelle eines Lastenausgleichs mit einer öffentlichen IP-Adresse.

SAP Business Technology Platform (BTP)

SAP BTP umfasst eine Vielzahl von SAP-Anwendungen, SaaS oder PaaS (Software-as-a-Service oder Platform as a Service), auf die in der Regel über einen öffentlichen Endpunkt über das Internet zugegriffen wird. SAP Cloud Connector wird häufig verwendet, um die Kommunikation für Anwendungen bereitzustellen, die in privaten Netzwerken ausgeführt werden, wie ein SAP S/4HANA-System, das in Azure ausgeführt wird. SAP Cloud Connector wird als Anwendung in einer VM ausgeführt. Es erfordert einen ausgehenden Zugriff auf das Internet, um einen TLS-verschlüsselten HTTPS-Tunnel mit SAP BTP aufzubauen. Er fungiert als Reverse-Invoke-Proxy zwischen dem privaten IP-Bereich in Ihrem virtuellen Netzwerk und SAP BTP-Anwendungen. Dank dieser Reverse-Invoke-Unterstützung sind keine offenen Firewallports oder andere Zugriffe für eingehende Verbindungen erforderlich, da die Verbindung von Ihrem virtuellen Netzwerk ausgehend ist.

Standardmäßig verfügen virtuelle Computer über nativen ausgehenden Internetzugriff in Azure. Die öffentliche IP-Adresse, die für den ausgehenden Datenverkehr verwendet wird, wenn dem virtuellen Computer keine eigene öffentliche IP-Adresse zugeordnet ist, wird nach dem Zufallsprinzip aus dem Pool der öffentlichen IP-Adressen in der jeweiligen Azure-Region ausgewählt. Sie können es nicht steuern. Um sicherzustellen, dass ausgehende Verbindungen über einen kontrollierten und identifizierbaren Dienst und eine IP-Adresse hergestellt werden, können Sie eine der folgenden Methoden verwenden:

  • Ein NAT-Gateway, das dem Subnetz oder Lastenausgleich und seiner öffentlichen IP-Adresse zugeordnet ist.
  • HTTP-Proxyserver, die Sie betreiben.
  • Eine benutzerdefinierte Route, die den Netzwerkdatenverkehr zu einem Netzwerkgerät wie einer Firewall leitet.

Das Architekturdiagramm zeigt das häufigste Szenario: Routing des internetgebundenen Datenverkehrs zum virtuellen Hubnetzwerk und durch die zentrale Firewall. Sie müssen weitere Einstellungen in SAP Cloud Connector festlegen, um eine Verbindung mit Ihrem SAP BTP-Konto herzustellen.

Hochverfügbarkeit für SAP Cloud Connector

Hochverfügbarkeit ist in SAP Cloud Connector integriert. Cloud Connector wird auf zwei virtuellen Computern installiert. Die Hauptinstanz ist aktiv und die Schatteninstanz ist mit ihr verbunden. Sie teilen die Konfiguration und werden nativ synchron gehalten. Wenn die Hauptinstanz nicht verfügbar ist, versucht die sekundäre VM, die Hauptrolle zu übernehmen und den TLS-Tunnel zu SAP BTP wiederherzustellen. Eine Cloud Connector-Umgebung mit Hochverfügbarkeit wird in der Architektur angezeigt. Für die Konfiguration benötigen Sie keine weiteren Azure-Technologien wie Lastenausgleich oder Clustersoftware. Ausführliche Informationen zu Konfiguration und Betrieb finden Sie in der SAP-Dokumentation.

SAP Analytics Cloud Agent

Für einige Anwendungsszenarien ist der SAP Analytics Cloud Agent eine Anwendung, die in einer VM installiert wird. Er verwendet den SAP Cloud Connector für die SAP BTP-Konnektivität. In dieser Architektur wird die SAP Analytics Cloud Agent-VM im Subnetz der SAP-Umkreisanwendung neben den SAP Cloud Connector-VMs ausgeführt. Informationen zum Datenverkehr von privaten Netzwerken wie einem virtuellen Azure-Netzwerk zu SAP BTP über SAP Analytics Cloud Agent finden Sie in der SAP-Dokumentation.

SAP bietet den Private Link-Dienst für SAP BTP. Er ermöglicht private Verbindungen zwischen ausgewählten SAP BTP-Diensten und ausgewählten Diensten in Ihrem Azure-Abonnement und virtuellen Netzwerk. Wenn Sie einen Private Link-Dienst verwenden, wird die Kommunikation nicht über das öffentliche Internet weitergeleitet. Sie bleibt auf dem hochsicheren globalen Netzwerk-Backbone von Azure. Die Kommunikation mit Azure-Diensten erfolgt über einen privaten Adressraum. Ein verbesserter Schutz vor Datenexfiltration ist integriert, wenn Sie den Private Link-Dienst verwenden, da der private Endpunkt den spezifischen Azure-Dienst einer IP-Adresse zuordnet. Der Zugriff ist auf den zugeordneten Azure-Dienst beschränkt.

Für einige SAP BTP-Integrationsszenarien ist der Private Link-Dienst der bessere Ansatz. Für andere ist SAP Cloud Connector besser geeignet. Informationen, die Ihnen bei der Entscheidung hinsichtlich der zu verwendenden Option helfen, finden Sie unter Paralleles Ausführen von Cloud Connector und SAP Private Link.

SAP RISE/ECS

Wenn SAP Ihr SAP-System im Rahmen eines SAP RISE/ECS-Vertrags betreibt, ist SAP der Partner für verwaltete Dienste. Die SAP-Umgebung wird von SAP bereitgestellt. Die hier gezeigte Architektur der SAP-Architektur gilt nicht für Ihre Systeme, die in RISE mit SAP/ECS ausgeführt werden. Informationen zum Integrieren dieser Art von SAP-Landschaft mit Azure-Diensten und Ihrem Netzwerk finden Sie in der Azure-Dokumentation.

Andere Anforderungen an die SAP-Kommunikation

Für eine SAP-Landschaft, die in Azure betrieben wird, können zusätzliche Überlegungen zur internetgebundenen Kommunikation gelten. Der Datenverkehrsfluss in dieser Architektur verwendet eine zentrale Azure-Firewall für diesen ausgehenden Datenverkehr. Benutzerdefinierte Regeln in den virtuellen Spoke-Netzwerken leiten Anforderungen für den internetgebundenen Datenverkehr an die Firewall weiter. Alternativ können Sie NAT-Gateways in bestimmten Subnetzen, standardmäßige ausgehende Azure-Kommunikation, öffentliche IP-Adressen auf VMs (nicht empfohlen) oder einen öffentlichen Lastenausgleich mit Ausgangsregeln verwenden. Typische Szenarien erreichen öffentliche Endpunkte von Microsoft Entra ID, Azure-Verwaltungs-APIs bei management.azure.com und Dienste von Anwendungen von Drittanbietern oder Regierungsanwendungen über ausgehenden Netzwerkzugriff.

Aufgrund von Änderungen am standardmäßigen ausgehenden Zugriff in Azure stellen Sie sicher, dass ein skalierbarer ausgehender Zugriff definiert ist. Bei VMs, die sich hinter einem internen Standardlastenausgleich befinden, wie z. B. in Clusterumgebungen, ist zu beachten, dass Load Balancer Standard das Verhalten für die öffentliche Konnektivität modifiziert. Weitere Informationen finden Sie unter Public Endpoint Connectivity for VMs using Azure Load Balancer Standard in SAP high-availability scenarios.

Weitere Informationen zur standardmäßigen ausgehenden Konnektivität von VMs finden Sie unter Routingoptionen für VMs aus privaten Subnetzen im Azure Networking-Blog.

Betriebssystemupdates

Betriebssystemupdates befinden sich oft hinter einem öffentlichen Endpunkt und der Zugriff erfolgt über das Internet. Wenn kein unternehmensweites Repository und keine Updateverwaltung vorhanden sind, die Betriebssystemupdates von Anbietern auf private IP-Adressen/VMs spiegeln, muss Ihre SAP-Workload auf die Updaterepositorys der Anbieter zugreifen.

Für Linux-Betriebssysteme können Sie auf die folgenden Repositorys zugreifen, wenn Sie die Betriebssystemlizenz von Azure erhalten. Wenn Sie Lizenzen direkt erwerben und in Azure übernehmen (BYOS), wenden Sie sich an den Anbieter des Betriebssystems, um zu erfahren, wie Sie sich mit den Betriebssystemrepositorys und ihren jeweiligen IP-Adressbereichen verbinden können.

Verwaltung des Hochverfügbarkeitsclusters

Hochverfügbare Systeme wie gruppierte SAP ASCS/SCS oder Datenbanken können einen Cluster-Manager mit Azure-Fence-Agent als STONITH-Gerät verwenden. Diese Systeme sind darauf angewiesen, Azure Resource Manager zu erreichen. Resource Manager wird für Statusabfragen über Azure-Ressourcen und für Vorgänge zum Beenden und Starten von VMs verwendet. Da Resource Manager ein öffentlicher Endpunkt ist, der unter management.azure.com verfügbar ist, muss die ausgehende VM-Kommunikation ihn erreichen können. Diese Architektur basiert auf einer zentralen Firewall mit benutzerdefinierten Firewallregeln, die den Datenverkehr aus virtuellen SAP-Netzwerken weiterleiten. Alternative Informationen finden Sie in den vorherigen Abschnitten.

Beitragende

Dieser Artikel wird von Microsoft gepflegt. Er wurde ursprünglich von folgenden Mitwirkenden geschrieben:

Hauptautoren:

Andere Mitwirkende:

Melden Sie sich bei LinkedIn an, um nicht öffentliche LinkedIn-Profile anzuzeigen.

Communitys

Verwenden Sie diese Communitys, um Antworten auf Ihre Fragen zu erhalten und um Hilfe beim Einrichten einer Bereitstellung zu bekommen:

Nächste Schritte