Par Jason Merrick, SVP des produits chez Tenable
Avec l'adoption croissante du cloud par les entreprises, la sécurité de celui-ci est devenue une priorité absolue. Toutefois, entre les environnements multi-cloud, les configurations complexes, les cycles de développement rapides et la méconnaissance, voire le désintérêt, des développeurs pour la cybersécurité, la protection des infrastructures cloud est un véritable parcours du combattant. C’est là que les Cloud-Native Application Protection Platform (CNAPP) apportent une réponse globale, en facilitant une sécurité de bout en bout, du développement à la production. Elles permettent aux développeurs de travailler librement tout en assurant aux administrateurs une tranquillité d'esprit. Pour être efficaces, elles doivent cependant répondre à des critères clés et suivre les meilleures pratiques permettant de sécuriser chaque étape du cycle de vie des applications.
Légende : Intégration d’une CNAP avec AWS
Une visibilité complète grâce à une intégration profonde
Une CNAPP efficace commence par établir une connexion directe avec les API des principaux fournisseurs cloud comme Azure, AWS, GCP et OCI. Cette intégration permet une visibilité complète sur toutes les ressources cloud, y compris les workloads, les identités, les configurations réseau et les données. Grâce à cette vue d’ensemble, les organisations peuvent identifier rapidement des configurations inadéquates, des autorisations excessives et d’autres vulnérabilités qui pourraient compromettre leur environnement. Par exemple, pour AWS, il est possible de choisir entre deux modes de connexion : en "frictionless" via AWS Systems Manager Inventory et AWS Systems Manager Agent (SSM Agent), ou en utilisant le cloud connector d’AWS.
Une gestion proactive des risques via le CSPM
Une fois l’infrastructure connectée, la plateforme CNAPP repose sur deux piliers essentiels pour la gestion des risques cloud. Premièrement, le Cloud Security Posture Management (CSPM) scanne en permanence les configurations pour identifier les violations de conformité avec des standards comme le RGPD, ISO 27001 ou les benchmarks CIS. Cela garantit que les environnements respectent les meilleures pratiques en matière de sécurité. La plateforme s’interconnecte en mode sans agents avec les fichiers de configuration des infrastructures en production pour les comparer à ses bases de données de vulnérabilités et de bonnes pratiques.Le Cloud Infrastructure Entitlement Management (CIEM) analyse les permissions des identités (humaines ou machines) pour réduire les risques liés à des autorisations excessives ou inutilisées. Il permet d’appliquer des politiques d’approvisionnement "juste-à-temps" et de moindre privilège, limitant ainsi les possibilités d'accès non autorisés. L’objectif du CIEM est de minimiser les risques sans compromettre la productivité des utilisateurs.
Uniformisation au service d’une CNAPP et d’un CSPM plus intelligents
Le défi principal dans la sécurisation de l'Infrastructure as Code (IaC) réside dans le manque de standardisation des définitions d'infrastructure. Par exemple, le YAML de Kubernetes est différent du HashiCorp Configuration Language (HCL) utilisé pour Terraform. Ce manque d'uniformité complique l'évaluation et la réduction des risques. La seule manière évolutive d'obtenir de la cohérence est de normaliser les types d'IaC dans un format uniforme (Cloud as Code).Une fois les définitions d'infrastructure normalisées, des vérifications basées sur des politiques (Policy as Code) peuvent être appliquées pour identifier les violations de bonnes pratiques en matière de conformité ou de sécurité. Les solutions CSPM doivent examiner le code tout au long de son développement, sans entraver le flux de travail et l'agilité des développeurs. Open Policy Agent (OPA) est désormais le standard pour l'application des politiques. Les moteurs de politiques basés sur Python, par exemple, sont peu maniables par rapport à ceux basés sur OPA, qui utilisent le langage de requête Rego.
Une sécurité avancée pour Kubernetes
Les environnements Kubernetes, essentiels à la modernisation des infrastructures, introduisent également des défis uniques en termes de sécurité. Une CNAPP doit simplifier leur gestion grâce à une surveillance continue des ressources Kubernetes, comme les nœuds, les namespaces et les comptes de service, tout en détectant les configurations non conformes aux standards de sécurité, tels que les benchmarks CIS pour Kubernetes.
L’automatisation au service de la sécurité
Au-delà du monitoring, la force d’une CNAPP réside dans son approche automatisée de la remédiation. Lorsqu’une vulnérabilité ou une configuration incorrecte est détectée, plusieurs solutions sont possibles. Il est possible d’appliquer des correctifs automatisés intégrés dans des outils comme Terraform et CloudFormation via une intégration fluide avec des plateformes comme Jira, Slack ou ServiceNow, et des guides de correction manuelle lorsque l’automatisation n’est pas souhaitée. Cette flexibilité garantit que la sécurité ne freine pas les cycles de développement rapide.
La plupart des développeurs ne sont toutefois pas des experts en sécurité et manquent des connaissances nécessaires pour remédier aux mauvaises configurations détectées dans l'IaC. Les workflows de remédiation doivent ainsi avoir la capacité de s'intégrer à ceux des développeurs. La seule approche scalable est une solution CSPM qui génère automatiquement le code nécessaire pour résoudre les mauvaises configurations et qui crée des pull requests contre la branche principale (Remédiation en tant que Code).
Légende : Exemple d'alerte fournie par une CNAPP concernant un conteneur vulnérable.
Assurer une remédiation plus efficace et sécuritaire en production
La plus grande distinction entre les solutions CSPM de première génération et celles de nouvelle génération réside dans leur approche de la remédiation des erreurs qui se produisent sur la production. Les solutions CSPM de première génération offraient des capacités de remédiation pour traiter un ensemble limité de risques en modifiant automatiquement les configurations en temps réel. Cette approche était toutefois risquée. Elle nécessite d’abord que l'outil CSPM soit autorisé à mettre à jour les environnements en temps réel, ce qui peut être contraire à la politique de sécurité. Ensuite, autoriser un outil à apporter des modifications automatiques aux configurations de l'infrastructure en temps réel introduit le risque d'un éventuel temps d'arrêt. Et plus important encore, toute modification apportée aux configurations d'infrastructure en temps réel crée une dérive par rapport à la base de référence de l'IaC. Cela signifie que si l'infrastructure est redéployée à partir de l'IaC, le changement effectué en temps réel sera perdu.
Les solutions CNAPP de nouvelle génération établissent quant à elle l'IaC comme la seule source de vérité. Par exemple, quand un ingénieur augmente la configuration de la mémoire d'une instance de calcul en temps réel pour améliorer les performances d'une application, le changement de configuration n'introduit pas de risque, mais l'IaC correspondant doit être mis à jour pour refléter ce changement. Cela permet d’établir une nouvelle base de référence.En cas de configuration risquée, comme la création accidentelle d'une règle dans une table de routage exposant un sous-réseau privé à Internet, la plateforme génère automatiquement le code nécessaire pour corriger la configuration. Les opérations peuvent ensuite redéployer l'infrastructure en utilisant le code mis à jour et éliminer les risques.En réunissant des outils de gestion des risques, de remédiation et de conformité dans une seule plateforme, la CNAPP réduit la complexité des environnements multi-cloud. Elle permet aux développeurs d’innover rapidement tout en assurant aux équipes SecOps un contrôle continu sur la sécurité des environnements cloud.
Légende : Des outils open-source gratuits comme Terrascan offrent aux développeurs un moyen simple de se familiariser avec les tests de Policy as Code (PaC) pour l'Infrastructure as Code (IaC).
Connexion
