Compromis de conception et safe proxies

La partie « Concevoir les systèmes » de Building Secure and Reliable Systems défend une idée simple à énoncer, exigeante à appliquer : la manière la plus économique d'intégrer la sécurité et la fiabilité est de le faire le plus tôt possible, dès la phase de conception. Ce chapitre couvre deux moments de cette partie. D'abord une étude de cas concrète — les safe proxies de Google, et notamment le Tool Proxy — qui montre comment rendre plus sûr un système déjà en production sans le réécrire. Ensuite, le raisonnement sur les compromis de conception (design tradeoffs) : pourquoi sécurité et fiabilité ne sont pas des fonctionnalités que l'on coche, mais des propriétés émergentes (emergent properties) du système entier, et pourquoi différer leur prise en compte au nom de la « vélocité » est une fausse économie qui se paie cher plus tard.

Étude de cas : les safe proxies en production

Imaginons qu'un adversaire veuille délibérément perturber vos systèmes. Ou, plus banalement, qu'un ingénieur bien intentionné disposant d'un compte privilégié commette par mégarde une modification aux conséquences vastes. Si vos systèmes sont bien compris et conçus pour le moindre privilège (least privilege) et pour la récupération (recovery), l'impact reste circonscrit, et la réponse à incident permet d'identifier la cause racine et d'agir. Tous les systèmes ne correspondent pourtant pas à ce tableau idéal : il faut souvent un moyen de rendre un système en marche plus sûr et moins sujet aux pannes. Les safe proxies sont l'une de ces méthodes.

Le principe général d'un proxy est de répondre à de nouvelles exigences de sécurité et de fiabilité sans modifier en profondeur les systèmes déployés. Plutôt que de toucher au système existant, on insère un proxy qui route les connexions qui seraient autrement allées directement au système, et l'on y greffe les contrôles voulus. Chez Google, les safe proxies forment un cadre qui autorise des personnes habilitées à consulter ou modifier l'état de serveurs physiques, de machines virtuelles ou d'applications particulières — pour relire, approuver et exécuter des commandes risquées sans ouvrir de connexion SSH vers les machines. Ils constituent un point d'entrée unique entre les réseaux, et permettent trois choses essentielles :

• auditer chaque opération sur l'ensemble du parc (fleet) ;
• contrôler l'accès aux ressources ;
• protéger la production des erreurs humaines à grande échelle.

Le modèle du safe proxy

Dans le modèle, au lieu de parler directement au système cible, les clients parlent au proxy. Google impose ce comportement en configurant le système cible pour qu'il n'accepte que les appels provenant du proxy. Cette configuration précise, via des listes de contrôle d'accès (access control lists, ACL), quels appels de procédure distante (remote procedure calls, RPC) de la couche applicative peuvent être exécutés par quels rôles de client. Après vérification des permissions, le proxy transmet la requête, qui sera exécutée via RPC sur le système cible ; chaque cible héberge typiquement un programme applicatif qui reçoit la requête et l'exécute. Le proxy journalise toutes les requêtes et commandes.

       Client (humain ou automatisation)
                  │
                  │  RPC (même API externe que la cible)
                  ▼
        ┌───────────────────────────────┐
        │           SAFE PROXY          │
        │  1. journalise tout (audit)   │
        │  2. vérifie l'ACL / la policy │
        │  3. MPA si action sensible    │
        │  4. limitation de débit       │
        └───────────────────────────────┘
                  │  (identité du client transmise)
                  ▼
        ┌───────────────────────────────┐
        │     Système cible             │
        │  config : n'accepte QUE       │
        │  les appels du proxy          │
        └───────────────────────────────┘

   Connexion directe ───X───►  refusée hors breakglass

Que le client soit un humain, de l'automatisation, ou les deux, le proxy apporte plusieurs bénéfices, qui forment le cœur réutilisable du pattern dans la suite du livre :

Bénéfice	Ce qu'il apporte concrètement
Autorisation multi-parties (multi-party authorization, MPA)	Un point central où l'on exige qu'un second utilisateur approuve une action avant qu'elle n'ait lieu, pour les requêtes touchant des données sensibles.
Audit d'usage administratif	Savoir quand une requête donnée a été exécutée et par qui.
Limitation de débit (rate limiting)	Un changement comme un redémarrage prend effet graduellement ; on restreint ainsi le rayon d'impact (blast radius) d'une erreur.
Compatibilité avec du tiers fermé	Contrôler le comportement de composants que l'on ne peut pas modifier (closed-source) via la logique ajoutée dans le proxy.
Amélioration continue	Ajouter de nouveaux renforts de sécurité et de fiabilité en un point central, dont profitent tous les appels.

