Politique de sécurité — Edu-Kit

Version : 1.0     Date : Juin 2026     Statut : En vigueur

Sommaire

  1. Contexte et périmètre
  2. Objectifs de sécurité
  3. Conformité réglementaire et standards
  4. Cartographie des risques
  5. Responsabilités

1. Contexte et périmètre

1.1 Contexte

Edu-Kit est une plateforme de virtualisation pédagogique destinée aux établissements d’enseignement secondaire et supérieur (lycées technologiques, IUT, écoles d’ingénieurs). Elle permet la mise à disposition de machines virtuelles pour les travaux pratiques des étudiants.

La plateforme héberge des données d’établissements scolaires et traite des comptes d’utilisateurs incluant des mineurs. Ce contexte impose des exigences de confidentialité, d’intégrité et de traçabilité renforcées.

1.2 Périmètre

Le système d’information Edu-Kit couvre deux plans distincts.

Plan de contrôle (infrastructure hébergée par l’équipe Edu-Kit) :

Composant Rôle
Cluster Proxmox VE (pve1, pve2, pve3) Hyperviseur — héberge l’ensemble des VMs de services
Clusters K3s dev et prod Orchestration des applications (Traefik, ArgoCD, Longhorn)
Firewalls MikroTik fw-01 / fw-02 Sécurité périmétrique — politique deny by default
Keycloak Authentification centralisée (SSO, RBAC, OIDC/PKCE)
Wazuh Détection d’intrusion et supervision de sécurité (SIEM/EDR)
Warpgate Bastion SSH — centralisation et traçabilité des accès Ops
Harbor Registre de conteneurs avec scan CVE automatique
Vaultwarden Gestionnaire de secrets d’équipe
PBS on-site + PBS OVH Sauvegarde et restauration des VMs
Stack Prometheus / Grafana / Loki Observabilité et alerting

Plan d’exécution (infrastructure cliente) :

Composant Rôle
Proxmox clients (établissements / OVHCloud) Hôtes des VMs pédagogiques des étudiants
Templates cloud-init Provisionnement standardisé des VMs

1.3 Segmentation réseau

L’infrastructure est segmentée en sept zones fonctionnelles, cloisonnées par les firewalls MikroTik en politique de refus par défaut. Aucun flux inter-zone n’est autorisé sans règle explicite.

Zone Adressage Contenu
dmznet 192.168.10.0/24 Services exposés publiquement
adminet 192.168.20.0/24 Administration Proxmox, PBS
k3snet 192.168.30.0/24 Clusters Kubernetes dev et prod
obsnet 192.168.50.0/24 Stack d’observabilité
socnet 192.168.60.0/24 Wazuh Manager
regnet 192.168.70.0/24 Harbor (registre de conteneurs)
mailnet 192.168.80.0/24 Serveur mail

2. Objectifs de sécurité

La politique de sécurité d’Edu-Kit est fondée sur les trois piliers de la sécurité de l’information :

  • Confidentialité : seuls les utilisateurs authentifiés et autorisés accèdent aux ressources qui leur sont attribuées (Keycloak RBAC, WireGuard VPN nominatif, Warpgate bastion).
  • Intégrité : les données et les systèmes ne sont pas altérés de façon non autorisée (FIM Wazuh, Harbor scan CVE, Sealed Secrets, PBS verify automatique).
  • Disponibilité : les services restent accessibles conformément aux engagements (cluster Proxmox HA, VRRP MikroTik, Longhorn, PBS multi-sites).

2.1 Indicateurs clés

Les objectifs de sécurité sont pilotés par des indicateurs mesurables, portés par l’Ops Sécurité :

Indicateur Cible
Délai de réponse à une vulnérabilité critique (CVSS ≥ 9) < 5 jours ouvrés
Couverture CIS Benchmarks sur les machines de production ≥ 80 % des recommandations niveau 1
Taux d’adoption du SSO sur l’ensemble des services internes 100 %
Images container avec vulnérabilité CRITICAL autorisées en production 0

2.2 Indicateurs de risque (KRI)

Les indicateurs suivants signalent une dégradation de la posture de sécurité et déclenchent une action corrective prioritaire :

Indicateur Seuil d’alerte
Nombre de vulnérabilités critiques (CVSS ≥ 9) détectées par Wazuh > 0 non traité après 5 jours
Tentatives de connexion SSH échouées en rafale sur un nœud > 10 en 60 secondes
Dérive de configuration ArgoCD non corrigée > 1 heure
Échec de vérification d’intégrité PBS Immédiat

3. Conformité réglementaire et standards

3.1 RGPD

Edu-Kit traite des données à caractère personnel (comptes utilisateurs d’établissements scolaires, données de sessions pédagogiques). La conformité RGPD est structurée autour des éléments suivants.

Registre des traitements (article 30 RGPD)

Un registre des activités de traitement a été constitué pour les six traitements principaux de l’infrastructure :

