Nextcloud unter PCI DSS – Ein schmaler Grat zwischen Flexibilität und Compliance

Es ist eine dieser typischen Konstellationen in der IT: Ein Unternehmen hat sich für Nextcloud als zentrale Kollaborationsplattform entschieden – aus guten Gründen, denn die Open-Source-Lösung bietet viel Kontrolle, keine Lizenzkosten und eine beeindruckende Feature-Liste. Doch dann kommt die Compliance-Abteilung um die Ecke und fragt: „Und wie sieht das mit PCI DSS aus?“ Plötzlich steht man vor einer Herausforderung, die viele Teams zunächst unterschätzen. Denn PCI DSS – der Payment Card Industry Data Security Standard – ist kein Papiertiger, sondern ein detailliertes Regelwerk mit zwölf Hauptanforderungen, die für alle Unternehmen verpflichtend sind, die Kreditkartendaten verarbeiten, speichern oder übertragen. Und Nextcloud ist nun einmal nicht als PCI-konforme Box konzipiert.

Das heißt aber nicht, dass man Nextcloud in einer PCI-regulierten Umgebung vergessen muss. Im Gegenteil: Viele Unternehmen setzen Nextcloud erfolgreich als Teil ihrer Infrastruktur ein, ohne gegen den Standard zu verstoßen. Der Schlüssel liegt im Verständnis der Anforderungen und in einer sauberen Architektur. Wer einfach eine Nextcloud-Instanz aufsetzt, dort Kreditkartenabrechnungen als PDF ablegt und meint, die Ende-zu-Ende-Verschlüsselung mache schon alles sicher, der wird spätestens beim nächsten Audit böse überrascht. PCI DSS verlangt nämlich mehr als nur eine verschlüsselte Dateiablage.

Was PCI DSS wirklich von Nextcloud verlangt

PCI DSS definiert zwölf Anforderungen, die in sechs Gruppen zusammengefasst sind. Für eine Nextcloud-Umgebung sind vor allem vier Bereiche relevant:

• Build and Maintain a Secure Network: Firewalls, sichere Konfiguration, keine Standard-Passwörter. Nextcloud läuft auf einem Webserver (Apache, Nginx) und benötigt eine Datenbank – beides muss nach aktuellen Härtungsrichtlinien konfiguriert sein.
• Protect Cardholder Data: Verschlüsselung ruhender und übertragener Daten. Nextcloud bietet serverseitige Verschlüsselung und Ende-zu-Ende-Verschlüsselung (E2EE) – aber nicht jede Variante erfüllt die PCI-Anforderungen automatisch.
• Maintain a Vulnerability Management Program: Regelmäßige Patches, Virenschutz, sichere Entwicklung. Nextcloud veröffentlicht regelmäßig Sicherheitsupdates – der Betreiber muss sie zeitnah einspielen.
• Implement Strong Access Control Measures: Zugriff nach dem Need-to-know-Prinzip, eindeutige Identifikation, Multi-Faktor. Nextcloud kennt Benutzer, Gruppen, Berechtigungen und kann mit LDAP/AD verbunden werden. Auch Zwei-Faktor-Authentifizierung ist an Bord – aber nur, wenn sie auch aktiviert und durchgesetzt wird.
• Regularly Monitor and Test Networks: Logging, Überwachung, Penetrationstests. Nextclouds eigenes Logging ist für viele Audits zu rudimentär – ein SIEM-System muss die Daten aufnehmen können.
• Maintain an Information Security Policy: Dokumentierte Prozesse, Verantwortlichkeiten. Das ist kein technisches Problem, aber ein organisatorisches – Nextcloud liefert keine Policy-Vorlage.

Interessant ist: PCI DSS unterscheidet nicht zwischen kommerzieller Software und Open Source. Solange die Umgebung die Anforderungen erfüllt, ist das Tool egal. Das bedeutet aber auch: Jede Organisation, die Nextcloud selbst hostet, trägt die volle Verantwortung für die Einhaltung. Ein Managed-Anbieter wie Nextcloud GmbH selbst bietet zwar Hosting-Dienstleistungen, aber meines Wissens kein PCI-zertifiziertes Produkt – das muss man im Vertrag prüfen.

Nextclouds eingebaute Sicherheitswerkzeuge – eine Bestandsaufnahme

