7 façons d’éviter une attaque de mauvaise configuration du cloud

Les équipes d’ingénierie et de sécurité cloud doivent poser des questions importantes sur la sécurité de leurs environnements cloud, et elles doivent aller bien au-delà de la réussite ou non des audits de conformité.

Dans les minutes qui suivent Si vous incluez un nouveau point de terminaison sur Internet, un ennemi potentiel l’a scanné et a examiné son exploitabilité. Une seule mauvaise configuration du cloud peut mettre une cible sur le dos de votre organisation et mettre vos informations en danger.

Imaginez une minute qu’un attaquant trouve l’une de ces vulnérabilités et obtienne une emprise préliminaire sur votre environnement. Quel est le rayon de souffle de cette pénétration ? Quel type de dommages pourraient-ils causer ?

Serait-il facile pour un attaquant de comprendre votre environnement et où vous conservez des informations délicates ? Pourraient-ils tirer parti des clés d’API de ressources cloud et des paramètres IAM (identité et accès à la gestion) trop permissifs pour compromettre votre avion de contrôle cloud et accéder à des ressources et des données supplémentaires ? Pourraient-ils être en mesure d’extraire ces données dans leur propre compte cloud sans détection, comme avec une commande de synchronisation de conteneur de stockage ?

Regardez beaucoup plus loin, et il est possible que vous n’aimiez pas ce que vous découvrez . Agissez rapidement pour fermer ces espaces dans votre sécurité cloud avant que les pirates ne puissent les exploiter. Et reconnaissez également que la « dérive » de la configuration du cloud se produit tout le temps, même lorsque des pipelines CI/CD automatisés sont utilisés, vous devez donc rester vigilant. Un environnement cloud dépourvu de mauvaise configuration aujourd’hui ne conservera probablement pas cette méthode longtemps.

La sécurité du cloud est la sécurité de la configuration

Le cloud est essentiellement un énorme ordinateur programmable, et les opérations du cloud sont concentré sur la configuration des ressources cloud, composées de ressources sensibles à la sécurité telles que IAM, les groupes de sécurité et l’accès aux politiques pour les bases de données et le stockage des éléments. Vous devez vous assurer que les configurations de vos ressources cloud sont correctes et sécurisées le premier jour où elles conservent cette méthode le jour 2.

Les experts du marché appellent cela la gestion de la posture de sécurité du cloud (CSPM). Et c’est ce que les clients du cloud ont tendance à se tromper tout le temps, dans certains cas avec des effets dévastateurs. Si vous constatez une violation de données, y compris Amazon Web Services, Microsoft Azure ou Google Cloud, il est fort probable que l’attaque ait été rendue possible grâce à des erreurs de consommation dans le cloud.

Nous avons tendance de se concentrer sur la prévention des erreurs de configuration pour les ressources de cloud privé telles que les services de stockage d’objets (par exemple, Amazon S3, Azure Blob) et les réseaux virtuels (par exemple, AWS VPC, Azure VNet), et il est absolument vital de le faire.

Il est également crucial de reconnaître que la sécurité du cloud dépend de l’identité. Dans le cloud, de nombreux services se connectent les uns aux autres via des appels d’API, nécessitant des services IAM pour la sécurité au lieu de directives de réseau basées sur IP, de programmes de pare-feu, etc.

Une connexion d’une fonction AWS Lambda à un Le pail Amazon S3 est réalisé à l’aide d’une stratégie connectée à une fonction prise en charge par la fonction Lambda : son identité de service. L’IAM et les services similaires sont complexes et riches en fonctionnalités, et il est simple d’être excessivement permissif juste pour faire fonctionner les choses, ce qui signifie que les configurations IAM excessivement permissives (et souvent dangereuses) sont la norme.

Cloud IAM est le tout nouveau réseau, mais comme les services cloud IAM sont créés et gérés avec la configuration, la sécurité du cloud reste une question de configuration et d’évitement des erreurs de configuration.

Mauvaises configurations du cloud et événements de sécurité

