Sicheres Verfügbarmachen von SAP-Legacy-Middleware mit Azure-PaaS
In einer Vielzahl von Szenarios müssen interne Systeme und externe Partner mit SAP-Back-Ends interagieren können. In vorhandenen SAP-Landschaften werden häufig die Legacy-Middlewarelösungen SAP Process Orchestration (PO) oder Process Integration (PI) eingesetzt, um die jeweiligen Integrations- und Transformationsanforderungen zu erfüllen. Der Einfachheit halber wird in diesem Artikel der Begriff SAP Process Orchestration verwendet, um auf beide Angebote zu verweisen.
In diesem Artikel werden Konfigurationsoptionen in Azure beschrieben. Der Schwerpunkt liegt dabei auf Implementierungen mit Internetzugriff.
Hinweis
SAP nennt SAP Integration Suite – insbesondere SAP Cloud Integration – auf Business Technology Platform (BTP) als Nachfolger von SAP PO und PI. Sowohl die BTP-Plattform als auch die Dienste sind in Azure verfügbar. Weitere Informationen finden Sie im SAP Discovery Center. Weitere Informationen zur Wartungssupportzeitachse für die Legacy-Komponenten finden Sie unter SAP OSS-Hinweis 1648480.
Übersicht
Bei vorhandenen auf SAP-Middleware basierenden Implementierungen wird häufig die proprietäre SAP-Dispatch-Technologie SAP Web Dispatcher verwendet. Diese Technologie ist in Schicht 7 des OSI-Modells implementiert und wird als Reverseproxy sowie zum Lastenausgleich für nachgelagerte SAP-Anwendungsworkloads wie SAP Enterprise Resource Planning (ERP), SAP Gateway oder SAP Process Orchestration verwendet.
Dispatching-Lösungen umfassen herkömmliche Reverseproxys wie Apache, PaaS-Optionen (Platform as a Service) wie Azure Load Balancer und den wertenden SAP Web Dispatcher. Die in diesem Artikel beschriebenen allgemeinen Konzepte gelten für die genannten Optionen. Informationen zur Verwendung von Lastenausgleichsmodulen anderer Anbieter finden Sie im SAP-Wiki.
Hinweis
Bei allen in diesem Artikel beschriebenen Setups wird davon ausgegangen, dass eine Hub-and-Spoke-Netzwerktopologie verwendet wird, in der gemeinsame Dienste im Hub bereitgestellt werden. Basierend auf der kritischen Rolle von SAP benötigen Sie möglicherweise eine zusätzliche Isolation. Weitere Informationen finden Sie unter „Eingehende und ausgehende Internetverbindungen für SAP in Azure“ im Abschnitt Netzwerkentwurf.
Primäre Azure-Dienste
Azure Application Gateway wird eingesetzt für das öffentliche internetbasierte und interne private HTTP-Routing sowie für das verschlüsselte Tunneln zwischen Azure-Abonnements. Beispiele sind Sicherheits und automatische Skalierung.
Da der Fokus auf dem Verfügbarmachen von Webanwendungen liegt, bietet Azure Application Gateway eine Webanwendungsfirewall (WAF). Workloads in anderen virtuellen Netzwerken, die mit SAP über Azure Application Gateway kommunizieren, können über private Verbindungen sogar mandantenübergreifend verbunden werden.
Azure Firewall übernimmt das öffentliche internetbasierte und interne private Routing für Datenverkehrstypen in den Schichten 4 bis 7 des OSI-Modells. Der Dienst bietet eine Filterung und Threat Intelligence-Feeds direkt von Microsoft Security.
Azure API Management wird für das öffentliche internetbasierte und das interne private Routing speziell für APIs eingesetzt. Der Dienst bietet eine Anforderungsbegrenzung, Nutzungskontingente und -einschränkungen, Governancefeatures wie Richtlinien sowie API-Schlüssel für die Aufschlüsselung von Diensten nach Client.
Azure VPN Gateway und Azure ExpressRoute werden als Einstiegspunkte für lokale Netzwerke eingesetzt. Sie werden in den Diagrammen als VPN und XR abgekürzt.
Überlegungen zum Setup
Abhängig von der Schnittstelle, die eine Organisation verwendet, muss eine abweichende Integrationsarchitektur implementiert werden. SAP-proprietäre Technologien wie Intermediate Document (IDoc) Framework, Business Application Programming Interface (BAPI), transaktionsale Remotefunktionsaufrufe (tRFCs) oder einfache RFCs erfordern eine bestimmte Laufzeitumgebung. Sie sind in den Schichten 4 bis 7 des OSI-Modells implementiert, im Gegensatz zu modernen APIs, die normalerweise auf HTP-basierter Kommunikation basieren (Schicht 7 des OSI-Modells). Aus diesem Grund können die Schnittstellen nicht auf die gleiche Weise behandelt werden.
Dieser Artikel konzentriert sich auf moderne APIs und HTTP, einschließlich Integrationsszenarios wie Applicability Statement 2 (AS2). File Transfer Protocol (FTP) dient als Beispiel für den Umgang mit Nicht-HTTP-Integrationsanforderungen. Weitere Informationen zu Microsoft-Lastenausgleichslösungen finden Sie unter Optionen für den Lastenausgleich.
Hinweis
SAP veröffentlicht dedizierte Connectors für die eigenen Schnittstellen. Suchen Sie in der SAP-Dokumentation z. B. nach Java und .NET. Diese Connectors werden auch von Microsoft-Gateways unterstützt. Beachten Sie, dass iDocs auch über HTTP gepostet werden können.
Aufgrund von Sicherheitsaspekten ist die Verwendung von Firewalls für Protokolle niedrigerer Schichten und WAFs für HTTP-basierten Datenverkehr mit Transport Layer Security (TLS) erforderlich. Für eine effektive Implementierung müssen TLS-Sitzungen auf WAF-Ebene beendet werden. Für die Unterstützung von Zero-Trust-Ansätzen wird anschließend eine erneute Verschlüsselung empfohlen, um die End-to-End-Verschlüsselung sicherzustellen.
Bei Integrationsprotokollen wie AS2 können Warnungen mithilfe von WAF-Standardregeln ausgelöst werden. Es wird empfohlen, mithilfe des Application Gateway-WAF-Triageworkbooks zu ermitteln, weshalb eine Regel ausgelöst wird. So können Sie effektiv und sicher darauf reagieren. Die Standardregeln werden vom Open Web Application Security Project (OWASP) bereitgestellt. Einen detaillierten Videobeitrag zu diesem Thema – mit Fokus auf dem Verfügbarmachen von SAP Fiori – finden Sie im Webcast zu SAP in Azure.
Sie können die Sicherheit weiter verbessern, indem Sie die gegenseitige TLS (mTLS) verwenden, die auch als gegenseitige Authentifizierung bezeichnet wird. Im Gegensatz zur normalen TLS wird dabei die Clientidentität überprüft.
Hinweis
Bei VM-Pools ist ein Lastenausgleich erforderlich. Für eine bessere Lesbarkeit zeigen die Diagramme in diesem Artikel keinen Lastenausgleich.
Hinweis
Wenn Sie keine SAP-spezifischen Ausgleichsfeatures benötigen, die SAP Web Dispatcher bereitstellt, können Sie sie durch Azure Load Balancer ersetzen. Dieser Ersatz bietet den Vorteil eines verwalteten PaaS-Angebots anstelle eines Infrastructure-as-a-Service-Setups (IaaS).
Szenario: Fokus auf eingehender HTTP-Konnektivität
SAP Web Dispatcher bietet keine WAF. Für ein sichereres Setup wird daher Azure Application Gateway empfohlen. SAP Web Dispatcher und Process Orchestration sind dabei mit Dimensionierungsrichtlinien und Grenzwerten für gleichzeitige Anforderungen weiterhin dafür verantwortlich, das SAP-Back-End vor einer Überlastung durch zu viele Anforderungen zu schützen. SAP-Workloads bieten keine Drosselungsmöglichkeit.
Sie können unbeabsichtigten Zugriff durch Zugriffssteuerungslisten auf SAP Web Dispatcher vermeiden.
Eines der Szenarios für die SAP Process Orchestration-Kommunikation ist ein eingehender Flow. Der Datenverkehr kann von lokalen, externen Apps oder Benutzer*innen oder einem internen System stammen. Das folgende Beispiel konzentriert sich auf HTTPS.
Szenario: Fokus auf ausgehender HTTP/FTP-Konnektivität
Für die umgekehrte Kommunikationsrichtung kann SAP Process Orchestration virtuelles Netzwerkrouting verwenden, um lokale Workloads oder internetbasierte Ziele über das Internetbreakout zu erreichen. Azure Application Gateway dient in diesen Szenarios als Reverseproxy. Ziehen Sie für die Nicht-HTTP-Kommunikation das Hinzufügen von Azure Firewall in Betracht. Weitere Informationen finden Sie weiter unten in diesem Artikel unter Szenario: Dateibasiert und Vergleich von Gatewaysetups.
Das folgende Szenario mit ausgehendem Datenverkehr zeigt zwei mögliche Methoden. Eine verwendet HTTPS über Azure Application Gateway mit Aufruf eines Webdiensts (z. B. SOAP-Adapter). Die andere verwendet FTP over SSH (SFTP) über Azure Firewall mit der Übertragung von Dateien an den SFTP-Server eines Geschäftspartners.
Szenario: Fokus auf API Management
Im Vergleich zu den Szenarios für eingehende und ausgehende Konnektivität werden bei der Einführung von Azure API Management im internen Modus (nur private IP und virtuelle Netzwerkintegration) u. a. folgende integrierte Funktionen hinzugefügt:
- Einschränkung.
- API-Governance,
- zusätzliche Sicherheitsoptionen wie moderne Authentifizierungsflows,
- Microsoft Entra ID-Integration.
- die Möglichkeit, SAP-APIs zu einer zentralen unternehmensweiten API-Lösung hinzuzufügen.
Wenn Sie keine WAF benötigen, können Sie Azure API Management im externen Modus bereitstellen, indem Sie eine öffentliche IP-Adresse verwenden. Diese Bereitstellung vereinfacht das Setup und behält die Drosselungs- und API-Governancefunktionen bei. Der Basic-Schutz wird für alle Azure-PaaS-Angebote implementiert.
Szenario: Globale Reichweite
Azure Application Gateway ist ein regionsbasierter Dienst. Im Vergleich zu den oben genannten Szenarios stellt Azure Front Door ein globales regionsübergreifendes Routing sicher (einschließlich einer Webanwendungsfirewall). Ausführliche Informationen zu den Unterschieden finden Sie in diesem Vergleich.
Das folgende Diagramm komprimiert SAP Web Dispatcher, SAP Process Orchestration und das Back-End in ein einzelnes Bild, um die Lesbarkeit zu verbessern.
Szenario: Dateibasiert
Für Nicht-HTTP-Protokolle wie FTP können Azure API Management, Application Gateway oder Azure Front Door nicht wie in den vorherigen Szenarios gezeigt eingesetzt werden. Stattdessen wird die verwaltete Azure Firewall-Instanz oder die äquivalente Network Virtual Appliance (NVA) für die Sicherheit eingehender Anforderungen verwendet.
Dateien müssen gespeichert werden, bevor SAP sie verarbeiten kann. Sie sollten SFTP verwenden. Azure Blob Storage bietet native Unterstützung für SFTP.
Bei Bedarf stehen alternative SFTP-Optionen im Azure Marketplace zur Verfügung.
Das folgende Diagramm zeigt eine Variation dieses Szenarios mit externen und lokalen Integrationszielen. Verschiedene Typen von sicherem FTP veranschaulichen den Kommunikationspfad.
Einblicke in NFS-Dateifreigaben (Network File System) als Alternative zu Blob Storage finden Sie unter NFS-Dateifreigaben in Azure Files.
Szenario: SAP RISE-spezifisch
SAP RISE-Bereitstellungen sind technisch identisch mit den zuvor beschriebenen Szenarios. Die einzige Ausnahme besteht darin, dass die SAP-Zielworkload von SAP selbst verwaltet wird. Die beschriebenen Konzepte können hier angewendet werden.
Die folgenden Diagramme zeigen zwei Setups als Beispiele. Weitere Informationen finden Sie unter „Integrieren von Azure in verwaltete SAP RISE-Workloads“ im Abschnitt Peering virtueller Netzwerke mit SAP RISE/ECS.
Wichtig
Wenden Sie sich an SAP, um sicherzustellen, dass Kommunikationsports für Ihr Szenario zulässig und in NSGs geöffnet sind.
HTTP eingehend
Im ersten Setup werden die Integrationsschicht (einschließlich SAP Process Orchestration) und der vollständige eingehende Pfad vom Kunden gesteuert. Lediglich das endgültige SAP-Ziel wird im RISE-Abonnement ausgeführt. Die Kommunikation mit der in RISE gehosteten Workload wird über das Peering virtueller Netzwerke konfiguriert (in der Regel über den Hub). Eine potenzielle Integration könnten iDocs sein, die von einer externen Partei im SAP ERP-Webdienst /sap/bc/idoc_xml gepostet werden.
In diesem zweiten Beispiel wird ein Setup gezeigt, bei dem SAP RISE die gesamte Integrationskette ausführt (mit Ausnahme der API Management-Ebene).
Datei ausgehend
In diesem Szenario schreibt die von SAP verwaltete Process Orchestration-Instanz Dateien in die vom Kunden verwaltete Dateifreigabe in Azure oder in eine lokale Workload. Der Kunde ist für das Breakout zuständig.
Vergleich von Gatewaysetups
Hinweis
Bei den Leistungs- und Kostenmetriken wird von Produktionsdienstebenen ausgegangen. Weitere Informationen finden Sie beim Azure-Preisrechner. Weitere Informationen finden Sie in den folgenden Artikeln: Azure Firewall-Leistung, Unterstützung von hohem Datenverkehr für Application Gateway und Kapazität einer Azure API Management-Instanz.
Abhängig von den verwendeten Integrationsprotokollen benötigen Sie möglicherweise mehrere Komponenten. Weitere Informationen zu den Vorteilen der verschiedenen Kombinationen der Verkettung von Azure Application Gateway mit Azure Firewall finden Sie unter Azure Firewall und Application Gateway für virtuelle Netzwerke.
Faustregel für die Integration
Welche der in diesem Artikel beschriebenen Integrationsszenarios sich am besten für Ihre Anforderungen eignet, muss von Fall zu Fall bewertet werden. Erwägen Sie die Aktivierung der folgenden Funktionen:
Anforderungsbegrenzung mithilfe von API Management
Einschränkung der maximalen Anzahl von gleichzeitigen Anforderungen in SAP Web Dispatcher
Gegenseitige TLS zur Verifizierung von Client und Empfänger
Azure Firewall für Nicht-HTTP-Integrationen
Hochverfügbarkeit und Notfallwiederherstellung für VM-basierte SAP-Integrationsworkloads
Moderne Authentifizierungsmechanismen wie OAuth2, sofern anwendbar
Ein verwalteter Schlüsselspeicher wie Azure Key Vault für alle beteiligten Anmeldeinformationen, Zertifikate und Schlüssel
Alternativen zu SAP Process Orchestration mit Azure Integration Services
Mit dem Azure Integration Services-Portfolio können Sie nativ die Integrationsszenarios abdecken, die SAP Process Orchestration abdeckt. In dieser Blogreihe finden Sie Erkenntnisse zum Entwerfen von SAP iFlow-Mustern mit cloudnativen Mitteln. Das Connectorhandbuch enthält weitere Details zu AS2 und EDIFACT.
Weitere Informationen finden Sie unter Azure Logic Apps-Connectors für Ihre gewünschten SAP-Schnittstellen.
Nächste Schritte
Schützen von APIs mit Application Gateway und API Management
Integrieren von API Management in ein internes virtuelles Netzwerk mit Application Gateway
Verstehen der Application Gateway-WAF für SAP
Verstehen der Auswirkungen beim Kombinieren von Azure Firewall und Azure Application Gateway