Bereitstellungsmodelle für regulierte Unternehmen: Vergleich von Souveränität und Compliance-Auswirkungen

Regulierte Unternehmen stehen vor einem strukturellen Problem, wenn sie Enterprise-Filesharing- und Content-Plattformen bewerten: Die Frage lautet nie einfach „Welches Bereitstellungsmodell ist am sichersten?“, sondern vielmehr „Welches Bereitstellungsmodell bietet uns die erforderliche Souveränität, Zertifizierungsabdeckung und operative Kontrolle, die unser regulatorisches Umfeld verlangt – und was ändert sich konkret, wenn wir zwischen den Modellen wechseln?“

Die Antwort ist komplexer, als Anbieter üblicherweise zugeben. On-Premises-, Private-Cloud-, FedRAMP-zertifizierte Cloud-, Hybrid- und Air-Gapped-Bereitstellungen nutzen im Kern ähnliche Technologien. Doch ihre Compliance-Abdeckung, Datenresidenz-Garantien, operative Kontrolle durch den Kunden und Souveränitätsauswirkungen unterscheiden sich in entscheidenden Punkten – mit erheblichen Auswirkungen für Einkaufsteams, Datenschutzbeauftragte und Security-Architekten. Eine Zertifizierung, die für ein Bereitstellungsmodell gilt, ist nicht automatisch auf ein anderes übertragbar. Eine EU-Datenresidenz-Zusage, die für SaaS gilt, kann bei einem anderen Bereitstellungsmodell eine vertragliche Nachverhandlung erfordern.

Dieser Beitrag stellt diese Unterschiede dar. Er zeigt, was jedes Bereitstellungsmodell in Bezug auf Souveränität tatsächlich bedeutet, welche Zertifizierungen wo gelten und welche Fragen Einkaufsteams stellen müssen, um die Dokumentationslücken zu schließen, die viele Anbieter offenlassen. Die Analyse richtet sich an Teams, die Plattformen für regulierte Workloads – Verteidigung, Finanzdienstleistungen, Gesundheitswesen, kritische Infrastrukturen – evaluieren, bei denen die Wahl des Bereitstellungsmodells eine Compliance-Entscheidung ist und keine reine Architekturpräferenz.

Executive Summary

Kernaussage: Unterschiedliche Bereitstellungsmodelle haben erhebliche Auswirkungen auf Souveränität und Compliance – nicht nur theoretisch, sondern in Bezug auf Zertifizierungsumfang, Datenresidenz-Garantien und operative Kontrolle durch den Kunden. Einkaufsteams benötigen eine bereichsspezifische Sicht auf die Compliance-Abdeckung, nicht einfach eine Zertifikatsliste, die eine einheitliche Gültigkeit für alle Bereitstellungsoptionen suggeriert.

Warum das relevant ist: NIS 2, DORA und Rahmenwerke wie BSI C5, IRAP und G-Cloud 14 verpflichten Unternehmen dazu, nachzuweisen, dass die genutzten Kontrollen tatsächlich für das spezifische Bereitstellungsmodell zertifiziert sind. Eine BSI C5-Zertifizierung für einen Managed-Cloud-Service deckt nicht automatisch eine On-Premises-Appliance ab – und umgekehrt. Um diese Lücke zu schließen, müssen Anbieter eine Paritätsmatrix veröffentlichen – und Unternehmen diese einfordern –, die Zertifizierungen den Bereitstellungsmodellen zuordnet. Die meisten Anbieter tun das derzeit nicht.

5 Wichtige Erkenntnisse

