Como proteger a configuração e o acesso a buckets S3 com Snyk e Solvo

Solvo capacita desenvolvedores e engenheiros de DevOps a executar a infraestrutura em nuvem com acesso de privilégio mínimo, em alta velocidade e escala. Neste artigo, vamos apresentar um fluxo de trabalho que combina a plataforma automatizada da Solvo com Snyk Infrastructure as Code (Snyk IaC) para criar um acesso personalizado e seguro de uma função Lambda a um bucket AWS S3. Este artigo foi publicado originalmente no site da Solvo.

Cada vez mais, as organizações estão adotando o modelo de infraestrutura como código para gerenciar as configurações dos recursos em nuvem.

Configurar a infraestrutura por meio de código permite ter mais controle de versão e do código-fonte, facilitando o acompanhamento e a replicação das condições de um ambiente para outro. Essa abordagem é especialmente útil para criar buckets AWS S3, que podem ser usados para armazenar código ou outros dados importantes. Como recurso de nuvem, esses buckets S3 podem ser facilmente compartilhados com o restante da equipe.

Mas, às vezes, esses buckets S3 acabam sendo _compartilhados demais_. Na correria, escrever uma política IAM segura para um recurso de nuvem (S3, Lambda, EC2 ou qualquer outro) costuma ser a última preocupação dos desenvolvedores. Para ganhar velocidade e conveniência, não é raro um desenvolvedor configurar o bucket incorretamente, com políticas de segurança permissivas demais, colocando o conteúdo em risco de exposição.

Vamos conhecer alguns riscos de segurança relacionados a políticas e ver como evitá-los.

Exemplo de uma função Lambda configurada incorretamente

A seguir, temos uma configuração do Terraform que cria uma função AWS Lambda para armazenar uma imagem em um bucket S3. Também é possível ver o código da função IAM e da política de segurança.

O que podemos deduzir dessa configuração sobre o conteúdo e o nível de segurança?

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

No nosso aplicativo, a função Lambda foi escrita para armazenar imagens de cães em um bucket S3. Ela tem permissão para fazer isso, além de executar outras ações, como Put, Get, Delete, Create e List. E muitas outras, se considerarmos todos os demais serviços além do S3.

Isso aconteceu por causa do que está escrito nas linhas 52 a 54. Na prática, estamos PERMITINDO todas as ações em todos os recursos. Isso equivale a permissões administrativas.

Essa política é permissiva demais. A única ação que deveria ser permitida aqui é “put”, pois qualquer outra é excessiva e pode levar ao vazamento ou à corrupção de dados, ou ser usada para fazer reconhecimento dos nossos recursos.

Se você conhece bem o Terraform e o AWS IAM e só precisasse revisar essa configuração, talvez fosse fácil identificar o problema. Mas, em geral, há muito mais configurações do Terraform, e é difícil acompanhar todos os detalhes. Assim, é pouco provável que um desenvolvedor ou membro da equipe de segurança encontre essa política arriscada, escondida em meio a um conjunto de módulos do Terraform.

Felizmente, há novas ferramentas que facilitam muito a identificação e a correção desses problemas, além de ajudar a distribuir as responsabilidades de segurança entre todas as equipes de engenharia que usam IaC.

Como detectar configurações inseguras

Snyk Infrastructure as Code (IaC) é uma ferramenta de teste de IaC capaz de analisar configurações de Terraform, Kubernetes e AWS CloudFormation e identificar políticas arriscadas em serviços da AWS, do Azure e do GCP. O problema pode ser algo tão simples quanto um asterisco, que torna a política permissiva demais, como no exemplo acima. Ou pode ser uma permissão de “gravação” onde deveria haver apenas “leitura”, por exemplo.

Com testes estáticos contínuos e automatizados, o Snyk IaC consegue analisar o Terraform em escala, ajudando as organizações a gerenciar a infraestrutura como código. Se a análise encontrar uma configuração arriscada, a Snyk orientará a pessoa desenvolvedora na correção. Melhor ainda: você pode usar o Solvo com o Snyk IaC para gerar automaticamente uma política segura que reduza a exposição a riscos.

Vamos ver como isso funciona na prática.

Para executar a análise, podemos usar a CLI da Snyk e rodar um snyk iac test na nossa configuração:

A análise encontrou uma configuração incorreta na política, que usa “*” e é permissiva demais, pois permite tudo.

Snyk IaC informa os possíveis riscos dessa configuração e dá orientações gerais para corrigir o problema. O Solvo vai além e gera automaticamente uma configuração IAM específica para o seu ambiente, com o mínimo de privilégios. Juntos, eles ajudam você a encontrar e corrigir problemas enquanto escreve o código, fazer rapidamente os ajustes necessários e garantir a segurança antes da implantação.

Agora, vemos que nossa política permite apenas “PutObject”, então nossas fotos de cães estão protegidas.

Depois que o Solvo aplicou a política, analisamos o arquivo Terraform novamente, e o Snyk IaC mostra que todas as permissões administrativas foram removidas:

Combine integrações para ampliar a cobertura

Com as análises do Snyk IaC, as organizações podem identificar e corrigir proativamente políticas arriscadas na infraestrutura como código, seja em Terraform, Kubernetes ou CloudFormation. Quando usado com o Solvo, ele pode substituir as políticas arriscadas por políticas seguras e ajudar as organizações a corrigir rapidamente configurações incorretas e aumentar a segurança, sem precisar contratar mais profissionais ou buscar novos conhecimentos especializados.

Para saber mais sobre como o Solvo pode ajudar a reduzir automaticamente os riscos da sua infraestrutura em nuvem, acesse o site da Solvo para começar ou solicitar uma demonstração gratuita. Se você ainda não experimentou o Snyk IaC, pode começar a usar gratuitamente.

David Hendri é cofundador e CTO da Solvo

Lauren Place é gerente de marketing de produto da Snyk