NIS2 verlangt von wesentlichen und wichtigen Einrichtungen „geeignete und verhältnismäßige technische, operative und organisatorische Maßnahmen“. Einen guten Teil der technischen kann Infrastruktur tragen. Die operativen und organisatorischen kann sie nicht tragen, und kein Plattformanbieter sollte Ihnen etwas anderes erzählen. Diese Seite zeigt die Aufteilung, Maßnahme für Maßnahme.
Was diese Seite ist und was nicht
Dies ist die plattformseitige Hälfte. Die organisatorische Hälfte ist ein Engagement zum Festpreis, beschrieben auf der Seite NIS2-Compliance: Einstufung Ihrer Einrichtung, Bestandsaufnahme Ihrer Kontrollen, Gap-Analyse und Maßnahmenplan. Die kostenlose NIS2-Compliance-Checkliste ist die Kurzfassung.
Zur Herkunft. Die folgenden Mechanismen sind die von Cozystack v1.6, der Open-Source-Engine unter Apache 2.0 bei der CNCF, die Ænix entwickelt hat und gemeinsam mit Maintainern anderer Unternehmen pflegt. Auf ihr bauen die Ænix Public Cloud Platform, die Private Cloud Platform und die AI Platform auf. Es sind dieselben Mechanismen, die auf den Seiten PCI DSS, DSGVO, DORA und CIS Benchmark gemessen wurden; dort stehen auch die Prüfkommandos und Testläufe. Die proprietären Ænix-Module (WHMCS-Integration, Abrechnungs- und Portalkomponenten) laufen oberhalb der Engine und ändern an diesen Kontrollen nichts.
Und wer die Pflicht trägt. Die Richtlinie (EU) 2022/2555 musste bis 17. Oktober 2024 in nationales Recht umgesetzt werden (Art. 41). Sie verpflichtet wesentliche und wichtige Einrichtungen in den Sektoren der Anhänge I und II. Anbieter von Cloud-Computing-Diensten, Rechenzentrumsdiensten und Anbieter verwalteter Dienste gehören dazu, in Anhang I. Für sie legt die Durchführungsverordnung (EU) 2024/2690 der Kommission die technischen und methodischen Anforderungen jeder Maßnahme nach Art. 21 Abs. 2 fest. Software fällt nicht in den Anwendungsbereich. Die Einrichtungen, die sie betreiben, schon.
Art. 21 Abs. 2, Punkt für Punkt
Art. 21 Abs. 2 nennt zehn Maßnahmen, die die Maßnahmen nach Abs. 1 „zumindest“ umfassen müssen. Hier stehen sie in der Reihenfolge der Richtlinie. Geliefert heißt: auf einer Standardinstallation aktiv. Optional heißt: wird mitgeliefert, Sie schalten es ein. Ihre Aufgabe heißt: keine Infrastruktur kann das für Sie erledigen.
| Art. 21 Abs. 2 | Maßnahme (Wortlaut gekürzt) | Was die Plattform liefert | Was bei Ihnen bleibt |
|---|---|---|---|
| a) | Konzepte für Risikoanalyse und Sicherheit für Informationssysteme | Nachweise, keine Konzepte. Deklarierter Zustand als Manifeste: ein genaues, versioniertes Inventar von Tenants, Services und ihrer Konfiguration. | Die Risikoanalyse, das Sicherheitskonzept und seine Billigung durch das Leitungsorgan. |
| b) | Bewältigung von Sicherheitsvorfällen | Geliefert: Metriken, Log-Aggregation, Alerting und Dashboards; Audit-Log der Kubernetes-API nach einer von Ihnen vorgegebenen Policy. | Erkennungsregeln für Ihre Bedrohungen, Bereitschaft, Triage, Einstufung und das Reaktions-Playbook. |
| c) | Aufrechterhaltung des Betriebs, Backup-Management, Wiederherstellung nach einem Notfall, Krisenmanagement | Geliefert: LINSTOR/DRBD-replizierter Speicher, wo die StorageClass es verlangt, Live-Migration, standardmäßig verschlüsselte Velero-Backups, standortübergreifend gestreckte Cluster. Nicht geliefert: automatisches standortübergreifendes VM-Failover. | Backup-Ziel außerhalb des geschützten Clusters, Wiederherstellungsübungen gegen RTO/RPO, Notfall- und Krisenplan. |
| d) | Sicherheit der Lieferkette | Geliefert: offener Quellcode unter Apache 2.0, öffentliche Sicherheitshinweise, Komponenten auf unveränderliche Image-Digests festgelegt. | Lieferanteninventar und -bewertung nach Abs. 3, einschließlich Ænix, wenn Sie bei Ænix kaufen, sowie Ihrer Hardware- und Rechenzentrumslieferanten. |
| e) | Sicherheit bei Erwerb, Entwicklung und Wartung, einschließlich Umgang mit und Offenlegung von Schwachstellen | Geliefert: unveränderliche Talos-Linux-Knoten ohne SSH und ohne Shell; Releases mit Changelogs, die jede aktualisierte Komponente nennen; offen veröffentlichte Sicherheitshinweise. | Ihr Update-Rhythmus, Schwachstellenmanagement für eigene Workloads und Images, Ihr Offenlegungsprozess. |
| f) | Konzepte und Verfahren zur Bewertung der Wirksamkeit | Nachweise: reproduzierbare Testläufe, etwa der veröffentlichte kube-bench-Lauf und die Konformitätsläufe, wiederholbar auf Ihrem eigenen Cluster. | Das Bewertungsprogramm, interne Audits und deren Zeitplan. |
| g) | Grundlegende Cyberhygiene und Schulungen | Teilweise geliefert: privilegierte Workloads werden bei der Zulassung abgewiesen, Tenants sind standardmäßig isoliert. | Hygienepraktiken und Schulungsprogramm, einschließlich der Schulung des Leitungsorgans nach Art. 20 Abs. 2. |
| h) | Kryptografie und gegebenenfalls Verschlüsselung | Geliefert: TLS für veröffentlichte Services über cert-manager, verschlüsselte Backups, Kubernetes-Secrets verschlüsselt in etcd, wenn der API-Server mit einem Encryption Provider läuft. Optional: LUKS-Volume-Verschlüsselung, transparente Cilium-Verschlüsselung (WireGuard oder IPsec) für Ost-West-Verkehr. | Das Kryptografiekonzept, die Schlüsselverwahrung und die Entscheidung, welche Datenklassen Volume-Verschlüsselung brauchen. |
| i) | Sicherheit des Personals, Konzepte für die Zugriffskontrolle, Management von Anlagen | Geliefert: Tenant-bezogenes RBAC; Cilium-Netzwerkrichtlinien, die Tenants bei der Anlage isolieren. Optional: Keycloak-SSO, angebunden an Ihren Verzeichnisdienst. | Eintritts-, Wechsel- und Austrittsprozess, Berechtigungsreviews, das Anlageninventar über die Plattform hinaus. |
| j) | Multi-Faktor- oder kontinuierliche Authentifizierung; gesicherte Kommunikation | Optional: MFA über Keycloak, sobald die OIDC-Integration bei der Installation aktiviert ist; eine Standardinstallation authentifiziert mit einem Cluster-Credential. | MFA für jeden Administrator durchsetzen, gesicherte Sprach-, Video- und Notfallkommunikation. |
Zwei Punkte der Tabelle brauchen mehr als eine Zelle.
Buchstabe c und Failover. Die Plattform hält Daten durch Replikation verfügbar und verschiebt Workloads bei Wartung ohne Ausfallzeit. Sie übernimmt nach einem ungeplanten Ausfall kein automatisches Failover virtueller Maschinen zwischen Standorten. Auch innerhalb eines Standorts starten virtuelle Maschinen nach einem ungeplanten Knotenausfall nicht von selbst neu, denn die Plattform liefert kein Fencing mit: Sobald ein Operator den ausgefallenen Knoten als außer Betrieb markiert (oder ein externer Fencing-Mechanismus das übernimmt), startet KubeVirt sie auf gesunden Knoten neu, mit ihren Daten, wenn ihre Disks auf repliziertem Speicher liegen. Worker-Knoten von Tenant-Kubernetes-Clustern werden automatisch ersetzt. Den Fencing-Schritt und das standortübergreifende Failover zu einem Verfahren auszubauen ist Konfigurations- und Übungsarbeit. Siehe Disaster Recovery. Die zweite Lücke ist der Ablageort der Backups. Plattformverwaltete Backups landen standardmäßig in einem gemeinsamen Bucket innerhalb des Clusters, den sie schützen. Richten Sie die BackupClass auf Speicher außerhalb des Clusters mit eigenen Zugangsdaten und halten Sie das im Backup-Konzept fest.
Buchstabe j und die Standardinstallation. Single Sign-on und MFA sind verfügbar, aber nicht standardmäßig aktiv. Aktivieren Sie die Keycloak-OIDC-Integration, bevor die Plattform produktive Workloads trägt; MFA und Passwortrichtlinie sind dann Keycloak-Einstellungen. Die PCI-DSS-Seite enthält die Kommandos zur Prüfung.
Art. 23: was die Plattform zu den Meldungen beiträgt
Art. 23 Abs. 4 setzt die Fristen ab dem Moment, in dem Sie von einem erheblichen Sicherheitsvorfall Kenntnis erlangen:
- Frühwarnung unverzüglich, in jedem Fall innerhalb von 24 Stunden, mit der Angabe, ob ein rechtswidriges oder böswilliges Handeln vermutet wird oder grenzüberschreitende Auswirkungen möglich sind.
- Meldung des Sicherheitsvorfalls innerhalb von 72 Stunden, mit einer ersten Bewertung von Schweregrad und Auswirkungen und, soweit verfügbar, den Kompromittierungsindikatoren.
- Abschlussbericht spätestens einen Monat nach der Meldung, mit ausführlicher Beschreibung, der wahrscheinlichen Ursache, den getroffenen und laufenden Abhilfemaßnahmen und gegebenenfalls den grenzüberschreitenden Auswirkungen.
Ob ein Vorfall erheblich ist, wie er eingestuft wird und die Meldung selbst liegen bei der Einrichtung. Nach Art. 23 Abs. 3 ist ein Vorfall erheblich, wenn er schwerwiegende Betriebsstörungen oder finanzielle Verluste verursacht hat oder verursachen kann oder anderen erheblichen Schaden zufügt. Für Cloud-, Rechenzentrums- und Managed-Service-Anbieter ergänzt die Durchführungsverordnung (EU) 2024/2690 konkrete Schwellenwerte.
Was die Plattform beiträgt, sind die Aufzeichnungen. Jede Frist verlangt Fakten, und melden können Sie nur, was Sie vorher aufgezeichnet haben:
Alerting und Metriken liefern den Zeitpunkt der Erkennung und den Wirkungsbereich. Mit der Kenntnisnahme beginnt die 24-Stunden-Frist, daher zählt, wie schnell ein Alert einen Menschen erreicht.
Zentralisierte Logs liefern die Abfolge der Ereignisse über Tenants und Services hinweg für die Bewertung nach 72 Stunden.
Das Audit-Log der Kubernetes-API zeichnet nach einer von Ihnen vorgegebenen Policy auf, wer was an der Control Plane geändert hat. Zwei Einstellungen entscheiden, ob es für einen Abschlussbericht taugt. Aufbewahrung: Der Standard auf dem Referenzcluster sind dreißig Tage. Das reicht für eine Meldung nach 72 Stunden. Für eine Untersuchung, die erst Wochen später beginnt, kann es zu kurz sein. Erhöhen Sie den Wert oder leiten Sie das Log in einen Speicher unter Ihrer Kontrolle, unveränderlich, wenn Ihr Konzept das verlangt. Die Policy: Setzen Sie nicht alles auf vollständige Erfassung von Request und Response. Dann landen Secrets und personenbezogene Daten im Log. Die Seiten DSGVO und CIS Benchmark zeigen eine praktikable Aufteilung.
Isolation pro Tenant begrenzt den Umfang, über den Sie berichten müssen. Wenn Tenants durch Netzwerkrichtlinien und RBAC getrennt sind, lässt sich ein Vorfall in einem Tenant leichter als eingegrenzt belegen. Das hilft bei der Pflicht aus Art. 23 Abs. 1, betroffene Empfänger Ihrer Dienste zu unterrichten, und bei der Bewertung grenzüberschreitender Auswirkungen.
Lieferkettensicherheit, einschließlich Ænix als Lieferant
Art. 21 Abs. 2 Buchst. d und Abs. 3 verlangen, dass Sie „die spezifischen Schwachstellen der einzelnen unmittelbaren Anbieter und Diensteanbieter“ sowie die Qualität ihrer Produkte und ihrer sicheren Entwicklungsverfahren berücksichtigen. Diese Fakten gehören in diese Bewertung.
Die Engine ist Open Source. Cozystack steht unter Apache 2.0 und wird von der CNCF getragen. Sie können den Code lesen, prüfen und bauen, ohne jemanden zu fragen. Die Kontinuität hängt nicht an einem Unternehmen. Endet ein Ænix-Abonnement, läuft die Open-Source-Plattform auf Ihrer Hardware weiter. Nur die proprietären Module und der Ænix-Support entfallen.
Sie läuft auf Ihrer Hardware. Es gibt keine Control Plane des Anbieters in einem fremden Konto und keinen dauerhaften Zugriff des Anbieters. Wenn Ænix Sie unterstützt, erfolgt Fernzugriff auf Ihre Cluster nur mit Ihrer Freigabe.
Änderungen sind nachvollziehbar. Komponenten-Images sind auf unveränderliche Digests festgelegt, ein Release ist also reproduzierbar. Changelogs nennen jede aktualisierte Komponente. Sicherheitshinweise werden offen veröffentlicht, einschließlich der Bewertungen von CVEs, die die Plattform nicht betreffen. Diese Aufzeichnungen können Sie direkt im Schwachstellenmanagement nach Buchstabe e verwenden.
Ænix als unmittelbarer Lieferant. Wenn Sie ein Abonnement, Support oder Dienstleistungen kaufen, ist Ænix ein Lieferant, den Sie bewerten. Die AENIX s.r.o. ist für ihr Informationssicherheits-Managementsystem nach ISO/IEC 27001:2022 zertifiziert (Details zum Zertifikat). Das zertifiziert, wie das Unternehmen arbeitet, nicht ein Produkt. Einen SOC-2-Bericht hat Ænix nicht.
Vorgelagerte Komponenten. Die Plattform setzt CNCF- und andere Open-Source-Projekte zusammen: Kubernetes, KubeVirt, Cilium, LINSTOR/DRBD, Talos Linux, Keycloak und weitere. Deren Maintainer sind nicht Ihre Vertragspartner. Ihre Sicherheitshistorie gehört trotzdem in Ihre Risikoanalyse, und die koordinierten EU-Risikobewertungen kritischer Lieferketten nach Art. 22 können einige davon erfassen.
Art. 20: Governance bleibt beim Leitungsorgan
Art. 20 Abs. 1 verlangt, dass die Leitungsorgane wesentlicher und wichtiger Einrichtungen die Risikomanagementmaßnahmen im Bereich der Cybersicherheit billigen, ihre Umsetzung überwachen und für Verstöße verantwortlich gemacht werden können. Nach Art. 20 Abs. 2 müssen ihre Mitglieder an Schulungen teilnehmen.
Keine Plattformfunktion übernimmt diese Rolle. Eine Plattform kann die Maßnahmen günstiger umsetzbar und leichter nachweisbar machen. Billigen, überwachen und dafür einstehen muss Ihre Geschäftsleitung. Wenn Sie Unterstützung bei den Unterlagen wünschen, die ein Leitungsorgan billigt, ist das Teil des NIS2-Readiness-Engagements.
Quellen
- Richtlinie (EU) 2022/2555 (NIS2), EUR-Lex: Art. 20, 21, 22, 23, 41 und Anhang I.
- Durchführungsverordnung (EU) 2024/2690 der Kommission, EUR-Lex: technische und methodische Anforderungen und Kriterien für erhebliche Sicherheitsvorfälle, unter anderem für Cloud-, Rechenzentrums- und Managed-Service-Anbieter.
- Plattformmechanismen und ihre Prüfung: PCI DSS, DSGVO, DORA, CIS Benchmark, ISO/IEC 27001.
Hinweise
Diese Seite beschreibt Cozystack v1.6, die Engine, auf der die Ænix-Plattformen aufbauen, und dient der Information. Sie ist keine Rechtsberatung, kein Assessment und keine Aussage darüber, dass eine Konfiguration die Anforderungen einer zuständigen Behörde erfüllt. NIS2 ist eine Richtlinie: Verbindlich sind für Sie die Vorschriften des Umsetzungsgesetzes Ihres Mitgliedstaats, die über die Richtlinie hinausgehen können. Ob NIS2 für Sie gilt und ob als wesentliche oder wichtige Einrichtung, klären Sie mit Ihrer Rechtsberatung.