Physische Sicherheit für Datensouveränität beim Enterprise Filesharing

Datenhoheit wird häufig abstrakt diskutiert: Jurisdiktionen, rechtliche Rahmenbedingungen, vertragliche Rechte und Compliance-Nachweise. Bei der physischen Sicherheit enden diese Abstraktionen. Die Hardware, die die sensiblen Daten Ihres Unternehmens speichert, befindet sich entweder in einer Einrichtung, die Sie kontrollieren – oder nicht. Die kryptografischen Schlüssel, die diese Daten schützen, werden entweder in Hardware-Modulen gehalten, die Sie betreiben – oder nicht. Wenn ein Speichermedium das Ende seines Lebenszyklus erreicht, zerstört Ihr Team es entweder direkt oder es durchläuft eine CoC-Kette (Chain of Custody), die Sie nicht vollständig verifizieren können.

Dies sind keine Randfälle. Es sind die operativen Fragen, die echte Datenhoheit von Compliance-Theater unterscheiden. Für Verantwortliche der physischen Sicherheit, Audit-Teams und CISOs, die für Rechenzentrums- und Hardwaresicherheit zuständig sind, muss die Bewertung einer Filesharing-Plattform vier konkrete Fragen umfassen: Wo befindet sich die Hardware? Wer hat physischen Zugang? Wer kontrolliert die kryptografischen Schlüssel und in welcher Hardware? Was geschieht mit Speichermedien, wenn sie zerstört werden müssen? Dieser Beitrag beantwortet jede dieser Fragen direkt, beleuchtet relevante Zertifizierungen und Standards und erklärt, wie das Bereitstellungsmodell die Antworten bestimmt.

Executive Summary

Kernaussage: Physische Sicherheit beim Filesharing in Unternehmen ist in erster Linie eine Frage des Bereitstellungsmodells – erst danach eine Frage der Anbieterzertifizierung. Eine On-Premises-Bereitstellung platziert die Hardware in der eigenen Einrichtung des Kunden. Physische Zugangskontrollen, Medienvernichtung und HSM-Betrieb liegen vollständig in der Hand des Kunden. Bei einer vom Anbieter betriebenen Cloud-Bereitstellung geht die Verantwortung für die physische Sicherheit auf die Rechenzentrumspartner des Anbieters über; BSI C5, ISO 27001, FedRAMP und IRAP bieten Drittparteiennachweise. Kunden mit höchsten Anforderungen an physische Souveränität – Verteidigung, kritische Infrastrukturen, Finanzmarkt-Infrastruktur – sollten On-Premises-Bereitstellung als Ausgangspunkt und nicht als Notlösung betrachten.

Warum das relevant ist: NIS 2 Artikel 21 verlangt von Betreibern wesentlicher Dienste die Umsetzung angemessener physischer und umweltbezogener Sicherheitsmaßnahmen für Informationssysteme. ISO 27001 Anhang A Kontrollen A.7 (Physische Kontrollen) gelten sowohl für kundenbetriebene als auch für anbieterseitig betriebene Einrichtungen, aber die Möglichkeit des Kunden, diese zu verifizieren, unterscheidet sich grundlegend – je nachdem, ob die Hardware ihm gehört. BSI C5 und FedRAMP High enthalten explizite Kontrollfamilien zum physischen Schutz (PE), die strukturierte Drittparteienbewertungen für anbieterseitig betriebene Infrastrukturen liefern. Zu wissen, welche Kontrollen zu welcher Partei gehören – und wie sie zu verifizieren sind – ist die zentrale Aufgabe der physischen Sicherheitsprüfung.

5 wichtige Erkenntnisse