Nextcloud ist in den letzten Jahren sicherheitstechnisch deutlich gereift. Die Plattform bietet von Haus aus einige Funktionen, die für PCI DSS relevant sind:

• Verschlüsselung auf mehreren Ebenen: Die serverseite Verschlüsselung (Server-Side Encryption) verschlüsselt Dateien auf dem Speichermedium mit einem zentralen Schlüssel. Die E2EE hingegen verschlüsselt bereits auf dem Client – der Server hat keinen Zugriff auf die Inhalte. Für PCI DSS ist das ein zweischneidiges Schwert: E2EE verhindert, dass der Server die Daten überhaupt sehen kann, aber auch ein Virenscanner oder ein DLP-System kann dann nichts mehr prüfen. Das muss man mit den Anforderungen an „Protect Cardholder Data“ abgleichen.
• Granulare Zugriffssteuerung: Nextcloud erlaubt es, Berechtigungen bis auf Dateiebene zu vergeben, inklusive Freigabelinks mit Passwort und Ablaufdatum. Das ist grundsätzlich gut – aber PCI DSS verlangt, dass Zugriffe auf Basis von Jobfunktionen und mit minimalen Rechten vergeben werden. In der Praxis heißt das: Administratoren sollten nicht gleichzeitig die Logs einsehen und Dateien löschen können. Nextcloud kann das abbilden, es erfordert aber eine durchdachte Rollenkonfiguration.
• Audit-Logs: Die integrierte Audit-Engine zeichnet Ereignisse wie Dateioperationen, Login-Versuche und Berechtigungsänderungen auf. Allerdings sind die Logs nicht direkt an ein PCI-konformes Format angepasst. Man muss sie entweder in ein SIEM exportieren (z. B. via Syslog) oder eine App wie „Audit“ nutzen, die die Daten strukturierter ausgibt. Dass die Logs manipulationssicher sein müssen, steht auf einem anderen Blatt – Nextcloud speichert sie in der Datenbank, was nicht unbedingt ausreicht, wenn ein Angreifer Datenbank-Zugriff hat.
• Zwei-Faktor-Authentifizierung (2FA): Ja, vorhanden. Aber standardmäßig ist sie nicht erzwungen. Für PCI DSS muss 2FA für alle externen Zugriffe auf die Cardholder Data Environment (CDE) aktiviert sein. Wer also Nextcloud aus dem Internet erreichbar macht (etwa für mobile Mitarbeiter), muss 2FA für alle Benutzer verpflichtend machen – und das auch durchsetzen.
• File Integrity Monitoring: Nextcloud selbst hat kein eingebautes FIM. Das muss auf Betriebssystemebene oder mit Tools wie OSSEC, Tripwire oder AIDE nachgerüstet werden. PCI DSS verlangt, dass Änderungen an Systemdateien überwacht werden.

Ein Punkt, der oft übersehen wird: Die Datenbank, in der Nextcloud Metadaten (Dateinamen, Pfade, Benutzerinformationen) speichert, kann selbst PCI-relevante Informationen enthalten – etwa wenn ein Benutzer eine Datei mit dem Namen „Kreditkarten_2025_03.csv“ anlegt. Dateinamen sind Klartext, auch wenn die Datei selbst verschlüsselt ist. Das ist eine typische Fallgrube, die bei Audits auffällt.

Die größten Stolpersteine im Detail

Wer Nextcloud in einer PCI-Umgebung betreibt, stößt immer wieder auf dieselben Knackpunkte. Ich möchte drei besonders kritische Bereiche näher beleuchten:

1. Verschlüsselung und das Problem der Kontrolle

PCI DSS fordert, dass Kreditkartendaten sowohl bei der Übertragung (in transit) als auch bei der Speicherung (at rest) verschlüsselt sein müssen. Nextcloud erfüllt das grundsätzlich: Die Datenübertragung läuft über TLS (HTTPS), und die Dateien können serverseitig verschlüsselt werden. Aber die serverseitige Verschlüsselung hat einen Haken: Der private Schlüssel liegt auf dem Server – wer den Server kompromittiert, hat im Zweifel Zugriff auf alle verschlüsselten Dateien. PCI DSS verlangt eine stärkere Trennung: Die Entschlüsselungsschlüssel sollten niemals gemeinsam mit den verschlüsselten Daten auf demselben System liegen.

