Scope und Architekturtypen nach CSCF v2027: was in die Attestierung gehört

Problem in der Praxis

Der Scope wird häufig an der klassischen Schnittstelle festgemacht und übersieht neuere Wege: selbst entwickelte API-Anbindungen, Middleware oder Dateitransfer zu einem Dienstleister, Client-Anwendungen beim Nutzer, Schlüssel- und Geheimnisspeicher. Auch Co-Hosting zieht unbemerkt Systeme in den Scope, etwa wenn eine andere Anwendung auf derselben virtuellen Maschine läuft oder dieselben Zugangsdaten nutzt.

CISO-Einordnung

Was im Scope liegt (CSCF v2027, S. 11 bis 14):

• die Swift-Infrastruktur des Nutzers, ob vor Ort oder fremd betrieben: Secure Zone, Messaging- und Communication-Interface, SwiftNet Link, Swift-Connector, Hardware-Sicherheitsmodule, Netzgeräte, grafische Oberflächen;
• Customer-Connectoren ohne Swift-Software, darunter Middleware, Dateitransfer und selbst entwickelte Anwendungen, die Swift-Schnittstellen nutzen, um Zahlungsaufträge eigenständig zu übertragen; Client-Connectoren sind nach v2027 seit v2026 für mehrere Kontrollen verpflichtend im Scope;
• Operatoren und ihre Rechner, als allgemeine Arbeitsplatzrechner oder als dedizierte Rechner in der Secure Zone;
• der Datenaustausch mit dem ersten Back-Office-System, direkt oder über Bridging-Server;
• neu in v2027 ausdrücklich: die künftige virtuelle VPN-Option von Alliance Connect beim Kunden und Schlüssel- und Geheimnisspeicher (Secrets and Keys Vault).

Herausnahme: Eine Komponente fällt nur heraus, wenn sie keine Zahlungsaufträge verwalten oder übertragen kann, keine Schnittstelle mit Geschäftssignatur enthält und keine Zugangsdaten mit solchen Berechtigungen nutzt, alle drei Bedingungen zugleich, fortlaufend durch Scope-Analyse und Risikobewertung bestätigt (S. 14).

Test- und Entwicklungssysteme: Testsysteme liegen nur außerhalb, wenn sie vollständig von der Produktion getrennt sind, einschließlich eigener HSM, und so konfiguriert sind, dass sie nur Testverkehr unterstützen; sind sie nicht vollständig getrennt oder lassen sie sich für Liveverkehr konfigurieren, gehören sie mit denselben Kontrollen wie die Produktion in den Scope; Entwicklungssysteme gehören nicht in die Secure Zone und liegen außerhalb (S. 15).

Außerhalb des Scopes: Back-Office-Systeme, solange sie weder mit einer Swift-bezogenen Komponente im Scope co-gehostet sind noch in der Secure Zone liegen (S. 15 und 117), die allgemeine Unternehmens-IT und die Leitungen der Netzpartner; die Alliance-Connect-Geräte unterliegen aber der Kontrolle zur physischen Sicherheit (S. 16). Swift empfiehlt ausdrücklich, auch Back-Office und Unternehmens-IT nach einem Sicherheitsrahmen zu schützen.

Die fünf Architekturtypen (S. 20 bis 25):

• A1: Der Nutzer besitzt das Communication Interface (meist auch das Messaging Interface).
• A2: Der Nutzer besitzt das Messaging Interface, das Communication Interface liegt bei einem Dienstleister, einem Group Hub oder bei Swift.
• A3: Ein Swift-Connector beim Nutzer, ohne eigenes Interface.
• A4: Ein Customer-Connector ohne Swift-Software, etwa Middleware, Dateitransfer oder eine eigene API-Anwendung.
• B: Keine Swift-spezifische Infrastrukturkomponente beim Nutzer; erfasst sind die rein interaktive Nutzung einer Anwendung bei einem Swift-Dienstleister, einem Group Hub oder bei Swift sowie eine Infrastruktur, deren Customer-Connector nach den Herausnahmebedingungen formal keine Komponente im Scope hat. Die Rechner, mit denen Zahlungsaufträge erteilt oder beeinflusst werden, bleiben als allgemeine Operator-Rechner zu schützen. Wer nur interaktiv eine Anwendung eines Outsourcing-Partners nutzt, wählt nach v2027 A4, nicht B, und stützt sich auf dessen Ergebnisse.

