Tribunes

Ce que la panne de Crowdstrike apprend réellement aux DSI

La panne provoquée par Crowdstrike a mis en évidence les erreurs de ce prestataire, mais elle a aussi souligné la fragilité des parcs déployés sur des sites ne disposant pas de techniciens spécialisés. (Photo : Milad Fakurian/Unsplash)

Après la panne de Crowdstrike en juillet, les équipes IT en entreprises reconsidèrent l'impact du cloud sur la fiabilité de leurs applications. A raison ?

PublicitéLe 19 juillet, quelques minutes après que Crowdstrike, le géant de la sécurité des données, a publié ce qui était censé être une mise à jour de sécurité, les entreprises ont commencé à perdre des terminaux Windows. Et nous nous sommes retrouvés avec l'une des pannes informatiques les plus graves et les plus étendues de tous les temps. On a beaucoup parlé du pourquoi et du comment de cet événement. Mais quelles conséquences a-t-il eu sur la manière dont les entreprises anticipent les pannes et sur ce qu'elles pensent devoir faire en pareil cas ? On nous a également dit que les entreprises repensaient leur stratégie cloud suite à la panne Crowdstrike. Est-ce vrai, et, si oui, que prévoient-elles de faire ?

Une chose est claire : les entreprises pensent que le problème vient de Crowdstrike. Seules 21 des entreprises que j'ai contactées pensaient que Microsoft y avait contribué, et aucune ne pensait que cet éditeur était le principal acteur à blâmer.

Les deux erreurs de Crowdstrike

Selon les entreprises, Crowdstrike a commis deux erreurs. Tout d'abord, il n'a pas tenu compte de la sensibilité de son logiciel client Falcon pour les terminaux concernant les données décrivant comment rechercher les problèmes de sécurité. En conséquence, une mise à jour de ces données a fait planter le client en introduisant une condition qui existait auparavant mais qui n'avait pas été correctement testée. Deuxièmement, au lieu de procéder à une diffusion limitée du nouveau fichier de données, qui aurait certainement permis de détecter le problème et d'en limiter l'impact, Crowdstrike l'a diffusé d'emblée à l'ensemble de sa base d'utilisateurs.

Toute logique de programmation est dépendante des données, en ce sens que les chemins logiciel sont déterminés par les données qu'il traite. On ne peut donc pas dire qu'on a testé un programme si l'on n'a pas exploré tous ces chemins. Sur les 89 responsables du développement au sein d'entreprises qui m'ont fait part de leurs commentaires, tous ont déclaré avoir été confrontés à ce problème lors de leurs propres tests, et ils s'attendent à ce qu'un fournisseur de logiciels soit encore plus prudent qu'ils ne le sont eux-mêmes. Ils comprennent néanmoins comment cela peut se produire. L'un d'entre eux a déclaré avoir entendu dire que le bogue logiciel était présent dans le client Falcon depuis plus d'un an et qu'il n'avait tout simplement pas encore été détecté.

Microsoft : fautif ou pas ?

