ISO 27001 sur Kubernetes : preuve de conception contre preuve d'efficacité, mesure par mesure de l'annexe A

La plateforme de gouvernance, risques et conformité (GRC) est au vert : politique d'accès approuvée, règles Kyverno dans Git, manifestes de contrôle d'accès fondé sur les rôles (RBAC) revus. Puis l'organisme de certification demande la revue des droits du dernier trimestre et ce qu'elle a retiré, les exceptions accordées à une règle d'admission et leur approbateur, la dernière alerte de détection et la personne qui l'a traitée, la dernière restauration réussie. Pour le responsable plateforme ou le responsable de la sécurité des systèmes d'information (RSSI), la question devient : pourquoi, avec l'outil et les politiques, le dossier n'est-il pas prêt ?

La réponse tient dans la différence entre une preuve de conception, qui montre qu'une mesure est définie, et une preuve d'efficacité, qui montre qu'elle a fonctionné sur une période. Cet article la rend opérationnelle sur Kubernetes : ce que les normes demandent, ce que l'échantillonnage impose, un tableau mesure par mesure de l'annexe A avec les commandes utiles, deux vérifications contre les déclarations fausses, une chaîne de collecte. Le parcours de certification lui-même (étapes, calendrier, budget) n'est pas traité ici.

Conception, mise en œuvre, efficacité : trois preuves différentes

ISO/IEC 27001:2022 sépare déjà ces questions, sans ce vocabulaire. La déclaration d'applicabilité (clause 6.1.3 d) liste les mesures nécessaires, leur justification, le fait qu'elles soient mises en œuvre ou non et la justification des exclusions : une conception et un état de mise en œuvre, rien sur le fonctionnement. La clause 9.1 (« Monitoring, measurement, analysis and evaluation »), dans le chapitre 9 (« Performance evaluation »), traite de la surveillance, de la mesure, de l'analyse et de l'évaluation : c'est là que la norme place l'évaluation de la performance du système de management de la sécurité de l'information (SMSI).

Côté certification, ISO/IEC 17021-1 assigne à l'étape 2 (stage 2) l'évaluation de la mise en œuvre, « y compris l'efficacité », du système de management ; ISO/IEC TS 27008:2019 guide l'examen de la mise en œuvre et du fonctionnement des mesures. Le couple conception et efficacité de fonctionnement est aussi celui des rapports d'assurance de type SOC 2, présentés dans « SOC 2 ou ISO 27001 : lequel choisir pour un SaaS français, et comment préparer un premier SOC 2 ».

