Fachbeiträge

Sicherer File-Transfer sensibler Daten bei Banken

Die Herausforderung

Im Rahmen eines umfangreichen Security-Projekts bei einem großen Finanzdienstleister galt es ein Verfahren zu implementieren, welches einen in jeder Hinsicht sicheren Datei-Transfer zwischen unterschiedlichen Applikationen auf unterschiedlichen Plattformen gewährleistet. Die bisher verwendete Lösung genügte nur noch zum Teil den strengen aufsichtsrechtlichen Anforderungen wie z.B. Gewährleistung der Authentizität, granulare Berechtigungsstufen, zuverlässige Verschlüsselung, Manipulationssicherheit und Nachvollziehbarkeit. Außerdem sollte die Lösung auf etablierten, allgemein anerkannten Sicherheitsstandards aufbauen und einfach zu administrieren sein.

Die Idee

Erste Überlegungen gingen dahin, das bereits eingesetzte kommerzielle Produkt zu nutzen und um die von diesen noch nicht abgedeckten aber benötigten Anforderungen zu erweitern, vor allem um eine hinreichend starke Verschlüsselung und um die Protokollierung von Checksummen der übertragenen Dateien. Außerdem wären Werkzeuge zur vereinfachten Fehleraufdeckung und Administration wünschenswert. Die Ergänzung all dieser Anfordungen hätte sich jedoch aufwendig gestaltet, da die bereits eingesetzten Produkte zum einen keine geeigneten APIs zur Verfügung stellen und andererseits auch nicht quelloffen sind. Ein weiterer genereller Nachteil waren die auf Client-Seite erforderlichen Aufwände zur Installation und Wartung.

Ein völlig anderer Ansatz, der auf einer eher Service-orientierten Architektur basiert, würde hingegen nur sehr geringe Anforderungen an den Client und dessen Administration stellen. In diesem Zusammenhang fiel das Augenmerk auf die bereits vielfach installierte OpenSSH-Software, deren SSH-Daemon schließlich nicht nur eine SSL-gesicherte Terminalverbindung zwischen Client und Server ermöglicht sondern darüber hinaus mit Hilfe der Applikationen Secure-FTP (SFTP) und Secure-Copy (SCP) auch Funktionen für einen verschlüsselten Datei-Transfer bietet. Die Authentifizierung erfolgt dabei über ein derzeit allgemein als sicher geltendes asymmetrisches RSA-Schlüsselpaar und die Verbindung selbst (nach gesichertem Austausch eines symmetrischen geheimen Schlüssels) aus Performancegründen mit der ebenfalls zuverlässigen 3DES- oder Blowfish-Chiffrierung.

Die größte Hürde hierbei ist jedoch das "Alles oder Nichts"-Prinzip bei der Zuteilung der Zugriffsrechte. Wenn der Ziel-Benutzer T1 einen Remote-Client-Benutzer C1 autorisiert, Dateien von seinem Rechner M1 auf dem Zielrechner M2 unter seinem Ziel-Account einzustellen, so würde es dem Benutzer C1 ebenso ermöglicht werden, in einer Terminal-Session die komplette Identität des Benutzers T1 zu übernehmen und damit beliebige Aktionen auszuführen. Diese Gefahr des Mißbrauchs gilt es durch Einführung einer weitergehenden Zugriffskontrolle einzudämmen.

Bei der OpenSSH-Software erweist sich die Erweiterung um fehlende Funktionalitäten wie die granularere Rechtevergabe, Reporting etc. generell als eher unproblematisch, da es sich bei OpenSSH um eine quelloffene Software handelt, die unter der freien BSD-Lizenz erhältlich ist. Neben dem Vorteil des Zugangs zum Quellcode fallen als zusätzlicher Pluspunkt bei dieser Software im Gegensatz zu kommerziellen Produkten daher auch keinerlei Lizenzkosten an.
 

Die Umsetzung

