Renforcement de la sécurité des serveurs de production : une liste de contrôle complète

Le délai moyen pour identifier une violation de données est de 204 jours. Le renforcement des serveurs de production réduit votre surface d'attaque afin que les violations soient plus difficiles à initier et plus rapides à détecter. Ce guide couvre les mesures de sécurité concrètes que chaque serveur de production doit mettre en œuvre, de la configuration SSH aux pare-feu d'applications Web.

Points clés à retenir

• L'authentification par clé SSH uniquement et les ports non standard bloquent 99 % des attaques automatisées par force brute
• Un pare-feu correctement configuré réduit la surface d'attaque de milliers de points d'entrée à moins de dix
• Les pare-feu d'applications Web bloquent l'injection SQL, XSS et d'autres attaques OWASP Top 10 au niveau de la couche réseau.
• L'application automatisée de correctifs garantit que les vulnérabilités sont corrigées dans les heures qui suivent leur divulgation, et non dans les semaines qui suivent.

---

Renforcement SSH

###Configuration

# /etc/ssh/sshd_config

# Disable password authentication
PasswordAuthentication no
ChallengeResponseAuthentication no

# Disable root login
PermitRootLogin no

# Use SSH keys only
PubkeyAuthentication yes
AuthorizedKeysFile .ssh/authorized_keys

# Limit login attempts
MaxAuthTries 3
MaxSessions 5

# Set idle timeout (5 minutes)
ClientAliveInterval 300
ClientAliveCountMax 0

# Restrict SSH to specific users
AllowUsers deploy ubuntu

# Disable X11 forwarding
X11Forwarding no

# Use only strong algorithms
KexAlgorithms [email protected],diffie-hellman-group-exchange-sha256
Ciphers [email protected],[email protected],[email protected]
MACs [email protected],[email protected]

Échec2Ban

# /etc/fail2ban/jail.local
[sshd]
enabled = true
port = ssh
filter = sshd
logpath = /var/log/auth.log
maxretry = 3
bantime = 3600
findtime = 600

[nginx-http-auth]
enabled = true
filter = nginx-http-auth
logpath = /var/log/nginx/error.log
maxretry = 5
bantime = 3600

---

Configuration du pare-feu

UFW (Ubuntu)

# Reset and set default policies
sudo ufw default deny incoming
sudo ufw default allow outgoing

# Allow SSH (consider changing port)
sudo ufw allow 22/tcp

# Allow HTTP/HTTPS
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp

# Allow specific IPs for management
sudo ufw allow from 203.0.113.10 to any port 9090 comment "Grafana"
sudo ufw allow from 203.0.113.10 to any port 9093 comment "Alertmanager"

# Deny everything else (implicit with default deny)
sudo ufw enable
sudo ufw status verbose

Groupes de sécurité AWS

# Terraform security group
resource "aws_security_group" "app" {
  name_prefix = "app-"
  vpc_id      = aws_vpc.main.id

  # Allow HTTPS from anywhere
  ingress {
    from_port   = 443
    to_port     = 443
    protocol    = "tcp"
    cidr_blocks = ["0.0.0.0/0"]
    description = "HTTPS from internet"
  }

  # Allow SSH from office IP only
  ingress {
    from_port   = 22
    to_port     = 22
    protocol    = "tcp"
    cidr_blocks = ["203.0.113.0/24"]
    description = "SSH from office"
  }

  # Allow all outbound
  egress {
    from_port   = 0
    to_port     = 0
    protocol    = "-1"
    cidr_blocks = ["0.0.0.0/0"]
  }
}

# Database security group - no public access
resource "aws_security_group" "db" {
  name_prefix = "db-"
  vpc_id      = aws_vpc.main.id

  ingress {
    from_port       = 5432
    to_port         = 5432
    protocol        = "tcp"
    security_groups = [aws_security_group.app.id]
    description     = "PostgreSQL from app servers only"
  }
}

---

En-têtes de sécurité Nginx

# Security headers for all responses
add_header X-Frame-Options "DENY" always;
add_header X-Content-Type-Options "nosniff" always;
add_header Referrer-Policy "strict-origin-when-cross-origin" always;
add_header Permissions-Policy "camera=(), microphone=(), geolocation=()" always;
add_header Strict-Transport-Security "max-age=63072000; includeSubDomains; preload" always;
add_header Content-Security-Policy "default-src 'self'; script-src 'self'; style-src 'self' 'unsafe-inline'; img-src 'self' data: https:; font-src 'self'; connect-src 'self' https://api.example.com;" always;

