Temps de lecture : 11 minutes

Dans le cadre d’une mission, nous devions trouver une solution capable de diminuer les risques dans le cloud et qui permettrait au client d’avoir une bonne gestion de sa posture de sécurité principalement dans le cloud public. Plusieurs outils pouvaient répondre à cette problématique, parmi lesquels CloudGuard de Checkpoint, CloudHealth de VMWare et Aqua Sec, pour ne mentionner que ceux-là. Après un PoC où nous avons testé et comparé la capacité de chaque outil en matière de posture de sécurité, CloudGuard a été retenu.

Le but de cet article n’est pas de faire une comparaison des outils cités, car le choix dépend essentiellement du contexte, mais de présenter dans un premier temps les raisons pour lesquelles CloudGuard a été retenu, et dans un second temps les étapes de sa mise en place au sein de l’environnement du client.

CloudGuard

Présentation de la solution

CloudGuard est un outil CSPM proposé par Checkpoint sous la forme d’une plateforme SaaS. 

CloudGuard est une solution qui offre de multiples fonctionnalités :

• Inventory. Grâce à des dashboards, il est possible de visualiser des statistiques basées sur les résultats des analyses effectuées par l’outil.
• Posture management. Elle permet de gérer la conformité des ressources cloud. L’outil est doté de plusieurs jeux de règles bien définies tirées de standards (CIS benchmark, RGPD, etc), auxquels le client peut ajouter des jeux de règles personnalisés. Ces jeux de règles, appliqués aux comptes cloud du client, font ressortir les écarts entre la politique de sécurité déclarée et l’état de sécurité réel.
• Shiftleft. Cette fonctionnalité permet de faire un check de conformité sur les templates d’Infra as Code (Terraform et Cloudformation). 
• Intelligence qui se base sur l’analyse des logs d’activité des comptes et des logs réseaux pour détecter les flux en provenance de sources malicieuses. 
• CloudBots. L’outil fournit un processus automatique d’auto remédiation pour les erreurs de configuration détectées lors de ses analyses.
• Workload protection. CloudGuard protège les fonctions serverless et aussi les containers Kubernetes

Les arguments de CloudGuard qui ont convaincu le client

Le client s’est basé sur ces principaux critères pour orienter son choix vers CloudGuard :

• Un outil cloud agnostique. L’environnement client, d’abord on premise, s’étend aujourd’hui au cloud. Il fallait donc un outil central permettant d’interagir à la fois avec les environnements internes et cloud. Dans le cas de ce projet, l’environnement cloud est approvisionné depuis la chaîne CI/CD, qui se situe en interne. C’est là aussi que sont réalisés les scans avant déploiement (avec la fonctionnalité Shiftleft). 
• Autonomie dans l’écriture des règles de conformité. La facilité d’écriture des règles a été particulièrement convaincante. L’outil utilise un langage qui lui est propre (le GSL). Le client a voulu utiliser un outil CSPM pour durcir sa landing zone. CloudGuard a montré qu’il était possible de créer des règles qui pouvaient non seulement cibler la landing zone mais aussi les ressources déployées par les équipes projet. 
• Intégration pratiquement native avec d’autres outils déjà présents dans l’environnement du client (outil de ticketing, système de gestion de la sécurité, etc)
• Présence d’une fonctionnalité permettant d’assurer la conformité des ressources avant déploiement sur le cloud : shiftleft

Les fonctionnalités suivantes sont celles qui étaient prioritaires dans l’objectif d’avoir deux niveaux de contrôle avec l’outil : 

• Shiftleft pour le check de conformité avant déploiement 
• Posture management pour la conformité des ressources déployées dans le cloud.

Intégration dans l’environnement du client

L’intégration de CloudGuard s’est faite pour le moment uniquement avec l’environnement AWS, le client ayant estimé ne pas être assez mature sur la gestion de ses plateformes cloud fournies par d’autres fournisseurs.

A- Onboarding des comptes

Cette étape consiste à donner à CloudGuard les permissions qui lui sont nécessaires pour analyser un compte. 

Plus précisément, un rôle IAM doit être créé sur le compte AWS et sera assumé par un autre compte tiers managé par CloudGuard :

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Principal": {
                "AWS": "arn:aws:iam::<CloudGuard_ACCOUNT_ID>:root"
            },
            "Action": "sts:AssumeRole",
            "Condition": {
                "StringEquals": {
                    "sts:ExternalId": "123456789012345678901234567890"
                }
            }
        }
    ]
}

Côté CloudGuard, il convient de créer un environnement AWS en lui passant l’ARN du rôle et l’external ID. L’external ID est important dans la mesure où il permet d’endiguer le problème du “confused deputy”. 

A ce rôle seront attachées des policies qui permettent à CloudGuard d’analyser la configuration des ressources du compte.

Pour gérer les comptes AWS, CloudGuard a deux modes d’opération :

