Une checklist complète pour sécuriser un serveur Debian, du système d'exploitation jusqu'à l'application, en passant par le réseau et la supervision. À valider progressivement.

1. Sécurité du serveur

  • [ ] Système du serveur à jour (correctifs de sécurité)
  • [ ] Services inutiles désactivés (FTP, SNMP...)
  • [ ] SSH par clé, pas de mot de passe
  • [ ] Fail2ban actif (SSH + HTTP)
  • [ ] PHP à jour > 8.3 et display_errors=Off
  • [ ] Base de données : accès limité, SSL activé
  • [ ] Fichiers .git et configs non accessibles
  • [ ] Backups chiffrés et testés

2. Sécurité Réseau

  • [ ] HTTPS forcé + HSTS activé
  • [ ] Firewall actif, ports inutiles fermés
  • [ ] Accès admin restreint par IP
  • [ ] Protection brute-force (limite tentatives + Captcha)
  • [ ] Surveillance via Nmap ou équivalent

3. Sécurité de l'application (Back-end)

  • [ ] password_hash() et password_verify() utilisés
  • [ ] session_regenerate_id(true) après login
  • [ ] Cookies sécurisés (HttpOnly, Secure, SameSite=Strict)
  • [ ] Timeout de session actif
  • [ ] Token CSRF unique par session
  • [ ] htmlspecialchars() pour toute sortie
  • [ ] PDO + requêtes préparées partout
  • [ ] Pas de chemins dynamiques non filtrés (include/ORDER BY)
  • [ ] PDF protégés par token signé + expiration
  • [ ] Filigrane dynamique sur PDF sensible

4. Sécurité du front-end

  • [ ] initSecure actif pour bloquer F12, Ctrl+U et le clic droit
  • [ ] Détection DevTools pour bascule PDF Canvas
  • [ ] innerHTML jamais utilisé avec des données non filtrées
  • [ ] Validation JS côté client

5. Surveillance et réaction

  • [ ] Log des connexions et actions critiques
  • [ ] Alerte mail en cas de comportement suspect
  • [ ] Monitoring CPU / RAM / SSL / stockage
  • [ ] Backups réguliers et testés
  • [ ] Plan de restauration documenté

Sécurité et Protection des Données

Un ERP bien conçu intègre les meilleures pratiques de sécurité informatique. Même sans revendiquer officiellement de certifications (ISO ou NF), les mécanismes suivants appliquent les principes de ces référentiels afin de garantir la protection des données.

  • Confidentialité et anonymisation : les données sensibles sont protégées et anonymisées conformément aux recommandations du RGPD.
  • Sauvegardes automatiques et régulières : dispositif inspiré des exigences de continuité d'ISO 27001, avec des sauvegardes testées et vérifiées.
  • Mises à jour automatiques : application des correctifs de sécurité et maintenance préventive afin de rester aligné sur les bonnes pratiques SaaS.
  • Chiffrement des données sensibles : protection conforme aux standards AES/SSL pour sécuriser les bases de données.
  • Traçabilité complète : journalisation conforme aux recommandations de la norme NF525 afin d'assurer la traçabilité et l'inaltérabilité des données.
  • Gestion stricte des accès : contrôle par rôles et privilèges inspiré des modèles RBAC (ISO 27001).
  • Protection réseau : mécanismes de défense contre les attaques DDoS et les tentatives d'intrusion, avec filtrage IP et firewall applicatif.
  • Déconnexion automatique après 48h d'inactivité et verrouillage d'écran pour les sessions sensibles.
  • Restriction par adresses IP pour les accès administratifs critiques.
  • API REST sécurisée pour les requêtes clients, avec gestion de tokens et contrôle des permissions.
  • Webhooks sécurisés pour les notifications serveur, avec signature pour prévenir toute falsification.
  • Protection contre la force brute : les tentatives de connexion sont limitées et ralenties par un délai de sécurité (sleep()) afin de décourager les attaques automatisées.

Ces pratiques s'inscrivent dans l'esprit de normes telles que le RGPD pour la protection des données, ISO 27001 pour la sécurité des systèmes d'information et NF525 pour la traçabilité. Même sans certification officielle, les protections sont mises en place avec le même niveau d'exigence.

Plan de Restauration des Données

Ce plan présente, de manière anonymisée, le processus de restauration des données en cas d'incident. Aucune information sensible n'y figure, mais il illustre la démarche professionnelle mise en place en matière de sécurité.

# Plan de restauration ERP (anonymisé)

Dernière mise à jour : 31/07/2025
Responsable : Équipe IT (Administrateur système)

## 1. Localisation des backups
- NAS local : \\XXX.XXX.XXX.XXX\backup\PROJET_ERP
- Cloud : S3 bucket `CLOUD_BACKUP` (clé sécurisée en coffre-fort)

## 2. Procédure de restauration
1. Monter le NAS ou télécharger depuis le cloud sécurisé
2. Restaurer la base de données :
   mysql -u user -p projet_erp < backup.sql
3. Restaurer le code source et les fichiers upload
4. Vérifier les permissions :
   chown -R www-data:www-data /var/www/projet_erp
5. Tester l'application

## 3. Durée estimée
- RTO : 30 minutes
- RPO : 24h max de perte de données

## 4. Validation
- Dernier test de restauration : 01/07/2025

1. Objectifs

  • Assurer une restauration rapide des services critiques.
  • Limiter la perte de données à moins de 3h.
  • Garantir la continuité d'activité pour les clients.

2. Données concernées

  • Base de données (clients, documents, historiques)
  • Fichiers applicatifs et codes sources
  • Documents générés (PDF, exports, uploads)
  • Configurations système et tâches planifiées

3. Localisation et sécurité des sauvegardes

  • Sauvegarde locale quotidienne sur un NAS interne sécurisé
  • Sauvegarde distante chiffrée sur un cloud sécurisé
  • Accès aux sauvegardes protégé par une authentification forte
  • Rotation automatique avec conservation sur 30 jours

4. Procédure de restauration

  1. Identifier la sauvegarde la plus récente valide.
  2. Restaurer la base de données à partir de l'archive chiffrée.
  3. Redéployer les fichiers applicatifs et les documents.
  4. Vérification des permissions et redémarrage des services.
  5. Contrôle fonctionnel de l'application après restauration.

Temps de restauration estimé : moins de 30 minutes.

5. Validation et tests

  • Test de restauration effectué tous les trimestres.
  • Suivi d'un RTO (Recovery Time Objective) et RPO (Recovery Point Objective).
  • Mise à jour de la documentation après chaque test.

6. Responsabilités

  • L'équipe technique est responsable du déclenchement de la restauration.
  • Les procédures sont documentées et validées par la direction technique.
  • Les accès aux sauvegardes et clés de chiffrement sont limités.