DORA (Digital Operational Resilience Act)
Attestkeep rattache ce que l'admission control et le scan d'images de votre cluster ont enregistré sur une période à 22 exigences (source : règlement (UE) 2022/2554). 15 sont évaluées sur ces enregistrements ; 7 sont marquées hors périmètre, chacune avec la raison.
15 exigences à portée de cluster.
Références et titres tels que le rapport les imprime, c'est-à-dire en anglais. Ouvrez une exigence pour lire ce qu'elle demande, reformulé au plus près du texte de l'instrument.
Digital Operational Resilience Act
règlement (UE) 2022/2554
Chapitre II, articles 8 à 11 (gestion du risque lié aux TIC : identification, protection et prévention, détection, réponse) et chapitre V, article 28 (risque lié aux prestataires tiers de services TIC)
| Référence | Exigence | Sections du rapport |
|---|---|---|
| Article 8(1) | Identify, classify and document ICT assetsLes entités financières identifient, classent et documentent de manière adéquate toutes les fonctions métier, rôles et responsabilités s'appuyant sur les TIC, ainsi que les actifs informationnels et TIC qui soutiennent ces fonctions, et réexaminent chaque année l'adéquation de cette classification. | CoverageControl statement |
| Article 8(6) | Maintain and update inventoriesLes entités financières tiennent des inventaires pertinents et les mettent à jour périodiquement et à chaque changement majeur. | Coverage |
| Article 8(5) | Identify processes dependent on third-party providersLes entités financières identifient et documentent tous les processus qui dépendent de prestataires tiers de services TIC. | Control statementSupply chain |
| Article 9(2) | Availability, authenticity, integrity and confidentiality of dataLes entités financières conçoivent, acquièrent et mettent en œuvre des politiques, procédures, protocoles et outils de sécurité des TIC visant à garantir la résilience, la continuité et la disponibilité des systèmes de TIC et à maintenir des normes élevées de disponibilité, d'authenticité, d'intégrité et de confidentialité des données, au repos, en cours d'utilisation ou en transit. | Supply chainControl statement |
| Article 9(3)(b) | Minimise the risk of technical flawsLes entités financières réduisent au minimum le risque d'altération ou de perte de données, d'accès non autorisé et de défaillances techniques susceptibles d'entraver l'activité. | CoverageAdmission decisionsOutcomes |
| Article 9(4)(c) | Limit logical access to what legitimate functions requireLes entités financières mettent en œuvre des politiques qui limitent l'accès physique ou logique aux actifs informationnels et TIC à ce qu'exigent les seules fonctions et activités légitimes et approuvées. | Control statementAdmission decisions |
| Article 9(4)(d) | Strong authentication mechanismsLes entités financières mettent en œuvre des politiques et protocoles de mécanismes d'authentification forte, fondés sur des normes pertinentes et des systèmes de contrôle dédiés. | Evidence chain |
| Article 9(4)(e) | ICT change managementLes entités financières disposent de politiques, procédures et contrôles documentés de gestion des changements des TIC, garantissant que tous les changements sont enregistrés, testés, évalués, approuvés, mis en œuvre et vérifiés de manière maîtrisée. | Control statementAdmission decisionsEvidence chain |
| Article 9(4)(f) | Patches and updatesLes entités financières disposent de politiques documentées appropriées et complètes en matière de correctifs et de mises à jour. | Control statementCoverageAdmission decisionsOutcomesIssues |
| Article 10(1) | Promptly detect anomalous activities and single points of failureLes entités financières disposent de mécanismes permettant de détecter rapidement les activités anormales, y compris les problèmes de performance des réseaux TIC et les incidents liés aux TIC, et d'identifier les points de défaillance uniques potentiellement significatifs. Tous les mécanismes de détection sont testés régulièrement. | CoverageAvailability |
| Article 10(2) | Alert thresholds and criteria to trigger responseLes mécanismes de détection permettent plusieurs niveaux de contrôle et définissent des seuils d'alerte et des critères pour déclencher les processus de réponse aux incidents liés aux TIC, y compris des alertes automatiques au personnel concerné. | Admission decisionsCoverageOutcomesBreak-glass events |
| Article 10(3) | Resources to monitor activity and anomaliesLes entités financières consacrent des ressources et des capacités suffisantes à la surveillance de l'activité des utilisateurs, de la survenue d'anomalies TIC et d'incidents liés aux TIC, en particulier des cyberattaques. | Evidence chainAdmission decisionsBreak-glass events |
| Article 11(1) | ICT business continuity policyLes entités financières mettent en place une politique complète de continuité des activités TIC, partie intégrante de leur politique de continuité opérationnelle, pour garantir la continuité des fonctions critiques ou importantes. | Availability |
| Article 28(4) | Due diligence before entering a third-party arrangementAvant de conclure un accord contractuel portant sur l'utilisation de services TIC, les entités financières identifient et évaluent tous les risques pertinents et exercent toute la diligence requise à l'égard des prestataires tiers de services TIC envisagés. | Supply chainControl statement |
| Article 28(5) | Providers shall meet appropriate information security standardsLes entités financières ne peuvent conclure d'accords contractuels qu'avec des prestataires tiers de services TIC qui respectent des normes appropriées de sécurité de l'information ; lorsque ces services soutiennent des fonctions critiques ou importantes, les normes les plus récentes et de la plus haute qualité s'appliquent. | Supply chainControl statementCoverageAdmission decisionsOutcomes |
7 exigences hors périmètre, et pourquoi
| Référence | Exigence et raison |
|---|---|
| Article 5 | Governance and organisation L'approbation, la surveillance et la responsabilité de l'organe de direction sont des enregistrements de l'entité, pas d'un cluster. Les paramètres d'application repris dans la déclaration de contrôle sont un résultat de cette gouvernance, pas une preuve de celle-ci. |
| Article 6 | ICT risk management framework Le cadre est un document que l'entité tient à jour et réexamine. Ce contrôle fonctionne à l'intérieur et produit des preuves pour certaines de ses parties ; il n'est pas le cadre. |
| Article 12 | Backup, restoration and recovery La sauvegarde et la restauration des systèmes et des données de l'entité dépassent ce qu'un admission controller enregistre. La sauvegarde de la base de données de l'operator revient au client. |
| Article 13 | Learning and evolving Le retour d'expérience après incident est une pratique menée par des personnes. Les refus, exceptions et fenêtres d'indisponibilité de ce document alimentent un tel retour d'expérience ; ils ne le constituent pas. |
| Articles 17 – 23 | ICT-related incident management, classification and reporting La classification selon les seuils de DORA et la notification à une autorité compétente sont des décisions et des déclarations de l'entité. Ce contrôle déclenche et enregistre des événements ; il ne les classe pas et ne les déclare pas. |
| Articles 24 – 27 | Digital operational resilience testing Le programme de tests de l'entité, y compris les tests de pénétration fondés sur la menace, est mené sur son système d'information par des testeurs. Rien de ce qu'un cluster enregistre ne prouve qu'il a eu lieu. |
| Article 28(3) | Register of information on contractual arrangements Le registre d'informations est un document contractuel détenu par l'entité. L'inventaire d'images de ce document enregistre ce qui tourne, pas ce qui a fait l'objet d'un contrat. |
Preuves tirées des journaux que tient déjà le cluster.
Rien n'est rempli à la main. La réponse à chaque exigence porte un statut (satisfaite, partielle, écart ou hors périmètre), une note avec les chiffres de la période et les sections du rapport d'où viennent ces chiffres.
Ce sur quoi s'appuie le mapping
Chaque exigence évaluée reçoit sa réponse d'une ou plusieurs de ces affirmations sur les enregistrements de la période. La même affirmation répond à la même question dans tous les frameworks : deux rapports sur une même période ne peuvent pas diverger.
- Chaque image de l'inventaire a un enregistrement de scan4 exigences
- Les images portant des vulnérabilités graves sont refusées4 exigences
- Seules les images de provenance établie peuvent tourner3 exigences
- Les images n'entrent que depuis des registries désignés3 exigences
- Chaque décision et chaque action d'administration est enregistrée2 exigences
- Le contrôle lui-même a fonctionné pendant toute la période2 exigences
- Les workloads désignent les images par digest, pas par un tag mobile2 exigences
- Un refus ou une vulnérabilité critique parvient à une personne2 exigences
- Un SBOM est conservé pour les images en service2 exigences
- L'accès administrateur est fédéré à un annuaire1 exigence
- L'admission refuse les workloads non conformes1 exigence
- Un délai de correction est déclaré pour chaque sévérité1 exigence
- Les privilèges des workloads sont limités à l'admission1 exigence
Ce que contient le rapport.
Chaque paquet contient les mêmes sections, quel que soit le framework. Les sections signalées sont celles que citent les réponses pour DORA, avec le nombre d'exigences qui renvoient à chacune.
- 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)
Le paragraphe de périmètre, tel que le rapport l'imprime (en anglais).
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.
Sur DORA
Est-ce une certification selon DORA ?
Non. Le paquet est une preuve produite à partir des enregistrements de votre cluster. Ce n'est pas une certification, et aucun auditeur n'est tenu de l'accepter. Le paragraphe de périmètre de cette page est celui que porte le rapport lui-même.
Pourquoi 7 exigences sont-elles hors périmètre ?
Elles portent sur des choses que les enregistrements d'admission et de scan d'un cluster ne peuvent pas montrer. Elles figurent avec la raison au lieu d'être omises, pour que le lecteur du rapport voie que l'exclusion est voulue.
Quel plan inclut DORA ?
Tous les plans peuvent produire un rapport selon ce framework. Community et Team incluent un framework au choix, Business trois, Enterprise tous. Les prix sont sur la page des tarifs.
Comment un auditeur vérifie-t-il le paquet ?
Dans un navigateur, sur attestkeep.com/verify.html, où rien n'est envoyé, ou avec le court script du site de documentation. Aucun des deux n'a besoin de nous. La page Pour les auditeurs donne le détail.
Installez-le vous-même.
Créez un compte, confirmez votre e-mail avec le code envoyé, prenez la clé Community gratuite sur la page Licences et installez avec Helm.
Créer un compte