1. On-Premises-Bereitstellung gibt Kunden vollständige physische Souveränität über ihre File-Infrastruktur. Wenn die Kiteworks-Appliance auf Hardware läuft, die der Kunde besitzt und betreibt, bestimmt der Kunde jede Entscheidung zur physischen Sicherheit – Zugangskontrolle, Gebäudestandards, Umweltüberwachung, Besuchermanagement. Der Anbieter hat keinen physischen Zugang zur Hardware, es sei denn, dies wird ausdrücklich gewährt. Dies ist die stärkste Form physischer Souveränität und kann direkt verifiziert werden – ohne Abhängigkeit von Anbieterzertifikaten.
2. Kundenbetriebene HSMs halten Verschlüsselungsschlüssel außerhalb der Reichweite des Anbieters. Hardware Security Modules bieten manipulationssichere Schlüsselaufbewahrung in dedizierter kryptografischer Hardware. Ist das HSM kundenseitig betrieben und FIPS 140-3 validiert, kann der Anbieter die Schlüssel nicht einsehen – unabhängig vom administrativen Zugriff auf die Anwendungsebene. Das Hold Your Own Key (HYOK)-Modell – unterstützt von validierten Anbietern wie dem SafeNet Luna Network HSM von Thales – ermöglicht, dass selbst in gehosteten Umgebungen die Schlüssel beim Kunden verbleiben.
3. Medienvernichtung ist eine oft übersehene Souveränitätsanforderung. Wer zerstört Speichermedien, nach welchem Verfahren, mit welchem Nachweis? Bei On-Premises-Bereitstellung steuert der Kunde die Medienvernichtung direkt – keine CoC-Kette des Anbieters, keine Abhängigkeit von Drittzertifikaten, keine Zerstörungsplanung, die Anbieterabstimmung erfordert. In Cloud-Umgebungen liegt die Verantwortung beim Anbieter und wird durch Zertifikate wie BSI C5 und ISO 27001 belegt.
4. Key-Ceremony-Prozesse sind genauso wichtig wie HSM-Hardware. Ein FIPS 140-3 validiertes HSM bietet hardwarebasierte Manipulationssicherheit, aber die Sicherheit des Schlüssels hängt vom Schlüsselgenerierungsprozess ab: Wie wurde der Schlüssel erzeugt, von wem, unter welchen prozeduralen Kontrollen und mit welchem Audit-Trail? Formale, dokumentierte Key Ceremonies unter Kundenkontrolle ergänzen die HSM-Hardware und sind in Rahmenwerken wie NIST SP 800-57 und PCI DSS vorgeschrieben.
5. Anbieterzertifikate für Cloud-Einrichtungen bieten Nachweise, aber keine Kontrolle. BSI C5 Type 2, ISO 27001, FedRAMP High und IRAP PROTECTED beinhalten alle Komponenten zur Bewertung der physischen Sicherheit und liefern Drittparteiennachweise, dass Anbieter-Einrichtungen definierte Standards erfüllen. Aber Zertifikate belegen nur die Einhaltung zu einem bestimmten Zeitpunkt – keine laufende Kontrolle. Unternehmen, die Echtzeit- und unabhängig überprüfbare physische Sicherheitskontrolle benötigen, müssen die Hardware selbst besitzen.

Bereitstellungsmodell und physische Souveränität

Fragen zur physischen Souveränität lassen sich nicht unabhängig vom Bereitstellungsmodell beantworten. Ob die Hardware On-Premises im Besitz des Kunden, vom Anbieter in einer Private Cloud oder in einer Public Cloud betrieben wird, hängt von der Bereitstellungswahl ab – und diese bestimmt das gesamte Sicherheitsumfeld. Die meisten Evaluierungen von Filesharing-Lösungen konzentrieren sich auf Funktionen und Zertifikate, ohne zuerst das Bereitstellungsmodell zu klären. Das ist die falsche Reihenfolge.

On-Premises: Volle physische Kontrolle durch den Kunden

Bei einer On-Premises-Bereitstellung läuft die Kiteworks-Appliance auf Hardware, die der Kunde besitzt und in einer eigenen Einrichtung installiert. Der physische Zugang zu Server-, Speicher- und Netzwerktechnik wird ausschließlich durch das eigene Sicherheitsprogramm des Kunden geregelt. Der Kunde bestimmt, welches Personal Zutritt zum Serverraum hat, welche Umweltüberwachung eingesetzt wird, welche multifaktoriellen physischen Zugangssysteme die Geräte schützen und welche Überwachungssysteme die Einrichtung absichern. Keine dieser Entscheidungen trifft der Anbieter.

Das ist aus mehreren Gründen relevant, die direkt in regulatorischen Rahmenwerken adressiert werden. NIS 2 Artikel 21(2)(e) fordert „physische Sicherheit und Umweltsicherheit“ als Basismaßnahme für wesentliche Dienste. ISO 27001 Anhang A.7 (Physische Kontrollen) umfasst Maßnahmen für gesicherte Bereiche, Zugangskontrollen, Schutz von Büros und Geräten, Überwachung der physischen Sicherheit und Schutz vor Umwelteinflüssen. Wenn der Kunde die Hardware betreibt, liegt jede dieser Kontrollen in seinem direkten Implementierungs- und Prüfungsbereich – verifizierbar durch eigene Nachweise ohne Abhängigkeit von Anbieterattesten.

