Groupe de réflexion sur la sécurité : dans le cloud, les approches anti-humaines nous mettent sur la voie de l’échec

Ce qui m’a le plus surpris en 2021, c’est que nous continuons à construire de nouvelles approches de sécurité avec les mêmes modèles anti-humains que nous avons vus auparavant, nous préparant aux mêmes types d’échecs que nous essayons d’éradiquer depuis des années. Il n’est pas surprenant que Gartner prédise que 99 % des violations du cloud impliqueront des erreurs de configuration qui sont la faute de l’organisation.

Nos activités fonctionnent toutes sur une infrastructure complexe, et elle a évolué rapidement – presque toutes les organisations sont désormais hybrides, mélangeant différentes saveurs de cloud, sur site et de nouvelles superpositions comme Kubernetes. Chacune de ces évolutions est annoncée comme la façon moderne et sans erreur de faire les choses, car tout sera défini par logiciel – dites simplement ce que vous voulez, et l’automatisation s’occupera du reste.

Le problème est que, comme tous les autres types de logiciels, les langages de contrôle sont obscurs – ils souffrent tous de la même contradiction que vous ne pouvez pas avoir quelque chose qui est à la fois puissant et à l’épreuve des erreurs. Les utilisateurs exigent toujours plus de fonctionnalités pour des cas plus particuliers, la complexité augmente et les ouvertures d’erreurs reviennent. Oui, les langages définis par logiciel bien conçus éliminent certains anciens problèmes, mais finissent par les remplacer par de nouveaux.

Personne dans les réseaux cloud n’a à s’inquiéter qu’une passerelle Internet ait un mot de passe par défaut défini en usine, car il n’y a plus une telle chose, et c’est génial. Mais avant de construire sur les clouds, personne ne faisait l’erreur d’un compartiment Amazon S3 lisible dans le monde entier et exposé à Internet avec des données critiques – ce qui n’était pas possible jusqu’à ce que nous adoptions les nouvelles techniques.

L’exemple le plus net qui m’a permis de le faire en 2021 a été d’examiner de près les contrôles de sécurité intégrés à Kubernetes. Kubernetes est devenu vraiment enraciné en 2021 en tant que moyen actuel de créer des applications et une infrastructure cloud, et certainement, il est livré avec beaucoup de puissance – je préfère l’utiliser dans mes propres offres SaaS. Et, bien sûr, Kubernetes vous permet de configurer la microsegmentation – l’équivalent réseau de la distanciation sociale que nous avons tous dû utiliser dans meatspace en 2021.

Mais si vous avez de bons instincts de sécurité, vous savez vous demander « qu’est-ce qui pourrait mal tourner? » lorsque vous voyez de nouvelles façons de faire les choses. Je vous recommande de jeter un coup d’œil à la façon dont vous différenciez une stratégie de permis par défaut de tout d’un refus par défaut dans Kubernetes – peut-être la chose la plus élémentaire que vous pourriez vouloir faire dans n’importe quel langage de stratégie d’accès réseau.

La langue fonctionne-t-elle?  Oui, je l’utilise, et c’est agréable et puissant. Mais c’est aussi anti-humain, en ce sens qu’il est beaucoup trop difficile pour un humain de lire et d’analyser avec précision – la différence entre les opposés extrêmes de « tout ce qui est permis » et « tout bloqué » est une paire d’accolades bouclées vides. (Il ne s’agit même pas seulement des instructions par défaut – le langage « et » par rapport à « ou » se résume à une différence d’un seul trait d’union dans les fichiers YAML obscurs.)

Maintenant, imaginez essayer de lire une grande pile de documents de politique, plisser les écaux pour repérer les accolades et les traits d’union, et comprendre à quoi ils s’additionnent tous. Un grand pouvoir s’accompagne d’une grande responsabilité pour les erreurs.

On pourrait penser que nous aurions maintenant appris que les humains sont vraiment mauvais pour lire et comprendre des règles de configuration complexes. Peu importe à quel point nous nous dépalons vers la gauche, nous continuons d’exiger des chaînes d’outils informatiques puissantes et flexibles, ce qui est intrinsèquement sujet aux erreurs, dans la mesure où les failles de sécurité auto-infligées sont le problème de sécurité dominant.

Ce n’est pas comme si nous ne savions pas comment sécuriser les actifs individuels – de bons guides de durcissement sont faciles à trouver. Le problème, c’est que nous ne savons pas encore comment fabriquer des systèmes fiables… ce qui me fait penser à la vieille blague selon laquelle si les développeurs de logiciels construisaient le monde réel, le premier pic détruirait la civilisation occidentale.