Bei einer Host-to-Host-Bankverbindung erfolgt die Authentifizierung in der Regel über kryptografische Zertifikate, die zwischen dem Unternehmenssystem und dem Bankserver ausgetauscht werden. Der Prozess basiert auf dem gegenseitigen Nachweis der Identität beider Kommunikationspartner, bevor Zahlungsdateien übertragen werden. Die folgenden Abschnitte erläutern die gängigen Verfahren, typische Unterschiede zu anderen Protokollen und die Absicherung im SAP-Umfeld.

Welche Authentifizierungsverfahren werden bei H2H-Verbindungen eingesetzt?

Bei einer Host-to-Host-Bankverbindung werden überwiegend zertifikatsbasierte Verfahren eingesetzt, bei denen beide Kommunikationspartner ihre Identität durch digitale Zertifikate nachweisen. Die gängigsten Methoden sind TLS-Mutual-Authentication (mTLS), SSH-Schlüsselpaare sowie bankspezifische API-Schlüssel in Kombination mit Tokenmechanismen. Welches Verfahren zum Einsatz kommt, legt in der Regel die jeweilige Bank vertraglich fest.

Das am häufigsten eingesetzte Verfahren ist die gegenseitige TLS-Authentifizierung. Dabei präsentiert nicht nur der Bankserver ein Serverzertifikat, sondern auch das Unternehmenssystem ein Client-Zertifikat. Die Bank prüft dieses Zertifikat gegen eine vorab hinterlegte Whitelist zugelassener Zertifikate. Erst nach erfolgreicher gegenseitiger Prüfung wird die verschlüsselte Verbindung aufgebaut.

Bei dateibasierten H2H-Verbindungen über SFTP kommt häufig die SSH-Authentifizierung zum Einsatz. Hier erzeugt das Unternehmen ein RSA- oder ECDSA-Schlüsselpaar, dessen öffentlicher Schlüssel bei der Bank registriert wird. Der private Schlüssel verbleibt im Unternehmenssystem und wird bei jeder Verbindung zur Signatur verwendet.

Neuere H2H-Verbindungen, insbesondere solche auf API-Basis, kombinieren Zertifikate mit OAuth-2.0-Tokens oder statischen API-Schlüsseln. Dabei dient das Zertifikat der Transportverschlüsselung und Identitätsprüfung, während der Token die Autorisierung für bestimmte Aktionen steuert. Diese Schichtung erhöht die Sicherheit, erfordert aber eine sorgfältige Verwaltung beider Komponenten.

Was ist der Unterschied zwischen H2H- und EBICS-Authentifizierung?

Der wesentliche Unterschied liegt im Standardisierungsgrad: EBICS ist ein klar normiertes Protokoll mit definierten Authentifizierungsschichten, während H2H eine individuelle, bilateral zwischen Unternehmen und Bank vereinbarte Verbindung ist. EBICS schreibt elektronische Signaturen auf Nachrichtenebene vor; H2H verlässt sich primär auf die Transportschicht.

Bei EBICS werden drei kryptografische Schlüssel unterschieden: der Authentifizierungsschlüssel, der Verschlüsselungsschlüssel und der elektronische Unterschriftsschlüssel. Jede EBICS-Nachricht wird auf Anwendungsebene signiert, sodass die Integrität und Herkunft unabhängig vom Transportkanal nachgewiesen werden kann. Dieses Prinzip ist im EBICS-Standard verbindlich festgelegt und gilt für alle teilnehmenden Banken gleichermaßen.

H2H-Verbindungen hingegen sind nicht durch einen übergreifenden Standard geregelt. Jede Bank definiert eigene Anforderungen an Zertifikatsformate, Schlüssellängen, Verbindungsprotokolle und Authentifizierungsabläufe. Das bedeutet für Unternehmen, die mit mehreren Banken über H2H kommunizieren, einen erhöhten Konfigurationsaufwand, da jede Verbindung individuell eingerichtet und gepflegt werden muss. Lösungen wie SAP Multi-Bank Connectivity adressieren genau diese Komplexität durch eine zentrale Verwaltungsschicht.

Wie werden Zertifikate bei einer H2H-Bankverbindung ausgetauscht?

