Update-Policy für Nextcloud-Software und Systemkomponenten

1. Zielsetzung

Diese Richtlinie regelt den Umgang mit Software- und Systemupdates auf der von Wolkesicher betriebenen Plattform. Ziel ist ein Betrieb, der gleichrangig sicher, stabil und verfügbar ist. Updates werden risikobasiert bewertet und kontrolliert eingespielt — weder vorschnell noch ungerechtfertigt verzögert.

Diese Richtlinie beschreibt die internen Grundsätze und Zielwerte des Betriebs. Sie begründet keine eigenständigen vertraglichen Zusicherungen oder Service Level Agreements; verbindliche Leistungsumfänge ergeben sich ausschließlich aus den jeweiligen Verträgen mit dem Kunden.

2. Grundsätze zur Versionsstrategie

Für den Produktivbetrieb wird nicht reflexhaft die jeweils neueste Version einer Software eingesetzt, sondern eine erprobte und vom Hersteller aktiv unterstützte Version.

Konkret gilt:

  • Eingesetzt wird bevorzugt eine Version, die bereits ausreichend im Markt erprobt ist und sich im Produktiveinsatz Dritter bewährt hat.
  • Voraussetzung ist in jedem Fall ein aktiver Herstellersupport mit regelmäßigen Sicherheitsupdates. Übergangsphasen (z. B. reine Security-Maintenance am Ende des Lebenszyklus einer Version) können im Rahmen einer Einzelfallbewertung weiter genutzt werden, sofern die Sicherheitsversorgung gewährleistet bleibt und ein geordneter Upgrade-Pfad eingeleitet ist.
  • Die Versionsauswahl berücksichtigt zusätzlich den verbleibenden Support-Zeitraum, damit ein geordneter Upgrade-Pfad zur jeweils nachfolgenden Version jederzeit möglich bleibt und keine EOL-Notsituationen entstehen.
  • Ein Wechsel auf eine neuere Version erfolgt geplant, nach interner Bewertung und ggf. nach vorheriger Validierung in einer Testumgebung.

3. Update-Strategie für Nextcloud

Die Durchführung von Nextcloud-Core-Updates (einschließlich occ upgrade, Datenbankmigrationen und systemnaher Eingriffe an der Instanz) erfolgt ausschließlich durch Wolkesicher. Kunden führen Core-Upgrades nicht eigenständig durch.

3.1 Reguläre Funktions- und Maintenance-Updates

  • Updates werden nicht unmittelbar am Tag der Veröffentlichung eingespielt, sondern nach kurzer Beobachtungsphase.
  • Vor dem Rollout werden ausgewertet:
    • offizielle Release-Notes und Changelog
    • bekannte Issues im Upstream-Repository
    • Rückmeldungen aus Community und Nutzerfeedback
    • eigene Erfahrungen aus Test- oder Pilotsystemen
  • Ziel ist es, Regressionsfehler frühzeitig zu erkennen und auszuschließen, bevor sie auf Produktivsystemen wirksam werden.
  • Bei kurzfristig vom Hersteller nachgeschobenen Hotfixes (Patch-on-Patch innerhalb weniger Tage) wird in der Regel die konsolidierte, spätere Version eingespielt, sofern dies die in 3.3 genannten Ziel-Reaktionszeiten nicht verletzt.

3.2 Stabilitäts- und Kompatibilitätsprüfung

Vor dem produktiven Einspielen wird bewertet:

  • Kompatibilität mit der eingesetzten Systemumgebung (PHP, Datenbank, Apps, Integrationen)
  • Auswirkungen auf Performance und bestehende Konfigurationen
  • Prüfung, ob in Changelogs genannte oder eigene gemeldete Fehlerbilder in der Zielversion behoben sind
  • Verfügbarkeit eines funktionsfähigen Rollback-Pfads (insbesondere bei Major-Upgrades mit Datenbankmigrationen)

3.3 Sicherheitskritische Updates

Sicherheitsupdates werden nach Schweregrad priorisiert. Wolkesicher orientiert sich — soweit technisch und betrieblich vertretbar — an folgenden Ziel-Reaktionszeiten:

