Architecture de protection serveur portable

Cette page ajoute un second document de reference de securite a la documentation iTafaray. Il decrit une pile de protection serveur portable, reutilisable sur AWS ou sur des serveurs Linux hors AWS, avec un ordre de mise en place progressif.

Important

Le document privilegie une approche defensive par couches : nftables, Nginx, ModSecurity + CRS, fail2ban, Suricata et ELK. Il complete les guides d’installation applicatifs en decrivant la securisation de l’entree reseau, l’inspection HTTP et la centralisation des journaux.

Documents disponibles

Voir aussi

Guide associe pour le serveur de securite X-Road : Guide d’installation du serveur de securite X-Road

Vue d’ensemble

Le document couvre notamment :

  • l’architecture logique cible avec point d’entree HTTPS unique via Nginx ;

  • les prerequis systeme, reseau, DNS, TLS, stockage de logs et maintenance ;

  • l’ordre recommande de mise en place des couches de protection ;

  • les configurations minimales a valider avant mise en production ;

  • les flux reseau cibles et les risques a surveiller.

Pile recommandee

Couche

Role

Positionnement

nftables

Filtrage reseau de base et reduction de la surface exposee

Sur chaque serveur Linux

Nginx

Point d’entree HTTPS unique et reverse proxy

Face publique du serveur

ModSecurity + CRS

WAF HTTP pour bloquer ou journaliser les requetes suspectes

Module rattache a Nginx

fail2ban

Blocage automatique des IP abusives a partir des logs

Sur chaque serveur expose

Suricata

Detection IDS/IPS complementaire au niveau reseau

Sur le serveur ou sur une sonde dediee

ELK

Centralisation et correlation des journaux

Idealement sur une instance separee

Ordre recommande de mise en place

  1. Mettre a jour l’OS, nettoyer les paquets inutiles et stabiliser la journalisation.

  2. Installer nftables et verrouiller les ports exposes.

  3. Mettre Nginx en point d’entree unique HTTPS.

  4. Ajouter ModSecurity + CRS en mode detection avant de generaliser le blocage.

  5. Activer fail2ban sur SSH et Nginx.

  6. Ajouter Suricata en mode IDS puis evaluer la charge et les faux positifs.

  7. Brancher la collecte vers ELK et construire les tableaux de bord de suivi.

Points de vigilance

  • Ne pas exposer directement les applications backend sur une interface publique.

  • Limiter les ports publics au strict necessaire : 443/TCP obligatoire, 80/TCP seulement pour la redirection, 22/TCP reserve a l’administration.

  • Garder ELK hors du serveur applicatif si les ressources sont limitees.

  • Prevoir une rotation de logs et un espace disque suffisant avant d’activer Suricata et la centralisation de journaux.

  • Introduire l’IPS inline dans un second temps seulement, apres observation du trafic reel.