Nextcloud bietet daher die Ende-zu-Ende-Verschlüsselung als Alternative. Hier liegt der Schlüssel nur auf den Clients – der Server sieht nur Chiffrat. Das klingt perfekt für PCI DSS, doch es bringt andere Probleme mit sich: Wenn ein Benutzer seinen Schlüssel verliert, sind die Daten unwiederbringlich weg. Außerdem kann der Server keine Komprimierung, keine Vorschaubilder und keine Virenprüfung mehr durchführen. Und: PCI DSS verlangt die Möglichkeit, Daten auf Anforderung des Karteninhabers oder des Acquirers zu löschen – bei E2EE kann der Administrator nicht nachprüfen, ob eine Datei wirklich gelöscht wurde, weil er sie nicht lesen kann. Das ist ein schwerwiegendes Compliance-Problem.

Ein Ausweg ist die hybride Verschlüsselung: Man nutzt serverseitige Verschlüsselung mit einem HSM (Hardware Security Module), das die Schlüssel in einem abgetrennten Sicherheitsmodul verwaltet. Das ist aufwändig, aber machbar. Einige Nextcloud-Integratoren bieten solche Lösungen an – sie kosten allerdings extra und sind nicht standardmäßig enthalten.

2. Netzwerksegmentierung und die Rolle der CDE

PCI DSS teilt die IT-Umgebung in die Cardholder Data Environment (CDE) und alles andere ein. Die CDE umfasst alle Systeme, die Kreditkartendaten verarbeiten, speichern oder übertragen. Wenn Nextcloud innerhalb der CDE betrieben wird, müssen alle PCI-Anforderungen auf diese Instanz angewendet werden. Das bedeutet: Firewall-Regeln, die nur notwendigen Verkehr zulassen, keine gemeinsamen Verzeichnisse mit Nicht-CDE-Systemen, strenge Zugriffskontrollen. Viele Unternehmen stellen fest, dass Nextcloud – so praktisch es ist – in der CDe einfach zu viele Funktionen bietet, die nicht benötigt werden und die Angriffsfläche vergrößern.

Eine gängige Strategie ist daher, Nextcloud außerhalb der CDE zu betreiben. Das funktioniert, solange auf Nextcloud keine Kreditkartendaten im Klartext gespeichert werden. Man kann dort Rechnungen ablegen, die nur die letzten vier Ziffern der Karte zeigen, oder Zahlungsbelege mit maskierten Nummern. Die vollständigen Kartendaten verbleiben im Zahlungsgateway (z. B. Stripe, Adyen) oder in einem speziell gesicherten Token-Speicher. Nextcloud dient dann als Frontend für die Zusammenarbeit – aber die sensitiven Daten werden nie dorthin übertragen. Das ist praxiserprobt und deutlich einfacher zu zertifizieren.

Allerdings muss die Kommunikation zwischen den Systemen trotzdem abgesichert sein. Wenn Nextcloud aus der CDE per API auf ein Token-System zugreift, muss diese Verbindung ebenfalls TLS-verschlüsselt und authentifiziert sein. Und: Die Administratoren, die Nextcloud betreuen, dürfen nicht automatisch Zugriff auf die CDE haben – das sind oft separate Rollen.

3. Logging und Überwachung – eine never ending Story

PCI DSS verlangt, dass Logs aller Systeme, die die CDE berühren, für mindestens ein Jahr aufbewahrt werden – und die letzten drei Monate müssen sofort verfügbar sein. Nextclouds integrierte Logs sind dafür nicht ausgelegt. Sie werden in der Datenbank gespeichert, die schnell anwächst, und wenn die Datenbank crasht, sind die Logs weg. Es ist daher dringend ratsam, die Logs per Syslog an ein zentrales SIEM-System zu senden (z. B. Splunk, ELK, Graylog). Nextcloud unterstützt Syslog nativ – man muss es nur in der Konfiguration aktivieren.

