Un serveur qui va accueillir des données de santé n’a pas droit à l’approximation, même sur un simple site vitrine de cabinet ou une plateforme de prise de rendez-vous. La réglementation autour des données de santé impose des garanties précises, et il vaut mieux les vérifier une à une avant la mise en ligne plutôt que de les découvrir lors d’un audit après incident. Cette checklist reprend, point par point, les contrôles appliqués avant d’ouvrir un serveur mutualisé ou dédié à ce type de projet.
Elle ne remplace pas un hébergement certifié HDS quand celui-ci est requis par la nature du traitement, mais elle couvre le socle technique minimal exigé pour tout site qui manipule, même indirectement, des informations de santé identifiantes.
Chiffrement : au repos et en transit
Le disque système et le volume qui contient les sauvegardes doivent être chiffrés au repos, avec une clé qui ne réside jamais sur le même serveur que les données qu’elle protège. Sur un VPS classique, cela signifie activer le chiffrement LUKS dès le provisionnement, avant toute installation de WordPress, car un chiffrement ajouté après coup sur un disque déjà rempli de données réelles n’offre aucune garantie rétroactive.
Le certificat TLS doit forcer TLS 1.2 minimum, idéalement 1.3, avec HSTS activé et une durée de préchargement suffisante. Aucune connexion en clair, y compris pour l’administration WordPress, ne doit rester possible : un test avec curl -I http://domaine.fr doit renvoyer une redirection 301 systématique vers HTTPS.
Journalisation : tout tracer, tout conserver
Chaque connexion à l’espace d’administration, chaque modification de rôle utilisateur et chaque accès SSH doivent être journalisés dans un fichier distinct du serveur applicatif, idéalement exporté vers un stockage externe en écriture seule. La conservation minimale retenue pour ce type de dossier est d’un an, avec une rotation qui ne supprime jamais silencieusement les journaux les plus anciens sans validation manuelle.
- Journal des connexions SSH avec authentification par clé uniquement, mot de passe désactivé dans
sshd_config. - Journal des connexions à
wp-login.php, y compris les tentatives échouées, avec seuil d’alerte après cinq échecs consécutifs. - Journal des modifications de fichiers dans
wp-content, pour détecter une injection de code malveillant a posteriori. - Journal des requêtes de base de données lentes ou atypiques, utile pour repérer une exfiltration en cours.
Cloisonnement réseau et système
Le site ne partage jamais son compte système avec un autre projet hébergé sur le même serveur physique. Chaque site dispose de son propre utilisateur Linux, de ses propres permissions de fichiers, et surtout de sa propre base de données avec des identifiants qui ne sont utilisés nulle part ailleurs. Sur un mutualisé partagé entre plusieurs clients, ce cloisonnement doit être vérifié explicitement auprès de l’hébergeur, car certaines offres d’entrée de gamme partagent encore le même utilisateur MySQL entre plusieurs bases.
Le pare-feu applicatif bloque tout accès entrant qui ne provient pas d’une liste d’IP autorisées pour l’administration, et le port SSH n’écoute jamais sur le port par défaut. Ces deux mesures, simples à mettre en place, réduisent immédiatement la surface d’attaque exposée aux scans automatisés qui parcourent en permanence les plages IP des hébergeurs français.
Sauvegardes et plan de restauration testé
Une sauvegarde chiffrée quotidienne, stockée sur un support distinct du serveur de production, ne suffit pas si elle n’a jamais été restaurée en conditions réelles. La checklist impose un test de restauration complet sur un environnement isolé au moins une fois avant la mise en ligne, puis tous les trimestres, avec mesure du temps réellement nécessaire pour reconstruire le site à l’identique.
Ce que ce test révèle souvent
Un temps de restauration sous-estimé de moitié, des identifiants de sauvegarde périmés, ou une dépendance oubliée qui n’était pas incluse dans le script d’export : ces trois problèmes reviennent le plus souvent lors du premier test grandeur nature, et il vaut mieux les découvrir avant un incident réel plutôt que pendant.
Une checklist de sécurité n’a de valeur que si chaque ligne est cochée par une preuve vérifiable, jamais par une simple déclaration d’intention.
En résumé
Douze points techniques, du chiffrement à la journalisation en passant par le cloisonnement et le test de restauration, forment le socle minimal avant d’accueillir un projet lié à des données de santé sur un serveur. Aucun de ces points n’est exotique ou coûteux à mettre en œuvre, mais leur absence, une fois révélée lors d’un audit, coûte largement plus cher en temps de mise en conformité qu’une vérification préalable méthodique.
