Firewall, IP-Freigabe und mTLS

Für welche Anbindung gilt diese Anleitung?

Diese Anleitung beschreibt die im Kunden-Runbook vorgesehene Anbindung Azure Application Gateway WAF v2 → SAP Web Dispatcher → SAP S/4HANA. Sie richtet sich an das Azure- und Netzwerkteam sowie SAP Security. Die SAP-Dienste, Rollen und Verbindung in kontori werden separat eingerichtet.

Für eine direkt bereitgestellte S/4HANA Public Cloud wird diese Architektur nicht vorausgesetzt. Wendet die Schritte an, wenn der vereinbarte Integrationsweg tatsächlich über ein kundenseitiges Application Gateway und einen privaten Web Dispatcher führt.

So wird der Zugang geschützt

Nur ein dedizierter HTTPS-Endpunkt ist öffentlich erreichbar. Das Gateway prüft die feste Ausgangs-IP von kontori, das Client-Zertifikat und die erlaubten API-Pfade und HTTP-Methoden. SAP prüft anschließend zusätzlich den technischen Zugang und dessen Berechtigungen.

Vergrößern

Geschützter Integrationsweg

mTLS bedeutet, dass auch kontori sich beim HTTPS-Verbindungsaufbau mit einem Zertifikat ausweist. Dieses Client-Zertifikat ergänzt die SAP-Anmeldung. Es ersetzt weder Benutzerrechte noch OAuth.

Angaben und Zuständigkeiten

Alle Werte in eckigen Klammern sind Platzhalter. Tragt vor der Einrichtung die tatsächlich abgestimmten Werte ein.

Das Client-Zertifikat und sein privater Schlüssel bleiben auf der kontori-Seite. Für das Azure-mTLS-Profil wird ausschließlich die CA-Kette übergeben. Zertifikate für den öffentlichen Listener, für den Web Dispatcher und für den kontori-Client haben unterschiedliche Aufgaben.

1. Gateway und WAF-Policy vorbereiten

1. Stelle ein Application Gateway mit Tier/SKU: WAF_v2 bereit. Auch bei einem vorhandenen Gateway bekommt diese Integration einen eigenen Listener, eigene Backend-Einstellungen und eine eigene WAF-Policy.
2. Verwende ein dediziertes Application-Gateway-Subnetz. Im Runbook ist /24 für Autoscaling und Wartung empfohlen; andere Ressourcentypen gehören nicht in dieses Subnetz.
3. Konfiguriere Zone Redundancy und Autoscaling mit mindestens 2 Instanzen und dem abgestimmten Maximum.
4. Lege die WAF-Policy waf-kontori-s4 mit DRS 2.2 zunächst im Detection-Modus an. Aktiviere Request body inspection und setze die Request-Grenze auf [MAX_REQUEST_KB]. Sie muss auch $batch und die größte freigegebene Payload abdecken.
5. Aktiviere über Diagnostic settings die Kategorien ApplicationGatewayAccessLog und ApplicationGatewayFirewallLog. Sende die Logs an den vereinbarten Log Analytics Workspace beziehungsweise das SIEM und bestätige den Empfang mit einer Testabfrage.

Die verwalteten Regeln dokumentiert Microsoft unter DRS- und CRS-Regelgruppen.

2. DNS, HTTPS-Listener und mTLS einrichten

Öffentlicher Endpunkt

1. Binde den kontori-Listener an eine statische Standard Public IPv4. Konfiguriere für diesen Integrationsweg keinen öffentlichen IPv6-Zugang.
2. Richte für [PUBLIC_FQDN] einen A-/Alias-Record auf diese Adresse ein. Ein CNAME ist nur geeignet, wenn die Public-IP-Ressource einen eigenen DNS-Namen besitzt; er zeigt dann auf diesen Namen.
3. Lege unter Listeners → Add listener den HTTPS-Listener listener-kontori-s4-https auf Port 443 an. Ordne ihm den dedizierten Hostnamen [PUBLIC_FQDN] zu.
4. Hinterlege [FRONTEND_CERTIFICATE_PFX] als Frontend TLS certificate. Die Zertifikatskette muss gültig sein und zum öffentlichen DNS-Namen passen.
5. Wähle eine TLS-Richtlinie mit TLS 1.2 oder höher. TLS 1.0/1.1 und schwache Cipher werden nicht zugelassen.

Platziert für diesen Listener keine zusätzliche CDN- oder Reverse-Proxy-Schicht vor dem Gateway. Die IP-Regel soll die tatsächliche kontori-Ausgangsadresse in RemoteAddr prüfen.

Client-Zertifikat im Strict-Modus prüfen

