So deaktivieren Sie Telemetrie und externe Verbindungen in Collabora CODE

Kurz gesagt: Collabora Online Development Edition (CODE) bietet keine allgemeine Telemetrie-Funktion, die Administratoren für routinemäßige Analysen deaktivieren müssen. Laut Collabora benötigt die selbstgehostete Online-Version keine Telemetrie- oder Analyse-Callbacks. Die zu kontrollierenden ausgehenden Aktivitäten sind separat: regelmäßige Update-Prüfungen, optionale Integrationen, Überwachungsendpunkte und Dokumentfunktionen, die Daten von externen Servern abrufen. Deaktivieren Sie die nicht benötigten optionalen Funktionen und erzwingen Sie eine Liste mit zulässigen ausgehenden Verbindungen, während die WOPI-Verbindung zu Ihrem Speicherserver erhalten bleibt.

Dies gilt für selbstgehostete CODE-Instanzen, beispielsweise solche, die in Nextcloud oder ownCloud integriert sind. Die vollständige Blockierung des ausgehenden Datenverkehrs kann das Laden und Speichern von Dokumenten beeinträchtigen, da CODE seinen WOPI-Host erreichen muss. Die unten aufgeführten Konfigurationsnamen wurden am 6. Oktober 2026 mit der Upstream-Vorlage von Collabora abgeglichen; Paketierung und Standardeinstellungen können je nach Version variieren.

Was zählt als Telemetrie bzw. als externe Verbindung?

Telemetrie bezeichnet üblicherweise Produktnutzungs- oder Diagnosedaten, die an einen Anbieter gesendet werden. Collabora gibt an, dass sein selbstgehostetes Online-Produkt weder Telemetrie noch Analyse-Callbacks oder externe Serviceverbindungen benötigt. Die Upstream- coolwsd.xmlVorlage enthält weder einen globalen Telemetrie-Collector noch einen „Phone Home“-Switch.

Es wird eine regelmäßige Versionsprüfung angezeigt: fetch_update_checkStandardmäßig alle 10 Stunden. Durch die entsprechende Einstellung 0kann diese Prüfung deaktiviert werden. Diese Einstellung allow_update_popupsteuert, ob Aktualisierungsbenachrichtigungen im Editor angezeigt werden; durch die Deaktivierung wird falsedie Benachrichtigung ausgeblendet, dies ersetzt jedoch nicht die Deaktivierung der Prüfung selbst. Wenn Ihre Version beide Optionen unterstützt, aktivieren Sie beide.

Weitere Verbindungen sind funktionsbasiert. Dazu gehören beispielsweise ein konfigurierter externer Monitor, externe Rechtschreib- oder Grammatikprüfungsdienste, DeepL-Übersetzung, KI-Anbieter, externe Schriftkonfiguration und externe Daten, die von einem Dokument angefordert werden. Laut der übergeordneten Vorlage sind die externen LanguageTool- oder Duden-APIs standardmäßig deaktiviert; DeepL ist ebenfalls standardmäßig deaktiviert. Verwenden Sie die Einstellungen Ihrer spezifischen CODE-Version, wenn Sie KI- oder Integrationsoptionen prüfen.

Schritt 1: Wesentliche und optionale Reiseziele ermitteln

Erstellen Sie eine Übersicht über den Bearbeitungsprozess, bevor Sie das Netzwerk ändern. Angenommen, Nextcloud befindet sich unter [URL] cloud.example.comund CODE unter [URL office.example.com]. Der Browser lädt den Editor von CODE, während der CODE-Server über WOPI mit Nextcloud kommuniziert, um das Dokument abzurufen und zu speichern. Behalten Sie diese Server-zu-Server-Route, das Schema und den Port Ihrer Installation sowie alle für Ihre Bereitstellung erforderlichen DNS- oder Proxy-Dienste bei.

Erstellen Sie anschließend eine Bestandsaufnahme der optionalen Dienste in Ihrer effektiven Konfiguration. Suchen Sie <monitors>nach explizit konfigurierten Überwachungsadressen. Prüfen Sie die Remote-Rechtschreibprüfung, DeepL, KI, die Remote-Schriftkonfiguration und die Remote-Konfigurations-URLs. Entfernen Sie benutzerdefinierte Endpunkte, die nicht Teil eines genehmigten Workflows sind. Falls ein solcher Endpunkt benötigt wird, dokumentieren Sie dessen Hostnamen und Zweck, bevor Sie die entsprechende Netzwerkausnahme erstellen.

