WISSEN > GLOBAL FILESYSTEM > FILE SYNC & SHARE
Autor: Dirk Neumann Geschäftsführer ASSISTRA Cloud Services GmbH 17.08.2026
File Sync & Share
Sicher zusammenarbeiten, ohne die Kontrolle über Unternehmensdaten zu verlieren
Das sollten Sie mitnehmen:
- File Sync & Share ≠ einheitliche Produktkategorie
Ähnliche Benutzerfunktionen können auf grundlegend verschiedenen Daten- und Betriebsmodellen beruhen.
- Datenplattform oder Zugriffskanal
Entscheidend ist nicht der Funktionsumfang, sondern welche Rolle File Sync & Share innerhalb der bestehenden Datenarchitektur übernimmt.
- Jede Kopie erzeugt einen zweiten Datenbestand
Wird für die Zusammenarbeit kopiert, muss technisch geklärt sein, welcher Stand führt und wie Änderungen zurückgelangen.
- Datenresidenz ≠ Datenhoheit
Ein europäischer Speicherort beantwortet nicht, wer Plattform, Verschlüsselungsschlüssel und Zugang kontrolliert.
- Protokolle überleben Produktentscheidungen
Das Supportende von Office Online Server zeigt, wie schnell eine selbstverständliche Funktion entfällt, wenn eine Architektur gegen ein Produkt statt gegen eine Schnittstelle integriert.
File Sync & Share
Inhaltsverzeichnis
- Warum klassische File Services an der Unternehmensgrenze enden
- Zwei grundsätzlich unterschiedliche Architekturmodelle
- Die entscheidende Frage: Entsteht ein zweiter Datenbestand?
- Datenresidenz, Schlüsselhoheit und Datenhoheit sind drei verschiedene Dinge
- Digital Sovereignty ist 2026 messbar geworden
- Wer kontrolliert Daten, Technologie und Zugang?
- Ein Lehrstück: der Wegfall von Office Online Server
- Die übersehene Abhängigkeit: der Identity Provider
- Warum die Jurisdiktion des Anbieters relevant ist
- Portabilität gehört zur Souveränität
- Die fünf Ansätze im Einzelnen
- Marktvergleich auf einen Blick
- Was in Projekten tatsächlich schwierig wird
- Welche Fragen sollten vor der Einführung beantwortet werden?
- Fazit
- Quellen
Unternehmen müssen Dateien längst über die Grenzen des eigenen Netzwerks hinaus bereitstellen. Mitarbeiter arbeiten mobil, externe Spezialisten werden in Projekte eingebunden, Rechtsabteilungen tauschen Dokumente mit Kanzleien aus, Marketingabteilungen arbeiten mit Agenturen und Freiberuflern, und Fertigungsunternehmen müssen Konstruktionsunterlagen fortlaufend mit Partnern abgleichen. Klassische File Services sind für diese Anforderung nicht gebaut worden. Sie setzen einen Benutzer voraus, der sich innerhalb einer definierten Infrastruktur authentifiziert und anschließend per SMB oder NFS auf einen Server zugreift.
File-Sync-&-Share-Lösungen (FSS, im Unternehmensumfeld häufig EFSS – Enterprise File Sync and Share) schließen diese Lücke. Benutzer rufen Dateien über unterschiedliche Geräte ab, synchronisieren sie und teilen sie mit internen oder externen Personen. Weil die sichtbaren Funktionen dabei fast überall gleich aussehen – synchronisieren, freigeben, mobil zugreifen, Links versenden –, entsteht leicht der Eindruck einer austauschbaren Produktkategorie.
Architektonisch trifft das nicht zu. Die entscheidende Frage lautet nicht, wie Benutzer Dateien synchronisieren und teilen, sondern wo die Daten liegen, wer die zugrunde liegende Infrastruktur kontrolliert und ob File Sync & Share Bestandteil der bestehenden File Services ist oder eine zusätzliche Datenplattform darstellt. Mit der europäischen Diskussion über Digital Sovereignty hat diese Frage in den vergangenen zwei Jahren erheblich an Gewicht gewonnen – und seit 2026 auch eine messbare Grundlage bekommen.
Warum klassische File Services an der Unternehmensgrenze enden
Innerhalb der eigenen Infrastruktur funktioniert das klassische Modell gut. Ein Benutzer greift per SMB auf einen File Server oder ein NAS-System zu und erhält entsprechend seiner Berechtigungen Zugriff auf Dateien und Verzeichnisse. Berechtigungen kommen aus dem Verzeichnisdienst, die Datenhaltung ist eindeutig, Versionierung und Backup sind geregelt.
Sobald Personen außerhalb dieser Umgebung beteiligt werden sollen, bricht das Modell an mehreren Stellen. Externe haben kein Konto im Verzeichnisdienst. Sie sollen keinen VPN-Zugang erhalten, weil dieser typischerweise deutlich mehr öffnet als den einen benötigten Ordner. Und die Zusammenarbeit endet irgendwann, das heißt der Zugriff muss vollständig und nachweisbar wieder entzogen werden.
In der Praxis wird die Lücke dann oft mit E-Mail geschlossen – die schlechteste aller Lösungen. Jeder Anhang erzeugt eine weitere Kopie außerhalb jeder Kontrolle, Änderungen müssen manuell zusammengeführt werden, und die Frage nach dem aktuellen Versionsstand beantwortet am Ende ein Mensch aus dem Gedächtnis. File Sync & Share schafft stattdessen einen gemeinsamen, kontrollierbaren Zugriffsweg. Damit stellt sich allerdings sofort die nächste Frage: Wo befindet sich der gemeinsame Datenbestand?
Zwei grundsätzlich unterschiedliche Architekturmodelle
Für die Bewertung von File-Sync-&-Share-Lösungen ist die Unterscheidung zwischen zwei Architekturmodellen hilfreich.
Im ersten Modell ist File Sync & Share ein eigenständiger SaaS-Dienst mit eigenem Speicher. Dropbox und Microsoft OneDrive sind die bekanntesten Vertreter. Bei Dropbox werden Dateien mit der Dropbox-Infrastruktur synchronisiert; Dropbox dokumentiert eine standardmäßige Speicherung auf Servern in US-Rechenzentren und stellt für berechtigte Team-Abonnements zusätzliche Speicherregionen unter anderem innerhalb der Europäischen Union bereit. Microsoft betreibt mit OneDrive und SharePoint ebenfalls eine anbietereigene Datenplattform und hat für europäische Kunden mit der EU Data Boundary umfangreiche Data-Residency-Mechanismen geschaffen: Für erfasste Dienste verpflichtet sich Microsoft, Kundendaten und personenbezogene Daten grundsätzlich innerhalb der EU beziehungsweise EFTA zu speichern und zu verarbeiten, dokumentiert dabei aber definierte Ausnahmen. Ein europäischer Speicherort ist bei diesen Modellen also durchaus erreichbar. Was der Kunde nicht unabhängig bestimmt, ist die zugrunde liegende File- und Storage-Infrastruktur – sie ist Bestandteil des jeweiligen SaaS-Ökosystems.
Im zweiten Modell ist File Sync & Share kein eigener Speicher, sondern ein zusätzlicher Zugriffskanal auf eine bereits vorhandene File-Service-Plattform. CTERA ist hierfür ein Beispiel: CTERA Drive Share synchronisiert Dateien mit dem Global File System und stellt darauf File-Sync-&-Share-Funktionen bereit, während CTERA Drive Connect Dateien aus dem CTERA Portal direkt in Windows Explorer beziehungsweise macOS Finder einbindet. Der Storage ist dabei nicht auf einen einzelnen Cloud-Provider festgelegt; die aktuelle Herstellerdokumentation führt unter anderem Amazon S3, Microsoft Azure Blob Storage, IBM Cloud Object Storage, Hitachi Vantara HCP, Wasabi, Scality, MinIO und zahlreiche weitere S3-kompatible Systeme als mögliche Storage Nodes auf. Das Portal selbst kann im eigenen Rechenzentrum oder in einer kundenseitig kontrollierten Cloud-Umgebung betrieben werden. File Services, File Sync & Share und Storage lassen sich damit architektonisch voneinander trennen.
Vereinfacht sieht das zweite Modell so aus:
Interne und externe Nutzung werden dabei nicht auf verschiedene Datenplattformen verteilt. Ein interner Benutzer arbeitet über die vorhandenen File Services, während für einen externen Partner lediglich ein definierter Datenbereich über die Sharing-Funktion freigegeben wird. File Sync & Share wird damit von einem separaten Speicherdienst zu einer Zugriffsmethode innerhalb der Datenarchitektur.
Die entscheidende Frage: Entsteht ein zweiter Datenbestand?
Der Unterschied zwischen beiden Modellen wird besonders deutlich, wenn bereits umfangreiche Unternehmens-File-Services existieren. Angenommen, eine Marketingabteilung arbeitet intern mit einem Verzeichnis wie
\\company\marketing\agency
und eine externe Agentur benötigt regelmäßig Dateien daraus. Bei einer separaten Collaboration-Plattform entsteht dann typischerweise folgender Ablauf.
Damit existiert potenziell ein zweiter Datenbestand. Das ist nicht grundsätzlich problematisch. Wenn die SaaS-Plattform der gewünschte führende Datenbestand für diese Arbeitsprozesse sein soll, ist genau diese Architektur sinnvoll und sauber. Problematisch wird es erst, wenn die ursprünglichen File Services weiterhin maßgeblich bleiben und die Kopie nur als Übergabemechanismus gedacht war. Dann muss geklärt werden, welche Datei die aktuelle Version ist, wo eine vom externen Partner geänderte Datei gespeichert wird, wie sie zurück in die internen File Services gelangt, wer für die Synchronisation zwischen beiden Datenräumen verantwortlich ist und welcher Datenbestand letztlich führt. Je intensiver interne und externe Benutzer mit denselben Dateien arbeiten, desto teurer wird die falsche Antwort auf diese Fragen – meist nicht sofort, sondern nach zwölf bis achtzehn Monaten, wenn die manuelle Rücksynchronisation zur Routine geworden ist und niemand mehr weiß, welcher Stand wo liegt.
Datenresidenz, Schlüsselhoheit und Datenhoheit sind drei verschiedene Dinge
Für die Bewertung der Modelle ist eine saubere Trennung dieser drei Begriffe nötig.
Datenresidenz beantwortet die Frage, wo Daten gespeichert und verarbeitet werden. Das ist für regulatorische und datenschutzrechtliche Anforderungen relevant, und beide großen SaaS-Anbieter liefern hier belastbare Zusagen: Microsoft über die EU Data Boundary, Dropbox über regionale Speicheroptionen für berechtigte Team-Abonnements.
Datenhoheit fragt darüber hinaus, wer die Plattform kontrolliert. Ein Unternehmen kann bei einem SaaS-Dienst Benutzer, Berechtigungen, Freigaben und zahlreiche Sicherheitseinstellungen administrieren – die Serviceplattform selbst wird trotzdem vom Anbieter betrieben, aktualisiert und im Zweifel auch abgeschaltet.
Dazwischen liegt ein Aspekt, der in Architekturdiskussionen regelmäßig zu kurz kommt: die Schlüsselhoheit. Wenn Daten clientseitig oder auf einer kundenkontrollierten Komponente verschlüsselt werden und der Kunde die Schlüssel in einem eigenen Key-Management-System hält, verschiebt sich die Jurisdiktionsfrage erheblich. Ein Storage-Provider, der ausschließlich AES-256-verschlüsselte Objekte speichert, deren Schlüssel er nie gesehen hat, kann auf behördliche Anordnung hin auch nur diese Objekte herausgeben. Das ist kein juristischer Freibrief, aber es ist der technisch belastbarste Hebel, den eine Architektur überhaupt bietet – und er ist deutlich wirksamer als jede Aussage über den Standort eines Rechenzentrums. Entsprechend gehört in jede Bewertung die Frage, an welcher Stelle im Datenpfad verschlüsselt wird und wer die Schlüssel verwaltet.
Digital Sovereignty ist 2026 messbar geworden
Die Europäische Kommission definiert technologische Souveränität als Europas Fähigkeit, in der digitalen Welt unabhängig zu handeln, indem Schlüsseltechnologien, Daten und Infrastrukturen entwickelt und kontrolliert und Abhängigkeiten von Nicht-EU-Anbietern reduziert werden. Lange blieb das eine politische Zielformulierung ohne operative Konsequenz. Das hat sich geändert.
Im Oktober 2025 veröffentlichte die Kommission das Cloud Sovereignty Framework, eine Bewertungsmethodik für die eigene Cloud-Beschaffung. Sie definiert acht Sovereignty Objectives (SOV-1 bis SOV-8): strategische Souveränität, rechtliche und jurisdiktionelle Souveränität, Data & AI Sovereignty, Operational Sovereignty, Supply Chain Sovereignty, Technology Sovereignty, Security & Compliance sowie Environmental Sovereignty. Jedes Objective wird über eine Reihe von Einzelkriterien bewertet und einem Sovereign European Assurance Level (SEAL-0 bis SEAL-4) zugeordnet, wobei SEAL-4 eine vollständig europäische Lieferkette von den Chips bis zur Software verlangt. Angebote, die die geforderten Mindestlevel nicht über alle acht Objectives hinweg erreichen, werden ausgeschlossen.
Diese Methodik ist nicht theoretisch geblieben. Im April 2026 vergab die Kommission einen Rahmenvertrag über bis zu 180 Millionen Euro für souveräne Cloud-Services an vier europäische Anbieter; als Mindestanforderung galt SEAL-2. Wenige Wochen später, am 3. Juni 2026, folgte das European Technological Sovereignty Package mit dem Cloud and AI Development Act (CADA, COM(2026) 502) als zentralem Bestandteil, der ein EU-weites, vierstufiges Framework zur Bewertung der Souveränität von Cloud- und AI-Diensten für sensible Workloads der öffentlichen Hand einführt.
Zwei Einschränkungen gehören dazu. Erstens ist das Cloud Sovereignty Framework kein Zertifizierungsschema; SEAL-Level existieren bislang nur innerhalb konkreter Vergabeverfahren, nicht als am Markt erwerbbares Prüfsiegel. Zweitens richten sich beide Instrumente primär an die öffentliche Beschaffung. Für Unternehmen ergibt sich daraus dennoch ein praktischer Nutzen: Die acht Objectives sind eine brauchbare, bereits durchdachte Checkliste für die eigene Architekturbewertung – und wer als Zulieferer oder Dienstleister für den öffentlichen Sektor arbeitet, wird diesen Kriterien früher oder später ohnehin begegnen.
Für File Sync & Share lässt sich das auf einen Satz zusammenziehen: „Unsere Daten liegen in Europa" ist eine wichtige, aber keine vollständige Antwort auf die Souveränitätsfrage.
Wer kontrolliert Daten, Technologie und Zugang?
Aus Sicht einer File-Service-Architektur zerfällt die Souveränitätsfrage in mehrere getrennt zu beantwortende Teilfragen. Wo liegen die Daten – innerhalb der EU oder außerhalb? Wer betreibt den Storage, und kann das Unternehmen den Provider selbst auswählen, oder ist er fester Bestandteil des SaaS-Angebots? Wer betreibt die File-Service-Plattform, und läuft sie ausschließlich beim Anbieter oder auch in einer kundenseitig kontrollierten Umgebung? Wer verwaltet die Verschlüsselungsschlüssel? Von welchen externen Diensten hängt der Zugriff auf die Unternehmensdaten ab? Wie portabel sind Daten und Metadaten? Und welche technischen wie organisatorischen Abhängigkeiten bleiben bei einem Providerwechsel bestehen?
Erst wenn diese Fragen einzeln beantwortet sind, wird Digital Sovereignty von einem politischen Schlagwort zu einer konkreten technischen Eigenschaft der Gesamtarchitektur.
Ein Lehrstück: der Wegfall von Office Online Server
Wie konkret Provider-Abhängigkeit werden kann, lässt sich derzeit an einem Beispiel beobachten, das viele Organisationen unvorbereitet trifft.
Microsoft hat das Supportende für Office Online Server zum 31. Dezember 2026 angekündigt. Danach gibt es keine Sicherheitsupdates, keine Fehlerbehebungen und keinen technischen Support mehr. Office Online Server war bislang die einzige Möglichkeit, Word-, Excel- und PowerPoint-Dokumente im Browser innerhalb der eigenen Infrastruktur zu bearbeiten – genutzt vor allem von Behörden, Banken und Versicherungen, also genau von den Organisationen, für die eine Verlagerung in die Cloud regulatorisch schwierig ist. Ein On-Premises-Nachfolger ist nicht angekündigt. Bemerkenswert ist dabei, dass SharePoint Server selbst weiterhin unterstützt wird; abgeschaltet wird ausschließlich die Bearbeitungsschicht. Microsofts Empfehlung lautet, auf Microsoft 365 zu wechseln.
Aus Architektursicht ist das ein Lehrstück. Eine Funktion, die über Jahre selbstverständlich zur eigenen Infrastruktur gehörte, verschwindet nicht wegen eines technischen Problems, sondern wegen einer Produktstrategieentscheidung eines einzelnen Anbieters. Betroffene Organisationen haben darauf keinen Einfluss und keine Vorlaufzeit über die gesetzte Frist hinaus. Genau das ist gemeint, wenn von Provider-Abhängigkeit als eigenem Risikofaktor die Rede ist – nicht der behördliche Zugriff, sondern die schlichte Verfügbarkeit einer Funktion.
Wie eine Plattform mit einem solchen Ereignis umgeht, hängt davon ab, wie offen ihre Schnittstelle gebaut ist. Die Bearbeitung im Browser läuft über WOPI (Web Application Open Platform Interface), ein Protokoll, das Microsoft ursprünglich definiert hat, das aber von mehreren Anbietern implementiert wird. Wenn eine File-Service-Plattform gegen WOPI integriert statt gegen ein bestimmtes Produkt, ist der Editor austauschbar. CTERA dokumentiert genau das: Office Online Server wird bis zum 31. Dezember 2026 unterstützt, und andere Werkzeuge, die das WOPI-Protokoll unterstützen und denselben Funktionsumfang bereitstellen – ONLYOFFICE wird namentlich genannt –, können an seine Stelle treten. ONLYOFFICE Docs unterstützt WOPI seit Version 6.4; zu beachten ist, dass über WOPI der Fast-Co-Editing-Modus zur Verfügung steht, nicht der Strict-Modus mit Absatzsperre.
Damit ergibt sich eine Konstellation, die vor einem Jahr noch anders aussah: Ab Januar 2027 ist browserbasiertes Co-Authoring innerhalb der eigenen Infrastruktur nur noch über einen alternativen WOPI-Client möglich. Plattformen, deren Editor-Anbindung frei konfigurierbar ist, können das auffangen. Geschlossene SaaS-Plattformen können es per Definition nicht – dort ist der Editor Bestandteil des Dienstes.
Die allgemeine Lehre daraus ist wichtiger als der Einzelfall: Bei jeder Komponente einer File-Service-Architektur lohnt die Frage, ob sie gegen ein Protokoll oder gegen ein Produkt integriert ist. Protokolle überleben Produktentscheidungen.
Die übersehene Abhängigkeit: der Identity Provider
Ein Aspekt fehlt in den meisten Souveränitätsdiskussionen, obwohl er die praktisch härteste Abhängigkeit darstellt: die Authentifizierung.
Wer den Speicherort seiner Daten sorgfältig auswählt, den Object Storage bei einem europäischen Anbieter betreibt und die Verschlüsselungsschlüssel selbst verwaltet, hat viel erreicht – und trotzdem eine zentrale Abhängigkeit, wenn die Anmeldung sämtlicher Benutzer über einen einzigen externen Identity Provider läuft. Fällt dieser aus oder wird er unerreichbar, ist der Datenbestand technisch unverändert vorhanden und praktisch nicht nutzbar. Bei Architekturen, die eng an Microsoft 365 gekoppelt sind, ist Entra ID faktisch der eigentliche Single Point of Control, nicht der Speicher.
Für die Bewertung einer File-Sync-&-Share-Architektur heißt das konkret: Kann die Plattform gegen einen alternativen Verzeichnisdienst betrieben werden? Funktioniert der Zugriff bei Ausfall des IdP zumindest eingeschränkt weiter? Und über welchen Mechanismus authentifizieren sich externe Partner, die per Definition kein Konto im Unternehmensverzeichnis haben – über einen anbieterspezifischen Gastzugang, über Links mit Ablaufdatum, über einen föderierten Zugang? Diese Antwort entscheidet oft mehr über den tatsächlichen Lock-in als die Wahl des Storage-Backends.
Warum die Jurisdiktion des Anbieters relevant ist
Der physische Speicherort beantwortet die Jurisdiktionsfrage nicht. Ein Anbieter kann Daten in europäischen Rechenzentren speichern und gleichzeitig als Unternehmen den Rechtsvorschriften eines Drittstaates unterliegen. Dabei müssen zwei Risiken sauber getrennt werden.
Das erste betrifft den staatlichen Zugriff auf Daten. Ob und unter welchen Voraussetzungen ein Provider Daten an Behörden herausgeben muss, hängt von den anwendbaren Rechtsvorschriften und dem konkreten Fall ab. Hier ist die oben beschriebene Schlüsselhoheit der wirksamste architektonische Hebel.
Das zweite betrifft die Verfügbarkeit des Dienstes selbst. Auch ein technisch einwandfrei funktionierender Cloud-Service kann rechtlichen Beschränkungen unterliegen, die bestimmen, wem ein Anbieter seine Dienste überhaupt bereitstellen darf. Gegen dieses Risiko hilft Verschlüsselung nicht – hier zählt allein, ob der Dienst auch ohne die laufende Mitwirkung des Anbieters weiterläuft.
Für eine Architekturentscheidung bedeutet das nicht, dass außereuropäische Cloud-Services grundsätzlich ungeeignet wären. Es bedeutet, dass Jurisdiktion und Provider-Abhängigkeit als eigene Risikofaktoren zu betrachten sind, neben und nicht anstelle von Performance, Security und Datenresidenz.
Portabilität gehört zur Souveränität
Die Europäische Union behandelt den Wechsel zwischen Cloud-Anbietern inzwischen als regulatorisches Thema. Der EU Data Act (Verordnung (EU) 2023/2854) enthält in Kapitel VI Vorgaben zum Wechsel zwischen Datenverarbeitungsdiensten und zum Abbau technischer wie vertraglicher Hindernisse. Artikel 29 sieht die schrittweise Abschaffung von Wechselentgelten vor: Bis zum 12. Januar 2027 dürfen Anbieter nur ermäßigte, kostendeckende Entgelte erheben, ab diesem Datum keine mehr.
Das beseitigt einen technischen Vendor Lock-in nicht. Eine Architektur kann weiterhin stark von proprietären Schnittstellen, Identitätsdiensten, Datenmodellen oder Metadatenstrukturen eines einzelnen Anbieters abhängig sein – und genau diese Abhängigkeiten sind es, die eine Migration teuer machen, nicht die Ausstiegsgebühr. Für File Sync & Share sollte deshalb bereits bei der Einführung geprüft werden, wie man die Plattform später wieder verlässt: Welche Daten lassen sich exportieren, welche Metadaten, welche Berechtigungsstrukturen, welche Versionshistorie? Diese Frage gehört genauso zur Architektur wie die Frage nach der Einführung.
Die fünf Ansätze im Einzelnen
Ein Vergleich anhand von Funktionen wie Sync, Sharing, Mobile Access oder Offline Access greift zu kurz. Aussagekräftiger ist die Frage, wo Control Plane, Data Plane und Storage jeweils liegen.
Microsoft OneDrive und SharePoint
OneDrive und SharePoint sind eng in Microsoft 365 integriert. Für Unternehmen, die Microsoft 365 als zentrale Collaboration- und Datenplattform einsetzen wollen, ist genau diese Integration das entscheidende Merkmal – Co-Authoring, Teams, Purview-Governance und Rechteverwaltung greifen ineinander, und nichts davon lässt sich in vergleichbarer Tiefe nachbauen.
Der Preis dafür ist Geschlossenheit. Storage, Serviceplattform, Identität und wesentliche Collaboration-Funktionen bleiben Bestandteil des Microsoft-Ökosystems. Die Data-Residency- und EU-Data-Boundary-Zusagen adressieren die Residenzfrage sehr weitgehend, die Kontrollfrage adressieren sie nicht. Wer diesen Weg geht, sollte ihn bewusst gehen: SharePoint als führenden Datenbestand zu etablieren ist eine tragfähige Architekturentscheidung, SharePoint zusätzlich neben bestehende File Services zu stellen dagegen selten.
Dropbox
Dropbox ist eine cloud-zentrierte Plattform, die Storage, Synchronisation und Sharing als SaaS-Service bereitstellt. Die Benutzerführung ist nach wie vor die beste im Feld, und für berechtigte Business-Kunden stehen unterschiedliche Speicherregionen einschließlich der Europäischen Union zur Verfügung.
Architektonisch bleibt es das reinste Beispiel für Modell 1: Der SaaS-Dienst selbst ist die Datenplattform. Für Unternehmen, deren Dateien ohnehin dort leben sollen, ist das schlüssig. Als Ergänzung zu vorhandenen Enterprise File Services erzeugt Dropbox nahezu zwangsläufig den zweiten Datenbestand.
CTERA
CTERA verfolgt den entgegengesetzten Ansatz. File Sync & Share ist Bestandteil einer umfassenderen File-Service-Plattform und setzt auf demselben Global File System auf wie SMB-Zugriff, Desktop-Einbindung und Browser-Zugang. Der zugrunde liegende Storage wird unabhängig ausgewählt; dokumentiert ist eine breite Palette von Public-, Private- und S3-kompatiblen Object-Storage-Systemen.
Der aus Souveränitätssicht wesentliche Punkt ist die Betriebsumgebung des CTERA Portal. Es lässt sich vollständig on-premises oder in einer Virtual Private Cloud des Kunden betreiben – also hinter der eigenen Firewall. Damit existiert für den laufenden Betrieb keine Abhängigkeit von einer anbieterbetriebenen Cloud-Instanz: Control Plane, Data Plane und Storage liegen in der Umgebung des Kunden. Ergänzend verschlüsselt CTERA quellseitig mit AES-256, wobei die Schlüssel beim Kunden erzeugt und verwaltet werden, optional über ein angebundenes externes Key-Management-System. Bei unterstützten Storage Nodes lässt sich zudem ein Direct Mode einsetzen; für Wasabi ist dokumentiert, dass Uploads und Downloads dabei direkt zwischen Client beziehungsweise CTERA-Komponente und Storage Node erfolgen und nicht über das Portal laufen. Management-Funktionen und eigentlicher Datenpfad sind damit sauber getrennt.
Auf der Funktionsseite ist die Zusammenarbeit vollständig in dieselbe Plattform integriert statt als Zusatzmodul angebunden. CTERA Drive Connect stellt den VPN-losen Zugriff über Windows Explorer und macOS Finder bereit, Drive Share die Freigabe an interne wie externe Empfänger. Für externe Einladungen lässt sich eine Authentifizierung erzwingen, bei der der Empfänger bei jedem Zugriff einen sechsstelligen Passcode per E-Mail erhält – eine versehentlich weitergeleitete Einladung wird damit wertlos. Office-Dokumente lassen sich im Browser bearbeiten, mit Co-Authoring für bis zu zwanzig gleichzeitige Bearbeiter, und das Portal kann als Anwendung in Microsoft Teams eingebunden werden, sodass Freigaben direkt aus Channels und Chats heraus entstehen.
Ehrlicherweise gehört dazu: Eine On-Premises-Installation beseitigt die Betriebsabhängigkeit, nicht die Herstellerabhängigkeit. Lizenzierung, Support, Sicherheitsupdates und die Weiterentwicklung des Produkts bleiben beim Anbieter, und CTERA ist ein Unternehmen mit Sitz in New York und Israel. Optionale Zusatzdienste wie CTERA Insight werden als Cloud-Service betrieben und sollten bei entsprechenden Anforderungen bewusst mitbewertet werden. Der Unterschied zu einem SaaS-Modell bleibt dennoch substanziell: Ein laufendes System arbeitet auch dann weiter, wenn die Verbindung zum Hersteller unterbrochen ist.
Nasuni
Nasuni gehört ebenfalls in die Kategorie der globalen File Services und ist CTERA architektonisch näher als jeder SaaS-Anbieter. Das UniFS-Dateisystem lebt vollständig im Object Storage; Dateien, Metadaten und Verzeichnisstrukturen werden als Objekte abgelegt, während Nasuni Edge Appliances – virtuell oder als Hardware – an den Standorten die aktiv genutzten Dateien cachen und per SMB und NFS bereitstellen. Als Object Storage unterstützt Nasuni neben den Hyperscalern eine Reihe privater Systeme, darunter Cloudian HyperStore, Dell ECS, Hitachi HCP, IBM Cloud Object Storage, NetApp StorageGRID, Nutanix Objects, Pure Storage FlashBlade, Scality RING und Quantum ActiveScale. Verschlüsselt wird mit kundeneigenen Schlüsseln, bevor Daten die Edge Appliance verlassen. Ein reiner On-Premises-Betrieb mit privatem Object Storage ist ausdrücklich vorgesehen.
Die File-Sharing-Funktionen liefert das Add-on Nasuni Access Anywhere, das VPN-loses Arbeiten, Desktop-Synchronisation, externe Freigaben und eine Teams-Integration bereitstellt. Auch dieser Server wird als kundenseitige VM im eigenen Rechenzentrum oder in der eigenen Cloud betrieben, wahlweise als Einzelinstanz oder als mehrknotige Konfiguration hinter einem Load Balancer.
Der Unterschied zu CTERA liegt an einer Stelle, die man in Datenblättern leicht überliest: Nasuni trennt Control Path und Data Path bewusst, betreibt Teile des Control Path aber als eigenen Cloud-Dienst. Global File Locking und die beschleunigte Propagierung von Änderungen zwischen Standorten laufen über eine von Nasuni betriebene Orchestrierung. Für die reine Datensouveränität ist das unkritisch – Nutzdaten bleiben verschlüsselt im gewählten Storage. Für die Betriebssouveränität ist es relevant, weil zentrale Funktionen des verteilten Betriebs an der Verfügbarkeit eines Herstellerdienstes hängen. Wer Nasuni unter Souveränitätsgesichtspunkten bewertet, sollte für die konkret vorgesehene Deployment-Variante beim Hersteller schriftlich klären lassen, welche Komponenten zwingend mit Nasuni-Diensten kommunizieren und was bei deren Ausfall passiert. Mit der Übernahme von Resilio im März 2026 hat Nasuni die Synchronisations- und Edge-Beschleunigungstechnologie erweitert; wie sich das auf die Verteilung von Control- und Data-Path-Funktionen auswirkt, sollte bei aktuellen Projekten anhand der jeweils gültigen Dokumentation geprüft werden.
Als Einordnung: Nasuni ist eine sehr solide Wahl für global verteilte File Services mit starkem Fokus auf Multi-Site-Collaboration und Ransomware-Resilienz. Für Organisationen, deren primäres Kriterium ein vollständig herstellerunabhängiger Betrieb hinter der eigenen Firewall ist, ist CTERA die konsequentere Architektur.
Egnyte
Egnyte wird häufig in einem Atemzug mit CTERA und Nasuni genannt, gehört architektonisch aber auf die andere Seite der Trennlinie. Die Egnyte-Cloud ist der führende Datenbestand und die Control Plane; alles andere ordnet sich diesem Zentrum unter. Egnyte betreibt seit Langem ein europäisches Rechenzentrum in Amsterdam, und über den Public Cloud Connector können Kunden eigene Buckets bei AWS, Azure oder Google als Speicherziel hinterlegen – wobei Egnyte die Inhalte dort verschlüsselt ablegt, sodass ein nativer Zugriff auf die Dateien über die Konsole des jeweiligen Cloud-Providers nicht möglich ist. Storage Sync bindet zusätzlich vorhandene NAS-Systeme und File Server an und synchronisiert sie mit der Cloud.
Was daraus folgt, ist eine Zwischenposition mit klarem Schwerpunkt. Egnyte ist stärker als reine Sync-Plattformen, weil es lokale Repositories einbindet, Berechtigungsstrukturen über beide Welten hinweg konsistent hält und mit Governance, Klassifizierung und Compliance-Reporting Funktionen mitbringt, die in regulierten Branchen echten Aufwand ersparen. Es ist aber keine Architektur, die File Services vom Anbieter entkoppelt: Die Steuerungsebene bleibt ein SaaS-Dienst eines US-Unternehmens mit Sitz in Mountain View, und „Bring Your Own Bucket" verschiebt die Datenresidenz, nicht die Kontrolle über die Plattform.
Damit ist Egnyte eine gute Wahl für Organisationen, die eine Cloud-geführte Content-Plattform mit starker Governance suchen und ihre On-Premises-Bestände schrittweise anbinden wollen. Für Organisationen, deren Anforderung lautet, dass die File-Service-Plattform selbst im eigenen Verantwortungsbereich läuft, ist es die falsche Kategorie.
Marktvergleich auf einen Blick
So lesen Sie den Vergleich: Drei Ebenen entscheiden: Steuerungsebene, Datenpfad und Storage. Der Funktionsumfang ist nachrangig. Die Jurisdiktion fällt bei allen fünf Anbietern gleich aus. Sie ist deshalb kein Unterscheidungsmerkmal, sondern der Grund, warum Betriebsmodell und Schlüsselhoheit den Ausschlag geben.
Dropbox
Modell: SaaS-Plattform Steuerungsebene: Anbieter Datenpfad: Anbieter Storage: Anbieter, fest Schlüssel: Anbieter Browser-Editing on-prem: nicht möglich Stärke: beste Bedienung für externe Empfänger Grenze: erzeugt neben File Services einen zweiten Datenbestand
Microsoft OneDrive und SharePoint
Modell: SaaS-Plattform Steuerungsebene: Anbieter Datenpfad: Anbieter Storage: Anbieter, Azure Schlüssel: Customer Key möglich Browser-Editing on-prem: entfällt ab 2027 Stärke: tiefste Office-, Teams- und Purview-Integration Grenze: Storage, Plattform und Identität bleiben im Microsoft-Ökosystem
Egnyte
Modell: SaaS-Plattform mit Hybrid-Anbindung Steuerungsebene: Anbieter Datenpfad: Anbieter Storage: eigener Bucket möglich, Inhalte von Egnyte verschlüsselt Schlüssel: Anbieter Browser-Editing on-prem: nicht möglich Stärke: Governance, Klassifizierung, Compliance-Reporting Grenze: die Plattform selbst bleibt ein SaaS-Dienst
Nasui
Modell: File-Service-Architektur Steuerungsebene: teilweise Kunde, Locking beim Hersteller Datenpfad: Kunde, Edge Appliance Storage: frei wählbar, auch privat Schlüssel: Kunde Browser-Editing on-prem: eingeschränkt Stärke: global verteilte File Services, Multi-Site, Ransomware-Resilienz Grenze: zentrale Betriebsfunktionen hängen an einem Herstellerdienst
CTERA
Modell: File-Service-Architektur Steuerungsebene: Kunde, on-prem oder VPC Datenpfad: Kunde, Edge Filer und Direct Mode Storage: frei wählbar, auch rein on-prem Schlüssel: Kunde, externes KMS anbindbar Browser-Editing on-prem: möglich, WOPI-Client frei wählbar Stärke: vollständiger Betrieb hinter der eigenen Firewall Grenze: höchster Eigenbetriebsaufwand, Herstellerabhängigkeit bleibt
Der geringste Eigenbetriebsaufwand liegt bei den SaaS-Plattformen. Wer Kontrolle gewinnt, übernimmt Betrieb. Souveränität entscheidet sich nicht am Firmensitz, sondern am Betriebsmodell und an der Schlüsselhoheit.
Was in Projekten tatsächlich schwierig wird
Die Architekturfrage entscheidet sich selten an der Technik allein. In der Praxis sind es wiederkehrende Details, die ein Projekt aufhalten – und die in Produktvergleichen kaum vorkommen.
Das häufigste Problem ist die Berechtigungsabbildung für externe Benutzer. Interne Rechte kommen aus dem Verzeichnisdienst und sind gewachsen, oft über Jahre, oft mit verschachtelten Gruppen. Ein externer Partner hat dort kein Konto. Damit muss für jede Freigabe entschieden werden, ob eine parallele Rechtestruktur entsteht – die gepflegt werden will – oder ob externe Zugriffe über einen eigenen Mechanismus abgebildet werden, der von den internen Rechten entkoppelt ist. Beide Wege funktionieren, aber sie müssen bewusst gewählt werden, sonst entsteht schleichend eine dritte, undokumentierte Rechteebene.
Das zweitwichtigste ist das Offboarding. Der Zugriff eines externen Partners muss nach Projektende vollständig entzogen werden, und zwar nachweisbar. Freigabelinks ohne Ablaufdatum sind der Klassiker: Sie werden vergeben, geraten in Vergessenheit und funktionieren Jahre später noch. Eine Plattform sollte Ablaufdaten erzwingen können, nicht nur anbieten, und eine Übersicht aller aktiven externen Freigaben liefern, die auch ohne Auswertung von Logdateien lesbar ist.
Drittens die Rücksynchronisation. Sobald ein zweiter Datenbestand existiert, entsteht die Frage, wie geänderte Dateien zurückkommen. Wird das nicht technisch gelöst, löst es jemand manuell – und manuelle Rücksynchronisation ist der Punkt, an dem Versionsstände auseinanderlaufen.
Viertens die Dateigrößen und Formate. Konstruktionsunterlagen, Renderings und Videomaterial verhalten sich anders als Office-Dokumente. Ein Sync-Client, der eine 4-GB-Datei bei jeder Änderung vollständig überträgt, macht eine Zusammenarbeit über eine normale Standleitung unbrauchbar. Delta-Übertragung, Locking-Verhalten und das Verhalten bei gleichzeitigen Änderungen gehören deshalb in jeden Proof of Concept – und zwar mit echten Dateien aus dem Projekt, nicht mit Testdaten.
Die Anforderungen unterscheiden sich je nach Fall erheblich. Eine Rechtsabteilung, die mit einer Kanzlei zusammenarbeitet, braucht einen eng abgegrenzten Datenbereich mit lückenloser Nachvollziehbarkeit. Eine Marketingabteilung braucht vor allem, dass ein neuer Freelancer innerhalb von Minuten arbeitsfähig ist. Ein Fertigungsunternehmen braucht einen Datenaustausch, der über Monate im laufenden Entwicklungsprozess mitläuft. Die zugrunde liegende Architekturfrage ist trotzdem in allen drei Fällen dieselbe: Müssen Unternehmensdaten für die Zusammenarbeit auf eine separate Plattform kopiert werden, oder kann der externe Zugriff kontrolliert auf den bestehenden File Services aufsetzen?
Welche Fragen sollten vor der Einführung beantwortet werden?
Bevor Produkte verglichen werden, sollte die gewünschte Datenarchitektur definiert sein.
1. Wo befindet sich heute der führende Datenbestand? Liegen die relevanten Dateien auf klassischen File Services, bereits in einer Collaboration-Plattform oder verteilt auf mehreren Systemen?
2. Wo soll er zukünftig liegen? Soll die Collaboration-Plattform selbst zum primären Speicher werden, oder sollen die bestehenden File Services führend bleiben?
3. Entsteht für File Sharing eine zusätzliche Datenkopie? Wenn ja: Wie werden Versionen, Änderungen und Rückübertragung kontrolliert – technisch, nicht organisatorisch?
4. Wer bestimmt den Storage? Ist er Bestandteil des SaaS-Angebots, oder können Provider, Region und Technologie selbst gewählt werden?
5. Wer verwaltet die Verschlüsselungsschlüssel? An welcher Stelle im Datenpfad wird verschlüsselt, und kann ein eigenes Key-Management-System angebunden werden?
6. Wovon hängt die Authentifizierung ab? Welcher Identity Provider ist im Spiel, wie werden externe Benutzer authentifiziert, und was passiert bei dessen Ausfall?
7. Wie werden externe Benutzer eingebunden und wieder entfernt? Welche Datenbereiche sehen sie, welche Ablaufmechanismen greifen automatisch, und wie lässt sich der Bestand aktiver Freigaben prüfen?
8. Welche Souveränitätsanforderungen bestehen tatsächlich? Die acht Objectives des Cloud Sovereignty Framework sind hierfür eine brauchbare Gliederung, auch außerhalb der öffentlichen Beschaffung.
9. Wie funktioniert ein späterer Providerwechsel? Welche Daten, Metadaten, Berechtigungen und Versionsstände lassen sich exportieren, und welche Abhängigkeiten bleiben?
Erst danach lohnt sich die Produktauswahl.
Fazit
File Sync & Share wird meist über seine sichtbaren Funktionen bewertet: Dateien synchronisieren, Ordner teilen, mobil arbeiten, externe Benutzer einladen. Für eine Enterprise-Architektur reicht das nicht, weil ähnliche Benutzerfunktionen auf grundlegend verschiedenen Daten- und Betriebsmodellen beruhen können. Entscheidend ist, welche Rolle File Sync & Share innerhalb der gesamten Datenarchitektur übernimmt – eigenständige Datenplattform oder zusätzlicher Zugriffskanal auf bestehende File Services.
Soll eine SaaS-Collaboration-Plattform zum neuen führenden Datenbestand werden, bieten Microsoft OneDrive, SharePoint, Dropbox und Egnyte dafür ausgereifte Funktionen und eng integrierte Ökosysteme. Sollen dagegen vorhandene File Services die Grundlage bleiben, gewinnen Architekturen an Bedeutung, die File Services, Sharing und Storage voneinander entkoppeln – mit Nasuni und CTERA als den beiden ernsthaften Vertretern, wobei sich beide vor allem darin unterscheiden, wie viel Betrieb ohne Mitwirkung des Herstellers möglich bleibt.
Mit der europäischen Souveränitätsdiskussion kommt eine Dimension hinzu, die seit 2026 nicht mehr rein politisch ist. Die Frage ist nicht mehr nur, wo Daten gespeichert werden, sondern wer Storage, Plattform, Schlüssel und Zugang kontrolliert, welcher Jurisdiktion die beteiligten Anbieter unterliegen und wie stark die Dateninfrastruktur von einzelnen Providern abhängt. Aus einer scheinbar einfachen Frage – „Wie teilen wir Dateien?" – wird damit eine grundlegende Architekturentscheidung: Wo liegen unsere Daten, wer kontrolliert sie, und wie unabhängig wollen wir bleiben?
Quellen
Europäische Union
Europäische Kommission: Cloud Sovereignty Framework, Version 1.2.1, Oktober 2025 (acht Sovereignty Objectives SOV-1 bis SOV-8, Sovereign European Assurance Levels SEAL-0 bis SEAL-4).
Europäische Kommission: Sovereign Cloud Framework explained, 1. Juni 2026 (48 Einzelkriterien, acht Kategorien).
Europäische Kommission: Commission awards €180 million tender for sovereign cloud services, IP/26/833, April 2026 (Vergabe an vier europäische Anbieter, Mindestniveau SEAL-2).
Europäische Kommission: Strengthening Europe's Tech Sovereignty, 3. Juni 2026, sowie Pressemitteilung IP/26/1187.
Europäische Kommission: Proposal for a Cloud and AI Development Act (CADA), COM(2026) 502, 3. Juni 2026.
Europäische Union: Verordnung (EU) 2023/2854 (Data Act), Kapitel VI, insbesondere Artikel 23 ff. und Artikel 29 (Wegfall der Wechselentgelte ab 12. Januar 2027).
Hersteller
Microsoft: EU Data Boundary, Microsoft Trust Center.
Microsoft Learn: Data Residency for SharePoint and OneDrive.
Microsoft: Announcing the retirement for Office Online Server, Microsoft Community Hub, 21. Oktober 2025 (Supportende 31. Dezember 2026).
Microsoft Learn: Office Online Server – Microsoft Lifecycle.
ONLYOFFICE: Using WOPI – Overview, ONLYOFFICE API-Dokumentation (WOPI-Unterstützung ab Version 6.4, Fast-Co-Editing über WOPI).
Dropbox: Angaben zu Data Residency und Speicherregionen.
CTERA: CTERA Drive, CTERA Drive Share Functionality, About CTERA Portal, Managing Storage Nodes, Adding and Editing Storage Nodes, Wasabi Cloud Storage (S3), CTERA Knowledge Base.
CTERA: Security – Introduction to Team Portal Administration, CTERA Knowledge Base (Deployment on-premises oder VPC hinter der Firewall, AES-256, FIPS 140-3).
CTERA: Setting Up Key Management for a CTERA Portal, CTERA Knowledge Base.
CTERA: Office 365 Integration und Editing and Creating Files, CTERA Knowledge Base (WOPI-Anbindung, Co-Authoring bis 20 Bearbeiter; Hinweis auf ONLYOFFICE als Alternative nach dem Supportende von Office Online Server).
CTERA: Access CTERA Portal as a Tab in Microsoft Teams, CTERA Knowledge Base.
CTERA: Configuring Team Portal Settings, CTERA Knowledge Base (Authentifizierungsoptionen für externe Collaboration, Passcode-Challenge).
CTERA: Platform Security Architecture, White Paper.
Nasuni: Chapter 1 – Introducing Nasuni und Edge Appliance Data Sheet, Nasuni Documentation (UniFS, Edge Appliances, unterstützte Object-Storage-Systeme, kundeneigene Schlüssel).
Nasuni: Nasuni File Data Platform Security Model, White Paper (Trennung von Control Path und Data Path).
Nasuni: Access Anywhere – Architecture and Sizing sowie Access Anywhere – Getting Started, Nasuni Documentation.
Nasuni: Pressemitteilung zur Übernahme von Resilio, 4. März 2026.
Egnyte: Public Cloud Connector Overview und Storage Sync Overview, Egnyte Helpdesk.
Egnyte: Customize Your Cloud Storage on Egnyte, Egnyte Helpdesk.
Welche Entscheidung steht bei Ihnen an?
Sie möchten eine bestehende Infrastruktur bewerten, eine neue Architektur planen oder eine konkrete technische Fragestellung klären? Sprechen Sie mit uns über Ihre Anforderungen.
Spezialist für moderne Dateninfrastruktur
