Concevoir pour la récupération et résister au déni de service

Tout système complexe finit par tomber en panne, et un adversaire cherche précisément à provoquer ces défaillances. Deux disciplines en découlent, qui sont les deux faces d'une même médaille : savoir revenir à un état sain après un incident, et savoir tenir quand quelqu'un tente délibérément de vous mettre à terre. La récupération (recovery) et la lutte contre le déni de service (denial-of-service, DoS) sont la démonstration concrète de la thèse du livre : sécurité et fiabilité sont des propriétés émergentes, indissociables, qu'on ne bricole pas pendant la crise mais qu'on conçoit dès le départ. Ce chapitre, défensif de bout en bout, explique comment un adversaire raisonne — uniquement pour mieux s'en prémunir — et détaille les pratiques que Google a forgées pour récupérer vite et absorber l'assaut.

De quoi récupère-t-on ?

Avant de concevoir une stratégie de retour à un état sain, il faut nommer ce dont on récupère. Le livre range les défaillances en quatre catégories, et insiste : ne perdez pas de temps à classer finement un cas limite, soyez prêt à en récupérer.

Catégorie	Origine	Exemples
Erreurs aléatoires (random errors)	Le matériel physique, qui finit toujours par lâcher	Bit retourné par un rayon cosmique, cœur de CPU défaillant, séisme, micro-coupure de courant
Erreurs accidentelles (accidental errors)	L'humain bien intentionné qui se trompe	Action unilatérale non soumise à un garde-fou, pelleteuse qui sectionne une fibre
Erreurs logicielles (software errors)	Un cas particulier, différé, d'erreur accidentelle commise au développement	Bug, automatisation sans contrôle de sûreté qui mime un attaquant
Actions malveillantes (malicious actions)	L'humain qui œuvre délibérément contre vous	Initié qui abuse de ses droits, attaquant tiers ayant volé des identifiants

Concevoir pour aller aussi vite que possible, sous contrôle de la politique

Pendant un incident, la pression pousse à rétablir le service « le plus vite possible ». Mais les mécanismes qui changent l'état d'un système rapidement peuvent aussi propager la mauvaise modification trop vite, et aggraver la situation. Le principe directeur du chapitre résout cette tension par un découplage.

