DORA (Digital Operational Resilience Act)
Was Admission Control und Image-Scan Ihres Clusters in einem Zeitraum erfasst haben, ordnet Attestkeep 22 Anforderungen zu (Quelle: Verordnung (EU) 2022/2554). 15 davon werden aus diesen Einträgen bewertet; 7 sind als außerhalb des Umfangs markiert, jede mit Begründung.
15 Anforderungen aus Clustersicht.
Fundstellen und Titel so, wie der Bericht sie druckt, also auf Englisch. Öffnen Sie eine Anforderung, um zu lesen, was sie verlangt – nah am Wortlaut des Regelwerks wiedergegeben.
Digital Operational Resilience Act
Verordnung (EU) 2022/2554
Kapitel II Artikel 8 bis 11 (IKT-Risikomanagement: Identifizierung, Schutz und Prävention, Erkennung, Reaktion) und Kapitel V Artikel 28 (IKT-Drittparteienrisiko)
| Fundstelle | Anforderung | Berichtsabschnitte |
|---|---|---|
| Article 8(1) | Identify, classify and document ICT assetsFinanzunternehmen identifizieren, klassifizieren und dokumentieren angemessen alle IKT-gestützten Geschäftsfunktionen, Rollen und Verantwortlichkeiten sowie die Informations- und IKT-Assets, die diese Funktionen unterstützen, und überprüfen die Angemessenheit dieser Klassifizierung jährlich. | CoverageControl statement |
| Article 8(6) | Maintain and update inventoriesFinanzunternehmen führen einschlägige Bestandsverzeichnisse und aktualisieren sie regelmäßig sowie bei jeder größeren Änderung. | Coverage |
| Article 8(5) | Identify processes dependent on third-party providersFinanzunternehmen identifizieren und dokumentieren alle Prozesse, die von IKT-Drittdienstleistern abhängen. | Control statementSupply chain |
| Article 9(2) | Availability, authenticity, integrity and confidentiality of dataFinanzunternehmen konzipieren, beschaffen und implementieren IKT-Sicherheitsleitlinien, -verfahren, -protokolle und -werkzeuge, die Resilienz, Kontinuität und Verfügbarkeit der IKT-Systeme sichern und hohe Standards für Verfügbarkeit, Authentizität, Integrität und Vertraulichkeit von Daten gewährleisten, ob gespeichert, in Verwendung oder in Übertragung. | Supply chainControl statement |
| Article 9(3)(b) | Minimise the risk of technical flawsFinanzunternehmen minimieren das Risiko der Beschädigung oder des Verlusts von Daten, unbefugten Zugriffs und technischer Mängel, die die Geschäftstätigkeit behindern können. | CoverageAdmission decisionsOutcomes |
| Article 9(4)(c) | Limit logical access to what legitimate functions requireFinanzunternehmen setzen Leitlinien um, die den physischen oder logischen Zugang zu Informations- und IKT-Assets auf das beschränken, was für legitime und genehmigte Funktionen und Tätigkeiten erforderlich ist. | Control statementAdmission decisions |
| Article 9(4)(d) | Strong authentication mechanismsFinanzunternehmen setzen Leitlinien und Protokolle für starke Authentifizierungsmechanismen um, gestützt auf einschlägige Standards und eigene Kontrollsysteme. | Evidence chain |
| Article 9(4)(e) | ICT change managementFinanzunternehmen verfügen über dokumentierte Leitlinien, Verfahren und Kontrollen für das IKT-Änderungsmanagement, damit alle Änderungen kontrolliert erfasst, getestet, bewertet, genehmigt, umgesetzt und überprüft werden. | Control statementAdmission decisionsEvidence chain |
| Article 9(4)(f) | Patches and updatesFinanzunternehmen verfügen über angemessene und umfassende dokumentierte Leitlinien für Patches und Updates. | Control statementCoverageAdmission decisionsOutcomesIssues |
| Article 10(1) | Promptly detect anomalous activities and single points of failureFinanzunternehmen verfügen über Mechanismen, um anomale Aktivitäten, einschließlich Leistungsproblemen im IKT-Netz und IKT-bezogener Vorfälle, umgehend zu erkennen und mögliche wesentliche Single Points of Failure zu identifizieren. Alle Erkennungsmechanismen werden regelmäßig getestet. | CoverageAvailability |
| Article 10(2) | Alert thresholds and criteria to trigger responseDie Erkennungsmechanismen ermöglichen mehrere Kontrollebenen und legen Alarmschwellen und Kriterien fest, die Prozesse zur Reaktion auf IKT-bezogene Vorfälle auslösen, einschließlich automatischer Alarme für das zuständige Personal. | Admission decisionsCoverageOutcomesBreak-glass events |
| Article 10(3) | Resources to monitor activity and anomaliesFinanzunternehmen setzen ausreichende Ressourcen und Fähigkeiten ein, um Nutzeraktivitäten, das Auftreten von IKT-Anomalien und IKT-bezogene Vorfälle, insbesondere Cyberangriffe, zu überwachen. | Evidence chainAdmission decisionsBreak-glass events |
| Article 11(1) | ICT business continuity policyFinanzunternehmen legen als festen Bestandteil ihrer Leitlinie zur betrieblichen Kontinuität eine umfassende IKT-Geschäftsfortführungsleitlinie fest, um die Kontinuität kritischer oder wichtiger Funktionen sicherzustellen. | Availability |
| Article 28(4) | Due diligence before entering a third-party arrangementVor Abschluss einer vertraglichen Vereinbarung über die Nutzung von IKT-Dienstleistungen identifizieren und bewerten Finanzunternehmen alle relevanten Risiken und führen die gebotene Sorgfaltsprüfung künftiger IKT-Drittdienstleister durch. | Supply chainControl statement |
| Article 28(5) | Providers shall meet appropriate information security standardsFinanzunternehmen dürfen vertragliche Vereinbarungen nur mit IKT-Drittdienstleistern schließen, die angemessene Standards für Informationssicherheit einhalten; unterstützen die Dienstleistungen kritische oder wichtige Funktionen, gelten die aktuellsten und höchsten Qualitätsstandards. | Supply chainControl statementCoverageAdmission decisionsOutcomes |
7 Anforderungen außerhalb des Umfangs, und warum
| Fundstelle | Anforderung und Grund |
|---|---|
| Article 5 | Governance and organisation Genehmigung, Aufsicht und Verantwortung des Leitungsorgans sind Aufzeichnungen des Unternehmens, nicht eines Clusters. Die in der Kontrollerklärung wiedergegebenen Durchsetzungseinstellungen sind ein Ergebnis dieser Governance, kein Nachweis dafür. |
| Article 6 | ICT risk management framework Der IKT-Risikomanagementrahmen ist ein Dokument, das das Unternehmen pflegt und überprüft. Diese Kontrolle arbeitet innerhalb dieses Rahmens und liefert Nachweise für Teile davon; sie ist nicht der Rahmen. |
| Article 12 | Backup, restoration and recovery Sicherung und Wiederherstellung der Systeme und Daten des Unternehmens liegen außerhalb dessen, was ein Admission Controller festhält. Die eigene Datenbank des Operators sichert der Kunde. |
| Article 13 | Learning and evolving Die Nachbetrachtung von Vorfällen ist eine Tätigkeit von Menschen. Ablehnungen, Ausnahmen und Ausfallfenster in diesem Dokument sind Material für eine solche Nachbetrachtung, nicht die Nachbetrachtung selbst. |
| Articles 17 – 23 | ICT-related incident management, classification and reporting Die Klassifizierung nach den DORA-Schwellen und die Meldung an eine zuständige Behörde sind Entscheidungen und Meldungen des Unternehmens. Diese Kontrolle löst Ereignisse aus und hält sie fest; sie klassifiziert und meldet sie nicht. |
| Articles 24 – 27 | Digital operational resilience testing Das Testprogramm des Unternehmens, einschließlich bedrohungsorientierter Penetrationstests, wird von Testern gegen seine Systemlandschaft durchgeführt. Nichts, was ein Cluster festhält, belegt, dass es stattfand. |
| Article 28(3) | Register of information on contractual arrangements Das Informationsregister ist eine vertragliche Aufzeichnung des Unternehmens. Das Image-Inventar in diesem Dokument hält fest, was läuft, nicht was vertraglich vereinbart wurde. |
Nachweise aus Einträgen, die der Cluster ohnehin führt.
Nichts wird von Hand ausgefüllt. Jede Antwort zu einer Anforderung trägt einen Status (erfüllt, teilweise, Lücke oder außerhalb des Umfangs), eine Notiz mit den Zahlen des Zeitraums und die Berichtsabschnitte, aus denen diese Zahlen stammen.
Worauf sich das Mapping stützt
Jede bewertete Anforderung wird durch eine oder mehrere dieser Aussagen über die Einträge des Zeitraums beantwortet. Dieselbe Aussage beantwortet dieselbe Frage in jedem Framework; zwei Berichte über denselben Zeitraum können sich daher nicht widersprechen.
- Jedes Image im Bestand hat einen Scan-Eintrag4 Anforderungen
- Images mit schweren Befunden werden abgelehnt4 Anforderungen
- Nur Images mit nachgewiesener Herkunft dürfen laufen3 Anforderungen
- Images kommen nur aus benannten Registries3 Anforderungen
- Jede Entscheidung und jede administrative Aktion wird festgehalten2 Anforderungen
- Die Kontrolle selbst lief den ganzen Zeitraum2 Anforderungen
- Workloads referenzieren Images per Digest, nicht per verschiebbarem Tag2 Anforderungen
- Eine Ablehnung oder ein kritischer Befund erreicht eine Person2 Anforderungen
- Für die laufenden Images liegt ein SBOM vor2 Anforderungen
- Administrativer Zugang läuft über ein Verzeichnis1 Anforderung
- Admission lehnt nicht konforme Workloads ab1 Anforderung
- Für jeden Schweregrad ist ein Behebungsfenster festgelegt1 Anforderung
- Workload-Privilegien werden bei der Admission begrenzt1 Anforderung
Was der Bericht enthält.
Jedes Paket enthält dieselben Abschnitte, unabhängig vom Framework. Markiert sind die, auf die sich die Antworten zu DORA stützen, jeweils mit der Zahl der Anforderungen, die auf sie verweisen.
- Organisation
- Framework mapping
- Cluster
- Control statement8
- Coverage7
- Vulnerability findings
- Outcomes4
- Admission decisions7
- Supply chain4
- Triage decisions
- Break-glass events2
- Availability2
- Evidence chain3
- Deployment context
- Issues1
- Ledger
- Population
- Runtime events
- Producer statements (VEX)
Geltungsbereich, wörtlich aus dem Bericht (Englisch).
This document reports what one Kubernetes cluster's admission control and image scanning recorded during the period, mapped onto the Digital Operational Resilience Act. DORA governs a financial entity's entire ICT risk management framework, of which a container image control is one instrument: it speaks to identification of ICT assets, to protection, prevention and detection under Articles 8 to 11, and to the point in Article 28 where third-party code enters the estate. Governance, testing, backup and the incident reporting owed to competent authorities are the entity's own and are marked outside the scope of this document rather than claimed.
Fragen zu DORA
Ist das eine Zertifizierung nach DORA?
Nein. Das Paket ist ein Nachweis aus den clustereigenen Einträgen. Es ist keine Zertifizierung, und kein Auditor muss es anerkennen. Der Absatz zum Geltungsbereich auf dieser Seite ist derselbe, den auch der Bericht enthält.
Warum liegen 7 Anforderungen außerhalb des Umfangs?
Sie fragen nach Dingen, die die Admission- und Scan-Einträge eines einzelnen Clusters nicht zeigen können. Sie werden mit Begründung aufgeführt statt weggelassen, damit jeder Leser des Berichts sieht, dass der Ausschluss bewusst ist.
Welcher Plan enthält DORA?
Jeder Plan kann danach berichten. Community und Team enthalten 1 Framework Ihrer Wahl, Business 3, Enterprise alle. Die Preise stehen auf der Preisseite.
Wie prüft ein Auditor das Paket?
Im Browser unter attestkeep.com/verify.html, wo nichts hochgeladen wird, oder mit dem kurzen Skript auf der Dokumentationsseite. Beides kommt ohne uns aus. Einzelheiten stehen unter Für Auditoren.
Selbst installieren.
Konto anlegen, die E-Mail mit dem zugesandten Code bestätigen, den kostenlosen Community-Schlüssel auf der Seite Licences holen und mit Helm installieren.
Konto anlegen