Anbindung von Bankenperipheriegeräten in virtuellen Umgebungen

Mehrwert einer Virtualisierung

Die Schlagworte „Virtualisierung“ und „Cloud“ sind derzeit im Bereich IT-Architektur oft zu hören und „ohne“ scheint es keinen Weg in die Zukunft zu geben.
Inhaltlich verbirgt sich dahinter die Verlagerung des Betriebs von Software und Rechenleistung in entfernte Systeme. Eine Konzentration von Leistungen im Rechenzentrum (RZ) bietet eine ganze Reihe von Vorteilen, denen wir uns nicht entziehen können. Allem voran sind hier die Einsparpotentiale durch Vereinheitlichung der Prozesse sowie die Zusammenlegung und bessere Ausnutzung von Rechenleistung zu nennen. Die Anwendungen werden zentral verwaltet und die Komplexität sowie Kosten der IT reduziert. Der Auslastungsgrad der Hardware kann zudem gezielt erhöht werden.

Virtualisierung von Bankenperipheriegeräten

Aber was verbirgt sich genau hinter der Virtualisierung und was bedeutet dies für ein so komplexes Umfeld wie das einer Bankfiliale? Hier steht nicht nur die Arbeit mit einer Anwendung im Mittelpunkt, sondern das Tagesgeschäft eines Bankmitarbeiters mit Ein- und Auszahlungen über Kassentresore.
Aber fangen wir vorne am Arbeitsplatz an und schauen uns zunächst nur die Virtualisierung des Clients an:
Grundsätzlich ist Client-Virtualisierung ein Verfahren, um Benutzern gleichzeitig und unabhängig voneinander die Ausführung von Anwendungsprogrammen auf einem entfernten Server zu ermöglichen.
Bei der Betrachtung der Bank verschieben wir also den Betrieb unserer Bankanwendung vom Filial-Client ins Rechenzentrum. Der Client verliert damit seine eigentliche Aufgabe und muss zukünftig nur noch das Bild der Anwendung aus dem Rechenzentrum anzeigen – im Grunde die Funktionalität eines Fernsehers. Wir brauchen somit keinen Fat-Client mit eigener Anwendungssoftware, sondern nur noch einen Thin-Client mit geringer Softwareausstattung.
Das Rechenzentrum bietet uns die Software als Service. Dies kennen wir in ähnlicher Form vom „Office 365“ von Microsoft, das uns z.B. Word und Excel in der „Cloud“ anbietet. Auch hier wird uns die Anwendung auf einem (bzw. mehreren) entfernten Servern angeboten.
Die Virtualisierung von Anwendungen gehört in den IT-Projekten inzwischen zu den gängigen Aufgaben und es gibt auch schon viele Erfahrungen in dem Bereich. Bei einem kompletten Schalter-Kasse-Betrieb in der Bank, müssen wir aber unsere Peripheriegeräte in der Filiale aus dem Rechenzentrum heraus ansteuern, da dort unsere Anwendungen laufen.

Die folgende Skizze soll dies veranschaulichen:

Problemfelder bei der Bankenperipherie

Hier stehen wir nun vor einigen Problemen:

  • Aus dem Rechenzentrum heraus kommunizieren wir via TCP/IP, die Kassentresore z.B. werden aber – von den neuesten Modellen abgesehen – über eine serielle Schnittstelle angesprochen.
  • Es muss sichergestellt werden, dass wir mit dem richtigen Kassentresor in der Bankfiliale kommunizieren. Sowohl Rechenzentrum als auch Peripheriegerät in der Bank müssen sich authentifizieren.
  • Die Kommunikation zwischen Rechenzentrum (RZ) und Bank muss verschlüsselt sein.

Da die Verbindung zwischen RZ und Peripheriegerät in der Filiale das grundlegendste Problem darstellt, fokussieren wir uns zunächst auf den ersten Punkt.

Lösungsansätze

Betrachten wir die Kommunikation in Rechnernetzen vom ISO-OSI-Modell ausgehend, bieten uns die unterschiedlichen Schichten verschiedene Ansatzpunkte, um eine Kommunikation zwischen RZ-Server und Bankperipherie zu etablieren. Von der Bitübertragungs- bis zur Anwendungsschicht können wir theoretisch auf jeder Schicht aufsetzen. Die Lösungsmöglichkeiten sind vielfältig, da es für jede Schicht auch wiederum verschiedene Protokolle gibt. Des Weiteren können wir uns für ein Kaufprodukt oder eine Eigenbaulösung entscheiden. Eine Liste aller Lösungsansätze würde recht lang werden und jeden Ansatz zu verproben, wäre sicher zu aufwendig.
Es sollten daher zunächst grundsätzliche Entscheidungen getroffen werden, z.B. Aufsetzen auf der Applikationsschicht oder eher Bitübertragungsschicht oder ob wir ein Kaufprodukt oder eher eine Eigenbaulösung einsetzen wollen.

