SEAL — le périmètre cryptographique de confiance

01Le périmètre cryptographique de confiance #sec_af09b142

SEAL est le service qui concentre les opérations cryptographiques sensibles de REVIEWIT : conserver les références de secrets, dériver des valeurs, signer des sceaux, gouverner les générations de clés et autoriser leur destruction. Les modules métier lui demandent une opération ; ils n'obtiennent pas la matière secrète qui la rend possible.

Cette frontière évite que chaque application invente son propre stockage de clés, ses formats de reçus et ses règles de rotation. Le coffre sous-jacent protège les secrets ; SEAL ajoute la doctrine REVIEWIT : isolation par tenant, capacités autorisées, cycle de vie, preuve d'opération et état d'autorité.

SEAL ne décide pas d'une certification, d'un droit ou d'une durée de rétention. Il applique une opération cryptographique préalablement autorisée et retourne un résultat ou un reçu vérifiable.

02La clé ne sort pas, le résultat oui #sec_3b5f0896

Un consommateur manipule une référence stable, jamais un secret en clair. Pour signer une tête d'Audit Trail, SEAL fait utiliser la clé dans son périmètre et retourne la signature. Pour le sign-off, il dérive les aléas nécessaires aux preuves d'inclusion sans restituer le secret d'attestation.

Cette règle réduit fortement les chemins d'exposition : aucune clé privée ne voyage dans la mémoire d'une application métier, dans ses paramètres ou dans ses journaux. Elle facilite aussi le changement de fournisseur de coffre, puisque les consommateurs dépendent d'une capacité et non d'une API propriétaire.

Les opérations sont isolées par usage. Une clé de sceau d'audit, une clé de signature documentaire et un secret de dérivation d'attestation appartiennent à des domaines différents. Réutiliser une même clé parce que les trois opérations « signent quelque chose » mélangerait des responsabilités et des durées incompatibles.

03Générations, rotation et destruction #sec_52bf3522

Un secret possède une classe et des générations. La politique de classe décide si une rotation est permise, à quelle cadence et avec quelles validations.

Certaines valeurs sont volontairement non rotatives. Le secret qui a participé à un engagement d'attestation doit rester stable : le remplacer rendrait impossibles les preuves futures. Une nouvelle génération peut servir les attestations suivantes, mais l'ancienne reste disponible tant qu'une attestation vivante en dépend.

La destruction suit la règle inverse : elle doit être facile à demander lorsqu'elle est légitime, difficile à annuler et impossible tant qu'une dépendance protégée subsiste. L'état d'autorité empêche un retour silencieux à une génération révoquée ou détruite.

SEAL distingue ainsi la durée métier et le cycle cryptographique. La rétention peut rendre une génération éligible à la destruction ; elle ne la détruit pas directement ni ne contourne les contrôles de gouvernance.

04Autoriser l'opération, pas seulement l'appelant #sec_6d9b6b65

Le contrôle porte sur l'identité du demandeur, le tenant, la capacité demandée et l'état courant de l'autorité. Une application autorisée à dériver une valeur ne reçoit pas automatiquement le droit de signer, de faire tourner ou de détruire une clé.

Les actes humains les plus sensibles peuvent exiger une élévation TrustGate et une double validation. Les opérations de service répétitives suivent un régime adapté à leur nature, avec des identités machines, des capacités minimales et des reçus. Une opération non mutante n'est pas artificiellement traitée comme une opération de gouvernance, mais elle reste bornée et observable.

Les rôles produit ne suffisent pas à administrer le compte d'autorité. La séparation des pouvoirs s'étend aux politiques IAM et à la chaîne d'exploitation : la personne capable d'altérer le stockage de preuve ne doit pas, seule, pouvoir produire un sceau qui masquerait cette altération.

05Reçus, reprise et état dégradé #sec_40421e1a

Les opérations qui modifient l'état sont idempotentes. Une demande « obtenir ou créer » portant la même identité logique retrouve la même génération ; un redémarrage ne fabrique pas deux secrets concurrents. Les reçus permettent au consommateur et à l'audit de relier la demande, la décision d'autorité et le résultat sans exposer la valeur secrète.

L'audit reste proportionné. Une dérivation portant sur des milliers d'éléments est tracée par lot ou par tranche, pas par valeur élémentaire. Le système prouve qu'une construction a eu lieu sans submerger la piste.

En situation dégradée, SEAL échoue de manière fermée pour une opération cryptographique qu'il ne peut pas garantir. Le module appelant peut conserver un état de reprise, mais ne doit jamais présenter comme scellé ou signé ce qui ne l'est pas. Les opérations de lecture ou de service déjà explicitement autorisées ne deviennent pas, pour autant, des portes de contournement de la gouvernance.

06En résumé #sec_f94675c2

SEAL donne à REVIEWIT une seule frontière pour protéger, autoriser et prouver ses opérations cryptographiques. Les applications utilisent des capacités, pas des clés ; les générations suivent leurs dépendances ; les opérations sensibles respectent la séparation des pouvoirs ; et aucun résultat n'est présenté comme scellé lorsque l'autorité n'a pas pu le garantir.