Doch damit ist es nicht getan. PCI DSS fordert, dass Logs auf Anomalien überwacht werden. Wer also tausend Datei-Löschungen pro Stunde hat, muss darauf eine Alarmierung einrichten. Das erfordert Regeln im SIEM, die auf Nextcloud-spezifische Ereignisse wie „Login-Fehler“, „Datei-Download durch Admin“ oder „Berechtigungsänderung“ reagieren. Das ist aufwändig, aber umsetzbar. Man sollte aber nicht vergessen: Die Nextcloud-Instanz selbst muss auch gehärtet sein – denn ein Angreifer, der die Nextcloud-Administration übernimmt, könnte die Logs manipulieren. PCI DSS will daher, dass Logs nur lesbar für das Überwachungspersonal sind, nicht für Admins. In Nextcloud ist das eine Herausforderung, weil der Admin per Definition vollen Zugriff auf das System hat. Eine Lösung ist, die Datenbank-Logs in einen separaten, von Nextcloud unabhängigen Speicher zu schreiben (z. B. einen Syslog-Server, der nur SIEM-Zugriff erlaubt).

Architekturansätze für die Praxis

Aus der Beratungspraxis kenne ich drei Szenarien, wie Unternehmen Nextcloud und PCI DSS zusammenbringen:

Szenario 1: Nextcloud als reine Kollaborationsplattform (keine CDE)

Dies ist der einfachste Weg. Nextcloud wird in einem eigenen Netzwerksegment betrieben (nicht in der CDE). Es dürfen keine Kreditkartendaten auf Nextcloud gespeichert werden – das wird durch technische Maßnahmen (DLP, Berechtigungen, Schulungen) und organisatorische Regeln sichergestellt. Rechnungen werden vor dem Hochladen maskiert. Zahlungsdaten werden nur in speziellen PCI-zertifizierten Systemen (z. B. Zahlungsgateway, Token-Vault) vorgehalten. Nextcloud dient lediglich als Ablage für Dokumente, die keine sensitiven Kartendaten enthalten. Die Compliance besteht dann darin, die Trennung der Umgebungen nachzuweisen – Firewall-Regeln, Datenflussdiagramme, jährliche Penetrationstests. Das ist machbar und wird von vielen Unternehmen so praktiziert.

Szenario 2: Nextcloud für nur teilweise sensitive Daten (mit PCI DSS-Konformität auf der Instanz)

Will man Nextcloud doch in die CDE einbeziehen – etwa weil die Buchhaltung Belege mit Kartendaten in der Cloud benötigt –, muss die gesamte Nextcloud-Instanz gehärtet werden. Das bedeutet: Betrieb auf einem dedizierten Server (kein Teilen mit anderen Diensten), Härtung nach CIS-Benchmarks, Einsatz von E2EE plus HSM für die serverseitige Verschlüsselung, 2FA für alle Benutzer, Verwendung eines WAF (Web Application Firewall) vor Nextcloud, regelmäßige Updates, Schwachstellenscans und Pen-Tests. Das Logging muss extern erfolgen. Die Benutzeranzahl sollte klein gehalten werden – idealerweise nur die Personen, die die Belege tatsächlich benötigen. Der Aufwand ist hoch, aber für spezielle Anwendungsfälle (z. B. ein kleines Team im Rechnungswesen) vertretbar. Allerdings wird man Nextcloud in dieser Konfiguration kaum für alle Mitarbeiter öffnen können.

Eine interessante Alternative ist die Nutzung der Nextcloud-„Files Lock“-Funktion in Kombination mit einer separaten App zur Tokenisierung: Man speichert nur einen Verweis auf den Token (eine ID), nicht die Kartendaten. Das setzt aber voraus, dass die Token selbst nicht wieder in Klartext umgewandelt werden können – und das muss dann das Zahlungssystem leisten. Nextcloud wird so zum reinen Datei-Manager für IDs, was die Angriffsfläche drastisch reduziert.

Szenario 3: Managed Nextcloud mit PCI DSS-Erweiterungen

Es gibt spezialisierte Dienstleister, die Nextcloud als Managed Service anbieten und dabei auf PCI DSS-Konformität achten. Sie stellen eine gehärtete Umgebung bereit, kümmern sich um Patches, bieten SIEM-Integration, HSM-Unterstützung und oft ein separates Management-Panel für Compliance-Reporting. Allerdings ist das eine Nische – die meisten Managed-Provider haben kein PCI-Zertifikat für ihre Nextcloud-Plattform, weil sie nicht wissen, ob die Daten tatsächlich Kreditkarten enthalten. Man muss daher im Service-Level-Agreement klar regeln, wer für welche Controls verantwortlich ist. Ein Vorteil dieser Variante: Der Betreiber übernimmt die lästigen Aufgaben wie Log-Management und Schwachstellenscans, während der Kunde nur die Konfiguration seiner Benutzer anpassen muss.