Il y a beaucoup plus d’infrastructures cloud qu’il n’y en avait dans le centre d’information, et toutes ces ressources sont totalement configurables – et mal configurables. Tenez compte de tous les différents types de ressources cloud facilement disponibles et des méthodes qu’elles peuvent être intégrées ensemble pour prendre en charge les applications, et les possibilités de configuration sont efficacement illimitées.

Dans notre enquête 2021, 36 % du cloud Les spécialistes ont déclaré que leur organisation avait subi une grave fuite ou violation de la sécurité du cloud au cours de l’année précédente. Et il existe une variété de méthodes pour que ces occurrences deviennent possibles.

Le rapport sur l’état de la sécurité dans le cloud 2021

Source : Le rapport sur l’état de la sécurité dans le cloud 2021

N’oubliez pas que les configurations de ressources telles que Le stockage d’objets et les services IAM peuvent devenir exceptionnellement complexes dans des environnements évolutifs, et chaque violation de cloud dont nous avons connaissance a inclus une chaîne d’exploits de mauvaise configuration. Au lieu de se concentrer uniquement sur les erreurs de configuration d’une seule ressource, il est essentiel de comprendre complètement votre cas d’utilisation et de réfléchir de manière critique à la manière de sécuriser ces services dans le contexte complet de votre environnement.

Par exemple, vous pouvez penser que votre Amazon S3 bucket est configuré en toute sécurité en raison du fait que « Block Public Gain access to » est autorisé, lorsqu’un acteur destructeur pourrait être en mesure d’accéder à son contenu en exploitant des ressources IAM surprivilégiées dans le même environnement. Comprendre le danger de votre rayon d’explosion peut être un problème difficile à résoudre, mais c’est un problème qui ne peut être négligé.

L’ampleur de la mauvaise configuration du cloud

Les vulnérabilités de mauvaise configuration du cloud sont différentes de l’application et les vulnérabilités du système d’exploitation en ce sens qu’elles continuent d’apparaître même après que vous les ayez réellement corrigées. Vous avez probablement mis en place des contrôles dans votre pipeline d’avancement pour vous assurer que certains développeurs ne publient pas les vulnérabilités connues des applications ou du système en cours d’exécution en production. Et lorsque ces déploiements sont protégés, il s’agit généralement d’un problème résolu.

La mauvaise configuration du cloud est variée. Il est courant de voir la même vulnérabilité de mauvaise configuration apparaître encore et encore. Une règle de groupe de sécurité permettant un accès SSH illimité à (par exemple, 0.0.0.0/ 0 sur le port 22) n’est qu’un exemple du type d’erreurs de configuration qui se produisent quotidiennement, généralement en dehors du pipeline de déploiement approuvé. Nous utilisons cet exemple car de nombreux ingénieurs le connaissent (et ont très probablement consacré cet acte pur et simple à un moment donné de leur profession).

Parce que l’infrastructure cloud est si flexible et que nous pouvons la modifier à volonté en utilisant des API, nous avons tendance à le faire beaucoup. C’est un avantage, car nous innovons et améliorons continuellement nos applications et avons besoin de personnaliser notre infrastructure pour prendre en charge cette innovation. Si vous ne protégez pas contre une mauvaise configuration tout au long de la méthode, attendez-vous à ce que beaucoup de mauvaises configurations soient introduites dans votre environnement. La moitié des groupes d’ingénierie et de sécurité du cloud sont confrontés chaque jour à au moins 50 événements de mauvaise configuration.

Rapport sur l’état de la sécurité du cloud 2021

Source : Rapport sur l’état de la sécurité du cloud 2021

Pourquoi le cloud une mauvaise configuration se produit

Si nous utilisons efficacement le cloud, la seule constante de nos environnements cloud est le changement, car cela suggère que nous innovons rapidement et améliorons continuellement nos applications.

Avec chaque modification comporte des risques.

