Collabora CODE-Dokumente im Ruhezustand mit Speicherverschlüsselung schützen

Um Dokumente im Ruhezustand bei der Verwendung von Collabora Online Development Edition (CODE) zu verschlüsseln, aktivieren Sie die Verschlüsselung in der Dateispeicherplattform oder auf der zugrunde liegenden Festplatte – nicht im CODE-Editor. Collabora öffnet Dokumente, die von einem WOPI-Speicherhost bereitgestellt werden. Dieser Host ist für den Schutz der gespeicherten Kopien verantwortlich. Das Ergebnis sind verschlüsselte Speicherung, funktionierende Bearbeitungen und wiederherstellbare Dateien.

Ermitteln Sie, welches System die Dateien tatsächlich speichert.

Eine typische Implementierung nutzt Nextcloud oder einen anderen WOPI-kompatiblen Dienst zur Dateispeicherung und CODE für die browserbasierte Bearbeitung. Ein Dokument wird während einer autorisierten Bearbeitungssitzung zwischen diesen Komponenten übertragen; die Aktivierung von HTTPS schützt diese Verbindung, verschlüsselt aber nicht die gespeicherte Kopie. Die Sicherheitsübersicht von Collabora beschreibt die Speicherung als integrationsgesteuert, während die Serverkonfigurationsvorlage WOPI, TLS sowie optionale Cache- und Quarantäneeinstellungen dokumentiert.

Bevor Sie Änderungen vornehmen, notieren Sie, wo der WOPI-Host Dokumentdateien speichert, ob er lokale Festplatten oder externen Objektspeicher verwendet und wo CODE selbst ausgeführt wird. Berücksichtigen Sie dabei Backups, Snapshots, Vorschauen, Auslagerungsdateien und Container-Volumes: Kopien außerhalb des Hauptverzeichnisses sind möglicherweise ungeschützt.

Wählen Sie eine Verschlüsselung, die dem Risiko entspricht.

Für Dokumente auf der lokalen Festplatte eines Linux-Servers ist die Festplatten- oder Volume-Verschlüsselung, beispielsweise mit LUKS, meist die einfachste Lösung. Sie schützt den zugrundeliegenden Speicher, wenn das Volume gesperrt ist, auch vor Diebstahl eines ausgeschalteten Laufwerks. Die Dokumentation zur vollständigen Festplattenverschlüsselung von Ubuntu beschreibt LUKS als Blockverschlüsselung, nicht als Anwendungseinstellung. Verwenden Sie ein neues verschlüsseltes Volume oder eine getestete Migration: Die Initialisierung von LUKS kann vorhandene Daten zerstören.

Wenn Nextcloud Dateien auf einem externen Speichermedium speichert und der Speicheranbieter deren Inhalte nicht lesen darf, ist die serverseitige Verschlüsselung (SSE) von Nextcloud möglicherweise besser geeignet. Sie verschlüsselt die unterstützten Dateiinhalte, bevor diese im Backend-Speicher abgelegt werden. Die Schlüssel verbleiben in Nextcloud, sodass ein kompromittierter Server oder Administrator auf die entschlüsselten Dateien zugreifen kann. Nextcloud empfiehlt, für die lokale Speicherung eine Festplattenverschlüsselung in Betracht zu ziehen.

Wenn selbst der Anwendungsadministrator ein Dokument nicht lesen können muss, erfüllen weder die Verschlüsselung mit entsperrter Festplatte noch herkömmliche SSE diese Anforderung. Prüfen Sie einen unterstützten clientseitigen oder Ende-zu-Ende-Verschlüsselungs-Workflow und stellen Sie sicher, dass die Bearbeitung im Browser weiterhin möglich ist. Gehen Sie nicht davon aus, dass jedes verschlüsselte Dokument in CODE gemeinsam geöffnet werden kann.

Aktivieren Sie die Verschlüsselung auf dem Speicherhost.

