Architecture de sécurité cloud : la sécurité dès la conception

Les principales plateformes cloud, comme Amazon Web Services (AWS), Google Cloud (GCP) et Microsoft Azure, comptent des milliers de spécialistes de la sécurité qui protègent en permanence leur infrastructure cloud publique. Mais elles ne sont pas seules responsables de la sécurisation des déploiements cloud. Si les fournisseurs cloud ont une part de responsabilité dans la sécurité des données et des charges de travail exécutées sur leurs serveurs, une grande partie des risques liés au cloud incombe aux clients.

Dans le modèle traditionnel de sécurité des données, les organisations contrôlaient entièrement leur infrastructure informatique. La sécurité visait à renforcer le périmètre du réseau, et tous les utilisateurs et systèmes qui s’y trouvaient étaient considérés comme fiables. Cette approche ne fonctionne plus dans le cloud, et ses limites sont encore plus marquées dans les environnements hybrides et multicloud. Ce changement impose une architecture cloud sécurisée dès sa conception.

Dans cet article, nous expliquons ce que recouvre l’architecture de sécurité cloud et en quoi elle concerne les développeurs cloud-native.

Pourquoi l’architecture de sécurité cloud est-elle importante ?

Une architecture de sécurité cloud efficace permet aux organisations de maintenir un bon niveau de sécurité tout en avançant rapidement et en ajoutant de nouvelles fonctionnalités dans le cloud. Compte tenu du rythme rapide des méthodes de développement modernes et de la complexité des environnements cloud, il n’est pas envisageable d’attendre la mise en production des applications pour les sécuriser. En appliquant les bonnes pratiques d’architecture de sécurité cloud, les organisations peuvent développer efficacement des applications cloud-native tout en maintenant un haut niveau de sécurité.

Les défis de l’architecture de sécurité cloud

Une architecture de sécurité bien pensée pour le cloud doit tenir compte des défis suivants :

Menaces internes

Les organisations doivent vérifier les antécédents des employés et des parties prenantes ayant accès aux environnements cloud, les former avant de leur accorder cet accès et en contrôler strictement les permissions. Les environnements cloud peuvent être exposés aux attaques d’employés malveillants ou à la négligence d’employés, qui peut entraîner le vol d’identifiants ou des erreurs de configuration.

Compromission du plan de contrôle

Le plan de contrôle cloud regroupe les API qu’un fournisseur de services cloud comme Amazon, Google ou Microsoft met à la disposition des développeurs pour configurer et contrôler les environnements cloud qu’ils utilisent au quotidien. Lorsqu’un pirate parvient à s’introduire dans un environnement cloud, il cherche avant tout à obtenir les clés API qui lui permettent d’agir sur le plan de contrôle API du fournisseur. Ces clés lui permettent d’explorer l’environnement, de se déplacer latéralement, puis de trouver et d’exfiltrer des données tout en échappant aux outils de sécurité.

Attaques par déni de service

Les attaques par déni de service (DoS) menacent la disponibilité des données et des applications. Un attaquant n’est pas forcément en mesure d’accéder aux données ou de les modifier, mais s’il peut rendre des systèmes ou des données indisponibles pour vous ou vos clients, il peut vous empêcher d’assurer vos activités essentielles.

Les attaques DoS peuvent être temporaires ou permanentes. Les attaques par déni de service distribué (DDoS) temporaires surviennent lorsque des attaquants submergent un système de requêtes. Des règles de conformité réseau peuvent aider à les contrer. Les attaques DoS permanentes endommagent le matériel et rendent les serveurs inutilisables ; des techniciens doivent alors reconstruire physiquement le système à partir de zéro.

Contrôle côté client

Les données et les charges de travail exécutées dans les services cloud posent des défis en matière de visibilité et de contrôle. Les fournisseurs cloud ne détaillent pas toujours la façon d’appliquer des contrôles dans leur cloud ; les contrôles internes des clients ne sont donc pas toujours transposables. Il peut en résulter un ensemble disparate de contrôles pour les appareils, les réseaux et les ressources cloud internes, avec une visibilité réduite et un risque de faille ou de perte de données.

La responsabilité partagée de l’architecture de sécurité cloud

Les fournisseurs cloud modernes appliquent un modèle de responsabilité partagée. Fournisseurs et clients sont responsables des aspects du cloud qui relèvent de leur périmètre. Les fournisseurs cloud sont généralement responsables de la sécurité du backend, à commencer par la sécurité physique du centre de données, tandis que les clients doivent utiliser les services cloud de manière sécurisée, notamment en protégeant les appareils des utilisateurs et en appliquant des contrôles d’accès.

Voyons comment se répartit la responsabilité partagée dans trois des modèles de cloud computing les plus courants :

La plupart des grandes entreprises utilisent désormais plusieurs clouds publics pour tirer parti des avantages propres à chaque fournisseur de services cloud. Elles doivent donc prendre des responsabilités croissantes en matière de surveillance et de sécurisation des applications et des données dans tous leurs clouds.

Quels sont les principaux points à prendre en compte pour l’architecture de sécurité cloud ?