Selon Gartner, d’ici 2023, au moins 99 % des défaillances de sécurité dans le cloud seront imputables au client. Ce 1 % apparaît comme une haie en pensant qu’une mauvaise configuration du cloud est à l’origine des défaillances de la sécurité du cloud, et une mauvaise configuration est à 100 % le résultat d’une erreur humaine.

Mais pourquoi les ingénieurs du cloud commettent-ils si souvent des erreurs aussi cruciales ?

L’absence de sensibilisation à la sécurité et aux politiques du cloud a été l’une des principales causes de mauvaise configuration du cloud signalée au cours de l’année écoulée. Rassemblez toutes vos directives de conformité et vos politiques de sécurité internes et vous aurez probablement un volume aussi épais que Guerre et paix. Aucun humain ne peut mémoriser tout cela, et nous ne devrions pas nous attendre à ce qu’ils le fassent.

Nous avons donc besoin de contrôles sur place pour nous défendre contre les erreurs de configuration. Mais 31 % déclarent que leur entreprise ne dispose pas de contrôles et d’une surveillance adéquats pour éviter les erreurs de configuration du cloud.

Cela s’explique en partie par le fait qu’il existe de nombreuses API et interfaces cloud que les équipes peuvent gérer efficacement. L’utilisation de plusieurs plates-formes cloud (rapportées par 45 % des personnes interrogées) ne fait qu’aggraver le problème, car chacune a ses propres types de ressources, attributs de configuration, interfaces à gouverner, politiques et contrôles. Votre équipe a besoin de compétences qui traitent efficacement toutes les plates-formes cloud utilisées.

La difficulté de la sécurité multicloud est encore plus aggravée si les équipes ont adopté les outils de sécurité natifs d’un fournisseur de cloud, qui ne fonctionnent pas dans des environnements multicloud.

Rapport sur l’état de la sécurité du cloud 2021

Source : Rapport sur l’état de la sécurité du cloud 2021

7 recommandations tactiques

En raison du fait que la sécurité du cloud concerne principalement la prévention, détection et suppression des erreurs de configuration avant qu’elles ne puissent être exploitées par des pirates, une automatisation fiable basée sur des politiques est nécessaire à chaque phase du processus de développement, des installations en tant que code (IaC) en passant par CI/CD jusqu’à l’exécution.

Ci-dessous, j’ai répertorié 7 suggestions de professionnels du cloud pour y parvenir.

1. Développez la visibilité de votre environnement.

La sécurité du cloud consiste à comprendre votre cloud et à empêcher vos adversaires d’accéder à cette compréhension. Si vous n’êtes pas informé de l’état complet de votre environnement cloud, y compris de chaque ressource, configuration et relation, vous vous exposez à une menace sérieuse. Établissez et maintenez une exposition détaillée de votre environnement cloud sur toutes les plates-formes cloud et évaluez en permanence l’impact sur la sécurité de chaque modification, y compris les risques potentiels de rayon d’explosion.

Vous n’obtiendrez pas seulement une meilleure posture de sécurité, mais vous permettrez vos développeurs à agir plus rapidement, et les professionnels de la conformité vous remercieront pour la preuve d’audit proactive.

2. Utilisez l’infrastructure en tant que code partout où c’est possible.

À quelques exceptions près, il n’y a aucune raison pour que vous construisiez et modifiiez des installations cloud au-delà de l’infrastructure en tant que code et des pipelines CI/CD automatisés, en particulier pour tout ce qui est nouveau. L’utilisation d’IaC apporte non seulement efficacité, évolutivité et prévisibilité aux opérations cloud, mais offre également un système permettant d’examiner la sécurité du pré-déploiement de l’infrastructure cloud. Lorsque les concepteurs utilisent IaC, vous pouvez leur proposer les outils dont ils ont besoin pour inspecter la sécurité de leur infrastructure avant leur déploiement.

Si vous exploitez un environnement multicloud, un outil IaC open source comme Terraform qui a une adoption répandue est probablement votre meilleur choix. Les offres IaC des fournisseurs de services cloud (c’est-à-dire AWS CloudFormation, Azure Resource Supervisor et Google Release Cloud Manager) sont totalement gratuites et méritent d’être prises en compte si vous n’avez pas besoin d’assistance multicloud.

