Charges de travail cloud : prévisions de cybersécurité pour 2024

L’année 2023 a été marquée par des transitions spectaculaires sur le marché de la sécurité du cloud, chaque aspect de l’écosystème (fournisseurs, produits et infrastructure) ayant subi des changements considérables. À l’horizon 2024, la cybersécurité des charges de travail (VM, conteneurs, services) dans le cloud public continuera d’évoluer à mesure que les clients continueront de trouver un équilibre entre l’adoption agressive du cloud et la conformité aux besoins de sécurité de l’entreprise. Dans ce cadre, les DSI et RSSI mettront leurs équipes au défi de créer une plateforme de sécurité qui regroupe les produits ponctuels, prend en charge plusieurs cloud (AWS, Azure et GCP) et assure l’automatisation des opérations de sécurité. En conséquence, nous verrons une architecture Zero Trust ouvrir la voie à la sécurisation des charges de travail cloud, à la protection des données en temps réel et à l’application centralisée des politiques. Voici les 5 principales tendances qui, selon nous, se manifesteront en 2024.

1. Le déplacement latéral des menaces vers les cloud à partir d’environnements sur site va s’intensifier.

Le cloud est l’endroit où se dirigent les ressources les plus précieuses des entreprises, à savoir les applications et les données. Les hackers font appel à des techniques innovantes qui consistent à compromettre le réseau sur site d’une entreprise et à se déplacer latéralement vers son domaine cloud. Ces techniques connaissent une popularité croissante auprès des acteurs malveillants, car des incohérences persistent entre les environnements sur site et les environnements de cloud public.

Une attaque détaillée par l’équipe de recherche Microsoft Security (source : MERCURY et DEV-1084 : Attaque destructrice sur un environnement hybride) illustre cette tendance. Les acteurs malveillants ont d’abord compromis deux comptes privilégiés, puis les ont exploités pour manipuler l’agent Azure Active Directory (Azure AD) Connect. Deux semaines avant le déploiement du ransomware, les hackers ont utilisé un compte hautement privilégié compromis pour accéder à l’appareil sur lequel l’agent Azure AD Connect était installé. Nous avons de bonnes raisons de croire que les hackers ont ensuite utilisé l’outil AADInternals pour extraire les informations d’identification en texte brut d’un compte Azure AD privilégié. Ces informations d’identification ont ensuite été utilisées pour pivoter de l’environnement sur site ciblé vers l’environnement Azure AD ciblé.

Illustration : La compromission sur site pivote vers le cloud public.
 

2. Les services sans serveur vont considérablement élargir la surface d’attaque.

Les fonctions sans serveur apportent une simplicité exceptionnelle, permettant aux développeurs de se concentrer uniquement sur l’écriture et le déploiement du code sans se préoccuper de son infrastructure sous-jacente. L’adoption d’architectures basées sur des microservices continuera à stimuler l’utilisation de fonctions sans serveur en raison de leur caractère réutilisable, ainsi que de leur capacité à accélérer le développement d’applications. Cependant, les fonctions sans serveur s’accompagnent d’un risque de sécurité important, car elles interagissent avec diverses sources d’entrée et d’événements, nécessitant souvent des appels HTTP ou API pour déclencher des actions. Elles utilisent également des ressources cloud telles que les magasins blob ou le stockage en bloc, s’appuient sur des files pour séquencer les interactions avec d’autres fonctions et se connectent aux appareils. Ces points de contact étendent la surface d’attaque, car nombre d’entre eux impliquent des formats de message non fiables et ne disposent pas d’une surveillance ou d’un audit approprié pour la protection standard au niveau de la couche d’application.

Illustration : Les fonctions sans serveur peuvent accéder à la pile complète de services supplémentaires, générant ainsi une large surface d’attaque.
 

3. Les politiques de sécurité basées sur l’identité seront redéfinies dans le cadre de la protection du cloud public.

Alors que les charges de travail commencent à se multiplier dans les cloud publics, chaque fournisseur de services cloud (FSC) apportera ses propres capacités disparates en matière d’identité. Contrairement aux utilisateurs, il n’existe pas d’anneau unique (Active Directory) pour gouverner toutes ces fonctions. Les services informatiques continueront à gérer des profils d’identité déconnectés sur site, dans le cloud privé et dans le cloud public pour les charges de travail. Cela dit, en 2024, les équipes de sécurité continueront à gérer plusieurs attributs de charge de travail pour rédiger leurs politiques de sécurité, et les abstractions de niveau supérieur (comme les balises définies par l’utilisateur) commenceront à être plus largement adoptées en tant que telles. Cela favorisera la cohérence entre la cybersécurité et les autres fonctions de gestion des ressources (facturation, contrôles d’accès, authentification, création de rapports) pour les charges de travail cloud.

Illustration : Des balises définies par l’utilisateur seront utilisées pour déployer une architecture Zero Trust afin de sécuriser les charges de travail dans le cloud
 

4. Les entreprises évalueront et déploieront des plateformes de sécurité fournies dans le cloud qui prennent en charge plusieurs cloud publics.