Schweregrad Kriterien Ziel-Reaktionszeit
Kritisch CVSS ≥ 9,0, aktiv ausgenutzte Schwachstelle oder Hersteller-Einstufung „Critical“ innerhalb von 24–72 Stunden
Hoch CVSS 7,0–8,9 bzw. Hersteller-Einstufung „High“ innerhalb von 7 Tagen
Mittel/Niedrig CVSS < 7,0 im Rahmen des regulären Update-Zyklus
  • Die Einstufung erfolgt auf Basis einer Gesamtbewertung aus CVSS-Score, Herstellerbewertung, Ausnutzbarkeit in der konkreten Einsatzumgebung und öffentlich bekanntem Exploit-Status. CVSS ist ein Indikator, nicht das alleinige Kriterium; eine rechnerisch hohe Bewertung kann bei nicht gegebener Ausnutzbarkeit herabgestuft, eine rechnerisch mittlere bei aktiver Ausnutzung heraufgestuft werden.
  • Die genannten Zeitfenster sind interne Orientierungswerte und keine vertraglich zugesicherten Reaktionszeiten.
  • Rollouts kritischer Sicherheitsupdates erfolgen gegebenenfalls außerhalb der in Ziffer 6 genannten regulären Wartungsfenster; siehe Ziffer 6.
  • Nicht-Betroffenheit der eigenen Konfiguration entbindet nicht von der Pflicht zur Bewertung, sondern ist deren Ergebnis.

3.4 Nextcloud-Apps und Verantwortungsabgrenzung

Die Plattform wird in der Standardauslieferung von Nextcloud Community Edition betrieben. Als Standardauslieferung gelten ausschließlich die vom Hersteller Nextcloud GmbH in der jeweiligen Core-Version mitgelieferten und im Auslieferungszustand standardmäßig aktivierten Apps (sogenannte Shipped Apps bzw. Bundled Apps). Nicht zur Standardauslieferung zählen: App-Store-Apps, zusätzlich aktivierte oder nachinstallierte Apps, von Nextcloud optional bereitgestellte Erweiterungen sowie Apps, die im Rahmen einer individuellen Einrichtung durch Wolkesicher oder den Kunden aktiviert wurden — unabhängig davon, ob dies bei Vertragsbeginn, im laufenden Betrieb oder zu einem späteren Zeitpunkt erfolgt ist.

Die Aktualisierung der in der jeweiligen Nextcloud-Instanz installierten Apps (App-Store-Apps, optional aktivierte Erweiterungen jenseits der Standardauslieferung) liegt grundsätzlich in der Verantwortung des Kunden als Administrator seiner Instanz.

Verantwortungsabgrenzung:

  • Kunde: verantwortlich innerhalb seiner Instanz und im Rahmen seiner Administratorrechte — insbesondere für Auswahl, Aktivierung, Konfiguration und Aktualisierung von Apps sowie für deren Eignung für seinen jeweiligen Einsatzzweck.
  • Wolkesicher: verantwortlich für Plattform, Nextcloud-Core in der Standardauslieferung der Community Edition, Basisbetrieb und Mandantenschutz. Core-Updates und systemnahe Eingriffe an der Instanz werden ausschließlich durch Wolkesicher durchgeführt.

Wolkesicher schuldet keine Prüfung, keinen Support und keine Haftung für vom Kunden installierte oder aktivierte Drittanbieter-Apps außerhalb der Standardauslieferung — weder hinsichtlich Funktionsfähigkeit, Sicherheit, Updatefähigkeit noch Kompatibilität –, soweit dies nicht ausdrücklich vertraglich vereinbart wurde. Funktion, Stabilität und Sicherheit solcher Apps liegen in der Verantwortung des jeweiligen App-Anbieters; ihre Aktivierung und Aktualisierung erfolgt durch den Kunden auf eigenes Risiko.

Bei Apps mit plattformschädigender Wirkung — insbesondere bei nachweislicher Beeinträchtigung des stabilen Betriebs der Instanz, Gefährdung anderer Mandanten oder Sicherheitsrisiken für die Plattform — ist Wolkesicher berechtigt, die betroffene App ohne Vorankündigung zu deaktivieren. Die Deaktivierung ist auf das zur Gefahrenabwehr erforderliche Maß beschränkt. Der Kunde wird unverzüglich nach der Deaktivierung informiert, inklusive Begründung und, soweit möglich, Hinweisen zur Abstellung oder zu geeigneten Alternativen.

3.5 End-of-Life und Vorrang des Major-Upgrades

Erreicht eine eingesetzte Nextcloud-Version das Ende des Herstellersupports, ist ein Upgrade auf eine unterstützte Nachfolgeversion zwingend erforderlich. Ein Weiterbetrieb einer EOL-Version ist aus Sicherheitsgründen ausgeschlossen, sofern nicht im Einzelfall eine ausdrückliche, befristete Sondervereinbarung getroffen wird.