1. Die Wahl des Bereitstellungsmodells ist eine Compliance-Entscheidung, nicht nur eine Architekturfrage. Das gewählte Modell bestimmt, welche Zertifizierungen gelten, welche Datenresidenz erreichbar ist, wer operative Kontrollpflichten trägt und ob das Unternehmen Audit-Nachweise eigenständig erbringen kann. Diese regulatorischen Fragen müssen vor der finalen technischen Architektur beantwortet werden – nicht danach.
2. Zertifizierungen sind nicht automatisch auf alle Bereitstellungsmodelle übertragbar. Ein Anbieter mit BSI C5 Type 2-, ISO 27001– und SOC 2 Type II-Zertifizierung hat diese Nachweise möglicherweise für eine bestimmte Managed-Cloud-Umgebung erhalten. Die On-Premises-Appliance desselben Anbieters kann je nach Zertifizierungsumfang einige, alle oder keine dieser Nachweise tragen. Einkaufsteams müssen explizit nachfragen: Welche Zertifizierungen gelten für welches Bereitstellungsmodell?
3. EU-exklusive Datenresidenz ist mit On-Premises-Bereitstellung wirklich erreichbar – für SaaS ist sorgfältige Prüfung nötig. Bei On-Premises-Bereitstellung auf kundeneigener Infrastruktur in einem EU-Mitgliedstaat verbleiben die Daten physisch und rechtlich in dieser Jurisdiktion, ohne Abhängigkeit von Anbieter-Infrastruktur oder Routing. SaaS- und Private-Cloud-Modelle erfordern vertragliche Zusagen für EU-Regionen und die Überprüfung, dass Anbieterbetrieb, Subunternehmer und Support-Zugriffe keine Drittlandtransfers im Sinne der DSGVO Kapitel V auslösen.
4. Air-Gapped-Bereitstellungen bieten die stärksten Souveränitätsgarantien, verursachen aber den höchsten operativen Aufwand. Keine externe Konnektivität bedeutet keinen cloudbasierten Anbieterzugriff, keine Telemetrie verlässt die Umgebung und keine automatischen Updates – das eliminiert eine Klasse von Souveränitätsrisiken, überträgt aber die gesamte Verantwortung für Patching, Monitoring und Incident Response auf den Kunden. Für Verteidigungs- und Geheimdienst-Workloads ist dieser Trade-off oft nicht verhandelbar. Für die meisten regulierten Unternehmen ist eine gehärtete Appliance mit kontrollierter Konnektivität ein praktikablerer Kompromiss.
5. Eine konsolidierte Zertifizierungs-Paritätsmatrix existiert am Markt noch nicht – und ihr Fehlen ist ein Beschaffungsrisiko. Die meisten Plattformen veröffentlichen Compliance-Seiten mit globalen Zertifikatslisten, ohne zu spezifizieren, welche für welches Bereitstellungsmodell gelten. Einkaufsteams, die eine globale Zertifikatsliste akzeptieren, ohne sie auf ihr spezifisches Bereitstellungsmodell zu beziehen, verlassen sich möglicherweise auf Nachweise, die ihre tatsächlich genutzte Umgebung nicht abdecken. Die richtige Beschaffungsstrategie ist, von jedem Anbieter eine deploymentspezifische Zertifizierungsumfangserklärung einzufordern.

Was die Wahl des Bereitstellungsmodells tatsächlich bestimmt

Bevor einzelne Modelle verglichen werden, lohnt es sich, genau zu betrachten, was sich ändert – und was nicht –, wenn man zwischen Bereitstellungsoptionen für eine Enterprise-Filesharing-Plattform wechselt. Diese Unterscheidung bestimmt, welche Fragen Einkaufsteams stellen müssen und welche Aussagen Anbieter legitim treffen können.

Was sich zwischen Bereitstellungsmodellen ändert

Vier Aspekte ändern sich maßgeblich, wenn sich das Bereitstellungsmodell ändert: Wer kontrolliert die Infrastruktur, wo Daten physisch gespeichert und geroutet werden, welche Zertifizierungsumfänge gelten und wer die operative Verantwortung für Verfügbarkeit und Sicherheit trägt.

Die Infrastrukturkontrolle bestimmt, ob der Kunde oder der Anbieter über Patch-Zyklen, Konfigurationsänderungen, Hardware-Beschaffung und physische Access Controls entscheidet. Die Datenresidenz bestimmt, wo Daten gespeichert werden und ob sie Netzwerke durchlaufen, die ausländischer Rechtsprechung unterliegen. Der Zertifizierungsumfang legt fest, ob die Drittanbieter-Nachweise des Anbieters tatsächlich die vom Kunden genutzte Betriebsumgebung abdecken. Die operative Verantwortung bestimmt, wer vertraglich und regulatorisch für Betriebszeit, Incident Response und die zugrunde liegenden Kontrollen haftet.

