Pourquoi la sécurisation SSH est un enjeu RGPD majeur
La protection des données personnelles ne se limite pas à des politiques de confidentialité ou à des formulaires de consentement. Elle passe aussi par des mesures techniques robustes et éprouvées. L'authentification SSH par clé cryptographique est l'une de ces mesures fondamentales que tout responsable de traitement doit mettre en place pour respecter ses obligations légales.
Selon la CNIL, « la sécurité des données personnelles repose sur une approche technique et organisationnelle globale ». L'accès non autorisé à vos serveurs représente un risque direct de violation de données (data breach), exposant votre organisation à des sanctions pouvant atteindre 4 % du chiffre d'affaires ou 20 millions d'euros.
À retenir :
- L'authentification par clé SSH remplace les mots de passe faibles et élimine les risques de brute force
- La désactivation de l'accès root direct réduit la surface d'attaque et améliore la traçabilité des actions
- Une gestion stricte des clés publiques (authorized_keys) est obligatoire pour maintenir la conformité RGPD
- Ces mesures constituent des « mesures techniques et organisationnelles appropriées » au sens de l'article 32 du RGPD
L'article 32 du RGPD : l'obligation de sécurité technique
L'article 32 du Règlement Général sur la Protection des Données impose à tout responsable de traitement de mettre en œuvre « des mesures techniques et organisationnelles appropriées » pour assurer un niveau de sécurité adapté au risque. Cela inclut explicitement :
- Le chiffrement des données en transit et au repos
- La capacité à assurer la disponibilité et la résilience des systèmes
- La restauration rapide en cas d'incident
- Un système de gestion des accès robuste et auditables
L'authentification SSH par clé répond directement à ces exigences en garantissant que seules les personnes autorisées peuvent accéder à vos serveurs hébergeant des données personnelles.
Migrer de l'authentification par mot de passe à la clé SSH
Les mots de passe root présentent des faiblesses intrinsèques : ils peuvent être devinés, interceptés, partagés entre collaborateurs ou notés sur des post-it. Une authentification par clé cryptographique élimine ces risques.
Les avantages de la clé SSH pour la conformité RGPD
- Immuabilité : une clé privée ne peut pas être « oubliée » ou réutilisée entre plusieurs personnes
- Auditabilité : chaque clé peut être associée à un utilisateur spécifique, facilitant la traçabilité des accès
- Révocation rapide : en cas de départ d'un collaborateur, la suppression de sa clé publique est instantanée
- Prévention des attaques : aucun brute force possible sur une clé RSA 4096 bits
La gestion des clés publiques : un point critique souvent négligé
Une erreur courante consiste à partager un même fichier authorized_keys entre plusieurs utilisateurs ou serveurs. Cette pratique viole directement le principe de « séparation des accès » et crée une faille de conformité RGPD.
Chaque utilisateur doit disposer de sa propre clé privée, stockée de manière sécurisée (idéalement sur un gestionnaire de secrets ou un matériel dédié). Le fichier authorized_keys doit être strictement limité aux clés publiques correspondantes, avec des permissions restrictives (600 ou 400).
Bonnes pratiques de gestion des clés
- Générer une paire de clés unique par utilisateur et par contexte (développement, production, administration)
- Utiliser RSA 4096 bits minimum ou Ed25519 (plus moderne et performant)
- Protéger la clé privée avec une passphrase robuste
- Documenter l'inventaire des clés et leur association aux utilisateurs
- Auditer régulièrement les fichiers authorized_keys pour détecter les entrées obsolètes
- Implémenter une rotation des clés au moins annuellement
Désactiver l'accès root : renforcer la traçabilité
Permettre la connexion directe en root via SSH crée un problème majeur de traçabilité. Si plusieurs administrateurs utilisent le même compte, il devient impossible de déterminer qui a effectué telle ou telle action en cas d'incident.
La meilleure pratique consiste à :
- Désactiver complètement l'authentification par mot de passe pour root
- Désactiver l'accès SSH direct en tant que root
- Forcer les administrateurs à se connecter avec leur propre compte utilisateur
- Utiliser sudo pour les actions nécessitant des privilèges élevés
- Configurer un audit de toutes les commandes sudo via les logs système
Cette approche garantit une responsabilité individuelle et facilite les audits internes en cas de contrôle CNIL ou de violation de données.
Intégration avec votre politique de sécurité RGPD
La sécurisation SSH ne doit pas être une mesure isolée. Elle s'inscrit dans une stratégie globale de protection des données :
- Inventaire des accès : documenter qui a accès à quel serveur et pourquoi
- Contrôle d'accès basé sur les rôles (RBAC) : limiter les privilèges au strict nécessaire
- Logs centralisés : envoyer tous les logs SSH vers un système SIEM pour détection d'anomalies
- Plan de réponse aux incidents : définir la procédure en cas de compromission de clé
- Formation des équipes : sensibiliser au risque de phishing et d'ingénierie sociale
Questions fréquentes
La clé SSH remplace-t-elle complètement la nécessité de chiffrer les données ?
Non. La clé SSH sécurise l'accès au serveur, mais pas les données elles-mêmes. Vous devez combiner cette mesure avec le chiffrement des données au repos (disques chiffrés, bases de données chiffrées) et en transit (TLS/HTTPS). L'article 32 du RGPD exige une approche multicouche.
Que faire si une clé privée est compromise ?
Immédiatement, supprimez la clé publique correspondante du fichier authorized_keys sur tous les serveurs. Générez une nouvelle paire de clés. Documentez l'incident et vérifiez les logs pour détecter un accès non autorisé potentiel. Si des données ont été exposées, vous devez notifier la CNIL sous 72 heures.
Faut-il stocker les clés privées sur le serveur lui-même ?
Absolument pas. Les clés privées doivent être stockées localement sur la machine de l'administrateur, idéalement protégées par une passphrase. Pour les déploiements automatisés, utilisez un gestionnaire de secrets (Vault, AWS Secrets Manager) plutôt que des fichiers statiques.
Vers une infrastructure conformément sécurisée
La sécurisation SSH par clé cryptographique est un élément fondamental de la conformité RGPD. Elle démontre à la CNIL et à vos utilisateurs que vous prenez au sérieux la protection de leurs données. Combinée à d'autres mesures (chiffrement, audit, formation), elle constitue une base solide pour un programme de conformité durable et efficace.
N'attendez pas un incident pour agir. Auditez dès aujourd'hui vos pratiques d'accès et migrez vers une authentification par clé si ce n'est pas déjà fait.