Prüfen Sie auch die Einstellungen lok_allow. Diese regeln, welche Hosts bearbeitete Dokumente als externe Datenquellen nutzen dürfen, einschließlich URLs für eingefügte Grafiken oder Tabellenkalkulationsfunktionen WEBSERVICE(). Es handelt sich nicht um eine universelle Firewall. Die vorgelagerte Konfiguration weist darauf hin, dass zugelassene WOPI- und POST-Hosts ebenfalls als zulässige Datenquellen behandelt werden können. Daher sollte diese Richtlinie von den Kontrollen für ausgehende Netzwerkzugriffe getrennt gehalten werden.

Schritt 2: Deaktivieren Sie die regelmäßigen Update-Prüfungen

Für den Collabora CODE-Container legen Sie die Optionen über die extra_paramsUmgebungsvariable fest. Führen Sie diese mit dem bestehenden Wert zusammen; behalten Sie alle aktuellen TLS-Terminierungs-, Reverse-Proxy- oder Host-Einstellungen bei, von denen Ihre Installation abhängt. Verwenden Sie ein für Ihre Umgebung freigegebenes CODE-Image-Tag anstelle eines sich verschiebenden latestTags.

services:
  collabora:
    image: collabora/code:<approved-tag>
    environment:
      extra_params: >-
        --o:fetch_update_check=0
        --o:allow_update_popup=false

Dies ist ein beispielhafter Docker Compose-Ausschnitt, keine vollständige Bereitstellung. Behalten Sie Ihre bestehenden Domänenbeschränkungen, Administratoranmeldeinformationen, TLS-Einstellungen und Proxy-Konfiguration bei. In Kubernetes stellt das Upstream-Helm-Chart collabora.extra_paramsbenutzerdefinierte Inhalte bereit und unterstützt diese coolwsd.xml; verwenden Sie die Wertedatei und die Anweisungen für die von Ihnen installierte Chart-Version.

Wenn Sie die XML-Datei direkt bearbeiten, fügen Sie die Werte in das Hauptelement ein <config>:

<fetch_update_check>0</fetch_update_check>
<allow_update_popup>false</allow_update_popup>

Verlassen Sie sich nicht auf manuelle Änderungen in einem laufenden Container, es sei denn, die Datei ist persistent. Ein Neustart, ein Image-Update oder eine Orchestrierungsbereitstellung können sie überschreiben. Ändern Sie die persistente Compose-, Helm- oder eingebundene Konfigurationsquelle und erstellen oder stellen Sie CODE gemäß Ihrer üblichen Vorgehensweise neu bereit.

Schritt 3: Nicht verwendete Integrationen deaktivieren und Dokumentenabrufe einschränken

Lassen Sie dieses <monitors>Feld leer, wenn Sie keinen externen Überwachungsdienst verwenden. Die Upstream-Datei enthält einen kommentierten Beispielmonitor; ein kommentierter Eintrag ist ein Beispiel, keine aktive Verbindung. Entfernen Sie lokal hinzugefügte aktive Monitoreinträge, falls diese nicht mehr benötigt werden.

Die Remote-Rechtschreib- und Grammatikprüfung, DeepL und KI-Anbieterfunktionen sollten deaktiviert bleiben, sofern die Benutzer nicht darauf angewiesen sind. Die Remote-Sprachprüfung kann ausgewählten Dokumenttext an den konfigurierten Dienst senden; ihre Aktivierung hat daher Auswirkungen auf die Konnektivität und die Datenverarbeitung. Ist eine Integration erforderlich, sollte über die Ausgangsrichtlinie nur der dafür vorgesehene Endpunkt zugelassen werden.

Für von Dokumenten angeforderte externe Inhalte entfernen Sie öffentliche Hosts <lok_allow>und behalten Sie nur die Ziele bei, die Ihre Benutzer benötigen. Entfernen Sie hierfür nicht die WOPI-Route. WOPI ist die für die normale Bearbeitung erforderliche Speicherverbindung. Beachten Sie außerdem, dass weit gefasste Einträge im privaten Netzwerk das Abrufen von Dokumenten von mehr internen Hosts ermöglichen können als beabsichtigt. Schränken Sie diese daher entsprechend Ihrer Netzwerkarchitektur und der CODE-Version ein.

Schritt 4: Ausgehende Regeln außerhalb von CODE durchsetzen

Anwendungseinstellungen deaktivieren bestimmte Verhaltensweisen; sie garantieren jedoch nicht, dass das Betriebssystem oder der Prozess keine weiteren Verbindungen öffnen kann. Für eine stärkere Absicherung sollten Sie ausgehende Regeln auf der Host-Firewall, im Container-Netzwerk, in der Kubernetes-Netzwerkrichtlinie oder auf einer externen Firewall anwenden. Verwenden Sie standardmäßig die Option „Verweigern“ für CODE und erlauben Sie anschließend nur das WOPI-Ziel und explizit genehmigte Abhängigkeiten. Erlauben Sie DNS über den Netzwerkdienst, den Ihre Plattform verwendet.

