Conformité, co-responsabilité, contrôles d'accès… Quelles sont les clés d'une stratégie de sécurité cloud-native ?

Comment bien sécuriser ces environnements émergents pour des professionnels de sécurité peu familiers avec l'évolution rapide de la pile technologique cloud-native ?

Les bénéfices d'une approche cloud-native et des technologies de containers comme Kubernetes sur laquelle elle repose, ne sont plus à démontrer. Convaincues, les entreprises sont aujourd’hui nombreuses à investir dans cette voie pour leurs applications legacy ou leurs nouveaux pipelines. Mais si on reconnait les avantages - portabilité, évolutivité et surtout, réduction drastique des délais de déploiement - un défi de taille s’impose : comment bien sécuriser ces environnements émergents pour des professionnels de sécurité peu familiers avec l'évolution rapide de la pile technologique cloud-native ?

Entériner une nouvelle approche de la sécurité 

Il est certain que la conception même des applications cloud-natives les rend plus sûres que les applications traditionnelles. Les stratégies d'immuabilité créées pour les conteneurs par exemple ou encore le "shift-left" offrent en effet de réels avantages en matière de protection. Mais pour en tirer pleinement parti, il est indispensable de déployer une stratégie et des contrôles de sécurité additionnels, dédiés à la conception et à l'architecture toute particulière du cloud natif. 

De nombreuses équipes de sécurité pensent à tort que les solutions traditionnelles peuvent être facilement configurées ou adaptées à la sécurité des environnements de conteneurs. Mais en réalité, bien qu’avancées, ces solutions ne sont pas suffisamment nuancées pour les besoins de ces environnements. Par exemple, dans une architecture cloud-native, les firewalls traditionnels ne sont pas appropriés car ils surveillent l'hôte sur une adresse IP fixe tandis que dans un environnement Kubernetes, les adresses IP sont constamment modifiées et attribuées dynamiquement aux Pods au sein d'un cluster. Un pare-feu classique ne pourrait donc pas suivre ces informations changeantes pour savoir quel Pod est en cours d'exécution, ou à quelle application il appartient. 

Rattraper le retard en matière de conformité 

Assurer la conformité des environnements cloud natifs est aussi une tâche complexe ; les organismes règlementaires n'ayant pas encore établi de directives spécifiques pour ces environnements. Dans ce contexte, comment garantir sa conformité ? Si, en l'absence de règlementation dédiée, cela peut paraître impossible, l'objectif sera donc de tenter de démontrer que toutes les couches de l’architecture cloud-native de l’entreprise répondent bien aux directives en vigueur, ce qui finalement nous amènera à reconnaître la vacuité de ces contrôles classiques pour les environnements cloud natif spécifiques.

Prenons un exemple :  les directives PCI DSS, ces normes de sécurité de l’industrie des cartes de paiement servant de référence aux conditions techniques et opérationnelles pour protéger les données du titulaire, exigent que les systèmes PCI soient séparés des systèmes non-PCI. Elles orientent sur des méthodes strictes de contrôle d’accès et notamment « la garantie que les systèmes hors du champ d'application ne peuvent être utilisés pour compromettre un composant du système dans le champ d'application". Cela implique notamment les pares-feux, les contrôles d'accès physique, l'authentification, le monitoring et la restriction des accès administrateur. Autant de méthodes qui, nous le savons, fonctionnent différemment dans les environnements cloud natifs.

Par conséquent, pour répondre à ces exigences dans un cluster Kubernetes multi-tenant, nous devons modifier notre approche : séparer les registres et les pipelines, répartir les ressources entre entités séparées et approuver les administrateurs via des espaces de nommage K8s. Un étiquetage et un balisage appropriés doivent ensuite être opérés au sein de ces namespaces pour renforcer encore plus la segmentation.  Le tout en mettant en place un contrôle d'accès basé sur les rôles (RBAC). 

Il ne s'agit ici que d'un exemple pour aborder la problématique de conformité. De manière générale, la capacité de l’entreprise à prouver la mise en œuvre de contrôles dédiés fera l’affaire des auditeurs. Ces derniers devraient d’ailleurs très prochainement rattraper leur retard et établir des directives de conformité spécifiques pour le cloud natif. Mais en attendant, il est indispensable de déployer des contrôles de sécurité adaptés à ces environnements. 

Bien intégrer la notion de co-responsabilité en matière de sécurité cloud

A ces réflexions, s’ajoute une question importante : la notion de responsabilité ultime. Si le CSP ou fournisseur de services cloud peut proposer des configurations de sécurité par défaut, il n'est aucunement responsable de la vérification ou de l'amélioration de la sécurité des comptes et des services de ses clients. Il n'intervient pas non plus dans les applications que ces derniers déploient. Une mauvaise compréhension de la répartition des rôles et des responsabilités peut générer ainsi un faux sentiment de sécurité. Gartner indique d’ailleurs dans son rapport intitulé "How to Respond to the 2020 Threat Landscape", que "jusqu'en 2023, au moins 99% des défaillances de la sécurité du cloud seront imputables au client." Mettre en œuvre des services de sécurité cloud adaptés tout en envisageant correctement l'étendue réelle du modèle de responsabilité partagée incombe donc au client.

La protection des applications cloud natives ne pourra se faire que via des approches tout aussi dynamiques que l’environnement dans lequel elles sont déployées. Finalement, l’essentiel sera de prendre du recul et de planifier la sécurité cloud native de bout-en-bout en suivant le rythme de la transformation des architectures et des méthodes de développement applicatif modernes. Et face à la multitude d’alertes, de faux positifs et d’outils actifs gérés par leurs équipes, le tout, avec une visibilité augmentée en matière de catégorisation des risques.