Vieles, was ein ISO-27001-Audit fragt, passiert in Clusterward ohnehin: Zwei-Faktor-Anmeldung, Rollen, API-Tokens, Audit-Log, Backups mit Wiederherstellungstests, Isolation, Zertifikate. Die Compliance-Seite bringt das auf eine Seite – mit Live-Prüfungen samt Annex-A-Kontrolle, Berichten als CSV, einer unterschriebenen Zugriffsprüfung und einem Compliance-Paket für Ihren Prüfer.
Die Compliance-Seite ist ein eigener Punkt im Hauptmenü des Cockpits, gedacht für Ihren Informationssicherheitsbeauftragten und Ihren Prüfer. Sie zeigt Prüfungen, die Clusterward bei jedem Öffnen aus dem gespeicherten Stand Ihres Workspaces berechnet – nichts wird von Hand abgehakt, deshalb kann nichts veralten. Jede Prüfung nennt ihre Kontrolle aus ISO/IEC 27001:2022 Annex A und verlinkt die Seite, auf der Sie etwas ändern.
Jede Prüfung steht auf OK, Attention, Problem oder Info und nennt, was hinter der Zahl steckt – die Nutzer, Tokens oder Buckets. Die Kontrollnummern sind die der Norm, in jeder Zertifizierung nach der Fassung 2022 gleich: Sie finden jede in Ihrer eigenen Erklärung zur Anwendbarkeit wieder.
Dokumente nach der Fassung 2013 nutzen andere Nummern – ordnen Sie dort über den Namen der Kontrolle zu.
| Prüfung | Kontrolle | Achtung oder Problem, wenn |
|---|---|---|
| Zwei-Faktor-Anmeldung | A.8.5 Secure authentication | ein aktiver Nutzer sie nicht eingerichtet hat (offene Einladungen zählen gesondert) |
| Administratoren | A.8.2 Privileged access rights | sich ein Administrator 90 Tage nicht angemeldet hat |
| API-Tokens | A.5.17 Authentication information | ein Token nie abläuft oder 90 Tage nicht benutzt wurde |
| Zugriffsprüfung | A.5.18 Access rights | noch keine unterschrieben ist, die nächste in 14 Tagen fällig wird oder sie überfällig ist |
| Anmeldeschutz und Sitzungen | A.8.5 Secure authentication | Sitzungen länger als 4 Stunden ohne Aktivität offen bleiben oder mehr als 10 Fehlversuche erlaubt sind |
| Bucket-Backups | A.8.13 Information backup | Buckets ohne Backup-Ziel existieren, das Ziel nicht bereit ist oder ein Bucket 36 Stunden kein gutes Backup hatte |
| Wiederherstellungstests | A.8.13 Information backup | der letzte Test fehlschlug oder ein gesicherter Bucket diesen Monat noch nicht getestet wurde |
| Datenbank-Backups | A.8.13 Information backup | nur zur Information – Scaleway sichert jede Instanz nach ihrem eigenen Zeitplan |
| Audit-Log | A.8.15 Logging | es kürzer als 365 Tage aufbewahrt wird |
| Sicherheitsbenachrichtigungen | A.8.16 Monitoring activities | Anmelde-, Backup- und Zertifikatsereignisse keinen Kanal erreichen |
| IP-Allowlist | A.8.20 Networks security | nur zur Information – ob das Cockpit jede Adresse annimmt |
| Isolierte Umgebungen | A.8.22 Segregation of networks | eine Umgebung, in der Isolation angeboten wird, nicht isoliert ist |
| Zertifikate | A.8.24 Use of cryptography | ein Wildcard-Zertifikat in 14 Tagen abläuft oder nicht bereit ist |
| Cluster-Add-ons | A.8.8 Management of technical vulnerabilities | ein Upgrade bereitsteht oder ein Add-on nicht mehr zu seiner Kubernetes-Version passt |
| Konfigurationsprüfung | A.8.9 Configuration management | die letzte Prüfung Abweichungen fand oder älter als 7 Tage ist |
„Compliance“ im Hauptmenü: oben die Zählung OK, Attention, Problem, darunter die Prüfungen nach Thema.
Jede Prüfung verlinkt die Seite, auf der Sie es ändern – Nutzer, Tokens, Backups, Benachrichtigungen.
„Start review“ listet alle Nutzer und Tokens; nach dem Aufräumen „Sign review“ mit Notiz.
„Download compliance pack“ legt alle sechs Berichte eines Zeitraums mit README und Prüfsummen in ein ZIP.
Jede Prüfung entsteht beim Öffnen aus dem gespeicherten Stand. Was im Cockpit geändert wurde, zeigt die Seite sofort.
Neben A.8.5 oder A.8.13 steht der Name aus Annex A – auch im Compliance-Paket. So finden Sie jede in Ihrer SoA.
Zugriffe, Backup-Nachweis, Änderungen, Inventar mit Datenorten, Audit-Log und Sicherheitseinstellungen.
Ein ZIP mit allen Berichten, README und SHA256SUMS – mit sha256sum -c lässt sich später prüfen, dass nichts verändert wurde.
Wer wann unterschrieben hat, wie viele Nutzer und Tokens, dazu ein SHA-256 der Zugriffsliste als Beleg.
Die Seite braucht dieselbe Berechtigung wie das Audit-Log. Eine Prüfer-Rolle sieht und lädt alles, ändert nichts.
Sie wählen einen Zeitraum, standardmäßig die letzten 90 Tage, höchstens 400. Er gilt für die Berichte über Ereignisse; die anderen beschreiben den Stand von jetzt. Jeder Download steht im Audit-Log – auch die Nachweise selbst haben eine Spur.
| Bericht | Inhalt | Bezug |
|---|---|---|
| Zugriffsprüfung | jeder Nutzer und jedes API-Token: Rolle und was sie erlaubt, Anwendungsbereich, 2FA, Status, letzte Aktivität, Ablauf | Stand jetzt |
| Backup-Nachweis | jedes Bucket-Backup, jede Wiederherstellung und jeder Wiederherstellungstest | Zeitraum |
| Änderungen | jedes Deployment, jeder Restart und Rollback mit Version, Ergebnis und wer es ausgelöst hat | Zeitraum |
| Inventar und Datenorte | Cluster, Datenbank-Instanzen, Buckets, Backup-Ziel, DNS-Zonen, Secret Stores, Umgebungen und Services mit Anbieter und Region | Stand jetzt |
| Audit-Log | jede aufgezeichnete Aktion des Zeitraums; geheim wirkende Werte geschwärzt | Zeitraum |
| Sicherheitseinstellungen | die geltenden Werte: Anmeldeschutz, Sitzungen, Allowlist, Aufbewahrung, Backups, welcher Kanal welches Ereignis erhält | Stand jetzt |
ISO 27001 verlangt, Zugriffe in festen Abständen zu prüfen – und zu zeigen, dass es geschehen ist (A.5.18). „Start review“ listet alle, die den Workspace erreichen: Nutzer und API-Tokens mit Rolle, Anwendungsbereich, Zwei-Faktor, Status und letzter Aktivität. Sie räumen unter Users, Roles oder API tokens auf, kommen zurück und unterschreiben.
Die Unterschrift hält fest, wer wann unterschrieben hat, wie viele Nutzer und Tokens es waren, und einen SHA-256 der Zugriffsliste – der Beleg, ohne eine zweite Kopie der Liste zu lagern. Zwei Wochen vor der Fälligkeit wird die Prüfung gelb, danach rot, und „Access review overdue“ geht einmal an die abonnierten Kanäle.
Woher die Nachweise kommen, beschreiben die Seiten zu Sicherheit & Zugriff – Rollen, Pflicht-2FA, Audit-Log – und zu den S3-Backups, deren Wiederherstellungstests in den Backup-Nachweis einfließen.
Wie die Nachweise in eine NIS2- oder ISO-27001-Vorbereitung passen, zeigt Audit & NIS2. Welche Ereignisse Sie als Mail oder Webhook erreichen, steht unter Benachrichtigungen.
Welche Nachweise der Betrieb für NIS2 Art. 21 und ISO 27001 liefert.
Zu Audit & NIS2Nächtliche Kopien mit Object Lock, monatlich getestet, mit Nachweis.
Zu S3-BackupsRollen, Pflicht-2FA, API-Tokens, Audit-Log und IP-Allowlist.
Zu Sicherheit & ZugriffIhre Frage ist nicht dabei? Schreiben Sie uns, wir antworten in der Regel am selben Werktag.
Frage stellenBringen Sie Ihre Prüfliste mit: Wir öffnen die Prüfungen, unterschreiben eine Zugriffsprüfung und laden ein Compliance-Paket herunter.