Das On-Premises-Modell bestimmt auch, wer eine unangekündigte physische Inspektion durchführen kann. Aufsichtsbehörden und interne Audit-Teams können jederzeit die Einrichtung des Kunden betreten und physische Kontrollen direkt überprüfen. In einer Cloud-Umgebung erfordert der Zugang zum Rechenzentrum des Anbieters für physische Inspektionen vorherige Abstimmung, ist meist auf indirekte Beobachtung beschränkt und bedarf oft der Unterstützung des Anbieters. Für Unternehmen mit Prüfungsanforderungen – insbesondere im Finanzsektor, Verteidigung und kritischer Infrastruktur – ist das keine Nebensache, sondern eine Frage der Prüfungsrechte.

Was zu prüfen ist: Klären Sie mit dem Anbieter, ob die On-Premises-Bereitstellung Ihrem Team vollständigen physischen Zugang zur Appliance-Hardware ermöglicht – inklusive der Möglichkeit, eigene physische Sicherheitsmaßnahmen an der Hardware anzubringen (z. B. manipulationssichere Siegel). Verstehen Sie, ob der Anbieter einen Remote-Zugang zur Appliance behält und unter welchen Bedingungen.

Anbieterbetriebene Infrastruktur: Zertifizierung als Nachweis

Kiteworks-gehostete Cloud-Bereitstellungen laufen in Einrichtungen, die einer strukturierten Drittparteienprüfung der physischen Sicherheit unterliegen. Die BSI C5 (Cloud Computing Compliance Criteria Catalogue) Type 2 Attestierung umfasst physische Sicherheit als expliziten Bestandteil ihres Kontrollrahmens, inklusive Anforderungen an Zugangskontrollen, Überwachung, Umweltschutz und Medienhandhabung. Ein Type 2 Bericht belegt die Wirksamkeit der Kontrollen über einen Zeitraum – nicht nur das Design zu einem bestimmten Zeitpunkt.

Die ISO 27001-Zertifizierung bezieht sich auf das gesamte Informationssicherheitsmanagementsystem, einschließlich physischer und umweltbezogener Sicherheitskontrollen gemäß Anhang A.7. Die ISO 27001:2022 hat den Anhang zu physischen Kontrollen gegenüber der Version von 2013 erweitert und explizite Anforderungen für Clean-Desk-Policy, Gerätestandorte und Überwachung ergänzt. Die ISO 27001-Zertifizierung von Kiteworks umfasst die Cloud-Infrastruktur-Betriebe.

Für australische Behörden-Workloads verlangt die IRAP PROTECTED-Klassifizierung eine physische Sicherheitsbewertung nach dem australischen ISM (Information Security Manual), das spezifische Anforderungen an die physische Sicherheit von Einrichtungen zur Verarbeitung PROTECTED-Informationen enthält. Für US-Behörden und verteidigungsnahe Workloads umfasst der FedRAMP High In Process-Status die Bewertung der Physical and Environmental Protection (PE) Kontrollfamilie auf dem High-Baseline – eine der anspruchsvollsten physischen Kontrollanforderungen im US-Bundesrahmenwerk.

Der entscheidende Punkt: Diese Zertifikate liefern glaubwürdige, strukturierte Drittparteiennachweise für physische Sicherheitskontrollen in anbieterseitig betriebenen Einrichtungen. Sie geben dem Kunden jedoch keine direkte Kontrolle über diese Kontrollen. Unternehmen, die Kontrolle – nicht nur Nachweise – benötigen, brauchen das On-Premises-Bereitstellungsmodell.

Hardware Security Modules: Schlüsselaufbewahrung und kryptografische Souveränität

Verschlüsselung im ruhenden Zustand schützt Daten vor unbefugtem Zugriff auf Speicherebene. Der Schutz reicht jedoch nur so weit wie die Sicherheit der Verschlüsselungsschlüssel. Hält der Anbieter die Schlüssel – oder kann er darauf zugreifen – kann er die Daten im Prinzip entschlüsseln. Das ist die grundlegende Frage der kryptografischen Souveränität, die HSM-Integration adressiert.