Für solche Upgrades gilt:

  • Das Major-Upgrade des Nextcloud-Core hat absoluten Vorrang. Es wird nicht durch kundenseitig installierte Drittanbieter-Apps blockiert oder verzögert.
  • Kundenseitig aktivierte Drittanbieter-Apps außerhalb der Standardauslieferung werden im Rahmen des Upgrades nicht gesondert auf Kompatibilität geprüft. Sind solche Apps nach dem Upgrade nicht mehr lauffähig, nicht kompatibel, fehlerhaft oder nicht erreichbar, liegt dies ausschließlich im Verantwortungsbereich des Kunden.
  • Wolkesicher schuldet für Drittanbieter-Apps weder Kompatibilitätsanpassungen noch Wiederherstellungs- oder Migrationsleistungen.
  • Ein Anspruch auf Verzögerung oder Aussetzen eines Core-Upgrades wegen inkompatibler Drittanbieter-Apps besteht nicht, wenn die eingesetzte Nextcloud-Version das Ende des Herstellersupports (End of Life) erreicht hat oder dieses innerhalb des geplanten Upgrade-Zeitraums erreichen wird. Gleiches gilt, wenn ein Core-Upgrade aus Sicherheitsgründen oder wegen EOL einer erforderlichen Systemkomponente (z. B. PHP, Datenbank) zwingend erforderlich ist. In diesen Fällen hat die Aufrechterhaltung eines sicherheitsunterstützten Betriebszustands Vorrang vor der Funktionsfähigkeit einzelner Drittanbieter-Apps.
  • Der Kunde ist gehalten, die Kompatibilität der von ihm eingesetzten Apps mit kommenden Nextcloud-Versionen rechtzeitig selbst zu prüfen und ggf. Alternativen zu identifizieren.

Dieser Grundsatz ergibt sich unmittelbar aus der in 3.4 geregelten Verantwortungsabgrenzung: Wer außerhalb der Standardauslieferung Apps einsetzt, trägt auch deren Lebenszyklusrisiko.

4. Update-Strategie für Systemkomponenten

Diese Regeln gelten analog für alle systemnahen Komponenten:

  • Betriebssystempakete
  • Laufzeitumgebungen (PHP, Datenbank, Webserver)
  • Middleware, Reverse Proxies und abhängige Dienste
  • Storage- und Clusterkomponenten

4.1 Versionsauswahl

  • Eingesetzt werden Versionen, die sich im produktiven Einsatz als stabil bewährt haben und aktiv Herstellersupport erhalten.
  • LTS-Varianten werden bevorzugt, sofern verfügbar.

4.2 Regulärer Update-Prozess

  • Updates werden nach Veröffentlichung gesichtet (Changelogs, CVE-Listen, Issue-Tracker) und im Rahmen geplanter Wartungsfenster eingespielt.
  • Vor Einspielen auf Produktivsystemen wird, soweit möglich, in einer Test-/Staging-Umgebung validiert.

4.3 Sicherheitsrelevante Updates

  • Sicherheitsupdates für Systemkomponenten werden nach denselben Schweregrad-Fenstern wie unter 3.3 behandelt — ebenfalls als Orientierungswerte, soweit technisch und betrieblich vertretbar.
  • Bei aktiv ausgenutzten Schwachstellen (z. B. 0-Day mit öffentlichem PoC) erfolgt das Einspielen unverzüglich, notfalls außerhalb geplanter Wartungsfenster.

5. Test- und Rollback-Strategie

  • Für Major-Versionsprüfungen (Nextcloud, Datenbank, PHP-Major) wird vor dem produktiven Rollout eine Testinstallation mit repräsentativer Konfiguration validiert.
  • Vor jedem Update auf Produktivsystemen werden konsistente Sicherungen (Datenbank, Konfiguration, Datenverzeichnis) erstellt.
  • Ein Rollback-Pfad ist dokumentiert.

5.1 Grenzen des Rollbacks

Bei Minor- und Maintenance-Updates ist ein Rollback in der Regel durch das Wiedereinspielen des vorherigen Code-Stands möglich.

Bei Nextcloud-Major-Upgrades mit Schemamigrationen (insbesondere Änderungen an den oc_*-Tabellen) ist ein technisches Zurückrollen der laufenden Instanz nicht möglich. Ein „Rollback“ bedeutet in diesem Fall die vollständige Wiederherstellung aus einer vor dem Upgrade erstellten konsistenten Sicherung (Code, Datenbank, Konfiguration, Datenverzeichnis). Daten, die zwischen Upgrade und Wiederherstellung in der neueren Version erzeugt wurden, können dabei verloren gehen.