Der Zertifikatsaustausch bei einer H2H-Bankverbindung erfolgt in einem strukturierten Onboarding-Prozess: Das Unternehmen erzeugt ein Schlüsselpaar, übermittelt das Client-Zertifikat an die Bank, und die Bank hinterlegt es auf ihrer Seite. Gleichzeitig stellt die Bank ihr Serverzertifikat bereit, das im Unternehmenssystem als vertrauenswürdig eingetragen wird.

In der Praxis läuft dieser Prozess in mehreren Schritten ab:

1. Schlüsselerzeugung: Das Unternehmen generiert ein Schlüsselpaar, typischerweise RSA mit mindestens 2048 Bit oder ECDSA, entweder im eigenen System oder in einem Hardware-Security-Modul (HSM).
2. Zertifikatsantrag: Aus dem öffentlichen Schlüssel wird ein Certificate Signing Request (CSR) erstellt und an eine Zertifizierungsstelle oder direkt an die Bank übermittelt.
3. Registrierung bei der Bank: Die Bank trägt das Client-Zertifikat in ihre Whitelist ein und bestätigt die Registrierung schriftlich oder über ein Bankportal.
4. Hinterlegung des Bankzertifikats: Das Serverzertifikat der Bank wird im Trust Store des Unternehmenssystems eingetragen, damit die Bank-Gegenstelle beim Verbindungsaufbau als vertrauenswürdig erkannt wird.
5. Verbindungstest: Vor dem Produktivbetrieb wird die Verbindung in einer Testumgebung geprüft, um sicherzustellen, dass Authentifizierung und Dateiübertragung korrekt funktionieren.

Dieser Prozess kann je nach Bank mehrere Wochen in Anspruch nehmen, da manuelle Prüf- und Freigabeschritte auf Bankseite üblich sind. Eine frühzeitige Abstimmung mit dem zuständigen Bankbetreuer ist daher empfehlenswert.

Was passiert, wenn ein Zertifikat bei H2H abläuft oder kompromittiert wird?

Läuft ein Zertifikat bei einer H2H-Bankverbindung ab oder wird es als kompromittiert eingestuft, schlägt die Authentifizierung fehl und Zahlungsübertragungen werden unterbrochen. Im Falle eines abgelaufenen Zertifikats muss ein neues Zertifikat erzeugt, bei der Bank registriert und im eigenen System hinterlegt werden, bevor der Betrieb wieder aufgenommen werden kann.

Ein ablaufendes Zertifikat ist der häufigere Fall und grundsätzlich planbar. Zertifikate haben eine definierte Laufzeit, die je nach Ausstellungsart zwischen einem und drei Jahren beträgt. Unternehmen sollten einen internen Prozess etablieren, der die Ablaufdaten aller H2H-Zertifikate überwacht und den Erneuerungsprozess rechtzeitig anstößt. Erfahrungsgemäß sollte die Erneuerung mindestens vier bis sechs Wochen vor Ablauf eingeleitet werden, um Bearbeitungszeiten auf Bankseite einzuplanen.

Ein kompromittiertes Zertifikat erfordert sofortiges Handeln. In diesem Fall muss das betroffene Zertifikat unverzüglich bei der Bank gesperrt und durch ein neu erzeugtes Zertifikat ersetzt werden. Gleichzeitig sollte geprüft werden, ob der private Schlüssel tatsächlich in fremde Hände gelangt ist und ob weitere Systeme oder Verbindungen betroffen sein könnten. Die Nutzung eines HSM reduziert das Risiko einer Kompromittierung erheblich, da der private Schlüssel das Hardwaremodul nie verlässt.

In beiden Szenarien ist eine lückenlose Dokumentation des Zertifikatslebenszyklus unerlässlich, um im Ernstfall schnell reagieren zu können und revisionssichere Nachweise zu erbringen.

Wie sichert SAP die Authentifizierung in H2H-Zahlungsprozessen ab?

SAP sichert die Authentifizierung in H2H-Zahlungsprozessen über den SAP Trust Manager sowie die Zertifikatsverwaltung im SAP NetWeaver-Stack ab. Zertifikate werden zentral im System Certificate Store hinterlegt, und die Verbindungskonfiguration erfolgt über den SAP Transaction Manager oder die Konfigurationsoberflächen von SAP S/4HANA Treasury.