1. Öffne am Gateway SSL profiles → Add und lege kontori-s4-mtls an.
2. Wähle für Client Authentication den Modus Strict und deaktiviere Passthrough.
3. Lade kontori-client-ca-chain.pem als Trusted Client CA Chain hoch. Die Datei enthält genau eine Kette mit genau einer Root-CA und allen benötigten Intermediate-CAs; sie ist höchstens 25 KB groß. Client-Leaf-Zertifikat und privater Schlüssel werden hier nicht hochgeladen.
4. Verwende ausschließlich die dedizierte kontori-Client-CA-Kette und aktiviere Verify client certificate issuer DN.
5. Ordne das SSL-Profil dem Listener listener-kontori-s4-https zu.

Vergrößern

Client-CA-Kette und SSL-Profil zuordnen

Aktiviere die Zertifikats-Sperrprüfung OCSP, wenn das Client-Zertifikat einen erreichbaren OCSP-Responder in seiner AIA-Erweiterung enthält. Das Azure-Team stellt dafür DNS und Netzwerkzugriff vom Gateway zum Responder sicher. Die Konfiguration erfolgt über die freigegebene Infrastrukturverwaltung, CLI oder PowerShell; im Azure Portal wird sie derzeit nicht angeboten. Fehlt OCSP, verlangt das Referenz-Runbook vor dem Produktivstart eine dokumentierte Security-Ausnahme. Die Microsoft-Anleitung zu mTLS und OCSP beschreibt die Optionen.

Für ein bereits angelegtes SSL-Profil lautet das PowerShell-Muster:

$AppGw = Get-AzApplicationGateway -Name "[APPGW_NAME]" -ResourceGroupName "[RESOURCE_GROUP]"
$Profile = Get-AzApplicationGatewaySslProfile -Name "kontori-s4-mtls" -ApplicationGateway $AppGw
Set-AzApplicationGatewayClientAuthConfiguration -SslProfile $Profile -VerifyClientCertIssuerDN -VerifyClientRevocation OCSP
Set-AzApplicationGateway -ApplicationGateway $AppGw

Client-Zertifikat in kontori hinterlegen

Für den geschützten Endpunkt wird auf der kontori-Seite zusätzlich der Abschnitt Client Certificate der S/4HANA-Verbindung befüllt. Unter Client certificate chain wird die PEM-Kette des kontori-Client-Zertifikats, unter Client certificate private key dessen zugehöriger Schlüssel hinterlegt. Diese Einrichtung erfolgt durch die zuständige kontori-Administration; der Schlüssel wird nicht an das Kundengateway weitergegeben.

CA bundle dient einem anderen Zweck: Es ergänzt auf der kontori-Seite das Vertrauen zum Serverzertifikat des Endpunkts, falls dieses von einer privaten CA ausgestellt wurde. Bei einem öffentlich vertrauenswürdigen Serverzertifikat bleibt das Feld leer.

3. Privates Backend und Firewall anbinden

Netzwerkfreigabe zum Web Dispatcher

SAP Basis stellt den Web Dispatcher unter [WD_PRIVATE_FQDN]:[WD_HTTPS_PORT] bereit. Netzwerk und Firewall lassen auf diesem Port ausschließlich das Application-Gateway-Subnetz als Quelle zu. Der private DNS-Name muss vom Gateway auflösbar sein; der Netzwerkweg zum Backend muss funktionieren.

Web Administration und Admin Handler werden über diesen Integrationsendpunkt nicht veröffentlicht. Auch das SAP-System selbst erhält keinen direkten öffentlichen Zugang für diese Integration.

Backend-Pool und HTTPS-Einstellungen

Lege unter Backend pools den Pool pool-sap-web-dispatcher mit Target type: FQDN und Target: [WD_PRIVATE_FQDN] an. Erstelle anschließend unter Backend settings die Einstellungen bhs-sap-web-dispatcher-https.

Vergrößern

HTTPS und Backend-Zertifikat prüfen

Das Gateway verwendet zum Web Dispatcher HTTPS mit Serverzertifikatsprüfung. Das kontori-Client-Zertifikat wird am öffentlichen Listener geprüft; die SAP-Anmeldung bleibt zusätzlich aktiv. Die Microsoft-Dokumentation zu Backend-Einstellungen erläutert TLS-Prüfung und SNI.

Health Probe vorbereiten

SAP Basis aktiviert und testet intern den Ping-Pfad /sap/public/icman/ping. Er wird nur vom Gateway zum privaten Backend aufgerufen und gehört nicht in die öffentliche API-Allowlist.

Die Probe wird den Backend-Einstellungen zugeordnet. Ihre regelmäßige Prüfung wird mit der vollständigen Routing-Zuordnung im fünften Schritt wirksam.

4. IP-, API- und Methoden-Allowlist konfigurieren