En pourvoyant du personnel et en créant des architectures spécialisées pour sécuriser chaque cloud public, il incombera aux équipes de sécurité de rechercher les solutions qui leur conviennent le mieux. Les entreprises évalueront les outils des FSC tels que les solutions ponctuelles de pare-feu cloud, mais rechercheront de plus en plus des architectures capables de centraliser la définition, l’application et les mesures correctives de leurs politiques de sécurité cloud. Ce n’est que lorsque la cyberprotection sera assurée à partir d’une plateforme centrale que la cyberdéfense pourra être appliquée à toutes les charges de travail, et pas seulement à quelques unes d’entre elles.

5. La volonté des DSI de protéger leurs investissements dans AWS, Azure et GCP dictera la mise en œuvre d’outils de sécurité qui peuvent s’étendre sur plusieurs cloud.

En ce qui concerne les bonnes pratiques des fournisseurs, les DSI cherchent à diversifier leurs portefeuilles d’infrastructures cloud. Cela leur permet de réduire leur dépendance à l’égard d’un fournisseur unique, d’intégrer l’infrastructure héritée des fusions et acquisitions et d’exploiter les meilleurs services de différents cloud publics, tels que Google Cloud BigQuery pour l’analyse des données, AWS pour les applications mobiles et Oracle Cloud pour l’ERP.

Illustration : Cadre AWS pour la responsabilité partagée de la protection des ressources cloud [SOURCE]

Chaque fournisseur de cloud prône la notion de « responsabilité partagée » en matière de cybersécurité, faisant peser sur le client la responsabilité de mettre en place une infrastructure de sécurité pour ses ressources cloud. Les services informatiques avisés veilleront à choisir une plateforme de cybersécurité capable de prendre en charge plusieurs environnements de cloud public. Les clients ne peuvent pas envisager l’idée d’utiliser des outils de sécurité distincts pour chaque cloud public ; ils se contenteront d’une seule plateforme pour tous leurs besoins.

Le déploiement de charges de travail dans le cloud public n’est pas une nouvelle tendance dans le monde de l’entreprise, mais le sujet de la sécurité des charges de travail dans le cloud devient de plus en plus brûlant. Bien qu’il n’y ait pas encore de réponses claires, il existe quelques indications concernant la direction que prendront les clients en 2024, à savoir l’architecture Zero Trust, car elle offre un avantage immédiat à court terme et un cadre solide pour une sécurité pérenne des charges de travail dans le cloud. Vous souhaitez en savoir plus sur le modèle Zero Trust pour les charges de travail cloud ? Cliquez ici pour obtenir plus de perspectives de Zscaler.

Ce blog fait partie d’une série d’articles qui fournissent des déclarations prospectives sur l’accès et la sécurité en 2024. Le prochain article de cette série aborde les prévisions concernant le Zero Trust. 

Déclarations prospectives ou prévisions

Ce blog contient des déclarations prospectives basées sur les croyances et hypothèses de notre direction et sur les informations dont elle dispose actuellement.Les mots « croire », « potentiellement », « estimer », « continuer », « anticiper », « avoir l’intention », « projeter », « planifier », « s’attendre », les verbes conjugués au futur et au conditionnel, ainsi que d’autres expressions similaires qui expriment l’incertitude des événements ou des résultats futurs sont destinés à identifier les déclarations prospectives. Ces déclarations prospectives comprennent, sans s’y limiter, des éléments concernant : des prévisions sur l’état du secteur de la cybersécurité au cours de l’année civile 2024 et notre capacité à tirer parti de ces opportunités de marché ; les avantages anticipés et l’adoption croissante des modèles « As-a-Service » et de l’architecture Zero Trust pour lutter contre les cybermenaces ; et les croyances sur la capacité de l’IA et de l’apprentissage automatique à réduire les temps de réponse de détection et de correction, ainsi qu’à identifier et à arrêter les cybermenaces de manière proactive. Ces déclarations prospectives sont soumises aux dispositions de la sphère de sécurité créée par le Private Securities Litigation Reform Act de 1995. Elles sont soumises à un certain nombre de risques, d’incertitudes et d’hypothèses, et un nombre important de facteurs pourraient faire en sorte que les résultats réels diffèrent sensiblement des prévisions formulées dans ce blog, y compris, mais sans s’y limiter, les risques et les développements en matière de sécurité inconnus de Zscaler au moment de la rédaction de ce blog et les hypothèses sous-jacentes à nos prévisions concernant le secteur de la cybersécurité au cours de l’année civile 2024.

Les risques et incertitudes spécifiques à l’activité de Zscaler sont exposés dans notre dernier rapport trimestriel sur le formulaire 10-Q déposé auprès de la Securities and Exchange Commission (« SEC ») le 7 décembre 2022, disponible sur notre site Web à l’adresse ir.zscaler.com et sur le site Web de la SEC à l’adresse www.sec.gov. Toutes les déclarations prospectives contenues dans ce communiqué sont basées sur les informations limitées dont dispose actuellement Zscaler à la date du présent communiqué, lesquelles sont susceptibles de changer ; Zscaler ne s’engage pas à mettre à jour les déclarations prospectives contenues dans cet article, même si de nouvelles informations deviennent disponibles à l’avenir, sauf si la loi l’exige.