• Le mode Monitor qui consiste à attacher au rôle précédent uniquement des permissions en lecture
• Le mode Full protection, qui inclut le mode monitor, et qui comporte des permissions supplémentaires en écriture sur certaines ressources du cloud telles que les security-groups et les instances EC2.

Le client a eu à confirmer sa stratégie de déploiement par rapport aux enjeux suivants :

• Est-ce que je souhaite onboarder tous les comptes existants ou uniquement une partie ? Dans le cas qui nous concerne, le client a choisi de tous les onboarder, et ce de façon automatisée via Terraform.
• Comment onboarder les futurs comptes ? Pour ce projet, le client a choisi de procéder à un onboarding automatique.
• Comment vérifier qu’un compte a bien été onboardé dans la solution ? Là aussi le client a souhaité automatiser cette vérification.

• Onboarder tous les comptes de l’organisation (environ 200)

Pour ce besoin, deux possibilités semblaient convenir

• Script d’automatisation fourni par Checkpoint. Ce script permettait d’onboarder toute l’organisation AWS du client. Il crée une stack Cloudformation qui contient le rôle et les policies sur chaque compte AWS.

• Utilisation du provider Terraform de CloudGuard. Cette méthode consiste à onboarder chaque compte via terraform. 

Cette dernière méthode convenait le mieux. Le script python aurait été difficilement maintenable par l’équipe sans une réadaptation conséquente du code. Alors que dans le pipeline CI/CD le principal outil IAC est Terraform, la gestion des stacks Cloudformation déployées par le script python n’aurait pas été sans effort.  Avec cette méthode, la gestion des states Terraform pouvait se faire en un point unique.

• Onboarder automatiquement les futurs comptes AWS

Historiquement chez le client, la création d’un nouveau compte AWS se fait via une souscription. Lorsqu’une équipe projet veut un compte, il lui faut faire la demande via un portail en remplissant un formulaire. Une fois les informations valides entrées et le formulaire envoyé, un job jenkins les récupère et va procéder à la création du compte avec les configurations spécifiques qui constituent la baseline du compte. Pour répondre à ce use-case, deux ressources terraform sont ajoutées à la baseline appliquée au compte :

• Le rôle IAM avec les policies nécessaires que CloudGuard endosse pour analyser un compte
• Une ressource qui crée l’environnement CloudGuard associé au compte AWS

• Processus de vérification

Tout compte de l’organisation doit être onboardé sur CloudGuard. Pour le vérifier, un système composé des services AWS EventBridge et Lambda a été mis en place. Il va tourner à la manière d’un cron job, rechercher dans l’organisation tout compte non embarqué dans CloudGuard, et alerter. 

B- Ecritures de règles spécifiques au contexte client

L’outil comporte des jeux de règles prédéfinies qui permettent de procéder à des analyses de configuration, une fois les comptes embarqués. Parmi ces jeux de règles prédéfinies, un jeu de règles créé par Checkpoint sur base des standards de l’industrie (CIS BenchMark, RGPD, etc) réunit des règles de bonnes pratique cloud et concerne la plupart des services d’AWS (IaaS, PaaS et SaaS).

Plusieurs de ces règles ont été affinées et vont composer le jeu de règles personnalisées de la landing zone et touchent les domaines suivants :

• Exposition internet et/ou publique des ressources (VPC, S3 bucket )
• Stratégie de chiffrement des données (EBS, S3)
• Gestion des identités (IAM, tout type de policy IAM)
• Gestion des accès réseaux (security groups, EC2, VPC)

Les équipes projets du client doivent pouvoir profiter d’un socle durci où ils peuvent lancer leurs projets. Voilà pourquoi les règles qui concernent la Landing zone sont pour la plupart très strictes.

Par exemple, les bucket s3 qui contiennent des logs techniques de la Landing zone doivent impérativement être chiffrés par une clé gérée par le client.

S3Bucket should have encryption.serverSideEncryptionRules contain-all [ ( serverSideEncryptionByDefault.serverSideEncryptionAlgorithm='aws:kms' ) and ( serverSideEncryptionKeyManagementServiceKeyId unlike '%alias/aws/s3' ) ]

Les autres buckets S3 appartenant à une équipe projet ne sont pas forcément soumis à cette obligation, notamment si le niveau de confidentialité des données qu’ils stockent n’est pas élevé.

S3Bucket should have encryption.serverSideEncryptionRules

(note : dans cette règle la clé de chiffrement peut être une clé managée par AWS, ce que la règle précédente interdit)

Comme mentionné quelques lignes plus haut, l’outil a convaincu par la facilité à écrire des règles de conformité. Par exemple, pour être conforme avec le RGPD toute entreprise en Europe utilisant AWS cherche la plupart du temps à limiter le déploiement de ses ressources dans des régions européennes. Un exemple plus concret : pour une utilisation conforme du service Lambda, l’écriture de la règle GSL (langage CloudGuard), ressemblerait à cela :

Lambda should not have region in $UnauthorizedRegions

