Quand ça retombe en marche

En effet, son service de transport avait 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 modifier leur mot de passe a surchargé son gestionnaire de mots de passe et l’a mis hors ligne, de même que ses trois services de secours. Google déclare en effet dans un ouvrage de plus de 500 pages l’anecdote suivante : « 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 wi-fi 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. » Bon, jusque-là, du classique de chez classique, on a tous connu cela à la maison.

C’est après qu’arrivent les complications : l’ingénieur d’astreinte ne savait pas comment résoudre le problème – le système en question était un développement maison datant de plusieurs années, qui n’avait pas été conçu pour une telle charge et qui n’était jamais tombé en panne. Bref, il a fait ce que j’aurais fait à sa place : reboot général de tout le système. Et ce n’était pas la solution : le redémarrage nécessitait en effet une carte à puce spéciale.

Google écrit alors : « 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. »

Là, en général, quand la situation commence à partir en cacahuète de cette façon, ce n’est pas bon signe, mais alors pas du tout. En effet, même après que l’ingénieur californien a inséré la carte dans un lecteur, le service n’a pas redémarré et affiché 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 utilisé une perceuse électrique pour ce faire. Une heure plus tard, le coffre-fort était ouvert – mais les cartes récupérées à l’intérieur 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 », conclut Google.

Ce genre de mésaventure nous est bien entendu arrivé à tous, à différents degrés. Ce qu’il faut en retenir, c’est que sécuriser un système en mettant des mots de passe dans tous les coins, c’est super, sauf le jour où cela tombe en panne : plus on aura sécurisé le bazar, plus la relance sera compliquée.

En toute modestie, j’invite d’ailleurs tous les consultants qui pensent que la SSI dans le monde hospitalier est une vraie passoire (ce qui n’est d’ailleurs pas totalement faux) à se demander quelles auraient été les conséquences si, en plus du Covid, on avait eu à gérer des anecdotes du même acabit. La différence entre Google et un hôpital, c’est que quand les bus du campus de Google tombent en panne, il n’y a pas de morts. Dans un hôpital si.

OK, il y a des marges de progression dans un hôpital, mais il ne faut jamais oublier que sécuriser un SI, c’est faire des choix. Bienvenue dans la vraie vie.

On pourra trouver ce retour d’expérience et d’autres dans https://static.googleusercontent.com/media/landing.google.com/en//sre/static/pdf/SRS.pdf.