Sicherheitsarchitektur des InterAct-Adapters
Die Sicherheit für die Übertragung und den Empfang von Nachrichten wird mithilfe des Zertifikats und der Krypto-Features implementiert, die SWIFTNet Link (SNL) und das SWIFTAlliance Gateway (SAG) inhärent sind. SWIFT empfiehlt, dass für InterAct konzipierte Dienste eine End-to-End-Signatur anwenden, d. h. zum Signieren von Anforderungs- und Antwortnachrichten.
Die kryptografischen Vorgänge werden durch das Sicherheitsmodul von SWIFTNet Link implementiert. Dieses Modul ermöglicht die Signatur und Verschlüsselung mithilfe von PKI-Schlüsseln. Art und Umfang von Kryptografievorgängen werden als Teil der Datenstrukturen der Anforderungs- und Antwortsteuerung angegeben, die an die APIs übergeben werden.
SWIFTNet unterstützt das Signieren/Verschlüsseln von RequestPayload oder ResponsePayload. Auch der RequestHeader oder ResponseHeader kann signiert werden.
Signieren/Verschlüsseln von Anforderungen und Antworten
Die Regeln für das Anwenden kryptografischer Vorgänge auf SWIFTNet InterAct Request-Elemente sind wie folgt:
RequestControl: Dies ist nur für SWIFTNet bestimmt. SWIFTNet stellt einen RequestDescriptor an den Antwortgeber (und einige Elemente auch an den Anforderer) bereit. Daher kann kein Kryptografievorgang für den Clientprozess zum Server ausgeführt werden.
RequestE2EControl: Dieses Element enthält Informationen, um zuverlässiges End-to-End-Messaging zu gewährleisten. Es kann kein kryptografischer Vorgang ausgeführt werden.
RequestHeader: Er wird von SWIFTNet verwendet und unverändert an den Responder übermittelt. Daher kann dies nur signiert werden.
RequestPayload: Hier können alle kryptografischen Vorgänge ausgeführt werden.
Kryptoelemente: Diese beziehen sich auf zuvor aktivierte kryptografische Vorgänge für diese Anforderung. Für diese können keine kryptografischen Vorgänge ausgeführt werden.
Die Regeln zum Anwenden kryptografischer Funktionen auf SWIFTNet InterAct-Antworten sind:
ResponseControl: Dies ist nur für SWIFTNet bestimmt. SWIFTNet stellt einen ResponseDescriptor an den Anforderer bereit. Daher kann kein Kryptografievorgang des Servers zum Clientprozess ausgeführt werden.
ResponseE2EControl: Dieses Element enthält Informationen, um zuverlässiges End-to-End-Messaging zu gewährleisten. Es kann kein kryptografischer Vorgang ausgeführt werden.
ResponseHeader: Dieses Element kann signiert werden (es wird unverändert an den Anforderer übertragen).
ResponsePayload: kann verschlüsselt und/oder signiert werden.
Kryptoelemente: Diese beziehen sich auf zuvor aktivierte kryptografische Vorgänge für diese Anforderung. Für diese können keine kryptografischen Vorgänge ausgeführt werden.
Empfangen von Anforderungen mit Kryptografie
Ein Serverprozess kann Anforderungen empfangen, die vom Anforderer kryptografischen Vorgängen unterzogen wurden. Die eingehende Anforderung enthält alle relevanten Informationen, um die umgekehrten kryptografischen Vorgänge zu aktivieren. Die CryptoInternal-Informationen sind so, dass die Entschlüsselungs- und Überprüfungsfunktion jetzt effektiv funktioniert.
Der Serverprozess muss die Sicherheitskontexte des DN aktivieren, für die die Entschlüsselung erfolgen muss.
Die Anforderung wird dann durch die umgekehrten kryptografischen Vorgänge (Überprüfen, Entschlüsseln) so geändert, dass die ursprüngliche Anforderung unverändert für den Serverprozess zur Verfügung gestellt wird, da sie ursprünglich vom Clientprozess an die kryptografischen Vorgänge übermittelt wurde. Für die Antwort erfolgt eine ähnliche Verarbeitung. Es ist wichtig zu beachten, dass die Überprüfung einer Signatur nicht nur überprüft, was signiert wurde, nicht geändert wurde, sondern dass sie authentifiziert, ob der Signaturgeber original ist. Dies erfordert, dass der SignDN ein gültiges Zertifikat verwendet. Ein gültiges Zertifikat ist ein Zertifikat, das nicht widerrufen wurde (eine Suche in der Zertifikatsperrliste, die zentral in SWIFTNet aufbewahrt wird).
Aktivierung
SWIFTNet Link kann die Überprüfung und Entschlüsselung im automatischen Modus für alle eingehenden Anforderungen und eingehenden Antworten ausführen. Dies bedeutet, dass SWIFTNet Link den letzten Kryptoblock aller eingehenden Anforderungen (serverseitig) oder eingehenden Antworten (Clientseite) automatisch verarbeitet (überprüft und entschlüsselt). Voraussetzung ist, dass der für die Entschlüsselung erforderliche Sicherheitskontext geöffnet wird (wenn die Entschlüsselung angefordert wird) und dass SWIFTNet Link im automatischen Modus initialisiert wurde (diese Einstellung für den automatischen Modus erfolgt auf sw:InitRequest oder Sw:HandleInitResponse, indem der CryptoMode auf "Automatisch" oder besser noch "Erweitert" für InterAct festgelegt wird. (Wir verwenden immer "Erweitert" für den InterAct-Adapter, da dies dem Client oder der Serveranwendung ermöglicht, eine unerwartete Verschlüsselung durch die Remoteseite oder ein abgelaufenes Zertifikat wiederherzustellen.
SWIFTNet Link betreibt die Signatur und Verschlüsselung automatisch für eine ausgehende Anforderung (oder eine ausgehende Antwort), wenn das Feld RequestCrypto (ResponseCrypto) im RequestControl (ResponseControl) der Anforderung (Response) auf "TRUE" initialisiert wird.
In diesem Fall verarbeitet SWIFTNet Link den letzten Kryptoblock. Voraussetzung ist, dass der für die Signatur erforderliche Sicherheitskontext (wenn die Signatur angefordert wird) geöffnet wird, dass der Kryptoblock in der Anforderung vorhanden ist, wobei die Signatur und Verschlüsselung erforderlich ist, und dass das RequestCrypto-Flag (ResponseCrypto) im RequestControl (ResponseControl) auf "TRUE" festgelegt ist. Dies geschieht immer, unabhängig vom CryptoMode, der bei der Initialisierung des Clients oder Servers verwendet wird.
Weitere Informationen
Architektur des InterAct-Adapters
Komponenten des InterAct-Adapters
InterAct-Adapter – Nachrichtentypen für Geschäftsnachrichtenaustausch
InterAct-Adapter – Clientanwendung
InterAct-Adapter – Serveranwendung
InterAct-Adapter – Speicher- und Weiterleitungsmodus
InterAct-Adapter – Sicherstellen einer zuverlässigen End-to-End-Übermittlung
InterAct-Adapter – Statusüberwachung
InterAct-Adapter – Nichtabstreitbarkeit