Austausch von Dateien im B2B Umfeld

Aus der Historie heraus basierten solche Plattformen oft noch auf dem klassischen File Transfer Protocol. Server auf Basis des ungesicherten ftp-Protokolls scheiden eigentlich schon seit Jahren als Plattform für den Austausch sensibler Daten aus. Trotzdem gibt es diese Variante des Datenaustausch immer noch und wird nach wie vor produktiv genutzt. Einige dieser noch verbliebenen Server bieten ftps und somit eine TLS Verschlüsselung der Übertragung an. Aber gerade in Verbindung mit NAT ist dies nicht immer trivial in der Umsetzung und die Authentisierung basiert immer noch auf Benutzername und Passwort. Objektiv betrachtet ist es aber immer noch das ursprüngliche ftp-Protokoll aus dem Jahr 1972 und den über die Jahre hinweg hinzugefügten Erweiterungen. Dabei gibt es deutlich bessere Alternativen und eine sehr gut schon seit 1999 mit OpenSSH. State of the art sind natürlich https basierenden Applikationen für den Austausch von Dateien, wenn es um den Datenaustausch zwischen Personen geht.

Spätestens mit der DSGVO, die Ende Mai in Kraft trat, kann normales ftp zur Übermittlung personenbezogener Daten über offene Netze, wie das Internet, nicht mehr genutzt werden. Aus Sicht der IT Sicherheit sollte das ftp-Protokoll schon seit Jahren nicht mehr genutzt werden. Alleine schon wegen der Übertragung im Klartext. Da nützt es nichts, die Zugangsdaten lokal verschlüsselt abzulegen, wenn diese quasi für alle lesbar unverschlüsselt übertragen werden und hier insbesondere über das Internet. Die Empfehlung ist hier ganz klar und konsequent auf ftp zu verzichten. Dieses Protokoll hat in einer IT Umgebung die auf Sicherheit Wert legt nichts mehr zu suchen. Es mag zwar die eine oder andere Altlast oder neu, technische Schuld noch geben, aber diese Sonderfälle sollen nicht Bestandteil dieses Beitrags sein. Wer solche Server noch betreibt, sollten deren Einsatz auf jeden Fall in regelmäßigen Abständen hinterfragen und immer wieder anhand der Daten und dem benötigten Sicherheitsniveau den Einsatz neu bewerten.

Eine sehr gute Alternative ist die Verwendung von sftp auf Basis von OpenSSH. Hier profitiert man direkt von allen Vorteilen des verschlüsselten ssh-Protokolls und hat gleichzeitig scp, sftp und sshfs zur Verfügung, welche sich im Besonderen für automatisierte Abläufe eigenen. Auch ist man mit dem Public/Private Key Verfahren von ssh das leidige Problem der Passwörter u.a. beim Batch-Jobs los. Vor allem braucht es dann nicht wie sonst nötigt, andere kleine Helferlein und das Passwort muss auch nicht im Script hinterlegt werden. Gleichzeitig verabschiedet man sich von Benutzername und Passwort und setzt auf die wesentlich sicherere Variante mit Schlüsselpärchen. Der Einsatz von OpenSSH auf Linux oder den freien BSD Varianten bietet zudem den Vorteil von OpenSource und somit einer lizenzkostenfreien Nutzung. Auf der technischen Seite bietet OpenSSH sehr gute Verfahren zur Verschlüsselung an, die als sicher gelten. Nicht zuletzt hat das BSI mit der technischen Richtlinie TR-02102 (Teil 4) dies bestätigt und spricht entsprechenden Empfehlungen für den Einsatz von (Open)SSH aus. Dies ist ein großer Vorteil für all diejenigen, die SSH zur Übertragung von Daten, gemäß des IT Grundschutzes, im Rahmen einer Zertifizierung oder DSGVO-Konform nutzen möchten. Durch die Beachtung der technischen Richtlinie und den Empfehlungen entspricht die Übertragung dem Stand der Technik und dies Branchenübergreifend. Zudem lässt sich das System mit weiteren technischen Maßnahmen, wie zum Beispiel Fail2Ban gegen BruteForce Angriffe weiter absichern. Grundsätzlich empfiehlt sich aber auch der Einsatz eines IPS und auch einer Anomalieerkennung wie dies zum Beispiel mit einer Fortigate Firewall zur Verfügung steht. Der Empfehlung des Wechsels vom Standard Port 22/tcp auf einen anderen kann man gerne folgen. Hier muss man sich nur darüber im Klaren sein, dass dies nur die Script Kiddies und die einfachen Bots abhält, die nach offenen Standard ssh Ports suchen. Einen nur ein wenig professionellen Angreifer hält der Portwechsel effektiv gesehen nur ein paar Sekunden lang auf, um den Dienst zu finden und danach anzugreifen. Aber unabhängig der Angriffe gilt das ssh-Protokoll als sicher, dies zeigt sich auch in der Art der Angriffe selbst. Es wird mit BruteForce Angriffen gearbeitet um gültige Kombinationen von Benutzernamen und Passwort zu finden. Einen direkten Angriff auf das ssh-Protokoll an sich oder den Dienst selbst ist eher nicht zu finden. Verzichtet man zugunsten von Keys auf Passwörter laufen die BruteForce Angriffe in Leere, sofern man das Anmelden per Passwort auch in der Konfiguration unterbunden hat. Grundsätzlich wird aber trotzdem eine Härtung des Dienstes empfohlen, wenn dieser aus dem Internet zu erreichen ist. Aber (Open)SSH ist die richtige Wahl, wenn es um einen entsprechend abgesicherten Fernzugriff auf eine Console geht oder auch einen Ersatz zum Ablösen eines ftp-Server.

