L'intersection de la sécurité et de la fiabilité

Peu d'utilisateurs, à qui l'on demanderait de citer leurs fonctionnalités préférées d'un produit, commenceraient leur liste par la sécurité et la fiabilité. Ces deux qualités se cachent dans l'attente implicite des clients : quand elles fonctionnent bien, personne ne les remarque. Et pourtant, presque personne ne veut utiliser un produit qui ne soit ni sûr ni fiable. C'est la conviction qui irrigue tout Building Secure and Reliable Systems — l'ouvrage que Google a consacré, dans le sillage de ses livres SRE, à l'union de la sécurité et de la fiabilité. Ce premier chapitre pose la thèse fondatrice : sécurité et fiabilité sont des propriétés émergentes (emergent properties) d'un système, indissociables, qu'il faut concevoir dès le départ et qui relèvent de toute l'organisation.

Le livre, et donc ce blog à sa suite, propose des repères de haut niveau sur les adversaires potentiels : comment ils pourraient agir et comment leurs actions peuvent peser sur le cycle de vie d'un système. On y explique les menaces et le mode opératoire d'un adversaire pour mieux concevoir des défenses. Ce qui distingue cet ouvrage, ce sont les pratiques concrètes forgées par Google à grande échelle ; nous les rencontrerons tout au long du blog, mais leur fil conducteur tient dans une idée simple : on ne rajoute pas la sécurité ni la fiabilité après coup, on les fait émerger d'une conception saine.

Des mots de passe et des perceuses

Le livre s'ouvre sur une anecdote devenue célèbre, et qui dit tout de la tension à l'œuvre. Le 27 septembre 2012, une annonce anodine, diffusée à l'échelle de Google, a déclenché une série de défaillances en cascade (cascading failures) dans un service interne. La sortie de crise a fini par exiger une perceuse électrique.

Google dispose d'un gestionnaire de mots de passe interne qui permet aux employés de stocker et de partager des secrets pour des services tiers ne supportant pas de meilleurs mécanismes d'authentification. Parmi ces secrets : le mot de passe du WiFi invité des navettes qui relient les campus de la baie de San Francisco. Ce jour-là, l'équipe transport a annoncé par courriel à des milliers d'employés que le mot de passe WiFi avait changé. Le pic de trafic qui en a résulté a largement dépassé ce qu'un système conçu des années plus tôt pour une poignée d'administrateurs pouvait absorber.

La charge a rendu la réplique primaire (primary replica) non réactive ; le répartiteur de charge a basculé le trafic vers la réplique secondaire, qui a immédiatement cédé de la même façon. L'ingénieur d'astreinte (on-call), alerté, n'avait aucune expérience de panne sur ce service — il n'en avait jamais connu en cinq ans d'existence. Il a tenté un redémarrage, sans savoir qu'il fallait une carte à puce de module de sécurité matériel (hardware security module, HSM). Ces cartes dormaient dans des coffres répartis dans plusieurs bureaux du monde — mais aucun à New York, où se trouvait l'ingénieur.

Voici alors la mécanique parfaite du piège :

  Le gestionnaire de mots de passe tombe (pb de FIABILITÉ : load balancing)
                              │
                              ▼
  Redémarrage impossible sans carte à puce HSM (mesure de SÉCURITÉ)
                              │
        ┌─────────────────────┴─────────────────────┐
        ▼                                             ▼
  Coffre en Australie                          Carte récupérée
  → combinaison stockée DANS                   en Californie (combinaison
  le gestionnaire... hors ligne                 mémorisée par un collègue)
        │                                             │
        ▼                                             ▼
  PERCEUSE sur le coffre (1 h)                  Carte insérée → échec :
        │                                       « impossible de charger
        ▼                                       les cartes protégeant la clé »
  Mêmes cartes → même erreur                          │
        └───────────────────────┬─────────────────────┘
                                 ▼
        La carte était insérée À L'ENVERS (la LED verte ne
        signalait PAS une insertion correcte) → retournée → service rétabli

