Comment sécuriser l’infrastructure cloud tout au long du cycle de développement

Le cloud computing représente le changement informatique le plus profond depuis des années, aidant les organisations de tous les secteurs à transformer chaque élément de leur mode de fonctionnement. Cependant, le cloud a bouleversé la sécurité, produisant de toutes nouvelles catégories de menaces et de difficultés qui mettent les équipes de sécurité à rude épreuve au-delà de leurs capacités. Les organisations sont confrontées à un choix difficile : ralentir le rythme de développement dans un environnement de plus en plus concurrentiel pour permettre aux groupes de sécurité de suivre le rythme, ou embaucher plus d’ingénieurs de sécurité à une époque de guerres d’enchères qui entraînent leur implantation annuelle dans la stratosphère.

La sécurité est devenue le principal aspect limitant la vitesse à laquelle les équipes peuvent entrer dans le cloud et à quel point les organisations peuvent être agiles et efficaces. Les examens de sécurité manuels et les procédures d’approbation réduisent la livraison de l’infrastructure cloud dont les groupes d’applications ont besoin, et d’importantes ressources d’ingénierie sont absorbées pour gérer le volume considérable de vulnérabilités de mauvaise configuration du cloud qui doivent être examinées, ciblées et corrigées.

La nature du cloud lui-même offre une autre technique pour résoudre la sécurité du cloud, sans les compromis habituels. Dans cet article, nous verrons pourquoi l’automatisation de la sécurité du cloud développée sur Open Policy Agent (OPA) – l’exigence open source pour la politique en tant que code – peut réaliser ce que les approches de sécurité traditionnelles ne peuvent pas faire. Et nous verrons quelques exemples de la façon dont les options basées sur l’OPA telles que Fugue peuvent être appliquées pour sécuriser l’ensemble du cycle de vie de l’avancement des installations cloud de manière holistique.

Pourquoi est-il si difficile de garder le cloud sécurisé ?

L’infrastructure cloud est extrêmement différente de l’infrastructure du centre de données. La façon dont nous développons et gérons l’infrastructure cloud est variée. La surface d’attaque est variée. Et la façon dont les pirates opèrent est différente.

Les vulnérabilités de mauvaise configuration du cloud représentent la principale raison des fuites et des violations d’informations basées sur le cloud. Selon Gartner, presque toutes les attaques efficaces contre les services cloud sont le résultat d’une mauvaise configuration, d’une mauvaise gestion et d’erreurs des clients. Lorsque nous prenons une minute pour mieux comprendre la nature du risque de mauvaise configuration du cloud, il devient clair pourquoi la sécurité du cloud construite sur une politique open source en tant qu’exigence de code comme OPA est essentielle pour faire face à l’obstacle, sans sacrifier la vitesse ou les performances.

Dans le centre de données, les choses ont changé lentement et de manière extrêmement contrôlée. Dans le cloud, la modification est la seule constante. Dans le cloud, les concepteurs construisent leurs propres installations, au lieu d’attendre qu’une équipe du centre de données les leur fournisse. Cela indique que les développeurs font leurs propres choix d’installations, consistant en des configurations critiques pour la sécurité, puis les modifient en permanence. Chaque modification apporte une menace, donc même si les installations sont sûres et sécurisées aujourd’hui, elles ne le seront peut-être pas demain.

Dans le cloud, ce qui change est également différent. La pile d’infrastructure du centre de données est beaucoup plus simple, composée principalement d’un réseau, de serveurs et de stockage. La pile d’installations cloud comprend des versions virtualisées de ces éléments, et bien d’autres encore. Il existe des services de gestion des identités et des accès (par exemple, AWS IAM), des plateformes sans serveur (par exemple, Azure Functions), des conteneurs (Docker) et des systèmes d’orchestration de conteneurs (Kubernetes). Amazon Web Services à lui seul a présenté des centaines de tout nouveaux types de ressources cloud au cours des dernières années, et ils ont tous leurs propres caractéristiques de configuration et considérations de sécurité.