In der automatisierten Kommunikation zwischen Unternehmen ist das ssh-Protokoll eine gute Wahl. Aber in Verbindung mit Anwendern ist dies oft zum Scheitern verurteilt. Der Ablauf von sftp orientiert sich an ftp, aber genau hier liegt das Problem, denn die wenigsten wissen heute wie es “damals” mit ftp war Daten auszutauschen. Daher scheitert es schon häufig an der Bedienung eines grafischen Clients für ftp, ganz zu schweigen eines Clients auf der Kommandozeile. Das Grundproblem liegt darin, dass der heutige Umgang mit Dateien immer mehr in den Hintergrund gerät. Viele Applikationen nehmen den Benutzer den Umgang mit Dateien vollständig ab. Häufig weiß ein Anwender gar nicht mehr oder will es auch nicht, wo denn genau seine “Eigenen Dateien” auf ihrem lokalen Rechner denn wirklich gespeichert sind. Demzufolge fehlt oft das Verständnis für ein Dateisystem und dessen Strukturen. Dies ist aber nicht die Schuld des Anwenders, es ist ganz einfach dem geschuldet, wie IT heute benutzt wird. Gerade bei Anwendungen in der Cloud spielt es auch keine wirkliche Rolle für den Anwender, wo die Daten liegen und muss es auch nicht. Daher fehlt hier einfach das Wissen und auch die Routine, weil es auch in der modernen IT auch nicht mehr vom Anwender gefordert ist, dies zu wissen und damit umgehen zu können. Daher ist es auch dann nicht weiter verwunderlich, dass es im Umgang mit den klassischen Protokollen sehr oft zu den üblichen Verständnisschwierigkeiten kommt. Demzufolge braucht es hier entsprechenden Lösungen, die das gewohnte Arbeiten der Anwender nicht verlässt und nach Möglichkeit im Browser läuft. Spontan fallen einem hier die üblichen Verdächtigen, wie Dropbox, OneDrive & Co. ein. Doch dann liegen die Daten in einer (US-)Cloud. Je nachdem um welche Daten es sich handelt, muss dies nicht zwangsläufig ein Problem darstellen. Aber wenn man sensible, Daten die nicht zwangsläufig personenbezogene Daten sein müssen austauschen möchte, greift man lieber auf eigene Systeme oder auf Systeme eines Dienstleisters des Vertrauens zurück. Für diesen Zweck stehen Anwendungen wie, OwnCloud, NextCloud oder auch Seafile zur Verfügung. Wir empfehlen den Einsatz von Seafile, wenn es um den Austausch von Dateien geht und man weder Kalender oder andere AddOns benötigt. Den Einsatz einer “out of the box” Lösung, wie ihn NAS Systeme anbieten empfehlen wir nur bedingt, da es sich hier um doch eher proprietäre Lösungen handelt. In solchen Fällen doch eher auf OpenSource zu setzen bietet nicht nur den Vorteil bei den nicht vorhandenen Lizenzkosten, sondern auch im Besonderen in der Sicherheit der Anwendung und des darunter liegen Betriebssystem selbst. Hier hat man dann alles selbst in der Hand und kann dieses System für den Austausch von Daten entsprechend sicher gestalten. Angefangen beim Aufbau des Basissystems, mit der Auswahl des passenden Dateisystem und vielleicht hier schon mit einer entsprechenden Verschlüsselung der Datenpartition. Steht der eigene Server in einem externen Datacenter, was auch aus Gründen der Anbindung und der Verfügbarkeit oft deutlich mehr Sinn macht, statt in lokal zu betreiben, dann bieten manche Applikationen die Anbindung an den ADFS (Active Directory Federation Service) an. Dies ist eine geschickte Methode um den einen Anwendern mit einem AD Konto Zugriff auf die Anwendung zu geben, ohne dass die Anwendung eine direkte Verbindung zur AD benötigt oder die Authentifizierungsinformationen auf den somit externen Server vorgehalten wurden müssen. Dies ist eine sehr elegante Lösung eigene Anwender an der AD zu authentifizieren ohne die eigene AD bis in das externe Datacenter öffnen zu müssen.

Es gibt viele gute Lösungen die auch Dank OpenSource vollständig lizenzkostenfrei sind und eine wesentlich bessere Lösung darstellen, als es ein ftp Server jemals war. Wenn Sie Fragen zum Thema haben, sprechen Sie uns wie gewohnt einfach an.