# Hide server version
server_tokens off;

# Limit request size
client_max_body_size 10m;

# Rate limiting
limit_req_zone $binary_remote_addr zone=general:10m rate=10r/s;
limit_req_zone $binary_remote_addr zone=api:10m rate=30r/s;
limit_req_zone $binary_remote_addr zone=login:10m rate=5r/m;

server {
    location / {
        limit_req zone=general burst=20 nodelay;
    }

    location /api/ {
        limit_req zone=api burst=50 nodelay;
    }

    location /auth/ {
        limit_req zone=login burst=3 nodelay;
    }
}

---

Configuration SSL/TLS

# Modern TLS configuration
ssl_protocols TLSv1.2 TLSv1.3;
ssl_ciphers 'ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384';
ssl_prefer_server_ciphers off;

# OCSP stapling
ssl_stapling on;
ssl_stapling_verify on;

# Session configuration
ssl_session_timeout 1d;
ssl_session_cache shared:SSL:10m;
ssl_session_tickets off;

# Certificate (Let's Encrypt)
ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;

Renouvellement automatisé des certificats

# /etc/cron.d/certbot
0 0,12 * * * root certbot renew --quiet --post-hook "nginx -s reload"

---

Sécurité des conteneurs

Si vous exécutez Docker en production, appliquez ces mesures de renforcement supplémentaires :

Sécurité du démon Docker

{
  "userns-remap": "default",
  "no-new-privileges": true,
  "live-restore": true,
  "userland-proxy": false,
  "log-driver": "json-file",
  "log-opts": {
    "max-size": "10m",
    "max-file": "3"
  }
}

Restrictions d'exécution du conteneur

# docker-compose.yml security settings
services:
  api:
    security_opt:
      - no-new-privileges:true
    read_only: true
    tmpfs:
      - /tmp
    cap_drop:
      - ALL
    cap_add:
      - NET_BIND_SERVICE

Principes clés :

- Supprimez toutes les fonctionnalités et rajoutez uniquement ce qui est nécessaire

• Le système de fichiers en lecture seule empêche les attaquants de modifier le contenu du conteneur
• Aucun nouveau privilège n'empêche l'élévation des privilèges à l'intérieur des conteneurs
• Utilisateur non root dans le Dockerfile (voir notre Guide de déploiement Docker)

Sécurité des images

• Utiliser des images de base officielles et minimales (variantes alpines)
• Épingler les versions d'images (n'utilisez jamais :latest en production)
• Scanner les images à la recherche de vulnérabilités avec Trivy ou Grype
• Signez des images avec Docker Content Trust
• Utiliser un registre privé avec des contrôles d'accès

---

Sécurité de la base de données

Renforcement de PostgreSQL

# postgresql.conf security settings
listen_addresses = 'localhost'        # Only listen on localhost
ssl = on                              # Require SSL for connections
ssl_cert_file = '/path/to/server.crt'
ssl_key_file = '/path/to/server.key'
password_encryption = scram-sha-256   # Modern password hashing
log_connections = on                  # Log all connections
log_disconnections = on               # Log disconnections
log_statement = 'ddl'                 # Log DDL statements

# pg_hba.conf - restrict connections
# TYPE  DATABASE  USER  ADDRESS      METHOD
local   all       all                scram-sha-256
host    all       all   10.0.0.0/8   scram-sha-256
hostssl all       all   0.0.0.0/0    scram-sha-256

• N'exposez jamais PostgreSQL à l'Internet public
• Utiliser des utilisateurs de base de données dédiés avec les autorisations minimales requises
• Activer le cryptage de connexion (SSL)
• Définir des politiques de mot de passe fortes
• Vérification régulière des sauvegardes (voir notre guide de reprise après sinistre)

---

Détection d'intrusion

###Configuration OSSEC

<!-- /var/ossec/etc/ossec.conf -->
<ossec_config>
  <syscheck>
    <!-- Monitor critical files for changes -->
    <directories check_all="yes">/etc,/usr/bin,/usr/sbin</directories>
    <directories check_all="yes">/opt/app/dist</directories>

    <!-- Ignore frequently changing files -->
    <ignore>/etc/mtab</ignore>
    <ignore>/etc/resolv.conf</ignore>

    <!-- Run integrity check every 6 hours -->
    <frequency>21600</frequency>
  </syscheck>

  <rootcheck>
    <rootkit_files>/var/ossec/etc/shared/rootkit_files.txt</rootkit_files>
    <rootkit_trojans>/var/ossec/etc/shared/rootkit_trojans.txt</rootkit_trojans>
  </rootcheck>