Diese vier Dimensionen bewegen sich unabhängig voneinander. Eine Bereitstellung mit starker Infrastrukturkontrolle kann eine eingeschränkte Zertifizierungsabdeckung haben. Ein hochzertifizierter Managed Service kann schwächere Datenresidenz-Garantien bieten als eine On-Premises-Alternative. Einkaufsteams sollten jede Dimension separat bewerten, statt „Bereitstellungsmodell“ als binäre Variable zu behandeln.

Was gleich bleibt: Die Kernplattform

Kiteworks basiert auf einer einzigen gehärteten virtuellen Appliance, die allen Bereitstellungsmodellen zugrunde liegt – On-Premises, Private Cloud, FedRAMP-zertifizierte Cloud und Hybrid. Diese architektonische Konsistenz hat eine wichtige Compliance-Auswirkung: Die Appliance-Konfiguration, der Verschlüsselungs-Stack, das Access-Control-Framework und die Audit-Logging-Architektur sind keine unterschiedlichen Produkte mit unterschiedlichen Sicherheitsniveaus. Es handelt sich um dieselbe Plattform in verschiedenen Betriebsumgebungen.

Diese Konsistenz ist relevant, weil die Kontrollen, die ein Einkaufsteam bei der Evaluierung eines Bereitstellungsmodells prüft, substanziell dieselben sind, auf die es sich bei einem anderen Modell verlassen würde. Die Variablen sind die Betriebsumgebung, der Zertifizierungsumfang und die Verteilung der operativen Verantwortung – nicht die zugrunde liegende Sicherheitsarchitektur.

On-Premises-Bereitstellung: Maximale Souveränität, maximale operative Verantwortung

On-Premises-Bereitstellung – konkret über eine gehärtete virtuelle Appliance auf kundengesteuerter Hardware – bietet die höchstmögliche Souveränitätsstufe für Enterprise-Filesharing. Um das zu verstehen, muss man wissen, was Souveränität in diesem Kontext bedeutet – und was sie kostet.

Was On-Premises-Bereitstellung bietet

Betreibt ein reguliertes Unternehmen eine On-Premises-Bereitstellung, verlassen die Daten nie die eigene Infrastruktur. Es gibt keine Anbieter-Cloud, kein Drittanbieter-Rechenzentrum und kein vom Anbieter betriebenes Netzwerk, durch das Inhalte geroutet werden. Physische und logische Access Controls liegen vollständig im Verantwortungsbereich des Kunden. Der Anbieter kann ohne explizite, revisionssichere Autorisierung keinen Zugriff auf die Umgebung nehmen.

Für EU-Unternehmen mit strengen DSGVO-Datenresidenzanforderungen ist dies die sauberste Lösung für die Drittlandtransfer-Frage nach Kapitel V. Daten, die auf kundeneigener Infrastruktur in einem EU-Mitgliedstaat verarbeitet und gespeichert werden, unterliegen ausschließlich EU-Recht – es besteht keine Abhängigkeit von vertraglichen Zusagen des Anbieters für EU-Regionen oder Standardvertragsklauseln, um das zu erreichen, was die Architektur strukturell sicherstellt.

Die On-Premises-Bereitstellung von Kiteworks nutzt eine gehärtete Appliance mit abgesicherter Betriebskonfiguration. Die Appliance umfasst den vollständigen Plattform-Stack – Content Management, Access Control, kryptografisches Schlüsselmanagement, Audit Logging – als integrierte Einheit auf der Kundenhardware. Kunden kontrollieren die darunterliegende Infrastrukturschicht vollständig: Server-Spezifikation, physischer Standort, Netzwerksegmentierung, Backup-Architektur und Patch-Plan für die Infrastruktur (während Kiteworks Appliance-Updates bereitstellt).

Zertifizierungen für On-Premises-Bereitstellung

Kiteworks verfügt über folgende Zertifizierungen, die für On-Premises-Kontexte relevant sind. Einkaufsteams sollten beachten, dass der Zertifizierungsumfang variiert – einige Nachweise beziehen sich auf die Produktarchitektur und Sicherheitskontrollen, andere auf Managed-Service-Betrieb.

