Chiffrer les données sensibles
« Chiffrer les données » ne veut rien dire seul. Il faut préciser quoi, contre qui et à quel moment : le trafic réseau, les fichiers au repos, les sauvegardes, ou seulement quelques colonnes. Chaque couche a un coût et une clé différente. Confondre ces niveaux conduit souvent à un serveur réputé chiffré dont les exports restent lisibles.
Transport : TLS partout où ça circule
Le minimum est HTTPS sur les sites et les API. Certbot avec le plugin Nginx installe le certificat et planifie le renouvellement :
sudo apt install certbot python3-certbot-nginx
sudo certbot --nginx -d votre-domaine.fr
sudo certbot renew --dry-runLe renouvellement est assuré par un timer systemd : contrôlez-le avec systemctl list-timers | grep certbot, surtout après une migration. Pour une base distante ou un serveur mail, utilisez aussi TLS avec un certificat au nom de l'hôte, pas de l'adresse IP.
Chiffrement applicatif
Certaines données ne devraient jamais être stockées en clair : jetons d'API, clés privées, données bancaires ou de santé. Chiffrez-les avant l'insertion, avec AES-256-GCM ou libsodium, un nonce unique par enregistrement et un identifiant de clé conservé à côté du chiffré. Cet identifiant permet de faire tourner les clés sans réécrire toute la base.
Ne chiffrez pas les mots de passe : ils se hachent avec Argon2id ou bcrypt, et ne se déchiffrent jamais. Le chiffrement est réversible, le hachage non. Le chiffrement de colonne empêche la recherche et le tri sur ces colonnes : si vous en avez besoin, prévoyez un index aveugle ou acceptez la limitation.
Sauvegardes chiffrées
Sur Debian 13, installez l'outil avec sudo apt install age s'il n'est pas déjà présent.
tar -czf app.tar.gz /var/www/app
age -r AGE_PUBLIC_KEY -o app.tar.gz.age app.tar.gz
age -d -i cle.age.txt app.tar.gz.age | tar -tzf -Chiffrez avant de copier hors du serveur. La clé privée ne doit jamais se trouver dans la sauvegarde ni dans un dépôt Git. Testez le déchiffrement sur une autre machine : une sauvegarde illisible n'est pas une sauvegarde. La règle 3-2-1 reste valable, avec trois copies, deux supports et une hors site.
Gérer les clés
Une clé par usage, une date de création, un propriétaire. Stockez la clé privée dans un gestionnaire de secrets ou dans un fichier en mode 600, hors du répertoire web. Lors d'une rotation, déchiffrez avec l'ancienne, réécrivez avec la nouvelle, puis révoquez l'ancienne.
Sur un VPS NeoHeberg, le disque racine est un conteneur système : le chiffrement LUKS de la racine n'est pas disponible. Le chiffrement applicatif et les sauvegardes chiffrées deviennent donc la protection réelle des données sensibles.
Vérification
stat -c '%a %n' cle.age.txt
age -d -i cle.age.txt app.tar.gz.age | tar -tzf - | head
curl -sI https://votre-domaine.frAttendu : 600 sur la clé, une liste de fichiers lisible, un en-tête HTTPS valide. Vérifiez aussi qu'aucun journal ni message d'erreur n'affiche une valeur en clair. Une clé présente sur un serveur compromis est considérée comme perdue : la rotation et la révocation font partie du plan, pas de l'improvisation.
Publicité
Cet article vous a-t-il aidé ?
À lire aussi
- Auditer la sécurité de son serveurUne routine d'audit reproductible : inventaire, Lynis, permissions, mises à jour et compte rendu daté.
- Sécuriser une API publiqueLes couches minimales d'une API exposée : TLS, authentification, quotas, validation, CORS et journaux exploitables.
- Sécuriser une base de donnéesRéduire l'écoute réseau, les privilèges et l'exposition des sauvegardes d'une base MariaDB ou PostgreSQL.