Il y a aussi beaucoup plus de ressources dans un environnement cloud évolutif que dans un centre de données traditionnel. Il n’est pas rare qu’une organisation au niveau de l’entreprise dispose de centaines d’innombrables ressources cloud couvrant des centaines de comptes différents. Si cette organisation fonctionne dans un environnement multicloud, que ce soit par option ou par hasard, la complexité est aggravée par le fait que les services d’installations offerts par chaque cloud diffèrent considérablement en ce qui concerne la configuration et la sécurité.

La conformité a a constamment contribué à garantir le respect des politiques de sécurité, mais le cloud a enfreint la conception de la conformité standard. La plupart des organisations utilisant le cloud doivent se conformer aux contrôles de conformité du marché, tels que HIPAA pour les informations sur les soins de santé, PCI pour les données de services monétaires et SOC 2 pour le traitement des données client dans le cloud. Ces contrôles sont composés dans un langage humain – et généralement peu clair – qui peut être difficile à appliquer aux cas d’utilisation du cloud. Et il y a beaucoup de directives que tout individu doit garder à l’esprit.

Toute cette complexité, ce dynamisme et cette échelle entraînent des erreurs de mauvaise configuration du cloud qui se produisent tout au long de la journée, tous les jours. Le rapport State of Cloud Security 2021, qui a interrogé 300 ingénieurs cloud, a révélé que la moitié des groupes exécutant de grands environnements cloud réglementés subissent plus de 50 erreurs de configuration par jour. L’outil traditionnel pour détecter ces vulnérabilités d’exécution du cloud est la gestion de la posture de sécurité du cloud (CSPM), et les groupes interrogés investissent plus qu’un ingénieur comparable à temps plein dans la gestion du problème. C’est essentiellement un jeu vidéo de Whack-a-mole.

Et ce jeu vidéo est majeur. Des pirates informatiques malveillants ont modifié la façon dont ils attaquent les environnements cloud pour prendre des informations et causer d’autres dommages. Le schéma d’attaque consistant à choisir une cible et à rechercher des vulnérabilités à exploiter a en fait été renversé. Désormais, les pirates utilisent des outils d’automatisation pour analyser l’ensemble d’Internet à la recherche de mauvaises configurations de cloud à exploiter. Libérer une telle vulnérabilité peut effectivement mettre une cible sur le dos de votre organisation.

Comment les installations en tant que code et la politique en tant que code changent la sécurité du cloud

La donne est en train de changer pour les protecteurs de cloud. Les groupes de sécurité ne se contentent plus de suivre l’exécution du cloud pour détecter les vulnérabilités. Ils peuvent travailler directement avec les équipes d’ingénierie et de développement du cloud pour déplacer la sécurité du cloud vers la gauche et éviter ces vulnérabilités avant qu’elles n’atteignent le temps d’exécution.

Avec l’adoption de pipelines de publication CI/CD automatisés et d’installations en tant que code (IaC) , que les ingénieurs utilisent pour spécifier les configurations et les relations des ressources cloud, nous pouvons désormais éviter automatiquement les erreurs de configuration avant même qu’elles n’atteignent l’environnement d’exécution. Au-delà des avantages évidents en matière de sécurité, la sécurisation de l’IaC dans l’avancement et la défense contre la mise en œuvre d’une mauvaise configuration apportent des gains considérables en termes de coût et de vitesse.

Fugue

Mais afin d’inspecter IaC pour des problèmes de sécurité immédiatement sans perte de temps et d’erreur- évaluations manuelles sujettes, nous exigeons la politique en tant que code. Tout comme les langages de démonstration révèlent des fonctions rationnelles sous forme de code et IaC exprime les configurations sous forme de code, la politique en tant que code vous permet d’exprimer vos politiques de sécurité requises sous forme de code. Il n’y a pas de place pour les erreurs d’interprétation et les malentendus.