Les contreparties à assumer

Le livre, fidèle à son honnêteté de blue team, ne masque pas les inconvénients du pattern. Un proxy a un coût de maintenance et d'exploitation. Il introduit un point de défaillance unique (single point of failure) si lui-même ou l'une de ses dépendances devient indisponible — risque que Google atténue en exécutant plusieurs instances pour la redondance, en exigeant des accords de niveau de service (service level agreement, SLA) acceptables de toutes ses dépendances, et en documentant un contact d'urgence pour chaque équipe propriétaire d'une dépendance.

La configuration de la politique de contrôle d'accès peut elle-même devenir une source d'erreurs ; Google guide les utilisateurs vers les bons choix en fournissant des modèles (templates) ou en générant automatiquement des réglages sûrs par défaut (secure by default). Le proxy est aussi une machine centrale dont un adversaire pourrait prendre le contrôle : pour limiter ce risque, le proxy transmet l'identité du client et exécute les actions en son nom — aucune requête ne s'exécute sous un rôle « proxy » à hauts privilèges. Enfin, le proxy suscite une résistance au changement : des utilisateurs souhaiteront se connecter directement à la production. Pour réduire cette friction, Google travaille étroitement avec les ingénieurs afin qu'ils puissent accéder aux systèmes via un mécanisme de breakglass en cas d'urgence.

Le Google Tool Proxy

Les Googlers réalisent la majorité de leurs opérations d'administration via des outils en ligne de commande (command-line interface, CLI). Certains sont potentiellement dangereux — un outil peut éteindre un serveur ; avec un sélecteur de portée (scope) incorrect, une simple invocation peut accidentellement arrêter plusieurs frontends et provoquer une panne. Suivre chaque outil CLI, garantir sa journalisation centralisée et protéger ses actions sensibles, un par un, serait difficile et coûteux. Google a donc créé un Tool Proxy : un binaire qui expose une méthode RPC générique exécutant en interne la ligne de commande spécifiée via un fork et un exec. Toutes les invocations sont contrôlées par une politique, journalisées pour l'audit, et peuvent exiger une MPA.

Le Tool Proxy atteint ainsi un des buts de Zero Touch Prod : rendre la production plus sûre en n'autorisant pas les humains à y accéder directement. Les ingénieurs ne peuvent pas lancer de commandes arbitraires sur les serveurs ; ils doivent passer par le Tool Proxy. Qui a le droit de faire quoi est défini par un jeu de politiques à grain fin. Une politique peut, par exemple, autoriser un membre de group:admin à lancer la dernière version de la CLI borg avec n'importe quel paramètre, après qu'une personne de group:admin-leads a approuvé la commande. La structure de cette policy, telle qu'elle apparaît dans le livre, se lit ainsi (translittérée pour la lisibilité) :

proxy_role: admin-proxy
tools:
  borg:
    mpm: client@live
    binary_in_mpm: borg
    any_command: true
    allow:
      - group:admin
    require_mpa_approval_from:
      - group:admin-leads
    unit_tests:
      - expected: ALLOW
        command: file.borgcfg up

Un ingénieur peut alors arrêter une tâche Borg en production depuis son poste de travail en préfixant simplement sa commande :

tool-proxy-cli --proxy_address admin-proxy borg kill ...

Cette commande envoie un RPC au proxy, qui enchaîne quatre étapes :

1. JOURNALISATION  ─► tous les RPC et vérifications sont loggés (audit a posteriori)
2. AUTORISATION    ─► la policy confirme que l'appelant est dans group:admin
3. MPA             ─► commande sensible : attente d'une approbation
                      d'une personne de group:admin-leads
4. EXÉCUTION       ─► si approuvé, exécution ; le proxy attache au RPC
                      le code de retour, stdout et stderr

Le Tool Proxy n'impose qu'un petit changement au flux de travail : préfixer ses commandes par tool-proxy-cli --proxy_address. Pour empêcher les utilisateurs privilégiés de contourner le proxy, Google a modifié le serveur afin qu'il n'autorise les actions d'administration qu'au rôle admin-proxy et refuse toute connexion directe en dehors des situations de breakglass.

Compromis de conception : exigences et propriétés émergentes

Construire un produit logiciel, c'est passer d'une idée de haut niveau à du code déployé. En chemin, des exigences et contraintes plus précises émergent : exigences fonctionnelles sur ce que fait le produit, contraintes générales de coût de développement et d'exploitation, et — au cœur de notre sujet — exigences de sécurité et de fiabilité. Certaines entrent en conflit ; il faut alors arbitrer et trouver le bon équilibre. Or les caractéristiques qui satisfont la sécurité et la fiabilité ont une nature très différente des fonctionnalités, et c'est ce qui rend ces arbitrages si délicats.

