Wozu dienen FTP, SFTP und FTPS und was sind die Unterschiede? Wir stellen im folgenden Beitrag die technischen Grundlagen hinter diesen Protokollen vor und gehen auf die Unterschiede ein. Anschließend zeigen wir die Verwendung von SFTP/FTPS als mögliche Protokolle für den Datenaustausch zwischen einem ERP-System und einem EDI-Dienstleister auf.
Motivation für das FTP-Protokoll
Mit Hilfe des FTP-Protokolls (File Transfer Protocol) kann ein Rechner (der Server) einem oder mehreren anderen Rechnern (den Clients) Zugriff auf Teile des eigenen Dateisystems geben.
Damit kann also ein Dateisystem mit mehreren Rechnern geteilt werden, wodurch ein Datenaustausch zwischen diesen Rechnern realisiert werden kann. Die technische Grundlage ist im RFC 959 von 1985 beschrieben.
Für den Datenaustausch zwischen zwei Rechnern wird im Bereich des elektronischen Datenaustausches üblicherweise eines der folgenden Protokolle verwendet.
- FTP (File Transfer Protocol)
- SFTP (SSH File Transfer Protocol)
- FTPS (FTP over TLS)
Bei FTP erfolgt die Kommunikation zwischen Client und Server unverschlüsselt.
Bei SFTP erfolgt die Kommunikation verschlüsselt, wobei die Verschlüsselung mit Hilfe von SSH (Secure Shell) realisiert wird. Der Standard-Port für SFTP-Verbindungen ist 22. Technisch gesehen hat SFTP mit dem File Transfer Protocol (FTP) nichts zu tun – es besteht lediglich eine Ähnlichkeit hinsichtlich des Namens.
Bei FTPS erfolgt die Kommunikation ebenfalls verschlüsselt, wobei hier für die Verschlüsselung auf TLS (Transport Layer Security) gesetzt wird. TLS ist die neue Bezeichnung für Secure Sockets Layer (SSL), ein Verschlüsselungsprotokoll für die sichere Datenübertragung im Internet.
Warum FTP nicht verwendet werden sollte
Auch heute hört man in vielen EDI-Projekten noch die Forderung nach dem Einsatz von FTP als Datenaustauschprotokoll.
Im Unterschied zu SFTP oder FTPS ist eine FTP-Verbindung unverschlüsselt. Das bedeutet, dass mit etwas Know-How und den richtigen Tools die gesamte Kommunikation einfach abgehört und auch verändert werden kann. Ein Schutz der Daten vor unerlaubtem Zugriff und ein Schutz der Datenintegrität sind daher nicht gewährleistet.
Vom Einsatz von FTP ist daher dringend abzuraten.
SFTP im Einsatz bei EDI
Durch die einfache Verfügbarkeit von SFTP-Software (sowohl Client, als auch Server) kann SFTP auch im Bereich von EDI sehr einfach eingesetzt werden. Typischerweise wird SFTP in diesem Zusammenhang für den Datenaustausch zwischen einem Unternehmen und einem EDI-Dienstleister eingesetzt.
Wie in der folgenden Abbildung dargestellt, kann SFTP dabei als das zentrale Austauschprotokoll zwischen der ERP-Software und dem EDI-Dienstleister verwendet werden.
SFTP zwischen Unternehmen und EDI-Dienstleister
Da SFTP zwingend nach einem Server und einem Client verlangt, muss der SFTP-Server entweder vom Unternehmen betrieben werden oder vom EDI-Dienstleister. Der jeweils andere Partner agiert dann als SFTP-Client.
Die folgende Abbildung zeigt den Betrieb des SFTP-Servers im Unternehmen. In diesem Fall stellt der EDI-Dienstleister neu ankommende Nachrichten umgehend an den SFTP-Server zu. Vom Unternehmen für die Abholung bereitgestellte Dateien werden in periodischen Intervallen abgeholt – zB alle 15 Minuten.
Da der SFTP-Server im Unternehmen betrieben wird, kann das ERP-System direkt aus einem lokalen Ordner oder einem Netzwerk-Share lesen und in diesen schreiben.
Sofern vom Unternehmen kein SFTP-Server bereitgestellt werden kann, ist der Betrieb des SFTP-Servers auch auf Seiten des EDI-Dienstleisters möglich, wie in der folgenden Abbildung dargestellt. In diesem Fall liegt es in der Verantwortung des Unternehmens periodisch auf neue angekommene Nachrichten auf Seiten des EDI-Dienstleisters zu prüfen.
SFTP-Server beim EDI-Dienstleister
Um die Daten von und zum SFTP-Server auf Seiten des Dienstleisters zu übertragen, muss im Unternehmen ein entsprechender Batch-Job oder Workflow eingerichtet werden. Der Umsetzungsaufwand und das Monitoring sind damit höher, als bei einem Betrieb des SFTP-Servers direkt im Unternehmen.
In der Praxis kommen beide Anwendungsfälle zur Anwendung – je nachdem über welche technischen Möglichkeiten das Unternehmen verfügt.
Herausforderungen beim Einsatz von SFTP/FTPS
Der Einsatz von SFTP/FTPS im Zusammenhang mit EDI mag auf den ersten Blick trivial erscheinen. In der Realität steckt der Teufel jedoch im Detail. Im Folgenden gehen wir auf die verschiedenen Herausforderungen beim Einsatz von SFTP/FTPS ein.
Gleichzeitiges Lesen und Schreiben
Eine der zentralen Herausforderungen beim Einsatz von SFTP ist das Verhindern von gleichzeitigem Lesen und Schreiben. Das heißt, dass während ein Prozess noch in die Datei schreibt, darf ein anderer Prozess diese Datei noch nicht lesen. Ansonsten läuft man Gefahr, dass Daten nur unvollständig übernommen werden.
Eine Möglichkeit die oft in Erwägung gezogen wird, ist die zeitliche Trennung – zB Schreiboperationen nur zur vollen Stunde und Leseoperationen nur zur vollen Stunde + 30 Minuten. Von diesem Ansatz ist generell abzuraten, da es durch längere Schreiboperationen, kürzere Schreib-/Leseintervalle, System-Neustarts usw. trotzdem zu Überschneidungen kommen kann.
Im Folgenden stellen wir eine Reihe von Mechanismen vor, um gleichzeitiges Lesen und Schreiben zu verhindern.
Temporäre Dateien
Die erste Möglichkeit ist die Verwendung von temporären Dateien, welche anschließend umbenannt werden. Die Umbenennung einer Datei ist eine atomare Operation. Sprich, während dem Umbenennen der Datei kann kein anderer Prozess schreibend oder lesend auf die Datei zugreifen. Diesen Effekt macht man sich bei SFTP zu Nutze. Im Folgenden ist der Prozess im Detail aufgeschlüsselt.
Die typische SFTP-Ordnerstruktur am Server besteht aus einem in und einem out-Ordner. In den in-Ordner werden alle EDI-Dateien geschrieben, die vom EDI-Dienstleister an das Unternehmen weitergeleitet werden. In den out-Ordner werden vom Unternehmen alle Dateien geschrieben, die vom EDI-Dienstleister abgeholt werden sollen.
Im folgenden Beispiel ist vom Unternehmen eine Rechnung exportiert worden, welche vom EDI-Dienstleister abgeholt, konvertiert und an das Partnerunternehmen (zB ein Kunde) zugestellt werden soll. Anstatt die finale Datei zu schreiben, wird zuerst eine .tmp Datei erstellt. Der lesende Prozess des EDI-Dienstleisters ist explizit so konfiguriert, dass aus dem out-Ordner nur Dateien mit der Endung .xml gelesen werden sollen und keine Dateien aus dem Unterordner archive gelesen werden sollen. Warum letzteres wichtig ist, erklären wir im Folgenden.
Schreiben der temporären Datei
Nachdem der schreibende Prozess aus dem ERP-System des Unternehmens die temporäre Datei fertig geschrieben hat, wird diese vom schreibenden Prozess umbenannt und die korrekte Dateiendung .xml wird vergeben. Die Umbenennung der Datei ist atomar, sodass der lesende Prozess erst nach Abschluss der Umbenennung auf die Datei zugreifen kann. Da der lesende Prozess nur für Dateien mit der Endung .xml konfiguriert ist, wird die Datei nun korrekt erkannt und die Daten werden vom EDI-Dienstleister übernommen.
Umbenennen der temporären Datei
Nachdem die Datei erfolgreich gelesen wurde, wird sie in den Unterordner archive verschoben. Damit wird verhindert, dass der lesende Prozess eine Datei mehrmals liest. Des Weiteren bietet der archive-Ordner eine Übersicht über die bisher abgeholten Dateien. Da der lesende Prozess keine Dateien aus dem Unterordner archive liest, wird verhindert, dass diese archivierten Dateien noch einmal gelesen werden.
Lesen und Verschieben der Datei
Verwendung einer Done-Datei
Bei der Verwendung einer Done-Datei wird nach Abschluss der Schreiboperation eine Datei mit dem gleichen Namen und der Dateiendung .done erzeugt.
Der lesende Prozess liest nur Dateien, für welche eine entsprechende .done-Datei vorhanden ist. Die folgende Abbildung zeigt ein entsprechendes Beispiel.
Nachdem die Datei gelesen wurde, werden beide Dateien in einen Unterordner verschoben um ein erneutes Lesen zu verhindern.
Verwendung einer Lock-Datei
Bei der Verwendung einer Lock-Datei wird vor dem Schreiben der eigentlichen Datei eine Datei mit dem gleichen Namen und der Dateiendung .lock erzeugt. Anschließend wird die eigentliche Datei geschrieben. Die folgende Abbildung zeigt ein entsprechendes Beispiel.
Nachdem die Datei fertig geschrieben wurde, wird die .lock-Datei gelöscht. Der lesende Prozess liest nur Dateien für die keine .lock-Datei existiert. Nach dem Lesen wird die Datei in einen Unterordner verschoben.
Datei-Monitoring
Bei dieser Methode beobachtet der lesende Prozess zuerst die zu lesende Datei auf laufende Veränderungen – zB in den letzten 10 oder 15 Sekunden. Nur wenn in den letzten n Sekunden keine Veränderung zu erkennen war, wird die Datei gelesen.
Anschließend wird die Datei wie bei den anderen Methoden in einen Unterordner verschoben.
Firewall-Konfigurationen
Je nachdem ob das Unternehmen selbst einen SFTP-Server betreibt oder auf den SFTP-Server des EDI-Dienstleisters zugegriffen wird, müssen in der Unternehmens-Firewall die entsprechenden Ports freigegeben werden. Diese Portfreigaben müssen mit der unternehmensinternen IT bzw. sofern vorhanden mit dem IT-Dienstleister abgestimmt werden. Vor allem bei der Verwendung von FTPS kann die Firewall-Konfiguration herausfordernd sein, da unterschiedliche Ports freigegeben werden müssen — je nachdem ob Active oder Passive Mode FTPS verwendet wird.
Möchte das Unternehmen einen eigenen SFTP-Server betreiben, so ist eine eindeutige und fixe IP-Adresse, welche von außerhalb des Unternehmens erreichbar ist, eine Grundvoraussetzung.
User-Management
Für den Zugriff auf den SFTP-Server sind neben der IP-Adresse, dem Zielordner und dem Port auch ein Benutzername und ein Passwort zwingend notwendig. Der Betreiber des SFTP-Servers muss ein entsprechendes Management dieser Zugangsdaten garantieren. Dies beinhaltet das Setzen von sicheren Passwörtern, das Löschen von abgelaufenen Benutzern, das Sicherstellen des Zugriffs auf ausschließlich autorisierte Ressourcen etc.
Nachvollziehbarkeit des Austausches
Im Unterschied zu speziell für den elektronischen Datenaustausch vorgesehenen Protokollen wie AS2 oder OFTP2 bietet SFTP nur eine bedingte Nachvollziehbarkeit des Datenaustausches. So bietet der archive-Ordner zwar eine Übersicht über die bisher ausgetauschten Dateien, allerdings gibt es keine Bestätigung des Erhalts von der Gegenseite, wie dies zB bei AS2 mit MDNs (Message Disposition Notification) oder bei OFTP2 mit EERP (End-to-End-Response) der Fall ist.
Des Weiteren gibt es bei SFTP keine eindeutige ID für eine übertragene Datei, außer dem Dateinamen. Im Fehlerfall kann also lediglich anhand des Dateinamens gesucht werden.
Bei einem geringen EDI-Aufkommen stellt dies noch kein wesentliches Problem dar, da die Suche in den einzelnen Dateien noch überschaubar bleibt. Bei größerem EDI-Aufkommen sollte auf eine engere Integration zwischen ERP-System und EDI-Dienstleister gesetzt werden. Eine bessere Nachvollziehbarkeit der ausgetauschten Dateien zwischen einem ERP-System und dem EDI-Dienstleister lässt sich beispielsweise auf Basis der ERPEL API – realisieren.
Sie haben noch Fragen zum Unterschied FTP, SFTP und FTPS?
Sie haben noch Fragen zum Thema SFTP in Verbindung mit EDI? Nehmen Sie mit uns Kontakt auf oder benutzen Sie unseren Chat — wir helfen Ihnen gerne weiter!