Der OpenSSH-Server bietet eine sehr komfortable Möglichkeit, sämtliche eingehenden Client-Verbindungen über ein eigenständiges, frei definierbares Backend-Programm abarbeiten zu lassen. Auf Basis dieses Mechanismus konnten alle zusätzlich benötigten Sicherheits-Funktionen innerhalb genau dieses Backend-Programms ohne Veränderung des eigentlichen OpenSSH-Sourcecodes implementiert werden,. Hiermit ergaben sich entscheidene Vorteile:

  • Die Secure-Transfer-Lösung ist bei geeigneter Implementierung des Backends genauso plattformunabhängig wie OpenSSH selbst (Einsatz unter SUN Solaris, MS Windows NT/2000/XP, HP-UX, True64, BSD, MacOS, Linux, z/OS etc.).
  • Sicherheits-Updates (Patches) von OpenSSH können jederzeit unabhängig von der Backend-Software durchgeführt werden.
  • Bereits installierte OpenSSH-Versionen müssen nicht neu installiert oder gar neu kompiliert werden.
  • Das Backend-Programm kann an beliebiger Stelle im System abgelegt sein und wird mit den Rechten des SSH-Ziel-Users aufgerufen. Daher ist nicht einmal eine administrative "root"-Installation des Backends nötig.
  • Die Verfügbarkeit des Dienstes muss nicht separat durch komplizierte Verfahren wie Watchdog-Prozesse und Port-Kollisions-Prüfungen sichergestellt werden.

Die Anbindung des Backend-Programms an den SSH-Server erfolgt einfach durch Hinzufügen eines Präfixes (mit der „command“-Direktive) in jeder Public-Key-Zeile der "authorized_keys"-Datei des Ziel-Users. Aufgabe dieser Datei ist es, dass der Ziel-User bestimmten Remote-Usern den SSH-Zugang zu seinem Useraccount gestattet ohne dass eine interaktive Passwort-Eingabe nötig wäre (wichtig für den Batch-Betrieb). Jeder Remote-User muss dazu initial ein DSA- oder RSA-Schlüsselpaar generiert haben, der aus einem geheimen, nur diesem User bekannten Teil (Private Key) und einem öffentlichen Teil (Public Key) besteht, welchen der Ziel-User in ebendieser "authorized_keys"-Datei zeilenweise hinterlegt. Beim Verbindungsaufbau wird intern im SSH-Protokoll geprüft ob in der Liste der hinterlegten Public Keys beim Ziel-User ein zu dem geheimen Private-Key des Remote-Users passender Schlüssel existiert. Egal ob der Client eine Terminal-Session (SSH), eine FTP-Sessions (SFTP) oder einen direkten Datei-Transfer (SCP) initiiert hat, die „command“-Direktive in der passenden Public Key-Zeile erzwingt den Aufruf des Backend-Programms durch den den Request abhandelnden SSH-Server. Um dem Backend-Programm mitzuteilen, welcher Remote-User hinter der jeweiligen Public-Key-Zeile steckt, werden die Remote-User-Id und der Name des Remote-Rechners dem Programmaufruf als Argumente mit übergeben.

Zunächst verifiziert das Backend-Programm, ob der Remote-Zugriff tatsächlich vom erwarteten Remote-Rechner erfolgte, um die potentiell vorhandene Missbrauchsgefahr von unberechtigt erlangten Private Keys zu verringern. Dies erfolgt durch den Vergleich der vom SSH-Server erhaltenen IP-Adresse mit dem Remote-Rechnernamen aus der authorized_keys-Datei. Anschließend wird ermittelt, welche Aktion der Client ausführen möchte (z.B. Datei-Upload oder -Download, Ausführung eines Programms).