Die ehrliche Einschätzung zu dieser Tabelle: Zertifizierungsumfang muss direkt mit Kiteworks und den jeweiligen Zertifizierungsstellen geklärt werden. Eine konsolidierte, öffentlich verfügbare Paritätsmatrix, die jede Zertifizierung jedem Bereitstellungsmodell zuordnet, existiert derzeit nicht. Dies ist eine Dokumentationslücke, die Einkaufsteams explizit ansprechen sollten – und die Kiteworks aufgrund der gemeinsamen Appliance-Architektur über alle Bereitstellungsmodelle hinweg adressieren kann.

Quellcode und Escrow für On-Premises

On-Premises-Bereitstellung schafft eine Abhängigkeit, die Managed-Cloud-Delivery nicht hat: Was passiert mit der Plattform, wenn der Anbieter übernommen wird, insolvent geht oder das Produkt einstellt? Für regulierte Unternehmen, die kritische Infrastruktur auf einer gehärteten Appliance betreiben, ist dies eine regulatorisch und operativ relevante Frage.

Kiteworks bietet Software-Escrow-Vereinbarungen als Teil der kommerziellen Bedingungen für On-Premises-Kunden an. Quellcode-Escrow ermöglicht es einem unabhängigen Escrow-Agenten, den Quellcode unter definierten Bedingungen an Lizenznehmer freizugeben. Dies bietet eine zusätzliche Kontinuitätsabsicherung für Unternehmen, die über vertragliche Zusagen hinausgehende Sicherheit benötigen.

Private-Cloud-Bereitstellung: Kundeninfrastruktur, Kunden-Cloud

Private-Cloud-Bereitstellung liegt zwischen vollständigem On-Premises und vom Anbieter gemanagtem SaaS. Die Kiteworks-Appliance läuft auf Cloud-Infrastruktur – AWS, Azure oder GCP –, die der Kunde selbst beschafft und verwaltet. Der Anbieter betreibt die Plattformsoftware; der Kunde betreibt die Cloud-Umgebung, auf der sie läuft.

Souveränitätsauswirkungen von kundenverwalteter Cloud

Der entscheidende Unterschied zum Managed-Cloud-Modell ist die Kontrolle über das Cloud-Konto. Wenn ein reguliertes Unternehmen Kiteworks in seiner eigenen AWS- oder Azure-Umgebung betreibt, kontrolliert es die Netzwerktopologie, die IAM-Richtlinien für Zugriff auf Compute und Storage, die Regionsauswahl und das Egress-Routing. Der Anbieter kann Änderungen an der Cloud-Umgebung nur vornehmen, wenn der Kunde Zugriff gewährt – was dieser steuert und auditieren kann.

Für EU-Unternehmen ermöglicht Private-Cloud-Bereitstellung die Durchsetzung einer EU-exklusiven Region auf Infrastrukturebene – nicht nur über vertragliche Zusagen des Anbieters. Ein Unternehmen, das in einer AWS eu-west- oder Azure West Europe-Region mit Netzwerkregeln deployt, die Datenabfluss außerhalb dieser Regionen verhindern, hat eine technisch erzwungene Datenresidenz statt einer rein vertraglichen. Dieser Unterschied ist für Regulierer bei der Bewertung von Drittlandtransferrisiken nach Schrems II entscheidend.

Der Gegenaspekt: Private-Cloud-Bereitstellung bedeutet weiterhin Abhängigkeit von großen Hyperscalern – AWS, Azure oder GCP –, die alle US-Unternehmen sind und dem US CLOUD Act unterliegen. Für Unternehmen, deren Bedrohungsmodell behördlich angeordneten Zugriff der US-Regierung auf Daten bei US-Cloud-Providern umfasst, bleibt ein Souveränitätsrisiko bestehen, das On-Premises-Bereitstellung nicht hat. Das ist eine ehrliche Einschätzung des Trade-offs, keine Kritik an Kiteworks – es gilt für jede regulierte Workload auf US-Hyperscaler-Infrastruktur, unabhängig von der EFSS-Schicht.

Zertifizierungsabdeckung im Private-Cloud-Kontext

