Le rapport révèle un accès sans restriction aux tableaux de bord Kubernetes, ainsi que des identifiants en clair permettant d’accéder à d’autres infrastructures critiques dans des environnements de cloud public.
La plupart des gens ferment leur porte à clé — du moins lorsqu’ils ne sont pas chez eux. Après tout, personne n’a envie de rentrer et de trouver quelqu’un affalé sur son canapé, en train de regarder Netflix et de dérégler complètement les algorithmes qui déterminent ce qui apparaît dans la « liste des recommandations » en visionnant un genre que vous ne regarderiez jamais. Imaginez l’horreur.
Vous serez donc peut-être surpris d’apprendre que, d’après les statistiques de la criminalité, environ 30 % des cambrioleurs passent par une fenêtre ou une porte ouverte ou non verrouillée.
Du côté de la technologie, on retrouve des « portes et fenêtres ouvertes » similaires dans un récent rapport de l’équipe RedLock CSI. RedLock est une plateforme cloud de surveillance de la sécurité des infrastructures, compatible avec les API, qui offre une visibilité sur votre environnement cloud. C’est en quelque sorte l’équivalent d’ADT pour le cloud. Son récent rapport repose sur l’analyse des environnements de ses clients. Plus d’un million de ressources traitant 12 pétaoctets de trafic réseau ont été évaluées. L’équipe a relevé un certain nombre de pratiques à proscrire en matière de sécurité, mais l’une d’elles a particulièrement retenu mon attention :
“285 tableaux de bord Kubernetes (interfaces d’administration web) déployés sur Amazon Web Services (AWS), Microsoft Azure et Google Cloud Platform n’étaient pas protégés par un mot de passe. Après une enquête plus approfondie, l’équipe a découvert, au sein des systèmes Kubernetes, des identifiants en clair permettant d’accéder à d’autres infrastructures critiques. [c’est moi qui souligne] ”
La découverte d’identifiants en clair n’est malheureusement pas surprenante. Vous vous souvenez peut-être que ce problème avait été soulevé début 2016, lorsque nous avions abordé « La nouvelle menace interne : les frameworks d’automatisation ». Malheureusement, si vous laissez la porte d’entrée ouverte, l’utilisation d’identifiants en clair pour autoriser des activités dans différents environnements de conteneurs pourrait constituer une menace externe tout aussi importante qu’une menace interne.
On pourrait avancer que ces tableaux de bord accessibles à tous n’étaient peut-être pas critiques et qu’ils n’étaient probablement même pas utilisés en production. Il ne s’agissait que d’environnements de test ou de développement, n’est-ce pas ? C’étaient des preuves de concept visant à conteneuriser ultérieurement des applications, qui ont simplement été oubliées ou qui n’étaient pas considérées comme une menace. Sauf que nous savons que ce type d’environnements cloud non gouvernés contribue à la prolifération des ressources cloud, laquelle grignote les budgets et engendre d’autres risques, sans même parler de l’accès sans entrave à un système auquel il suffit d’un clic pour demander de créer d’innombrables systèmes.
Le même rapport a révélé que « 14 % des comptes utilisateurs sont inactifs : leurs identifiants sont toujours valides, mais aucune connexion n’a été enregistrée au cours des 90 derniers jours », ce qui semble clairement confirmer qu’un grand nombre de ressources dans le cloud sont laissées sans gestion — et que leur activité n’est probablement pas surveillée.
Laisser ne serait-ce qu’une porte ou une fenêtre déverrouillée augmente les risques. En matière de sécurité physique, les personnes malveillantes doivent généralement tester votre porte sur place pour savoir si elle est verrouillée. Cela demande du temps et des efforts. Dans le monde numérique, cette contrainte n’existe plus. Je peux analyser vos systèmes à l’aide d’un script et recevoir, en quelques secondes, un message détaillant tous les systèmes détectés qui sont en fonctionnement et accessibles. Les obstacles à surmonter pour commettre un cambriolage numérique sont moindres, ce qui rend encore plus dangereux le fait de laisser ne serait-ce qu’une seule porte ouverte.
La migration lente mais régulière vers des environnements cloud a eu un impact sur de nombreux aspects de l’informatique. L’un de ceux que nous évoquons rarement est l’administration. Pourtant, nous devrions en parler, d’autant plus qu’aujourd’hui, la plupart de ces environnements sont administrés au moyen d’une interface web et offrent un accès facile via le port 80 à quiconque le recherche. Cela signifie que la sécurité des consoles d’administration et des tableaux de bord doit être considérée comme une priorité. Ces systèmes reposent sur des composants web standard, dont beaucoup sont vulnérables aux mêmes failles de sécurité que leurs équivalents destinés aux utilisateurs. Qu’il s’agisse de scripts intersites, d’injections SQL, de mots de passe par défaut ou d’accès dérobés, nous devons (et il s’agit bien d’un « DOIT » au sens des RFC) consacrer du temps et un budget aux tests et à la sécurisation de la partie administrative des systèmes et des environnements que nous utilisons pour déployer nos applications.
Il ne s’agit pas ici d’un « nouveau » paradigme de sécurité, mais de la sécurité de base des applications web. Cela fait maintenant près de vingt ans que nous sécurisons l’accès aux applications web. C’est un domaine bien maîtrisé que nous ne devrions pas négliger avec désinvolture sous prétexte qu’il ne s’agit que d’un environnement de développement ou de test.
Il suffit d’une seule porte ouverte pour qu’un cambrioleur – numérique ou non – puisse accéder à toute votre maison. Et lorsqu’il s’agit d’un cambriolage numérique, les conséquences se propagent plus loin et plus rapidement grâce à la technologie et à la facilité avec laquelle nous pouvons analyser, infiltrer et accéder aux systèmes connectés.
Soyez prudents. Ne négligez pas la sécurité de vos consoles et systèmes d’administration.
À propos de l’auteur
Lori MacVittie est ingénieure émérite et évangéliste en chef au sein du bureau du directeur technique de F5. Elle possède une expertise approfondie dans la fourniture d’applications, les stratégies d’automatisation et les infrastructures. Elle est réputée pour sa capacité à rendre la complexité intelligible, qu’elle définisse des garde-fous pour les agents d’IA, analyse des architectures multicloud fragiles ou explore les limites des systèmes évolutifs. Elle cumule plus de trente ans d’expérience dans le secteur, couvrant le développement d’applications, l’architecture informatique ainsi que l’exploitation des réseaux et des systèmes. Avant de rejoindre F5, elle a été rédactrice spécialisée dans les technologies et a reçu plusieurs distinctions. MacVittie est titulaire d’un master en informatique et est une autrice prolifique dont les publications couvrent la sécurité, le cloud et l’architecture d’entreprise. Elle est également une passionnée de jeux de société et de jeux vidéo, et assume pleinement ses avis bien tranchés sur le fromage.
Autres articles de Lori Mac VittieArticles de blog associés
F5 NGINXaaS pour Google Cloud : des applications résilientes et évolutives
Découvrez comment NGINXaaS s’intègre à Google Cloud pour renforcer les performances et la sécurité, et préparer vos applications critiques à un avenir propulsé par l’IA.
L’intégration de F5 Web Application Firewall (WAF) à AWS est disponible dès aujourd’hui
En faisant appel à un partenaire de déploiement AWS WAF tel que F5, vous pouvez renforcer la sécurité de vos applications web grâce à des règles personnalisées qui bloquent les schémas d’attaque courants, comme les injections SQL ou les attaques par scripts intersites (XSS).
Appliquer le principe de Peter Parker à l’inspection TLS
« Un grand pouvoir implique de grandes responsabilités. » Si l’on en trouve des échos chez Voltaire et Churchill, cette citation est surtout connue grâce aux bandes dessinées Spider-Man, où elle est attribuée à l’oncle Ben. Bien entendu, si cette phrase est si répandue dans la culture populaire, c’est notamment parce qu’elle peut s’appliquer à une multitude de situations et de sujets, y compris à l’inspection TLS.
Le NetOps a besoin de défenseurs, pas d’adversaires
Il est important de reconnaître que les équipes NetOps ne sont pas toujours celles qui font obstacle au déploiement de la dernière nouveauté, application ou service. Les freins à la rapidité sont souvent dus au fait que les organisations n’adoptent pas tous les principes du DevOps lorsqu’elles cherchent à transformer leurs opérations informatiques.
Mise à jour des services applicatifs : sécurité, rapidité et visiteurs suspects
Il est de nouveau temps de nous pencher sur les services applicatifs que les entreprises utilisent réellement pour rendre leurs applications plus rapides et plus sûres. On constate notamment une hausse du recours aux services de protection contre les bots, ainsi que la progression lente mais régulière de HTTP/2. Bien qu’il ne s’agisse pas d’une application…
Les templates prennent le contrôle du cloud
Les modèles s’imposent dans le cloud. Lisez le blog de F5 pour découvrir comment l’infrastructure en tant que code et les API déclaratives automatisent la mise à disposition des applications.