GUIDE

Conformité et preuves d'audit

Référentiels supportés, méthode de scoring, exceptions tracées, rapport PDF signé Cosign.

Mis à jour: 2026-05-09

Conformité et preuves d’audit

Aegis Vetis traduit la posture sécurité d’un parc Kubernetes en deux sorties exploitables :

Un score de conformité lisible par un RSSI, mis à jour en continu, par cluster et par référentiel.
Un rapport PDF signé qu’un auditeur emporte, traçable jusqu’à l’événement source.

Ce document détaille les référentiels supportés, la méthode de scoring, le cycle de vie des exceptions, le contenu et la signature du rapport, et la procédure de vérification offline.

1. Référentiels supportés

Référentiel	Couverture	Statut
CIS Kubernetes Benchmark	Sous-ensemble couvrable par contrôles techniques (Kyverno + Kubescape + Trivy)	Mappé et scoré
NIS2-inspired	Mapping simplifié dérivé des exigences sécurité de la directive NIS2	Mappé et scoré
SecNumCloud-inspired	Mapping simplifié dérivé du référentiel SecNumCloud de l’ANSSI	Mappé et scoré

Aegis Vetis fournit des contrôles techniques inspirés de ces référentiels. La plateforme ne constitue pas une attestation officielle de conformité — elle vous donne les preuves techniques que votre auditeur consolidera dans son audit formel.

Cette mention figure en clair sur chaque rapport PDF, sur l’UI et dans les présentations commerciales. C’est à la fois une protection juridique et un engagement de transparence.

D’autres référentiels (HDS, ISO 27001, PCI-DSS) sont sur la roadmap.

2. Modèle de mapping

Chaque référentiel est décrit en YAML versionné, livré avec la plateforme :

Framework
 └── Domain              (ex : "Access Control")
      └── Control        (ex : "AC-2 — Account management")
           └── TechnicalCheck
                ├── kind:   kyverno-policy | kubescape-control | trivy-finding
                ├── ref:    <identifiant>
                └── weight: 1..5

Un contrôle d’un référentiel peut être couvert par plusieurs vérifications techniques.
Une vérification technique peut servir à plusieurs contrôles, croisée entre référentiels.
Le poids reflète la criticité métier du contrôle, pas la sévérité technique de la violation.

3. Méthode de scoring

Le score d’un contrôle, d’un domaine et d’un référentiel se calcule ainsi :

score(control)   = Σ (weight_i × pass_i) / Σ weight_i
score(domain)    = moyenne pondérée des contrôles du domaine
score(framework) = moyenne pondérée des domaines

Recalcul :

À chaque ingestion de scan Kubescape ou Trivy.
À chaque nouvelle violation Kyverno reçue de l’agent.
Sinon, par cron toutes les 15 min.

Effet des exceptions actives :

Le contrôle reste affiché en violation dans le rapport.
Le score brut est calculé sans l’exception (pénalité réelle).
Le score pondéré est calculé avec l’exception (pénalité réduite proportionnellement à l’expiration).

Le rapport PDF affiche les deux scores, pour ne pas masquer la réalité technique au RSSI ni à l’auditeur.

4. Exceptions

Une exception autorise temporairement une violation, avec justification, ticket de référence et date d’expiration obligatoire. C’est le mécanisme par lequel un platform engineer dit “je sais que c’est non conforme, voici pourquoi, voici la date où je l’aurai corrigé.”

Cycle de vie

[Active] ─── (TTL atteint, cron quotidien) ───► [Expired]
   │
   └─── (révocation manuelle) ───────────────► [Revoked]

Une exception expirée ou révoquée n’est plus appliquée par l’agent : la PolicyException Kyverno correspondante est retirée et la policy redevient enforce sur la cible. La trace en base reste consultable indéfiniment dans le journal d’audit.

Création depuis l’UI

Compliance → Violations → … → Create exception

Périmètre : cluster + namespace + ressource (kind / name).
Policy concernée.
Raison textuelle obligatoire.
Référence ticket (champ libre).
Expiration : date obligatoire, max 365 jours.

Toute création, modification ou révocation d’exception émet un audit_event avec actor_id, before / after et occurred_at.

Création depuis l’API

POST /api/v1/exceptions HTTP/1.1
Authorization: Bearer eyJ...
Content-Type: application/json