Private-Cloud-Bereitstellung auf kundenverwalteter Infrastruktur führt zu geteilter Zertifizierungsverantwortung. Zertifizierungen, die Kiteworks für seine Plattformsoftware hält – ISO 27001, BSI C5 – beziehen sich auf das Produkt und ggf. den Managed-Service-Betrieb. Sie decken nicht die Konfiguration des Kunden-Cloud-Kontos, die Netzwerkregeln oder das IAM-Governance-Modell für die Infrastruktur ab.

Das bedeutet: Ein reguliertes Unternehmen, das Kiteworks auf eigenem AWS-Account betreibt, muss zwei Zertifizierungsebenen abdecken: Plattform-Nachweise (Kiteworks) und eigene Cloud-Governance. AWS, Azure und GCP verfügen über umfangreiche Zertifizierungen (inklusive BSI C5 für europäische Regionen, ISO 27001 etc.), aber diese beziehen sich auf die Hyperscaler-Infrastruktur – nicht auf die kundenspezifische Konfiguration.

Einkaufsteams sollten diese Ebenen explizit abbilden: Plattformsoftware-Zertifizierungen (Kiteworks), Infrastrukturzertifizierungen (Hyperscaler) und Governance der Kundenkonfiguration (intern). Keine dieser Ebenen zertifiziert automatisch die jeweils anderen.

FedRAMP-zertifizierte Cloud: Höchster US-Regierungsstandard

FedRAMP (Federal Risk and Authorization Management Program) ist das Autorisierungsrahmenwerk der US-Bundesregierung für Cloud-Services. Die Autorisierungsstufen – Low, Moderate und High – spiegeln die Klassifizierung der Daten wider, die der Service verarbeiten darf. FedRAMP High ist die anspruchsvollste Stufe und deckt Controlled Unclassified Information (CUI) sowie andere sensible Regierungsdaten ab, deren unbefugte Offenlegung erheblichen Schaden verursachen würde.

Was FedRAMP High In Process praktisch bedeutet

Kiteworks hat den Status „FedRAMP High In Process“ erreicht – das heißt, der Autorisierungsprozess läuft aktiv, die finale Authorization to Operate (ATO) wurde aber noch nicht erteilt. Der Status ist öffentlich einsehbar unter fedramp.gov/marketplace/products/FR2435353186/. Organisationen, die Kiteworks für US-Beschaffung evaluieren, sollten den aktuellen Status direkt im Marketplace prüfen, da der Prozess definierte Meilensteine hat und sich der Status mit Erteilung der ATO ändert.

FedRAMP High Authorization erfordert eine unabhängige Prüfung durch eine Third Party Assessment Organization (3PAO) anhand der NIST SP 800-53 Controls auf High-Baseline – über 400 Sicherheitskontrollen zu Access Control, Konfigurationsmanagement, Incident Response, Systemintegrität und Supply Chain Risk Management u.a. Der Prozess umfasst außerdem eine Prüfung durch eine fördernde Bundesbehörde. Der Status „FedRAMP High In Process“ bedeutet, dass die ersten Prüfungen bestanden wurden; die ATO steht für die finale Freigabe durch die Behörde.

Für nicht-US-regulierte Unternehmen – insbesondere in der EU, Australien oder UK – ist FedRAMP High eine relevante Sicherheitsreferenz, auch wenn FedRAMP selbst kein Pflicht-Rahmenwerk ist. Das NIST 800-53-Controlset überschneidet sich stark mit ISO 27001, BSI C5 und IRAP. Unternehmen, die FedRAMP als Proxy für Sicherheitsniveau nutzen, sind damit auf einem soliden Fundament, sollten es aber nicht als Ersatz für die in ihrer Jurisdiktion geforderten Rahmenwerke betrachten.

Datenresidenz in der FedRAMP-Cloud

FedRAMP-zertifizierte Cloud-Bereitstellungen werden vom Anbieter – Kiteworks – auf speziell für FedRAMP-Compliance konfigurierter Infrastruktur betrieben. Der Kunde verwaltet die zugrunde liegende Infrastruktur nicht; Kiteworks übernimmt dies. Die Datenresidenz ist US-gebunden: FedRAMP verlangt Speicherung in US-Rechenzentren. Damit ist FedRAMP-Cloud-Bereitstellung keine Lösung für EU-Unternehmen mit DSGVO-Kapitel-V-Restriktionen – es handelt sich um ein US-spezifisches Compliance-Modell.

