Der SAP Cloud Connector (SCC) ist die zentrale Verbindungskomponente zwischen der SAP Business Technology Platform (BTP) und Ihren On-Premise-Systemen. Er ermöglicht dadurch einen sicheren, kontrollierten Zugriff auf Backend-Landschaften wie SAP S/4HANA, BW/4HANA oder andere interne Dienste.
Jedoch arbeiten viele Unternehmen noch mit veralteten Architekturen, unzureichend konfigurierten SCC-Instanzen oder überholten Praktiken. Das führt schnell zu Sicherheitsrisiken, die eigentlich vermeidbar sind. In diesem Artikel zeigen wir Ihnen, welche Punkte im Jahr 2026 weiterhin für den SCC-Betrieb kritisch sind und wie Sie eine nachhaltige Grundlage für die kommenden Jahre schaffen.
→ Der SAP Cloud Connector (SCC) verbindet Ihre On-Premise-Systeme sicher mit der SAP Business Technology Platform (BTP) in der Cloud. → Die Principal Propagation ersetzt technische Benutzer durch echte Endbenutzeridentitäten. So stellen Sie eine durchgängige Nachvollziehbarkeit sicher und vermeiden überprivilegierte Systembenutzer. → Achten Sie auf eine strikte Zugriffskontrolle: Exponieren Sie nur die Ressourcen, die tatsächlich benötigt werden, und setzen Sie gezielt Allowlists statt pauschaler Freigaben ein. → Nutzen Sie separate signierte Zertifikate für UI und Systemkommunikation, setzen Sie auf starke Algorithmen (RSA 4096 / ECDSA) und überwachen Sie Ablaufdaten proaktiv. |
Der SAP Cloud Connector ist eine wesentliche Komponente bei der Umsetzung hybrider SAP-Architekturen. Zusammen mit dem SAP Cloud Connectivity Service ermöglicht er Cloud-Anwendungen den sicheren Zugriff auf On-Premise-Systeme. Wenn eine Anwendung oder ein Dienst auf der SAP BTP auf Daten eines Backend-Systems zugreifen muss (z. B. S/4HANA, BW oder HANA), ist der Cloud Connector das Mittel der Wahl.
Technisch handelt es sich beim Cloud Connector um einen kleinen Software-Agenten, den Sie in Ihrer On-Premise-Umgebung installieren. Er fungiert als sogenannter Reverse-Invoke-Proxy: Sobald er mit einem BTP-Subaccount gekoppelt ist, baut er einen sicheren Tunnel zur Cloud auf. Dabei sind weder eingehende Firewall-Regeln nötig, noch werden Backend-Systeme dem Internet ausgesetzt. Eine einzelne SCC-Instanz lässt sich selbtverständlich mit mehreren Subaccounts verknüpfen.
Der SCC bietet Ihnen unter anderem:
Hinweis!
Darüber hinaus unterstützt der SCC auch Single Sign-On (SSO): Er generiert kurzlebige X.509-Zertifikate, um Benutzeridentitäten von der Cloud an das On-Premise-System weiterzuleiten. Diesen Mechanismus bezeichnet man als Principal Propagation.
In hybriden SAP-Landschaften nimmt der Cloud Connector eine besondere Rolle ein:
Aus Sicherheitssicht ist der SCC damit eine Schlüsselkomponente: Seine Konfiguration bestimmt, wer und was wie auf Ihre internen Systeme zugreifen kann.
Basierend auf unseren Sicherheitsüberprüfungen bei Xiting betreiben mehr als 80 % der Kunden den SCC mit veralteten Patches, fehlerhaften TLS-Konfigurationen oder inaktivem Monitoring. Den Cloud Connector als „set-and-forget“-Komponente zu behandeln, ist keine tragbare Strategie. Er muss wie jede kritische Infrastrukturkomponente kontinuierlich gepatcht, überwacht und verwaltet werden.
Schneller Selbst-Check!
Prüfen Sie die folgenden Punkte für Ihre Umgebung:
Wenn Sie zwei oder mehr dieser Punkte mit „Nein“ beantworten mussten, ist es Zeit für einen SCC-Health-Check. Wir bei Xiting unterstützen Sie dabei gerne.
Bevor wir auf die sicherheitsrelevanten Aspekte eingehen, geben wir Ihnen einen Überblick über die grundlegende Architektur des SAP Cloud Connectors:
In einem Standard-Hybrid-Setup wird der SCC On-Premise (oder in einer Private Cloud) installiert und als Connector für einen oder mehrere BTP-Subaccounts registriert. Er erstellt einen sicheren ausgehenden Tunnel, der es autorisierten Cloud-Diensten ermöglicht, ohne eingehende Firewall-Öffnungen mit internen Systemen zu kommunizieren.
Wesentliche Elemente umfassen:
In produktiven Umgebungen ist Hochverfügbarkeit (HA) essentiell, um Single Points of Failure zu vermeiden.
→ Eine Master-Node verwaltet aktiv Subaccount-Verbindungen, Tunnel und Konfigurationen.
→ Eine Shadow-Node läuft im Standby-Modus und synchronisiert kontinuierlich Konfigurationsdaten und Benutzerkontext vom Master.
→ Ist die Master-Node nicht verfügbar, übernimmt die Shadow-Node automatisch.
Diese Architektur gewährleistet Fehlertoleranz, nahtloses Failover und operative Kontinuität.Somit deckt sie alle entscheidenden Voraussetzungen für produktive SAP-BTP-Szenarien ab.
Im vergangenen Jahr haben wir bei Xiting zahlreiche SCC-Sicherheitsüberprüfungen branchenübergreifend durchgeführt. Jede Umgebung hat ihre eigenen Besonderheiten, doch bestimmte Muster begegnen uns immer wieder.
Die folgende Checkliste fasst die wichtigsten Kontrollen für Sie zusammen.
Die LDAP-Integration ersetzt lokale Administratorkonten durch eine zentrale Benutzerverwaltung. So lassen sich Passwortkomplexität und -richtlinien einheitlich durchsetzen.
Hinweis!
Mit der Principal Propagation wird ein authentifizierter Cloud-Benutzer durch dieselbe Identität im On-Premise-System repräsentiert. Technische Benutzer werden dadurch durch echten Endbenutzerkontext ersetzt. Wir erklären Ihnen, wie das funktioniert.
Ein User meldet sich bei einem SAP-BTP-Dienst an – zum Beispiel bei SAP Analytics Cloud – und authentifiziert sich über seinen Unternehmens-Identitätsanbieter (z. B. Microsoft Entra ID).
Nach erfolgreicher Anmeldung stellt die BTP ein SAML- oder JWT-Token aus, das die Attribute des Benutzers enthält.
Der SCC wandelt diese Assertion in ein kurzlebiges X.509-Zertifikat um. Es enthält nur minimale identifizierende Informationen (z. B. CN = Benutzername oder E-Mail) und dient ausschließlich als Identitätstoken, nicht für den TLS-Handshake.
Das Systemzertifikat des SCC wickelt den TLS-Kanal zum Backend ab. Das kurzlebige Benutzerzertifikat wird in den HTTP-Header (SSL_CLIENT_CERT) der Anfrage eingefügt.
Das SAP-Backend (S/4HANA, BW, Web Dispatcher usw.) validiert das Zertifikat über die STRUST-Trust-Konfiguration und ordnet den CN-Wert (ggf. weitere) über die Transaktion „CERTRULE“ zu.
Stimmt die Zuordnung, wird eine SSO-Sitzung unter der weitergeleiteten Benutzeridentität erstellt.
Ein häufiges Missverständnis: Nicht das Benutzerzertifikat ist die kritische Berechtigung. Das SCC-Systemzertifikat, sein privater Schlüssel und das entsprechende CA-Vertrauen in STRUST bilden die eigentliche Sicherheitsgrundlage.
Wird das Systemzertifikat kompromittiert, könnte ein Angreifer den SCC selbst imitieren. Deshalb sind eine OS-Härtung und der richtige Dateisystemschutz für Keystores (JKS/P12) so wichtig.
Der SAP Cloud Connector bringt eine eigene interne CA (Certificate Authority) mit.
Einige Unternehmen bevorzugen es jedoch, die Zertifikatsausstellung an den SAP Secure Login Server (SLS) zu delegieren, meist aus Compliance- oder HSM-Integrationsgründen.
→ SLS läuft auf AS Java, bringt zusätzliche operative Komplexität mit sich und erreicht 2027 das End of Life.
→ Ist HSM-Integration für Sie zwingend erforderlich, kann SLS noch gerechtfertigt sein.
→ In allen anderen Fällen bietet die integrierte SCC-CA ein gutes Gleichgewicht zwischen Einfachheit und Sicherheit.
Unsere Praxiserfahrungen aus zahlreichen hybriden SAP-Landschaften zeigen wiederkehrende Befunde.
Im Folgenden geben wir Ihnen einen Überblick über unsere Erkenntnisse:
Technische Hygiene
– SCC v2.18.1, SLES 15 SP5,
SAP JVM 8.1.105
– Ordnungsgemäße DMZ-Segmentierung
– Betrieb mit Nicht-Root-Dienstbenutzer
– Hochverfügbarkeit (Master/Shadow) implementiert
Identitäts- und Zugriffsschwächen
– Lokale Administrator-
konten ohne zentrale Steuerung
– Keine zentralen Passwortrichtlinien
– Fehlende LDAP-Integration
Zertifikats- und Trust-Probleme
– Interne 2-stufige PKI
(Root-CA + ausstellende CA)
im Einsatz
– Beim lokalen CA fehlt das KEYCERTSIGN-Flag (nicht blockierend, aber relevant)
– Abgelaufene Backend-
Trust-Einträge
BTP-Neo-Allowlist-Fehlkonfiguration
Eine leere Allowlist
bedeutet:
Allem wird vertraut.
→ Setzen Sie bekannte Anwendungen immer
explizit auf die Whitelist.
Subaccount-Zertifikatserneuerung
Eine manuelle Erneuerung führte in der Vergangenheit
zu Ausfallzeiten.
→ Seit Version 2.18 können
Sie die automatische Erneuerung über die SCC-Benutzeroberfläche und das BTP-Cockpit aktivieren
(~30 Tage vor Ablauf).
TLS-Cipher-Suites
Nur moderne ECDHE- und
AES-GCM-Cipher-Suites
aktiv.
→ Ob TLS 1.3 unterstützt
wird, hängt oft von der eingesetzten JVM und deren Einstellungen ab. Viele produktive Setups verlassen sich weiterhin auf gehärtete TLS 1.2‑ Konfigurationen.
Protokollierung & Alarmierung
– Audit-Level auf „ALL“ gesetzt
– Weiterleitung an ein SIEM-System für die Langzeitaufbewahrung
– Alarme für CPU-Auslastung, Speicherplatz und Zertifikatsablauf eingerichtet
Fehlende RFC-SNC-Verschlüsselung
Die RFC-Kommunikation zwischen SCC und Backend ist unverschlüsselt.
→ Wir empfehlen Ihnen,
SNC einzuführen, um die Identitätsweitergabe abzusichern und
Compliance-Anforderungen zu erfüllen.
Während die Version 2.18 wesentliche funktionale Verbesserungen einführte – darunter die Automatisierung von Zertifikaten – konzentriert sich die im April 2026 veröffentlichte Version 2.19.x vor allem auf die betriebliche Stabilität.
Mit SCC v2.18 (März 2025) kamen erstmals die Unterstützung für Windows Server 2025, die automatische Erneuerung von Subaccount‑Zertifikaten sowie ein zentral verwalteter Truststore für LDAP‑ und E‑Mail‑Kommunikation hinzu.
Der SAP Security Patch Day im Juni 2025 brachte außerdem 14 neue Security Notes mit sich, die insbesondere Proxy‑ und Connectivity‑Komponenten betrafen. Im Rahmen der Root‑CA‑Migration im Juli 2025 wechselte Let’s Encrypt von Root X1 auf X2, was entsprechende Aktualisierungen der JVM‑Truststores erforderlich machte.
Für die DigiCert‑G5/G3‑Migration im Jahr 2026 wird empfohlen, Backend‑Truststores frühzeitig vorzubereiten, um Unterbrechungen zu vermeiden.
Ein weiterer Schwerpunkt liegt zunehmend auf der Principal Propagation, die mittlerweile sowohl für HTTP‑ als auch für RFC‑Szenarien unterstützt wird.
Parallel dazu zeigen Integrations‑Trends, dass Microsoft Fabric und andere Multi‑Cloud‑Plattformen immer häufiger auf etablierte Best Practices im SAP‑Connectivity‑Umfeld verweisen.
Wenn Sie Ihren SCC von einer rein funktionalen Komponente zu einem strategisch verwalteten Baustein weiterentwickeln wollen, brauchen Sie ein klares Governance-Framework.
Wir empfehlen Ihnen folgende Maßnahmen:
Sie möchten wissen, wie es um die Sicherheit Ihres SAP Cloud Connectors steht? Wir bei Xiting führen umfassende SCC-Security-Reviews durch und unterstützen Sie bei der Umsetzung. Als SAP Partner helfen wir Ihnen dabei, die Sicherheit Ihrer hybriden SAP-Landschaft mit dem SCC nachhaltig zu gewährleisten.
Melden Sie sich noch heute für ein kostenloses und unverbindliches Erstgespräch mit unseren SAP-Security-Experten und erfahren Sie, wie wir Ihre SAP-Systeme zukunftssicher gestalten können:
Wir empfehlen (Stand März 2026) Version 2.18 oder höher. Versionen unter 2.16 sollten Sie aufgrund von Abhängigkeiten zu Sicherheitshinweisen zeitnah aktualisieren.
Ja. Sie können Nicht-SAP-Backends über virtuelle Host-/Port-Zuordnungen und Destinationen sicher anbinden.
Das kurzlebige Benutzerzertifikat identifiziert den Endbenutzer. Das Systemzertifikat hingegen authentifiziert den SCC selbst gegenüber dem Backend und ist somit der eigentliche Vertrauensanker.
Aktivieren Sie die automatische Erneuerung, richten Sie Ablaufwarnungen ein, betreiben Sie redundante SCC-Nodes und halten Sie Ihre JVM-Trust-Stores aktuell.
Wir empfehlen SLS nur dann, wenn es durch Ihre PKI- oder HSM-Richtlinien vorgeschrieben ist. Für die meisten Anwendungsfälle ist die interne CA des SCC ausreichend und einfacher zu warten.
Der „HANA Cloud Connector“ ist der frühere Name des heutigen SAP Cloud Connectors, funktional handelt es sich um dasselbe Produkt. Die Umbenennung erfolgte 2017 im Zuge der Plattform-Evolution: Aus der SAP HANA Cloud Platform (HCP) wurde zunächst die SAP Cloud Platform (SCP) und schließlich die SAP Business Technology Platform (BTP).
Sie sehen gerade einen Platzhalterinhalt von Vimeo. Um auf den eigentlichen Inhalt zuzugreifen, klicken Sie auf die Schaltfläche unten. Bitte beachten Sie, dass dabei Daten an Drittanbieter weitergegeben werden.
Mehr InformationenSie sehen gerade einen Platzhalterinhalt von YouTube. Um auf den eigentlichen Inhalt zuzugreifen, klicken Sie auf die Schaltfläche unten. Bitte beachten Sie, dass dabei Daten an Drittanbieter weitergegeben werden.
Mehr InformationenSie müssen den Inhalt von reCAPTCHA laden, um das Formular abzuschicken. Bitte beachten Sie, dass dabei Daten mit Drittanbietern ausgetauscht werden.
Mehr InformationenSie sehen gerade einen Platzhalterinhalt von Facebook. Um auf den eigentlichen Inhalt zuzugreifen, klicken Sie auf die Schaltfläche unten. Bitte beachten Sie, dass dabei Daten an Drittanbieter weitergegeben werden.
Mehr InformationenSie müssen den Inhalt von hCaptcha - Formidable laden, um das Formular abzuschicken. Bitte beachten Sie, dass dabei Daten mit Drittanbietern ausgetauscht werden.
Mehr InformationenSie müssen den Inhalt von reCAPTCHA laden, um das Formular abzuschicken. Bitte beachten Sie, dass dabei Daten mit Drittanbietern ausgetauscht werden.
Mehr InformationenSie müssen den Inhalt von Turnstile laden, um das Formular abzuschicken. Bitte beachten Sie, dass dabei Daten mit Drittanbietern ausgetauscht werden.
Mehr InformationenSie sehen gerade einen Platzhalterinhalt von Hubspot Meetings. Um auf den eigentlichen Inhalt zuzugreifen, klicken Sie auf die Schaltfläche unten. Bitte beachten Sie, dass dabei Daten an Drittanbieter weitergegeben werden.
Mehr InformationenSie sehen gerade einen Platzhalterinhalt von Instagram. Um auf den eigentlichen Inhalt zuzugreifen, klicken Sie auf die Schaltfläche unten. Bitte beachten Sie, dass dabei Daten an Drittanbieter weitergegeben werden.
Mehr InformationenSie sehen gerade einen Platzhalterinhalt von X. Um auf den eigentlichen Inhalt zuzugreifen, klicken Sie auf die Schaltfläche unten. Bitte beachten Sie, dass dabei Daten an Drittanbieter weitergegeben werden.
Mehr Informationen
