Zero Trust Architecture : vers un SI où le périmètre n’importe plus

Depuis quelques années, un couple de mots ressort de plus en plus dans le monde de la sécurité.
Cette combinaison de termes, c’est "Zero Trust".

C’est un couple qui revient beaucoup, mais le concept est encore méconnu, mal compris et parfois déformé par un excès de marketing.

Alors, c’est quoi Zero Trust ? Qu’est-ce que ça change à nos SI ? Au-delà du concept, comment peut-on le décliner ?

Dans cet article, on va donc creuser un peu ce concept qui consiste à minimiser au maximum la confiance en notre infrastructure. On parlera aussi de Zero Trust Architecture, le terme générique regroupant les architectures liées à ce modèle. Et cela pourrait changer la façon dont vous concevez la sécurité.

I - Les limites de la sécurité périmétrique

Afin de comprendre les origines de Zero Trust (parfois abrégé ZT), il est nécessaire de revenir sur les éléments qu’il remet en cause dans les approches courantes de la sécurité.

On ne reviendra pas sur la totalité de ce qu’est le monde de la sécurité informatique aujourd’hui, aussi, nous nous concentrerons sur les éléments remis en question par Zero Trust. Remarquez que ces choix sont bien entendus orientés pour les besoins de l’explication de ce qu’est Zero Trust. Tout n’est pas à jeter dans les pratiques actuelles.

Quelques prémisses (quelque peu caricaturées, entendons-nous bien) de l’approche traditionnelle de la sécurité sont :

• Les attaquants n’auront pas accès à mon réseau / sous réseau. S’ils y arrivent, ils auront des difficultés à basculer des uns vers les autres.
  Une segmentation réseau bien faite est donc efficace et essentielle. Grâce à elle, je peux faire confiance à tous les éléments à l’intérieur. Je dois en revanche être particulièrement robuste aux bornes de mon réseau afin de ne pas faire confiance à un attaquant.
• Je connais à l’avance la typologie de mes utilisateurs. Si je suis une DSI, ce sont mes salariés. Ils travaillent depuis mes locaux, sur des périphériques dont j’ai la maîtrise. Je suis en capacité de les empêcher d’accéder à mon SI par d’autres moyens.
• Les cas où mes employés devront télétravailler sont rares et exceptionnels. Ces employés en télétravail seront peu nombreux et je trouverai un moyen efficace de leur permettre de travailler sur mon réseau. Grâce, par exemple, à un VPN.

Certaines de ces prémisses se sont avérées fausses ces dernières années. Les autres sont bousculées.
Quelques mouvements principaux ont retenu notre attention :

Le travail dans les métiers du tertiaire connaît un mouvement diffus mais réel vers plus de travail à distance. La pandémie de COVID-19 ayant massivement accéléré ce phénomène. À tel point que de plus en plus d’entreprises, particulièrement dans l’IT (Facebook, Spotify, Twitter...) annoncent désormais faire du télétravail une stratégie de long terme. Leurs employés n’auront donc pas accès (du moins directement) au réseau qui est censé assurer la sécurité du système.
De plus, on vous en parlait l’année dernière, les VPN sont une brique assez difficile à maîtriser dans un SI. Ils ont du mal à tenir des charges aussi massives que celles que l’on souhaite leur faire encaisser ces derniers temps. Il faut donc investir très sérieusement dans l’ingénierie ou payer très cher un éditeur qui le fera pour vous… juste pour permettre à vos utilisateurs d’accéder à votre SI.

La croissance incroyable et la généralisation de l’utilisation du cloud public semblent aussi être un mouvement majeur de l’informatique. Or, avoir une application dans le cloud public, c’est accepter de sortir une partie de son métier de son réseau d’entreprise. Celui-là même qui était un élément de base de notre stratégie de sécurité. On peut bien sûr simuler une appartenance au SI grâce, une fois de plus, à des VPN. Cependant ces solutions sont toujours des solutions de contournement et lorsqu’une partie significative (20%, 30%, 50% ?) de mes nouvelles applications sont dans des clouds publics, est-il vraiment sain de maintenir un régime d’exception ?