Concevez votre système de déploiement pour qu'il opère aussi vite que vous puissiez l'imaginer un jour nécessaire — voire plus vite, jusqu'aux limites du raisonnable. Puis ajoutez par-dessus des contrôles qui bornent le débit de changement selon votre politique courante de risque et de perturbation. Séparer l'actionnement du changement (ce qu'on déploie) de sa cadence (à quelle vitesse) apporte des avantages décisifs.

                 ┌──────────────────────────┐
  Quoi déployer  │   Système de déploiement  │   « tourné au maximum »
  (binaire, conf)│    (capable du max)       │   = système d'urgence
                 └────────────┬─────────────┘
                              │
                 ┌────────────▼─────────────┐
  À quelle vitesse│  Limiteur de débit       │   microservice isolé,
  (politique)     │  (rate-limiting)         │   simple, testable, audité
                 └────────────┬─────────────┘
                              │
                 ┌────────────▼─────────────┐
                 │   Flotte / production      │
                 └──────────────────────────┘

Pour qu'un système capable d'aller très vite ne s'emballe pas, isolez le mécanisme de limitation de débit dans un microservice indépendant, mono-fonction, aussi simple que possible et rigoureusement testable. Il peut émettre un jeton cryptographique éphémère attestant qu'il a approuvé un changement à un instant donné, et constitue un point de collecte idéal pour les journaux d'audit. Google a appris cette leçon en faisant évoluer la diffusion de sa distribution Linux interne : d'une image « de référence » (golden image) poussée mensuellement, l'équipe est passée à des unités de publication granulaires par paquet, découplant la cadence de l'action — et a pu, du même geste, traiter les urgences en ajustant simplement quelques limites.

Limiter sa dépendance au temps « horloge »

Le temps de l'horloge murale (wall-clock time) est une forme d'état que vous ne contrôlez pas. Chaque endroit où votre système s'y arrime menace votre capacité à récupérer : rejouer des transactions signées peut échouer si des certificats ont « expiré » entre-temps ; un décalage entre le moment de la panne et celui de la réparation produit des comportements imprévus. Pis, lier la sécurité à l'horloge ouvre des failles — on est tenté de désactiver la vérification des certificats pour réparer, et le remède devient pire que le mal.

L'avancement par époque coordonne toutes les parties du système autour d'un entier signifiant « valide » contre « expiré ». En cas de problème, on stoppe l'avancement le temps de comprendre, sans jamais être tenté de couper la vérification. Attention toutefois : un adversaire qui contrôle temporairement le système pourrait précipiter l'avancement ou provoquer un débordement (overflow). La parade habituelle est un entier 64 bits assorti d'une limite de débit de secours câblée en dur — par exemple un incrément au maximum par seconde, ce qui couvre des milliards d'années. C'est l'exception assumée au principe « aussi vite que possible » : il est difficile d'imaginer un motif légitime de changer cet état plus d'une fois par seconde.

Le rollback : un arbitrage entre sécurité et fiabilité

Le premier réflexe de réponse à incident est de revenir au dernier état bon connu, généralement en annulant le changement suspect. La fiabilité l'exige : une grande part des incidents nécessitant une intervention humaine sont auto-infligés. Mais le retour arrière (rollback) cache un piège. Quand vous corrigez une vulnérabilité, vous courez contre l'attaquant ; une fois le correctif stable, autoriser un rollback réintroduit la faille — d'autant plus dangereuse qu'elle est ancienne et que des exploits prêts à l'emploi circulent.

Les deux politiques extrêmes échouent toutes deux, ce qui balise le problème.

Politique	Pourquoi elle échoue
Autoriser tout rollback	Non sécurisée : tout retour peut réintroduire une vulnérabilité connue et déjà outillée
Interdire tout rollback	Non fiable : un correctif buggé devient un piège sans issue ; impose de toujours produire une version « roll-forward »

Pour les composants applicatifs, on tranche par des listes de refus (deny lists) de versions indésirables, identifiées par un hachage cryptographique. Les composants auto-modifiants (self-updating) — un démon de paquets qui réécrit son propre binaire, un BIOS qui se reflashe — sont bien plus délicats, surtout sur du matériel doté de mémoire à programmation unique (one-time-programmable, OTP). Trois techniques, idéalement combinées, gèrent l'arbitrage.

• Listes de refus : rapides à mettre à jour pendant une réponse à incident, elles parent surtout les erreurs accidentelles. Une liste codée en dur dans le composant reste vulnérable au « dézippage » (unzipping) — l'attaquant recule version par version jusqu'à une faille connue. Mieux vaut encoder la liste hors du composant, dans un état persistant (ComponentState), qui survit aux mises à jour comme aux retours arrière.
• Numéros de version de sécurité (Security Version Numbers, SVN) et leur minimum acceptable (MASVN) : un entier ordonné, compact et comparable, qui remplace une liste de refus devenue ingérable. On définit un seuil plancher sous lequel le système ne doit jamais fonctionner. La règle d'application d'une mise à jour devient une simple comparaison.

// Schéma MASVN (pseudo-code translittéré) : on n'accepte une mise à jour
// que si son numéro de sécurité atteint le plancher courant.
function isUpdateAllowed(release: Release, state: ComponentState): boolean {
  return release.svn >= state.masvn;
}

// Maintenance au démarrage : le plancher ne fait que monter (cliquet).
state.masvn = Math.max(self.masvn, state.masvn);

• Rotation des clés de signature : retirer une clé publique ancienne ou compromise invalide les anciennes versions, puisque les nouvelles ne font plus confiance à la clé qui les vérifiait. Une rotation graduelle (on introduit la clé k+1 aux côtés de k, on accepte les deux, puis on abandonne k) exerce régulièrement une bonne pratique cryptographique — donc plus susceptible de fonctionner après un incident. C'est le dernier recours si un attaquant a poussé un MASVN au maximum pour saboter tout le schéma.

Un mécanisme de révocation explicite

Le rôle premier d'un système de révocation est de stopper un accès — bénédiction quand un attaquant a volé des identifiants valides (une clé SSH, par exemple). Mais une fois en place, il peut lui-même devenir une source de risques. Le piège majeur est le « fail open » : par peur que la base de validité des certificats, si elle tombe, n'entraîne tout le reste, on est tenté de tout accepter quand elle est injoignable. C'est dangereux — un attaquant qui lance un simple DoS sur le service de temps dont dépend la base peut ressusciter des certificats révoqués le temps de l'attaque.

La scalabilité de la révocation demande une vigilance particulière, car un attaquant partiellement infiltré pourrait s'en servir comme arme de déni de service : révoquer tous les certificats d'hôte de votre infrastructure. La parade élégante de Google : faire évaluer la nouvelle liste de révocation par le serveur cible avant application, et refuser toute mise à jour qui révoquerait ses propres identifiants. Une liste qui révoque tout le monde est ignorée de tous ; la meilleure stratégie de l'attaquant se réduit à révoquer la moitié des machines — vous avez la garantie qu'au moins la moitié de la flotte survit à chaque poussée, et restaurer la moitié d'une infrastructure est bien plus facile que sa totalité. Évitez par ailleurs la liste de révocation « d'urgence » dédiée (rarement utilisée, donc peu fiable) : préférez fractionner (sharding) la liste habituelle pour la mettre à jour de façon incrémentale, et ne créez jamais de comptes « spéciaux » qui court-circuiteraient la révocation — ce sont des cibles rêvées.

Connaître son état voulu, jusqu'à l'octet

Récupérer, c'est revenir à un état bon connu — encore faut-il le connaître. Plus vous encodez l'état voulu et réduisez l'état mutable à chaque couche (par service, par hôte, par appareil), plus il est facile de reconnaître que vous êtes revenu à bon port. C'est le socle de l'automatisation, de la détection d'intrusion et de la récupération.

Chez Google, chaque machine surveille en continu son système de fichiers et en maintient une carte (nom + somme de contrôle cryptographique de chaque fichier). Un service central compare cette carte à l'intention — l'ensemble des paquets assignés — et journalise chaque déviation, qu'il répare. Un bit corrompu par un rayon cosmique ? On répare. Une modification locale hors outillage, accidentelle ou malveillante ? On répare aussi — et l'attaquant a bien plus de mal à effacer ses traces, le service central ayant déjà tout consigné. Un post_install idempotent restaure l'état en mémoire (le démon SSH, par exemple, est redémarré pour relire sa configuration). Ce paradigme s'applique à toutes les couches : firmware (versions BIOS, ordre de démarrage SATA avant USB, clés autorisées à signer les mises à jour), services globaux (supportez plusieurs instances même si vous n'en prévoyez qu'une) et données persistantes.

L'accès d'urgence (breakglass)

Toutes ces méthodes supposent que le répondeur puisse interagir avec le système. Quand les accès normaux sont totalement rompus, il faut un dispositif d'urgence — le cas extrême où l'on ne peut surestimer l'importance conjointe de la sécurité et de la fiabilité, car il n'y a plus de couche pour absorber l'échec. L'accès d'urgence regroupe le strict minimum de technologies dont les répondeurs ont besoin pour atteindre les interfaces d'administration critiques et communiquer entre eux, tout en préservant autant que possible les contrôles d'accès.

   Accès NORMAL (zero trust)            Accès D'URGENCE (low-dependency)
   ┌───────────────────────┐           ┌───────────────────────┐
   │ SSO + 2FA              │           │ identifiants alternatifs │
   │ autorisation multi-    │   ──X──►  │ provisionnés HORS LIGNE │
   │ partie (MPA)           │  échoue   │ algos auth/autz de repli│
   │ évaluation du device   │           │ réservés à ceux qui     │
   └───────────────────────┘           │ doivent agir TOUT DE SUITE│
   nombreuses dépendances              └───────────────────────┘
                                       sécurité équivalente,
                                       dépendances minimales

Le réseau d'entreprise de Google tire ses propriétés zero trust d'une évaluation automatisée de chaque appareil, d'identifiants à courte durée de vie via un SSO à double facteur, et d'une autorisation multi-partie (multi-party authorization, MPA) pour certaines opérations d'administration — autant de fonctions logicielles aux dépendances non triviales. Pour survivre à la défaillance de l'une d'elles, l'entreprise a provisionné des identifiants alternatifs disponibles hors ligne, à la sécurité équivalente mais aux dépendances drastiquement réduites, restreints aux personnes qui doivent agir immédiatement. La stratégie d'accès distant s'ancre sur des services critiques autonomes déployés dans des baies géographiquement réparties : pendant une panne mondiale, chaque baie reste accessible à une partie des répondeurs, qui réparent ce qu'ils atteignent puis étendent la récupération de façon radiale.

Atténuer les attaques par déni de service

Sécurité et fiabilité se croisent à nouveau lorsqu'un adversaire peut provoquer une panne par une attaque par déni de service. Pour la penser, l'économie est plus utile que le vocabulaire militaire : l'adversaire cherche à faire en sorte que la demande d'un service dépasse l'offre de sa capacité. La victime doit alors choisir entre engager des dépenses encore plus lourdes pour absorber l'assaut, ou subir une indisponibilité. Tout service peut être visé — l'extorsion par DoS frappe d'ailleurs assez indistinctement.

La stratégie de l'attaquant — pour mieux la contrer

Un attaquant doit concentrer ses ressources limitées sur le maillon le plus faible de la chaîne de dépendances. Une requête utilisateur typique en compte plusieurs : une requête DNS fournit l'adresse IP, le réseau transporte la requête, les frontaux l'interprètent, les dorsaux (base de données) produisent la réponse. Perturber n'importe laquelle de ces étapes suffit. Le novice inonde de requêtes ; l'attaquant habile génère des requêtes coûteuses (en abusant d'une fonction de recherche, par exemple) ; le déterminé orchestre un DDoS (distributed denial-of-service) via un botnet ou une attaque par amplification.

Une architecture défendable : des défenses en couches

Surdimensionner toute la pile pour absorber n'importe quel assaut est ruineux et souvent infaisable. La clé est que, plus le trafic d'attaque s'enfonce dans le système, plus il devient concentré et coûteux à neutraliser — d'où des défenses en couches, où chaque couche protège la suivante. On ne dimensionne alors les couches internes que pour ce qui a percé les externes, et éliminer le trafic au plus tôt économise bande passante et calcul.

Couche	Levier anti-DoS	Effet
Bordure / pairage	ACL de routeur ; anycast (une IP annoncée depuis plusieurs sites) ; refus du trafic hostile au plus tôt	Disperse l'attaque mondialement, protège le réseau dorsal
Répartiteurs réseau	Bridage des inondations de paquets ; équilibrage vers le datacentre le plus proche disposant de capacité	Empêche la focalisation sur un seul composant
Répartiteurs applicatifs	Bridage des attaques spécifiques à l'application avant les frontaux ; WAF	Filtre les requêtes malveillantes connues
Proxys de cache	En-têtes Cache-Control près de la bordure	Sert le contenu répété sans toucher le dorsal, réduit la latence
Service / application	Dégradation gracieuse, spriting, redimensionnement des images, limitation de débit	Conserve l'essentiel sous charge, économise la bande passante de sortie

Mutualiser les défenses dans l'infrastructure partagée apporte une économie d'échelle : ce qui serait disproportionné pour un service isolé devient rentable une fois provisionné pour tous. C'est l'esprit de Project Shield : une attaque écrasante pour un site donné reste tout à fait gérable rapportée au volume agrégé de tous les sites protégés.

Services défendables et dégradation gracieuse

La conception même de l'application pèse lourd. Au-delà des proxys de cache, on minimise le nombre de requêtes (le spriting fusionne plusieurs petites icônes en une image — Google a ainsi économisé 10 millions de requêtes par jour) et on réduit la bande passante de sortie (egress) en redimensionnant les ressources. Mais la meilleure défense reste la dégradation gracieuse (graceful degradation) : quand absorber n'est pas possible, on réduit l'impact visible. Les ACL réseau brident le trafic suspect comme un interrupteur — sans le bloquer en permanence, afin de conserver la visibilité et de ne pas frapper le trafic légitime ressemblant à la signature. Les contrôles de qualité de service (QoS) priorisent le trafic critique. En surcharge, on bascule en mode dégradé : Blogger sert en lecture seule (commentaires coupés), Web Search réduit ses fonctionnalités, et les serveurs DNS répondent au maximum tout en étant conçus pour ne jamais planter, quelle que soit la charge.

Surveillance, alerte, et un système d'atténuation

Le temps de résolution se décompose en temps de détection (MTTD) et temps de réparation (MTTR). Surveillez le débit de requêtes en plus du CPU et de la mémoire. Surtout, n'alertez que lorsqu'une action humaine est requise : si l'attaque ne nuit pas aux utilisateurs, mieux vaut souvent l'absorber en silence. On ne réveille un répondeur que lorsque la demande dépasse la capacité et que les défenses automatiques se sont déjà engagées.

Un système d'atténuation automatisé se divise en détection (visibilité fine sur le trafic, échantillonnage statistique agrégé vers un contrôleur central qui repère les anomalies) et réponse (par exemple fournir une liste d'IP à bloquer, ou servir un défi JavaScript ou CAPTCHA). Les faux positifs sont inévitables — d'où l'intérêt d'un CAPTCHA permettant aux vrais utilisateurs derrière une IP partagée de contourner le blocage. Trois principes de conception ressortent.

• Le système d'atténuation doit lui-même résister à l'attaque : pas de dépendance à une infrastructure de production susceptible d'être touchée. Cela vaut jusqu'aux outils et canaux de communication de l'équipe (Google maintient des moyens de secours, Gmail ou Docs pouvant eux-mêmes être affectés).
• Réponse en secondes, ce qui crée une tension avec le déploiement prudent et lent. Le compromis : canariser tout changement, y compris les réponses automatiques, sur un sous-ensemble de la production — un canari qui peut ne durer qu'une seconde.
• « Fail static » : si le contrôleur central tombe, on ne « fail » ni fermé (qui bloquerait tout) ni ouvert (qui laisserait passer l'attaque) — la politique en cours ne change pas. Le moteur de DoS peut donc défaillir pendant une attaque (c'est arrivé chez Google) sans provoquer de panne, ce qui réduit son coût en le dispensant d'une disponibilité maximale.

Quand l'« attaque » n'en est pas une

Dans l'adrénaline d'une panne, on cherche un adversaire — mais il n'y en a parfois aucun. Un événement externe peut synchroniser les utilisateurs (un séisme nocturne qui réveille une région entière la pousse vers ses appareils ; un jeu télévisé allemand fit autrefois affluer vers Google Search des recherches anormales par préfixes de mots, prises à tort pour un botnet — corrigées par une simple fonctionnalité de suggestion de complétion). Le comportement de relance des clients est l'autre grand coupable : un logiciel qui réessaie en boucle face à des erreurs amplifie la panne. La parade est de concevoir les clients avec un back-off exponentiel agrémenté de gigue (jitter) pour désynchroniser les relances. Quand on ne contrôle pas le client (les serveurs DNS faisant autorité voient jusqu'à 30 fois le trafic normal après une panne), la meilleure réponse est de répondre au plus de requêtes possible tout en se protégeant par un bridage en amont : chaque réponse réussie libère un client de sa boucle.

À retenir

• Sécurité et fiabilité sont les deux faces d'une même exigence : tenir sous l'assaut (DoS) et revenir à un état sûr après l'incident (récupération) ne s'improvisent pas — ils se conçoivent dès le départ.
• Découplez l'action de la cadence : un système de déploiement capable d'aller au maximum, bordé par un limiteur de débit isolé. Votre système d'urgence doit être votre système normal poussé à fond — pas un « gros bouton rouge » jamais testé.
• Le rollback est un arbitrage sécurité/fiabilité, à trancher comme une politique explicite (listes de refus, SVN/MASVN, rotation de clés) ; évitez la dépendance au temps horloge, qui ressuscite des certificats révoqués.
• Connaissez votre état voulu jusqu'à l'octet et réparez toute déviation ; protégez vos sauvegardes comme vos données primaires, car « on ne se soucie que des restaurations ».
• L'accès d'urgence (breakglass) à faibles dépendances — identifiants hors ligne, MPA, réservé à ceux qui doivent agir tout de suite — est vital, mais inutile s'il n'est pas exercé : minimisez l'écart avec les procédures normales.
• Contre le DoS, pensez en économiste (demande contre offre) et en couches : éliminez le trafic au plus tôt (ACL, anycast, caches), provisionnez les défenses en mutualisé (Project Shield) et dégradez gracieusement plutôt que de tomber.
• Le système d'atténuation doit résister lui-même à l'attaque, canariser ses réponses en secondes et « fail static » ; répondez de façon stratégique sans renseigner l'adversaire — et vérifiez toujours que l'« attaque » n'est pas auto-infligée.