Sécuriser son Infrastructure

Sécuriser son Infrastructure

De SSH aux agents IA — sécuriser chaque couche de votre infrastructure

Sécurisez votre infrastructure serveur — SSH, pare-feux, TLS, monitoring, Fail2ban et réponse aux incidents. Exemples concrets, commandes et checklists pour VPS Ubuntu.

180 pages DE, EN, ES, FR, JA, KO, PT, RU, TH

Ce que vous allez apprendre

  • Vous savez vous connecter à un serveur en SSH.
  • Vous savez ce qu'est un Docker container, un reverse proxy, et une API.
  • Vous avez un agent IA capable d'exécuter des commandes sur votre serveur (Hermes, Claude Code, etc.).
  • Vous ne devez pas être expert en sécurité — c'est le but de ce livre.
  • Chapitre 1** — Sécuriser un VPS Ubuntu : SSH, pare-feu, monitoring, incident response. Les fondations sans lesquelles tout le reste est inutile.
  • Chapitre 2** — Sécuriser un serveur web : TLS, headers de sécurité, Docker, FastAPI, rate limiting. Ce qui protège vos utilisateurs quand ils accèdent à vos services.
  • Chapitre 3** — Sécuriser des agents IA autonomes : prompt injection, permissions, sandboxing, kill switches. Le nouveau frontier de la sécurité en 2026.
  • Chapitre 4** — Checklist complète : pré-déploiement, audit mensuel, outils automatisés. Tout consolider en un processus reproductible.

Chapitres détaillés

  • Introduction
    • Mon serveur n'est pas intéressant pour les hackers — vrai ou faux ?
    • Pourquoi ce livre
    • Comment utiliser ce livre
    • Prérequis
    • Ce que vous allez apprendre
    • Un mot sur les exemples
    • La sécurité est un processus
  • Chapitre 1 : Sécuriser un VPS Ubuntu
    • 1.1 SSH — la porte d'entrée
  • 1.2 Pare-feu (UFW)
    • 1.2 Pare-feu (UFW)
  • 1.3 Monitoring et logs
    • 1.3 Monitoring et logs
  • 1.4 Incident response — que faire quand ça arrive
    • 1.4 Incident response — que faire quand ça arrive
  • 1.5 Mises à jour automatiques
    • 1.5 Mises à jour automatiques
    • Résumé du chapitre
  • 1.6 Fail2ban — bannir automatiquement les attaquants
    • 1.6 Fail2ban — bannir automatiquement les attaquants
  • 1.7 Prompts d'audit — VPS Ubuntu
    • 1.7 Prompts d'audit — VPS Ubuntu
  • 2.1 TLS — chiffrer les communications
    • HTTP vs HTTPS : ce que VOUS perdez sans TLS
    • TLS 1.3 vs 1.2 : pourquoi upgrader
    • Certificats : la logique, pas les commandes
    • HSTS : forcer HTTPS
    • Mixed content : quand HTTPS ne protège pas
    • Prompt IA : audit configuration TLS
  • 2.2 Headers de sécurité
    • Pourquoi les headers HTTP sont votre première ligne de défense web
    • Content-Security-Policy : le header le plus puissant
    • X-Frame-Options : anti-clickjacking
    • X-Content-Type-Options : anti-MIME sniffing
    • Referrer-Policy : contrôler ce qui est partagé
    • Permissions-Policy : restreindre les API navigateur
    • Prompt IA : audit headers de sécurité
  • 2.3 Rate limiting et WAF
    • Pourquoi rate limiter
    • Rate limit vs throttling
    • Où appliquer le rate limiting
    • Les erreurs courantes de rate limiting
    • WAF : quand c'est utile, quand ce n'est pas suffisant
    • fail2ban pour Nginx : le lien firewall ↔ web
    • Prompt IA : audit rate limiting et WAF
  • 2.4 Docker — isolation et containment
    • Pourquoi un container n'est pas une machine virtuelle
    • Container escape : comment un attaquant sort d'un container
    • Ne jamais tourner en root
    • Resource limits : CPU, mémoire, disque
    • Docker Compose : séparer pour limiter le blast radius
    • Prompt IA : audit sécurité Docker
  • 2.5 FastAPI — sécuriser l'API
    • CORS : pourquoi c'est nécessaire et quand c'est un risque
    • Validation des entrées : Pydantic comme défense en profondeur
    • Secrets management : les .env ne suffisent pas en production
    • Logging sécurisé : ne jamais logger de tokens
    • Prompt IA : audit sécurité API FastAPI
  • 2.6 WAF — Web Application Firewall
    • 2.6 WAF — Web Application Firewall
  • 2.7 CI/CD Security — sécuriser le pipeline de déploiement
    • 2.7 CI/CD Security — sécuriser le pipeline de déploiement
  • 2.8 Prompts d'audit — Nginx, FastAPI, Docker
    • 2.8 Prompts d'audit — Nginx, FastAPI, Docker
  • 3.1 Pourquoi les agents IA sont différents
    • Un agent IA prend des décisions — un logiciel classique ne fait qu'exécuter
    • L'attaque surface n'est plus le code, c'est le prompt
    • Cas réel : l'incident Meta (mars 2026)
    • Cas réel : Summer Yue — l'inbox supprimée
    • Les leçons pour votre infrastructure
  • 3.2 Prompt injection — comprendre l'attaque
    • Injection directe : manipuler le prompt de l'utilisateur
    • Injection indirecte : contrôler le contenu que l'agent consomme
    • Pourquoi le filtrage de contenu est insuffisant
    • L'approche par permissions, pas par filtrage
    • Exemples concrets d'attaques réussies
  • 3.3 Permissions et moindre privilège
    • Pourquoi un agent IA doit avoir moins de droits que vous
    • Read-only vs read-write : décider par action
    • Scopes d'API : limiter chaque token à son utilité
    • Expiration automatique des permissions
    • Prompt IA : audit permissions d'un agent IA
  • 3.4 Sandboxing, kill switches et auditabilité
    • Pourquoi un agent doit tourner dans un environnement isolé
    • Containers, réseaux isolés, filesystems read-only
    • Hard gates vs soft prompts
    • Kill switches : le bouton d'arrêt d'urgence
    • Logs : chaque action doit être tracée
    • Masking et canary data
    • Prompt IA : vérifier les fail-safes d'un agent
  • 3.5 Contrôle des outils et logs sensibles
    • 3.5 Contrôle des outils et logs sensibles
  • 3.6 Prompts d'audit — Agents IA autonomes
    • 3.6 Prompts d'audit — Agents IA autonomes
  • 4.1 Checklist pré-déploiement
    • VPS : SSH, firewall, utilisateurs, mises à jour
    • Docker : isolation, utilisateurs, resource limits
    • API : headers, CORS, rate limiting, secrets
    • Agent IA : permissions, sandboxing, kill switch, logs
  • 4.2 Outils d'audit automatisés
    • Lynis : scanner complet de la machine
    • Trivy : vulnérabilités containers et images
    • docker-bench-security : CIS Docker Benchmark
    • Mozilla Observatory : headers HTTP
    • Intégration dans un workflow mensuel
    • Prompt IA : lancer et interpréter un audit complet
  • 4.3 Audit mensuel et cadres de référence
    • Pourquoi un audit unique ne suffit pas
    • Les 7 vérifications mensuelles essentielles
    • Quand un outil signale une vulnérabilité
    • Cadres de référence : NIST, CIS, OWASP
  • 4.4 Prompts d'audit — Infrastructure complète
    • 4.4 Prompts d'audit — Infrastructure complète
  • Conclusion
    • La sécurité est un processus, pas un état
    • Récap : les principes fondamentaux
    • Prochaines étapes
    • Glossaire
    • Ressources complémentaires