Lege in waf-kontori-s4 unter Custom rules → Add custom rule drei getrennte Regeln an. Jede Regel ist eine Match rule, hat eine eigene Priorität und blockiert mit einer negierten Bedingung alles außerhalb der jeweiligen Freigabe.

Feste kontori-IP

Damit werden Anfragen anderer Quelladressen blockiert, sobald Prevention aktiv ist. Eine einzelne IPv4 wird mit /32 eingetragen. Für IPMatch mit RemoteAddr beschreibt Microsoft nur IPv4-Unterstützung; deshalb bleibt dieser Integrationsweg ausschließlich über IPv4 erreichbar.

Freigegebene API-Pfade

Übernehmt die vollständigen, kanonischen Service-Präfixe mit abschließendem / aus der abgestimmten API-Liste. Mehrere Match Values innerhalb dieser Bedingung sind Alternativen. Die Liste richtet sich nach den auf der SAP-Seite beschriebenen Datenbereichen und den tatsächlich verwendeten Service-Adressen.

Beispiele für einzelne Dienste, keine pauschale Freigabeliste:

/sap/opu/odata/sap/API_BUSINESS_PARTNER/
/sap/opu/odata4/sap/api_product/srvd_a2x/sap/product/0002/
/sap/opu/odata4/sap/api_cost_center/srvd_a2x/sap/costcenter/0001/

Gebt weder /sap/* noch /sap/opu/odata/* allgemein frei. Der Probe-Pfad bleibt privat. Ein OAuth-Token-Endpunkt bekommt nur dann eine eigene, eng begrenzte Freigabe, wenn kontori ihn über denselben öffentlichen Host aufruft; ein separater Identity Provider wird unabhängig behandelt.

Zulässige HTTP-Methoden

Stimmt die Methoden mit dem tatsächlichen Datenumfang ab. Auch $batch, Metadatenabrufe und vereinbarte Schreiboperationen müssen berücksichtigt werden.

Verwendet für diese Freigaben keine Custom Rule mit Action: Allow: Sie kann nachgelagerte WAF-Prüfungen überspringen. Die Regellogik und den Unterschied zwischen Detection und Prevention beschreibt Microsoft unter WAF Custom Rules. Ändert API-Liste und Methoden bei funktionalen Erweiterungen kontrolliert und versioniert.

5. Routing und Backend Health prüfen

Lege die Request-Routing-Regel erst an, wenn HTTPS, das Strict-mTLS-Profil und die drei WAF-Regeln vorbereitet sind.

Bei einem gemeinsam genutzten Gateway überschreibt die Listener-Policy für diesen Listener die globale Policy. Prüft deshalb, dass alle für kontori erforderlichen Regeln in seiner Policy enthalten sind. Andere Listener behalten ihre Konfiguration.

Unter Backend health muss der Web Dispatcher Healthy melden. Prüft andernfalls zuerst private DNS-Auflösung, Firewall, HTTPS-Port, Zertifikatskette, SNI und den Probe-Pfad. Ein gesunder Probe-Status bestätigt die Backend-Erreichbarkeit; SAP-Anmeldung und API-Berechtigungen werden zusätzlich geprüft.

Abnahme vor dem Produktivbetrieb

Im Detection-Modus wird zunächst geprüft, ob die geplanten WAF-Regeln in den Logs treffen und der vereinbarte API-Verkehr funktioniert. Danach wird die Policy auf Prevention umgestellt und die Blockwirkung anhand der folgenden Fälle bestätigt.

Prüft bei jedem Fall die Gateway- und WAF-Logs sowie bei zulässiger Weiterleitung die SAP-Protokolle. Haltet den getesteten API-Umfang und das Ergebnis fest. Erst nach erfolgreicher Abnahme bleibt Prevention für den Produktivverkehr aktiv.

Betrieb und Änderungen

Hinterlegt Verantwortliche und Ablaufdaten für Listener-, Backend- und Client-Zertifikate. Eine Erneuerung wird vor Ablauf einschließlich CA-Kette, Ausstellerprüfung und gegebenenfalls OCSP getestet. Private Schlüssel verbleiben beim jeweiligen Betreiber.

Bei einer Änderung der kontori-Ausgangs-IP wird die /32-Freigabe abgestimmt aktualisiert. Werden neue Datenbereiche oder Rückschreiboperationen aktiviert, prüfen kontori, SAP Basis und das Netzwerkteam gemeinsam SAP-Rollen, API-Präfixe, Methoden, Request-Grenzen und Timeouts.

Bei Fehlern helfen die beteiligten Schichten bei der Eingrenzung: TLS-/Client-Zertifikatsfehler am Listener, IP-/Pfad-/Methodenblock im WAF-Log, Backend-Verbindungsfehler unter Backend health und SAP-Berechtigungsfehler in SAP. Anschließend wird die erste Synchronisierung in kontori geprüft.