{
  "cluster_id": "8f...",
  "policy": "disallow-host-path",
  "namespace": "legacy",
  "reason": "Migration en cours, hostPath nécessaire",
  "ticket": "JIRA-12876",
  "expires_at": "2026-09-30T23:59:59Z"
}

5. Le rapport PDF

Contenu

Un rapport est généré par cluster et par référentiel. Il contient, dans l’ordre :

Page de garde : logo, nom du client, cluster, période, date de génération, hash SHA-256 du contenu, signature Cosign.
Synthèse exécutive : score global, top 5 risques, tendance sur 30 jours.
Score par référentiel et par domaine.
Violations actives par sévérité, avec namespace et workload concerné.
Exceptions actives : justification, ticket, expiration, responsable.
Détail des scans Kubescape et Trivy : top findings, distribution par sévérité.
Recommandations priorisées.
Annexes : policies appliquées, version Aegis Vetis, version Kubernetes.
Page de pied : disclaimer “inspiré de”, hash SHA-256 répété, signature détachée.

Génération

POST /api/v1/reports HTTP/1.1

{
  "cluster_id": "8f...",
  "framework": "cis-k8s",
  "format": "pdf"
}

Réponse synchrone : 202 Accepted + report_id. Le PDF est rendu en arrière-plan, en moins d’une minute en pratique. Statut consultable :

GET /api/v1/reports/{report_id}

{
  "id": "01JT...",
  "state": "ready",
  "sha256": "f3d4...",
  "size_bytes": 218410,
  "generated_at": "2026-05-09T14:00:00Z"
}

Téléchargement : GET /api/v1/reports/{report_id}/download.

6. Vérifier une signature Cosign

La signature détachée du rapport et la clé publique Cosign sont exposées par le Control Plane :

curl -sO https://aegis.example.com/api/v1/reports/{id}/download
curl -sO https://aegis.example.com/api/v1/reports/{id}/signature
curl -sO https://aegis.example.com/api/v1/reports/cosign.pub

cosign verify-blob \
  --key cosign.pub \
  --signature <id>.sig \
  <id>.pdf
# → Verified OK

La vérification fonctionne hors-ligne : aucun appel à un service de transparence (Rekor) n’est requis. La clé publique Cosign peut être archivée par l’organisation à part, et utilisée plusieurs années plus tard pour vérifier un rapport historique.

La signature actuelle utilise une clé Cosign locale (ECDSA P-256). L’intégration HSM et le timestamping RFC 3161 figurent sur la roadmap.

7. Journal d’audit

Toutes les actions sensibles génèrent une entrée immuable dans audit_events :

Action	Acteur	Détail capturé
`user.login`	utilisateur	méthode (locale / OIDC), IP, user-agent
`cluster.enroll`	admin	cluster, token bootstrap consommé
`policy.assign`	operator	cluster, policy, mode (audit / enforce)
`exception.create`	operator	cluster, namespace, policy, raison, ticket, expiration
`exception.revoke`	operator	exception_id, raison
`report.generate`	operator	cluster, framework, report_id, sha256

L’audit est exportable au format JSON ou CSV depuis l’UI (Audit → Export) ou via l’API (GET /api/v1/audit?from=&to=).

8. Limites de la version courante

Limite	Mitigation actuelle	Sur la roadmap
Pas de HSM pour les clés JWT et Cosign	Secrets Kubernetes + chiffrement etcd côté cluster	Intégration KMS (AWS, Azure, Vault)
Pas de TSA RFC 3161	SHA-256 + signature Cosign locale, horodatage applicatif `generated_at`	Sidecar TSA optionnel
Pas de stockage WORM natif	Append-only par convention applicative + audit chaîné	Stockage dédié (S3 Object Lock, immutable blobs Azure)
Pas de Rekor (transparency log Sigstore)	Vérification offline OK avec `cosign.pub` archivée	Toggle Rekor optionnel à l’inclusion du bundle

Ces limites sont assumées explicitement et documentées en préambule de chaque rapport, pour ne pas induire en erreur l’auditeur.

9. Aller plus loin

Architecture — flux d’ingestion des preuves.
Installation — provisionner les clés Cosign.
Page Sécurité — posture sécurité de la plateforme.
Glossaire et FAQ.

Toute la documentation Retour à l'accueil