EBICS und VEU: Schwächen bei Gehaltszahlungen mit vertraulichen Informationen

Die Verteilte Elektronische Unterschrift (VEU) ist seit vielen Jahren eine wichtige Funktion, um Zahlungen von unterschiedlichen Personen selbst an unterschiedlichen Orten einreichen und freizeichnen zu lassen.

Die im EBICS-Protokoll dafür vorgesehenen Auftragsarten und deren fachlicher Inhalt erlauben eine Freigabe auf Basis der Gesamtdatenlage – über den Dateibegleitbeleg – oder gar auf Basis der inhaltlichen Zahlungsdaten. Dafür liefern EBICS-Server die wichtigsten Informationen für jede der enthaltenen Einzelzahlungen bereits in aufbereiteter Form. Ein Kundensystem, das diese Daten anzeigen soll, muss dazu nicht mal das konkrete Zahlungsformat kennen. Das macht die Software so komfortabel. Ausnahmsweise lässt sich sogar eine komplette Zahlungsdatei übermitteln. Doch gerade bei großen Sammelzahlungen stellt das den gerade beschriebenen Komfort wieder in Frage.

In der Zahlungsverkehrspraxis kommen nicht nur einfache Zahlungen und Lastschriften in die VEU-Mappe, sondern auch Sonderzahlungen mit sehr persönlichen Daten, die besonders zu schützen wären. Dazu gehören etwa Pensionszahlungen, Gehaltszahlungen sowie Bonuszahlungen und Gratifikationen, die nicht für die Allgemeinheit und erst recht nicht für die Einsichtnahme durch die Belegschaft eines Unternehmens bestimmt sind.

Genau an dieser Stelle wird eine Schwäche der EBICS-Spezifikation deutlich: der GVC oder PurposeCode, der festlegt, um was für eine Art Zahlung es sich handelt, fehlt, wenn die Einzelzahlungen übertragen werden. Die von Kunden eingesetzten EBICS-Produkte sind deshalb gar nicht in der Lage, selbst wenn die Unternehmen das wollten, vertrauliche Daten in einem Zahlungsauftrag zu schützen. Der Software fehlt das Kriterium, um zu entscheiden, ob Zahlungsdetails angezeigt oder ausgeblendet werden müssen.

Ohne eine Kennung im konkreten Zahlauftrag ist es nicht möglich, vertrauliche von normalen Zahlungen zu unterscheiden. Damit ist die VEU im Prinzip ungeeignet, um etwa Gehaltszahlungen zu prüfen und per VEU freizugeben, weil nicht auszuschließen ist, dass nicht berechtigte Mitarbeiter einen Blick auf die möglicherweise vertraulichen Informationen werfen.

Die EBICS-Gesellschaft sollte sich deshalb beim XML für den HVT eine Erweiterung überlegen, mit der künftig auch diese wichtigen Informationen für die Art der Zahlung übermittelt werden. Solange dies nicht geschieht, lässt sich die VEU für Gehaltszahlungen nur eingeschränkt nutzen.

Autor: Michael Schunk

Weiterlesen

Wie sich EBICS verbessern lässt Teil 10 – Gezielte EBICS-Downloads mit Datum und Uhrzeit

Im Zahlungsverkehr und insbesondere mit der Einführung neuer Verfahren, wie etwa den Instant Payments, wird es für den Bankenkunden immer wichtiger, auch untertägig über die Zahlungsbewegungen auf dem Laufenden gehalten zu werden. Diese Entwicklung stellt im Firmenkundengeschäft auch den EBICS-Standard vor neue Herausforderungen zumal diese Informationen üblicherweise von den EBICS-Kunden aktiv vom Bankrechner abgerufen werden müssen. Insbesondere, wenn Firmenkunden mehrere EBICS-Clients nutzen, ist die heute gängige sog. historische Abholung mit Datumsangabe die geeignete Download-Methode. Da jedoch die historische Abholung durch EBICS lediglich tagesgenau spezifiziert ist, werden die Daten in der Praxis untertägig in großem Umfang mehrfach abgeholt. Zudem hängen fachliche Zeitstempel für EBICS vom Bereitstellungsformat ab und sind damit bestenfalls tagesgenau und schlimmstenfalls auf dem Bankrechner einfach nicht vorhanden. Den abholenden Clients steht daher dann die Aufgabe zu, die redundant abgeholten Daten automatisiert zu filtern. Dieses Verhalten führt derzeit zu einer deutlichen Mehrbelastung aller beteiligten Systeme sowohl auf Seiten der Kunden, als auch auf Seiten der Banken.

Folgende Verbesserung in EBICS könnte bei entsprechender Spezifikation Abhilfe schaffen und gezielte zeitgesteuerte Abholungen erlauben.

Sinnvoll wäre es, wenn der EBICS-Server per Spezifikation eine zusätzliche Variante der historischen Abholung unterstützen würde. Im Gegensatz zur bisherigen standardisierten historischen EBICS-Abholung würde nun bei Start- und Endzeitpunkt jeweils auch die Uhrzeit berücksichtigt. Außerdem sollten sich die angegebenen Zeitpunkte immer auf den Bereitstellungszeitpunkt beziehen. Damit könnte dann der EBICS-Server alle Datensätze liefern, die innerhalb des angegebenen Zeitraums bereitgestellt wurden. Zur flexibleren Handhabung sollte es auch zulässig sein, bei Abholanfragen nur jeweils einen der beiden Zeitpunkte anzugeben. Ansonsten verhält sich die Abholung auch hinsichtlich der Quittungsphase wie die bisherige Standardabholung.