Beim Eigenbau einer solchen Lösung hätten wir auf der einen Seite eine sehr hohe Flexibilität und könnten das Produkt exakt auf unsere Wünsche zuschneiden, aber auf der anderen Seite müssten wir alle Anforderungen aus bankfachlicher als auch betriebs- und sicherheits-technischer Sicht selber definieren und implementieren. Neben unseren fachlichen Anforderungen, müssen wir auch Umsetzung, Betrieb, Sicherheit, Support und Weiterentwicklung im Auge behalten. Insbesondere im Betrieb tun sich weit mehr Fragen und Anforderungen auf, als man zunächst vermutet, z.B. Monitoring, Remote Operations, zentrale Logs, Software-Versorgung, Zertifikatsmanagement, Zukunftssicherheit usw. Diese Aufgaben werden zu Beginn eines Projektes gern unterschätzt, da häufig die Fachlichkeit im Fokus steht und weniger der technische Betrieb.
Der Aufwand bei solch umfangreichen Projekten erreicht schnell eine beachtliche Größe und benötigt zusätzlich noch einen verhältnismäßig großen Risikopuffer. Denn in der Regel betritt das Unternehmen bei der Eigenentwicklung Neuland und muss die Erfahrungen, z.B. eines bereits am Markt bestehenden Produktanbieters, erst noch sammeln. Zudem besteht die Gefahr die Architektur nicht variabel genug zu konzipieren, so dass bei einer späteren Integration eines weiteren Softwareprodukts oder einer Hardware-Komponente die gesamte Architektur geändert werden muss.
Der langfristige Support und Betrieb eines solchen Systems wiegt aber ebenfalls schwer. Beim Eigenbau einer Lösung müssten wir im Fehlerfall bis auf die Bit-Schicht herunter um den Fehler zu analysieren, die Zuständigkeit in unserer verteilten Architektur festzustellen und zu beheben.

Im Gegensatz zur Eigenbaulösung steht die Integration eines Kaufproduktes. In unserem Fall der Bankenperipherieanbindung würde diese Software / Appliance in der Bank die TCP/IP-Befehle empfangen und als serielles Signal an die Peripheriegeräte weiterleiten. Bei der Lösung der Betriebsthemen würden die eigenen Anforderungen nur gegen die Möglichkeiten des Produkts gehalten und die Differenzen wären vom Anbieter aufzuarbeiten. Es wäre sicherlich sinnvoll sich von dem Kaufprodukt klar abzugrenzen und es nur als „Blackbox“ zu sehen. Es soll auf der einen Seite unsere fachlichen Vorgaben umsetzen und sich betriebstechnisch integrieren können, aber auf der anderen Seite die Verantwortlichkeit beim Hersteller belassen – „das Produkt muss einfach funktionieren“.
Die Kosten beim Kauf eines Kaufproduktes sind sicher nicht unwesentlich, bieten uns aber ein höheres Maß an Kostensicherheit als der komplette Eigenbau. Auch würde sich der Betrieb und Support deutlich vereinfachen, da uns die verschlüsselte TCP/IP-Kommunikation nicht vor große Anforderungen stellt und die technische Ansteuerung der Peripheriegeräte dann beim Produkt liegt. Es böte sich sogar die Möglichkeit dem Kaufprodukt die fachlichen Funktionen vollständig zu überlassen. Am Beispiel einer Auszahlung könnte dies bedeuten, dass wir nur den Befehl „Auszahlung 100€ / Stückelungskennzeichen 1“ senden und alle weiteren technischen Aufgaben der Kaufsoftware im Sinne einer „Blackbox“ überlassen. Bei einem automatischen Kassentresor (AKT) wären dies unter anderem dasSperren des AKTs für die Transaktion, die Auswahl der Geldrollen (Kassetten) zur Auszahlung, die Auszahlung selbst und die abschließende Freigabe des AKTs.

Alles komplett selber zu steuern und zu entwickeln, gibt einem (fast) immer ein gutes Gefühl, man sollte aber die Risiken bei einem Eigenbau im Auge behalten. Wir haben im Falle der Anbindung der Bankenperipherie den Kauf eines Produktes empfohlen und in die Systemarchitektur des Kunden integriert. Damit haben wir die Kontrolle über die grundsätzliche Architektur und die Schnittstellen behalten und den Hersteller der Blackbox in einer zentralen Komponente unserer Architektur in die Verantwortung genommen.
 

Unsere Lösung

So könnte vereinfacht eine Lösung zur Virtualisierung von Bankenperipheriegeräten aussehen:

Virtualisierung von Bankenarbeitsplätzen wird spätestens mit der Anbindung der Peripheriegräte zu einer echten Herausforderung. Die Kommunikation aus dem Rechenzentrum in die Filiale hinein kann auf unterschiedlichste Weisen gelöst werden.
Wir haben auf den Bau einer kompletten Eigenlösung verzichtet und stattdessen ein Kaufprodukt empfohlen mit entsprechender Aufgaben- und Verantwortungsverteilung. Wir profitieren dabei nicht nur durch das Produkt des Herstellers, sondern partizipieren auch von dessen Erfahrung bei anderen Geldhäusern. Zudem werden Aufwand und Risiko deutlich minimiert.