Ein Hardware Security Module ist ein dediziertes kryptografisches Gerät, das zur Generierung, Speicherung und Verwaltung von Verschlüsselungsschlüsseln in manipulationssicherer Hardware entwickelt wurde. HSMs unterscheiden sich von Software-Schlüsselmanagement dadurch, dass das Schlüsselmaterial nie im Klartext außerhalb des HSM existiert – Schlüsseloperationen (Verschlüsselung, Entschlüsselung, Signatur) erfolgen im Gerät, das Schlüsselmaterial wird bei Manipulationsversuchen zerstört. Für Hochsicherheitsumgebungen sind HSMs der Standard für Schlüsselmanagement, keine optionale Ergänzung.

FIPS 140-3 Validierung: Der Hardware-Standard für kryptografisches Vertrauen

FIPS 140-3 (Federal Information Processing Standard 140-3) ist der US-Standard für die Validierung kryptografischer Module, verwaltet von NIST und dem Canadian Centre for Cyber Security. Er ersetzt FIPS 140-2 und ist mit ISO/IEC 19790 abgestimmt. FIPS 140-3 definiert vier Sicherheitsstufen – Level 1 bis 4 – wobei jede Stufe stärkere Anforderungen an Manipulationssicherheit stellt.

Level 3 ist der Standard für HSM-Bereitstellungen in regulierten Umgebungen: Er verlangt Manipulationserkennung, -nachweis und -reaktion, die bei Manipulation kritische Sicherheitsparameter löschen, sowie identitätsbasierte Authentifizierung. Level 4 ergänzt Schutz gegen Umwelteinflüsse und findet sich meist in Zahlungssystemen und klassifizierten Systemen.

Kiteworks unterstützt die Integration mit kundenseitig betriebenen HSMs, die auf FIPS 140-3 validiert sind. Der dokumentierte Integrationspartner für On-Premises ist das SafeNet Luna Network HSM von Thales (ehemals Gemalto) – ein FIPS 140-3 validiertes Modul, das in regulierten Finanzdienstleistungen, Behörden, Gesundheitswesen und Verteidigung weit verbreitet ist. Das SafeNet Luna HSM bietet manipulationssichere Schlüsselaufbewahrung, formale Key-Ceremony-Unterstützung und Audit-Logging auf Hardwareebene. Das HSM-Validierungszertifikat kann direkt in der NIST Cryptographic Module Validation Program (CMVP)-Datenbank überprüft werden – als unabhängig prüfbarer Nachweis der kryptografischen Vertrauenswürdigkeit des Moduls.

Hold Your Own Key (HYOK): Schlüsselaufbewahrung beim Kunden

Das Hold Your Own Key-Modell ist das Architekturprinzip, bei dem die Schlüsselaufbewahrung vollständig beim Kunden bleibt – unabhängig davon, wo die Anwendung läuft. In einer HYOK-Konfiguration verlässt der Verschlüsselungsschlüssel nie das HSM des Kunden – genauer: Der Klartextschlüssel verlässt nie die HSM-Grenze. Wenn die Anwendung Daten entschlüsseln muss, sendet sie eine Anfrage an das HSM; das HSM führt die Operation aus und gibt die entschlüsselten Daten zurück (nicht den Schlüssel). Die Anwendungsebene des Anbieters erhält keinen Zugriff auf das Schlüsselmaterial.

Diese Unterscheidung ist entscheidend, weil sie logischen Zugriff (die Anwendung des Anbieters kann Daten verarbeiten) von Schlüsselaufbewahrung trennt (der Anbieter kann Daten nicht ohne das HSM des Kunden entschlüsseln und die Freigabe des Kunden ist erforderlich). Zieht der Kunde das HSM aus dem Schlüsselmanagement zurück – per Richtlinie, durch physische Trennung oder als Reaktion auf eine rechtliche Anordnung – kann der Anbieter die Daten nicht entschlüsseln, unabhängig vom Zugriff auf Anwendung oder Speicher.

Kiteworks unterstützt HYOK für On-Premises-Bereitstellungen, bei denen das HSM physisch in der Einrichtung des Kunden steht und vollständig unter dessen Kontrolle betrieben wird. Diese Konfiguration bietet die stärkste kryptografische Souveränität: Die Hardware mit den Schlüsseln befindet sich in der Einrichtung des Kunden, betrieben vom eigenen Team, ohne Remote-Zugriffsmöglichkeit für den Anbieter.

