Continuité des données
Ce qui a été observé, ce qui reste partiel et ce qui interdit encore une restauration de production.
Un statut décrit toujours le périmètre exact de la preuve, jamais une impression générale de maturité.
Le snapshot ferme les sources et les contrats; le lab systemd éprouve les coupures locales; le reaper provider reste simulé sans prétendre à une exécution cloud réelle.
Le snapshot recovery ferme 126 sources au digest c25ee67a0a9302cf532a546a33c895a3b27dfc6a7121efa1c3ef5ad8b2a27e6f et au digest d’entrées 5c64e87449a54a644cb8cf26c12fc65999c81ab2b3ebee8a01be832153d05902. La suite telephony-backup-restore passe 48/48 tests, dont 42 scénarios hostiles internes; les quatre suites ciblées passent 81/81. Cette preuve porte sur le snapshot et les contrats, pas sur un service en production.
Le rapport brut v6 historique utilise une VM QEMU x86_64 émulée et jetable sous PID 1 systemd. Deux arrêts forcés enchaînent verrou persistant, adoption stale, finalizer, reprise synthétique positive, puis refus fail-closed d’un reçu corrompu. Son source-lock archivé reste la provenance exacte de ce rapport; le nouveau snapshot ne le réécrit pas. Les artefacts restent locaux, non signés et non authentifiables sans ancre externe.
Avec une CLI Scaleway factice, un canari déjà expiré doit disparaître avant toute ressource facturable, par un run réussi strictement postérieur, puis rester absent sur trois observations. Le serveur est supprimé sans cascade avant les UUID exacts du groupe de sécurité, du volume et de l’IP. Une course de rattachement est refusée; un GET direct vérifie les UUID mémorisés lorsque les listes sont vides.
Périmètre d’inventaire: l’état vide observe seulement les serveurs, groupes de sécurité, volumes et IP du Project et de la zone sélectionnés. Il ne couvre ni les autres zones ni les autres familles de ressources. Un Project dédié et une fenêtre d’écritures IAM exclusive restent des hypothèses d’exploitation, pas des faits attestés.
Coût et cycle de vie: le plafond de 0,10 EUR couvre seulement le DEV1-M, son IPv4 et son volume de 40 Go; le Job partagé est exclu. Le coût compute court jusqu’à serverDeletedAt; les coûts IPv4 et volume jusqu’à billableAttachmentsAbsentAt. Le workspace temporaire est créé seulement après readiness du reaper et armement du nettoyage persistant, puis supprimé après finalisation et absence attestée des ressources.
Harnais et coupures: tous les NAVY_SCALEWAY_TEST_* sont refusés avant toute commande provider hors du harnais hermétique exact; le catalogue synthétique ne peut pas activer un run réel. Trois arrêts SIGKILL prouvent causalement le maintien du nettoyage aux frontières du workspace.
Décision: la contre-revue ne trouve aucun P0/P1. Un essai Scaleway payant borné est GO seulement sous Node 22.23.2, avec Project et profil dédiés et opérateur local de confiance. P2 ouverts: vérificateur statique lexical et TOCTOU local théorique, même UID, entre hash et exécution. Le même parseur traverse deux pages synthétiques, mais aucune API publique réelle, aucun vrai Job/provider cloud ni perte complète du contrôleur n’a été exécuté. Aucun RPO/RTO réel. Production NO-GO.
Chaque gate a une autorité, une preuve à produire et un critère de sortie observable.
6 gates affichées.
Acquis: archive OCI fermée, digests et source liés, keeper durci en lab local.
Manque: signature externe, provenance des paquets, SBOM, règle de vulnérabilité et build réellement offline.
Sortie: une release signée vérifie image, sources, SBOM et seuil CVE sur un runner indépendant; une reconstruction offline reproduit l’identité attendue.
Acquis: adoption atomique du propriétaire stale, révocation de l’ancien token, finalizer committed-success, reprise synthétique et refus d’un reçu corrompu sont enchaînés après deux arrêts forcés sous systemd.
Limite: la preuve utilise une VM x86_64 émulée et jetable, une application synthétique, une release non signée et un arbre de travail sale. Elle ne simule ni perte électrique physique ni écriture de stockage déchirée.
Sortie production: rejouer la même séquence sur un hôte cloud amd64 natif candidat avec release signée, vraie application et fautes de stockage contrôlées.
Acquis: restauration synthétique isolée et rollbacks locaux.
Manque: archive candidate représentative, stockage hors site, coupure base et enregistrements, RPO/RTO, PITR et appel de contrôle.
Sortie: un environnement candidat restaure sans toucher la production, respecte les objectifs approuvés et repasse les contrôles applicatifs, média et d’intégrité.
Acquis: scripts et rapports locaux content-free.
Manque: runner explicitement autorisé pour ce dépôt, identité isolée, policy de secrets, artefacts signés et rétention.
Sortie: la fermeture de sources et les labs approuvés s’exécutent sur le runner dédié avec permissions minimales, résultat signé et échec fail-closed.
Acquis: corruption refusée sans autorité, réparation explicite réussie avec reçu durable, reprise d’un reçu pending, suppression bornée de deux images et conservation de l’image courante ainsi que d’une image superseded sont observées.
Limite: le bundle et les images proviennent d’une release locale non signée dans la VM jetable.
Sortie production: rejouer le repair et la rétention depuis une release signée, avec SBOM, décision CVE, inventaire avant/après et artefacts attestés sur l’hôte candidat.
Acquis: les responsabilités techniques sont nommées par fonction.
Manque: titulaires approuvés, RPO/RTO, périmètre des données, clés de reprise, stockage hors site et décision de retour au service.
Sortie: chaque autorité accepte les objectifs, le runbook, les clés, le plan de communication et le résultat du restore candidat.
La chaîne reste fermée tant qu’une étape ne possède pas la preuve du même artefact et de la même opération.
Signer image et sources, joindre SBOM, décision CVE et mode de reconstruction offline.
Release root-owned, kit hors checkout, bundle OCI validé, keeper inerte et masque persistant.
Les services tiennent un lease partagé; restore/recovery exige l’exclusif et bloque tout démarrage concurrent.
La chaîne locale enchaîne verrou persistant, adoption stale, finalizer, reprise synthétique et refus fail-closed d’un reçu corrompu après deux arrêts forcés. La reproduction sur hôte cloud natif candidat reste ouverte.
Contrôler intégrité, RPO/RTO, application, média et appel sur un environnement candidat représentatif.
Le runner autorisé signe le résultat; les owners approuvent ou refusent explicitement le retour en service.
Les objectifs existent comme politiques; aucune restauration souveraine n’est une preuve acquise.
| État | Autorité | Reprise cible | Statut réel |
|---|---|---|---|
| Sessions et configuration | PostgreSQL cible, tenant-scoped | Backup chiffré séparé, RPO/RTO, restauration synthétique vérifiée | Schémas et policy; aucune base ou restauration cloud |
| Enregistrements autorisés | Coffre objet conformité | Versioning, SSE-KMS, rétention approuvée et cleanup synthétique fail-safe | Module et recette; aucun bucket ni recette réelle |
| Audit Navy / VoiceBot | Ledgers séparés et corrélés | Append-only, scellement, réplication et export contrôlé | Contrats/code partiels; aucun registre immuable |
| Preuves de promotion | Release assurance | Artefact immuable par commit/digest/gate/approbateur | Enveloppes locales content-free; aucune attestation externe |
Approfondir: bundle de reprise hors ligne · gates de promotion · autorités de décision.