Kann es vorkommen, dass ein Zahlungsverkehrsauftrag, der in EBICS
eigentlich von zwei unterschiedlichen Personen autorisiert werden muss,
doch nur von einer Person freigegeben wird? Ja, unter bestimmten
Umständen ist das möglich. Bei manchen Vertragskonstellationen zwischen
dem Kreditinstitut und dem Firmenkunden lässt sich die handelnde Person
nicht eindeutig identifizieren.

Die Falle steckt im EBICS-Datenmodell
Das Berechtigungsmodell des Firmenkunden für die EBICS-Kommunikation orientiert sich am Datenmodell von EBICS. Dieses unterscheidet zwischen dem Kunden und seinem Mitarbeiter als EBICS-Teilnehmer.
Firmenkunden kommunizieren per EBICS mit ihrer Bank über eine unternehmensweit gültige EBICS-Kunden-ID und die Teilnehmer-ID des handelnden Mitarbeiters. Die IDs vergibt die Bank bei der Einrichtung für den Kunden und seinen Mitarbeiter; der Kunde benötigt sie für die Verbindung zum Bankrechner in den Zugängen der EBICS-Clients. Nun ist eben diese Teilnehmer-ID nicht immer eindeutig. Wie kann das sein?
Firmenkunden nutzen verschiedene EBICS-Clients
Größere Firmenkunden setzen auch mal mehrere EBICS-Clients unterschiedlicher Hersteller ein. Dabei nutzt ein Mitarbeiter je nach Funktionsumfang auch verschiedene Clients parallel. Ein Beispiel ist der Mitarbeiter, der mit einem EBICS-PC-Produkt Zahlungen autorisiert und einreicht – und der gleichzeitig Zahlungen, die aus seiner ERP-Lösung für die in Deutschland übliche Verteilte Elektronische Unterschrift direkt zur Bank gesendet worden sind, per EBICS-Mobile-Lösung autorisiert.
Schlüssel und Zertifikate sind häufig nicht wiederverwendbar
Da die teilnehmerbezogenen Schlüssel bzw. Zertifikate je nach Kundensystem und EBICS-Land unterschiedlich abgelegt sind, kann ein Mitarbeiter sie in den meisten Fällen nicht für alle EBICS-Clients übergreifend nutzen. Sprich, das EBICS-PC-Produkt und die EBICS-Mobile-Lösung erfordern jeweils eigene Schlüssel für den Teilnehmer. Daher hat der Mitarbeiter für seinen EBICS-Zugang zur Bank in jedem Client eine andere Teilnehmer-ID, die dann die Verbindung zu seinen jeweiligen Schlüsseln bzw. Zertifikaten sicherstellt.
Da das Datenmodell von EBICS aber den EBICS-Teilnehmer als eindeutige handelnde Person definiert, kann theoretisch eine Person mit mehreren Teilnehmer-IDs Zahlungen freigeben, die eigentlich von mehreren Personen autorisiert werden müssen. Im EBICS-Datenmodell ist die Zuordnung einer Person zu mehreren Teilnehmer-IDs nicht vorgesehen.
Um einen derartigen Missbrauch zu verhindern verfügen EBICS-Bankrechner mittlerweile über zusätzliche individuelle Berechtigungsfunktionen, dennoch ist eine einheitliche Lösung im EBICS-Standard selbst wünschenswert.
Einheitliches Austauschformat für Schlüssel und Zertifikate
Eine Möglichkeit wäre es z. B., im EBICS-Standard das Austauschformat bzw. die Ablage der Schlüssel und Zertifikate einheitlich vorzuschreiben, z. B. einen Software-Token mit der Ablage im PKCS12-Format. In diesem Fall ist die Teilnehmer-ID eindeutig nutzbar, um die handelnde Person zu identifizieren. Schlüssel und Zertifikate können somit in Verbindung mit der Teilnehmer-ID auf mehreren Clients genutzt werden.
Michael Lembcke
Die Falle steckt im EBICS-Datenmodell
Das Berechtigungsmodell des Firmenkunden für die EBICS-Kommunikation orientiert sich am Datenmodell von EBICS. Dieses unterscheidet zwischen dem Kunden und seinem Mitarbeiter als EBICS-Teilnehmer.
Firmenkunden kommunizieren per EBICS mit ihrer Bank über eine unternehmensweit gültige EBICS-Kunden-ID und die Teilnehmer-ID des handelnden Mitarbeiters. Die IDs vergibt die Bank bei der Einrichtung für den Kunden und seinen Mitarbeiter; der Kunde benötigt sie für die Verbindung zum Bankrechner in den Zugängen der EBICS-Clients. Nun ist eben diese Teilnehmer-ID nicht immer eindeutig. Wie kann das sein?
Firmenkunden nutzen verschiedene EBICS-Clients
Größere Firmenkunden setzen auch mal mehrere EBICS-Clients unterschiedlicher Hersteller ein. Dabei nutzt ein Mitarbeiter je nach Funktionsumfang auch verschiedene Clients parallel. Ein Beispiel ist der Mitarbeiter, der mit einem EBICS-PC-Produkt Zahlungen autorisiert und einreicht – und der gleichzeitig Zahlungen, die aus seiner ERP-Lösung für die in Deutschland übliche Verteilte Elektronische Unterschrift direkt zur Bank gesendet worden sind, per EBICS-Mobile-Lösung autorisiert.
Schlüssel und Zertifikate sind häufig nicht wiederverwendbar
Da die teilnehmerbezogenen Schlüssel bzw. Zertifikate je nach Kundensystem und EBICS-Land unterschiedlich abgelegt sind, kann ein Mitarbeiter sie in den meisten Fällen nicht für alle EBICS-Clients übergreifend nutzen. Sprich, das EBICS-PC-Produkt und die EBICS-Mobile-Lösung erfordern jeweils eigene Schlüssel für den Teilnehmer. Daher hat der Mitarbeiter für seinen EBICS-Zugang zur Bank in jedem Client eine andere Teilnehmer-ID, die dann die Verbindung zu seinen jeweiligen Schlüsseln bzw. Zertifikaten sicherstellt.
Da das Datenmodell von EBICS aber den EBICS-Teilnehmer als eindeutige handelnde Person definiert, kann theoretisch eine Person mit mehreren Teilnehmer-IDs Zahlungen freigeben, die eigentlich von mehreren Personen autorisiert werden müssen. Im EBICS-Datenmodell ist die Zuordnung einer Person zu mehreren Teilnehmer-IDs nicht vorgesehen.
Um einen derartigen Missbrauch zu verhindern verfügen EBICS-Bankrechner mittlerweile über zusätzliche individuelle Berechtigungsfunktionen, dennoch ist eine einheitliche Lösung im EBICS-Standard selbst wünschenswert.
Einheitliches Austauschformat für Schlüssel und Zertifikate
Eine Möglichkeit wäre es z. B., im EBICS-Standard das Austauschformat bzw. die Ablage der Schlüssel und Zertifikate einheitlich vorzuschreiben, z. B. einen Software-Token mit der Ablage im PKCS12-Format. In diesem Fall ist die Teilnehmer-ID eindeutig nutzbar, um die handelnde Person zu identifizieren. Schlüssel und Zertifikate können somit in Verbindung mit der Teilnehmer-ID auf mehreren Clients genutzt werden.
Michael Lembcke