Key Ceremony: Prozedurale Kontrolle der Schlüsselgenerierung

Eine formale Key Ceremony ist das dokumentierte Verfahren, mit dem ein kryptografischer Schlüssel generiert, ggf. aufgeteilt, in ein HSM geladen und unter prozeduralen Kontrollen aktiviert wird, sodass keine Einzelperson vollständigen Zugriff auf das Schlüsselmaterial hat. Anforderungen an Key Ceremonies sind in NIST SP 800-57 Teil 1 (Empfehlung für Schlüsselmanagement), PCI DSS Anforderung 3.7 und branchenspezifischen Standards festgelegt.

Die Key Ceremony ist entscheidend, weil die Sicherheit aller nachfolgenden kryptografischen Operationen von der Integrität des Schlüsselgenerierungsereignisses abhängt. Ein Schlüssel, der ohne prozedurale Kontrolle – von einer Einzelperson, ohne Zeugen, ohne Dokumentation – generiert wird, ist nicht vertrauenswürdiger als ein Software-Schlüssel im Anwendungsspeicher, unabhängig davon, wie sicher das HSM ist, das ihn speichert. Die Key Ceremony ist der prozedurale Vertrauensanker für den gesamten Schlüssellebenszyklus.

In On-Premises-Kiteworks-Bereitstellungen werden Key-Ceremony-Prozesse vollständig unter Kundenkontrolle durchgeführt. Das Kundenteam legt die Anforderungen fest, wählt Teilnehmer und Zeugen, entscheidet über Split Knowledge und Dual Control und erstellt die Audit-Dokumentation. Dies ist direkt durch das eigene Audit-Team und externe Prüfer prüfbar – die Unterlagen sind Eigennachweise des Kunden, kein Anbieterattest.

Medienvernichtung: Das Ende des Datenlebenszyklus

Das Datenlebenszyklusmanagement endet mit der Vernichtung von Speichermedien. Die meisten Diskussionen zur Unternehmenssicherheit konzentrieren sich auf den Anfang und die Mitte des Lebenszyklus – Verschlüsselung im ruhenden Zustand, Zugangskontrollen, Audit-Logging – und behandeln die Medienentsorgung als Randnotiz. Für Unternehmen mit Datenschutz– oder Geheimhaltungsanforderungen ist das ein Fehler. Die Frage, wer Speichermedien physisch zerstört, mit welcher Methode und welchem Nachweis, ist eine Souveränitätsfrage mit direkten regulatorischen und vertraglichen Auswirkungen.

Kundenkontrollierte Vernichtung bei On-Premises-Bereitstellung

Läuft die Kiteworks-Appliance auf kundeneigener Hardware, liegt die Medienvernichtung vollständig in der Hand des Kunden. Das Kundenteam entscheidet über die Methode – Entmagnetisierung, physisches Schreddern, kryptografische Löschung oder eine Kombination –, führt das Verfahren durch, bezeugt die Vernichtung und erstellt das Entsorgungszertifikat. Es ist keine Anbieterbeteiligung oder Terminabstimmung erforderlich und keine Drittparteien-CoC-Kette involviert.

Dies ist besonders relevant in zwei regulatorischen Szenarien: Erstens, wenn Vorschriften verlangen, dass Medienvernichtung innerhalb des eigenen Sicherheitsperimeters erfolgt – wie häufig in Verteidigungs- und Geheimhaltungsumgebungen – ist On-Premises die einzige zulässige Konfiguration. Zweitens, wenn bei Ermittlungen oder rechtlichen Verfahren ein sofortiger Stopp aller Medienoperationen erforderlich ist, kann das Kundenteam ohne Anbieterabstimmung handeln.

ISO 27001 Anhang A.7.10 (Speichermedien) verlangt, dass Medien über ihren gesamten Lebenszyklus, einschließlich sicherer Entsorgung, verwaltet werden. Der Standard schreibt keine bestimmte Vernichtungsmethode vor, fordert aber, dass die Entsorgung der Sensibilität der gespeicherten Informationen angemessen ist. NIST SP 800-88 (Guidelines for Media Sanitization) bietet die meistgenutzte technische Anleitung zu Methoden und deren Eignung für verschiedene Medientypen und Schutzstufen. Bei On-Premises-Bereitstellung wählt der Kunde die passende Methode gemäß NIST SP 800-88 und setzt sie direkt um.

