Aller au contenu principal

Modèle de sécurité

Cette page décrit comment France Nuage protège sa plateforme et les données qui lui sont confiées, en détaillant les couches de défense, le principe de résilience qui les sous-tend, et ce qui découle de notre choix d'exploiter notre propre infrastructure en France. Le statut contrôle par contrôle est détaillé dans notre déclaration d'applicabilité ; la gouvernance, dans notre politique de sécurité.

Un principe : la résilience horizontale​

La plupart des hébergeurs traitent chaque datacenter comme un point qui doit fonctionner coûte que coûte, et empilent les redondances locales (double alimentation, groupe électrogène, climatisation N+1) pour en réduire la probabilité de panne.

Nous avons pris le parti inverse. France Nuage est conçu pour être hautement résilient au niveau système. La perte d'un datacenter entier est un événement prévu et non critique par conception. Les données sont répliquées entre nos sites, et la bascule est testée. Concrètement :

  • nos bases de données managées répliquent en anti-affinité inter-zones (les répliques ne partagent pas le même site) ;
  • les sauvegardes sont copiées vers un stockage géographiquement distinct, et une restauration est testée régulièrement (pas seulement la sauvegarde) ;
  • le plan de continuité repose sur cette bascule multi-datacenters, pas sur l'infaillibilité d'un site isolé.

La conséquence est directe pour l'évaluation de nos contrôles physiques : un renforcement partiel sur un site donné (par exemple un onduleur sans groupe électrogène) est traité comme une mesure compensée. L'objectif de disponibilité est atteint par l'architecture, pas par la perfection d'un site. C'est un choix d'ingénierie assumé, non une faiblesse masquée.

Défense en profondeur​

Aucune couche n'est censée être parfaite seule ; c'est leur superposition qui protège.

Sécurité physique​

France Nuage détient et exploite ses trois datacenters en France (Essarts-en-Bocage, Saint-Gilles-Croix-de-Vie, Nantes). La sécurité physique (accès aux locaux, protection environnementale, mise au rebut des supports) fait partie de notre périmètre et n'est pas déléguée à un hébergeur tiers. Les supports de stockage sont chiffrés au repos. Un disque retiré est inexploitable.

Réseau​

  • Refus par défaut. Chaque espace de noms applique une politique réseau (NetworkPolicy) en refus par défaut, puis n'autorise que les flux nécessaires.
  • Isolation par locataire. Les charges d'un locataire ne peuvent atteindre ni le réseau hôte, ni le réseau interne du cluster, ni les métadonnées : le rebond latéral est bloqué au niveau réseau.
  • Mesh chiffré. Le trafic entre nœuds passe par un maillage WireGuard chiffré.
  • WAF. Un pare-feu applicatif (CrowdSec, virtual patching) filtre l'edge critique.

Identité et accès​

  • SSO centralisé via Keycloak, en migration vers l'IAM souverain FerrisKey. L'authentification multifacteur (MFA) est gérée au niveau du fournisseur d'identité.
  • Client confidentiel (BFF). L'échange de jetons se fait côté serveur ; la session est chiffrée et httpOnly ; aucun jeton n'est exposé au navigateur. Anti-CSRF et anti-rejeu en place, comportement fail-closed.
  • Moindre privilège. Le rôle par défaut est en lecture seule ; les droits d'administration font autorité en base, jamais depuis un jeton.
  • Autorisation fine. Un modèle par relations (organisation → dossier → projet → instance) décide de chaque accès, avec des assertions testées en intégration continue.

Données et cryptographie​

  • En transit : TLS partout, HTTP redirigé vers HTTPS.
  • Au repos : les secrets sont protégés par un chiffrement d'enveloppe authentifié (XChaCha20-Poly1305, clé de chiffrement des données propre à chaque enregistrement, enveloppée par une clé maîtresse qui ne touche jamais la base) et par des Sealed Secrets (secrets chiffrés jusque dans Git). Le stockage applique le chiffrement au niveau des supports.
  • Sauvegarde et restauration : sauvegardes quotidiennes surveillées, réessayées automatiquement en cas d'échec, restaurées à blanc régulièrement pour prouver qu'elles sont exploitables, avec une copie externalisée.

Application et développement​

  • Langage à sûreté mémoire (Rust) sur le cœur de la plateforme, éliminant des classes entières de vulnérabilités.
  • Garde-fous de code : lint bloquant, rédaction des secrets dans les journaux, effacement mémoire des clés, garde de compilation empêchant tout composant factice en production.
  • Chaîne d'intégration continue multi-étapes : analyse de secrets, lint, tests unitaires, d'autorisation, d'intégration et de sécurité des manifestes, comme conditions de fusion.
  • Séparation des environnements : clusters et espaces de noms distincts entre qualification et production, promotion vers la production limitée à la branche principale.

Observabilité et réponse​

Métriques, journaux et traces sont centralisés (Grafana, Mimir, Loki, Tempo). Des règles d'alerte couvrent la disponibilité, la saturation, la fraîcheur des sauvegardes et l'infrastructure réseau, et sont routées vers une astreinte. Chaque incident donne lieu à un post-mortem.

Chaîne d'approvisionnement logicielle​

Nos composants critiques sont open source et auto-hébergés. Les dépendances et images sont suivies et mises à jour automatiquement (montées de version soumises à revue humaine), les images sont tirées d'un registre interne avec des tags épinglés pour des redéploiements déterministes.

Souveraineté​

La sécurité de France Nuage est indissociable de sa souveraineté :

  • Hébergement exclusivement en France, dans nos propres datacenters, sans dépendance à un hyperscaler.
  • Personnel sous contrôle français ou européen : la citoyenneté française ou européenne est vérifiée à l'embauche, en cohérence avec l'exigence SecNumCloud.
  • Ré-internalisable. Nos composants étant open source, un client peut auditer et, s'il le souhaite, reprendre l'infrastructure chez lui (l'inverse du verrouillage propriétaire).

Voir aussi​