Für A1, A2 und A3 gelten dieselben Kontrollen, mit Ausnahme der Datenbankintegrität, die für A3 entfällt; für A4 und B gelten weniger (S. 26). Nach den Kontrollköpfen in v2027 (S. 29 bis 101; eigene Auszählung):

• Nur für A1 bis A3: 1.1 (Schutz der Swift-Umgebung), 2.1 (interne Datenflüsse) und 2.10 (Anwendungshärtung). Für A4 tritt an die Stelle von 1.1 die Kontrolle 1.5 (Schutz der Kundenumgebung), die nur für A4 gilt.
• Nicht für B: 2.4 (Back-Office-Datenflüsse), 6.2 (Softwareintegrität), 6.3 (Datenbankintegrität, außerdem nicht für A3) sowie die Empfehlungen 2.5A und 6.5A.
• Für A4 nur Empfehlung: 6.2 und 6.3. Für B nur Empfehlung: 1.2 (privilegierte Betriebssystemkonten), 1.3 (Virtualisierung und Cloud) und 2.7 (Schwachstellenscans).
• Damit sind von den 26 Pflichtkontrollen für A1 und A2 je 25 verpflichtend, für A3 24, für A4 21 und für B 16.

Umsetzungsperspektive

• Komponenteninventar aller Zahlungswege zu Swift aufbauen, einschließlich API- und Middleware-Anbindungen.
• Architekturtyp mit dem Entscheidungsbaum von Swift bestimmen und den umfassendsten wählen.
• Co-Hosting und gemeinsam genutzte Zugangsdaten gezielt suchen.
• Herausnahmen nur mit dokumentierter Prüfung aller drei Bedingungen.
• Backup- und Notfallumgebungen gleich behandeln wie die Produktion.

Typische Fehler

1. Eigene API-Anbindungen oder Middleware werden nicht als Customer-Connector erkannt.
2. Ein zu enger Architekturtyp wird gewählt, weil er weniger Kontrollen auslöst.
3. Testsysteme, die nicht vollständig getrennt sind oder sich für Liveverkehr konfigurieren lassen, werden als außerhalb behandelt.
4. Co-gehostete Anwendungen auf derselben virtuellen Maschine bleiben unerkannt.
5. Die Disaster-Recovery-Umgebung fehlt in der Attestierung.

Risiken und Trade-offs

Ein eng gezogener Scope senkt den Aufwand, verlagert aber das Risiko in ungeschützte Wege und hält einer unabhängigen Bewertung womöglich nicht stand. Eine Customer Secure Zone für Connectoren ist zusätzlicher Aufwand; wer bereits eine Swift Secure Zone hat, kann den Connector dort unterbringen (S. 13).

Entscheidungspunkte

• Welcher Architekturtyp ist der umfassendste, der auf uns zutrifft?
• Welche Anwendungen übertragen Zahlungsaufträge eigenständig über Swift-Schnittstellen?
• Welche Komponenten wollen wir herausnehmen, und tragen alle drei Bedingungen?
• Wie trennen wir Testsysteme sauber von der Produktion?

Praktische Empfehlungen

1. Inventarisieren Sie jeden Zahlungsweg zu Swift, nicht nur die klassische Schnittstelle.
2. Wählen Sie im Zweifel den umfassenderen Architekturtyp.
3. Dokumentieren Sie jede Herausnahme mit allen drei Bedingungen und überprüfen Sie sie laufend.
4. Trennen Sie Test und Produktion einschließlich HSM vollständig.
5. Nehmen Sie Backup und Disaster Recovery in jede Attestierung auf.

Relevante Normreferenzen

• Swift, Customer Security Controls Framework v2027 (10.07.2026), Scope of Security Controls, Architecture Types, Security Controls Summary Table und Kontrollköpfe der Detailed Control Descriptions, Anhang zu Diensten und Komponenten je Architekturtyp.