Sécuriser la configuration et les accès aux buckets S3 avec Snyk et Solvo

Solvo donne aux développeurs et aux ingénieurs DevOps les moyens d’exécuter leur infrastructure cloud avec le principe du moindre privilège, à grande vitesse et à grande échelle. Dans cet article, nous allons découvrir un workflow qui associe la plateforme automatique de Solvo à Snyk Infrastructure as Code (Snyk IaC) pour créer un accès personnalisé et sécurisé entre une fonction Lambda et un bucket AWS S3. Cet article a été publié à l’origine sur le site de Solvo.

De plus en plus d’organisations adoptent le modèle Infrastructure as Code pour gérer la configuration de leurs ressources cloud.

Configurer votre infrastructure sous forme de code vous permet de mieux contrôler les versions et le code source, et donc de suivre et de reproduire plus facilement les paramètres d’un environnement à l’autre. Cette approche est particulièrement utile pour créer des buckets AWS S3, qui peuvent servir à stocker votre code ou d’autres données utiles. En tant que ressources cloud, ces buckets S3 sont faciles à partager avec le reste de l’équipe.

Mais il arrive que ces buckets S3 deviennent un peu _trop_faciles à partager. Quand on travaille vite, rédiger une policy IAM sécurisée pour une ressource cloud (S3, Lambda, EC2 ou autre) est rarement une priorité pour les développeurs. Pour gagner du temps et simplifier les choses, il n’est pas rare qu’un développeur configure mal le bucket en lui appliquant des policies de sécurité trop permissives, ce qui risque d’exposer son contenu.

Examinons quelques risques liés aux policies de sécurité et voyons comment les éviter.

Exemple de fonction Lambda mal configurée

Ci-dessous, une configuration Terraform qui déploie une fonction AWS Lambda chargée de placer une image dans un bucket S3. Vous pouvez également voir le code du rôle IAM et de la policy de sécurité.

Quels éléments pouvons-nous tirer de cette configuration pour mieux comprendre son contenu et son niveau de sécurité ?