Ce qui rend ce livre différent

Cypher Aeon Veda

Il existe des centaines de guides de sécurité sur internet. Des blogs, des vidéos, des documentations officielles. Mais la plupart souffrent d'un problème : ils sont soit trop théoriques (des pages de concepts sans application), soit trop pratiques (des listes de commandes à copier-coller sans comprendre ce qu'elles font).

Ce livre prend une autre approche.

Chaque chapitre suit le même cycle :

  1. Comprendre — Pourquoi cette couche de sécurité existe, ce qui se passe si elle est absente, quels sont les risques réels.
  2. Comprendre les principes — Les frameworks de référence (OWASP, CIS, NIST) vulgarisés, pas copiés-collés.
  3. Agir via votre agent IA — Un prompt prêt à copier-coller dans votre agent IA (Hermes, Claude Code, Cursor, ou tout autre outil) pour qu'il audite votre infrastructure et vous propose les corrections.

Vous n'aurez pas besoin de mémoriser des commandes. Vous comprendrez pourquoi chaque mesure de sécurité est nécessaire, et vous saurez demander à votre agent IA de vérifier que tout est en place.

Formats et compatibilité

Ebook

EPUB + PDF. Lisible sur Kindle, tablette, smartphone, PC.

Questions fréquentes

Mon serveur n'est pas intéressant pour les hackers — vrai ou faux ?
C'est la phrase qu'on entend le plus souvent quand on parle de sécurité serveur. "Je n'ai rien de intéressant", "C'est juste un petit site", "Qui voudrait pirater mon VPS à 5 €/mois ?"
Comment utiliser ce livre
**Si vous débutez** — Lisez les chapitres dans l'ordre. Chaque chapitre construit sur le précédent, du VPS jusqu'à la checklist complète.
Pourquoi les headers HTTP sont votre première ligne de défense web
Quand un navigateur charge votre page, votre serveur envoie des headers HTTP avant le contenu. Ces headers sont des instructions pour le navigateur : comment afficher la page, quels scripts exécuter, comment gérer les cookies. Les headers de sécurité ajoutent une couche de protection *côté navigateur* — même si votre serveur est compromis, certains types d'attaques restent bloqués.
Pourquoi rate limiter
Le rate limiting limite le nombre de requêtes qu'un client peut envoyer dans un temps donné. C'est votre défense contre :
Où appliquer le rate limiting
**1. Au niveau du reverse proxy (Nginx)** — La meilleure position. Les requêtes malveillantes sont bloquées avant d'atteindre votre application. Nginx supporte `limit_req_zone` nativement avec un overhead minimal.
Pourquoi un container n'est pas une machine virtuelle
Une machine virtuelle (VM) émule du matériel : CPU, RAM, disque, réseau. Chaque VM a son propre noyau (kernel) Linux. Un process dans une VM ne peut pas voir les processus des autres VMs — le noyau l'en empêche physiquement.
Pourquoi le filtrage de contenu est insuffisant
L'approche naïve consiste à filtrer le contenu que l'agent consomme : bloquer les mots-clés comme "ignore", "instruction", "système". Mais c'est facilement contournable :
Pourquoi un agent IA doit avoir moins de droits que vous
Le principe du moindre privilège existe depuis des décennies en sécurité informatique : chaque utilisateur, chaque process, chaque service ne doit avoir que les permissions strictement nécessaires pour accomplir sa tâche.