Le collègue australien ne pouvait pas ouvrir son coffre : la combinaison était stockée dans le gestionnaire de mots de passe désormais hors ligne. Un collègue californien avait, lui, mémorisé la combinaison de son coffre — mais la carte insérée déclenchait une erreur cryptique. Les ingénieurs australiens ont alors opté pour la force brute (brute force) au sens littéral : une perceuse appliquée au coffre. Une heure plus tard, le coffre était ouvert ; les nouvelles cartes donnaient la même erreur. Il a fallu une heure de plus pour comprendre que la diode verte du lecteur n'indiquait pas une insertion correcte : les cartes étaient à l'envers. Une fois retournées, le service est reparti.

La différence clé : l'adversaire intelligent

Si l'on ne devait retenir qu'une distinction entre fiabilité et sécurité, ce serait celle-ci : la présence, ou l'absence, d'un adversaire malveillant et intelligent. C'est elle qui commande des considérations de conception différentes.

Les risques de fiabilité sont essentiellement non malveillants : une mauvaise mise à jour logicielle, la panne d'un disque, un pic de trafic légitime. En concevant pour la fiabilité, on suppose que quelque chose finira par mal tourner à un moment. Les risques de sécurité, eux, viennent d'adversaires qui cherchent activement à exploiter les vulnérabilités du système. En concevant pour la sécurité, on suppose qu'un adversaire pourrait essayer de faire mal tourner les choses à n'importe quel moment. La fiabilité affronte le hasard ; la sécurité affronte une intelligence qui s'adapte.

Cette différence change radicalement la manière dont un système doit réagir aux pannes. En l'absence d'adversaire, on conçoit souvent pour échouer en sécurité au sens physique (fail safe / fail open) : une serrure électronique reste ouverte en cas de coupure de courant, pour permettre la sortie. Mais ce comportement ouvre une faille évidente : un attaquant n'a qu'à provoquer une coupure pour franchir la porte. Pour s'en défendre, on conçoit la serrure pour échouer fermée (fail secure) quand elle n'est plus alimentée. Le même événement — une coupure de courant — appelle deux conceptions opposées selon qu'on raisonne fiabilité ou sécurité.

Dimension	Posture de fiabilité	Posture de sécurité
Nature de la menace	Aléatoire, non malveillante (bug, panne matérielle, pic)	Adversaire intelligent qui s'adapte et persiste
Hypothèse de conception	« Quelque chose va casser à un moment »	« Quelqu'un essaie de casser, à tout moment »
Mode d'échec par défaut	Échouer ouvert (fail open) pour la disponibilité	Échouer fermé (fail secure) pour la protection
Redondance	Atout : un chemin de secours augmente la disponibilité	Risque : chaque chemin élargit la surface d'attaque
Gestion d'incident	Beaucoup d'intervenants, points de vue multiples	Cercle restreint, partage « besoin d'en connaître »
Indépendance des défaillances	On peut supposer des pannes indépendantes	Un adversaire corrèle volontairement les défaillances

Confidentialité, intégrité, disponibilité : la triade CIA

Sécurité et fiabilité se préoccupent toutes deux de la confidentialité, de l'intégrité et de la disponibilité (confidentiality, integrity, availability) d'un système — les trois attributs historiques de la sécurité, regroupés sous l'acronyme anglais CIA, la triade CIA. La seule différence de regard, encore une fois, tient à la présence ou non d'un adversaire malveillant. Un système fiable ne doit pas violer la confidentialité par accident, comme le ferait une messagerie boguée qui se trompe de destinataire ; un système sûr doit empêcher un adversaire actif d'accéder, d'altérer ou de détruire des données confidentielles.

Trois exemples, tirés du livre, montrent comment un problème de fiabilité peut produire un problème de sécurité — et inversement.

Propriété	Défaillance de fiabilité (sans adversaire)	Menace de sécurité (avec adversaire)
Confidentialité	Un micro « parler-pour-transmettre » (push-to-talk) bloqué en émission diffuse à son insu les conversations du cockpit	Un attaquant accède à des données protégées et les exfiltre
Intégrité	Une erreur mémoire non corrigeable provoque un retournement de bit (bit flip) dans des données stockées	Un attaquant falsifie ou corrompt délibérément les données
Disponibilité	Une mise à jour fait synchroniser des millions d'appareils, qui submergent un service central	Une attaque par déni de service distribué (DDoS) inonde la victime de trafic

