Chapitre 9 -- Procedures operationnelles¶

Statut du chapitre : DRAFT Derniere mise a jour : 2026-02-26 Contract : CC-09 | Story : PD-249

9.1 Exploitation quotidienne¶

L'exploitation du SAE ProbatioVault repose sur une supervision continue des composants critiques : services applicatifs, infrastructure de stockage, modules cryptographiques et chaine de preuve. L'objectif est de detecter toute degradation avant qu'elle n'affecte la disponibilite ou l'integrite probatoire du systeme.

Stack de monitoring¶

Le systeme de supervision repose sur une stack open-source unifiee, deployee sur l'infrastructure OVH (VPS DEV : 51.68.126.160) :

Le Node Exporter utilise un textfile collector (/var/lib/node_exporter/textfile_collector/) permettant d'exposer des metriques personnalisees (resultats de tests d'integration, indicateurs metier) sans modification du code applicatif.

Indicateurs cles de performance (KPI)¶

Les indicateurs suivants constituent le socle minimal de surveillance du SAE. Chaque indicateur est associe a un seuil d'alerte qui declenche une notification vers les canaux de communication de l'equipe d'exploitation.

Tableaux de bord Grafana¶

L'equipe d'exploitation dispose de tableaux de bord dedies dans Grafana, organises par domaine :

• Dashboard Infrastructure : metriques systeme (CPU, RAM, disque, reseau), sante des services (PostgreSQL, Redis, NGINX, Node.js), etat des certificats TLS.
• Dashboard Stockage : volumes OVH S3 et AWS Glacier, taux de replication CRR, objets sous Object Lock, couts estimes mensuels.
• Dashboard API : latence par endpoint, taux d'erreur, debit de requetes, distribution des codes HTTP.
• Dashboard Tests d'integration : resultats des suites de tests automatises, taux de succes, historique des executions (via textfile collector).
• Dashboard Audit et Conformite (prevu) : metriques de conformite operationnelle, evenements d'audit, alertes de securite.

Alertes et notifications¶

Les alertes Prometheus sont configurees selon trois niveaux de severite :

Les alertes critiques declenchent un cycle d'astreinte avec escalade automatique si aucune prise en charge n'est enregistree dans le delai cible.

9.2 Maintenance et mises a jour¶

La maintenance du SAE couvre quatre domaines principaux : la rotation des cles cryptographiques, le renouvellement des certificats, l'application des correctifs de securite et la mise a jour des dependances logicielles. Chaque operation est tracee dans la piste d'audit append-only (cf. Ch. 7).

9.2.1 Rotation des cles HSM¶

La rotation des cles de signature HSM est une operation planifiee qui garantit le renouvellement periodique du materiel cryptographique sans interruption de service. Le mecanisme de key wrapping permet une rotation transparente pour les utilisateurs.

Procedure de rotation K_master HSM :

1. Preparation : Generer la nouvelle cle (pv-master-signing-YYYY) dans le cluster CloudHSM. Le prefixe pv-master-* identifie les cles de production ; les cles ephemeres de test utilisent le prefixe pv-test-*.
2. Basculement : Mettre a jour la reference de cle active dans HashiCorp Vault (kv/app/hsm-config). Le backend lit dynamiquement la cle active a chaque operation de signature.
3. Verification : Effectuer une signature de test et verifier la chaine complete (signature + horodatage + verification).
4. Archivage : L'ancienne cle passe en mode lecture seule dans le HSM. Elle reste disponible pour verifier les signatures emises pendant sa periode d'activite.
5. Trace : L'evenement de rotation est journalise dans la piste d'audit avec les metadonnees : identifiant cle precedente, identifiant nouvelle cle, date, operateur.

La rotation des cles utilisateur (K_master_user) suit un mecanisme different, decrit au chapitre 3 : le changement de mot de passe re-chiffre l'enveloppe du keystore sans modifier les cles de derivation documentaire (K_doc), evitant ainsi tout re-chiffrement des archives.

9.2.2 Renouvellement des certificats TSA¶

L'horodatage qualifie repose sur un service TSA (Time Stamping Authority) conforme RFC 3161. Les certificats TSA ont une duree de validite limitee et doivent etre renouveles avant expiration.

Procedure de renouvellement :