EU-Einkaufsteams sollten FedRAMP High In Process nicht mit EU-Zertifizierungsbereitschaft verwechseln. Es handelt sich um unterschiedliche Rahmenwerke für unterschiedliche regulatorische Umfelder. Für die EU sind BSI C5 (Deutschland), das kommende EUCS (EU-weites Cloud-Zertifizierungsschema unter ENISA) und nationale Zertifizierungen relevant. Kiteworks hält BSI C5 Type 2 – EUCS-Bereitschaft ist zum Zeitpunkt dieses Beitrags nicht bestätigt, Einkaufsteams sollten Kiteworks hierzu direkt ansprechen.

Hybrid-Bereitstellung: Souveränität und operative Flexibilität ausbalancieren

Hybrid-Bereitstellung kombiniert On-Premises- oder Private-Cloud-Komponenten mit vom Anbieter gemanagten Cloud-Funktionen. In der Praxis bedeutet das meist, dass bestimmte Workloads oder Datenkategorien auf kundengesteuerter Infrastruktur verbleiben, während andere in der Anbieter-Cloud laufen – die Plattform steuert die Grenze zwischen beiden.

Wann Hybrid für regulierte Unternehmen sinnvoll ist

Hybrid-Bereitstellung eignet sich besonders für Organisationen mit unterschiedlich sensiblen Daten. Ein Unternehmen kann seine sensibelsten regulierten Daten – etwa vertrauliche Verteidigungsunterlagen, Patientendaten, Vorstandsdokumente – On-Premises unter voller Kontrolle halten, während weniger sensible Kollaborations-Workloads zur einfacheren externen Zusammenarbeit in der Anbieter-Cloud laufen.

Die Souveränitäts- und Compliance-Frage bei Hybrid-Bereitstellung lautet: Welche Komponenten verarbeiten welche Datenkategorien und welche Zertifizierungs- und Residenzfolgen ergeben sich daraus? Eine Hybrid-Architektur, die hochsensible Daten durch die Anbieter-Cloud routet, kann unbeabsichtigt die Souveränitäts- und Residenzschutzmaßnahmen der On-Premises-Komponente unterlaufen. Datenfluss-Mapping ist entscheidend – nicht nur Architekturdiagramme.

Die gehärtete Appliance von Kiteworks läuft in allen Bereitstellungsmodellen, sodass die Sicherheitskontrollen der Plattform konsistent sind, unabhängig davon, welche Komponente eine Transaktion verarbeitet. Der Zertifizierungsumfang für die Hybrid-Grenze – also die Integration zwischen On-Premises- und Cloud-Komponenten – muss jedoch explizit geprüft werden. Einkaufsteams sollten Kiteworks bitten, zu spezifizieren, welche Zertifikatsnachweise das hybride Betriebsmodell abdecken – nicht nur die Einzelkomponenten isoliert.

Wichtige Beschaffungsfragen für Hybrid-Konfigurationen

Vor dem Einsatz einer Hybrid-Konfiguration für regulierte Workloads sind mehrere Fragen unverzichtbar. Bietet die Plattform eine Richtlinien-basierte Steuerung, die garantiert, dass bestimmte Datenkategorien in der On-Premises-Komponente verbleiben? Kann der Kunde anhand von Audit-Logs nachvollziehen, welche Komponente eine Transaktion verarbeitet hat? Decken die von Kiteworks gehaltenen Zertifizierungen die Integrationspunkte und Datenflüsse zwischen den Komponenten ab oder nur die Einzelkomponenten? Und – entscheidend – beinhaltet das Supportmodell für Hybrid-Bereitstellung Fernzugriff auf die On-Premises-Komponente und falls ja, unter welchen Autorisierungs- und Audit-Kontrollen?

Air-Gapped-Bereitstellung: Maximale Isolation für Hochrisiko-Umgebungen

Air-Gapped-Bereitstellung ist On-Premises-Betrieb mit einer zusätzlichen Einschränkung: keine externe Netzwerkkonnektivität. Die Plattform läuft in einer physisch und logisch isolierten Umgebung ohne Internetzugang, ohne Anbieter-Telemetrie und ohne Remote-Update-Funktion. Dieses Modell ist für klassifizierte Regierungssysteme, bestimmte Verteidigungs- und Geheimdienstumgebungen und kritische nationale Infrastrukturen gedacht, bei denen das Bedrohungsmodell explizit netzwerkbasierte Angriffe und Supply-Chain-Attacken einschließt.