Troisième élément, les DSI externalisent une bonne partie de leur main-d'œuvre à des sociétés de services et/ou de conseil. Il est aujourd’hui excessivement rare pour la DSI d’une grande entreprise de dépasser 50% d’internes. Il est donc compliqué de faire travailler tout le monde avec du matériel sous contrôle. Il est aussi très difficile de définir un profil générique pour les externes qui auront forcément accès à notre réseau (ce qui, on le rappelle, est l’un des éléments de notre stratégie de défense).

Ces situations offrent donc un véritable challenge aux postulats proposés. Le lecteur le plus sagace aura peut-être déjà remarqué qu’il semblerait confortable de s’affranchir de certaines limites. Et si l’on arrêtait de contrôler nos SI par leurs réseaux ?

II - Les concepts de Zero Trust

Zero Trust propose donc une approche différente de la sécurité. On relègue la sécurité par le périmètre réseau au second plan, car le problème est peut-être ailleurs. Cette approche, on l’a dit, a connu une vague de popularité ces derniers temps. Cependant, arrêter de se baser sur la sécurité périmétrique et utiliser des modèles différents est un argument récurrent (à défaut d’être sur le devant de la scène) depuis… au moins 2004.

Ce que propose le modèle est résumé dans le terme lui-même : "Zero Trust". L’idée est de renoncer à cette confiance faite par défaut à un acteur tiers, quelle que soit sa provenance. Désormais tout le monde doit prouver qui il est (s’authentifier) et ce qu’il a le droit de faire (ce qu’il est autorisé à faire) avant de pouvoir accéder ou agir sur une ressource.

Ce qui est proposé ici ce n’est pas de détruire le modèle de sécurité traditionnel. On souhaite bel et bien transformer ce modèle en trouvant des stratégies plus efficaces ; tant en termes de sécurité que d’usabilité.

Il est sur mon réseau ? Et alors ? Qu’il prouve qui il est et qu’il a le droit de discuter avec moi !

Extrait du discours (fictif) d’un système propriétaire d’une ressource en Zero Trust

