15 ans de Zero Trust chez Google, de l’opération Aurora à BeyondProd
En janvier 2010, Google rendait publique une cyberattaque d’ampleur, l’opération Aurora. Derrière cette attaque, des hackers chinois ciblant non seulement le groupe américain, mais également d’autres entreprises technologiques, des ONG et des journalistes. « Les hackers ont réussi à compromettre une partie de notre infrastructure. À l’époque, nous pensions avoir toutes les bonnes pratiques en place. Nous étions conformes aux référentiels de sécurité les plus reconnus », explique Thiebaut Meyer, directeur Cybersécurité au sein de l’Office of the CISO chez Google Cloud. Cette attaque a mis en évidence les limites de l’approche traditionnelle de la cybersécurité, centrée sur le périmètre. Elle a marqué le début d’une refonte radicale de la stratégie de sécurité de Google, fondée sur un principe : le Zero Trust.
« Never trust, always verify »
Dès 2010, Google décide d’abandonner toute présomption de confiance au sein de son infrastructure. « Zero Trust n’est pas un produit, ce n’est pas une fonction, ce n’est pas un objectif. C’est un état d’esprit, un processus, un programme », rappelle Thiebaut Meyer. Le mot d’ordre est clair : aucune entité ne doit être considérée comme fiable par défaut. Que ce soit un utilisateur, un appareil, un service ou un microservice, chaque tentative d’accès doit être vérifiée de manière systématique et contextuelle.
La stratégie repose sur trois piliers : la réduction des privilèges, la détection précoce des compromissions, et la continuité des vérifications. « On suppose désormais qu’il y aura, tôt ou tard, une compromission. Notre enjeu est alors de localiser, d’isoler, et de contenir l’attaque, tout en maintenant les activités critiques. »
Du Titan chip au pipeline de déploiement
La mise en œuvre de cette philosophie se traduit par une sécurisation profonde de l’ensemble de l’infrastructure. Google conçoit ses propres serveurs et y intègre sa puce cryptographique maison, Titan. « Chaque étape du démarrage est signée, vérifiée, et validée. Si une machine ne peut pas prouver son intégrité, elle n’est pas autorisée à communiquer sur le réseau. »
Au niveau logiciel, Google a développé le framework SALSA pour encadrer les chaînes de développement : validation du code source, contrôles du pipeline de build, et vérification des artefacts déployés. « Pas une seule image ne passe en production sans avoir reçu toutes les signatures nécessaires. »
BeyondCorp et BeyondProd : fin du VPN, début de la confiance contextuelle
En parallèle, Google a progressivement supprimé l’usage des VPN. « L’une des premières surprises quand on arrive chez Google, c’est qu’il n’y a plus de VPN », souligne Thiebaut Meyer. C’est le projet BeyondCorp, lancé officiellement en 2014, qui permet aux employés d’accéder aux ressources internes depuis n’importe où, sur la base d’une authentification forte et de signaux multiples : identité de l’utilisateur, intégrité de l’appareil, localisation, comportement, etc.
Côté production, le projet BeyondProd, publié en 2019, applique les mêmes principes à l’ensemble des services et microservices. Chaque composant doit prouver son identité avant d’interagir avec un autre. Le protocole ALTH, version maison de mTLS, en garantit l’exécution. « Chaque microservice n’est autorisé à communiquer qu’après vérification de son identité et de ses droits. »
Un modèle transposable à l’IA
En conclusion, Google applique désormais ces mêmes exigences à ses modèles d’intelligence artificielle. « Nous voulons garantir la sécurité du modèle dès sa création, pendant l’entraînement, lors des mises à jour, jusqu’à son déploiement », explique un intervenant. À chaque étape du cycle de vie, les vérifications s’appliquent, comme pour un logiciel traditionnel.
Pour Google, Zero Trust n’est pas un privilège de multinationale. « Tout le monde peut commencer par petites touches. Il n’y a pas besoin d’un big bang. Mais il faut de l’automatisation, et surtout, de la rigueur. »
« Zero Trust est une philosophie, pas une fonctionnalité. »
📄 Fiche opérationnelle : Déployer le Zero Trust par étapes
| Étape | Objectif | Outils recommandés |
|---|---|---|
| 1. Cartographie de l’existant | Identifier les zones à risque, les accès implicites | CMDB, Active Directory, scanners de vulnérabilités |
| 2. Authentification forte | Sécuriser l’identité des utilisateurs | MFA, FIDO2 (Yubikey, Titan), SSO (Okta, Azure AD) |
| 3. Moindre privilège | Limiter les accès au strict nécessaire | RBAC, ABAC, audits d’accès |
| 4. Accès sans VPN | Accès contextuel aux ressources internes | Identity-Aware Proxy, Zscaler ZPA, Cloudflare Access |
| 5. Sécurisation des services | Vérification d’identité des microservices | mTLS, service mesh (Istio, Linkerd), certificats |
| 6. Intégrité du code | Garantir la chaîne de confiance logicielle | CI/CD sécurisé, SALSA, SBOM, Binary Authorization |
| 7. Détection et réponse | Identifier rapidement les compromissions | SIEM, SOAR, EDR, analyse comportementale |
📆 Déploiement recommandé : incrémental, par priorités fonctionnelles et risques identifiés.
🔊 Mantra à retenir : « Ne jamais faire confiance, toujours vérifier. »
- MecAgent lève 2,75 millions d’euros pour automatiser la conception mécanique grâce à l’IA - 16/05/2025
- Plakar veut rebattre les cartes de la sauvegarde de données avec une approche open source, et lève 2,8 millions d’euros - 16/05/2025
- 15 ans de Zero Trust chez Google, de l’opération Aurora à BeyondProd - 16/05/2025
