Chiffrement, gestion des clés et destruction des données

Périmètre de ce document

Cette page est la référence cryptographique canonique de Zeuslock. Elle s'adresse aux architectes sécurité qui mènent une évaluation fournisseur, aux RSSI qui préparent une revue de risque et aux auditeurs qui mappent nos contrôles vers SOC 2 Type II, ISO 27001 et le RGS. Chaque algorithme, région et cadence de rotation listés ici reflète la configuration réellement déployée en production. Pour toute précision, votre équipe de compte peut fournir sur demande les identifiants de clés KMS, des extraits CloudTrail et le DPA.

Notre modèle de menace suppose un attaquant sophistiqué et bien financé, capable d'accéder ponctuellement aux chemins réseau, ainsi que la possibilité d'une contrainte légale exercée sur les fournisseurs cloud. Les contrôles ci-dessous visent à maintenir la confidentialité des données même dans ces scénarios, et à donner aux clients Édition Souveraine la capacité de révoquer notre accès à tout moment.

Chiffrement en transit

Tout le trafic entre l'extension de navigateur, l'agent de bureau, la CLI et la Console Opérateur se termine sur TLS 1.3 exclusivement. Les protocoles antérieurs (TLS 1.0, 1.1, 1.2) sont désactivés au niveau de l'équilibreur. La sélection des suites suit le profil Mozilla Modern : uniquement des suites AEAD, ECDHE pour la Perfect Forward Secrecy, et HTTP/2 comme protocole applicatif.

L'en-tête Strict-Transport-Security est servi sur chaque réponse avec max-age=31536000; includeSubDomains; preload, et zeuslock.ai figure dans la liste de préchargement HSTS de Chromium. L'agent de bureau applique en plus le pinning de certificat. Nous utilisons plusieurs emplacements de pin avec des fenêtres de validité qui se chevauchent, afin qu'une rotation de certificat ne bloque jamais un agent sur le terrain : les opérateurs peuvent déployer un nouveau certificat plusieurs semaines avant de retirer l'ancien pin.

Profil TLS en un coup d'œil

Chiffrement au repos

Toute donnée persistée est chiffrée en AES-256-GCM. Chaque tenant client est cloisonné au niveau du stockage ; aucune requête ne peut franchir la frontière d'un tenant, même avec des privilèges base de données élevés. Les sauvegardes sont écrites dans un compte AWS distinct, chiffrées avec une clé KMS dédiée et verrouillées en région UE. La réplication interrégionale est désactivée par défaut et n'est activée qu'à la demande explicite du client.

Matrice de chiffrement

Gestion des clés

Tenants standard : KMS géré par Zeuslock

Les plans standard utilisent AWS KMS en eu-west-3 (Paris). Les clés maîtres (CMK) sont automatiquement renouvelées tous les 365 jours ; une rotation à la demande est possible via notre API interne et se propage à toutes les ressources chiffrées en quelques minutes. Les clés de données sont générées par objet via GenerateDataKey ; aucune DEK n'est réutilisée d'un client à l'autre ni même d'un incident à l'autre.

L'accès aux opérations administratives KMS est soumis à un double contrôle : aucun ingénieur seul ne peut déchiffrer du matériel client ni désactiver une clé. Les politiques de clé restreignent kms:Decrypt au seul rôle de service production, et l'accès bris de glace exige deux SRE plus un responsable sécurité, chacun avec son propre jeton matériel. Chaque appel Encrypt, Decrypt ou GenerateDataKey émet un événement CloudTrail incluant le principal appelant, l'IP source, le contexte de chiffrement et l'ID de requête.

Édition Souveraine : clés gérées par le client (BYOK)

Les clients Édition Souveraine fournissent une clé AWS KMS hébergée dans leur propre compte AWS. Zeuslock reçoit un grant inter-comptes — jamais une copie de la clé. Le grant est limité aux opérations strictement nécessaires (Decrypt, GenerateDataKey) et exclut explicitement les verbes destructeurs. Si le client révoque le grant ou désactive la clé, Zeuslock perd immédiatement l'accès et tout le matériel chiffré — incidents, instantanés de payload, journaux d'audit — devient illisible.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "ZeuslockProdGrant",
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::ZEUSLOCK_PROD_ACCOUNT_ID:role/zeuslock-data-plane"
      },
      "Action": [
        "kms:Decrypt",
        "kms:GenerateDataKey",
        "kms:GenerateDataKeyWithoutPlaintext",
        "kms:DescribeKey"
      ],
      "Resource": "*",
      "Condition": {
        "StringEquals": {
          "kms:ViaService": "dynamodb.eu-west-3.amazonaws.com",
          "kms:EncryptionContext:tenant_id": "${aws:PrincipalTag/TenantId}"
        }
      }
    },
    {
      "Sid": "DenyDestructive",
      "Effect": "Deny",
      "Principal": {
        "AWS": "arn:aws:iam::ZEUSLOCK_PROD_ACCOUNT_ID:role/zeuslock-data-plane"
      },
      "Action": [
        "kms:ScheduleKeyDeletion",
        "kms:DisableKey",
        "kms:PutKeyPolicy",
        "kms:RevokeGrant"
      ],
      "Resource": "*"
    }
  ]
}