Les impacts de ce simple concept sur les douleurs identifiées précédemment sont importants. Puisque le périmètre (c'est-à-dire le filtrage des utilisateurs par le réseau) ne me protège pas, je peux le remplacer par des stratégies pilotées, cohérentes et renforcées d’authentification. Cela implique que :

• Une application peut être accessible via internet sans que cela soit un problème. Cela favorise à la fois le cloud et le télétravail.
• La sécurité de l’accès à une application repose sur un filtrage unitaire de ses utilisateurs. Cela se fait selon des profils qui sont maîtrisés et avec une granularité dans les droits ; à la fois au niveau de l’organisation et des applications.

D’un côté, on a donc les problématiques présentées en partie I, toutes résolues (ou partiellement résolues) directement ou indirectement par Zero Trust.
De l’autre, on a aussi quelques avantages supplémentaires (ou renforcement des bonnes pratiques existantes) par rapport à une protection par le réseau :

• Tous les flux doivent être justifiés. On ne fait pas confiance au réseau donc si un flux existe, c'est qu’il doit avoir une bonne raison d’être là. S’il n’a pas de raison d’exister, il est éliminé. C’est une bonne pratique qui n’est pas directement liée à Zero Trust, mais elle devient obligatoire avec lui. Cela signifie une limitation forte d’un schéma d’attaque très fréquent : les attaques par rebond.
• Vu que tous les flux sont authentifiés, il est plus facile de mettre en place des politiques globales liées à l’authentification, pour peu que votre architecture le permette.
• Cela permet la formalisation et le rassemblement de patterns d’architecture communs et reconnus, souvent identifiés comme des bonnes pratiques. Et ce au sein d’un ensemble plus cohérent.

Cette architecture, justement, c’est le sujet de notre prochaine partie.

III - L’architecture Zero Trust (ZTA)

L**’architecture Zero Trust** ou Zero Trust Architecture (ZTA) pour les plus anglophiles, c’est un modèle d’architecture générique proposé afin de répondre aux enjeux de Zero Trust.

Ce modèle, on le retrouve notamment dans la définition du NIST de Zero Trust. C’est une preuve que les éléments de base proposés ici sont reconnus par les praticiens comme étant une solution classique à la problématique.

Cela ne signifie pas qu’il s’agit de la seule solution possible pour faire du Zero Trust. Ni même que ZTA couvre entièrement les concepts de Zero Trust. Cela signifie simplement que cette implémentation spécifique fonctionne bien pour certaines organisations qui l’utilisent, y compris à l’échelle.

L’architecture Zero Trust classique (NIST) pourrait basiquement être décrite par ce schéma, qu’on détaillera par la suite :

Nous allons illustrer cette architecture avec l’exemple d’un système de gestion de la relation client : un CRM. Celui-ci est développé en interne par l’entreprise La Grosse Boîte. On a donc notre application (le-crm), où une chargée de clientèle (Nadia) veut modifier l’adresse d’un de ses clients (Denis). Ce cas aurait cependant pu être décliné dans à peu près tous les cas d'usage d’une application à usage interne et développée sur mesure.

1. Subject, Resource, Resource Management System

En tant que système de sécurité et schéma d’authentification et d’autorisation, Zero Trust a l’objectif suivant : assurer que l’utilisateur (Subject) puisse accéder à la ressource (Enterprise Resource ou Resource) - soit la donnée à traiter et à protéger.

On représente ici notre Subject comme un humain. Cependant, il peut très bien s’agir d’un utilisateur qui n’est pas humain. Votre application peut être utilisée par d’autres services, dans des contextes "machine-to-machine" sans que cela pose le moindre problème pour Zero Trust. Car en réalité un tel contexte est un contexte où vous accordez votre confiance au développeur et à l’opérateur du produit.

Dans notre exemple, le Subject sera donc Nadia, utilisatrice de le-crm. La Resource sera l’adresse de Denis.

Le Resource Management System est la brique permettant de traiter et de gérer l’Enterprise Resource. Le plus souvent, c’est une application. Cette brique n’est pas dans la norme, car elle n’est pas fondamentalement nécessaire. On pourrait accéder directement à la ressource sans intermédiaire. Cependant, conceptualiser le Resource Management System aide à une meilleure compréhension du modèle, car il s’agit souvent d’un élément sous-entendu. On a donc choisi de le représenter ici. Il s’agit dans notre exemple de l’application web qui permet d’accéder et de modifier la donnée du profil : c’est-à-dire l’application le-crm.

2. System

L’utilisateur, pour pouvoir accéder à la Resource va aussi utiliser un System. Cela correspond à son moyen d’accès au système de gestion de la ressource. Dans le cas de notre CRM, on l’a dit, l’utilisateur y accède via une application web. Le System correspond donc à l’ensemble des moyens permettant l’accès à l’application, et notamment :

• Le navigateur web de l’utilisateur
• Son système d’exploitation
• La machine avec laquelle il accède à la donnée (son hardware)

3 Eléments coeur de l’Architecture Zero Trust

Parlons désormais des éléments centraux de l’Architecture Zero Trust. On ne les définira que peu par rapport au métier de l’application car ils sont des éléments d’architecture technique plus que des éléments profondément métier. Il y en a trois et ils sont situés au centre sur notre schéma :

3.1 Policy Engine

Le Policy Engine : c’est un élément qui est géré à l’échelle de notre organisation. Ici à l’échelle du SI de La Grosse Boîte. L’idée de ce composant est de créer des stratégies liées à l’authentification et l’autorisation pour toute l’organisation.
Ces règles peuvent être très génériques et s'appliquent de manière globale (ce ne sont pas des règles pour un flux unitaire).

On mettra ici par exemple des règles liées à une authentification telle qu’on la conçoit aujourd’hui. Par exemple, une politique de mot de passe (sans règles liées à la composition de préférence).

Là où Zero Trust va plus loin, c’est qu’il remet en avant un élément un peu à la marge (pour le grand public du moins) dans le monde de l’authentification ces dernières années : l'authentification basée sur le score ou sur le risque (on verra souvent risk-based authentication). L’idée est de fournir des éléments contextuels sur le risque lié à la requête à la place ou en plus des éléments non contextuels.

Par exemple :

• Pour se connecter sur le-crm, Nadia rentre son identifiant et son mot de passe. Ces éléments sont non contextuels. Si c’est le seul contrôle qui est fait :
  • Soit ils sont vrais et ils le sont en toute circonstance et alors elle devra être autorisée.
  • Soit ils sont faux et ils le sont en toute circonstance et alors elle devra être rejetée.
• Cependant, Nadia, qui accède d’habitude à ses clients depuis Paris, y accède désormais depuis Bichkek. De plus, elle a accédé à l’application il y a une heure… et elle semblait bien se trouver à Paris. Elle utilise cette fois-ci Windows alors qu’elle accède habituellement à ses comptes sur sa tablette sous iOS.
  Tous ces éléments inhabituels peuvent alimenter la diminution d’un score de confiance en la requête qui peut aboutir à plusieurs choses. De manière un peu brutale, on pourrait simplement jeter sa requête. Ou bien demander des éléments non contextuels supplémentaires et/ou plus forts pour prouver qu’il s’agit bien d’elle (un TOTP par exemple, voir plus).

C’est ce composant qui fait de l’architecture Zero Trust une approche à échelle d’un SI. Si ce composant est absent, vous n’implémentez pas vraiment une architecture Zero Trust car votre implémentation perd son aspect systémique. Vous ne mutualisez et ne consolidez pas vraiment les stratégies d’authentification.

3.2 Policy Enforcement Point

Le Policy Enforcement Point (PEP) se situe cette fois-ci au niveau de l’architecture technique d’un produit (ici, c’est donc la responsabilité de le-crm). On peut le voir comme une pure brique technique dont le rôle principal est de servir de porte d’entrée (avec un videur, le Policy Administrator, dont on parle juste après !) à notre application.

La porte peut donc être ouverte ou fermée pour un utilisateur, dans un certain contexte et à cause de son niveau d’authentification ou d’autorisation.

En plus de son rôle principal de porte (ouverte / fermée), le PEP centralise les accès à notre application. Il peut donc être utile et sain de lui adjoindre des opérations de traçage et de monitoring des accès.

3.3 Policy Administrator

Le Policy Administrator (PA) est une fois de plus un élément de l’architecture de notre application.
Ce composant correspond à la vraie brique d’authentification de l’architecture. Il s’occupe de :

• Tirer ses règles du Policy Engine et les choisir afin de pouvoir authentifier et autoriser chaque flux de manière pertinente. On voudra par exemple mettre en place des règles plus strictes pour des flux d’administration que pour un flux HTTP classique.
• Vérifier si l’utilisateur est autorisé ou non à entrer et donner des instructions au PEP en conséquence (ouvert / fermé). On en a parlé précédemment, cette vérification peut être contextuelle avec des éléments comme la localisation du Subject ou encore son système d’exploitation.

L’idée ici est de se servir du PA avec un protocole d’authentification ou d’autorisation classique (par exemple OpenID Connect). On se sert de cette brique comme on se servirait d’un Authorization Server en Oauth2 (c’est d’ailleurs souvent à proprement parler un Authorization Server Oauth2 en 2021 !).

L’idée principale est donc de le contacter, qu’il vérifie et atteste ce qu’on a le droit de faire sur le périmètre de notre application puis qu’on le laisse tranquille jusqu’à la prochaine fois.

Dans le cas de le-crm, c’est lui qui fournit la page de login et délivre les tokens aux utilisateurs.

Même si conceptuellement, le PA et le PEP ont des rôles distincts, ils seront, dans certaines implémentations, regroupés dans une seule brique commune par souci de simplicité. Il est en effet souvent plus simple de rassembler la porte et le videur qui est censé contrôler celle-ci.

4. Eléments annexes et contextualisation

On ne les détaillera que peu mais les éléments qui sont en dehors du cadre sont des éléments qui donnent de l’information pour une prise de décision du Policy Administrator.

Concrètement, il s’agit d’éléments servant à contextualiser la demande d’authentification / d’autorisation par différents moyens, pouvant inclure :

• Des éléments liés à la conformité et à la politique de l’entreprise (CDM System, Data Access Policy, PKI, ...). On en a par exemple beaucoup parlé, l’élément qui représente la conformité du poste de travail (OS, configuration de celui-ci, navigateur et plus) est le bloc CDM System (pour "Continuous Diagnostics and Mitigation").
• Des éléments liés à l’environnement (Threat Intelligence, SIEM System, ...). Cela peut notamment permettre une estimation du risque d’attaque sur un composant à un moment donné.
• Des éléments liés à l’état de notre système (Activity Logs, ...). Cela pourrait nous servir par exemple à répondre à une question comme "Dois-je laisser quelqu’un se connecter en tant qu’administrateur alors qu’un autre administrateur est déjà actif sur la plateforme ?"
• … Et on pourrait en imaginer beaucoup d’autres.

IV - Une architecture Zero Trust, concrètement

À ce moment de l’article, vous pourriez être tenté de vous dire quelque chose comme "Oui, bon c’est bien gentil tous ces concepts mais jusqu’ici je n’ai rien de concret à mettre en place sur mon SI".

On vous propose donc de voir un premier exemple d’implémentation, celui de Google, qui réfléchit à cette architecture depuis une dizaine d’années et l’utilise depuis quelque temps. Ça s’appelle Beyond Corp et ils commencent aujourd’hui à le commercialiser packagé via Google Cloud Platform (avec des offres comme Beyond Corp Enterprise).

Beyond Corp, c’est basiquement le modèle autour duquel l’architecture Zero Trust a émergée. Les définitions de la ZTA viennent en grande partie de l’implémentation Beyond Corp, en supprimant le spécifique au besoin de Google et en généralisant.
C’est la raison pour laquelle on retrouve toutes les briques standard et quelques possibilités avancées dont on a parlé précédemment (quelques éléments de contextualisation de la requête notamment).

C’est aujourd’hui, assez logiquement, l’offre la plus mature du marché.

Une correspondance partielle des éléments Zero Trust et de l’offre commerciale Beyond Corp pourrait être la suivante :

Un point important à noter est que si ce découpage et cette implémentation de l’architecture Zero Trust sont adaptés aux besoins de Google, on peut évidemment transformer les composants et en fusionner ou bien en supprimer selon les besoins de notre organisation.

Nous n’avons peut-être pas exactement les mêmes besoins ou les mêmes contraintes réglementaires que Google. Nous devons donc travailler autour de ces architectures pour en tirer le meilleur, sans en trahir les principes de base.
Par exemple, disons que vous êtes une organisation de petite taille. Votre Policy Engine pourra être une brique légère. Cloud IAP est un outil puissant et qui grossit beaucoup. Peut-être que dans un premier temps, il sera plus intéressant pour vous d’avoir un outil plus léger, plus simple et qui vous permet juste de dire des choses comme : "la politique de mot de passe est au moins 12 caractères et les flux d’administration doivent utiliser une authentification multi facteurs".

De plus, Beyond Corp n’est pas la seule implémentation possible d’une architecture Zero Trust aujourd’hui. On pourrait citer CloudFlare Access, une autre solution clé en main pour faire du Zero Trust.

Et si vous souhaitez garder la maîtrise et/ou avoir plus de flexibilité, il est possible de reproduire une architecture Zero Trust sans faire appel à des services packagés. Il existe aujourd’hui un bon nombre de briques Open Source qui peuvent - voir se destinent à - servir de Policy Administrator et de Policy Enforcement Point. Libre à vous de créer ou d’intégrer les blocs autour. Ces briques centrales, ce sont les proxys d’autorisation ou "gatekeeper".

Pour en citer quelques uns : ORY OathKeeper, Pomerium, OAuth2 Proxy.

V - L'architecture Zero Trust, c’est pour moi ?

Zero Trust est - pour nous - un concept qui a de l’avenir. On souhaite limiter la place du périmètre dans le monde de la sécurité. On en a parlé dans la partie I, cela répond à des problématiques en croissance.
Il nous semble donc intéressant pour toutes les organisations de connaitre et de s’inspirer de Zero Trust pour structurer les décisions sécurité.

Cependant, la migration de tout un SI vers une architecture Zero Trust représente un chantier important et structurant, et il n’est pas sûr que chacun souhaite s’y attaquer n’importe quand.

Pour avoir un premier niveau de réponse à "Dois-je migrer vers une architecture Zero Trust ?", il est nécessaire de se poser ces quelques questions :

• Les utilisateurs de mon SI ont-ils la possibilité de travailler hors de mon réseau (en raison de la nature de leur métier, en mettant de côté toutes contraintes liées à de la sécurité du numérique) ?
• La plupart de mes applications sont-elles des applications web, ou la part de celles-ci est-elle en augmentation constante ?
• Est-ce que j’utilise beaucoup le cloud, ou est-ce que sa part d’utilisation est en augmentation constante ?

Si vous répondez "non" à au moins une de ces questions, vous n’avez sans doute pas (aujourd'hui) un bon rapport utilité / difficulté d’accès pour la mise en place d’une architecture Zero Trust. Dans le cas contraire, la question peut se poser.

On pourrait résumer l’arbre de décision ainsi :

Maintenant qu’on a vu dans quel contexte il peut être intéressant de transitionner vers une architecture Zero Trust pour son SI, on peut aussi se poser la question inverse. Mon organisation est-elle prête pour une architecture Zero Trust ?

En effet, comme pour tout changement d’ampleur sur l’architecture du SI, il est pour le moins douteux de penser qu’il est possible de changer en profondeur son archi sans changer son organisation (la Loi de Conway, vous connaissez peut-être).

Le passage de tout un SI vers une architecture Zero Trust est un projet de transformation majeur et ne se fera pas sans votre RSSI et/ou votre équipe sécurité. Il faudra qu’ils soient convaincus de l’intérêt pour les utilisateurs du SI. Il faudra aussi qu’ils comprennent les avantages en termes de sécurisation des ressources. Il faudra qu’ils soient convaincus que changer une bonne partie du fondement de leur modèle de sécurité actuel sera rentable à moyen terme.

Bref, il faudra convaincre et changer l’organisation et les manières de penser.

Pour ce qui est de la migration en elle-même, c’est un sujet à part entière et cet article étant déjà long, on ne va donc pas s’étendre dessus ici.

On vous propose cependant quelques axes qui nous semblent de bonnes stratégies de priorisation pour une migration :

1. Commencez avec un périmètre restreint et sur des applications en développement actif (il faut savoir maîtriser l’infrastructure et traiter les flux et ça peut demander du travail et des adaptations sur les produits). Par exemple, préférez des applications où le sujet de l’authentification n’a pas encore été traité pour commencer.
2. Commencez sur des applications Cloud Natives et hébergées sur un cloud (public ou privé). Ce sont les applications les plus adaptées, Zero Trust a été conceptualisé en partie pour mieux les traiter.
3. Mettez de côté vos progiciels ou outils en mode SAAS (dans un premier temps en tout cas), à cause de leur manque de flexibilité.

VI - Synthèse

Ce qu’on a vu au cours de cet article, c’est que Zero Trust est un modèle de sécurité basé sur la limitation maximale de la confiance dans les systèmes d'information. Notamment de la confiance dans le réseau d’entreprise.

Cet objectif de base a des impacts énormes sur la façon dont on conçoit la protection de notre périmètre métier. Il ne s’agit plus de protéger une ville avec des murs très hauts et très épais. Il s’agit désormais de protéger un grand nombre d’habitations éparses, en plaçant une porte identique à l’entrée de chacune d’entre elles.

Si Zero Trust est un concept, l’architecture Zero Trust (Zero Trust Architecture ou ZTA) est une adaptation de ce concept sous forme d’une architecture générique, implémentable à l’échelle d’un SI.

Zero Trust répond à des problématiques qui semblent être des mouvements de fond du domaine de l’IT et qui sont des douleurs pour les stratégies de sécurité traditionnelles. Cloud, télétravail, externalisation, effacement du périmètre … sont autant de points de crispation et de contournement des politiques de sécurité des entreprises.

Zero Trust nous semble aujourd'hui être un modèle très prometteur pour la structuration d’un SI. C’est un modèle qui permet de diminuer les contraintes pour les utilisateurs tout en améliorant notre niveau de sécurité et en éliminant les crispations susnommées. C’est exactement ce que l’on cherche lors de la mise en place d’un système de sécurité.

Pour ces raisons, mettre en place Zero Trust nous semble un investissement d’avenir qui pourrait être extrêmement intéressant pour beaucoup de SI.
En effet, aujourd’hui est sans doute le meilleur moment pour entamer un chantier de passage vers des politiques Zero Trust, si votre contexte le permet. La réflexion sur ces sujets est mature, les technologies qui répondent au besoin émergent.

C’est un chantier d’ampleur, mais c’est surtout un changement qui sera bénéfique à moyen et long terme, et qui permettra d’accompagner de manière plus sereine des mouvements déjà en œuvre dans nos organisations.

Pour aller plus loin :

• Zero Trust Architecture A.K.A NIST 800-207 par le NIST
• BeyondCorp: A New Approach to Enterprise Security par Google
• BeyondCorp: Design to Deployment at Google par Google