---
title: Sécuriser un serveur Debian : méthode, checklist et restauration
source: https://synapx.fr/blog/securite-serveur/
date: 2026-06-26
category: Debian & serveur
site: SynapxLab
---

# Sécuriser un serveur Debian : méthode, checklist et restauration

Sécuriser un serveur ne consiste pas à installer Fail2ban, fermer quelques ports puis considérer le travail terminé. Il faut réduire ce qui est exposé, limiter les privilèges, maintenir chaque composant, détecter les anomalies et surtout vérifier que le service peut être reconstruit après un incident.

Ce guide propose un socle réaliste pour un serveur Debian qui héberge un site, une API ou une application PHP. Il ne remplace ni une analyse de risques ni un audit adapté à une infrastructure sensible. Les commandes doivent être testées sur une préproduction ou avec un accès de secours : une règle de pare-feu ou une modification SSH incorrecte peut couper le seul accès au serveur.

> **Objectif :** savoir ce qui tourne, pourquoi cela tourne, qui peut l’administrer, comment une anomalie est détectée et comment l’activité est restaurée.

## Au sommaire

1. Inventorier avant de durcir.
2. Maintenir Debian et les applications.
3. Sécuriser les comptes et SSH.
4. Réduire l’exposition réseau.
5. Isoler les services et les droits.
6. Protéger HTTP, TLS et le serveur web.
7. Sécuriser l’application PHP.
8. Protéger la base et les secrets.
9. Journaliser et superviser.
10. Sauvegarder, restaurer et réagir à un incident.

## Partir du risque, pas de la liste d’outils

Un même serveur peut héberger une vitrine publique, une administration interne ou un ERP contenant des données personnelles. Les protections ne peuvent donc pas être identiques.

Avant toute modification, répondre à quatre questions :

* **Quel service doit rester disponible ?** Site, API, base, tâches planifiées, stockage de documents, messagerie transactionnelle…
* **Quelles données seraient graves à perdre ou à exposer ?** Base clients, documents, secrets, journaux, code, sauvegardes…
* **Qui peut agir sur le serveur ?** Administrateurs, développeurs, hébergeur, infogérant, pipeline de déploiement et comptes de service.
* **Comment revenir en arrière ?** Console de l’hébergeur, second accès administrateur, sauvegarde de configuration et procédure de restauration.

| Risque | Exemple | Première mesure | Preuve attendue |
|---|---|---|---|
| Compromission d’un compte | Clé SSH volée | Comptes nominatifs, clé protégée, MFA ou bastion selon le contexte | Revue des clés et test de révocation |
| Exploitation d’une faille | Service non corrigé | Versions supportées et correctifs suivis | Inventaire et historique de mise à jour |
| Mouvement latéral | Serveur web accédant à tout | Privilèges minimaux et segmentation | Test des droits depuis le compte du service |
| Effacement ou chiffrement | Rançongiciel ou erreur | Sauvegarde séparée, hors ligne ou immuable | Restauration complète réussie |
| Incident invisible | Intrusion silencieuse | Journaux protégés et alertes utiles | Alerte test reçue et traitée |

La politique doit rester proportionnée. Un serveur isolé chez un hébergeur n’exige pas le même dispositif qu’un parc multi-sites, mais il exige toujours des responsabilités explicites et des preuves de fonctionnement.

## 1. Inventorier avant de modifier

Le premier durcissement consiste souvent à découvrir ce qui est déjà installé et exposé. Sur Debian, ces commandes donnent un état initial sans modifier la configuration :

```bash
sudo ss -lntup
sudo systemctl list-units --type=service --state=running
sudo nft list ruleset
sudo apt list --upgradable
```

Elles permettent respectivement de voir les ports en écoute, les services actifs, le pare-feu `nftables` lorsqu’il est utilisé et les paquets pouvant être mis à jour.

Compléter cet inventaire avec :

