Conformité / audit

Politique SSI et procédures

SMSI · 5 (partie publique) — voir aussi le contexte de la démarche.

1. Politique SSI

Objectifs

Protéger la disponibilité, l'intégrité et la confidentialité des deux services hébergés (portfolio public, EventMap privé) et des secrets qui les font tourner, avec les moyens d'un particulier — pas d'astreinte, pas d'équipe, pas de budget sécurité dédié.

Périmètre

VM Oracle (Ubuntu 22.04, nginx + Node/systemd, services portfolio et eventmap), poste Windows d'administration, dépôts GitHub du code, sauvegarde chiffrée locale des secrets. Hors périmètre : les comptes cloud de secours non utilisés en production.

Rôles

Une seule personne — Hamdy Tabsissi — cumule RSSI (décide de la politique et des priorités), administrateur (applique, déploie, corrige) et DPO (répond des données personnelles collectées : IP anonymisées, liens nominatifs). Ce cumul est un écart structurel assumé, pas caché — documenté comme tel dans l'audit interne.

Principes directeurs

Moindre privilège — utilisateurs systemd dédiés par service, pas de root pour l'exécution applicative.
Secrets hors Git — les fichiers de configuration sensibles ne quittent jamais le dépôt ; sauvegarde chiffrée hors VM, passphrase séparée du fichier chiffré.
Zéro downtime volontaire — aucun redémarrage automatique, aucune montée de version majeure automatisée, reboots manuels avec vérification avant/après.
Pas de montée de version majeure sans snapshot préalable.
Traçabilité minimale et proportionnée — logs anonymisés, rétention courte, pas de collecte au-delà du nécessaire.
Tout nouveau sous-domaine naît en HTTPS, derrière Cloudflare proxifié — dès sa première mise en ligne, sans exception, y compris pour un essai ou une démonstration. Un sous-domaine servi en clair, même une heure, casse l'hypothèse sur laquelle reposent les en-têtes de transport du domaine entier.
Une interface d'administration n'est pas protégée par son mot de passe, elle est protégée avant lui — l'authentification se fait au bord du réseau, en amont du service, de sorte que l'application ne soit jamais atteinte par un visiteur non authentifié.

2. Procédures

Déploiement

Développer et tester en local.
git push sur le dépôt.
Sur la VM : git pull toujours suivi d'un chown -R <user>:<user> .
systemctl restart <service>
Vérifier la santé du service en local et depuis l'extérieur.

Sauvegarde et restauration des secrets

Sauvegarde chiffrée (AES-256, PBKDF2 forte itération) des fichiers de configuration sensibles, relancée après tout changement de secret.
Passphrase stockée séparément du fichier chiffré, dans un gestionnaire de mots de passe.
Procédure de restauration documentée et testée au moins une fois.

Gestion des incidents

Constater (alerte, symptôme, ou détection manuelle).
Isoler si nécessaire sans couper le service sain (les services sont indépendants).
Diagnostiquer sur la VM.
Corriger, vérifier en production, puis consigner dans le journal des incidents interne (date / impact / cause / correction / leçon).
Ne jamais toucher au pare-feu cloud ni rebooter sans vérifier qu'aucune autre intervention n'est en cours.

Gestion des changements

Toute modification d'architecture relit d'abord les décisions techniques déjà actées.
Changement de secret → sauvegarde relancée dans la foulée.
Changement réseau/pare-feu → vérifier les deux couches de pare-feu (système et cloud) : oublier l'une des deux est le piège le plus fréquent.
Création d'un sous-domaine → certificat et proxy Cloudflare avant la première résolution DNS publique, jamais après.
Pas de changement risqué (reboot, upgrade, régénération de clé) en solo sans avoir écrit au préalable ce qui sera vérifié après.
Toute modification de sshd à distance se fait avec un filet de retour automatique armé avant l'application, et désarmé seulement depuis une seconde session ouverte en parallèle.

Revue des accès