Avec toute technique de « décalage à gauche » vers la sécurité, vous discutez d’outils conviviaux pour les développeurs qui aident les groupes de développement à corriger les erreurs tôt dans le cycle de vie des progrès logiciels (SDLC). Les ingénieurs d’applications logicielles préfèrent les langages open source aux langages propriétaires, qui sont normalement restreints et plus difficiles à utiliser. Et vous voulez avoir la possibilité d’utiliser exactement les mêmes politiques à tout moment dans le SDLC – des installations comme les vérifications de code aux garde-corps CI/CD à la surveillance de l’exécution – afin que les concepteurs, les développeurs et les équipes de sécurité et de conformité fonctionnent tous à partir de le même livre de règles.

Open Policy Agent est un moteur de politique open source populaire qui est incroyablement efficace et flexible. Des organisations comme Goldman Sachs, Netflix et Pinterest sont toutes d’énormes utilisateurs d’OPA, et Fugue utilise largement OPA pour alimenter l’automatisation de la sécurité basée sur des politiques pour les environnements cloud et IaC. OPA est soutenu par la Cloud Native Computing Foundation (CNCF) et se réjouit d’un environnement d’outils robuste et d’un voisinage actif. Et il est beaucoup plus facile de trouver et de retenir des ingénieurs qui comprennent l’OPA. Lorsque l’on considère une structure de politique en tant que code, c’est un excellent concept pour commencer avec OPA.

Fugue

Recherche de politique en tant que code pour différentes étapes du SDLC

Fugue a été activement impliqué dans le projet OPA et développé l’outil open source Regula qui facilite grandement l’utilisation d’OPA pour vérifier Terraform et AWS CloudFormation IaC. Et Fugue IaC permet aux groupes d’utiliser exactement les mêmes directives pour les vérifications IaC pré-déploiement et la surveillance de l’exécution.

L’effet net d’une approche globale de la sécurité du cloud à l’aide de vérifications automatiques de la politique en tant que code à travers le Le cycle de vie avancé est que vos équipes d’application publieront plus rapidement des fonctions et des fonctionnalités pour les consommateurs, car les équipes d’infrastructure cloud fourniront plus rapidement l’infrastructure sécurisée aux groupes d’applications. Les équipes de sécurité et de conformité auront la possibilité de se concentrer sur les vulnérabilités qui ne peuvent pas être automatisées aussi rapidement qu’une mauvaise configuration du cloud. Vous aurez élevé la barre vis-à-vis des agresseurs et vous aurez très probablement évité les radars en évitant les erreurs de configuration.

Josh Stella est le co-fondateur et PDG de Fugue et un autorité technique sur la sécurité du cloud pour les entreprises extrêmement réglementées avec des clients comme AT&T, Red Ventures et SAP NS2. Fort de 25 ans de savoir-faire en tant que CTO d’une start-up de l’innovation, concepteur principal de solutions chez Amazon Web Provider et conseiller auprès de sociétés de renseignement, Josh a créé Fugue et a été le pionnier de l’utilisation de l’automatisation de la sécurité du cloud basée sur des politiques pour aider les entreprises à fonctionner plus rapidement et de manière plus sûre. dans le nuage. Il est titulaire d’un brevet d’innovation dans le cloud, auteur de livres et animateur de la série Cloud Security Masterclass. Entrez en contact avec Josh sur LinkedIn et via Fugue.

— Nouveau

Tech Forum fournit un emplacement pour explorer et passer en revue les affaires émergentes technologie d’une profondeur et d’une ampleur sans précédent. Le choix est subjectif, basé sur notre choix des innovations que notre société considère comme cruciales et qui intéressent le plus les lecteurs d’InfoWorld. InfoWorld n’accepte pas les supports marketing pour publication et se réserve le droit de modifier tout le contenu contribué. Envoyez toutes vos questions à newtechforum@infoworld.com.