Charte de gestion des correctifs
Cette charte fixe la manière dont France Nuage applique les correctifs sur les services qu'elle manage. Elle dit qui corrige quelle couche, par quelle voie, dans quel délai cible et avec quelles vérifications. Elle prolonge notre politique de veille et de gestion des vulnérabilités, qui traite de la détection, et notre politique de gestion des changements, qui décrit le circuit vers la production. Elle se rattache aux contrôles A.5.7, A.8.8, A.8.19 et A.8.32 de la déclaration d'applicabilité.
Nos contrôles sont auto-évalués, alignés sur ISO/IEC 27001, non certifiés par un tiers à ce jour. Le statut de chaque mesure ci-dessous reflète cette auto-évaluation.
Cette charte décrit notre pratique d'exploitation et les objectifs que nous nous fixons. Les engagements contractuels figurent dans les conditions générales de service (article 9), l'accord de niveau de service et l'annexe de responsabilité partagée. Un bon de commande ou un contrat de service peut fixer des délais et des fenêtres propres. En cas d'écart avec cette charte, le contrat prime.
Objet et périmètre
La charte s'applique aux logiciels des services managés et à leurs bases de données, à la plateforme qui les porte (Kubernetes et système des nœuds) et aux dépendances de notre propre code. Elle couvre les versions correctives, les correctifs de sécurité et les mesures d'atténuation prises en attendant un correctif. Elle vaut pour les services hébergés dans nos datacenters comme pour ceux que nous manageons chez le client, dans la limite des couches que nous opérons.
Principes
- Chaque couche a un responsable désigné. Le partage entre France Nuage et le client est écrit avant la mise en service, couche par couche.
- Deux voies, un seul circuit. La voie courante et la voie de sécurité diffèrent par leur délai et passent par les mêmes contrôles.
- L'attente d'un correctif se couvre. Tant que l'éditeur n'a rien publié, une mesure d'atténuation documentée réduit l'exposition.
- Une mise à jour ne doit rien coûter au service. Sauvegarde préalable, version épinglée et déploiement progressif encadrent chaque opération.
- Un correctif se vérifie. Une vulnérabilité est close une fois la version corrigée déployée et constatée en production.
Partage des responsabilités
Le tableau suivant indique qui applique les correctifs, couche par couche, selon le lieu où tourne le service.
| Couche | Service hébergé chez France Nuage | Chez le client, cluster opéré par France Nuage | Chez le client, sur son Kubernetes ou ses machines virtuelles |
|---|---|---|---|
| Logiciel du service managé et sa base de données | France Nuage | France Nuage | France Nuage |
| Kubernetes et socle du cluster | France Nuage | France Nuage, avec son partenaire d'infrastructure Kubernetes | Client, France Nuage consultée |
| Machines, système hôte, réseau et stockage | France Nuage | Client | Client |
| Applications sources, intégrations et postes du client | Client | Client | Client |
Pour un service hébergé dans nos datacenters, l'annexe de responsabilité partagée fait foi. France Nuage y tient la version du logiciel et ses correctifs, et le client signale ses contraintes de compatibilité.
Pour un service managé chez le client, le bon de commande précise la répartition. Le client garde les couches qu'il fournit et nous ouvre les fenêtres d'exploitation dont une mise à jour a besoin.
Voie courante
Les versions correctives publiées par l'éditeur d'un logiciel sont déployées après vérification de leur stabilité. Les montées de version nous sont proposées automatiquement sous forme de demandes de fusion, que nous intégrons seulement si la chaîne d'intégration continue est verte.
Les opérations qui interrompent un service sont regroupées en maintenances planifiées. Nous les annonçons au moins 5 jours ouvrés à l'avance et nous les plaçons de préférence hors des heures ouvrées. Il n'existe pas de fenêtre récurrente, une maintenance est planifiée quand un lot de mises à jour le justifie.
Voie de sécurité
Un correctif de sécurité suit le même circuit que les autres, avec un délai cible et des étapes propres.
| Étape | Règle |
|---|---|
| Détection | Veille sur les CVE et les avis de sécurité de l'ensemble de la pile, appuyée par un agent de veille, par les signalements reçus sur le canal sécurité et par les mises à jour de dépendances automatisées (A.5.7). |
| Qualification | Vérification de la version réellement déployée sur chaque cluster, de la version corrigée indiquée par l'avis de l'éditeur et des conditions d'exploitation dans notre configuration. Le score CVSS est un élément de cette analyse. |
| Classement | Est critique une vulnérabilité exploitable à distance sans authentification ou signalée comme activement exploitée (conditions générales de service, article 9.2). |
| Correction | Tout correctif de sécurité disponible est appliqué dans les 72 heures qui suivent sa publication par l'éditeur. Ce délai est un objectif (A.8.8). |
| Sans correctif disponible | Mesure d'atténuation documentée (restriction de l'exposition, filtrage, correctif virtuel sur l'edge public, suspension temporaire), maintenue jusqu'à la publication du correctif. |
| Vérification | Clôture une fois la version corrigée déployée et constatée sur le service en production. |
Le délai de 72 heures est un objectif d'exploitation, sans garantie de résultat. Il devient un engagement lorsqu'un contrat de service l'inscrit, et le correctif est alors déployé dans la fenêtre convenue avec le client.
Pour une vulnérabilité critique, le correctif ou la mesure d'atténuation peut intervenir sans préavis et hors fenêtre de maintenance, comme le prévoit l'article 9.3 des conditions générales de service. L'astreinte peut être déclenchée en dehors des heures ouvrées pour ce motif.
Une version corrective qui échoue à la vérification de stabilité reste hors production. Une mesure d'atténuation prend alors le relais et le RSSI arbitre le report.
Ce délai de 72 heures porte sur l'application d'un correctif. La notification d'une violation de données personnelles suit ses propres règles, fixées par l'article 11 de l'accord de traitement des données.
Garde-fous d'une mise à jour
| Garde-fou | Règle |
|---|---|
| Sauvegarde préalable | Une montée de version qui migre le schéma d'une base est précédée d'une sauvegarde de cette base. |
| Version épinglée | La version cible est désignée par une étiquette fixe, sans recours à une étiquette flottante (A.8.19). |
| Circuit de changement | La mise à jour passe par une demande de fusion, les validations de la chaîne d'intégration continue et une étape de qualification avant la production (A.8.32). |
| Répétition | Une montée de version majeure dont la migration de base est irréversible est d'abord jouée sur une copie de la base, pour les services outillés. |
| Déploiement progressif | Les composants redondés (base répliquée, nœuds du cluster) sont mis à jour l'un après l'autre pour maintenir le service. Un service en instance unique redémarre brièvement. |
| Contrôle après déploiement | La version servie est vérifiée sur l'adresse publique du service, en plus de l'état du déploiement. |
| Urgence | Une mesure prise directement sur la production est signalée au contact sécurité et régularisée par une demande de fusion a posteriori. |
Annonce et niveaux de service
Une maintenance planifiée est annoncée au moins 5 jours ouvrés à l'avance. Lorsqu'une mesure conservatoire touche son service, le client en est informé dans les meilleurs délais (conditions générales de service, article 10.2).
Les maintenances planifiées annoncées dans ce délai et les opérations de correctif et d'atténuation de l'article 9 des conditions générales de service sont exclues du calcul de la disponibilité (accord de niveau de service, article 4).
Responsabilités
- Le RSSI (François-Guillaume Ribreau) est responsable de cette charte. Il qualifie les vulnérabilités critiques et arbitre les correctifs urgents comme les reports.
- L'astreinte SRE traite une vulnérabilité exploitée ou activement exploitable comme un incident, selon notre politique de gestion des incidents.
- L'auteur d'une mise à jour applique les garde-fous de cette charte et documente l'opération dans sa demande de fusion.
- Le client signale ses contraintes de compatibilité. Pour un service managé chez lui, il applique les correctifs des couches qu'il fournit.
Statut et trajectoire
Le circuit de changement par lequel passe chaque mise à jour est en place (A.8.32). La veille et la gestion des vulnérabilités techniques restent partielles (A.5.7, A.8.8), et la charte hérite de leurs limites :
- Délai de 72 heures. Cette charte le fixe comme objectif. Aucun indicateur ne mesure encore son respect.
- Détection. La détection CVE automatisée reste à câbler dans la chaîne d'intégration continue, et nous n'avons pas de source automatique pour les vulnérabilités activement exploitées.
- Garde-fous. Ils reposent sur nos procédures d'exploitation, sans contrôle automatique qui en vérifie le respect. La répétition sur copie est outillée pour une partie des services managés et reste à généraliser.
- Compte rendu. Nous ne publions pas de rapport des correctifs appliqués par service. Un contrat de service peut en prévoir un.
Revue
Cette charte est revue au moins une fois par an, et à chaque évolution des conditions générales de service ou de notre chaîne de livraison.
Dernière revue : 11 octobre 2026.
Voir aussi
- Politique de veille et de gestion des vulnérabilités (la veille et la qualification en amont de cette charte)
- Politique de gestion des changements (le circuit par lequel un correctif atteint la production)
- Politique de sauvegardes (les sauvegardes sur lesquelles s'appuie une mise à jour)
- Politique de gestion des incidents (le traitement d'une vulnérabilité exploitée)
- Déclaration d'applicabilité (le statut des contrôles A.5.7, A.8.8, A.8.19 et A.8.32)
- Politique de divulgation responsable (comment nous signaler une vulnérabilité)