Politique de cryptographie
Cette politique décrit quand et comment France Nuage utilise la cryptographie pour protéger les données confiées par ses clients et les secrets de sa plateforme. Elle décline, sur le volet cryptographique, les principes de notre politique de sécurité de l'information et couvre les contrôles A.8.24, A.7.10 et A.7.14 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.
Objet et périmètre
La politique s'applique à tous les flux et à tous les stockages du périmètre du SMSI (console d'administration, API, interface en ligne de commande nuage, communications entre nœuds, secrets d'infrastructure, sauvegardes et supports physiques de nos trois datacenters).
Elle décrit ce que nous chiffrons et avec quoi. Elle ne prétend pas couvrir davantage. Le chiffrement au repos s'applique côté stockage et sur les secrets applicatifs, ce qui n'équivaut pas à un chiffrement où France Nuage serait techniquement incapable de lire la donnée traitée pour le compte du client. Les usages où le client conserve seul la clé relèvent de services spécifiques, pas d'une propriété générale de la plateforme.
Principes
- Chiffrement systématique en transit : aucun flux en clair sur un réseau que nous ne contrôlons pas ; HTTP est redirigé vers HTTPS.
- Chiffrement authentifié uniquement : les secrets au repos sont protégés par un mode AEAD ; un déchiffrement qui échoue à l'authentification échoue tout court.
- Séparation de la clé et de la donnée : la clé maîtresse ne touche jamais la base de données qu'elle protège.
- Primitives standard, jamais de cryptographie maison : algorithmes publics, éprouvés, implémentés par des bibliothèques auditées par leur communauté.
- Rotation prévue par conception : chaque enregistrement chiffré porte sa version de clé, ce qui permet de changer de clé maîtresse sans réécrire l'ensemble des données d'un bloc.
- Le support en fin de vie n'est pas une fuite : un disque retiré, réutilisé ou mis au rebut est inexploitable.
Mesures
| Domaine | Mesure |
|---|---|
| Flux externes | TLS partout, HTTP redirigé vers HTTPS, TLS 1.2 au minimum ; certificats émis et renouvelés automatiquement au niveau de l'ingress (A.8.24). |
| Flux internes | Trafic entre nœuds transporté par un maillage WireGuard chiffré ; accès d'exploitation via VPN WireGuard (Headscale) (A.8.24). |
| Secrets applicatifs au repos | Chiffrement d'enveloppe authentifié XChaCha20-Poly1305 : une clé de chiffrement des données tirée aléatoirement par enregistrement, enveloppée par une clé maîtresse de 256 bits, nonce de 192 bits par enregistrement et donnée additionnelle authentifiée pour la séparation de domaine (A.8.24). |
| Gestion des clés en mémoire | Les clés sont effacées de la mémoire dès qu'elles ne servent plus (zeroization), et les secrets sont expurgés des journaux (A.8.24). |
| Secrets d'infrastructure | Sealed Secrets : les secrets sont chiffrés jusque dans Git et ne sont déchiffrables que par le contrôleur du cluster destinataire (A.8.24). |
| Rotation | Version de clé stockée avec chaque enregistrement, permettant le ré-enveloppement progressif lors d'un changement de clé maîtresse ; rotation des secrets au départ d'une personne (A.8.24). |
| Supports de stockage | Chiffrement au repos côté stockage : un support retiré est inexploitable. Effacement et destruction sécurisés en fin de vie (A.7.10). |
| Mise au rebut du matériel | Effacement cryptographique (crypto-erase) puis destruction physique à la mise au rebut ou avant réemploi (A.7.14). |
| Sauvegardes | Sauvegardes chiffrées, avec une copie dans un datacenter géographiquement distinct (A.8.24). |
Responsabilités
- Le RSSI (François-Guillaume Ribreau) est responsable de cette politique, du choix des algorithmes et de la détention de la clé maîtresse.
- L'équipe d'ingénierie applique ces mesures dans le code et l'infrastructure ; toute introduction d'un nouveau mécanisme cryptographique passe par une revue de MR.
- L'équipe d'exploitation exécute l'effacement et la destruction des supports en fin de vie.
- Toute suspicion de compromission d'une clé est signalée sans délai à security@france-nuage.fr et déclenche une rotation.
Statut et trajectoire
L'usage de la cryptographie, la protection des supports de stockage et l'élimination sécurisée du matériel sont en place et opérationnels (A.8.24, A.7.10, A.7.14).
Nous précisons deux limites, parce qu'elles pèsent sur l'évaluation d'un acheteur exigeant. La clé maîtresse est fournie par la configuration de la plateforme. Nous n'utilisons pas de module matériel dédié (HSM) à ce jour, et la gestion du cycle de vie des clés n'est pas encore formalisée dans une procédure écrite distincte de cette politique. Par ailleurs, deux mesures voisines restent à ouvrir. Le masquage et l'anonymisation des données (A.8.11) et un dispositif de prévention des fuites de données (A.8.12) sont planifiés, non déployés. La politique de rétention à l'échelle de l'organisation reste à formaliser (A.5.33, partiel).
Revue
Cette politique est revue au moins une fois par an, à chaque évolution significative de nos primitives ou de notre gestion des clés, et à la publication d'un avis affectant un algorithme que nous utilisons.
Dernière revue : 31 août 2026.
Voir aussi
- Déclaration d'applicabilité (le statut des contrôles A.8.24, A.7.10 et A.7.14)
- Modèle de sécurité (la place de la cryptographie dans notre défense en profondeur)
- Politique de sécurité réseau (le chiffrement des flux et le cloisonnement qui l'accompagne)
- Guide des sauvegardes (protection et restauration des données clients)
- Politique de sécurité de l'information (le cadre du SMSI dont cette politique découle)