1. Surveillance : Un job planifie verifie mensuellement la date d'expiration du certificat TSA actif.
2. Renouvellement : Obtenir le nouveau certificat aupres du prestataire TSA et verifier la chaine de confiance (certificat racine, intermediaires).
3. Deploiement : Mettre a jour le certificat dans la configuration backend (HashiCorp Vault, chemin kv/app/tsa-config).
4. Validation : Emettre un jeton d'horodatage de test et verifier la validite de la reponse TSA.
5. Continuite : Les jetons d'horodatage emis avec l'ancien certificat restent valides tant que le certificat etait valide au moment de l'emission.

9.2.3 Correctifs de securite¶

Les correctifs de securite sont appliques selon un calendrier guide par la criticite des vulnerabilites identifiees.

Principes directeurs :

• Les correctifs sont d'abord appliques sur l'environnement de staging, puis deployes en production apres validation du pipeline CI/CD (lint, tests, Sonar).
• Aucun correctif n'est applique directement en production sans passage par le pipeline automatise.
• Chaque correctif est documente dans le changelog de l'infrastructure (Terraform/Ansible) ou du backend (NestJS).
• Les Quality Gates Sonar ne sont jamais contournees : si un patch introduit une regression, le code est corrige, pas les regles.

9.2.4 Mise a jour des dependances¶

La gestion des dependances logicielles suit un processus de verification continu.

Regle de compatibilite : Les mises a jour de dependances sensibles (cryptographie, ORM, framework) font l'objet d'une revue dediee avant integration. Les dependances ESM-only identifiees sont documentees dans le plan d'implementation de chaque story pour eviter les incompatibilites de runtime.

9.3 Gestion des incidents¶

La gestion des incidents SAE suit un processus structure en cinq phases, concu pour minimiser l'impact sur la disponibilite et l'integrite probatoire du systeme. Chaque incident est documente dans un rapport post-mortem et les enseignements sont integres dans les procedures operationnelles.

9.3.1 Classification des incidents¶

Les incidents sont classes selon deux axes : la severite (impact sur le service) et la nature (domaine fonctionnel affecte).

Severite :

Nature :

9.3.2 Procedure de reponse aux incidents¶

La procedure de reponse suit cinq phases sequentielles. La traçabilite de chaque phase est assuree par la piste d'audit append-only et par les rapports post-mortem archives.

Diagramme : Procedure de gestion d'incident SAE¶

graph TB
    DET["Detection<br/>Alertes Prometheus / Grafana"]
    CLA["Classification<br/>Severite S1-S4 + Domaine"]
    CON["Confinement<br/>Isolation du composant affecte"]
    ERA["Eradication<br/>Correction de la cause racine"]
    RES["Restauration<br/>Retour au service nominal"]
    POST["Post-mortem<br/>Rapport + enseignements"]
    VER["Verification integrite<br/>Controle chaine de preuve"]

    DET --> CLA
    CLA --> CON
    CON --> ERA
    ERA --> RES
    RES --> VER
    VER --> POST

    style DET fill:#e8f5e9,stroke:#2e7d32,color:#000
    style CLA fill:#fff3e0,stroke:#ef6c00,color:#000
    style CON fill:#fce4ec,stroke:#c62828,color:#000
    style ERA fill:#fce4ec,stroke:#c62828,color:#000
    style RES fill:#e3f2fd,stroke:#1565c0,color:#000
    style VER fill:#f3e5f5,stroke:#6a1b9a,color:#000
    style POST fill:#e0f2f1,stroke:#00695c,color:#000

Legende : Le diagramme illustre la sequence de traitement d'un incident SAE, depuis la detection automatisee jusqu'au post-mortem. La phase de verification d'integrite est specifique au contexte probatoire : elle garantit qu'aucune archive n'a ete alteree pendant l'incident.

Phase 1 -- Detection :

• Les alertes Prometheus et les tableaux de bord Grafana constituent la premiere ligne de detection.
• Les logs structures (format JSON, horodates UTC) fournissent le detail des evenements.
• Les utilisateurs peuvent signaler un incident via le canal Slack dedie ou par escalade directe.
• Delai cible de detection : < 5 min pour les incidents S1/S2 (alertes automatisees).

Phase 2 -- Classification :

• L'operateur d'astreinte evalue la severite (S1 a S4) et identifie le domaine fonctionnel.
• Pour les incidents S1 (integrite probatoire), l'escalade vers le responsable securite est immediate et obligatoire.
• Un identifiant unique d'incident est cree et un canal de communication dedie est ouvert (Slack thread ou bridge).

