Cartographie de conformité

AKKO fournit des contrôles de sécurité intégrés qui correspondent aux principaux référentiels de conformité. Cette page documente comment chaque fonctionnalité AKKO s'aligne avec les exigences SOC 2, ISO 27001 et RGPD.

Ce n'est pas une certification

Cette cartographie est un guide de référence. L'obtention d'une certification formelle nécessite un audit indépendant, une documentation des politiques et des contrôles organisationnels au-delà de l'implémentation technique.

Tableau de correspondance des contrôles

Fonctionnalité AKKO	Contrôle SOC 2	ISO 27001	RGPD
Keycloak SSO + MFA	CC6.1 Contrôle d'accès	A.9 Contrôle d'accès	Art. 32 Sécurité
OPA Sécurité au niveau des lignes	CC6.3 Accès logique	A.9.4 Accès système	Art. 25 Protection des données dès la conception
pgaudit + logs layer	CC7.2 Supervision	A.12.4 Journalisation	Art. 30 Registre des traitements
object storage Webhook d'audit	CC7.2 Supervision	A.12.4 Journalisation	Art. 30 Registre
Journal d'événements Keycloak	CC7.2 Supervision	A.12.4 Journalisation	Art. 5 Responsabilité
Politiques réseau	CC6.6 Périmètres système	A.13 Sécurité des communications	Art. 32 Sécurité
TLS partout	CC6.7 Chiffrement	A.10 Cryptographie	Art. 32 Sécurité
Fonction akko_ai_pii()	CC8.1 Gestion des changements	A.18 Conformité	Art. 17 Droit à l'effacement
CronJobs de sauvegarde	CC7.5 Récupération	A.12.3 Sauvegarde	Art. 32 Sécurité
Helm RBAC (5 rôles)	CC6.2 Accès basé sur les rôles	A.9.2 Accès utilisateur	Art. 32 Sécurité

Chiffrement au repos

Chiffrement des PVC

Les PersistentVolumeClaims (PVC) Kubernetes peuvent être chiffrés au repos en configurant la classe de stockage sous-jacente :

• Fournisseurs cloud (EKS/AKS/GKE) : Activez le chiffrement sur la StorageClass en utilisant le KMS du fournisseur (ex. : chiffrement AWS EBS avec une CMK, Azure Disk SSE, GCP CMEK).
• Bare metal / k3s : Utilisez des volumes chiffrés LUKS ou un pilote CSI prenant en charge le chiffrement (ex. : Longhorn avec chiffrement activé).
• k3d (dev) : Non applicable -- le développement local ne nécessite pas de chiffrement au repos.

# Exemple : StorageClass AWS EBS chiffrée
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: encrypted-gp3
provisioner: ebs.csi.aws.com
parameters:
  encrypted: "true"
  kmsKeyId: "arn:aws:kms:eu-west-1:123456789:key/your-key-id"
  type: gp3

PostgreSQL TDE

Le chiffrement transparent des données (TDE) PostgreSQL est disponible via :

1. Extension pg_tde (PostgreSQL 16+) : Chiffre les fichiers de données des tables au niveau du stockage.
2. Chiffrement intégral du disque (recommandé) : Chiffrez le PVC sous-jacent comme décrit ci-dessus -- c'est plus simple et couvre le WAL, les fichiers temporaires et les index.

object storage Server-Side Encryption (SSE)

object storage prend en charge le SSE avec un KMS externe :

# votre overlay values production
storage:
  environment:
    STORAGE_KMS_KES_ENDPOINT: "https://kes.akko.local:7373"
    STORAGE_KMS_KES_KEY_NAME: "akko-storage-key"

Pour les déploiements air-gapped, utilisez object storage KES avec un backend Vault ou le keystore du système de fichiers intégré.

Immutabilité des journaux d'audit

Architecture

Logs des services --> Fluent Bit --> VictoriaLogs (akko-victorialogs:9428) --> PVC
                                             |
                              Transfert du flux d'audit --> stockage WORM externe

Journaux d'audit immuables

VictoriaLogs (le backend de logs par défaut) stocke sur un PVC local et n'est pas en soi un stockage WORM (écriture unique, lectures multiples). Pour l'immuabilité, transférez le flux d'audit vers une cible WORM externe (bucket S3 avec Object Lock, ou un SIEM compatible WORM). La chart marque les événements d'audit dans le flux {app="akko-audit"}, vous ne transférez donc que ce flux.

1. Créez un bucket object storage verrouillé :

   mc mb storage/akko-audit --with-lock
   mc retention set --default COMPLIANCE 365d storage/akko-audit
   

2. Transférez le flux d'audit vers ce bucket via une sortie Fluent Bit sur l'instance du forwarder SIEM (voir la page du forwarder SIEM pour la configuration de la sortie).

3. Résultat : Les journaux ne peuvent être ni supprimés ni modifiés pendant la période de rétention, satisfaisant les exigences SOC 2 CC7.2 et ISO 27001 A.12.4.

Rétention des données

Politiques de rétention configurables

La rétention VictoriaLogs est configurée via logs.victorialogs.retention dans helm/akko/charts/akko-observability/values.yaml (par défaut 14d). Le stockage sous-jacent est un PVC dimensionné par logs.victorialogs.storageSize (par défaut 50Gi) :

# votre overlay values production
akko-observability:
  logs:
    victorialogs:
      retention: 365d        # Conserver les journaux pendant 1 an
      storageSize: 200Gi     # Dimensionner le PVC pour la fenêtre de rétention

Pour une rétention par flux (périodes différentes selon le type de journal), transférez les flux concernés vers un stockage WORM dédié avec sa propre politique de rétention, comme montré dans la section immuabilité ci-dessus. VictoriaLogs mono-nœud applique une seule fenêtre de rétention globale.

Demandes de personnes concernées (RGPD)

Pour le RGPD Art. 17 (Droit à l'effacement) :

• Données utilisateur : Gérées dans PostgreSQL -- utilisez les instructions DELETE standard.
• Journaux d'audit : Si le stockage WORM est utilisé, les journaux contenant des données personnelles sont conservés pendant la période de conformité. Documentez cela dans votre politique de confidentialité comme base légale (Art. 6(1)(c) -- obligation légale).
• Détection des données personnelles : La fonction Trino akko_ai_pii() peut analyser les résultats de requêtes pour détecter les données personnelles avant l'export, contribuant à l'application de l'Art. 25 (Protection des données dès la conception).