Ich denke, eine solche Lösung einheitlich für alle EBICS Nutzer im EBICS-Standard zu spezifizieren, könnte den Abholprozess für EBICS verfeinern, die Rechnerauslastung reduzieren und insbesondere im Hinblick auf die wachsende Bedeutung von Aktualität deutlich verbessern. Bisher bereits eingesetzte proprietäre Lösungen in den EBICS-Produkten wären überflüssig.

Michael Lembcke

Weiterlesen

Serverseitige Erneuerung der EBICS-Zertifikate

Was die französische Version des EBICS-Protokolls anbelangt, so wurden die EBICS-Server überwiegend Ende 2009 sowie im Laufe des Jahres 2010 in Betrieb genommen. Viele von ihnen verwenden selbstsignierte X.509-Zertifikate mit einer Laufzeit von fünf Jahren, weshalb einige Institute bereits mit deren Erneuerung begonnen haben bzw. sich andere darauf vorbereiten.



Auf Kundenseite sieht das EBICS-Protokoll bei der Zertifikatserneuerung entsprechende EBICS-Nachrichten (PUB-, HCA- und HCS-Nachrichten) mit einer entsprechenden client- und serverseitigen Verarbeitung vor, so dass manuelle Eingriffe prinzipiell entfallen (signierte Nachrichten, die keiner zusätzlichen Validierung bedürfen). Bei der serverseitigen Erneuerung der Bankzertifikate verhält es sich jedoch anders: Lediglich die HPB-Nachricht ist dafür derzeit in EBICS verfügbar. Die Validierung der Bankzertifikate umfasst einen manuellen Schritt, nämlich den Abgleich des entsprechenden Hash-Werts. Ein weiterer beträchtlicher Unterschied liegt in der Tragweite des Vorgangs, der sich auf mehrere Tausend Kundenzugänge gleichzeitig auswirken kann.

Um diesen Eingriff im Umgang mit Zertifikaten in EBICS zu erleichtern, sind eine Reihe von Vorkehrungen und Vorsichtsmaßnahmen erforderlich.

Aus unseren Erfahrungen in der Entwicklung und Implementierung von EBICS-Software auf Kunden- wie auf Bankseite konnten wir für die Zertifikatserneuerungen einige Erkenntnisse ableiten. Wir möchten daher denjenigen, die sich mit der EBICS-Server-Administration befassen, folgende Empfehlungen geben:

- Erkundigen Sie sich bei Ihrem Software-Anbieter, nach welchem Verfahren die Zertifikate generiert und aktualisiert werden.

- Meiden Sie bei der Auswahl von Datum und Uhrzeit solche Zeiträume, in denen üblicherweise hohe Belastungen herrschen (Monatsende, Cut-off-Zeiten etc.) oder nur wenige Mitarbeiter auf Kundenseite verfügbar sind (am späten Abend, nachts, in den Schulferien etc.). Da das Ablaufdatum der Zertifikatsgültigkeit vorhersehbar ist, können vorbereitende Maßnahmen schon im Vorfeld ergriffen werden, um sich einen zeitlichen Spielraum zu verschaffen.

- Informieren Sie die Kunden langfristig im Voraus über Datum und Uhrzeit für den Wechsel der Bankzertifikate. Es ist sinnvoll, einige Tage vor dem Termin ein Erinnerungsschreiben zu versenden. Nachfolgend einige Punkte, die ein solches Schreiben unserer Ansicht nach enthalten sollte:

• Dem Kunden die Kontaktaufnahme mit seinem Softwareanbieter nahelegen, damit der Kunde sicherstellt, dass seine Software die Erneuerung der Bankzertifikate unterstützt und er eine Ablaufbeschreibung der Zertifikatserneuerung erhält, sofern er noch keine besitzt. Wir haben ermittelt, dass zwei verschiedene Kundenprodukte diesen Vorgang nicht zulassen. In beiden Fällen waren die Kunden gezwungen, ihre Zugänge vollständig neu anzulegen.
• Den Kunden bitten, das Schreiben vom Softwarehersteller ggf. an den Dienstleister weiterzuleiten, dem er einen DFÜ-Zugang übertragen hat. Denn der vorgenannte Punkt gilt für den Dienstleister gleichermaßen.
• Den Hash-Wert des neuen Bankzertifikats angeben, damit der Kunde den Hash angleichen kann. Die übliche Darstellung als Matrix aus 4 Zeilen zu je 8 Bytes lässt sich durch eine lineare Darstellung (die 32 Bytes in derselben Zeile ohne Trennzeichen) ergänzen, um das Kopieren und Einfügen in die Software des Kunden zu vereinfachen.
• Den Kunden darauf hinweisen, dass, sofern er seine Einstellungen nicht rechtzeitig aktualisiert, der erste Transfer unter Ausgabe eines Fehlercodes mit dem Wert 091008 und der Kennzeichnung EBICS_BANK_PUBKEY_UPDATE_REQUIRED fehlschlägt. Vor einem erneuten Anstoßen der fehlgeschlagenen Transfers muss er zunächst die neuen Bankzertifikate einspielen.
• Dem Kunden empfehlen, sich mit dem echten Zertifikatswechsel vorab vertraut zu machen, indem er das aktuelle Bankzertifikat wiederholt abholt (HPB). So lässt sich der Zertifikatswechsel der Bank mit der Client-Software jederzeit simulieren.

Die aktuellen Möglichkeiten zur Erneuerung der EBICS-Bankzertifikate gewährleisten derzeit keinen reibungslosen Ablauf. Ich bin mir sicher, dass es der EBICS-Gesellschaft so wie im Falle der Order-ID gelingt, in der nächsten Zeit Abhilfe zu schaffen und den Standard so weiterzuentwickeln, dass auch dieses Problem gelöst ist.

Marc Dutech 

Weiterlesen