</ossec_config>

AWS GuardDuty

resource "aws_guardduty_detector" "main" {
  enable = true

  datasources {
    s3_logs {
      enable = true
    }
    kubernetes {
      audit_logs {
        enable = true
      }
    }
  }
}

---

Correctifs de sécurité automatisés

# Ubuntu: Enable unattended security updates
sudo apt install unattended-upgrades
sudo dpkg-reconfigure -plow unattended-upgrades

# /etc/apt/apt.conf.d/50unattended-upgrades
Unattended-Upgrade::Allowed-Origins {
    "${distro_id}:${distro_codename}-security";
};

Unattended-Upgrade::Automatic-Reboot "true";
Unattended-Upgrade::Automatic-Reboot-Time "03:00";
Unattended-Upgrade::Mail "[email protected]";

---

Liste de contrôle pour le renforcement de la sécurité

Niveau du serveur

• Authentification par clé SSH uniquement, connexion root désactivée
• Pare-feu configuré avec une politique de refus par défaut
• Fail2Ban actif sur SSH et le serveur web
• Mises à jour de sécurité automatiques activées
• Services non essentiels désactivés
• Surveillance de l'intégrité des fichiers (OSSEC ou équivalent)
• Journalisation d'audit activée (auditd)

Niveau d'application

• TLS 1.2+ sur tous les points de terminaison, HSTS activé -[ ] En-têtes de sécurité configurés (CSP, X-Frame-Options, etc.)
• Limitation de débit sur tous les points de terminaison publics
• Validation des entrées et requêtes paramétrées (pas de sql.raw())
• HttpOnly, cookies sécurisés pour l'authentification
• CORS limité aux origines connues
• Les réponses d'erreur ne fuient pas les traces de la pile

Niveau réseau

• Base de données non accessible au public
• Services internes sur sous-réseaux privés
• Points de terminaison VPC pour les services AWS (pas d'Internet public)
• WAF sur les points de terminaison publics
• Protection DDoS (Cloudflare, AWS Shield)

Surveillance

• Alerte d'événement de sécurité configurée
• Conservation des journaux pendant au moins 90 jours
• Tentatives d'authentification échouées surveillées
• Modèles de trafic inhabituels détectés

---

Questions fréquemment posées

À quelle fréquence devons-nous effectuer des audits de sécurité ?

Analyses automatisées trimestrielles (analyse des vulnérabilités, audits de dépendances) et tests d'intrusion manuels annuels. Les applications à haut risque (traitement des paiements, données de santé) doivent faire l'objet de tests d'intrusion externes tous les 6 mois. Chaque déploiement de production doit inclure une analyse de sécurité automatisée dans le pipeline CI/CD --- consultez notre guide des meilleures pratiques CI/CD.

Un WAF est-il nécessaire si nous avons déjà une limitation de débit ?

Oui. La limitation du débit empêche les abus mais n'inspecte pas le contenu de la demande. Un WAF bloque l'injection SQL, XSS et d'autres attaques au niveau de la couche application en analysant les charges utiles des requêtes. Considérez la limitation de débit comme une protection contre les inondations et le WAF comme une inspection du contenu : vous avez besoin des deux.

Comment sécuriser un serveur de production Odoo ?

En plus du renforcement général ci-dessus : désactivez le gestionnaire de base de données en production (list_db = False), définissez un admin_passwd fort, utilisez dbfilter pour restreindre l'accès à la base de données, exécutez Odoo derrière Nginx (n'exposez jamais Odoo directement) et gardez Odoo et tous les modules à jour. ECOSIRE fournit le renforcement de la sécurité Odoo dans le cadre de nos services d'hébergement gérés.

Quelle est la mesure de sécurité la plus efficace ?

Activation de la MFA (Multi-Factor Authentication) sur tous les comptes administratifs. Ce contrôle unique empêche 99 % des attaques basées sur les identifiants. Implémentez MFA sur SSH (via PAM), la console AWS, les outils d'administration de base de données et les panneaux d'administration d'application avant toute autre mesure de renforcement.

---

Ce qui vient ensuite

Le renforcement de la sécurité est une pratique continue. Combinez-le avec surveillance et alerte pour la détection, reprise après sinistre pour la résilience et analyse de sécurité CI/CD pour la prévention.

Contactez ECOSIRE pour obtenir des conseils en matière de renforcement de la sécurité, ou explorez notre guide DevOps pour obtenir la feuille de route complète de l'infrastructure.

---

Publié par ECOSIRE – aider les entreprises à sécuriser leur infrastructure de production.