Ein Wort zur Zertifizierung und Selbstauskunft

PCI DSS verlangt keine Zertifizierung der Software – nur der Prozesse und der Umgebung. Das bedeutet, dass man Nextcloud auch ohne offizielles Zertifikat compliant betreiben kann, wenn man nachweist, dass alle Anforderungen erfüllt sind. Dazu gehört eine umfassende Dokumentation: Netzwerkdiagramme, Datenflussanalysen, Policy-Dokumente, Ergebnisse von Penetrationstests und Schwachstellenscans, Log-Auswertungen und Zugriffsmatrixen. Viele Unternehmen scheitern nicht an der Technik, sondern an der Dokumentation. Nextcloud selbst kann dabei helfen, indem es Konfigurationsänderungen in der Datenbank speichert – aber das ist noch lange kein vollständiges Audit-Protokoll im PCI-Sinne.

Eine interessante Frage ist, ob Nextcloud GmbH eine PCI-zertifizierte Variante anbieten wird. Bisher gibt es keine offizielle Ankündigung, aber der Trend zu mehr Compliance (DSGVO, HIPAA, PCI) ist erkennbar. Die Open-Source-Community arbeitet an einer besseren Audit-App und an der Unterstützung von HSMs. Es ist wahrscheinlich, dass in den nächsten Jahren eine „PCI Edition“ von Nextcloud auf den Markt kommt – vielleicht als Teil des Enterprise-Angebots.

Fazit: Nicht unmöglich, aber aufwändig

Nextcloud und PCI DSS sind kein Widerspruch – aber sie erfordern ein hohes Maß an Disziplin und technischem Verständnis. Wer die Plattform als Teil der Cardholder Data Environment nutzen möchte, muss tief in die Konfiguration eingreifen und zusätzliche Komponenten (HSM, SIEM, WAF, 2FA) integrieren. Der Aufwand ist vergleichbar mit dem Betrieb einer eigenen PCI-zertifizierten Filesharing-Lösung – und vielleicht ist eine dedizierte Lösung wie ein tokenisiertes Dokumentenmanagement-System dann die schlankere Alternative.

Auf der anderen Seite bietet Nextcloud eine Flexibilität, die kaum ein anderes System mitbringt. Man kann es sich exakt an die eigenen Prozesse anpassen, was bei standardisierter Compliance-Software oft nicht geht. Ich persönlich halte den Ansatz, Nextcloud außerhalb der CDE zu belassen und nur maskierte oder tokenisierte Daten darauf zu speichern, für den praktikabelsten. Wenn die Geschäftsanforderungen es aber zwingend erfordern, dass Kreditkartenbelege in Nextcloud landen, dann sollte man sich darauf einstellen, die Infrastruktur entsprechend aufzurüsten – und das Budget für externe Prüfungen einzuplanen.

Letztlich entscheidet die Organisation selbst, ob der Mehrwert von Nextcloud die Compliance-Kosten überwiegt. Ein genauer Blick in das PCI-DSS Rulebook und ein Gespräch mit einem zertifizierten QSA (Qualified Security Assessor) sind vor jedem Deployment unvermeidbar. Denn was nützt die schönste Cloud, wenn sie das Audit nicht besteht?

Ein kleiner Trost: Nextcloud ist nicht allein. Auch andere Open-Source-Plattformen wie Seafile, OwnCloud oder selbst die gute alte Samba-Freigabe stehen vor ähnlichen Herausforderungen. PCI DSS macht vor keiner Software Halt – es ist eine Frage der Architektur, nicht des Tools. Und die Nextcloud-Community ist groß genug, um Lösungen zu entwickeln. Vielleicht sehen wir ja bald ein offizielles Hardening-Guide für PCI DSS. Bis dahin: Prüfen, planen, implementieren – und dokumentieren, dokumentieren, dokumentieren.