Exigences fonctionnelles vs propriétés émergentes

Les exigences fonctionnelles (feature requirements, ou functional requirements) identifient la fonction première d'un service et décrivent comment un utilisateur accomplit une tâche. Elles s'expriment en cas d'usage, récits utilisateur (user stories) ou parcours. Le sous-ensemble des exigences critiques est celui sans lequel il n'y a pas de produit viable. Les exigences fonctionnelles présentent un lien clair entre la spécification, le code qui la réalise et les tests qui la valident : un récit « l'utilisateur modifie son profil » se traduit en types structurés, en code d'interface, en handlers serveur, et se vérifie par un test d'intégration qui rejoue le scénario pas à pas.

Les exigences non fonctionnelles (nonfunctional requirements) — au premier rang desquelles la sécurité et la fiabilité — sont bien plus difficiles à cerner. Il serait commode qu'un serveur web possède un drapeau --enable_high_reliability_mode qu'il suffirait d'activer. Mais ce drapeau n'existe pas, et aucun module ne « implémente » la fiabilité. C'est l'idée-force du chapitre : la fiabilité comme la sécurité sont des propriétés émergentes de la conception du système entier — et même de tout le flux de développement, de déploiement et d'exploitation.

Aspect	Exigence fonctionnelle	Propriété émergente (sécurité / fiabilité)
Nature	Comportement spécifique attendu	Attribut général du système entier
Localisation	Code dédié, identifiable	Aucun module unique ; diffuse dans toute l'architecture
Spécification	Récit utilisateur, cas d'usage	Contraintes transverses, SLO, modèles de menace
Validation	Test d'intégration rejouant le scénario	Revues de conception, tests de sécurité, PRR, tests de charge, monitoring
Coût d'ajout tardif	Souvent local et circonscrit	Souvent fondamental : refonte, réécriture partielle