1```
2# create function 
3resource "aws_lambda_function" "Lambda_function" { 
4    s3_bucket = "my-bucket" 
5    s3_key = "my-key.zip" 
6    function_name = "my-test-function" 
7    role = aws_iam_role.lambda_iam_role.arn 
8    handler = "index.handler" 
9    runtime = "nodejs12.x" 
10    memory_size = 1024 
11    timeout = 900
12}
13
14# create role 
15resource "aws_iam_role" "Lambda_iam_role" {
16    name = "my-lambda-role" 
17    assume_role_policy = <<EOF
18{
19    "Version": "2012-10-17", 
20    "Statement": [
21        {
22            "Action": "sts:AssumeRole", 
23            "Principal": {
24                "Service": "lambda.amazonaws.com" 
25            }, 
26            "Effect": "Allow", 
27            "Sid": ""
28        }
29    ]
30}
31EOF
32}
33
34# create policy 
35resource "aws_iam_role_policy" "Lambda_iam_policy" { 
36    name = "my-lambda-policy" 
37    role = aws_iam_role.Lambda_iam_role.id
38    policy = <<EOF
39{
40    "Version": "2012-10-17", 
41    "Statement": [
42        {
43            "Effect": "Allow", 
44            "Action": [
45                "logs:CreateLogGroup",
46                "logs:CreateLogStream", 
47                "logs:PutLogEvents"
48            ],
49            "Resource": "*"
50        },
51        {
52            "Effect": "Allow", 
53            "Action": "*",
54            "Resource": "*"
55        }
56    ]
57}
58EOF

Dans notre application, la fonction Lambda est actuellement conçue pour placer des images de chiens dans un bucket S3. Elle dispose des autorisations nécessaires, mais aussi d’autres actions comme Put, Get, Delete, Create et List. Et de nombreuses autres actions si l’on tient compte de tous les autres services, en plus de S3.

Cela s’explique par le contenu des lignes 52 à 54. En pratique, nous autorisons toutes les actions sur toutes les ressources. Cela revient à accorder des autorisations d’administration.

C’est beaucoup trop permissif. La seule action qui devrait être autorisée ici est « put » : toute autre action est excessive et pourrait entraîner une fuite ou une corruption de données, ou servir à repérer nos ressources.

Si vous maîtrisez bien Terraform et AWS IAM et que vous n’avez qu’à examiner cette configuration, le problème peut être facile à repérer. Mais, en général, les configurations Terraform sont bien plus volumineuses et il est difficile de suivre tous les détails de configuration. Un développeur ou un membre de l’équipe de sécurité risque donc de ne pas repérer cette policy dangereuse, enfouie au cœur d’un ensemble de modules Terraform.  

Heureusement, de nouveaux outils facilitent considérablement la détection et la correction de ces problèmes, et permettent de répartir les responsabilités en matière de sécurité entre toutes les équipes d’ingénierie qui utilisent l’IaC.

Détecter les configurations non sécurisées

Snyk Infrastructure as Code (IaC) est un outil de test IaC qui analyse les configurations Terraform, Kubernetes et AWS CloudFormation et détecte les policies risquées dans les services AWS, Azure et GCP. Il peut s’agir d’un simple astérisque qui rend une policy beaucoup trop permissive, comme dans notre exemple ci-dessus. Ou encore d’une autorisation « write » là où seul un accès « read » devrait être accordé.

Grâce aux tests statiques continus et automatisés, Snyk IaC peut analyser Terraform à grande échelle et aider les organisations à gérer leur infrastructure as code. Si l’analyse détecte une configuration risquée, Snyk guide l’ingénieur vers une correction. Mieux encore, Solvo peut être utilisé avec Snyk IaC pour générer automatiquement une policy sécurisée qui réduit le risque d’exposition.

Voyons comment cela fonctionne en pratique.

Pour lancer l’analyse, nous pouvons utiliser la CLI Snyk et exécuter snyk iac test sur notre configuration :

L’analyse a détecté une erreur de configuration dans la policy : le caractère « * » est beaucoup trop permissif, car il autorise toutes les actions.

Snyk IaC fournit des informations sur les risques potentiels liés à cette configuration ainsi que des conseils généraux pour corriger le problème. Solvo va plus loin en générant automatiquement une configuration IAM qui applique le principe du moindre privilège dans votre environnement. En les utilisant ensemble, vous détectez et corrigez les problèmes au fur et à mesure que vous codez, afin d’apporter rapidement les corrections nécessaires et de sécuriser votre code avant le déploiement.

Nous voyons maintenant que notre policy autorise uniquement « PutObject » : nos photos de chiens sont donc à l’abri.

Une fois la politique appliquée par Solvo, nous analysons à nouveau le fichier Terraform. Snyk IaC nous confirme que toutes les autorisations d’administration ont disparu :

Associer des intégrations pour une couverture plus large

Grâce aux analyses Snyk IaC, les organisations peuvent détecter et corriger de manière proactive les policies risquées dans leur infrastructure as code, qu’il s’agisse de Terraform, Kubernetes ou CloudFormation. Utilisé avec Solvo, Snyk IaC permet de remplacer les policies risquées par des policies sécurisées. Les organisations peuvent ainsi corriger rapidement les erreurs de configuration et renforcer leur sécurité sans avoir à mobiliser des ressources ou une expertise supplémentaires. 

Pour en savoir plus sur la manière dont Solvo peut contribuer à réduire automatiquement les risques liés à votre infrastructure cloud, consultez le site de Solvo pour commencer ou demander une démo gratuite. Si vous n’avez pas encore essayé Snyk IaC, vous pouvez commencer à l’utiliser gratuitement.

David Hendri est cofondateur et directeur technique (CTO) de Solvo

Lauren Place est responsable marketing produit chez Snyk