Parmi les principaux aspects d’une architecture de sécurité cloud figurent la sécurité dès la conception, la sécurité des applications cloud-native, le shift left, l’automatisation, la conformité cloud, la visibilité sur le cloud et la gestion multicloud.

Examinons chacun de ces aspects plus en détail :

Sécurité dès la conception

Les exigences de sécurité sont intégrées à l’architecture cloud afin d’éviter qu’elles ne soient contournées par inadvertance à cause de règles mal configurées. Par exemple, la gestion des identités doit être centralisée et des contrôles d’accès basés sur les rôles doivent être appliqués à chaque interaction avec une ressource cloud. Cela peut également contribuer à prévenir la compromission du plan de contrôle.

Sécurité des applications cloud-native

L’agilité et l’évolutivité qu’offre le cloud font partie des avantages du déploiement d’applications dans cet environnement. L’architecture de sécurité cloud doit veiller à ce que les outils et les pratiques de sécurité ne ralentissent pas les mises en production agiles et ne créent pas d’obstacles au déploiement. Sinon, les équipes de développement et d’exploitation pourraient être tentées de sauter ou de négliger certaines étapes de sécurité.

Shift left

Le shift left est une approche moderne de la sécurité des applications. Au lieu d’attendre que les applications soient en production, cette approche intègre les tests de sécurité le plus tôt possible dans le processus de développement. Puisque plus de 50 % des spécialistes DevSecOps déclarent utiliser une forme ou une autre d’infrastructure en tant que code (IaC) pour déployer leurs charges de travail, il est important de tester les applications et l’infrastructure aussi tôt et aussi souvent que possible au cours du développement, plutôt que d’attendre leur mise en production.

Automatisation

Les mises à jour, les contrôles et les configurations de sécurité doivent être automatisés à l’aide de code afin que les développeurs et les équipes de sécurité puissent détecter automatiquement les menaces qui ciblent les applications cloud-native et les données, et y répondre.

Conformité cloud

Les autorités renforcent les lois relatives aux données et aux processus cloud. L’architecture de sécurité cloud doit intégrer les réglementations gouvernementales ainsi que les normes sectorielles ou organisationnelles à l’architecture cloud afin de garantir le respect des obligations.

Visibilité sur le cloud

Les déploiements hybrides et multicloud compliquent la visibilité. Les solutions de sécurité traditionnelles sont souvent incapables de surveiller et de gérer la sécurité de l’infrastructure cloud. Une architecture de sécurité cloud efficace doit donc inclure des méthodes et des technologies permettant d’obtenir une vue d’ensemble des déploiements hybrides ou multicloud.

Gestion multicloud

Les organisations font de plus en plus appel à plusieurs fournisseurs cloud, chacun disposant de ses propres paramètres de configuration et outils de sécurité intégrés. La gestion des déploiements multicloud alourdit la charge de développeurs et d’équipes de sécurité déjà sursollicités. L’architecture de sécurité cloud doit donc contribuer à centraliser la gestion des solutions de sécurité proposées par chaque fournisseur.

Comment Snyk peut contribuer à sécuriser vos environnements cloud

On assimile souvent le cloud à un centre de données, mais, en pratique, il s’agit de logiciels. L’infrastructure d’hier fait désormais partie des applications. Par conséquent, sécuriser les applications cloud implique de transférer certaines responsabilités de l’informatique et des opérations vers la sécurité des applications. La sécurité cloud-native doit commencer par les développeurs, afin qu’ils puissent se concentrer sur la livraison de logiciels qui répondent aux objectifs métier tout en garantissant la sécurité du code. Snyk propose de nombreux outils qui aident les développeurs à sécuriser l’infrastructure et les conteneurs sur lesquels leurs applications s’exécutent.

Shift left et principes DevSecOps

La plateforme de sécurité des applications cloud-native de Snyk intègre la sécurité des applications, des plateformes et de l’infrastructure au pipeline de développement, avec une surveillance continue des nouvelles vulnérabilités. Elle facilite l’adoption des pratiques DevSecOps en éliminant les cycles de révision fastidieux au cours desquels les équipes de sécurité détectent des bugs en production avant de renvoyer les problèmes aux équipes de développement. Lorsque la sécurité est intégrée au processus de développement dès le départ, les équipes de sécurité n’ont plus besoin de demander après coup aux développeurs d’ajouter des fonctionnalités ou des audits : elles savent que ces exigences sont prises en compte dès le premier jour.

Snyk IaC

Snyk IaC élimine les révisions manuelles fastidieuses et sujettes aux erreurs : les développeurs peuvent sécuriser les configurations d’infrastructure au fur et à mesure de leur rédaction et de leur déploiement. La solution inclut des règles de stratégie en tant que code intégrées et permet de créer des règles personnalisées à l’aide d’Open Policy Agent (OPA).

Sécurité des conteneurs

Snyk Container permet aux développeurs de sécuriser la couche des conteneurs pendant le développement et en production. La solution contribue à éliminer les vulnérabilités grâce à des recommandations automatisées d’images de base et à des mises à niveau. Le récent partenariat de Snyk avec Sysdig étend notre capacité à analyser et à corriger les vulnérabilités des conteneurs dans l’environnement d’exécution.