La fiabilité émerge de facteurs comme le découpage en composants (microservices), la dépendance de la disponibilité du service à celle de ses backends et de sa plateforme, les mécanismes de communication (RPC, files de messages, bus d'événements), le routage, l'équilibrage et le délestage de charge (load balancing, load shedding), l'intégration des tests unitaires, de bout en bout, des revues de mise en production (production readiness reviews, PRR) et des tests de charge dans le flux, et enfin la qualité du monitoring. De même, la posture de sécurité ne naît d'aucun « module de sécurité » : elle émerge de la décomposition du système et des relations de confiance entre composants, des langages et frameworks choisis, de l'intégration des revues et tests de sécurité dans le flux, et des outils de journalisation d'audit et de détection d'anomalies disponibles pour les analystes.

Le document de conception de Google

Pour ancrer ces préoccupations avant le code, Google utilise un modèle de document de conception (design document template) qui guide la conception de chaque nouvelle fonctionnalité et recueille le retour des parties prenantes avant le démarrage. Ses sections relatives à la fiabilité et à la sécurité rappellent aux équipes de penser aux implications de leur projet et de lancer, le cas échéant, les processus de revue de mise en production ou de revue de sécurité — parfois plusieurs trimestres avant la phase de lancement. Le modèle interroge notamment la scalabilité, la redondance et la fiabilité (perte locale de données, erreurs transitoires), les dépendances (que se passe-t-il si elles sont indisponibles ? introduit-on des cycles ?), l'intégrité des données (comment détecter et récupérer une corruption ?), les exigences de SLA, et les considérations de sécurité et de confidentialité — où l'on demande explicitement de décrire les attaques pertinentes, leur impact pire cas et les contre-mesures. Si un projet n'a aucune considération de sécurité, il faut l'affirmer explicitement et dire pourquoi.

Équilibrer les exigences : l'exemple du traitement des paiements

L'exemple canonique du livre illustre la profondeur des interdépendances. Soit un service vendant des widgets en ligne ; accepter un paiement est une exigence critique. Mais accepter des noms, adresses et numéros de carte introduit aussitôt des exigences de sécurité et de fiabilité lourdes : ce sont des données personnelles sensibles, soumises à des standards comme PCI DSS, et dont la compromission peut faire perdre la confiance des clients — certaines entreprises ont disparu après un incident grave.

La meilleure manière d'atténuer ces risques est souvent de ne pas détenir la donnée du tout : déléguer le traitement à un prestataire tiers. On réduit alors le risque de compromission, on simplifie parfois les obligations de conformité, on évite de bâtir l'infrastructure de protection des données au repos, et on peut profiter des contre-mesures anti-fraude du prestataire. Mais cette délégation crée à son tour de nouveaux risques. Le livre déroule alors une cascade vertigineuse :

Risque de SÉCURITÉ : on ne veut pas stocker les données de paiement
        │  → on délègue à un prestataire tiers
        ▼
Risque de FIABILITÉ : nouvelle dépendance externe, nouveaux modes de panne
        │  → on ajoute une file d'attente pour bufferiser si le prestataire tombe
        ▼
Risque de FIABILITÉ : une file en mémoire volatile peut perdre des transactions
        │  → on rend la file durable (stockage sur disque)
        ▼
Risque de SÉCURITÉ : écrire les données de paiement sur disque réintroduit
        le risque de compromission qu'on cherchait à éviter au départ !
        │  → pire : un attaquant interne pourrait COUPER le lien avec le
            prestataire exprès pour activer la file locale et la compromettre

On aboutit à un risque de sécurité né d'une tentative de mitiger un risque de fiabilité, lui-même né d'une tentative de mitiger un risque de sécurité. S'y ajoutent des risques de sécurité directs : confier des données sensibles à un tiers dont il faut évaluer la posture en continu ; lier une bibliothèque fournie par le prestataire (et ses dépendances transitives) que l'on peut atténuer par du sandboxing ; ou inclure une bibliothèque JavaScript côté client qui s'exécute avec tous les privilèges de l'origine web de l'application — atténuable par un iframe isolé au prix d'un canal de communication cross-origin sécurisé, donc d'une complexité supplémentaire. Parti d'un arbitrage sur les données de paiement, on se retrouve au cœur de la sécurité de la plateforme web, avec des implications contractuelles et réglementaires.

Gérer les tensions et aligner les objectifs

Le tableau n'est pourtant pas voué au conflit perpétuel. Avec un peu de planification en amont, on satisfait souvent les exigences non fonctionnelles sans sacrifier de fonctionnalités et à coût raisonnable — car ces objectifs sont en réalité très alignés avec les attributs généraux de qualité logicielle. Le livre prend l'exemple d'un framework interne de microservices et d'applications web. Son but premier était de fluidifier le développement, via des vérifications de conformité (conformance checks) statiques et dynamiques : par exemple, vérifier que toute valeur passée entre contextes d'exécution concurrents est d'un type immuable (ce qui réduit drastiquement les bugs de concurrence), ou imposer l'isolation entre composants. Grâce à cette structure rigide et bien définie, le framework automatise quantité de tâches — scaffolding, intégration continue, déploiements — ce qui l'a rendu populaire.

Le lien avec la sécurité et la fiabilité ? L'équipe du framework a collaboré avec les équipes SRE et sécurité durant toute la conception, tissant les bonnes pratiques dans l'étoffe du framework plutôt que de les y boulonner à la fin. Le framework prend en charge la plupart des vulnérabilités web courantes : par une combinaison de design d'API et de conformance checks, il empêche les développeurs d'introduire accidentellement ces failles — allant au-delà du « sûr par défaut » pour prendre pleinement la responsabilité de la sécurité sur ces classes de risques. C'est un scénario gagnant-gagnant : les développeurs adoptent le framework parce qu'il leur facilite la vie ; les ingénieurs sécurité et SRE disposent d'une surface commune où ajouter des fonctionnalités ; et un build vert devient une garantie raisonnable que le projet n'est pas affecté par les risques déjà couverts. Les corrections propagées depuis un framework central bénéficient automatiquement à toutes les applications reconstruites.

Cet alignement se retrouve sur d'autres axes : l'intelligibilité (understandability) du système — clé pour raisonner sur ses invariants — sert à la fois la sécurité, la fiabilité et la vélocité de développement ; concevoir pour la récupération permet de quantifier et contrôler le risque des changements, donc de soutenir une cadence de déploiement plus élevée ; et concevoir pour un paysage mouvant rend le système plus adaptable, tant face aux nouvelles vulnérabilités qu'aux évolutions métier.

Vélocité initiale vs vélocité soutenue

Reste la tentation, surtout dans les petites équipes, de différer la sécurité et la fiabilité : « on ajoutera la sécurité et on se souciera du passage à l'échelle quand on aura des clients ». On justifie l'arbitrage au nom de la « vélocité ». Le livre y oppose une distinction cruciale entre vélocité initiale (initial velocity) et vélocité soutenue (sustained velocity).

Renoncer à traiter tôt des exigences critiques — sécurité, fiabilité, maintenabilité — peut effectivement accroître la vélocité au début. Mais l'expérience montre que cela vous ralentit fortement ensuite. Le coût tardif d'une refonte pour accommoder des exigences qui se manifestent comme des propriétés émergentes est très substantiel ; pire, faire ces changements invasifs sous la pression d'un incident introduit de nouveaux risques de sécurité et de fiabilité. D'où l'impératif d'ancrer ces préoccupations dans la culture d'équipe dès le départ.

                 ▲ Vélocité
                 │
                 │            ╭───────────────  « investir tôt »
                 │          ╭─╯                  (lente au début,
                 │        ╭─╯                     rapide et durable)
                 │   ╭────╯
                 │ ╭─╯        ╲___
                 │╱               ╲____  « différer »
                 │   ↑ rapide au début   ╲____ (dette, refontes,
                 │     mais...                  ralentissement)
                 └──────────────────────────────────────►  Temps

L'histoire d'Internet illustre l'arbitrage. La fiabilité — survie du réseau malgré la panne de nœuds, communication fiable sur des liens faillibles — était un objectif explicite et prioritaire des précurseurs comme ARPANET. La sécurité, elle, est quasi absente des premiers documents : les réseaux étaient fermés, opérés par des institutions de confiance. Sur l'Internet ouvert d'aujourd'hui, cette hypothèse s'effondre. IP, UDP et TCP n'ont aucun moyen d'authentifier l'émetteur ni de détecter une modification malveillante des données ; HTTP et DNS y sont intrinsèquement vulnérables. Des protocoles sécurisés ont été ajoutés après coup — HTTPS, IPsec — mais leur déploiement large s'est révélé difficile : cinquante ans après les débuts d'Internet, une part substantielle du trafic web n'utilise toujours pas HTTPS. Le rattrapage tardif d'une propriété émergente est lent et incomplet.

L'investissement dans un flux d'intégration et de déploiement continus (CI/CD) mûr — couverture de tests suffisante, pipeline fiable, infrastructure de déploiements et de rollbacks échelonnés, architecture permettant des déploiements découplés (feature flags) — est modeste lorsqu'il est consenti tôt et ne demande ensuite qu'un effort incrémental pour maintenir des builds verts. À l'inverse, un flux à tests pauvres, étapes manuelles et longs cycles finit par engluer le projet ; le rattrapage exige alors un gros effort d'un coup, et les tests ajoutés tardivement risquent même de figer le comportement bogué plutôt que le comportement correct. Ces investissements profitent aux projets de toute taille, mais les grandes organisations amortissent leur coût sur de nombreux projets : l'engagement d'un projet individuel se résume alors à utiliser les frameworks et flux maintenus centralement.

À retenir

• Les safe proxies (dont le Google Tool Proxy) ajoutent audit, contrôle d'accès, autorisation multi-parties (MPA), limitation de débit et breakglass à un système existant sans le réécrire ; ils incarnent Zero Touch Prod (aucun accès humain direct à la production) et auraient pu prévenir ~13 % des pannes analysées par Google.
• Un proxy a un prix : coût d'exploitation, point de défaillance unique (mitigé par la redondance), policy faillible (mitigée par des templates sûrs par défaut) et résistance au changement (mitigée par le breakglass) — le pattern n'est pleinement résilient qu'associé aux autres principes de conception.
• La sécurité et la fiabilité ne sont pas des fonctionnalités mais des propriétés émergentes du système entier et de tout le flux de développement, déploiement et exploitation : aucun module ne les « implémente ».
• Parce qu'elles sont émergentes, ces propriétés sont des choix de conception fondamentaux ; les « boulonner » tard exige refontes et réécritures coûteuses et risquées — l'exemple du traitement des paiements montre que chaque mitigation déplace le risque plutôt que de l'effacer.
• Les objectifs de sécurité/fiabilité sont en réalité alignés avec la qualité logicielle (intelligibilité, récupération, adaptabilité) ; un framework co-conçu avec les équipes SRE et sécurité rend les applications sûres et fiables par construction, gagnant-gagnant pour développeurs et défenseurs.
• Distinguer vélocité initiale et vélocité soutenue : différer la sécurité et la fiabilité accélère au début mais ralentit durablement (dette, refontes sous pression) ; investir tôt coûte peu et accélère sur la durée.
• Outiller ces décisions dès l'amont — document de conception avec sections scalabilité, redondance, dépendances, intégrité, SLA et sécurité ; revue de sécurité déclenchée tôt ; CI/CD mûr et frameworks centraux — ancre la sécurité et la fiabilité dans la culture d'équipe.