Was Air-Gapping leistet – und was nicht

Eine Air-Gapped-Bereitstellung eliminiert eine ganze Kategorie von Souveränitätsrisiken: das Risiko, dass Anbieter, Subunternehmer, kompromittierte Update-Mechanismen oder staatliche Akteure über das Netzwerk auf Kundendaten zugreifen können. Es gibt keinen Remote-Zugriff, weil dieser architektonisch ausgeschlossen ist. Das ist ein strukturell anderes Sicherheitsniveau als eines, das sich auf Access Controls verlässt – hier wird die Angriffsfläche entfernt statt verteidigt.

Was Air-Gapping nicht adressiert, ist die Insider-Bedrohung im Perimeter, die Sicherheit der physischen Einrichtung, die Supply-Chain-Integrität von Hardware und Software vor der Installation und die operative Herausforderung von Updates. In einer Air-Gapped-Umgebung werden Offline-Update-Pakete über kundengesteuerte, sichere Transferverfahren bereitgestellt. Das erfordert eine strenge Patch-Disziplin: Unternehmen müssen einen rigorosen Prozess für Identifikation, Test und Einspielung von Patches ohne automatisierte Update-Mechanismen etablieren.

Kiteworks unterstützt Air-Gapped-On-Premises-Bereitstellung für Unternehmen in solchen Umgebungen. Die gehärtete Appliance ist dafür ausgelegt, ohne externe Konnektivität zu laufen. Kunden aus Verteidigungs- und Geheimdienstbereichen sollten Kiteworks direkt zu Update-Mechanismen und Support-Modell in Air-Gapped-Umgebungen ansprechen.

Die fehlende Paritätsmatrix: Die entscheidende Dokumentationslücke

Die größte Beschaffungslücke im Enterprise-Filesharing-Markt – auch bei Kiteworks – ist das Fehlen einer öffentlich verfügbaren, deploymentspezifischen Zertifizierungs-Paritätsmatrix. Das ist keine Kritik an einem einzelnen Anbieter, sondern ein strukturelles Problem in der Marktkommunikation zur Compliance-Position.

Was eine Paritätsmatrix abdecken sollte

Eine Zertifizierungs-Paritätsmatrix würde jede vom Anbieter gehaltene Zertifizierung jedem Bereitstellungsmodell zuordnen und den Umfang der jeweiligen Nachweise spezifizieren. Eine gut aufgebaute Matrix würde mindestens folgende Dimensionen enthalten:

Beschaffungshinweis: Die „Umfang mit Kiteworks klären“-Einträge in dieser Tabelle sind keine Ausweichantworten. Der Zertifizierungsumfang ist dokumentiert – jede Zertifizierungsstelle stellt eine Scope-Erklärung aus. Einkaufsteams sollten diese direkt bei Kiteworks anfordern, Kiteworks muss sie liefern können. Unternehmen, die eine globale Zertifikatsliste akzeptieren, ohne sie auf ihr spezifisches Bereitstellungsmodell abzubilden, gehen eine Annahme ein, die nicht zwangsläufig zutrifft.

Zwei Fragen, die in jede Ausschreibung gehören

Angesichts des Fehlens einer öffentlich konsolidierten Paritätsmatrix sollten zwei Fragen in jeder Ausschreibung für Enterprise-Filesharing-Plattformen in regulierten Umgebungen gestellt werden.

Erstens: Kann der Anbieter einen Zertifizierungs-Status-Tracker vorlegen – mit BSI C5, ISO 27001, FedRAMP, IRAP, Cyber Essentials Plus, G-Cloud 14, SOC 2 und NIS 2 – und explizit jedem Bereitstellungsmodell zuordnen, das das Unternehmen evaluiert? Nicht eine globale Compliance-Seite, sondern eine modellbezogene Scope-Erklärung für jeden relevanten Nachweis.

