ISO/IEC 27001:2022, annexe A — vue de l'état de préparation des mesures
Cette page est générée à partir de la table d'exigences que le moteur AiSSAY livre pour ce référentiel. Quand le moteur produit un dossier de preuves, chaque ligne ci-dessous reçoit un statut calculé à partir des propres enregistrements de l'opérateur à ce moment-là. Cette page montre la table, pas les résultats de qui que ce soit.
Mise en correspondance à titre informatif, établie par les propres outils de l'opérateur. Ce n'est ni un avis juridique, ni une certification, ni un substitut au conseil d'un avocat. Elle organise les enregistrements de l'opérateur au regard des exigences citées ; la question de savoir si ces enregistrements satisfont aux exigences relève de l'appréciation de l'opérateur, de son conseil juridique et du contrôleur.
ISO 27001 certifie un système de management de la sécurité de l'information (SMSI), audité par un organisme accrédité. Cette vue met en correspondance les mécanismes livrés avec les thèmes de l'annexe A et nomme clairement les lacunes du SMSI.
La table d'exigences
12 lignes : 6 mécanismes, 4 organisationnelles, 1 lacune nommée, 1 calculée
| Exigence | Mécanisme, obligation ou lacune | Type |
|---|---|---|
| A.5.1 — politiques de sécurité de l'information | organisationnel : l'ensemble documentaire du SMSI | organisationnel |
| A.5.19–5.22 — relations avec les fournisseurs | organisationnel : registre des sous-traitants (la conception auto-hébergée garde ce registre court par construction) | organisationnel |
| A.6 — mesures liées aux personnes (sélection, formation, accords de confidentialité) | organisationnel | organisationnel |
| A.8.15 — journalisation | journal d'accès chaîné par hachage avec l'acteur, l'action et la raison ; chaque lecture de chaque enregistrement y est consignée | mécanisme |
| A.8.16 — activités de surveillance | vérification de la chaîne, vérification de l'ancrage, y compris la détection d'un échange de clé, scellement des lacunes de capture | mécanisme |
| A.8.24 — utilisation de la cryptographie | AES-256-GCM au repos, attestation et approbations Ed25519, chaînes SHA-256 ; les clés ne quittent jamais les machines de l'opérateur | mécanisme |
| A.8.13 — sauvegarde des informations | mécanisme de restauration à partir du témoin livré ; le calendrier de sauvegarde et les tests sont organisationnels | organisationnel |
| A.8.32 — gestion des changements | estampilles VERSION, suites de régression figées, registre signé des profils d'instrument | mécanisme |
| A.5.15/A.8.3 — contrôle d'accès et restriction d'accès à l'information | DÉLÉGUÉ lorsque le stockage est scellé par votre gestionnaire de clés (le fournisseur kms) : toute personne que votre gestionnaire de clés refuse ne peut pas ouvrir le stockage du tout, et chaque ouverture apparaît dans le propre journal d'audit de votre gestionnaire de clés. Le stockage lui-même n'a ni authentification, ni rôles, ni permissions, et ne refuse aucune lecture : une fois une clé désencapsulée, le processus qui la détient peut lire chaque enregistrement. Avec tout autre fournisseur, NON IMPLÉMENTÉ — les permissions de fichiers du système d'exploitation sont le seul contrôle d'accès. Le statut est calculé à partir du fournisseur que déclare ce stockage, et non supposé. | calculé |
| A.8.24 — utilisation de la cryptographie, y compris le cycle de vie des clés | cérémonie de changement de clé : une clé successeur est scellée par le même fournisseur, chaque enregistrement est placé sous cette clé, chacun déclarant sa clé, et l'ancienne clé n'est détruite qu'après la relecture réussie de chaque enregistrement sous la nouvelle ; les autorisations et les parts de garde de la clé retirée n'ouvrent plus rien ensuite. La rotation de la clé d'encapsulation propre au gestionnaire de clés relève du gestionnaire de clés. LIMITE : quiconque détient à la fois l'ancienne clé et une ancienne copie du texte chiffré peut toujours lire cette copie. | mécanisme |
| A.8.8 (identification) — vulnérabilités connues dans les dépendances Python | chaque paquet Python résolu à partir de requirements.txt et du fichier facultatif requirements-aws.txt est contrôlé, chaque fichier dans son propre bloc, au regard d'une base publique d'avis de sécurité AU MOMENT DE LA PUBLICATION, et le rapport est livré avec son empreinte (depscan.py, DEPSCAN.json). Ce contrôle ne peut pas s'exécuter sur votre machine, parce que la base d'avis se trouve sur le réseau. Ni les paquets du système d'exploitation, ni l'interpréteur, ni de façon continue. | mécanisme |
| A.8.8/A.8.29 — remédiation, surveillance et tests de sécurité | PARTIELLEMENT IMPLÉMENTÉ, et les parties sont nommées. Présent : une analyse des dépendances au moment de la publication, avec un contrôle d'ancienneté qui refuse qu'une analyse périmée passe pour actuelle ; un vérificateur statique sur cette arborescence pour un ensemble court et listé de catégories de défauts, éprouvé à chaque version sur un fichier où un exemplaire de chacune a été introduit ; et un fuzzing par mutation des analyseurs qui lisent des entrées que nous n'avons pas écrites, éprouvé sur un analyseur délibérément défectueux. Absent : tests d'intrusion, analyse des paquets du système d'exploitation, surveillance continue entre les versions, et revue de la conception cryptographique par un tiers. Décider quoi faire d'un constat est une procédure, et cette procédure appartient à l'opérateur. | lacune nommée |
Comment un statut s'obtient
- Étayé
- une vérification déterministe a été exécutée sur vos enregistrements et les décomptes étayent la ligne. Un stockage ne contenant aucun enregistrement pertinent apparaît comme non étayé — une affirmation vraie, pas une validation. Vide ne compte jamais comme conforme.
- Délégué
- le mécanisme est appliqué par un système auquel vous faites déjà confiance — un stockage scellé par votre propre gestionnaire de clés lui délègue le contrôle d'accès, et le dossier indique que le journal qui fait foi est celui de votre gestionnaire de clés, pas le nôtre. Le dossier nomme le point de terminaison par lequel le gestionnaire de clés a été joint. Un point de terminaison AWS autre que celui qu'AWS utilise par défaut pour la région apparaît comme délégué à ce point de terminaison, avec une demande de confirmation qu'il s'agit bien de votre service de gestion des clés. Un seul backend — AWS KMS — a été exécuté sur le service AWS KMS réel ; aucun autre backend ne l'a été.
- Point d'intégration de test
- scellé par un backend de test interne au processus — un bouchon (stub), ou un substitut du client AWS — et le statut précise lequel. Aucun gestionnaire de clés n'applique le contrôle d'accès. Le point d'intégration est construit et testé, et le dossier refuse d'appeler cela une délégation.
- Partiellement étayé
- le mécanisme est construit et certaines de vos exécutions en portent la preuve, mais pas toutes — généralement parce qu'elles ont été scellées avant que le mécanisme n'existe. Le dossier indique combien d'exécutions se trouvent dans chaque groupe, et ne compte jamais celles qui manquent comme validées.
- Organisationnel
- l'exigence est une procédure que seules des personnes peuvent accomplir. Le dossier la désigne comme la vôtre au lieu de déguiser une politique en mécanisme.
- Lacune nommée
- le dossier ne peut pas l'étayer — soit le mécanisme n'est pas construit, soit aucun logiciel ne peut le fournir — et il précise lequel des deux. La lacune est imprimée, parce qu'un examinateur doit la lire ici plutôt que la découvrir.
Aucun statut n'est saisi à la main : chaque statut est recalculé à partir du stockage chaque fois qu'un dossier est produit, le texte des exigences et des mécanismes est rédigé et relu dans le cadre du moteur, et les preuves relatives aux dépendances proviennent de notre analyse de version. Un mécanisme en échec ne peut jamais être lu comme la preuve que le contrôle fonctionne.
Les lignes marquées « calculé » sont les lignes relatives au contrôle d'accès. Leur statut est calculé à partir du fournisseur que déclare votre stockage : une lacune, sauf si votre gestionnaire de clés scelle le stockage ; « point d'intégration de test » avec un backend bouchon ou de substitution ; « délégué » uniquement avec un backend réel. Aujourd'hui, elles ne peuvent jamais apparaître comme étayées, et les présenter comme un mécanisme construit les surestimerait.