* la version de Debian et sa période de support ;
* les dépôts APT configurés ;
* les versions de Nginx ou Apache, PHP, MariaDB/PostgreSQL et des runtimes annexes ;
* les tâches `cron` et timers systemd ;
* les virtual hosts et noms de domaine ;
* les comptes locaux, groupes privilégiés et clés autorisées ;
* les montages, volumes et espaces d’écriture ;
* les agents de sauvegarde, de supervision et de déploiement ;
* les flux entrants et sortants réellement nécessaires.

Un port ouvert n’est pas automatiquement une vulnérabilité. En revanche, un service oublié, non maintenu ou exposé sans nécessité augmente la surface d’attaque.

Avant de toucher à SSH ou au pare-feu, conserver la console de secours de l’hébergeur, ouvrir une deuxième session et sauvegarder les fichiers de configuration concernés. Un snapshot facilite un retour rapide, mais il ne remplace pas une sauvegarde indépendante : il peut disparaître avec le serveur ou le compte d’hébergement.

## 2. Maintenir le système et les logiciels

Debian publie des avis et correctifs sur sa page officielle [Debian Security Information](https://www.debian.org/security/). Le serveur doit utiliser une version encore supportée et des dépôts maîtrisés. Les paquets abandonnés, dépôts tiers non suivis et installations compilées sans procédure de mise à jour doivent être recensés séparément.

Le paquet `unattended-upgrades` peut installer automatiquement les correctifs autorisés. Debian précise cependant que son usage doit être configuré et surveillé : une mise à jour installée n’implique pas qu’un service a redémarré correctement ni que l’application fonctionne encore. Pour une application critique :

1. définir quelles mises à jour peuvent être automatiques ;
2. recevoir le résultat des mises à jour ;
3. prévoir les redémarrages nécessaires ;
4. exécuter un contrôle HTTP et applicatif après changement ;
5. conserver un moyen de retour arrière ;
6. traiter rapidement les échecs plutôt que les laisser s’accumuler.

Les composants installés hors APT suivent leur propre cycle : dépendances Composer ou npm, images de conteneurs, extensions PHP, modules du serveur web, agents de sauvegarde. L’objectif n’est pas de lancer aveuglément toutes les mises à jour en production, mais de connaître les versions, leurs avis de sécurité et le délai accepté avant correction.

Pour PHP, éviter une règle figée comme « version supérieure à 8.3 ». La bonne exigence est d’utiliser une branche encore prise en charge selon la page [PHP Supported Versions](https://www.php.net/supported-versions.php), puis de planifier la migration avant sa fin de support.

Checklist de maintenance :

- [ ] Debian est encore supporté.
- [ ] Les dépôts APT sont justifiés et signés.
- [ ] Les correctifs de sécurité sont suivis.
- [ ] Les redémarrages requis sont planifiés.
- [ ] Les dépendances applicatives sont inventoriées.
- [ ] Un test fonctionnel suit chaque mise à jour importante.
- [ ] Les logiciels en fin de vie ont une date de remplacement.

## 3. Sécuriser les comptes et SSH sans se verrouiller dehors

Chaque administrateur doit utiliser un compte nominatif. Le compte `root` reste nécessaire au système, mais sa connexion distante directe peut être interdite ; l’élévation passe alors par `sudo`, ce qui améliore l’attribution des actions.

Pour SSH :

* utiliser des clés modernes protégées par une phrase secrète ;
* retirer les clés des personnes parties ;
* éviter de partager la même clé entre plusieurs administrateurs ;
* réserver l’accès aux comptes ou groupes qui en ont besoin ;
* limiter ou désactiver les redirections SSH pour les comptes restreints ;
* protéger la machine qui conserve la clé privée ;
* utiliser une clé matérielle, un bastion ou un second facteur lorsque le risque le justifie.

Une base possible dans un fichier de `/etc/ssh/sshd_config.d/` est :

```text
PermitRootLogin no
PubkeyAuthentication yes
PasswordAuthentication no
PermitEmptyPasswords no
MaxAuthTries 4
```

Ce bloc n’est pas à copier aveuglément. `PasswordAuthentication no` ne doit être activé qu’après validation d’une clé dans une deuxième session. Si aucun second facteur SSH ne repose sur PAM, contrôler aussi la valeur effective de `KbdInteractiveAuthentication` : désactiver la seule authentification par mot de passe ne ferme pas nécessairement un parcours `keyboard-interactive`. À l’inverse, si le second facteur utilise PAM, cette méthode doit rester active et correctement configurée. Une directive `AllowGroups` n’est utile qu’après création et test du groupe autorisé.

Avant le rechargement :

```bash
sudo /usr/sbin/sshd -t
sudo /usr/sbin/sshd -T | grep -E 'permitrootlogin|pubkeyauthentication|passwordauthentication|kbdinteractiveauthentication'
sudo systemctl reload ssh
```

Conserver la session courante, ouvrir une nouvelle connexion et tester aussi l’élévation `sudo`. Le manuel officiel [`sshd_config`](https://man.openbsd.org/sshd_config) documente les directives et leurs interactions.

Changer le port 22 peut réduire le bruit des robots dans les journaux, mais ne remplace ni l’authentification forte, ni le filtrage, ni les correctifs. Fail2ban peut ralentir des tentatives répétées ; il ne corrige pas une clé volée, un mot de passe réutilisé ou une faille du service.

## 4. Réduire l’exposition réseau

Le principe est simple : refuser par défaut les connexions entrantes, puis autoriser uniquement les flux nécessaires. Pour un serveur web classique, cela signifie souvent HTTP/HTTPS et un chemin d’administration clairement défini. La base de données, Redis, les interfaces de supervision et les consoles ne devraient généralement pas écouter sur Internet.

Points à vérifier :

* le pare-feu de l’hébergeur et celui du système ne se contredisent pas ;
* les règles couvrent IPv4 **et** IPv6 ;
* les services internes écoutent sur `localhost` ou une adresse privée ;
* l’accès d’administration est limité à un VPN, un bastion ou des sources maîtrisées lorsque c’est praticable ;
* les flux sortants sensibles sont connus ;
* les règles temporaires ont une date d’expiration ;
* une console de secours reste disponible en cas d’erreur.

Le [chapitre sécurité du Manuel de l’administrateur Debian](https://www.debian.org/doc/manuals/debian-handbook/security.en.html) décrit notamment `nftables`, la supervision et AppArmor.

Un test externe peut confirmer les ports réellement visibles, mais uniquement contre une adresse que l’on possède ou pour laquelle on dispose d’une autorisation. Un scan interne ne prouve pas ce qu’Internet voit, et l’absence de port inattendu ne prouve pas que l’application est sûre.

Enfin, un pare-feu local ne suffit pas contre une attaque volumétrique. La protection DDoS doit souvent être traitée en amont par l’hébergeur, l’opérateur ou un service de protection adapté.

## 5. Isoler les services et limiter les droits

Un serveur web compromis ne devrait pas pouvoir réécrire son propre code, lire toutes les sauvegardes ou administrer la base. Séparer au minimum :

* le compte d’administration ;
* le compte de déploiement ;
* l’utilisateur Nginx/Apache ;
* les pools PHP-FPM si plusieurs applications doivent être isolées ;
* les comptes de base de données ;
* le compte de sauvegarde ;
* les tâches planifiées sensibles.

Le code et les configurations sont idéalement possédés par un compte d’administration ou de déploiement et seulement lisibles par le service. Le serveur web n’écrit que dans les répertoires prévus : cache, sessions, fichiers téléversés ou données générées. `chmod -R 777` n’est pas une réparation de permissions : il supprime précisément la barrière que les permissions devaient créer.

Quelques contrôles utiles :

- [ ] Les services inutiles sont désactivés ou supprimés.
- [ ] Chaque service tourne sous un compte dédié non privilégié.
- [ ] Les répertoires inscriptibles sont limités et documentés.
- [ ] Les sauvegardes ne sont pas montées en permanence avec les mêmes droits que la production.
- [ ] Les tâches planifiées utilisent des chemins absolus et des fichiers non modifiables par un utilisateur non autorisé.
- [ ] Les profils AppArmor existants sont actifs et leurs refus sont examinés avant adaptation.

Les conteneurs n’annulent pas ces principes. Une image obsolète, un secret injecté sans précaution ou un conteneur trop privilégié déplace le problème sans le résoudre.

## 6. Protéger HTTP, TLS et le serveur web

Tout accès contenant une authentification ou des données personnelles doit utiliser HTTPS. Le certificat peut être renouvelé automatiquement avec ACME, mais l’expiration et l’échec du renouvellement doivent être supervisés.

Pour les protocoles et suites cryptographiques, préférer une configuration maintenue telle que le [générateur de configuration TLS de Mozilla](https://ssl-config.mozilla.org/) plutôt qu’une liste copiée plusieurs années auparavant.

HSTS indique au navigateur qu’un domaine doit uniquement être contacté en HTTPS. Il est efficace, mais doit être activé progressivement. `includeSubDomains` impose aussi HTTPS à tous les sous-domaines, et le préchargement est difficile à annuler rapidement. Vérifier d’abord que chaque sous-domaine nécessaire possède un certificat et répond correctement ; la [documentation HSTS de MDN](https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/Strict-Transport-Security) détaille ces conséquences.

Le serveur web doit également :

* interdire l’accès à `.git`, `.env`, dumps SQL, archives, journaux et fichiers de sauvegarde ;
* désactiver l’indexation de répertoires lorsqu’elle n’est pas voulue ;
* limiter la taille et la durée des requêtes selon les usages ;
* servir les fichiers téléversés avec un type contrôlé et, si nécessaire, hors du domaine principal ;
* séparer les virtual hosts et les racines documentaires ;
* ne pas divulguer une page d’erreur détaillée en production ;
* conserver des journaux exploitables sans enregistrer de secrets.

Les en-têtes comme CSP, `X-Content-Type-Options`, `Referrer-Policy` ou `frame-ancestors` apportent des protections différentes. Ils doivent être adaptés à l’application. Une CSP peut commencer en mode `Content-Security-Policy-Report-Only` pour détecter les dépendances avant de bloquer. Obtenir un bon score dans un test d’en-têtes ne compense pas une autorisation défaillante côté serveur.

## 7. Sécuriser l’application PHP

Le système peut être correctement durci et rester vulnérable par son application. Les contrôles suivants constituent un socle, inspiré des guides de l’[OWASP Cheat Sheet Series](https://cheatsheetseries.owasp.org/) :

### Authentification et sessions

* utiliser `password_hash()` et `password_verify()` pour les mots de passe ;
* régénérer l’identifiant de session après l’authentification et tout changement de privilège ;
* poser les cookies de session avec `Secure` et `HttpOnly` ;
* choisir `SameSite=Lax` ou `Strict` selon les parcours réels ; réserver `SameSite=None` aux échanges intersites réellement nécessaires et l’associer obligatoirement à `Secure` ;
* définir des délais d’inactivité et une durée maximale cohérents avec la sensibilité ;
* invalider les sessions lors d’un changement de mot de passe, d’un départ ou d’un incident ;
* protéger les comptes sensibles par un second facteur et des moyens de récupération contrôlés.

Une déconnexion automatique au bout de 48 heures n’est pas une règle universelle. Pour une administration critique, ce délai peut être beaucoup trop long ; pour une application peu sensible, une déconnexion excessivement courte pousse parfois aux contournements.

### Entrées, sorties et base de données

* valider les données côté serveur selon leur type et leur usage ;
* utiliser des requêtes préparées pour les valeurs SQL ;
* utiliser une liste autorisée pour les identifiants SQL dynamiques comme un nom de colonne ou un sens de tri ;
* encoder la sortie selon son contexte : HTML, attribut, URL, JavaScript ou CSS ;
* vérifier l’autorisation sur chaque ressource, pas seulement l’affichage du bouton ;
* protéger les actions à effet de bord contre les requêtes intersites ;
* limiter les requêtes coûteuses et les tentatives d’authentification.

`htmlspecialchars()` est utile pour du texte inséré dans du HTML, mais ce n’est pas un filtre universel pour JavaScript, une URL ou une requête SQL.

### Fichiers, PDF, API et webhooks

Pour un téléversement, contrôler l’extension, le type attendu, la taille et le nom généré ; stocker le fichier hors de la racine publique lorsque c’est possible ; analyser ou reconstruire les formats à risque ; empêcher leur exécution. Le guide [OWASP File Upload](https://cheatsheetseries.owasp.org/cheatsheets/File_Upload_Cheat_Sheet.html) rappelle aussi les risques de saturation, d’écrasement et de contenu actif.

Un PDF sensible doit rester soumis à une autorisation serveur à chaque accès. Une URL signée et courte peut faciliter un partage contrôlé ; un filigrane peut décourager une redistribution, mais aucun des deux ne remplace le contrôle d’accès.

Pour une API :

* donner aux jetons une portée et une durée limitées ;
* ne jamais les placer dans l’URL ;
* vérifier l’autorisation objet par objet ;
* appliquer des limites de débit adaptées ;
* journaliser les actions critiques sans enregistrer le jeton.

Pour un webhook, vérifier une signature sur le corps brut, inclure un horodatage ou un identifiant d’événement et refuser les rejeux. Le secret du webhook doit pouvoir être renouvelé.

### Ce que le navigateur ne peut pas protéger

Bloquer F12, `Ctrl+U`, le clic droit ou tenter de détecter les outils de développement n’empêche pas un utilisateur de lire les données déjà reçues par son navigateur. Cela gêne surtout l’usage normal et l’accessibilité. La sécurité doit rester côté serveur : authentification, autorisation, limitation des données envoyées et journalisation.

De même, ralentir chaque échec de connexion avec `sleep()` immobilise des workers PHP et peut faciliter un déni de service. Préférer une limitation centralisée et progressive, tenant compte du compte, de l’adresse et du contexte, sans permettre à un attaquant de verrouiller définitivement un utilisateur.

## 8. Protéger la base de données et les secrets

La base ne devrait pas être exposée publiquement si seuls l’application et les administrateurs en ont besoin. Utiliser :

* une écoute locale ou privée ;
* un pare-feu ;
* un compte applicatif distinct par application ;
* les privilèges minimaux ;
* un compte séparé pour les migrations ;
* TLS pour les connexions traversant un réseau non maîtrisé ;
* une journalisation et des sauvegardes adaptées.

L’application ne doit pas se connecter avec le compte administrateur global de la base.

Les secrets — mots de passe, jetons, clés API, clés privées — ne doivent figurer ni dans Git, ni dans la racine web, ni dans une image publique. Selon la taille du système, les conserver dans un gestionnaire de secrets ou dans un fichier de configuration protégé, déployé séparément du code. Une variable d’environnement n’est pas automatiquement secrète : elle peut apparaître dans un diagnostic, un dump ou l’interface d’un orchestrateur.

La gestion des secrets inclut leur cycle de vie : création, distribution, usage, rotation, révocation et récupération. Chiffrer une sauvegarde sans savoir retrouver la clé le jour de la restauration remplace un risque de fuite par un risque de perte définitive.

## 9. Journaliser, superviser et tester les alertes

Les journaux servent à détecter, comprendre et prouver. Ils doivent couvrir au minimum :

* connexions et élévations de privilèges ;
* changements de comptes, clés et permissions ;
* erreurs du serveur web et de l’application ;
* authentifications et changements sensibles ;
* tâches planifiées et déploiements ;
* résultats de sauvegarde ;
* événements de pare-feu utiles ;
* actions d’administration de la base et du cloud lorsque disponibles.

Ne pas enregistrer les mots de passe, jetons, secrets de session, contenus sensibles ou données personnelles sans nécessité. La fiche [OWASP Logging](https://cheatsheetseries.owasp.org/cheatsheets/Logging_Cheat_Sheet.html) insiste sur la protection des journaux et sur la distinction entre journalisation de sécurité et simple diagnostic.

Une copie distante ou protégée limite la possibilité pour un attaquant d’effacer toutes ses traces. Le guide de l’[ANSSI sur l’administration sécurisée](https://messervices.cyber.gouv.fr/guides/en-recommendations-secure-administration-it-systems) recommande de préserver l’intégrité des journaux et d’en restreindre l’accès.

Surveiller au minimum :

* disponibilité HTTP et validité TLS ;
* espace disque et inodes ;
* CPU, mémoire et charge ;
* erreurs applicatives ;
* échecs de connexion inhabituels ;
* ouverture d’un nouveau port ;
* changement de fichiers critiques ;
* retard ou échec de sauvegarde ;
* réplication et santé de la base ;
* expiration d’un domaine ou certificat.

Une alerte sans destinataire, seuil pertinent ni procédure n’est pas une protection. Tester périodiquement que l’alerte arrive, qu’une personne la comprend et qu’elle sait quoi faire.

## 10. Sauvegarder pour restaurer, pas seulement pour copier

Une stratégie de sauvegarde doit couvrir plus que la base :

* code et version déployée ;
* configuration du système et des services ;
* base de données ;
* fichiers téléversés et documents ;
* tâches planifiées ;
* liste des paquets et dépendances ;
* secrets nécessaires à la reprise ;
* clés de chiffrement et procédure de récupération ;
* configuration DNS, certificats et services externes ;
* documentation de reconstruction.

Le guide de l’[ANSSI sur la sauvegarde des systèmes d’information](https://messervices.cyber.gouv.fr/guides/fondamentaux-sauvegarde-systemes-dinformation) recommande une logique « 3-2-1 » : trois copies des données, sur deux types de supports, dont une hors ligne. La sauvegarde hors ligne ou correctement immuable doit utiliser des accès séparés de la production ; sinon un compte compromis peut chiffrer le serveur **et** ses copies.

Définir pour chaque service :

* **RPO** : quantité maximale de données que l’entreprise accepte de perdre ;
* **RTO** : durée visée avant le rétablissement du service ;
* responsable du déclenchement ;
* ordre de restauration ;
* critères de validation métier.

Ces valeurs ne doivent pas être promises avant un test complet. Restaurer un fichier SQL en cinq minutes ne signifie pas que l’application, les fichiers, les comptes, le DNS et les intégrations fonctionneront en trente minutes.

### Procédure générique de restauration

1. Qualifier l’incident et décider si les sauvegardes sont susceptibles d’être compromises.
2. Choisir une sauvegarde antérieure et vérifier son intégrité.
3. Construire une base propre sur une version supportée.
4. Restaurer les configurations et secrets depuis une source maîtrisée.
5. Restaurer la base et les fichiers dans l’ordre prévu.
6. Exécuter les migrations et contrôles d’intégrité nécessaires.
7. Tester l’authentification, les droits, les fonctions métier et les intégrations.
8. Rouvrir progressivement le trafic.
9. Renforcer temporairement la surveillance.
10. Documenter le temps réel, les écarts et les corrections à apporter au plan.

Consigner chaque exercice :

| Champ | Exemple de contenu |
|---|---|
| Périmètre | Base, documents, configuration, service externe |
| Sauvegarde utilisée | Date, emplacement, type de copie |
| Personnes présentes | Technique et validation métier |
| Durée mesurée | Préparation, transfert, restauration, validation |
| Échecs | Clé absente, version incompatible, fichier manquant |
| Résultat | Réussi, partiel ou échoué |
| Action | Responsable et échéance |

Le dossier [archive inaltérable, Synology et cloud français](/blog/archive-inalterable-synology-cloud-francais/) détaille la différence entre sauvegarde, snapshot, versionnement et archivage.

## 11. Réagir à une suspicion de compromission

Une réaction précipitée peut détruire des traces ou restaurer trop tôt un système encore compromis. En cas de doute sérieux :

1. noter l’heure, les symptômes et les premières décisions ;
2. limiter l’exposition ou isoler le service sans supprimer inutilement les preuves ;
3. utiliser un poste sain pour les communications et changements de secrets ;
4. préserver les journaux et éléments volatils lorsque l’équipe sait le faire ;
5. rechercher l’étendue : comptes, autres serveurs, cloud, sauvegardes, postes administrateurs ;
6. contacter le prestataire de réponse prévu, l’assureur et les interlocuteurs juridiques selon le contexte ;
7. reconstruire depuis une base connue plutôt que déclarer une machine « nettoyée » sans preuve ;
8. restaurer, tester puis surveiller ;
9. évaluer rapidement les obligations de notification et d’information ;
10. conduire un retour d’expérience.

Le service public [17Cyber](https://17cyber.gouv.fr/) aide à qualifier la situation et à trouver l’assistance adaptée. Pour les incidents importants, les guides de l’[ANSSI sur la remédiation](https://cyber.gouv.fr/securisation/gestion-de-crise/piloter-la-remediation-dun-incident-cyber/) expliquent pourquoi investigation, reprise de contrôle et rétablissement doivent être coordonnés.

## Checklist de mise en production

- [ ] Le service et les données critiques sont identifiés.
- [ ] Debian, PHP et les composants sont encore supportés.
- [ ] Les ports et services exposés sont justifiés.
- [ ] Le pare-feu couvre IPv4 et IPv6.
- [ ] SSH a été testé avec une seconde session avant durcissement.
- [ ] Les comptes sont nominatifs et les droits minimaux.
- [ ] Le serveur web ne peut écrire que dans les dossiers prévus.
- [ ] `.git`, `.env`, dumps, sauvegardes et journaux ne sont pas publics.
- [ ] HTTPS et le renouvellement des certificats sont supervisés.
- [ ] La base n’est pas exposée inutilement et l’application n’utilise pas un compte administrateur.
- [ ] Les secrets sont séparés du code et peuvent être renouvelés.
- [ ] L’application contrôle sessions, autorisations, CSRF, requêtes SQL et téléversements.
- [ ] Les journaux utiles sont conservés hors de portée immédiate du service compromis.
- [ ] Les alertes importantes ont un destinataire et une procédure.
- [ ] Une sauvegarde séparée existe.
- [ ] Une restauration complète a été testée et chronométrée.
- [ ] Une fiche d’incident et des contacts de secours sont disponibles hors ligne.

## Fréquence de contrôle

| Fréquence | Contrôles |
|---|---|
| Continu ou quotidien | Disponibilité, erreurs critiques, espace disque, sauvegardes, certificats proches de l’expiration |
| Hebdomadaire | Correctifs urgents, alertes de sécurité, échecs d’authentification inhabituels |
| Mensuel | Paquets et dépendances, comptes privilégiés, services exposés, capacité des volumes |
| Trimestriel | Test de restauration, revue des clés et accès tiers, exercice d’incident ciblé |
| Annuel ou après changement majeur | Analyse de risques, test de reprise complet, revue d’architecture et des fournisseurs |

La fréquence exacte dépend du rythme de changement et de la criticité. Un serveur modifié chaque jour nécessite des contrôles plus fréquents qu’un service stable et isolé.

## Erreurs fréquentes

* considérer Fail2ban comme la protection principale ;
* changer le port SSH et conserver une authentification faible ;
* appliquer une configuration trouvée en ligne sans tester `sshd` ou le pare-feu ;
* bloquer F12 ou le clic droit ;
* utiliser `chmod 777` pour résoudre un problème de déploiement ;
* conserver les sauvegardes montées avec les mêmes identifiants que la production ;
* chiffrer sans procédure de récupération des clés ;
* activer HSTS avec `includeSubDomains` avant d’avoir migré tous les sous-domaines ;
* journaliser les jetons et mots de passe ;
* automatiser les mises à jour sans surveiller leur résultat ;
* annoncer un RTO sans test chronométré ;
* confondre une checklist remplie avec une sécurité démontrée.

## FAQ

### Faut-il changer le port SSH ?

Ce changement réduit surtout le bruit automatisé. Il ne remplace pas les clés, la suppression de l’accès root distant, le filtrage et les correctifs.

### Fail2ban suffit-il à protéger SSH ?

Non. Il peut bloquer des tentatives répétées, mais ne protège pas contre une clé privée volée, une faille du service ou un accès déjà autorisé.

### Faut-il automatiser toutes les mises à jour ?

Les correctifs de sécurité peuvent être automatisés dans un cadre surveillé. Les changements majeurs et redémarrages doivent rester compatibles avec l’application, les tests et la procédure de retour arrière.

### Combien de sauvegardes faut-il conserver ?

Le nombre dépend du RPO, du rythme des données et du temps pendant lequel une corruption peut rester invisible. Il faut surtout plusieurs générations, des accès séparés et au moins une copie hors ligne ou immuable réellement restaurable.

### Un snapshot du VPS est-il une sauvegarde ?

Il facilite un retour rapide mais reste souvent lié au même compte, au même fournisseur et au même incident. Il doit compléter, pas remplacer, une copie indépendante.

### HSTS doit-il être activé immédiatement ?

Non. Commencer avec une durée courte et sans `includeSubDomains`, vérifier le domaine, les sous-domaines et le renouvellement TLS, puis augmenter progressivement.

### Peut-on empêcher un visiteur d’ouvrir les outils de développement ?

Non de manière fiable. Tout contenu envoyé au navigateur peut être inspecté. Les données sensibles ne doivent pas être envoyées sans autorisation serveur.

### À quelle fréquence faut-il tester la restauration ?

À une fréquence cohérente avec la criticité et les changements. Un test trimestriel est un repère possible, mais un changement majeur de base, stockage, chiffrement ou hébergeur doit déclencher un nouveau test.

## Pour aller plus loin

* [Votre NAS n’est pas un coffre-fort : construire une archive inaltérable](/blog/archive-inalterable-synology-cloud-francais/)
* [DNSSEC : BIND9, Unbound, dnsmasq, KSK et ZSK](/blog/dnssec-ksk-zsk/)
* [Sécurité des e-mails : SPF, DKIM et DMARC](/blog/securite-email-spf-dkim-dmarc/)
* [Proxy inverse Nginx devant Apache](/blog/proxy-inverse-nginx-apache/)
* [Dix ans de cyberattaques : enquête sur une guerre invisible](/blog/panorama-cyberattaques-10-ans/)

## Conclusion

Un serveur sûr n’est pas un serveur sur lequel on a coché le plus d’options. C’est un système dont l’exposition est comprise, les accès sont maîtrisés, les composants sont maintenus, les alertes sont traitées et la reconstruction a déjà été répétée.

Le meilleur contrôle final reste concret : prendre une sauvegarde choisie au hasard dans la période de rétention, reconstruire le service dans un environnement propre, mesurer le temps nécessaire et faire valider le résultat par quelqu’un qui connaît réellement l’application.