Documentation

Modèle de continuité et d’intégrité

CONTINUITY-INTEGRITY-MODEL — v1.0.0

publicpubliév1.0.0Conditions LXKeys de documentation et d’interopérabilité
Identifiant du documentCONTINUITY-INTEGRITY-MODEL
Version1.0.0
S’applique àLXKeys.org
PRINCIPE

L’immutabilité canonique et la reprise opérationnelle sont distinctes. LXKeys ne réécrit pas l’historique finalisé du Registre pour rétablir le fonctionnement logiciel.

RUNTIME PARTAGÉ

Les données canoniques et les preuves de production sont stockées dans un runtime partagé séparé des répertoires de release applicative. Un rollback applicatif peut ainsi rétablir un code stable sans remonter silencieusement l’état des enregistrements canoniques.

SAUVEGARDES

Les paquets complets de reprise contiennent le snapshot de base, les éléments de stockage/preuves nécessaires à la reprise, la référence de configuration, les informations de version, un manifeste et des empreintes SHA-256. L’existence d’une sauvegarde ne constitue pas une preuve de reprise tant que les procédures de vérification et de restauration n’ont pas été testées.

CONTRÔLE DE RESTAURATION

LXKeys Control peut préparer un paquet de reprise et afficher les informations d’intégrité. La restauration privilégiée est volontairement exécutée via une CLI hôte auditée afin que l’application web ne reçoive aucun privilège Docker ou root sur l’hôte. La restauration valide le paquet, crée une sauvegarde préalable, applique la reprise puis exécute des contrôles d’intégrité après restauration.

AUDIT

Les actions applicatives sont inscrites dans l’Audit LXKeys. Les actions privilégiées de continuité en SSH sont également inscrites dans un registre externe contrôlé par root afin qu’une restauration de base ne puisse effacer le fait qu’une opération de reprise a eu lieu.

PÉRIMÈTRE PUBLIC

Ce document décrit uniquement les principes de contrôle. Les secrets, chemins privés de l’hôte, identifiants de reprise et procédures défensives détaillées ne sont pas publics.

AUDIT DE CONTINUITÉ
Les actions SSH privilégiées sont écrites dans un registre de continuité externe contrôlé par root et chaîné par SHA-256. Chaque entrée référence l’empreinte précédente et possède sa propre empreinte, ce qui permet de vérifier la continuité du journal indépendamment de la base applicative.