3. Automatisation basée sur des règles d’utilisation partout possible.

Partout où vous avez des règles de cloud exprimées en langage humain, vous acceptez les distinctions dans l’analyse et les erreurs d’application. Chaque politique de sécurité et de conformité cloud qui s’applique à votre environnement cloud doit être révélée et implémentée sous forme de code exécutable. Avec la politique comme code, la sécurité du cloud finit par être déterministe. Cela permet de gérer et d’appliquer efficacement la sécurité et aide les développeurs à obtenir la sécurité dès le début du processus d’avancement.

Évitez la politique de fournisseur propriétaire en tant qu’outils de code et choisissez un moteur de politique open source tel que Open Policy Agent ( OPA). OPA peut être appliqué à tout ce qui peut produire une sortie JSON ou YAML, qui couvre presque tous les cas d’utilisation du cloud.

Priorité aux options qui ne nécessitent pas divers outils et politiques pour IaC et l’exécution de l’infrastructure cloud.

4. Donnez aux concepteurs les moyens de construire en toute sécurité.

Avec le cloud, la sécurité est un problème d’ingénierie logicielle plus qu’un problème d’analyse d’informations. Les professionnels de la sécurité cloud ont besoin de compétences en ingénierie et d’une compréhension du fonctionnement de l’ensemble du cycle de vie de l’avancement des applications logicielles (SDLC), du développement au CI/CD et à l’exécution. Et les concepteurs ont besoin d’outils pour les aider à obtenir la sécurité dès le début du SDLC. Faites de la sécurité une planification et un partenaire proche du développement, et non une réflexion après coup uniquement axée sur les problèmes de post-déploiement.

Former les groupes de sécurité sur les pratiques d’ingénierie du cloud non seulement les équipera beaucoup mieux avec les compétences nécessaires pour se défendre contre les dangers quotidiens du nuage, mais ils acquerront des capacités et une expérience importantes pour faire progresser leur profession. Vous améliorerez la rétention de l’équipe et positionnerez bien mieux votre entreprise comme un lieu de travail souhaitable.

La série de cours de maître sur la sécurité dans le cloud est conçue pour aider les ingénieurs du cloud et de la sécurité à comprendre les dangers du cloud et à réfléchir sérieusement à la protection de leur cas d’utilisation distincts.

5. Verrouillez vos politiques d’accès.

Si vous ne disposez pas actuellement d’une politique officielle d’accès et de gestion de vos environnements cloud, il est maintenant temps d’en créer une. Utilisez des réseaux personnels virtuels (VPN) pour implémenter des interactions protégées dans des zones réseau critiques (par exemple, Amazon Virtual Private Cloud ou Azure Virtual Network). Faites en sorte que le VPN obtienne l’accès offert ou nécessaire afin que le groupe puisse accéder aux ressources de l’entreprise même s’il se trouve sur un réseau Wi-Fi moins utilisé.

Les ingénieurs sont susceptibles de créer de nouvelles directives de groupe de sécurité ou des listes blanches d’IP afin qu’ils peuvent accéder aux ressources de groupe partagées dans le cloud. Des audits fréquents peuvent certifier que les fabricants virtuels ou d’autres installations cloud n’ont pas été exposés à une menace supplémentaire. Gérez les hôtes bastion de production, verrouillez l’IP source et surveillez l’accès SSH illimité.

Dans AWS, Azure, GCP et d’autres clouds publics, IAM fonctionne comme un réseau omniprésent. Suivez le principe de moindre permission et utilisez des outils tels que la structure Fugue Finest Practices pour reconnaître les vulnérabilités que les contrôles de conformité peuvent ignorer. Intégrez les modifications IAM à votre procédure de gestion des changements et utilisez des outils de gestion des identités et des sessions privilégiées.

Adoptez l’état d’esprit « rejeter par défaut ».

6. Étiquetez toutes les ressources cloud.