Option A: Lokales Volume verschlüsseln

Bei einer neuen Linux-Installation sollten die Dateidaten und relevanten Service-Volumes vor dem Import der Dokumente auf verschlüsseltem Speicher bereitgestellt werden. Das Entsperrgeheimnis und die Wiederherstellungsinformationen sollten außerhalb des Servers aufbewahrt, der administrative Zugriff eingeschränkt und der Neustart bzw. die Entsperrprozedur getestet werden. Bei bestehenden Systemen sollten die Backups überprüft und während der Ausfallzeit migriert werden. Die Verschlüsselung für Cloud-Volumes oder Objektspeicher wird mit dem jeweiligen Anbieter konfiguriert.

Verwenden Sie diese Funktion lsblk -f, um Blockgerätetypen und findmnt -T /path/to/document/datadas Dateisystem Ihres eigentlichen Datenverzeichnisses zu identifizieren. Überprüfen Sie den Pfad vom Datenverzeichnis zum verschlüsselten Gerät: Die Installation cryptsetupallein verschlüsselt kein Dateisystem.

Option B: Nextcloud-serverseitige Verschlüsselung aktivieren

Wenn Nextcloud SSE angebracht ist, folgen Sie der Anleitung zur serverseitigen Verschlüsselung . Sichern Sie die Nextcloud-Konfiguration, die Datenbank, die Dateien und die Verschlüsselungsschlüssel, bevor Sie Änderungen vornehmen. Legen Sie den Schlüsselmodus fest, bevor Sie Inhalte verschlüsseln; die aktuelle Anleitung beschreibt einen serverseitig verwalteten Hauptschlüssel als Standard für die meisten Bereitstellungen.

1. Aktivieren Sie das Nextcloud-Standardverschlüsselungsmodul in den Apps und anschließend die serverseitige Verschlüsselung in den Administrationseinstellungen oder verwenden Sie die dokumentierten occBefehle.
2. Bei einer herkömmlichen Linux-Installation führen Sie die Befehle aus dem Nextcloud-Installationsverzeichnis als Webserver-Konto aus: sudo -E -u www-data php occ app:enable encryption, dann sudo -E -u www-data php occ encryption:enable. Passen Sie Benutzername und Ausführungsmethode an Ihre Paketierung an; Docker-Bereitstellungen verwenden Befehle innerhalb des entsprechenden Containers.
3. Führen Sie den Befehl aus sudo -E -u www-data php occ encryption:status, um die Funktion und das ausgewählte Modul zu bestätigen. Interpretieren Sie ein aktiviertes Flag nicht als Beweis dafür, dass jede bereits vorhandene Datei verschlüsselt ist.
4. Planen Sie ein Wartungsfenster ohne Benutzerzugriff auf Dateien und führen Sie den Befehl aus, sudo -E -u www-data php occ encryption:encrypt-allum bereits vorhandene Dateien zu bearbeiten. Dieser Vorgang kann einige Zeit in Anspruch nehmen. Die offizielle Referenz der Verschlüsselungsbefehle weist darauf hin, dass er den Wartungsmodus verwaltet und ein interaktives Terminal erfordert.

SSE schließt Dateinamen, Ordner, vorhandene Papierkorbdateien, einige ältere Versionen, Miniaturansichten, Vorschauen, Suchindizes und bestimmte Anwendungsdaten aus. Schützen Sie ausgeschlossene Elemente bei Bedarf separat. Sichern Sie Sicherungskopien Ihrer Verschlüsselungsschlüssel; der Verlust wichtiger Schlüssel oder Instanzgeheimnisse kann die Wiederherstellung dauerhaft verhindern.

Schützen Sie den Host von CODE und halten Sie den Bearbeitungspfad sicher.