Im Kontext von SAP Multi-Bank Connectivity übernimmt die cloudbasierte Plattform die Verwaltung der Bankverbindungen und deren Sicherheitskonfiguration. Zertifikate für H2H-Verbindungen werden dort zentral gepflegt, und die Kommunikation zwischen dem SAP-System und der Bankplattform ist durchgängig verschlüsselt. Das reduziert den administrativen Aufwand erheblich, da Zertifikatserneuerungen und Verbindungskonfigurationen an einem einzigen Ort vorgenommen werden.

Darüber hinaus greift SAP Bank Communication Management (BCM) als vorgelagerter Prozessschritt: Zahlungsaufträge durchlaufen einen definierten, revisionssicheren Freigabeprozess, bevor sie an die Bankschnittstelle übergeben werden. So wird sichergestellt, dass nur autorisierte Zahlungen die H2H-Verbindung erreichen. Die Kombination aus Prozessautorisierung auf Anwendungsebene und kryptografischer Authentifizierung auf Transportebene bildet eine robuste Sicherheitsarchitektur für den elektronischen Zahlungsverkehr.

Für Unternehmen, die mehrere H2H-Verbindungen parallel betreiben, empfiehlt sich zudem eine zentrale Überwachung der Verbindungsstatus und Zertifikatsablaufdaten, die in SAP-Systemen über entsprechende Monitoring-Werkzeuge abgebildet werden kann. Weitere Informationen zu den verfügbaren Erweiterungspaketen für die Zahlungsverkehrsanbindung finden Sie auf den entsprechenden Seiten.

Wie PAYMENTS.CC Sie bei der H2H-Authentifizierung unterstützt

Die Einrichtung und der sichere Betrieb einer Host-to-Host-Bankverbindung erfordern technisches Know-how, bankspezifisches Prozesswissen und eine sorgfältige Konfiguration im SAP-Umfeld. Genau hier setzen wir an. PAYMENTS.CC begleitet Sie mit langjähriger Projekterfahrung aus mehr als 30 nationalen und internationalen Implementierungen durch alle Phasen Ihrer H2H-Anbindung.

Unsere Leistungen im Bereich H2H-Authentifizierung und Bankenkommunikation umfassen unter anderem:

• Analyse und Konzeption: Wir prüfen Ihre bestehende Systemlandschaft und erarbeiten gemeinsam mit Ihnen ein Sicherheitskonzept für Ihre H2H-Verbindungen.
• Technische Implementierung: Wir richten Zertifikate, Trust Stores und Verbindungsparameter in Ihrem SAP-System ein und koordinieren den Onboarding-Prozess mit Ihren Bankpartnern.
• SAP Multi-Bank Connectivity: Wir implementieren und konfigurieren SAP MBC als zentrale Plattform für alle Ihre Bankverbindungen, inklusive H2H, EBICS und SWIFT.
• Zertifikatsmanagement und Monitoring: Wir unterstützen Sie beim Aufbau eines strukturierten Prozesses zur Überwachung und rechtzeitigen Erneuerung Ihrer Zertifikate.
• Schulung und Wissenstransfer: Wir befähigen Ihr Team, die Verbindungen eigenständig zu betreiben und im Fehlerfall schnell zu reagieren.

Sprechen Sie uns gerne an. Unser erfahrenes Team steht Ihnen schnell, kompetent und lösungsorientiert zur Verfügung. Nehmen Sie Kontakt auf und erfahren Sie, wie wir Ihre H2H-Bankverbindung sicher und revisionssicher gestalten können.

Ähnliche Artikel

• Was kostet die Umstellung auf EBICS im SAP-Umfeld wirklich?
• Was bedeutet die Abschaltung der SWIFT MT-Nachrichten für Unternehmen?
• Was ist EBICS und wie funktioniert es im SAP-Zahlungsverkehr?
• Wie verändert ISO 20022 die Multi-Bank-Connectivity in SAP?
• Was ist SAP Multi-Bank Connectivity und wie funktioniert es?

Dieser Inhalt wurde mithilfe von KI erstellt und kann Fehler enthalten.