Im obigen Beispiel kann CODE möglicherweise cloud.example.comüber das für WOPI konfigurierte Schema und den Port auf andere öffentliche Ziele zugreifen, während diese gesperrt werden. Vermeiden Sie die Verwendung einer fest codierten IP-Adresse, wenn sich der Speicherhost hinter einem Load Balancer befindet oder seine Adresse sich ändert. Eine verwaltete Zielgruppengruppe oder ein kontrollierter Egress-Proxy sind einfacher zu handhaben. Stellen Sie sicher, dass jeder Proxy für den Container konsistent konfiguriert ist.

Halten Sie eingehende und ausgehende Pfade getrennt. Der Browser muss den veröffentlichten CODE-Endpunkt erreichen können, und der Speicherserver benötigt möglicherweise Zugriff auf CODE für die Erkennung oder für Dokumentsitzungen. Eine Ausgangsrichtlinie, die es CODE erlaubt, WOPI aufzurufen, richtet diese eingehenden Routen nicht ein. Ebenso lok_allowdeaktiviert eine Änderung nicht alle Arten von ausgehenden Verbindungen.

Schritt 5: Starten Sie das System neu und überprüfen Sie die Richtlinie.

Starten Sie CODE neu oder stellen Sie es bereit, damit die effektive Konfiguration geladen wird. Überprüfen Sie die Startprotokolle auf die geladenen Konfigurationswerte und Warnungen zu ignorierten Einstellungen. Öffnen Sie anschließend ein bearbeitbares Testdokument über die normale Speicherintegration, nehmen Sie eine Änderung vor, speichern Sie es, schließen Sie es und öffnen Sie es erneut. Das Dokument sollte die Änderung beibehalten.

• Überprüfen Sie während des Starts und der Bearbeitung die Protokolle der Firewall, des Proxys oder der Netzwerkrichtlinien. Der erwartete WOPI-Datenverkehr sollte zugelassen werden.
• Vergewissern Sie sich, dass die von Ihnen blockierten externen Ziele tatsächlich gesperrt sind. Ein leeres Protokoll allein beweist nicht, dass jede mögliche Route blockiert ist.
• Nach Ablauf des vorherigen Aktualisierungsprüfungsintervalls prüfen Sie, ob der CODE-Container versucht hat, nach Aktualisierungen zu suchen. Stellen Sie sicher, dass das Aktualisierungs-Popup fehlt, falls dieses ebenfalls deaktiviert wurde.
• Testen Sie alle Funktionen, die Benutzer benötigen, einschließlich externer Schriftarten, Übersetzungen, Sprachhilfen, Dokumentverknüpfungen und Formeln zum Abrufen externer Daten. Stellen Sie nur das spezifische, genehmigte Ziel wieder her, das für eine erforderliche Funktion notwendig ist.

Wenn Dokumente nicht geöffnet oder gespeichert werden können, überprüfen Sie zuerst DNS und die WOPI-Verbindung zwischen den Servern. Falls nur ein externes Bild oder eine Tabellenkalkulationsformel nicht funktioniert, überprüfen Sie dies lok_allowunabhängig von der Firewall-Richtlinie. Das Blockieren einer öffentlichen Datenquelle, während WOPI weiterhin funktioniert, ist beabsichtigt; das Blockieren von Speichervorgängen bedeutet, dass die ausgehende Datenrichtlinie zu weit gefasst ist.

Was die Deaktivierung dieser Verbindungen garantieren kann und was nicht.

Durch Deaktivieren der Update-Prüfung und nicht verwendeter Integrationen wird die erwartete ausgehende Aktivität von CODE reduziert. Eine standardmäßig ablehnende Netzwerkrichtlinie definiert die Durchsetzungsgrenze. Keine dieser Richtlinien regelt den separaten Datenverkehr Ihres Hosts, Ihrer Container-Laufzeitumgebung, Ihrer Orchestrierungsplattform, Ihres Reverse-Proxys oder Ihres Überwachungsagenten. Falls die Anforderung den gesamten Server betrifft, sollten Sie auch diese Komponenten prüfen.

Die Standardkonfigurationen können sich zwischen den Releases ändern, und Integrationen können zusätzliche Einstellungen hinzufügen. Vergleichen Sie vor der Veröffentlichung die mit Ihrem festgelegten Image ausgelieferte Vorlage mit der aktuellen Upstream-Vorlage und testen Sie die Implementierung in der Staging-Umgebung. Die wichtigsten Referenzen sind die Upstream-Konfigurationsvorlage `coolwsd.xml` von Collabora , die offiziellen Helm-Chart-Werte und die zugehörige Erklärung zu selbstgehosteten Deployments und externen Diensten .