Auch wenn der WOPI-Host gespeicherte Dokumente verschlüsselt, sollte die CODE-Maschine separat geprüft werden. Collabora beschreibt die aktive Dokumentenverwaltung als speicherorientiert und sieht CODE nicht als permanenten Dokumentenspeicher vor. Die veröffentlichte coolwsd.xmlVorlage enthält jedoch Einstellungen für optionale Quarantäne- und Cache-Dateien. Prüfen Sie daher die tatsächliche Bereitstellung, anstatt anzunehmen, dass alle temporären Artefakte nicht vorhanden sind. Schützen Sie Container-Laufzeitspeicher, eingebundene Volumes, System-Swap, Crash-Dumps und Backups mit geeigneten Verschlüsselungs- oder Aufbewahrungsrichtlinien.

Verwenden Sie HTTPS zwischen Browsern, CODE und dem WOPI-Dienst und beschränken Sie die Verbindungen zu WOPI-Hosts. Die Konfigurationsdokumentation von Nextcloud Office empfiehlt, WOPI-Anfragen auf die erwarteten Collabora-Server-IP-Adressen zu beschränken. Diese Zugriffskontrollen ersetzen nicht die Verschlüsselung ruhender Daten, verhindern aber, dass unbefugte Bearbeiter Klartext aus dem verschlüsselten Speichersystem erhalten.

Aktivieren Sie den lokalen Dateisystem-Speichermodus von Collabora nicht als Abkürzung für den Produktivbetrieb; das offizielle SDK beschreibt die Dateisystemspeicherung als reine Testoption und empfiehlt WOPI. Behalten Sie die normale Speicherintegration bei, damit das Autorisierungs- und Speicherverhalten konsistent bleibt.

Prüfen Sie, ob das Ergebnis gut genug ist.

Verwenden Sie für den Akzeptanztest eine unkritische Beispieldatei. Laden Sie diese über den Speicherdienst hoch, öffnen Sie sie in CODE, bearbeiten Sie eine Zeile, speichern Sie die Datei, schließen Sie den Editor und öffnen Sie ihn erneut. Ein erfolgreicher Roundtrip bestätigt, dass die Bearbeitung weiterhin funktioniert; er beweist jedoch nicht die Verschlüsselung ruhender Daten.

• Speichernachweis: Überprüfen Sie, ob das tatsächliche Dokumentenverzeichnis auf das vorgesehene verschlüsselte Volume verweist oder ob der Speicherdienst die erwartete Verschlüsselungskonfiguration meldet. Prüfen Sie bei SSE mithilfe eines kontrollierten Tests und autorisiertem Backend-Zugriff, ob die vom Backend gespeicherten Daten ohne die Schlüssel der Speicheranwendung unlesbar sind.
• Abdeckung alter Dateien: Migration bestätigen oder encryption:encrypt-allerfolgreich abgeschlossen; nicht nur eine neu hochgeladene Datei testen.
• Sekundäre Kopien: Überprüfen Sie Backups, Snapshots, Vorschaudaten, Protokolle und den CODE-Hostspeicher auf Einhaltung der gleichen Schutzanforderungen.
• Wiederherstellbarkeit: Stellen Sie ein Beispiel und die dazugehörigen Schlüssel in einer separaten Testumgebung wieder her und bestätigen Sie anschließend, dass sich das Dokument mit CODE öffnen und speichern lässt.

Wechseln Sie den Ansatz, wenn der Speicheranbieter oder die Anwendung die Inhalte nicht entschlüsseln kann, wenn eine geschützte Datenkategorie außerhalb des Verschlüsselungsbereichs liegt oder wenn die Schlüsselwiederherstellung nicht nachgewiesen werden kann. Die Verschlüsselung ruhender Daten beschränkt hauptsächlich die Risiken durch Speicherverlust und unautorisierte Zugriffe auf das Backend; sie kann jedoch nicht verhindern, dass ein kompromittierter Server, ein autorisierter Benutzer eine Datei herunterlädt oder ein gestohlenes Konto ein geöffnetes Dokument liest.