Dieser Umstand wird bei der Planung von Major-Upgrades berücksichtigt und entsprechend vorbereitet.

6. Wartungsfenster und Kommunikation

  • Reguläre Wartungsarbeiten im Business-Bereich erfolgen grundsätzlich innerhalb definierter Wartungsfenster außerhalb der üblichen Geschäftszeiten, in der Regel werktags zwischen 22:00 und 06:00 Uhr sowie am Wochenende.
  • Wartungen können bei Bedarf auch außerhalb dieser Zeiträume durchgeführt werden, sofern dies aus technischen oder betrieblichen Gründen erforderlich ist.
  • Planbare Wartungen werden dem Kunden in der Regel mindestens 24 Stunden vorab im Kundenbereich angekündigt.
  • Bei sicherheitskritischen Schwachstellen oder betrieblich relevanten Störungen können Wartungsmaßnahmen kurzfristig und ohne Vorankündigung erfolgen, auch außerhalb der genannten Wartungsfenster. In diesen Fällen erfolgt eine Information des Kunden in angemessener Frist über die üblichen Kommunikationskanäle.
  • Abweichende Regelungen können sich aus individuell vereinbarten Service Level Agreements ergeben.

7. Betriebspriorität

Sicherheit und Stabilität werden als gleichrangige Ziele behandelt. Beide tragen gemeinsam zur Verfügbarkeit bei.

Daraus folgt insbesondere: Ein längeres Beibehalten einer bewährten, stabilen Version von Systemsoftware ist ausdrücklich legitim, solange keine ausnutzbaren Sicherheitslücken bestehen und der Herstellersupport (mindestens als Security-Maintenance) fortbesteht. Ein Update, das technisch möglich wäre, aber keinen sicherheitsrelevanten oder betrieblich erforderlichen Mehrwert bringt, wird nicht allein aus Gründen der Aktualität durchgeführt, wenn dies die Stabilität des Gesamtsystems gefährden könnte. Bewährte Konfigurationen haben Vorrang vor reiner Versionsaktualität, sofern sie sicherheitstechnisch unbedenklich sind.

8. Entscheidungsgrundlage und Nachweisführung

Relevante Sicherheitsinformationen werden fortlaufend aus Hersteller-Advisories, CVE-Datenbanken sowie öffentlich zugänglichen Sicherheitsquellen bewertet. Diese bilden die Grundlage für die Priorisierung und Einsteuerung von Updates.

Jede Update-Entscheidung — Einspielen, Verzögern, Aussetzen — basiert auf der Abwägung folgender Faktoren:

  • Schweregrad der Sicherheitslage (CVE, Hersteller-Advisory, öffentliche Ausnutzung)
  • Stabilität und Reife der Zielversion
  • Kompatibilität mit der bestehenden Systemumgebung
  • Betriebliche Auswirkungen (Downtime, Migrationsaufwand, Rollback-Möglichkeit)
  • Erfahrungen aus Community und vergleichbaren Produktivumgebungen

Updates erfolgen kontrolliert und werden nicht ungeprüft automatisiert in Produktivsysteme eingespielt.

Durchgeführte Updates werden mindestens mit Datum, betroffener Komponente und Versionsstand dokumentiert und sind intern nachvollziehbar archiviert.

Diese Dokumentation dient ausschließlich internen Betriebszwecken. Ein Anspruch des Kunden auf Einsicht, Herausgabe oder Übermittlung der Update-Dokumentation besteht nicht, sofern nicht ausdrücklich ein entsprechender Service Level Agreement oder eine individuelle vertragliche Vereinbarung getroffen wurde. Unberührt bleiben gesetzliche Auskunftsansprüche sowie berechtigte Informationsinteressen des Kunden im Rahmen konkreter Störungsfälle, soweit diese kausal auf ein Update zurückzuführen sind.

9. Zusammenfassung

  • Eingesetzt wird eine erprobte, vom Hersteller unterstützte Version mit geordnetem Upgrade-Pfad — weder reflexhaft die neueste noch grundlos verzögert.
  • Nextcloud-Core-Updates erfolgen ausschließlich durch Wolkesicher; Drittanbieter-Apps liegen in der Verantwortung des Kunden.
  • Sicherheit und Stabilität sind gleichrangige Ziele; ein Verbleib auf einer bewährten, sicheren Version ist zulässig.
  • Major-Upgrades haben Vorrang vor kundenseitigen Drittanbieter-Apps — deren Kompatibilität liegt im Risikobereich des Kunden.