Réf. Traitement Responsable Données collectées Conservation
1-Infra Cluster Proxmox VE Ops Sécurité Identité, e-mail 2 ans
2-Infra Rancher Ops Plateforme Identité, logs connexion 24 mois
3-Infra ArgoCD Ops Plateforme Identité, logs connexion 24 mois
4-Infra Harbor Ops Sécurité Identité, e-mail 2 ans
5-Infra Firewalls MikroTik Ops Sécurité Logs réseau, IP 24 mois
6-Infra Keycloak Ops Plateforme Identité, logs d’authentification 24 mois

Mesures techniques de conformité

  • Contrôle d’accès aux données par Keycloak RBAC : chaque utilisateur n’accède qu’aux ressources de son organisation.
  • Traçabilité complète des accès Ops via Warpgate (session nominative, horodatée, enregistrée).
  • Chiffrement des secrets Kubernetes via Sealed Secrets.
  • Hébergement France : infrastructure principale au DIIAGE, sauvegarde externalisée chez OVHCloud (France).

Documents légaux

Un Accord de traitement des données (DPA) est prévu pour chaque établissement client. Les CGU et la Politique de confidentialité ont été rédigées et sont destinées à être publiées avant la mise en production.

3.2 Recommandations ANSSI

La politique de sécurité est alignée avec les recommandations de l’ANSSI :

  • Délai de correction des vulnérabilités critiques (CVSS ≥ 9) : < 5 jours ouvrés.
  • Authentification forte sur l’ensemble des accès (MFA via Keycloak, VPN WireGuard).
  • Segmentation réseau avec politique de refus par défaut.
  • Journalisation centralisée des événements de sécurité (Wazuh + Loki).

3.3 CIS Benchmarks

Le durcissement des machines virtuelles suit le référentiel CIS Benchmarks niveau 1. L’outil Lynis est utilisé pour mesurer la conformité (score cible : ≥ 80 %). Les rapports de durcissement sont des livrables types de l’Ops Sécurité.

3.4 Standard d’authentification

L’authentification de la plateforme respecte le standard OIDC/PKCE (Keycloak 26), recommandé pour les applications SPA et imposé comme standard d’authentification sur l’ensemble des services internes.


4. Cartographie des risques

Les risques suivants ont été identifiés sur le périmètre de l’infrastructure Edu-Kit. Chaque risque est évalué par sa probabilité, son impact et sa criticité, avec la mesure de traitement retenue.

ID Risque Probabilité Impact Criticité Mesure de traitement
RI-01 Compromission d’un compte d’accès Ops Faible Critique Élevée VPN WireGuard nominatif + bastion Warpgate + procédure de révocation immédiate (fiche de poste OS)
RI-02 Panne d’un nœud Proxmox Moyenne Élevé Élevée Cluster 3 nœuds avec HA Proxmox + stockage Ceph distribué (tolérance à la perte d’un nœud)
RI-03 Vulnérabilité critique non corrigée exploitée Faible Critique Élevée Wazuh détection temps réel + KRI délai < 5j ouvrés + scan Harbor/Trivy
RI-04 Accès non autorisé aux données d’un établissement Très faible Critique Élevée Isolation réseau par zone + Keycloak RBAC par organisation + TLS sur tous les flux
RI-05 Perte irréversible des sauvegardes Très faible Élevé Moyenne PBS on-site (DIIAGE) + PBS OVH remote + vérification automatique d’intégrité
RI-06 Attaque par force brute sur les accès SSH Moyenne Moyen Moyenne Accès SSH uniquement via Warpgate + détection Wazuh en temps réel
RI-07 Image container avec vulnérabilité CRITICAL déployée Faible Élevé Moyenne Harbor + Trivy : refus automatique de toute image CRITICAL en push

5. Responsabilités

5.1 Rôle responsable

La politique de sécurité est portée par le domaine Ops Sécurité et intégration continue (OS), responsable final (A/R dans le RACI) des activités #10 (pipelines CI/CD) et #11 (sécurité applicative et infrastructure).

Voir la fiche de poste Ops Sécurité pour le détail des missions, compétences et livrables attendus.

5.2 Répartition des responsabilités de sécurité

Domaine de sécurité Responsable final Contributeurs
Authentification et autorisation (Keycloak) OS DB, DF
Détection d’intrusion (Wazuh) OS OP, OE
Architecture réseau et segmentation (MikroTik) OR OS
Supervision et alerting (Prometheus, Grafana) OE OS
Infrastructure et sauvegarde (PBS, Proxmox HA) OE OP
Pipelines CI/CD et déploiement (ArgoCD) OS OP
Registre et intégrité des images (Harbor) OS OP

Voir la Matrice RACI projet pour le détail complet.

5.3 Mise à jour de ce document

Ce document est mis à jour par l’Ops Sécurité à chaque évolution significative de l’infrastructure ou de la réglementation applicable. Il est versionné dans le dépôt Git de la documentation.


Voir aussi


Retour en haut