Pour gérer vos consentements :

Le refactoring applicatif Kubernetes, un risque de sécurité à ne pas négliger

Le développement vertigineux des données et leur stockage favorise en miroir les vulnérabilités et les risques d’intégrité. Une récente étude d’IDC a révélé qu’en 2022, sur près de 80% des entreprises ayant activé une stratégie de reprise après sinistre, 83% ont expérimenté une corruption de leurs données et, le plus inquiétant, près des deux tiers perdu leurs données de manière irrécupérable après avoir subi une attaque ransomware.

Si aucune application ne peut aujourd’hui se prévaloir d’être totalement « ransomware proof », les organisations qui refactorisent leurs applications pour Kubernetes risquent d’être confrontées à de réels enjeux de sécurité et de performances.

La stratégie de refactorisation va permettre aux entreprises de décomposer les charges de travail monolithiques en micro services basés sur des conteneurs pour obtenir un environnement cloud évolutif et agile, hautement extensible selon les besoins et capable de prendre en charge différents cas d’usage.

Si Kubernetes, puissant outil de gestion et d’orchestration des workloads conteneurisés a révolutionné le développement applicatif haute performance, les enjeux de protection et de sécurité des données lors du processus sont de taille.

Aujourd’hui, selon IDC, la plupart des applications conteneurisées sont refactorisées à partir de code legacy et, par conséquent, sont déjà opérationnelles sur des serveurs bare metal ou des machines virtuelles. Le processus de refactoring est par ailleurs complexe en lui-même – il impose notamment de modifier des composants existants dans l’application pour supporter la conteneurisation.

Autre exemple d’impact potentiel sur la sécurité : les Pods, ces composants indispensables aux déploiements Kubernetes et qui ont pour rôle d’héberger les conteneurs pour chaque processus applicatif.

Chaque Pod possède une adresse IP et peut ainsi directement communiquer avec un autre Pod. Les adresses IP sont constamment modifiées et attribuées dynamiquement aux Pods au sein d’un cluster et la méthode la plus courante consiste à utiliser des groupes de Pods appelés Services, accessibles via un nom de DNS ou une adresse IP unique.

Comme la plupart des applications Kubernetes s’appuient sur les services pour communiquer, l’accès au Pod peut être exposé voire provoquer des problèmes de réseau dans le cluster en raison des redémarrages fréquents. De véritables portes d’entrée pour les hackers !

Autre source de préoccupation : les risques liés aux attaques ciblant la supply chain. Si les applications conteneurisées sont conçues pour l’automatisation, certains déploiements Kubernetes peuvent extraire le dernier Pod d’une application – lors de la mise à jour du code par exemple – sans vérifier les vulnérabilités potentielles, augmentant ainsi les risques de sécurité.

L’ensemble de ces enjeux est exacerbé par la pénurie actuelle de compétences et de connaissances au sein des équipes travaillant à la conception d’applications de production basées sur conteneurs. Il est évident que le déploiement d’une application sans protection des données associée à une politique de sécurité intégrée tout au long des workflows de développement, augmentera sa vulnérabilité aux attaques de ransomware.

Pour atténuer les risques et l’impact que peuvent avoir ces attaques sur les infrastructures de conteneurs, les entreprises doivent d’abord dresser un inventaire des applications à refactoriser et réfléchir à la façon dont les données doivent être intégrées. Sur cette base, des politiques de sécurité et de récupération de données pourront ensuite être envisagées à un stade précoce du processus global.

Les responsables de la refactorisation devront s’appuyer soit sur des fonctionnalités natives soit sur une solution de protection des données intégrée. De cette façon, les applications conteneurisées pourront être protégées plus efficacement contre les ransomwares, les malwares et autres risques de sécurité susceptibles de perturber leur capacité à se restaurer.

En permettant le déplacement d’applications et de services vers Kubernetes, le refactoring présente ainsi des risques de sécurité importants : la nature dynamique de cet environnement peut potentiellement créer des failles liées aux données et à l’accès aux services. De plus, le déploiement de conteneurs non sécurisés représente également un facteur de risques.

Pour se protéger de manière holistique, les organisations doivent porter une attention particulière aux solutions de protection des données. En s’appuyant sur une solution native, elles poseront la protection des données en élément fondamental de leur stratégie basée sur conteneurs et fourniront à la fois les plus hauts niveaux de protection et de résilience, tout en bénéficiant des performances et de l’agilité inhérentes à cette technologie innovante

Recent Posts

Mise en conformité avec NIS2 : RSSI et DPO, deux postes complémentaires

Dans de trop nombreuses entreprises, les rôles de RSSI et de DPO sont souvent attribués…

3 semaines ago

Checklist pour répondre aux ransomwares : un guide pour les RSSI

Les attaques continuent d'évoluer et les défenses, en plus de protéger, doivent réévaluer en permanence…

3 semaines ago

NIS 2 : en chemin vers la conformité et une cyber résilience renforcée

Alors que la directive doit être traduite dans la législation française avant le 17 octobre…

4 semaines ago

L’IA, un maillon essentiel pour sécuriser la chaîne d’approvisionnement logicielle et des données

2024 s’impose comme l’année du changement où les équipes DevSecOps utilisent de plus en plus…

4 semaines ago

Le Negative Trust ou l’évolution du concept de Zero Trust

Le concept de Negative Trust ne vise pas à se méfier de ses propres collaborateurs,…

1 mois ago

La souveraineté des données est loin d’être une chimère

Le respect des réglementations en matière de souveraineté des données exige une gouvernance, une conformité…

1 mois ago