Ein großer Vorteil der SSH-Backend-Anbindung besteht darin, dass alle (Stderr-)Ausgaben des Backend-Programms direkt via SSH als (Stderr-)Ausgabe zum aufrufenden Programm an den Client-User weitergeleitet werden. Hiermit und mit der ebenfalls transparenten Weiterleitung des Fehlerrückgabewertes kann der Client sehr detailliert über Erfolg bzw. Grund des Misserfolgs seiner Client-Aktion informiert werden. Es kann also sofort gemeldet werden ob z.B. der Datei-Upload gescheitert ist, weil auf dem Ziel-Volume nicht mehr ausreichend Speicherplatz vorhanden war, ob ein ungültiges Zielverzeichnis angegeben wurde oder ob für den Client generell keine Berechtigung besteht, auf dem Server Dateien abzulegen.

Da eine interaktive Terminal- oder FTP-Session keine in sich geschlossene und damit auf diesem Weg kontrollierbare Transaktion darstellt werden derartige Verbindungsversuche mit entsprechender Meldung abgewiesen. Zum Datei-Transfer wird einzig Secure-Copy zugelassen. In einer einfachen Konfigurationsdatei wird festgelegt, welcher User von welchem Rechner kommend in welches Verzeichnis Dateien einstellen darf oder aus welchem Verzeichnis er Dateien herunterladen darf. Die im Backend-Programm nun vorhandenen Informationen wie Remote-Userid, Remote-Hostname und Kommando incl. Verzeichnis werden nun mit der Konfigurationsdatei verglichen, um damit die Berechtigung zur gewünschten Aktion festzustellen.

Neben der detaillierten Fehlermeldung an den Client wird ebenso wie im Erfolgsfall auch stets ein umfangreicher Log-Eintrag hinterlegt. Zusätzlich zum Zeitstempel, dem Remote-User, dem Remote-Rechner, der auszuführenden Aktion und dessen Erfolg sowie Misserfolg (und dessen Grund) wird hier bei Datei-Transfers stets auch die genaue Größe und die Checksumme der übertragenen Dateien protokolliert. Dies ermöglicht eine spätere Kontrolle, ob die übertragenen Daten nachträglich auf Serverseite verändert wurden (Manipulations-Schutz).

Mittlerweile wurde das Backend-Programm und die XML-Konfigurations-Syntax soweit erweitert, dass neben dem bloßen Dateitransfer auch Konsistenz-Check-Scripte konfiguriert werden können, die etwa ungültige Header- oder Trailer-Zeilen erkennt und dies mit genauer Fehlermeldung an den "scp"-aufrufenden Client direkt meldet. Diese Überprüfung erfolgt noch bevor die Datei an den endgültigen Ort eingestellt und dort möglicherweise sofort weiterverarbeitet wird. Ergänzend dazu sind auch Action-Scripte vorgesehen, die innerhalb einer einzigen "scp"-Transaktion z.B. ein zu übertragendes, komprimiertes Tar-Archiv automatisch am Ziel-Ort entpacken oder beim Datei-Download erst die gewünschte Datei generieren (z.B. durch ein Datenbank-Dump), bevor diese an den anfordernden Client geschickt wird.

Das Ergebnis

Neben dem Vorteil der entfallenden Lizenzkosten durch den Einsatz von OpenSSH wurden durch die Implementierung des SSH-Server-Backends nun alle benötigten regulatorischen Anforderungen mit nur geringem Entwicklungsaufwand sichergestellt. Die Lösung ist inzwischen beim Kunden auch außerhalb des ursprünglich definierten Bereichs im produktiven Einsatz, insbesondere da weder beim Client noch beim Server neben der Installation des OpenSSH-Pakets administrative Tätigkeiten anfallen. Lediglich das Backend muss auf dem Server-System „eingeklinkt“ und die Berechtigungen konfiguriert werden. Der Client kann dann normal mit einem gewohnten Secure-Copy seine Dateien an den Server senden oder vom Server beziehen und bekommt stets direkte Rückmeldung über Erfolg oder Grund des Misserfolgs seines Transfers.