Anbieterverwaltete Vernichtung: Zertifizierung und CoC-Kette

In anbieterseitig betriebenen Cloud-Umgebungen sind Speichermedien Teil der Infrastruktur des Anbieters (oder Cloud Service Providers). Die Medienvernichtung erfolgt durch den Anbieter oder dessen Rechenzentrumspartner und wird durch die entsprechenden Zertifikate belegt. BSI C5 fordert dokumentierte Verfahren zur Medienhandhabung und -vernichtung als Teil der physischen Sicherheitskriterien. ISO 27001 deckt diesen Bereich unter Anhang A.7.10 ab. Die FedRAMP PE-Kontrollfamilie umfasst Medienkontrollen (MP-Familie) für Bereinigung und Entsorgung.

Diese Zertifikate liefern Drittparteiennachweise, dass dokumentierte Vernichtungsverfahren existieren und eingehalten werden. Sie geben dem Kunden jedoch keinen direkten Einblick, wann bestimmte Medien vernichtet werden, welche Medien seine Daten enthielten oder welche Methode für die eigenen Speicher angewendet wurde. Für die meisten regulierten Unternehmen ist dieses Maß an attestierter Sicherheit ausreichend. Für Organisationen mit höchster Sensibilität – klassifizierte Daten, nicht öffentliche Informationen, kritische nationale Infrastrukturdaten – ist das Fehlen direkter Kontrolle und Verifikation eine echte Einschränkung des Cloud-Modells.

Was zu prüfen ist: Lassen Sie sich vom Anbieter die vertragliche und operative CoC-Kette für die Entsorgung von Speichermedien erläutern. Klären Sie, welche Zertifikate das Rechenzentrum abdecken, in dem Ihre Daten gespeichert werden – nicht nur das Gesamtportfolio des Anbieters. Fordern Sie das aktuelle BSI C5- oder ISO 27001-Attest an, das die konkrete Einrichtung abdeckt, und prüfen Sie, dass die Medienentsorgung im Geltungsbereich enthalten ist.

Shared Responsibility: Was das Modell in der Praxis bedeutet

Das Shared-Responsibility-Modell wird im Cloud-Sicherheitskontext häufig diskutiert, ist aber gerade bei physischer Sicherheit besonders relevant, weil die Verantwortlichkeiten an den Extremen am klarsten sind: vollständig On-Premises oder vollständig Cloud-nativ. Die Unschärfe liegt in hybriden und Co-Location-Konfigurationen – dort, wo viele Unternehmensumgebungen tatsächlich angesiedelt sind.

Zu wissen, welche physischen Sicherheitskontrollen beim Kunden und welche beim Anbieter liegen, ist nicht nur eine Compliance-Übung – es bestimmt, woher Ihre Audit-Nachweise stammen müssen, welche Kontrollen Sie selbst prüfen und wo bei einer Aufsichtsprüfung Lücken entstehen können.

Kiteworks-Differenzierung: Physische Sicherheit über alle Bereitstellungsmodelle hinweg

Kiteworks unterstützt ein Spektrum von vollständig On-Premises bis zu anbieterseitig betriebener Cloud – die Sicherheitslage verschiebt sich entlang dieses Spektrums. Nachfolgend die dokumentierten Differenzierungsmerkmale für physische Sicherheit und HSM-Integration.

On-Premises-Appliance-Modell

Die Kiteworks-Appliance ist für den Betrieb auf kundeneigener Hardware in der eigenen Einrichtung des Kunden konzipiert. Es handelt sich nicht um Co-Location oder eine von Kiteworks gehostete Private Cloud – sondern um Hardware, die der Kunde bereitstellt, betreibt und physisch kontrolliert. Die Appliance kann in Rechenzentren eingesetzt werden, die der Kunde nach eigenen ISO 27001-, BSI IT-Grundschutz- oder branchenspezifischen Programmen betreibt – so erhält der Kunde vollständige physische Souveränität über die Bereitstellung.