Accès SSH par clé uniquement, revue périodique des clés autorisées sur la VM. Connexion directe de root refusée, liste blanche d'utilisateurs autorisés.
Interfaces d'administration derrière une authentification de bord. Les sous-domaines d'administration ne servent pas leur propre page de connexion : une requête non authentifiée est redirigée vers le fournisseur d'identité avant d'atteindre la machine. C'est vérifiable de l'extérieur — ces hôtes répondent par une redirection d'authentification, là où les sites publics répondent directement.
Accès admin applicatif : mot de passe unique, rotation en cas de suspicion de fuite, jamais de partage.
Protection anti-brute-force active sur SSH, contrôle mensuel de son statut.
Authentification multifacteur exigée sur la console du fournisseur cloud, par politique du compte — c'est le seul chemin vers la configuration réseau et les sauvegardes.

Rotation de clé SSH (procédure sûre — ajouter avant de retirer)

Générer la nouvelle paire de clés.
Ajouter la nouvelle clé publique aux clés autorisées sur la VM, en gardant l'ancienne active.
Tester la connexion avec la nouvelle clé depuis une session séparée, sans fermer la session existante.
Une fois confirmée, retirer l'ancienne clé.
Ne jamais inverser l'ordre : retirer avant d'ajouter coupe l'accès sans filet.

3. Exposition du port SSH — écart assumé

Le port SSH de la machine est ouvert à l'ensemble d'Internet, et non restreint à une plage d'adresses. C'est un fait observable de l'extérieur par n'importe quel balayage de ports : l'écrire ici ne révèle rien, le taire serait un mensonge par omission dans un document qui prétend décrire le contrôle d'accès réel.

Ce que cette exposition coûte, mesuré sur le journal d'authentification : 232 tentatives de connexion le 12/09/2026, depuis 80 adresses distinctes ; 4 403 tentatives depuis le 22/08 ; 97 bannissements prononcés par la protection anti-brute-force. Ce bruit est permanent et il ne baissera pas.

La fermeture a été étudiée : faire passer l'administration par un tunnel applicatif, et ne plus rien exposer. La solution a été montée, testée, puis retirée — la latence ajoutée rendait le canal d'administration pénible au point d'être évité, et un contrôle de sécurité que son propriétaire contourne est pire qu'un contrôle absent. L'arbitrage est donc explicite : l'exposition est conservée, et elle se paie ailleurs.

Ce que l'exposition oblige en retour. Tant que le port est ouvert, la veille sur les vulnérabilités du serveur SSH n'est plus un confort, c'est une mesure compensatoire nécessaire : c'est elle qui tient l'écart. Concrètement — authentification par clé uniquement (aucun mot de passe accepté), connexion directe de root refusée et liste blanche d'utilisateurs, bannissement automatique des sources répétées, application automatique quotidienne des correctifs de sécurité, et souscription au support de sécurité étendu de la distribution qui couvre le serveur SSH sur toute la durée de vie prévue de la machine.

La conséquence pratique est qu'un correctif SSH ne peut pas attendre une fenêtre de maintenance confortable. C'est le prix du choix, il est écrit pour qu'il soit tenu.

Note du 14/09/2026 — ce qui a déclenché l'écriture de cette section. Jusqu'à cette date, ce document disait « protection anti-brute-force active sur SSH » et s'arrêtait là. L'ouverture du port au monde entier n'était écrite nulle part : elle n'avait pas été décidée, elle avait été héritée de la configuration par défaut, et personne ne l'avait relue depuis. Elle a été découverte en lisant la règle de filtrage réelle, pas la documentation.

Le même contrôle a livré un second défaut, plus discret : la protection anti-brute-force voyait sa liste d'exemptions vide, parce que la ligne qui la définit est commentée dans la configuration livrée par la distribution. Chaque test d'administration mené depuis la machine elle-même consommait donc du quota de bannissement. Corrigé le 13/09/2026.

Un contrôle hérité n'est pas un contrôle décidé. La différence ne se voit pas tant qu'on lit la documentation ; elle saute aux yeux dès qu'on lit la machine.