Zweitens: Veröffentlicht der Anbieter Architektur- und Datenflussdokumentation, die es einem EU-Kunden oder Regulierer ermöglicht, Souveränitäts- und Transparenzanforderungen eigenständig zu prüfen? Für Unternehmen unter dem EU Cybersecurity Framework ist die Möglichkeit zur unabhängigen Verifikation – nicht bloß Vertrauen – eine Compliance-Anforderung, kein Nice-to-have. Architekturdiagramme, Datenflussdokumentation und Subunternehmer-Offenlegung sind das Minimum an Nachweisstandard.

Wie Kiteworks Deployment-Souveränität adressiert

Die Differenzierung von Kiteworks im Bereich der Bereitstellungsmodelle basiert auf drei Säulen: architektonische Konsistenz über alle Modelle hinweg, breite unabhängige Drittzertifizierung und ehrliche Anerkennung bestehender Dokumentationslücken.

Der gehärtete Appliance-Kern – genutzt in On-Premises-, Private-Cloud-, Hybrid- und Air-Gapped-Bereitstellungen – sorgt dafür, dass Sicherheitskontrollen nicht für jedes Modell neu entwickelt werden. Der gleiche Verschlüsselungs-Stack, das gleiche Access-Control-Framework, die gleiche Audit-Logging-Architektur, die der FedRAMP-zertifizierten Cloud zugrunde liegen, laufen auch On-Premises. Das ist architektonisch überprüfbar, nicht bloß behauptet. Einkaufsteams können die Appliance-Konfigurationsdokumentation anfordern und sie mit den Beschreibungen für jedes Bereitstellungsmodell abgleichen.

Im Hinblick auf die Zertifizierungsbreite deckt das Kiteworks-Portfolio EMEA-, Asien-Pazifik- und US-Rahmenwerke ab: BSI C5 Type 2, ISO 27001, Cyber Essentials Plus, IRAP PROTECTED, FedRAMP High In Process und SOC 2 Type II. Die G-Cloud 14-Listung im UK Government Digital Marketplace bietet einen öffentlichen Referenzpunkt für britische Behördenbeschaffung. Das ist ein breiteres Zertifizierungsportfolio als bei den meisten vergleichbaren Plattformen am Markt, und die Kombination aus EMEA-orientierten Rahmenwerken (BSI C5, ISO 27001), APAC-Government-Assessment (IRAP) und US-Federal-Authorization (FedRAMP) zeigt echtes Engagement über Jurisdiktionen hinweg – nicht bloß eine US-zentrierte Compliance-Haltung.

Was Kiteworks bislang nicht getan hat – und worauf angesprochen werden sollte – ist die Veröffentlichung einer deploymentspezifischen Zertifizierungs-Paritätsmatrix. Die Zertifizierungen existieren. Die Dokumentation, die sie jedem Bereitstellungsmodell zuordnet, gibt es noch nicht in konsolidierter, öffentlich zugänglicher Form. Für Einkaufsteams in regulierten Umgebungen ist das Schließen dieser Lücke ein berechtigtes Anliegen. Die gemeinsame Appliance-Architektur von Kiteworks sollte diese Dokumentation ermöglichen; die Frage ist, ob sie priorisiert wurde.

Quellcode-Escrow für On-Premises-Kunden bietet einen Kontinuitätsmechanismus über das operative Zertifizierungsportfolio hinaus – besonders relevant für Verteidigung, Geheimdienste und kritische Infrastrukturen, wo langfristige Plattformkontinuität eine Beschaffungsvoraussetzung ist.

Fazit

Mit der Weiterentwicklung regulatorischer Rahmenwerke – EUCS kurz vor der Umsetzung, verschärfte NIS 2-Durchsetzung, DORA-Anforderungen an operationale Resilienz – steigt die Erwartung, dass Unternehmen die Compliance-Position für ihr spezifisches Bereitstellungsmodell nachweisen können, statt sie nur zu behaupten. Der Markt wird sich in Richtung deploymentspezifischer Zertifizierungstransparenz bewegen – ob die Anbieter vorangehen oder nicht. Einkaufsteams, die Paritätsanforderungen jetzt in ihre Ausschreibungen aufnehmen, positionieren sich vorausschauend, statt später Nachweislücken schließen zu müssen, wenn Regulierer die Fragen stellen, die bislang unbeantwortet geblieben sind.

Häufig gestellte Fragen