Die Kontrolle des Kunden erstreckt sich auf die Hardwareauswahl, physische Sicherheitsmaßnahmen an der Appliance (manipulationssichere Siegel, Racksicherung, Zugangskartenpflicht für den Geräteraum), Konfiguration der Umweltüberwachung und Medienvernichtung. Der Anbieter hat in dieser Konfiguration keinen physischen Zugang zur Hardware – jeglicher Remote-Zugang zu Supportzwecken erfordert explizite Autorisierung durch den Kunden und unterliegt dessen Remote-Access-Policy.

HSM-Integration mit führenden Enterprise-Anbietern

Kiteworks unterstützt die Integration mit dem SafeNet Luna Network HSM von Thales, einem FIPS 140-3 validierten Hardwaremodul, das in regulierten Branchen weit verbreitet ist. Bei On-Premises-Bereitstellung befindet sich das HSM physisch in der Einrichtung des Kunden und wird vollständig vom Kunden verwaltet. Die HYOK-Architektur stellt sicher, dass Kiteworks-Anwendungsprozesse kryptografische Anfragen an das HSM stellen, aber kein Schlüsselmaterial erhalten – nur das Ergebnis der Operation. Das bedeutet: Zugriff auf die Kiteworks-Anwendungsebene – sei es durch kompromittierte Zugangsdaten, eine Support-Session oder eine gerichtliche Anordnung gegen den Softwareanbieter – führt nicht zu Entschlüsselungsmöglichkeiten. Die Schlüssel liegen in kundenkontrollierter Hardware, auf die der Anbieter keinen Zugriff hat.

Zertifikate für anbieterseitig betriebene Infrastruktur

Für Unternehmen, die Kiteworks-gehostete Cloud-Bereitstellungen nutzen, basiert die physische Sicherheitsgarantie auf dem Zertifizierungsportfolio für die Rechenzentrumsinfrastruktur von Kiteworks. Die BSI C5 Type 2 Attestierung bietet den detailliertesten physischen Sicherheitsnachweis für EMEA-Organisationen, mit einem Bewertungszeitraum, der die Wirksamkeit der Kontrollen abdeckt. Die ISO 27001-Zertifizierung deckt das gesamte Informationssicherheitsmanagementsystem einschließlich physischer Kontrollen ab. Der FedRAMP High In Process-Status zeigt, dass die vollständige PE-Kontrollfamilie auf High-Baseline geprüft wird – das strengste US-Regelwerk für physische Sicherheit bei Cloud-Services. Die IRAP PROTECTED-Klassifizierung bietet gleichwertige Sicherheit für australische Behörden-Workloads.

Diese Zertifikate sind kumulative Nachweise für physische Sicherheitskontrollen in anbieterseitig betriebenen Einrichtungen, unabhängig geprüft von qualifizierten Drittparteien. Sie sind der geeignete Nachweis für Unternehmen, die sich für anbieterseitige Infrastruktur entschieden haben und eine Drittparteienbestätigung benötigen, dass die physische Sicherheit regulatorische und vertragliche Anforderungen erfüllt.

Fazit

Physische Sicherheit ist die Ebene der Datenhoheit, die sich nicht durch Softwarekontrollen oder Compliance-Zertifikate abstrahieren lässt. Die Frage, ob die Hardware mit sensiblen Daten in einer vom Kunden kontrollierten Einrichtung steht – und ob die kryptografischen Schlüssel in Hardwaremodulen liegen, die der Kunde betreibt – hat eine direkte operative Antwort, die vom Bereitstellungsmodell und nicht vom Zertifizierungsportfolio des Anbieters abhängt. Für Unternehmen, bei denen physische Souveränität eine echte Anforderung und kein Compliance-Häkchen ist, bietet das On-Premises-Modell mit kundenbetriebener HSM-Integration die stärkste und direkt prüfbare Position im Filesharing-Umfeld.

Die regulatorische Entwicklung in EMEA, dem US-Bundesbereich und Australien geht in Richtung expliziterer physischer Sicherheitsanforderungen – nicht weniger: NIS 2, die Weiterentwicklung von BSI C5 und die anhaltende Strenge der FedRAMP-PE-Kontrollen zeigen alle in die gleiche Richtung. Unternehmen, die jetzt klare, eigennachweisbare physische Sicherheitskontrollen etablieren – durch Bereitstellungsentscheidungen, HSM-Architektur und Medienvernichtung –, schaffen die Nachweisbasis, die Aufsichtsbehörden zunehmend dokumentiert sehen wollen – nicht nur attestiert.

Häufig gestellte Fragen