Le contexte de chiffrement lie chaque opération à un identifiant de tenant précis : même un rôle de plan de données compromis ne peut donc pas déchiffrer les données d'un autre client. Nous recommandons de reprendre cette politique telle quelle, en n'adaptant que l'ARN du principal et le schéma de tag tenant.

Cadence de rotation

• Clés de données (DEK) : rotation automatique par objet via GenerateDataKey. Aucune réutilisation.
• Clés maîtres (CMK) : rotation annuelle par AWS KMS ; réchiffrement immédiat des en-têtes, réchiffrement paresseux des charges utiles.
• À la demande : tout client peut demander une rotation hors cycle via le support ou l'API de gestion ; nous la terminons sous 24 heures et la confirmons avec un extrait CloudTrail.
• Certificats TLS : renouvelés tous les 90 jours ; les emplacements de pin se chevauchent d'au moins 30 jours.

Gestion interne des secrets

Aucun secret en clair ne réside dans le code source, les images de conteneur, les variables d'environnement ou les journaux CI. Les identifiants de production sont stockés dans AWS Secrets Manager et récupérés à l'exécution via des jetons de fédération de courte durée (TTL 1 heure) émis par AWS STS. Les clés d'accès IAM statiques sont interdites en production et bloquées par une Service Control Policy.

Les développeurs ne reçoivent jamais de secrets de production sur leur poste. Le développement local utilise des comptes bac à sable isolés avec des données synthétiques, et les hooks pre-commit ainsi que la CLI Zeuslock elle-même scannent chaque commit à la recherche de motifs d'identifiants avant le push.

Garanties de destruction

Droit à l'effacement (RGPD article 17)

Une demande d'effacement soumise via la Console Opérateur ou l'API REST déclenche une suppression définitive sous 24 heures sur le plan de données vivant. Les mêmes identifiants sont ensuite purgés des sauvegardes glissantes sous 30 jours, conformément à la fenêtre de rétention. Nous émettons un certificat de suppression signé à l'achèvement.

Sortie d'un client

À la résiliation d'un contrat, nous procédons d'abord à un broyage cryptographique : la clé maîtresse propre au tenant est supprimée, ce qui rend mathématiquement irrécupérable, en quelques secondes, tout blob chiffré — y compris les sauvegardes en cours. La destruction physique des objets de stockage sous-jacents est ensuite planifiée et achevée dans les 30 jours. Les clients Édition Souveraine peuvent réaliser ce broyage eux-mêmes en supprimant leur clé KMS ; nous n'avons aucun moyen de le bloquer ou de le retarder.

Rétention des sauvegardes

Les sauvegardes sont conservées sur une fenêtre glissante de 30 jours. Les instantanés plus anciens sont écrasés sur place ; nous n'archivons jamais les données client vers des paliers de stockage froid sans accord explicite.

Audit et transparence

Chaque opération cryptographique — handshakes TLS, appels KMS, récupérations de secrets — génère un journal structuré transmis à notre SIEM. Les enregistrements d'événements KMS sont conservés un an et peuvent être exportés vers un client sur demande, sous forme de dump JSON CloudTrail ou de réconciliation CSV. Les clients Édition Souveraine voient ces événements directement dans leur propre CloudTrail, sans intermédiaire.

Nos contrôles sont alignés sur SOC 2 Type II (Security, Availability, Confidentiality) et l'Annexe A d'ISO 27001. Nous sommes audités chaque année ; le dernier rapport et sa lettre passerelle sont disponibles sous NDA.

FAQ

Zeuslock peut-il déchiffrer mes données sur réquisition d'autorités américaines ?

Édition Souveraine : non. Nous ne détenons pas la clé. Nous pouvons remettre un texte chiffré que nous sommes incapables de lire, et nous vous notifierons sauf interdiction légale. Plan standard : les données sont hébergées en France et traitées sous droit français. Nous contestons les demandes extraterritoriales, exigeons le passage par la procédure d'entraide judiciaire (MLAT) et publions un rapport de transparence annuel.

Quels algorithmes de hachage utilisez-vous pour les identifiants sensibles ?

SHA-256 avec un sel par tenant pour tout usage cryptographique (recherches déterministes, empreintes, déduplication d'identifiants sensibles). Nous utilisons BLAKE3 pour la déduplication non cryptographique de gros volumes lorsque la vitesse prime et que les collisions adversariales ne font pas partie du modèle de menace. MD5 et SHA-1 sont proscrits dans tout nouveau code.