Protege la configuración y el acceso a los buckets de S3 con Snyk y Solvo

Solvo empodera a los desarrolladores y a los ingenieros de DevOps al permitirles ejecutar su infraestructura en la nube con acceso de privilegio mínimo, a gran velocidad y escala. En este artículo, veremos un flujo de trabajo que combina la plataforma automatizada de Solvo con Snyk Infrastructure as Code (Snyk IaC) para crear un acceso personalizado y seguro desde una función Lambda a un bucket de AWS S3. Esta publicación se publicó originalmente en el sitio web de Solvo.

Cada vez más organizaciones están adoptando el modelo de infraestructura como código para administrar las configuraciones de sus recursos en la nube.

Configurar tu infraestructura mediante código te permite tener un mejor control de versiones y del código fuente, lo que facilita el seguimiento y la replicación de las condiciones de un entorno a otro. Este enfoque es especialmente útil para crear buckets de AWS S3, que pueden servir para almacenar tu código u otros datos útiles. Como recursos en la nube, estos buckets de S3 se pueden compartir fácilmente con el resto del equipo.

Pero a veces, estos buckets de S3 se vuelven _demasiado_ fáciles de compartir. Cuando se trabaja con rapidez, escribir una política de IAM segura para un recurso de la nube (S3, Lambda, EC2 u otro) suele ser lo último en lo que piensan los desarrolladores. Por priorizar la velocidad y la comodidad, no es raro que un desarrollador configure mal el bucket con políticas de seguridad demasiado permisivas, que pueden poner su contenido en riesgo de exposición.

Veamos algunos riesgos de seguridad basados en políticas y cómo podemos evitarlos.

Ejemplo de una función Lambda mal configurada

A continuación, tenemos una configuración de Terraform que crea una función AWS Lambda que coloca una imagen en un bucket de S3. Aquí también puedes ver el código del rol de IAM y la política de seguridad.

¿Qué detalles de esta configuración podemos identificar que nos indiquen algo sobre su contenido y nivel de seguridad?

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

En nuestra aplicación, la función Lambda está programada para colocar imágenes de perros en un bucket de S3. Tiene permiso para hacerlo, además de realizar otras acciones como Put, Get, Delete, Create y List. Y muchas más si tenemos en cuenta todos los demás servicios, además de S3.

Esto se debe a lo que está escrito en las líneas 52-54. En la práctica, estamos PERMITIENDO todas las acciones en todos los recursos. Esto equivale a permisos de administrador.

Esto es demasiado permisivo. El único tipo de acción que debería permitirse aquí es “put”, ya que cualquier otra es excesiva y podría provocar una filtración o corrupción de datos, o usarse para reconocer nuestros recursos.

Si conoces bien Terraform y AWS IAM y solo tienes que revisar esta configuración, quizá sea fácil detectar el problema. Pero, en general, hay mucha más configuración de Terraform y es difícil mantenerse al día con sus detalles. Por eso, es poco probable que un desarrollador o integrante del equipo de seguridad encuentre esta política riesgosa oculta en lo profundo de un conjunto de módulos de Terraform.  

Por suerte, ahora hay nuevas herramientas que facilitan mucho más la tarea de encontrar y corregir estos problemas, y permiten distribuir las responsabilidades de seguridad entre todos los equipos de ingeniería que usan IaC.

Analiza las configuraciones inseguras

Snyk Infrastructure as Code (IaC) es una herramienta de pruebas de IaC que puede analizar configuraciones de Terraform, Kubernetes y AWS CloudFormation, e identificar políticas riesgosas en servicios de AWS, Azure y GCP. Puede tratarse de algo tan sencillo como un asterisco que hace que la política sea demasiado permisiva, como en el ejemplo anterior. O quizá de un permiso de “escritura” cuando solo debería haber uno de “lectura”.

Gracias a las pruebas estáticas, continuas y automatizadas, Snyk IaC puede analizar Terraform a una escala que permite a las organizaciones administrar su infraestructura como código de forma eficaz. Si el análisis detecta una configuración riesgosa, Snyk guiará al ingeniero para corregirla. Y, mejor aún, puedes usar Solvo con Snyk IaC para generar automáticamente una política segura que mitigue la posible exposición.

Veamos cómo funciona en la práctica.

Para ejecutar el análisis, podemos usar la CLI de Snyk y ejecutar snyk iac test en nuestra configuración:

El análisis detectó una configuración incorrecta en la política, que usa un “*” demasiado permisivo porque permite todo.

Snyk IaC proporciona información sobre el posible riesgo de esta configuración y consejos generales para corregir el problema. Solvo va un paso más allá y genera automáticamente una configuración de IAM con los privilegios mínimos, específica para tu entorno. Al usarlos juntos, puedes encontrar y corregir los problemas a medida que programas, hacer rápidamente los cambios necesarios y asegurarte de que todo sea seguro antes del despliegue.

Ahora vemos que nuestra política solo permite “PutObject”, así que nuestras fotos de perros están a salvo

Una vez que Solvo aplicó la política, volvemos a analizar el archivo de Terraform y Snyk IaC nos muestra que ya no quedan permisos administrativos:

Combina integraciones para ampliar la cobertura

Al aprovechar los análisis de Snyk IaC, las organizaciones pueden identificar y corregir de forma proactiva políticas riesgosas en su infraestructura como código, ya sea en Terraform, Kubernetes o CloudFormation. Al combinarlo con Solvo, Solvo puede generar políticas seguras para reemplazar las riesgosas y ayudar a las organizaciones a corregir rápidamente las configuraciones incorrectas y mejorar la seguridad sin necesidad de sumar recursos ni experiencia especializada. 

Para obtener más información sobre cómo Solvo puede ayudar a reducir automáticamente el riesgo de tu infraestructura en la nube, visita el sitio web de Solvo para comenzar o solicitar una demostración gratuita. Si aún no probaste Snyk IaC, puedes comenzar a usarlo gratis.

David Hendri es cofundador y director de tecnología (CTO) de Solvo

Lauren Place es gerente de marketing de producto en Snyk