Les choses deviennent un peu plus confuses sur le plantage des systèmes Windows (plus de huit millions d'entre eux) consécutif à la défaillance de Crowdstrike et sur leur résistance à la récupération à distance. Les 21 entreprises qui estiment que Microsoft a contribué au problème pensent toutes que Windows n'aurait pas dû réagir comme il l'a fait à l'erreur de CrowdStrike. Les 37 entreprises qui n'ont pas tenu Microsoft pour responsable ont souligné que les logiciels de sécurité ont nécessairement une capacité unique à interagir avec le logiciel du noyau Windows, ce qui signifie qu'ils peuvent créer un problème majeur en cas d'erreur.

PublicitéMais si les entreprises ne sont pas convaincues que Microsoft a bien contribué au problème, plus des trois quarts d'entre elles pensent que Microsoft pourrait agir pour réduire le risque de rechute. Presque autant d'entreprises ont déclaré qu'elles pensaient que Windows était plus sensible que d'autres OS au type de problème créé par le bogue de Crowdstrike, et ce point de vue était partagé par 80 des 89 responsables du développement interrogés, dont beaucoup ont souligné que MacOS ou Linux ne présentait pas le même niveau de risque et qu'aucun n'avait été touché par le problème.

Evaluer l'impact du cloud sur la fiabilité des applications

Mais qu'est-ce que tout cela signifie en ce qui concerne l'utilisation du cloud ? Les entreprises considéraient traditionnellement son usage comme un moyen d'améliorer la fiabilité de leurs applications. Mais la part de celles qui pensent avoir mal évalué la valeur du cloud dans ce domaine est passée de moins de 15% avant la panne à 35% immédiatement après et à 55% au début du mois d'août. Le facteur le plus important de cette croissance a été la prise de conscience que des défaillances massives des points d'accès pouvaient mettre fin à leurs activités, et qu'aucune sauvegarde dans le cloud ne serait efficace. Les entreprises ont été obligées d'examiner en profondeur l'impact du cloud sur la fiabilité des applications.

Supposons qu'une application hébergée dans un datacenter soit liée à un PC Windows. Supposons encore que chacun d'eux soit susceptible de tomber en panne 1% du temps. Vous souhaitez améliorer la fiabilité en ajoutant un front-end dans le cloud, également associé à un taux de panne de 1% du temps. Quelle est votre fiabilité ? Tout dépend de la capacité du cloud et du datacenter à se sauvegarder mutuellement. S'ils ne le peuvent pas, la probabilité que les trois soient opérationnels en même temps est de 0,99 au cube, soit 97 %, ce qui est inférieur à la disponibilité sans le cloud. Mais si ce dernier et le datacenter peuvent s'appuyer l'un sur l'autre, il faudrait qu'ils tombent tous les deux en panne pour que votre application soit indisponible. Le risque de défaillance du nuage et du centre de données est alors de 1% fois 1%, soit un sur dix mille. La fiabilité de l'application s'en trouve améliorée.

Le multicloud améliore la fiabilité ? Pas toujours

Le même type de calcul doit être pris en compte pour le multicloud. Sur les 110 entreprises qui ont commenté l'impact du multicloud sur la fiabilité, 108 ont déclaré qu'il rendait les applications plus fiables. Est-ce le cas ? Cela dépend. Si deux cloud se soutiennent mutuellement, le risque de défaillance est effectivement plus faible, comme dans mon exemple précédent. Mais de nombreuses entreprises ont admis qu'au moins certaines de leurs applications avaient besoin des deux cloud parce que les composants reposaient sur des fonctions spécifiques à chaque environnement. Dans ce cas, les deux prestataires doivent être opérationnels en même temps, et le multi-cloud réduit en fait la fiabilité de l'application !

Cela prouve que les entreprises se font peut-être des illusions sur le cloud. Il ne va pas toujours améliorer la fiabilité, pas plus qu'il ne va systématiquement réduire les coûts. Rien ne remplace le fait de savoir précisément ce que l'on fait, en particulier dans le domaine de la gestion de la fiabilité. L'instinct n'est pas un bon substitut à un cours sur les probabilités et les statistiques.

La question clef de la fiabilité des accès

Mais revenons à mon calcul de la fiabilité du cloud. Oui, le risque de défaillance du nuage et du datacenter est de un sur dix mille, mais le risque de défaillance du terminal ets, dans cet exemple, est de un sur cent. Le risque lié aux points d'accès est clairement plus important, alors que peuvent faire les entreprises à ce sujet ?

Sur les 138 entreprises qui ont commenté le problème, la suggestion la plus fréquente a été d'apprendre aux personnes clés de chaque site à effectuer un « démarrage sécurisé » de leurs systèmes, car c'est tout ce qui était réellement nécessaire pour résoudre rapidement le problème Crowdstrike. La deuxième recommandation la plus fréquente est d'utiliser une interface de navigateur sur le terminal plutôt qu'une application. En fait, 44 entreprises ont déclaré qu'elles utilisaient un accès par navigateur et qu'elles étaient en mesure de fonctionner normalement lors d'une panne de type Crowdstrike à condition de disposer d'un terminal ne tournant pas sur Windows. Le plus souvent, il s'agissait d'un téléphone ou d'une tablette, mais certaines (13) disposaient de systèmes bureautiques Mac ou Linux qu'elles auraient pu utiliser pendant la panne. En outre, il est possible d'utiliser un certain nombre de terminaux basiques pour faire fonctionner un navigateur, comme un Chromebook, et ce type d'appareils est moins susceptibles d'être la proie de problèmes tels que celui rencontré par Crowdstrike, ou même d'avoir besoin d'outils de sécurité spécialisés pour les terminaux.

Simplifier les terminaux

Devriez-vous donc « repenser votre stratégie cloud » ? En fait, ce qu'il faut peut-être, c'est repenser la stratégie relative aux terminaux. La recommandation portant sur l'accès via un navigateur pourrait signifier que renforcer l'usage du cloud réduirait les risques. Car le vrai problème ici est que les dispositifs sophistiqués, qui servent de portes d'entrée aux applications, sont plus difficiles à réparer à distance, et que le personnel local n'a pas les compétences nécessaires pour effectuer ce travail lui-même. La simplification des terminaux peut conduire à une multiplicité d'options de terminaux disponibles, comme cela a été le cas pour de nombreuses entreprises, ce qui raménerait le type de défaillance créé par Crowdstrike à un désagrément marqué. Ne paniquez pas ; bien utilisé, le cloud reste votre ami.

Article rédigé par

Tom Nolle, fondateur d'Andover Intel

Tom Nolle est le fondateur et l'analyste principal d'Andover Intel, une société de conseil et d'analyse qui examine les technologies et les applications en constante évolution du point de vue de l'aquéreur et de ses besoins. Tom est programmeur, architecte logiciel et a dirigé l’évolution de logiciels et produits de réseau reconnus. Il fournit des services de conseil et d'analyse technologique depuis des dizaines d'années. Il écrit régulièrement des articles sur les réseaux, le développement de logiciels et le cloud, ainsi que sur les technologies émergentes telles que l'IoT, l'IA et le métavers.