Le cas de confidentialité vient de l'aviation : un micro push-to-talk coincé en position d'émission a, dans plusieurs cas documentés, diffusé les conversations privées des pilotes. Aucun adversaire — une simple panne matérielle suffit à rompre la confidentialité.

Le cas d'intégrité est plus subtil, et instructif. En 2015, des SRE de Google ont remarqué que les contrôles d'intégrité cryptographiques de bout en bout échouaient sur quelques blocs de données. Comme certaines machines ayant traité ces données présentaient des erreurs mémoire non corrigeables, les SRE ont écrit un logiciel qui calculait, de façon exhaustive, le contrôle d'intégrité pour chaque version des données avec un seul bit retourné (un 0 devenu 1, ou l'inverse). Toutes les erreurs se sont révélées être des retournements de bit unique, et toutes les données ont été récupérées. Détail savoureux : c'est ici une technique de sécurité (le contrôle d'intégrité cryptographique) qui est venue au secours d'un incident de fiabilité. À noter que les systèmes de stockage de Google emploient aussi des contrôles d'intégrité de bout en bout non cryptographiques — mais d'autres problèmes ont empêché les SRE de détecter les retournements de bit par ce biais, et c'est bien le contrôle cryptographique qui a permis de remonter à la cause.

Les points communs : deux faces d'une même médaille

Voici le cœur de la thèse. À la différence de la plupart des autres caractéristiques d'un système, fiabilité et sécurité sont des propriétés émergentes (emergent properties) : elles naissent de l'interaction de nombreux composants, et non d'un module qu'on brancherait à part. On les rajoute difficilement après coup ; il faut donc les penser dès les premières étapes de conception, puis y veiller et les tester tout au long du cycle de vie, car une modification anodine d'un composant peut affecter la fiabilité ou la sécurité de l'ensemble — souvent sans que cela apparaisse avant l'incident. Examinons leurs points communs (commonalities).

Invisibilité

Fiabilité et sécurité sont presque invisibles quand tout va bien. C'est précisément ce qui les rend vulnérables sur le plan organisationnel : faute de conséquences immédiates visibles, on les perçoit comme des coûts qu'on peut réduire ou différer. Or le prix d'une défaillance peut être colossal. Selon des reportages, des fuites de données auraient amputé de 350 millions de dollars le prix payé par Verizon pour racheter l'activité internet de Yahoo! en 2017. La même année, une panne de courant a éteint des systèmes clés chez Delta Airlines, causant près de 700 annulations de vols et réduisant d'environ 60 % le débit de la compagnie sur la journée. Un objectif des équipes de fiabilité et de sécurité est donc aussi de gagner et garder la confiance des clients par une communication honnête et concrète, en temps de crise comme en temps calme.

Évaluation du risque

La perfection étant hors de portée, on adopte des approches fondées sur le risque (risk-based) pour estimer le coût des événements négatifs face au coût de leur prévention. Mais on n'en mesure pas la probabilité de la même manière. Côté fiabilité, on peut raisonner sur la composition de systèmes et planifier le travail selon des budgets d'erreur (error budgets), en partie parce qu'on peut supposer l'indépendance des défaillances entre composants. Côté sécurité, c'est bien plus difficile : un adversaire corrèle volontairement les pannes. On gagne en assurance par l'analyse de la conception et de l'implémentation, et par les tests adverses (adversarial testing) — des attaques simulées, menées du point de vue d'un adversaire défini, pour évaluer la résistance, l'efficacité de la détection et les conséquences potentielles d'une attaque.

Simplicité

Garder la conception aussi simple que possible est l'un des meilleurs moyens d'évaluer fiabilité et sécurité. Un design simple réduit la surface d'attaque, diminue les interactions imprévues et reste compréhensible par des humains — qualité précieuse en pleine urgence, où elle abaisse le temps moyen de réparation (mean time to repair, MTTR). L'idée se prolonge en isolant les invariants de sécurité dans de petits sous-systèmes simples, qu'on peut raisonner indépendamment.

