Für das Kapitel von DORA, das die meisten Plattformgespräche entscheidet — die Abhängigkeit von einem einzelnen IKT-Anbieter — sind die Ænix-Plattformen ungefähr so gut, wie Infrastruktur es sein kann. Die Engine ist quelloffene Software unter Apache 2.0, sie läuft auf Ihrer eigenen Hardware, und ein Wechsel bedeutet, standardisierte Kubernetes-Objekte und virtuelle Maschinen zu bewegen, statt ein proprietäres Format aufzulösen. Eine Exit-Strategie, die man proben kann, schlägt eine Klausel, die Kooperation verspricht.
Was diese Seite ist — und was nicht
Dies ist die plattformseitige Hälfte. Sie beschreibt, was die Infrastruktur gegenüber DORA leistet und wie das beobachtet wurde. Die organisatorische Hälfte — Gap-Analyse, Kontroll-Landkarte dessen, was Ihr Unternehmen heute nachweisen kann, Konzentrationsrisiko bis zur zweiten Lieferantenstufe, Exit-Machbarkeit mit Zeitschätzungen, Remediationsplan — ist ein Engagement zum Festpreis und steht auf der Seite DORA-Compliance. Beginnen Sie dort, wenn Sie das Programm brauchen; bleiben Sie hier, wenn Sie den Nachweis darunter brauchen.
Zur Herkunft. Die Beobachtungen unten stammen von Cozystack v1.6 auf einem Referenzcluster. Cozystack ist die quelloffene, Apache-2.0-lizenzierte, bei der CNCF gehostete Engine, die Ænix entwickelt hat und gemeinsam mit Maintainern anderer Unternehmen pflegt; die Ænix Public Cloud Platform, die Private Cloud Platform und die AI Platform basieren darauf. Die proprietären Ænix-Module (WHMCS-Integration, Billing- und Portal-Komponenten) setzen darauf auf und verändern die hier beschriebenen Infrastrukturkontrollen nicht. Das zählt hier doppelt: Es ist der Grund, warum der Nachweis trägt, und es ist die Substanz des Kapitel-V-Arguments weiter unten.
Und was die Plattform nicht kann, ist die Pflicht halten. DORA — Verordnung (EU) 2022/2554 — gilt seit dem 17. Januar 2025 und bindet die in Art. 2 aufgezählten Kategorien von Finanzunternehmen: Banken, Versicherer, Wertpapierfirmen, Zahlungs- und E-Geld-Institute, Anbieter von Krypto-Dienstleistungen und weitere. IKT-Drittdienstleister fallen nicht unmittelbar in den Anwendungsbereich; einige wenige werden von den Europäischen Aufsichtsbehörden nach Art. 31 als kritisch eingestuft und einem EU-Überwachungsrahmen mit einem federführenden Überwacher unterstellt — ein anderes Regime als die Aufsicht durch die zuständige Behörde, der Finanzunternehmen unterliegen.
IKT-Drittparteienrisiko: der Teil, der von der Plattform abhängt
DORA widmet dem IKT-Drittparteienrisiko ein ganzes Kapitel: Informationsregister, vertragliche Anforderungen, Konzentrationsrisiko, Exit-Strategien und das Auditrecht. Aufsichtsbehörden interessiert das, weil ein Finanzunternehmen, das einen Anbieter nicht verlassen kann, seine eigene Resilienz nicht wirklich kontrolliert.
Drei Eigenschaften zählen hier. Keine ist ein Feature, das man aktiviert; jede folgt daraus, wie die Plattform gebaut und lizenziert ist.
Der Quellcode ist offen, unter Apache 2.0. Die vertragliche Kontinuität hängt nicht am Fortbestand eines Anbieters, und der Code kann von Ihnen oder einem Dritten geprüft werden, ohne dass jemand um Erlaubnis gefragt werden müsste.
Sie läuft auf Ihrer eigenen Hardware. Keine Control Plane in fremdem Account, kein Anbieter mit dauerhaftem Zugriff als Funktionsvoraussetzung, keine Abhängigkeit davon, dass ein externer Dienst erreichbar ist. Was Sie hosten, kontrollieren Sie.
Der Ausstieg ist praktisch möglich, nicht nur auf dem Papier. Workloads sind Kubernetes-Objekte und virtuelle Maschinen in Standardformaten; es gibt keine proprietäre Kapselung aufzulösen. Ein Exit-Plan, den man proben kann, ist einer Aufsichtsbehörde mehr wert als eine Klausel, die Kooperation verspricht.
Nichts davon befreit Sie davon, das Informationsregister nach Art. 28 Abs. 3 zu führen, eine Exit-Strategie nach Art. 28 Abs. 8 vorzuhalten oder Verträge mit den Kernbestimmungen des Art. 30 DORA zu schließen — ein anderer Art. 30 als der der DSGVO. Es macht diese Dokumente leichter wahrheitsgemäß zu schreiben.
Ein ehrlicher Vorbehalt. Wenn Sie Support, Hosting oder Betrieb bei Ænix einkaufen, wird Ænix zum IKT-Drittdienstleister nach Art. 3 Nr. 19 und gehört mit der gestützten Funktion in Ihr Register. Die quelloffene Engine begründet keine vertragliche Vereinbarung; eine kommerzielle Beziehung darum herum schon.
Resilienz: was die Plattform liefert
DORA erwartet, dass IKT-Systeme Störungen standhalten und sich davon erholen — und dass das getestet und nicht angenommen wird.
Replizierter Speicher, wo die StorageClass es verlangt. LINSTOR platziert Volumes mit DRBD-Replikation über Knoten hinweg; ein repliziertes Volume überlebt also den Ausfall eines Knotens, der eine seiner Kopien hält. Replikation ist eine Eigenschaft der StorageClass und nicht der Plattform — lokale, nicht replizierte Klassen existieren und sind für manche Workloads die richtige Wahl —, prüfen Sie also, welche Klasse jede kritische oder wichtige Funktion tatsächlich nutzt. Ein separates Storage-Array ist in keinem Fall nötig.
Live-Migration. Virtuelle Maschinen wechseln ohne Abschaltung den Knoten, womit geplante Wartung von einem Ausfall zu einer Operation wird.
Deklarierter Zustand, kontinuierlich abgeglichen. Maschinen und Dienste werden als Manifeste beschrieben, und die Plattform arbeitet daran, die Realität mit der Beschreibung in Deckung zu halten. Beenden Sie einen Workload direkt, kommt er zurück, weil die Beschreibung sich nicht geändert hat.
Standortübergreifend gestreckte Cluster. Multi-Rechenzentrums-Topologien sind eine normale Betriebsform und keine Exotik — relevant, wenn Ihre Resilienzanforderungen geografische Trennung benennen.
Seien Sie präzise darin, was nicht geliefert wird. Es gibt keinen automatischen Neustart virtueller Maschinen nach ungeplantem Knotenausfall, wie ihn ein dediziertes HA-Produkt bietet, denn die Plattform liefert kein Fencing mit. Virtuelle Maschinen sind zwar auf Dauerbetrieb gesetzt, doch solange die alte Instanz auf dem toten Knoten hängt, startet KubeVirt keine zweite Kopie. Ein einziger Fencing-Schritt löst die Blockade: Ein Operator markiert den ausgefallenen Knoten als außer Betrieb oder entfernt ihn, oder ein externer Fencing-Mechanismus erledigt das. Danach startet KubeVirt die virtuellen Maschinen auf gesunden Knoten neu, und Maschinen mit Disks auf repliziertem LINSTOR/DRBD-Speicher kommen mit ihren Daten zurück. Geplante Wartung ist ein anderer Fall: Beim Drain eines Knotens wandern seine virtuellen Maschinen per Live-Migration ohne Ausfallzeit weiter. Worker-Knoten von Tenant-Kubernetes-Clustern werden automatisch ersetzt: Ein Health Check ist standardmäßig aktiv, und fehlerhafte Worker werden gelöscht und neu erzeugt, solange mindestens die Hälfte einer Node-Gruppe gesund bleibt. Den Fencing-Schritt zu einem automatisierten Verfahren auszubauen ist Konfigurations- und Probearbeit, kein Schalter. Wie das üblicherweise ausgebaut wird, steht unter Disaster Recovery.
Backup, Wiederherstellung und der Nachweis, dass beides funktioniert
Velero wird für geplante Backups, Volume-Snapshots, VM-Backups und Clusterzustand mitgeliefert, und Backup-Daten sind im Objektspeicher über den kopia-Uploader standardmäßig verschlüsselt.
Wo diese Backups landen, braucht eine Entscheidung vor der Prüfung, nicht danach. Plattformverwaltete Backups landen standardmäßig in einem geteilten Bucket cozy-backups in tenant-root, zwischen den Tenants nach Objektpfad getrennt. Art. 12 Abs. 3 verlangt, dass ein Finanzunternehmen bei der Wiederherstellung von Backup-Daten mit eigenen Systemen IKT-Systeme nutzt, die physisch und logisch vom Quellsystem getrennt sind — und ein Bucket innerhalb des geschützten Clusters lässt sich schwerlich als davon getrennt darstellen. Art. 12 Abs. 2 ergänzt, dass die Aktivierung eines Backup-Systems die Sicherheit, Verfügbarkeit, Authentizität, Integrität oder Vertraulichkeit der Daten nicht selbst gefährden darf und dass die Verfahren regelmäßig getestet werden. Richten Sie die BackupClass auf Speicher außerhalb des Clusters, mit eigenen Credentials und eigenem Schlüssel, und halten Sie das in der Backup-Richtlinie fest, die Art. 12 Abs. 1 von Ihnen verlangt.
Der Schwerpunkt der Verordnung liegt nicht darauf, Backups zu haben, sondern darauf, wiederherstellen zu können. Proben Sie die Wiederherstellung gegen ein definiertes Wiederanlaufziel und einen definierten Datenverlustpunkt, halten Sie fest, was Sie tatsächlich erreicht haben, und bewahren Sie diese Aufzeichnung auf. Eine gemessene Wiederherstellungszeit ist ein Nachweis; eine Schätzung nicht.
Erkennung, Protokollierung und Vorfallsnachweise
DORA verlangt, dass Vorfälle erkannt, klassifiziert und — bei schwerwiegenden — der zuständigen Behörde binnen kurzer Frist gemeldet werden. Das funktioniert nur, wenn die zugrunde liegende Aufzeichnung existiert.
Die Plattform bringt Metrikerfassung, Log-Aggregation, Alerting und Dashboards mit, und der Kubernetes-API-Server schreibt ein Audit-Log nach einer Policy, die Sie liefern. Zwei Dinge bewusst setzen:
Aufbewahrung. Der Default auf dem untersuchten Cluster beträgt dreißig Tage — kürzer, als eine Finanzaufsicht es für Aufzeichnungen zu kritischen oder wichtigen Funktionen erwartet.
Die Audit-Policy, Ressource für Ressource. Heben Sie nicht alles auf vollständige Request-/Response-Erfassung: Das schreibt Secrets und personenbezogene Daten ins Log und erkauft ein DSGVO-Problem, um ein DORA-Problem zu lösen. Warum, steht auf der DSGVO-Seite; die praktikable Aufteilung auf der CIS-Benchmark-Seite.
Security-Advisories zur Engine werden offen veröffentlicht, einschließlich Bewertungen von Schwachstellen, die sie am Ende nicht betreffen. Dieser öffentliche Nachweis ist in den Bereichen Threat Intelligence und Schwachstellenmanagement eines IKT-Risikorahmens direkt verwendbar.
Resilienz testen, ohne die Produktion anzufassen
DORA erwartet ein Programm für Tests der digitalen operationalen Resilienz nach Kapitel IV und bedrohungsgeleitete Penetrationstests nach Art. 26 für diejenigen Unternehmen, die ihre zuständige Behörde dafür benennt — eine Einstufung nach Risikoprofil und systemischer Bedeutung, keine Kategorie, die Sie aus der eigenen Bilanz ablesen können.
Zwei Eigenschaften der Plattform helfen dem allgemeinen Programm. Ein Tenant gibt Ihnen einen isolierten Ort, um destruktive Tests gegen eine realistische Kopie zu fahren. Und weil Umgebungen als Manifeste beschrieben sind, lässt sich die getestete Umgebung exakt wiederherstellen — was ein Testergebnis beim zweiten Mal überhaupt erst aussagekräftig macht.
TLPT ist eine andere Übung, und die Unterscheidung zählt: Tests nach Art. 26 laufen gegen produktive Systeme, die kritische oder wichtige Funktionen stützen; eine Tenant-Kopie ersetzt sie nicht. Wo die Plattform für Sie betrieben wird oder eine kritische oder wichtige Funktion stützt, geraten die beteiligten IKT-Drittdienstleister in den Umfang dieses Tests und müssen vorab eingebunden werden.
Die CIS-Benchmark-Seite zeigt einen solchen Test gegen einen laufenden Cluster, samt der Argumentation, die aus einem Rohbericht etwas macht, das ein Prüfer verwenden kann.
Wo das bereits eingesetzt wird
Zwei anonymisierte Fallstudien zeigen die Plattform im regulierten Finanzsektor: eine Private Cloud mit Developer Self-Service in einer Bank und ein einheitliches Cloud-Portal für eine Finanzgruppe. Keine davon ist eine DORA-Zertifizierung von irgendetwas; beide zeigen die hier beschriebene Architektur im Produktivbetrieb.
Was bei Ihnen bleibt
Die Governance liegt beim Leitungsorgan und lässt sich nicht an einen Lieferanten delegieren: der IKT-Risikorahmen, das Informationsregister, die Klassifizierung und Meldung von Vorfällen innerhalb der Fristen der Verordnung, das Testprogramm zur digitalen operationalen Resilienz, die vertraglichen Vereinbarungen mit Anbietern und die Exit-Strategie selbst.
Eine Plattform kann jedes davon billiger erfüllbar machen. Halten kann sie es nicht. Wenn Sie Unterstützung bei der Erstellung möchten: dafür gibt es das DORA-Readiness-Engagement, und die kostenlose DORA-Compliance-Checkliste ist die Kurzfassung dessen, was dabei betrachtet wird.
Hinweise
Diese Seite beschreibt Cozystack v1.6 — die Engine, aus der die Ænix-Plattformen gebaut sind —, beobachtet auf einem Referenzcluster im August 2026, und ist informatorisch. Sie ist keine Rechtsberatung, kein Assessment und keine Aussage darüber, dass irgendeine Konfiguration eine zuständige Behörde zufriedenstellt. Die Verordnung (EU) 2022/2554 gilt für definierte Kategorien von Finanzunternehmen und deren kritische IKT-Anbieter; ob und in welcher Eigenschaft sie für Sie gilt, ist eine Frage an Ihre eigene Rechtsberatung.