Phase 3 -- Confinement :

• Isoler le composant defaillant pour empecher la propagation de l'impact.
• En cas de compromission cryptographique suspectee : revocation immediate de la cle concernee dans le HSM et suspension des operations de signature.
• En cas d'indisponibilite stockage : activation du mode degrade (file d'attente des operations en base PostgreSQL, reprise automatique apres retour du service).

Phase 4 -- Eradication :

• Identifier et corriger la cause racine (patch, configuration, rollback).
• Toute correction suit le pipeline CI/CD standard : lint, tests, Sonar, deploiement staging puis production.
• Aucune modification directe en production n'est autorisee hors du pipeline.

Phase 5 -- Restauration et verification :

• Retour au service nominal et verification que tous les indicateurs KPI sont dans les seuils.
• Verification specifique SAE : controle d'integrite des archives (empreintes SHA3-256, etat Object Lock, statut de replication CRR).
• Confirmation que la piste d'audit est complete et coherente pour la periode de l'incident.

Post-mortem :

Chaque incident S1 ou S2 fait l'objet d'un rapport post-mortem structure :

Les rapports post-mortem sont archives dans la piste d'audit append-only et sont accessibles aux auditeurs dans le cadre des controles de conformite.

9.3.3 Matrice d'escalade¶

9.4 Plan de continuite et de reprise d'activite (PCA/PRA)¶

Le plan de continuite du SAE ProbatioVault s'appuie sur l'architecture multi-cloud (OVH + AWS) pour garantir la resilience face aux scenarios de panne. La conception du stockage hybride (cf. Ch. 4) fournit une fondation naturelle pour le basculement et la restauration.

9.4.1 Objectifs de continuite¶

9.4.2 Scenarios de panne et strategies de basculement¶

Scenario 1 -- Panne OVH S3 (stockage actif) :

Scenario 2 -- Panne AWS S3 (stockage COLD + compliance) :

Scenario 3 -- Panne complete OVH (VPS + S3) :

Scenario 4 -- Panne regionale AWS Paris (eu-west-3) :

9.4.3 Restauration depuis Glacier Deep Archive¶

La restauration d'archives depuis Glacier Deep Archive est une operation couteuse en temps et en cout, reservee aux scenarios de reprise apres sinistre ou aux demandes ponctuelles de restitution.

Procedure de restauration :

1. Identification : Identifier les objets a restaurer via les metadonnees en base PostgreSQL (UUID document, cle S3, version).
2. Demande de restauration : Emettre une requete RestoreObject sur le bucket Glacier (Paris ou Frankfurt selon le scenario).
3. Attente : Le delai de restauration depend du tier choisi (Standard : 12 h, Bulk : 48 h).
4. Recuperation : Une fois l'objet temporairement disponible en S3 Standard, le telecharger et le placer dans le bucket HOT OVH.
5. Verification : Verifier l'integrite du document restaure par comparaison de l'empreinte SHA3-256 avec la valeur enregistree en base.
6. Nettoyage : La copie temporaire en S3 Standard expire automatiquement selon la duree configuree.

9.4.4 Tests du plan de continuite¶

Le plan de continuite fait l'objet de tests reguliers pour valider l'operationnalite des procedures de basculement.

9.4.5 Resilience des composants critiques¶

Le tableau ci-dessous synthetise les mecanismes de resilience de chaque composant SAE :

9.5 Synthese des procedures¶

Le tableau ci-dessous recapitule les procedures operationnelles avec leur frequence et leur responsable :

References¶

• Architecture de stockage : Ch. 4 -- Stockage et immutabilite (PD-4, PD-5, PD-6)
• Modele cryptographique : Ch. 3 -- Modele de securite (PD-7, PD-8, PD-33, PD-34)
• Tracabilite : Ch. 7 -- Tracabilite et audit (PD-19, PD-37)
• Feuille de route observabilite : Ch. 10 -- Feuille de route (PD-196 EPIC monitoring)
• Sources infrastructure : ProbatioVault-infra/docs/reference/infra/operations/, ProbatioVault-infra/docs/architecture/storage/
• Normes de reference : NIST SP 800-57 (rotation des cles), NIST SP 800-38F (key wrapping), RFC 3161 (horodatage), ISO 14641:2018 section 7 (exploitation du SAE), NF Z42-013:2020 section 8 (procedures d'exploitation)