Une demande de fusion acceptée prouve qu'une conception a été relue ; elle ne prouve ni que la mesure est appliquée, ni qu'elle est efficace. Par méthode, et sans exigence normative, un dossier distingue quatre états pour une règle de plateforme : le test local (la règle évaluée sur des manifestes d'exemple), le rendu (la sortie de helm template ou de kustomize build contrôlée), le contrôle en intégration continue (le pipeline bloque un manifeste non conforme) et le contrôle observé en fonctionnement (la règle active dans le cluster, ses rapports, ses refus). Seul le dernier approche l'efficacité, et seulement s'il est observé dans la durée.

Une déclaration générale, du type « toutes les vulnérabilités critiques sont corrigées », se réfute par un seul élément contraire. Une déclaration utile est une mesure datée et bornée : « au JJ/MM/AAAA, les rapports Trivy Operator des espaces de noms de production ne comptent aucune vulnérabilité critique ouverte au-delà du délai fixé par la politique ».

Ce que l'échantillonnage impose au dossier

Selon ISO/IEC 17021-1:2015, l'organisme obtient les informations utiles par un échantillonnage approprié, puis les vérifie (clause 9.4.4.1), par entretiens, observation des processus et examen des documents et enregistrements (9.4.4.2) ; le rapport précise que l'audit repose sur un échantillonnage des informations disponibles (9.4.8.2). L'étape 1 évalue si les audits internes et les revues de direction sont planifiés et réalisés ; chaque année civile comporte ensuite au moins un audit, de surveillance ou de renouvellement (9.1.3.3). La surveillance couvre notamment les audits internes, la revue de direction, les actions sur les non-conformités précédentes, l'efficacité au regard des objectifs, la maîtrise opérationnelle continue et la revue des changements (9.6.2.2).

ISO/IEC 27006-1:2024 exige que l'équipe d'audit connaisse collectivement toutes les mesures de l'annexe A et leur mise en œuvre, et sache remonter des indices d'incidents jusqu'aux éléments du SMSI. Son annexe E, informative, guide la revue des mesures mises en œuvre ; son contenu n'a pas été consulté. ISO/IEC 27007:2020 complète ISO 19011 pour les audits de SMSI.

Ce que cela change pour une plateforme Kubernetes

Aucune source consultée ne fixe le nombre d'éléments tirés ni une durée minimale d'observation : ils relèvent des méthodes de l'organisme, qu'il faut lui demander. Lecture professionnelle des principes :

1. La population d'abord. Un échantillon se tire dans une liste : tous les changements de production pour 8.32, toutes les arrivées, mobilités et départs pour 5.18, toutes les exceptions aux règles d'admission pour 8.9. Une liste incomplète rend l'échantillon inutilisable.
2. L'auditeur choisit. Des exemples choisis par l'équipe ne forment pas un échantillon ; chaque élément doit pouvoir être produit sur demande.
3. La traçabilité de bout en bout. L'alerte mène au ticket, à la personne et à l'action ; la demande de fusion à l'approbation et au déploiement observé ; le départ à la désactivation dans le fournisseur d'identité, puis à la disparition des droits dans le cluster.
4. La période entière. Une revue trimestrielle se prouve par chaque trimestre écoulé. Un trimestre sans trace est un écart, pas un oubli de classement.

La clause 9.2 suit la même logique

La clause 9.2 (« Internal audit ») et sa sous-clause 9.2.2 (« Internal audit programme ») encadrent les audits internes du SMSI, conduits selon un programme. Un audit interne qui relit les politiques sans tirer d'échantillon dans les journaux du cluster laisse ce travail à l'organisme de certification. La page consacrée à l'audit interne ISO 27001 externalisé décrit comment CTN Solutions l'organise.

Mesure par mesure : conception, efficacité et où trouver la preuve dans Kubernetes

L'annexe A d'ISO/IEC 27001:2022 liste 93 mesures de sécurité, réparties en quatre thèmes : mesures organisationnelles (5.1 à 5.37), liées aux personnes (6.1 à 6.8), physiques (7.1 à 7.14) et technologiques (8.1 à 8.34). La déclaration d'applicabilité indique celles qui sont retenues et justifie les exclusions. Le tableau couvre celles dont une partie de la preuve se trouve dans un cluster Kubernetes ou chez son fournisseur cloud ; il suit les intitulés français d'ISO/IEC 27002:2022, dont l'annexe A d'ISO/IEC 27001:2022 reprend la liste. Les noms entre chevrons sont à remplacer.

Accès et privilèges : ce que kubectl auth can-i montre, et ce qu'il tait

# Droits effectifs d'un compte de service (--as exige le droit d'emprunt d'identité)
kubectl auth can-i --list --as=system:serviceaccount:<espace>:<compte> -n <espace>

# Qui détient cluster-admin, à date
kubectl get clusterrolebindings -o json | jq -r '.items[]
  | select(.roleRef.name == "cluster-admin")
  | "\(.metadata.name) : \([.subjects[]? | "\(.kind)/\(.name)"] | join(", "))"'

# Rôles qui ouvrent une élévation : jokers, escalate, bind, impersonate, nodes/proxy, Secrets
kubectl get clusterroles -o json | jq -r '.items[] | select(any(.rules[]?;
    (.verbs | any(. == "*" or . == "escalate" or . == "bind" or . == "impersonate"))
    or ((.resources // []) | any(. == "*" or . == "nodes/proxy" or . == "secrets"))))
  | .metadata.name'

# Amazon EKS : accès accordés hors RBAC
aws eks list-access-entries --cluster-name <cluster>
aws eks list-associated-access-policies --cluster-name <cluster> --principal-arn <arn>

La documentation Kubernetes liste les droits qui ne sont pas ce qu'ils paraissent : list et watch sur les Secrets en révèlent le contenu ; get sur nodes/proxy n'est pas une lecture seule, ouvre l'API du kubelet et contourne journalisation d'audit et contrôle d'admission ; escalate, bind et impersonate permettent de dépasser ses propres droits ; un membre de system:masters échappe à tout contrôle RBAC. Un rôle « lecture seule » se vérifie donc règle par règle, et la même page juge « vital » de revoir périodiquement les réglages RBAC.

Sur Amazon EKS, kubectl auth can-i --list n'affiche pas les permissions des politiques d'accès associées à une entrée d'accès, et --as force l'autorisation RBAC : une revue qui ne lit que les bindings y est incomplète. Côté identité, Keycloak ne stocke ni n'affiche les événements par défaut, seules les erreurs étant journalisées ; l'enregistrement des événements d'administration s'active par Save events dans les réglages du royaume, faute de quoi rien ne dit qui a modifié un groupe (voir « Piloter la configuration Keycloak en GitOps : adoption, dérive et suppression de champs »).

La preuve d'efficacité d'une revue d'accès tient en trois pièces : l'export à la date de la revue, la décision (qui, quoi, ticket) et l'export suivant, qui montre que les retraits ont eu lieu.

Journalisation de l'API Kubernetes : la source centrale des preuves d'efficacité

Sans l'option --audit-policy-file, kube-apiserver ne journalise aucun événement. La politique est lue dans l'ordre et la première règle qui correspond fixe le niveau : None, Metadata (utilisateur, horodatage, ressource, verbe, sans corps), Request ou RequestResponse. Un extrait qui sert les mesures 8.2 et 8.24 :

apiVersion: audit.k8s.io/v1
kind: Policy
omitStages:
  - "RequestReceived"
rules:
  # Secrets : qui les lit ou les modifie, jamais leur contenu
  - level: Metadata
    resources:
      - group: ""
        resources: ["secrets"]
  # Changements de droits : corps de la requête et de la réponse
  - level: RequestResponse
    verbs: ["create", "update", "patch", "delete"]
    resources:
      - group: "rbac.authorization.k8s.io"
        resources: ["roles", "rolebindings", "clusterroles", "clusterrolebindings"]
  # Tout le reste au niveau des métadonnées
  - level: Metadata

La règle sur les Secrets vient en premier : placée après une règle Request plus large, elle ne s'appliquerait jamais et le journal recopierait les valeurs. Sur un service managé, la configuration décide des preuves qui existeront. Sur EKS, les journaux du plan de contrôle ne partent pas vers CloudWatch Logs par défaut : chaque type s'active séparément, et le journal d'audit arrive dans le groupe /aws/eks/<cluster>/cluster, flux kube-apiserver-audit-.... Sur Azure Kubernetes Service (AKS), les journaux du plan de contrôle ne sont pas collectés sans paramètre de diagnostic, et la catégorie kube-audit-admin, conseillée pour réduire le coût, exclut les événements get et list : une lecture de Secret par ces verbes n'y laisse aucune trace. Sur Google Kubernetes Engine (GKE), les journaux Data Access, qui couvrent les lectures, sont désactivés par défaut.

La métrique apiserver_audit_error_total, quand elle est accessible, compte les événements perdus à l'export. Trois requêtes sur un journal JSON lines :

# Écritures humaines en production, hors comptes system: (dont celui de l'outil GitOps)
jq -c 'select(.stage == "ResponseComplete")
  | select(.verb | IN("create", "update", "patch", "delete"))
  | select(.objectRef.namespace == "<production>")
  | select(.user.username | startswith("system:") | not)
  | {t: .requestReceivedTimestamp, qui: .user.username, verbe: .verb,
     objet: "\(.objectRef.resource)/\(.objectRef.name)", code: .responseStatus.code}' audit.log

# Lectures de Secrets, pour la revue des accès aux informations sensibles
jq -c 'select(.stage == "ResponseComplete" and .objectRef.resource == "secrets")
  | select(.verb | IN("get", "list", "watch"))
  | {t: .requestReceivedTimestamp, qui: .user.username, verbe: .verb,
     ns: .objectRef.namespace, nom: .objectRef.name}' audit.log

# Tentatives refusées par l'autorisation
jq -c 'select(.annotations["authorization.k8s.io/decision"] == "forbid")' audit.log

La première donne pour 8.32 ce que Git ne donne pas : qui a écrit en production hors processus, à rapprocher du ticket qui dit pourquoi. Un pipeline qui écrit avec son propre compte de service se liste à part, puisque le filtre exclut les comptes system:. La dernière montre que le contrôle d'accès a refusé quelque chose, ce qu'aucune politique écrite ne démontre.

Admission, configuration et réseau

Kyverno publie ses résultats dans des PolicyReport et ClusterPolicyReport (wgpolicyk8s.io/v1alpha2), avec les résultats pass, fail, warn, error et skip. Ces rapports représentent l'état courant du cluster et ne gardent aucun historique : une entrée disparaît avec sa ressource. Une règle en failureAction: Enforce bloque immédiatement une ressource non conforme, qui n'apparaît donc pas dans les rapports ; pour les ressources bloquées, la documentation de Kyverno renvoie à la métrique d'exécution des règles ou aux événements Kubernetes émis sur la politique, à exporter puisque les événements expirent. L'efficacité d'une règle bloquante se prouve donc par les rapports sur l'existant, par ces refus exportés et par ceux du journal d'audit. spec.validationFailureAction est déprécié au profit de failureAction par règle : la preuve de conception montre le mode règle par règle.

Les PolicyException sont désactivées par défaut (options enablePolicyException et exceptionNamespace) ; une exception applicable fait ignorer la règle pour la ressource, et le rapport indique skip. La page consultée ne décrit pas de date d'échéance propre aux exceptions. Le registre des exceptions (ticket, approbateur, échéance, retrait vérifié) se tient donc hors de Kyverno, et c'est lui que l'auditeur échantillonne pour 8.9. Gatekeeper, lui, ne garde par défaut que 20 violations dans le statut de chaque contrainte (--constraint-violations-limit), totalViolations gardant le nombre réel ; une contrainte en dryrun signale sans bloquer : elle ne prouve pas qu'une ressource non conforme est refusée. Pour Pod Security Admission, le mode enforce ne vise que les pods, alors que audit et warn s'appliquent aussi aux ressources de charge de travail.

Un pod n'est isolé que si une NetworkPolicy le sélectionne, et seulement si le plugin réseau applique ces politiques. Dans Kubernetes, sans configuration du chiffrement au repos, les Secrets sont stockés en clair dans etcd ; Amazon EKS applique par défaut un chiffrement d'enveloppe à partir de Kubernetes 1.28 : la preuve de conception dépend donc du service en place. Un tag d'image peut être déplacé, un digest non, et la documentation déconseille :latest en production (voir « DevSecOps en pratique : scanner, signer et promouvoir l'image qu'on déploie vraiment »).

Ces points se vérifient par script ; chaque résultat se date et rejoint les preuves de la mesure qu'il sert (8.9, 8.20 et 8.22, 8.24) : l'export des rapports Kyverno, les espaces de noms qui n'ont pas de NetworkPolicy, les images qui ne sont pas référencées par digest et les variables d'environnement littérales dont le nom évoque un secret.

# Rapports Kyverno : état courant, à exporter à date
kubectl get policyreport -A -o json > policyreports-$(date -u +%Y-%m-%d).json

# Espaces de noms sans NetworkPolicy
comm -23 <(kubectl get ns -o jsonpath='{range .items[*]}{.metadata.name}{"\n"}{end}' | sort) \
  <(kubectl get networkpolicy -A -o jsonpath='{range .items[*]}{.metadata.namespace}{"\n"}{end}' | sort -u)

# Conteneurs dont l'image n'est pas référencée par digest
kubectl get pods -A -o json | jq -r '.items[] | .metadata.namespace as $ns | .metadata.name as $p
  | (.spec.containers[], (.spec.initContainers // [])[])
  | select(.image | contains("@sha256:") | not) | "\($ns)/\($p) \(.image)"'

# Variables littérales au nom évocateur d'un secret (le nom, jamais la valeur)
kubectl get pods -A -o json | jq -r '.items[] | .metadata.namespace as $ns | .metadata.name as $p
  | .spec.containers[] | .name as $c | (.env // [])[]
  | select(has("value") and (.name | test("PASS|SECRET|TOKEN|KEY"; "i")))
  | "\($ns)/\($p)/\($c) \(.name)"'

Le dernier filtre est une heuristique sur les noms de variables : son résultat ne vaut qu'à sa date et pour les noms recherchés. Un cluster qui utilise les politiques propres à son plugin réseau doit les ajouter au calcul de couverture.

Vulnérabilités et changements

Trivy Operator écrit un VulnerabilityReport (aquasecurity.github.io/v1alpha1) par conteneur de chaque charge de travail, avec les dernières vulnérabilités trouvées : encore un état courant. L'efficacité de 8.8 est la série de ces rapports, rapprochée des tickets de correction et des délais que fixe votre propre politique. Pour 8.32, Argo CD ne garde par défaut que 10 entrées d'historique par application (revisionHistoryLimit) : argocd app history montre les derniers déploiements, pas la période, que seuls Git et le journal d'audit couvrent. Une écriture faite hors de Git apparaît alors comme une dérive à expliquer (voir « GitOps en production : Argo CD ou Flux, santé des applications et nettoyage des orphelins »).

kubectl get vulnerabilityreports -A -o wide
argocd app history <application>

Une alerte n'existe que si quelqu'un la reçoit, une rétention que si on la mesure

Suivre l'alerte jusqu'à l'humain

Une règle de détection active et un arbre de routage sont des preuves de conception : ils ne disent pas qu'une personne reçoit l'alerte. La documentation d'Alertmanager définit un récepteur comme une configuration nommée d'une ou plusieurs intégrations de notification ; un récepteur déclaré sans intégration n'avertit donc personne. Les valeurs par défaut du chart kube-prometheus-stack (version 92.1.0, lues le 7 octobre 2026) en déclarent un, nommé null, vers lequel pointent la route racine et la route de l'alerte Watchdog : tant que cette configuration n'est pas remplacée, une alerte qu'aucune autre route ne capte n'atteint personne.

L'efficacité de 8.16 demande donc trois preuves de plus :

1. Un test de routage. amtool config routes test indique les récepteurs qu'une alerte portant des étiquettes données atteindrait ; avec --verify.receivers, il renvoie le code 1 en cas d'écart, ce qui permet de le rejouer en intégration continue.
2. Un compteur qui bouge. alertmanager_notifications_total, étiqueté par intégration, compte les notifications tentées, alertmanager_notifications_failed_total les échecs. Un compteur resté plat pendant des semaines sur l'intégration censée prévenir une personne appelle une vérification.
3. Un événement contrôlé. Falcosidekick transmet les alertes Falco à Alertmanager, et l'outil event-generator du projet Falco produit des actions que les règles détectent. Sa documentation conseille de l'exécuter dans un conteneur, certaines actions modifiant des fichiers système : il se réserve à un environnement isolé dont la chaîne d'alerte est identique à la production. La preuve est l'acquittement horodaté par une personne, puis le ticket.

# Une alerte portant ces étiquettes atteint-elle le récepteur attendu ? (code 1 si écart)
amtool config routes test --config.file=alertmanager.yaml \
  --verify.receivers=<récepteur-attendu> <étiquette>=<valeur>

# Requête PromQL : notifications tentées par intégration sur sept jours
#   sum by (integration) (increase(alertmanager_notifications_total[7d]))

Sur la période, l'échantillon se tire dans la liste des alertes de sévérité élevée : chacune se suit de la notification à l'acquittement, au ticket et à sa clôture.

Rétention déclarée contre rétention réelle

Une politique de journalisation écrit une durée de conservation ; un risque est que la durée réellement disponible soit plus courte, car elle est fixée par le plus court de plusieurs mécanismes :

• Le backend fichier de kube-apiserver. --audit-log-maxage (jours), --audit-log-maxbackup (fichiers) et --audit-log-maxsize (mégaoctets avant rotation) valent par défaut 366, 100 et 100 sur la branche 1.37 : le nombre de fichiers multiplié par leur taille borne le volume, et la durée couverte dépend donc du trafic.
• La destination. Sur CloudWatch Logs, retentionInDays fixe la conservation ; sans politique de rétention, rien n'expire, et un événement échu est en général supprimé dans les 72 heures qui suivent. Sur Loki, la rétention n'est pas activée par défaut et les journaux sont gardés indéfiniment ; activée, elle suit retention_period, et une règle de cycle de vie du stockage objet doit rester plus longue, sous peine de supprimer des données avant elle.
• Les événements Kubernetes. kube-apiserver les garde une heure par défaut (--event-ttl) : ce n'est pas une archive.
• Les quotas d'ingestion ou de stockage. Selon le produit, un quota atteint peut se traduire par des rejets ou des pertes : son remplissage se surveille comme une source de preuve.

La seule preuve est l'entrée la plus ancienne encore lisible, comparée à la date qu'implique la rétention déclarée, complétée par un comptage quotidien qui révèle les trous. Sur Loki, la même question se pose avec logcli query et les options --from, --to et --limit.

# Rétention configurée du groupe de journaux du plan de contrôle EKS
aws logs describe-log-groups --log-group-name-prefix /aws/eks/<cluster>/cluster \
  --query 'logGroups[].[logGroupName,retentionInDays,storedBytes]'

# Rétention déclarée de 90 jours au 28/09/2026 (exemple fictif) :
# un événement d'audit du 01/07/2026, 89 jours plus tôt, est-il encore lisible ?
aws logs filter-log-events --log-group-name /aws/eks/<cluster>/cluster \
  --log-stream-name-prefix kube-apiserver-audit \
  --start-time 1782864000000 --end-time 1782950400000 --max-items 1

Construire le dossier que l'outil GRC ne produit pas seul

Une plateforme GRC collecte par ses intégrations une partie des états de configuration, suit les tâches et peut porter l'index des preuves. Elle ne décide ni d'une revue d'accès, ni d'une exception, ni de l'acceptation d'un risque, et ne garde l'historique d'un cluster que si quelque chose l'exporte : or les objets vus plus haut ne conservent que l'état courant. Prouver l'efficacité revient donc à construire une chaîne de collecte dont la sortie est elle-même vérifiable.

Cinq règles de conception, qui relèvent de la pratique et non d'une exigence normative :

1. Des exports planifiés et horodatés en UTC, par exemple par un CronJob ; la mesure 8.17 (« Synchronisation des horloges ») conditionne la corrélation entre sources.
2. Un stockage en écriture unique, hors de portée des administrateurs du cluster. En mode conformité, S3 Object Lock interdit à tout utilisateur, y compris l'utilisateur racine, d'écraser ou de supprimer une version protégée ; le mode gouvernance le permet à des utilisateurs dotés de permissions spéciales. La mesure 5.33 (« Protection des enregistrements ») vaut aussi pour les preuves.
3. Un contrôle de couverture, qui transforme une collecte en preuve de continuité : une source qui cesse de déposer se voit le jour même, et non au moment de l'échantillonnage.
4. Un index par mesure : source, cadence, responsable, emplacement, relecteur. Quand l'auditeur demande 8.9, la réponse est un chemin, pas une recherche.
5. Les décisions humaines dans le même index : qui, quand, quelle décision.

Pour cadrer le périmètre, construire ces preuves et préparer l'évaluation, la page Accompagnement ISO 27001 : construire les preuves décrit notre intervention et ses limites ; la décision de certification reste l'acte de l'organisme accrédité.

Sources officielles et limites de lecture

Cette lecture repose sur ISO/IEC 27001:2022 (amendement 1:2024 compris), ISO/IEC 17021-1:2015, ISO/IEC 27006-1:2024, ISO/IEC 27007:2020 et ISO/IEC TS 27008:2019, sur la documentation de Kubernetes 1.37 (publiée le 26 août 2026), de Kyverno 1.19 et des outils cités, revérifiée le 7 octobre 2026.

• Textes payants. Les clauses 9.1 et 9.2 ne sont citées que par leurs intitulés, tirés du sommaire officiel ; leur contenu se lit sur le texte acheté. ISO/IEC 17021-1 a été lue dans un extrait publié par un organisme d'accréditation ; les intitulés de l'annexe A viennent de la prévisualisation française d'ISO/IEC 27002:2022.
• Ni taille d'échantillon ni durée d'observation : seul l'organisme de certification peut dire comment il échantillonne.
• Commandes. Les filtres jq ont été vérifiés sur des données de synthèse ; les autres commandes reprennent la syntaxe des documentations citées, sans exécution sur un cluster pour cet article. Les services managés évoluent : chaque comportement se revérifie sur la version en service.
• Base de l'article : méthode et documentation officielle, sans référence client ni retour de mission ; CTN Solutions n'exerce aucune activité de certification.

Sources

1. ISO/IEC 27001:2022, Information security, cybersecurity and privacy protection, Information security management systems, Requirements, ISO, https://www.iso.org/standard/27001, consulté le 28/09/2026.
2. ISO/IEC 27001:2022, extrait de prévisualisation (sommaire, clauses 1 à 6), iTeh Standards, https://cdn.standards.iteh.ai/samples/82875/726bcf58250e43d9a666b4d929c8fbdb/ISO-IEC-27001-2022.pdf, consulté le 07/10/2026.
3. ISO/IEC 27002:2022, extrait de prévisualisation en français (sommaire des mesures), iTeh Standards, https://cdn.standards.iteh.ai/samples/75652/9b0c626e1b1e4bda804fca1097e129db/ISO-IEC-27002-2022.pdf, consulté le 07/10/2026.
4. ISO/IEC 17021-1:2015, Conformity assessment, Requirements for bodies providing audit and certification of management systems, Part 1: Requirements, ISO, https://www.iso.org/standard/61651.html, consulté le 28/09/2026.
5. ISO/IEC 17021-1:2015, section 9, exigences relatives aux processus (extrait publié par l'organisme d'accréditation IAS), https://www.iasonline.org/wp-content/uploads/2021/02/17021-1-2015-Section-9.pdf, consulté le 07/10/2026.
6. Question 37.12, ISO 17021-1:2015 clause 9.1.3, European co-operation for Accreditation, https://european-accreditation.org/sp_accordion_faqs/question-37-12-iso-17021-12015-clause-9-1-3/, consulté le 07/10/2026.
7. ISO/IEC 27006-1:2024, Requirements for bodies providing audit and certification of information security management systems, Part 1: General, ISO, https://www.iso.org/standard/82908.html, consulté le 28/09/2026.
8. ISO/IEC 27006-1:2024, extrait de prévisualisation (sommaire, annexes, clauses 1 à 7), iTeh Standards, https://cdn.standards.iteh.ai/samples/82908/130ca63751e44a2a89b464af8d30cb00/ISO-IEC-27006-1-2024.pdf, consulté le 07/10/2026.
9. ISO/IEC 27007:2020, Guidelines for information security management systems auditing, ISO, https://www.iso.org/standard/77802.html, consulté le 28/09/2026.
10. ISO/IEC TS 27008:2019, Guidelines for the assessment of information security controls, ISO, https://www.iso.org/standard/67397.html, consulté le 28/09/2026.
11. Auditing, Kubernetes Documentation, https://kubernetes.io/docs/tasks/debug/debug-cluster/audit/, consulté le 07/10/2026.
12. Kube-apiserver Audit Configuration (v1), Kubernetes Documentation, https://kubernetes.io/docs/reference/config-api/apiserver-audit.v1/, consulté le 07/10/2026.
13. Audit Annotations, Kubernetes Documentation, https://kubernetes.io/docs/reference/labels-annotations-taints/audit-annotations/, consulté le 07/10/2026.
14. kube-apiserver (référence des options), Kubernetes Documentation, https://kubernetes.io/docs/reference/command-line-tools-reference/kube-apiserver/, et code source des options sur la branche release-1.37, https://github.com/kubernetes/kubernetes/blob/release-1.37/staging/src/k8s.io/apiserver/pkg/server/options/audit.go et https://github.com/kubernetes/kubernetes/blob/release-1.37/pkg/controlplane/apiserver/options/options.go, consultés le 07/10/2026.
15. kubectl auth can-i, Kubernetes Documentation, https://kubernetes.io/docs/reference/kubectl/generated/kubectl_auth/kubectl_auth_can-i/, consulté le 07/10/2026.
16. Role Based Access Control Good Practices, Kubernetes Documentation, https://kubernetes.io/docs/concepts/security/rbac-good-practices/, consulté le 07/10/2026.
17. Colonnes d'affichage des RoleBindings et ClusterRoleBindings (printers.go), dépôt kubernetes/kubernetes, branche release-1.37, https://github.com/kubernetes/kubernetes/blob/release-1.37/pkg/printers/internalversion/printers.go, consulté le 07/10/2026.
18. Good practices for Kubernetes Secrets, Kubernetes Documentation, https://kubernetes.io/docs/concepts/security/secrets-good-practices/, consulté le 07/10/2026.
19. Network Policies, Kubernetes Documentation, https://kubernetes.io/docs/concepts/services-networking/network-policies/, consulté le 07/10/2026.
20. Pod Security Admission et Enforce Pod Security Standards with Namespace Labels, Kubernetes Documentation, https://kubernetes.io/docs/concepts/security/pod-security-admission/ et https://kubernetes.io/docs/tasks/configure-pod-container/enforce-standards-namespace-labels/, consultés le 07/10/2026.
21. Images, Kubernetes Documentation, https://kubernetes.io/docs/concepts/containers/images/, consulté le 07/10/2026.
22. Releases et calendrier de publication (fichier schedule.yaml du site), Kubernetes, https://kubernetes.io/releases/, consulté le 07/10/2026.
23. Policy Reports, Kyverno Documentation, https://kyverno.io/docs/guides/reports/, consulté le 07/10/2026.
24. Policy Exceptions, Kyverno Documentation, https://kyverno.io/docs/guides/exceptions/, consulté le 07/10/2026.
25. Validate Rules, Kyverno Documentation, https://kyverno.io/docs/policy-types/cluster-policy/validate/, consulté le 07/10/2026.
26. Audit, Handling Constraint Violations et How to use Gatekeeper, OPA Gatekeeper Documentation, https://open-policy-agent.github.io/gatekeeper/website/docs/audit, https://open-policy-agent.github.io/gatekeeper/website/docs/violations et https://open-policy-agent.github.io/gatekeeper/website/docs/howto, consultés le 07/10/2026.
27. Send control plane logs to CloudWatch Logs, Amazon EKS User Guide, AWS, https://docs.aws.amazon.com/eks/latest/userguide/control-plane-logs.html, consulté le 07/10/2026.
28. Associate access policies with access entries et Grant IAM users access to Kubernetes with EKS access entries, Amazon EKS User Guide, AWS, https://docs.aws.amazon.com/eks/latest/userguide/access-policies.html et https://docs.aws.amazon.com/eks/latest/userguide/access-entries.html, consultés le 07/10/2026.
29. LogGroup et PutRetentionPolicy (API Reference), et filter-log-events (AWS CLI Command Reference), Amazon CloudWatch Logs, AWS, https://docs.aws.amazon.com/AmazonCloudWatchLogs/latest/APIReference/API_LogGroup.html, https://docs.aws.amazon.com/AmazonCloudWatchLogs/latest/APIReference/API_PutRetentionPolicy.html et https://docs.aws.amazon.com/cli/latest/reference/logs/filter-log-events.html, consultés le 07/10/2026.
30. Monitor Azure Kubernetes Service (AKS), Microsoft Learn, https://learn.microsoft.com/en-us/azure/aks/monitor-aks, consulté le 07/10/2026.
31. GKE audit logging, Google Cloud Documentation, https://docs.cloud.google.com/kubernetes-engine/docs/how-to/audit-logging, consulté le 07/10/2026.
32. Alertmanager Configuration, Prometheus Documentation, https://prometheus.io/docs/alerting/latest/configuration/ ; README (amtool) et notify/metrics.go, dépôt prometheus/alertmanager, https://github.com/prometheus/alertmanager, consultés le 07/10/2026.
33. values.yaml du chart kube-prometheus-stack (version 92.1.0), dépôt prometheus-community/helm-charts, https://github.com/prometheus-community/helm-charts/blob/kube-prometheus-stack-92.1.0/charts/kube-prometheus-stack/values.yaml, consulté le 07/10/2026.
34. AlertManager output, Falcosidekick, https://github.com/falcosecurity/falcosidekick/blob/master/docs/outputs/alertmanager.md, et event-generator, projet Falco, https://github.com/falcosecurity/event-generator, consultés le 07/10/2026.
35. Log retention et logcli getting started, Grafana Loki Documentation, https://grafana.com/docs/loki/latest/operations/storage/retention/ et https://grafana.com/docs/loki/latest/query/logcli/getting-started/, consultés le 07/10/2026.
36. VulnerabilityReport et Quick Start, Trivy Operator Documentation, https://aquasecurity.github.io/trivy-operator/latest/docs/crds/vulnerability-report/ et https://aquasecurity.github.io/trivy-operator/latest/getting-started/quick-start/, consultés le 07/10/2026.
37. argocd app history et manifeste Application de référence (revisionHistoryLimit), Argo CD Documentation, https://argo-cd.readthedocs.io/en/stable/user-guide/commands/argocd_app_history/ et https://argo-cd.readthedocs.io/en/stable/operator-manual/application.yaml, consultés le 07/10/2026.
38. Server Administration Guide, Auditing and events (login events, admin events), Keycloak 26.8, https://www.keycloak.org/docs/latest/server_admin/, consulté le 07/10/2026.
39. Locking objects with Object Lock, Amazon S3 User Guide, AWS, https://docs.aws.amazon.com/AmazonS3/latest/userguide/object-lock.html, consulté le 07/10/2026.
40. Données ouvertes de l'ISO, métadonnées des publications (statut, stade, résumé), ISO, https://isopublicstorageprod.blob.core.windows.net/opendata/_latest/iso_deliverables_metadata/json/iso_deliverables_metadata.jsonl, consulté le 07/10/2026.
41. Default envelope encryption for all Kubernetes API Data, Amazon EKS User Guide, AWS, https://docs.aws.amazon.com/eks/latest/userguide/envelope-encryption.html, consulté le 07/10/2026.