Évolution

Aussi élégant soit-il, aucun design ne reste figé. Nouvelles fonctionnalités, changements d'échelle, évolution de l'infrastructure et nécessité de suivre des attaques toujours nouvelles font croître la complexité — sans parler de la dette technique (technical debt) accumulée sous la pression du marché. Or la complexité s'accumule souvent à l'insu de tous, jusqu'au point de bascule où un changement minuscule a des conséquences majeures.

Résilience

Un problème d'utilisation mémoire ne devrait jamais causer une panne mondiale. Les systèmes doivent être conçus résilients (resilient) face à l'adversité. Côté fiabilité, on absorbe une charge excessive en délestant (load shedding) une partie des requêtes (traiter moins) ou en réduisant le coût de chacune (traiter moins cher), et l'on incorpore redondance et domaines de défaillance distincts (distinct failure domains) pour limiter l'impact d'une panne par réacheminement.

Mais un système suffisamment complexe ne peut prouver son immunité totale. On y répond par la défense en profondeur (defense in depth) — l'empilement de plusieurs mécanismes de défense, parfois redondants — et par des domaines de défaillance distincts, qui limitent le rayon d'impact (blast radius) d'une compromission. Un bon design borne la capacité de l'adversaire à se déplacer latéralement (lateral movement) ou à élever ses privilèges (privilege escalation) depuis un hôte compromis ou des identifiants volés.

  Compromission d'un seul hôte / vol d'identifiants
                       │
        ┌─────────────┴──────────────┐
        ▼                            ▼
  SANS cloisonnement          AVEC domaines distincts +
                              défense en profondeur
        │                            │
   mouvement latéral          identifiants limités à une RÉGION
   + escalade de privilèges   chiffrement applicatif EN PLUS du disque
        │                            │
        ▼                            ▼
  blast radius = tout         blast radius = un seul domaine
  le système                  (l'attaquant reste cantonné)

Google illustre ces principes très concrètement. Son infrastructure interne supporte des identifiants explicitement limités à une région géographique : compromettre un serveur d'une région ne donne pas accès aux serveurs des autres. Le chiffrement par couches indépendantes est un autre mécanisme : même si les disques chiffrent au niveau matériel, on chiffre aussi au niveau applicatif, de sorte qu'une implémentation défaillante dans un contrôleur de disque ne suffise pas à compromettre des données si un attaquant obtient un accès physique.

Du design à la production

Sécurité et fiabilité accompagnent la traduction d'un bon design en système réellement déployé. Dès l'écriture du code, les revues de code (code reviews) repèrent des problèmes, et l'usage de cadres et bibliothèques communs prévient des classes entières de failles. Avant le déploiement, les tests — test de charge (load testing), fuzzing sur des entrées inattendues, tests spécialisés vérifiant qu'une bibliothèque cryptographique ne fuit pas d'information — donnent l'assurance que le système construit correspond bien à l'intention. Enfin, certaines manières de déployer limitent le risque : les canaris (canaries) et les déploiements progressifs (slow rollouts) évitent de tout casser pour tous les utilisateurs en même temps, et un système qui n'accepte que du code dûment relu réduit le risque qu'un initié pousse un binaire malveillant en production.

Investigation et journalisation

Comme la prévention parfaite est impraticable ou trop coûteuse, il faut supposer que les mécanismes préventifs échoueront, et prévoir comment détecter et récupérer. Une bonne journalisation (logging) est le socle de la détection : en général, des journaux plus complets et détaillés valent mieux — mais avec des réserves. À grande échelle, le volume des journaux représente un coût et complique l'analyse (l'exemple YouTube montre qu'une simple journalisation peut elle-même casser la fiabilité). Les journaux de sécurité posent un défi supplémentaire : ils ne devraient pas contenir d'information sensible — identifiants d'authentification, données personnelles (personally identifiable information, PII) — sous peine de devenir eux-mêmes des cibles attrayantes.

Réponse de crise

En situation d'urgence, les équipes doivent collaborer vite et sans accroc, car les conséquences sont immédiates. Au pire, un incident peut détruire une entreprise en quelques minutes : en 2014, un attaquant a mis hors d'état le service d'hébergement de code Code Spaces en quelques heures, en prenant le contrôle des outils d'administration et en supprimant toutes les données, sauvegardes comprises. Il vaut donc mieux disposer d'un plan avant l'urgence : chaîne de commandement claire, listes de contrôle, manuels d'intervention (playbooks) et protocoles solides. Google a codifié sa réponse de crise dans un programme appelé IMAG (Incident Management at Google), qui établit une manière standard et cohérente de gérer tout type d'incident, de la panne au désastre naturel ; il s'inspire de l'Incident Command System (ICS) du gouvernement américain. Entre deux crises, il faut garder les compétences affûtées : le programme de test de reprise après sinistre (Disaster Recovery Testing, DiRT) simule régulièrement des pannes internes et force les équipes à les affronter, tandis que des exercices offensifs fréquents éprouvent les défenses et révèlent de nouvelles vulnérabilités.

Récupération

Récupérer d'une faille de sécurité passe souvent par le correctif (patch) d'une vulnérabilité. On voudrait que cela aille au plus vite, via des mécanismes éprouvés régulièrement, donc fiables. Mais la capacité à pousser des changements rapidement est une arme à double tranchant : elle ferme vite les vulnérabilités, mais peut aussi introduire des bugs ou des problèmes de performance dévastateurs. Choisir de déployer lentement (plus d'assurance sur l'absence d'effets de bord, mais risque que la faille soit exploitée) ou vite relève, in fine, d'une évaluation du risque et d'une décision métier. D'où le besoin de mécanismes de récupération fiables : un système de reprise de flotte robuste doit disposer d'une représentation fidèle de l'état courant et désiré de chaque machine, et de garde-fous garantissant qu'on ne revient jamais à un état obsolète ou dangereux.

Penser les deux ensemble, dès le départ

Sécurité et fiabilité ont énormément en commun : ce sont des propriétés inhérentes à tout système d'information, qu'il est tentant de sacrifier au nom de la vélocité, mais coûteuses à réparer après coup. C'est pourquoi le livre invite à traiter tôt ces défis, à mesure que les systèmes grandissent et évoluent. Au-delà de l'ingénierie, chaque organisation doit comprendre les rôles et responsabilités qui contribuent à bâtir une culture de la sécurité et de la fiabilité — car ces propriétés émergentes appartiennent à tout le monde, pas à une équipe isolée. Gardez enfin à l'esprit le profil de risque de votre projet : opérer une bourse de valeurs ou une plateforme de communication pour dissidents n'a rien à voir avec un site pour un refuge animalier. Le prochain chapitre détaillera les classes d'adversaires et leurs motivations possibles.

À retenir

• Sécurité et fiabilité sont des propriétés émergentes (emergent properties) : elles naissent de l'interaction de tout le système, se rajoutent mal après coup, et doivent donc être conçues dès le départ puis testées sur tout le cycle de vie.
• La différence clé entre les deux est l'adversaire intelligent : la fiabilité affronte des défaillances aléatoires et non malveillantes, la sécurité un attaquant qui s'adapte et persiste — d'où des conceptions parfois opposées (fail open contre fail secure).
• L'anecdote « des mots de passe et des perceuses » incarne la tension confidentialité / disponibilité : une panne de fiabilité, aggravée par des mesures de sécurité, jusqu'à percer un coffre à la perceuse.
• La triade CIA (confidentialité, intégrité, disponibilité) concerne les deux disciplines ; seule change la lentille — avec ou sans adversaire. Le DoS chevauche d'ailleurs les deux mondes.
• Leurs points communs sont nombreux : invisibilité, évaluation du risque, simplicité, évolution, résilience, du design à la production, journalisation, réponse de crise, récupération.
• Les pratiques concrètes de Google — moindre privilège, autorisation multipartite (MPA), identifiants limités à une région, défense en profondeur, DiRT, IMAG — montrent comment faire émerger la sécurité et la fiabilité ensemble.
• Ces propriétés relèvent de toute l'organisation et de sa culture : penser sécurité et fiabilité dès le départ évite de payer un prix bien plus lourd plus tard.