Google : comment la réinitialisation de mot de passe Wi-Fi a paralysé l’un de nos systèmes

Si votre travail consiste à protéger l’infrastructure informatique, il pourrait bien valoir la peine de lire le nouveau livre gratuit de 500 pages de Google qui détaille les nombreuses défaillances affectant les systèmes internes de Google et des produits comme YouTube.

Il est important de noter que ce nouveau livre révèle également comment ses équipes d’ingénierie et de sécurité des sites coopèrent pour protéger les systèmes clés de Google, d’Android à Chrome, en passant par Gmail, Search et Google Cloud.

Une vue maison sur le SRE (Site Reliability Engineering)

Peu d’entreprises dans le monde opèrent à l’échelle de Google, mais il y a néanmoins des leçons à tirer de ce document, qui est publié alors que la pandémie de Coronavirus COVID-19 rend plus important que jamais la fiabilité des systèmes en ligne.

Le livre présente les points de vue d’équipes qui pratiquent ce qu’on appelle l’ingénierie de la fiabilité des sites (SRE – Site Reliability Engineering), l’approche de Google pour coordonner les ingénieurs en logiciels qui développent ses produits et ses systèmes, et les équipes opérationnelles qui assurent le fonctionnement du produit.

Google, qui utilise les principes de l’ESR depuis près de deux décennies, le définit comme “ce que vous obtenez lorsque vous traitez les opérations comme s’il s’agissait d’un problème de logiciel”.

Le lien sécurité entre les développeurs et les équipes opérationnelles

Le texte, intitulé ‘Building Secure and Reliable Systems‘, se concentre sur la façon dont Google apporte une approche SRE à la sécurité, et le rôle de la sécurité dans le développement et les opérations de produits logiciels. Les précédents ouvrages de Google sur le SRE couvraient les meilleures pratiques en la matière, mais ne traitaient pas des liens entre fiabilité et sécurité.

“Pour de bonnes raisons, les équipes de sécurité des entreprises ont largement mis l’accent sur la confidentialité. Cependant, les entreprises reconnaissent souvent que l’intégrité et la disponibilité des données sont tout aussi importantes, et abordent ces domaines avec des équipes différentes”, explique Royal Hansen, l’un des premiers responsables SRE pour Gmail et l’actuel vice-président de l’ingénierie de la sécurité de Google.

“La fonction SRE est une approche de la fiabilité qui est la meilleure de sa catégorie. Toutefois, elle joue également un rôle dans la détection en temps réel des problèmes techniques et la réponse à ceux-ci – y compris les attaques liées à la sécurité sur les accès ou les données sensibles. En fin de compte, si les équipes d’ingénieurs sont souvent séparées sur le plan organisationnel en fonction de compétences spécialisées, elles ont un objectif commun : assurer la qualité et la sécurité du système ou de l’application”.

Un système peut-il être fiable s’il n’est pas fondamentalement sûr ? Ou peut-il être sûr s’il n’est pas fiable ?

Le livre s’ouvre sur les questions suivantes : un système peut-il être considéré comme vraiment fiable s’il n’est pas fondamentalement sûr ? Ou peut-il être considéré comme sûr s’il n’est pas fiable ?

La première histoire mentionnée par Google est celle d’un échec en cascade en 2012, après que son service de transport ait annoncé que le mot de passe Wi-Fi de ses bus reliant ses campus de la baie de San Francisco avait changé. Le flot d’employés essayant de changer leur mot de passe a surchargé son gestionnaire de mots de passe et l’a mis hors ligne, ainsi que ses trois services de secours.

Google avait besoin d’une carte à puce pour redémarrer le système et en disposait dans plusieurs bureaux à travers le monde, mais ne pouvait pas y accéder aux États-Unis. L’entreprise a donc fait appel à des ingénieurs en Australie pour en trouver une là-bas. Il s’est avéré qu’elle était enfermée dans un coffre-fort avec un code que l’ingénieur avait oublié.

Google et le mystère de la carte à puce

Et où le code avait-il été sauvegardé ? Bien sûr, dans le gestionnaire de mots de passe qui était désormais inaccessible. Mais il y a eu encore plus de problèmes lorsque les ingénieurs ont tenté de redémarrer le gestionnaire de mots de passe.

“Ce jour-là, en septembre, l’équipe des transports de l’entreprise a envoyé un courriel à des milliers d’employés pour leur annoncer que le mot de passe du WiFi avait changé. Le pic de trafic qui en a résulté était bien plus important que ce que le système de gestion des mots de passe – qui avait été développé des années auparavant pour un petit groupe d’administrateurs système – pouvait gérer”.

“La charge a fait que la réplique primaire du gestionnaire de mots de passe ne répondait plus, de sorte que l’équilibreur de charge a détourné le trafic vers la réplique secondaire, qui a rapidement échoué de la même manière. À ce stade, le système a bipé l’ingénieur de garde. L’ingénieur n’avait aucune expérience en matière de réponse aux pannes du service : le gestionnaire de mots de passe était supporté au mieux de ses capacités et n’avait jamais subi de panne au cours de ses cinq années d’existence. L’ingénieur a tenté de redémarrer le service, mais ne savait pas qu’un redémarrage nécessitait une carte à puce”.

De l’avantage d’insérer correctement une carte dans un lecteur

“Ces cartes à puce étaient stockées dans plusieurs coffres-forts dans différents bureaux de Google à travers le monde, mais pas à New York, où se trouvait l’ingénieur de garde. Lorsque le service n’a pas pu redémarrer, l’ingénieur a contacté un collègue en Australie pour récupérer une carte à puce. À son grand désarroi, l’ingénieur australien n’a pas pu ouvrir le coffre-fort car la combinaison était stockée dans le gestionnaire de mots de passe désormais hors ligne. Heureusement, un autre collègue en Californie avait mémorisé la combinaison dans le coffre-fort sur place et a pu récupérer une carte à puce”.

“Cependant, même après que l’ingénieur californien ait inséré la carte dans un lecteur, le service n’a pas redémarré et affichait l’erreur incompréhensible suivante : “Le mot de passe ne peut charger aucune des cartes protégeant cette clé”.

Les ingénieurs australiens ont alors décidé qu’une approche de force brute était justifiée pour résoudre leur problème de sécurité et ont utilisé une perceuse électrique pour cela. Une heure plus tard, le coffre-fort était ouvert – mais les cartes récupérées dedans ont déclenché le même message d’erreur.

“Il a fallu une heure supplémentaire pour que l’équipe se rende compte que la carte n’avait pas été insérée correctement. Lorsque les ingénieurs ont retourné la carte, le service a redémarré et la panne a pris fin”.