(nb : $UnauthorizedRegions est une liste de régions non autorisées stockée au préalable sur l’outil).

La clause where du GSL permet de cibler exactement les ressources pertinentes pour une règle donnée :

Lambda where account=”123456789012” should not have region in $UnauthorizedRegions

Cette règle appliquée à une OU composée de plusieurs comptes dont 123456789012 ne sortira des résultats que pour ce dernier.

C- Mise en place de Shiftleft

La fonctionnalité Shiftleft permet d’avoir des contrôles de sécurité au plus tôt dans le pipeline CI/CD. Elle permet de tester trois types de ressources et nous avons commencé à l’utiliser pour analyser les templates Terraform qui déploient les ressources sur AWS.

• Intégration dans le pipeline

Pour utiliser cette fonctionnalité CloudGuard propose un binaire qui est intégré dans la chaîne de déploiement. Lors de son exécution, ce binaire communique avec le backend de CloudGuard pour récupérer le jeu de règles lui permettant d’analyser les templates d’Infra as Code.

Les résultats d’une analyse sont envoyés vers la plateforme SaaS. Par défaut, un test avec shiftleft arrête le pipeline dès qu’une alerte soulevée est de sévérité LOW. Selon le besoin, le niveau de sévérité qui stoppera le pipeline peut être ajusté.

En exemple, voici la commande cli à exécuter pour analyser du code Terraform :

shiftleft iac-assessment -p  {projectPath}  -r {ruleId} -e {environmentId} -s {Low|Medium|High|Critical}

• Implémentation des règles pour shifleft

Ilétait primordial pour le client d’avoir les mêmes règles de conformité qui s’appliquent à la fois avant et après le déploiement des ressources.

Les jeux de règles utilisés pour le posture management ne s’appliquent pas aux templates IaC à analyser. Une adaptation de ces règles s’est imposée. Puisqu’aucune translation automatique des règles n’était proposée avec l’outil, il fallait le faire règle par règle.

Cette limitation vient du fait de la non uniformité de la nomenclature des champs dans les configurations des ressources cloud et Infra as Code.

Prenons l’exemple d’une règle sur le chiffrement au repos des bucket s3.

Pour la fonctionnalité posture management qui concerne les ressources qui tournent déjà dans le cloud, la syntaxe GSL est la suivante :

S3Bucket  should have encryption.serverSideEncryptionRules

Pour shiftleft qui gère la conformité avant déploiement, la règle s’écrit comme suit :

aws_s3_bucket  should have server_side_encryption_configuration 

D- Politiques de contrôle continu

Le contrôle continu permet d’être alerté dès qu’un nouveau problème est détecté par les différentes fonctionnalités de CloudGuard. Pour le posture management il s’agit d’appliquer à un environnement ou une unité organisationnelle un jeu de règles. Dès lors, l’outil va analyser le compte AWS associé à l’environnement toutes les heures.

• Stratégie de création des politiques

Parce que tous les comptes du client (landing zone et comptes équipe projet) n’ont pas les mêmes exigences, appliquer un jeu de règles à tous les comptes onboardés ne convient pas. C’est de là qu’est venue la nécessité d’organiser les comptes. Des unités organisationnelles ont été créées de manière à mettre ensemble les environnements ayant le même but fonctionnel.

Un jeu de règles peut s’appliquer à chacun des niveaux dans cette hiérarchie.

Une stratégie de tagging déployée dans l’organisation AWS permet d’avoir des règles plus affinées et donc de diminuer les faux positifs.

Lambda where tags contain [ key=’type’ and value=dev ] should not have region=’eu-west-1’

Une telle règle, faisant partie d’un jeu appliqué à l’OU racine AWS, vérifie que des comptes de développement n’ont pas de fonctions Lambda qui tournent dans la région Irlande.

• Notifications

Pour être alerté rapidement des problèmes de non-conformité du cloud, il est possible de créer des politiques de contrôle continu. Une politique de contrôle continu permet à CloudGuard d’analyser toutes les heures un environnement ou une unité organisationnelle. Plus concrètement un ou plusieurs jeux de règles va être appliqué à l’environnement (ou l’OU). Les nouvelles alertes peuvent être envoyées vers de multiples cibles telles qu’un système de gestion de la sécurité, un canal slack, une adresse email etc.

Dans le cadre de notre projet client, il était pertinent d’utiliser Security Hub, qui centralise déjà les logs du cloud AWS, pour recevoir ces notifications.

Conclusion

CloudGuard s’est montré pertinent par rapport aux besoins du client. Checkpoint propose plusieurs moyens pour l’intégrer dans différents types d’environnement que ce soit dans le cloud ou dans un environnement hybride comme ce fut le cas pour notre client. Son intégration dans l’environnement du client a été plus ou moins facile et a permis plusieurs niveaux de contrôle. La fonctionnalité Shiftleft, bien qu’assez récente, permet néanmoins de relever plusieurs problèmes de configurations avant même de déployer des ressources dans le cloud.