# Seguridad de Serverless.com {{#include ../banners/hacktricks-training.md}} ## Información Básica ### Organización Una **Organización** es la entidad de más alto nivel dentro del ecosistema de Serverless Framework. Representa un **grupo colectivo**, como una empresa, departamento o cualquier entidad grande, que abarca múltiples proyectos, equipos y aplicaciones. ### Equipo El **Equipo** son los usuarios con acceso dentro de la organización. Los equipos ayudan a organizar a los miembros según roles. **`Colaboradores`** pueden ver y desplegar aplicaciones existentes, mientras que **`Administradores`** pueden crear nuevas aplicaciones y gestionar la configuración de la organización. ### Aplicación Una **Aplicación** es un agrupamiento lógico de servicios relacionados dentro de una Organización. Representa una aplicación completa compuesta de múltiples servicios serverless que trabajan juntos para proporcionar una funcionalidad cohesiva. ### **Servicios** Un **Servicio** es el componente central de una aplicación Serverless. Representa tu proyecto serverless completo, encapsulando todas las funciones, configuraciones y recursos necesarios. Se define típicamente en un archivo `serverless.yml`, un servicio incluye metadatos como el nombre del servicio, configuraciones del proveedor, funciones, eventos, recursos, plugins y variables personalizadas. ```yaml service: my-service provider: name: aws runtime: nodejs14.x functions: hello: handler: handler.hello ```
Función Una **Función** representa una única función serverless, como una función AWS Lambda. Contiene el código que se ejecuta en respuesta a eventos. Se define en la sección `functions` en `serverless.yml`, especificando el controlador, el entorno de ejecución, los eventos, las variables de entorno y otras configuraciones. ```yaml functions: hello: handler: handler.hello events: - http: path: hello method: get ```
Evento **Eventos** son disparadores que invocan tus funciones sin servidor. Definen cómo y cuándo se debe ejecutar una función. Los tipos de eventos comunes incluyen solicitudes HTTP, eventos programados (trabajos cron), eventos de base de datos, cargas de archivos y más. ```yaml functions: hello: handler: handler.hello events: - http: path: hello method: get - schedule: rate: rate(10 minutes) ```
Recurso **Recursos** te permiten definir recursos adicionales en la nube de los que depende tu servicio, como bases de datos, buckets de almacenamiento o roles de IAM. Se especifican en la sección `resources`, a menudo utilizando la sintaxis de CloudFormation para AWS. ```yaml resources: Resources: MyDynamoDBTable: Type: AWS::DynamoDB::Table Properties: TableName: my-table AttributeDefinitions: - AttributeName: id AttributeType: S KeySchema: - AttributeName: id KeyType: HASH ProvisionedThroughput: ReadCapacityUnits: 1 WriteCapacityUnits: 1 ```
Proveedor El objeto **Proveedor** especifica el proveedor de servicios en la nube (por ejemplo, AWS, Azure, Google Cloud) y contiene configuraciones relevantes para ese proveedor. Incluye detalles como el tiempo de ejecución, la región, la etapa y las credenciales. ```yaml yamlCopy codeprovider: name: aws runtime: nodejs14.x region: us-east-1 stage: dev ```
Etapa y Región La etapa representa diferentes entornos (por ejemplo, desarrollo, preproducción, producción) donde tu servicio puede ser desplegado. Permite configuraciones y despliegues específicos del entorno. ```yaml provider: stage: dev ``` La región especifica la región geográfica donde se desplegarán tus recursos. Es importante para consideraciones de latencia, cumplimiento y disponibilidad. ```yaml provider: region: us-west-2 ```
Plugins **Plugins** extienden la funcionalidad del Serverless Framework al agregar nuevas características o integrarse con otras herramientas y servicios. Se definen en la sección `plugins` y se instalan a través de npm. ```yaml plugins: - serverless-offline - serverless-webpack ```
Capas **Capas** te permiten empaquetar y gestionar código compartido o dependencias por separado de tus funciones. Esto promueve la reutilización y reduce el tamaño de los paquetes de implementación. Se definen en la sección `layers` y son referenciadas por las funciones. ```yaml layers: commonLibs: path: layer-common functions: hello: handler: handler.hello layers: - { Ref: CommonLibsLambdaLayer } ```
Variables y Variables Personalizadas **Variables** permiten la configuración dinámica al permitir el uso de marcadores de posición que se resuelven en el momento de la implementación. - **Sintaxis:** La sintaxis `${variable}` puede hacer referencia a variables de entorno, contenidos de archivos u otros parámetros de configuración. ```yaml functions: hello: handler: handler.hello environment: TABLE_NAME: ${self:custom.tableName} ``` * **Variables Personalizadas:** La sección `custom` se utiliza para definir variables y configuraciones específicas del usuario que pueden ser reutilizadas en todo el `serverless.yml`. ```yaml custom: tableName: my-dynamodb-table stage: ${opt:stage, 'dev'} ```
Salidas **Salidas** definen los valores que se devuelven después de que un servicio es implementado, como ARNs de recursos, puntos finales u otra información útil. Se especifican en la sección `outputs` y a menudo se utilizan para exponer información a otros servicios o para un fácil acceso después de la implementación. ```yaml ¡outputs: ApiEndpoint: Description: "API Gateway endpoint URL" Value: Fn::Join: - "" - - "https://" - Ref: ApiGatewayRestApi - ".execute-api." - Ref: AWS::Region - ".amazonaws.com/" - Ref: AWS::Stage ```
Roles y Permisos de IAM **Roles y Permisos de IAM** definen las credenciales de seguridad y los derechos de acceso para tus funciones y otros recursos. Se gestionan bajo la configuración del `provider` o de funciones individuales para especificar los permisos necesarios. ```yaml provider: [...] iam: role: statements: - Effect: 'Allow' Action: - 'dynamodb:PutItem' - 'dynamodb:Get*' - 'dynamodb:Scan*' - 'dynamodb:UpdateItem' - 'dynamodb:DeleteItem' Resource: arn:aws:dynamodb:${aws:region}:${aws:accountId}:table/${self:service}-customerTable-${sls:stage} ```
Variables de Entorno **Variables** te permiten pasar configuraciones y secretos a tus funciones sin codificarlos de forma rígida. Se definen en la sección `environment` para el proveedor o funciones individuales. ```yaml provider: environment: STAGE: ${self:provider.stage} functions: hello: handler: handler.hello environment: TABLE_NAME: ${self:custom.tableName} ```
Dependencias **Dependencias** gestionan las bibliotecas y módulos externos que requieren tus funciones. Generalmente se manejan a través de administradores de paquetes como npm o pip, y se empaquetan con tu paquete de despliegue utilizando herramientas o complementos como `serverless-webpack`. ```yaml plugins: - serverless-webpack ```
Hooks **Hooks** te permiten ejecutar scripts o comandos personalizados en puntos específicos del ciclo de vida de despliegue. Se definen utilizando plugins o dentro del `serverless.yml` para realizar acciones antes o después de los despliegues. ```yaml custom: hooks: before:deploy:deploy: echo "Starting deployment..." ```
### Tutorial Este es un resumen del tutorial oficial [**de la documentación**](https://www.serverless.com/framework/docs/tutorial): 1. Crea una cuenta de AWS (Serverless.com comienza en la infraestructura de AWS) 2. Crea una cuenta en serverless.com 3. Crea una aplicación: ```bash # Create temp folder for the tutorial mkdir /tmp/serverless-tutorial cd /tmp/serverless-tutorial # Install Serverless cli npm install -g serverless # Generate template serverless #Choose first one (AWS / Node.js / HTTP API) ## Indicate a name like "Tutorial" ## Login/Register ## Create A New App ## Indicate a name like "tutorialapp) ``` Esto debería haber creado una **app** llamada `tutorialapp` que puedes verificar en [serverless.com](serverless.com-security.md) y una carpeta llamada `Tutorial` con el archivo **`handler.js`** que contiene algo de código JS con un código `helloworld` y el archivo **`serverless.yml`** declarando esa función: {{#tabs }} {{#tab name="handler.js" }} ```javascript exports.hello = async (event) => { return { statusCode: 200, body: JSON.stringify({ message: "Go Serverless v4! Your function executed successfully!", }), } } ``` {{#endtab }} {{#tab name="serverless.yml" }} ```yaml # "org" ensures this Service is used with the correct Serverless Framework Access Key. org: testing12342 # "app" enables Serverless Framework Dashboard features and sharing them with other Services. app: tutorialapp # "service" is the name of this project. This will also be added to your AWS resource names. service: Tutorial provider: name: aws runtime: nodejs20.x functions: hello: handler: handler.hello events: - httpApi: path: / method: get ``` {{#endtab }} {{#endtabs }} 4. Crea un proveedor de AWS, yendo al **dashboard** en `https://app.serverless.com//settings/providers?providerId=new&provider=aws`. 1. Para dar acceso a `serverless.com` a AWS, pedirá ejecutar una pila de cloudformation usando este archivo de configuración (en el momento de escribir esto): [https://serverless-framework-template.s3.amazonaws.com/roleTemplate.yml](https://serverless-framework-template.s3.amazonaws.com/roleTemplate.yml) 2. Esta plantilla genera un rol llamado **`SFRole-`** con **`arn:aws:iam::aws:policy/AdministratorAccess`** sobre la cuenta con una Identidad de Confianza que permite que la cuenta de AWS de `Serverless.com` acceda al rol.
Yaml roleTemplate ```yaml Description: This stack creates an IAM role that can be used by Serverless Framework for use in deployments. Resources: SFRole: Type: AWS::IAM::Role Properties: AssumeRolePolicyDocument: Version: "2012-10-17" Statement: - Effect: Allow Principal: AWS: arn:aws:iam::486128539022:root Action: - sts:AssumeRole Condition: StringEquals: sts:ExternalId: !Sub "ServerlessFramework-${OrgUid}" Path: / RoleName: !Ref RoleName ManagedPolicyArns: - arn:aws:iam::aws:policy/AdministratorAccess ReporterFunction: Type: Custom::ServerlessFrameworkReporter Properties: ServiceToken: "arn:aws:lambda:us-east-1:486128539022:function:sp-providers-stack-reporter-custom-resource-prod-tmen2ec" OrgUid: !Ref OrgUid RoleArn: !GetAtt SFRole.Arn Alias: !Ref Alias Outputs: SFRoleArn: Description: "ARN for the IAM Role used by Serverless Framework" Value: !GetAtt SFRole.Arn Parameters: OrgUid: Description: Serverless Framework Org Uid Type: String Alias: Description: Serverless Framework Provider Alias Type: String RoleName: Description: Serverless Framework Role Name Type: String ```
Relación de Confianza ```json { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "AWS": "arn:aws:iam::486128539022:root" }, "Action": "sts:AssumeRole", "Condition": { "StringEquals": { "sts:ExternalId": "ServerlessFramework-7bf7ddef-e1bf-43eb-a111-4d43e0894ccb" } } } ] } ```
5. El tutorial pide crear el archivo `createCustomer.js`, que básicamente creará un nuevo endpoint de API manejado por el nuevo archivo JS y pide modificar el archivo `serverless.yml` para que genere una **nueva tabla DynamoDB**, defina una **variable de entorno**, el rol que estará utilizando las lambdas generadas. {{#tabs }} {{#tab name="createCustomer.js" }} ```javascript "use strict" const AWS = require("aws-sdk") module.exports.createCustomer = async (event) => { const body = JSON.parse(Buffer.from(event.body, "base64").toString()) const dynamoDb = new AWS.DynamoDB.DocumentClient() const putParams = { TableName: process.env.DYNAMODB_CUSTOMER_TABLE, Item: { primary_key: body.name, email: body.email, }, } await dynamoDb.put(putParams).promise() return { statusCode: 201, } } ``` {{#endtab }} {{#tab name="serverless.yml" }} ```yaml # "org" ensures this Service is used with the correct Serverless Framework Access Key. org: testing12342 # "app" enables Serverless Framework Dashboard features and sharing them with other Services. app: tutorialapp # "service" is the name of this project. This will also be added to your AWS resource names. service: Tutorial provider: name: aws runtime: nodejs20.x environment: DYNAMODB_CUSTOMER_TABLE: ${self:service}-customerTable-${sls:stage} iam: role: statements: - Effect: "Allow" Action: - "dynamodb:PutItem" - "dynamodb:Get*" - "dynamodb:Scan*" - "dynamodb:UpdateItem" - "dynamodb:DeleteItem" Resource: arn:aws:dynamodb:${aws:region}:${aws:accountId}:table/${self:service}-customerTable-${sls:stage} functions: hello: handler: handler.hello events: - httpApi: path: / method: get createCustomer: handler: createCustomer.createCustomer events: - httpApi: path: / method: post resources: Resources: CustomerTable: Type: AWS::DynamoDB::Table Properties: AttributeDefinitions: - AttributeName: primary_key AttributeType: S BillingMode: PAY_PER_REQUEST KeySchema: - AttributeName: primary_key KeyType: HASH TableName: ${self:service}-customerTable-${sls:stage} ``` {{#endtab }} {{#endtabs }} 6. Despliegue ejecutando **`serverless deploy`** 1. El despliegue se realizará a través de un CloudFormation Stack 2. Tenga en cuenta que las **lambdas están expuestas a través de API gateway** y no a través de URLs directas 7. **Pruébelo** 1. El paso anterior imprimirá las **URLs** donde se han desplegado las funciones lambda de sus puntos finales de API ## Revisión de Seguridad de Serverless.com ### **Roles y Permisos IAM Mal Configurados** Los roles IAM excesivamente permisivos pueden otorgar acceso no autorizado a recursos en la nube, lo que lleva a filtraciones de datos o manipulación de recursos. Cuando no se especifican permisos para una función Lambda, se creará un rol con permisos solo para generar registros, como:
Permisos mínimos de lambda ```json { "Version": "2012-10-17", "Statement": [ { "Action": [ "logs:CreateLogStream", "logs:CreateLogGroup", "logs:TagResource" ], "Resource": [ "arn:aws:logs:us-east-1:123456789012:log-group:/aws/lambda/jito-cranker-scripts-dev*:*" ], "Effect": "Allow" }, { "Action": ["logs:PutLogEvents"], "Resource": [ "arn:aws:logs:us-east-1:123456789012:log-group:/aws/lambda/jito-cranker-scripts-dev*:*:*" ], "Effect": "Allow" } ] } ```
#### **Estrategias de Mitigación** - **Principio de Menor Privilegio:** Asignar solo los permisos necesarios a cada función. ```yaml provider: [...] iam: role: statements: - Effect: 'Allow' Action: - 'dynamodb:PutItem' - 'dynamodb:Get*' - 'dynamodb:Scan*' - 'dynamodb:UpdateItem' - 'dynamodb:DeleteItem' Resource: arn:aws:dynamodb:${aws:region}:${aws:accountId}:table/${self:service}-customerTable-${sls:stage} ``` - **Usar Roles Separados:** Diferenciar roles según los requisitos de la función. --- ### **Secretos Inseguros y Gestión de Configuración** Almacenar información sensible (por ejemplo, claves API, credenciales de base de datos) directamente en **`serverless.yml`** o en el código puede llevar a la exposición si los repositorios son comprometidos. La **manera recomendada** de almacenar variables de entorno en el archivo **`serverless.yml`** de serverless.com (en el momento de escribir esto) es usar los proveedores `ssm` o `s3`, que permiten obtener los **valores de entorno de estas fuentes en el momento de la implementación** y **configurar** las **variables de entorno de las lambdas** con el **texto claro de los valores**! > [!CAUTION] > Por lo tanto, cualquier persona con permisos para leer la configuración de las lambdas dentro de AWS podrá **acceder a todas estas variables de entorno en texto claro!** Por ejemplo, el siguiente ejemplo usará SSM para obtener una variable de entorno: ```yaml provider: environment: DB_PASSWORD: ${ssm:/aws/reference/secretsmanager/my-db-password~true} ``` Y incluso si esto previene la codificación dura del valor de la variable de entorno en el **`serverless.yml`**, el valor se obtendrá en el momento de la implementación y se **agregará en texto claro dentro de la variable de entorno de lambda**. > [!TIP] > La forma recomendada de almacenar variables de entorno usando serveless.com sería **almacenarla en un secreto de AWS** y solo almacenar el nombre del secreto en la variable de entorno y el **código de lambda debería recogerlo**. #### **Estrategias de Mitigación** - **Integración con Secrets Manager:** Utilizar servicios como **AWS Secrets Manager.** - **Variables Encriptadas:** Aprovechar las características de encriptación del Serverless Framework para datos sensibles. - **Controles de Acceso:** Restringir el acceso a secretos según roles. --- ### **Código y Dependencias Vulnerables** Dependencias desactualizadas o inseguras pueden introducir vulnerabilidades, mientras que un manejo inadecuado de entradas puede llevar a ataques de inyección de código. #### **Estrategias de Mitigación** - **Gestión de Dependencias:** Actualizar regularmente las dependencias y escanear en busca de vulnerabilidades. ```yaml plugins: - serverless-webpack - serverless-plugin-snyk ``` - **Validación de Entradas:** Implementar una validación y sanitización estrictas de todas las entradas. - **Revisiones de Código:** Realizar revisiones exhaustivas para identificar fallas de seguridad. - **Análisis Estático:** Utilizar herramientas para detectar vulnerabilidades en la base de código. --- ### **Registro y Monitoreo Inadecuados** Sin un registro y monitoreo adecuados, las actividades maliciosas pueden pasar desapercibidas, retrasando la respuesta a incidentes. #### **Estrategias de Mitigación** - **Registro Centralizado:** Agregar registros utilizando servicios como **AWS CloudWatch** o **Datadog**. ```yaml plugins: - serverless-plugin-datadog ``` - **Habilitar Registro Detallado:** Capturar información esencial sin exponer datos sensibles. - **Configurar Alertas:** Configurar alertas para actividades sospechosas o anomalías. - **Monitoreo Regular:** Monitorear continuamente registros y métricas en busca de posibles incidentes de seguridad. --- ### **Configuraciones Inseguras de API Gateway** APIs abiertas o mal aseguradas pueden ser explotadas para acceso no autorizado, ataques de Denegación de Servicio (DoS) o ataques entre sitios. #### **Estrategias de Mitigación** - **Autenticación y Autorización:** Implementar mecanismos robustos como OAuth, claves API o JWT. ```yaml functions: hello: handler: handler.hello events: - http: path: hello method: get authorizer: aws_iam ``` - **Limitación de Tasa y Regulación:** Prevenir abusos limitando las tasas de solicitud. ```yaml provider: apiGateway: throttle: burstLimit: 200 rateLimit: 100 ``` - **Configuración Segura de CORS:** Restringir orígenes, métodos y encabezados permitidos. ```yaml functions: hello: handler: handler.hello events: - http: path: hello method: get cors: origin: https://yourdomain.com headers: - Content-Type ``` - **Usar Firewalls de Aplicaciones Web (WAF):** Filtrar y monitorear solicitudes HTTP en busca de patrones maliciosos. --- ### **Aislamiento Insuficiente de Funciones** Recursos compartidos y un aislamiento inadecuado pueden llevar a escalaciones de privilegios o interacciones no deseadas entre funciones. #### **Estrategias de Mitigación** - **Aislar Funciones:** Asignar recursos y roles de IAM distintos para asegurar una operación independiente. - **Particionamiento de Recursos:** Utilizar bases de datos o buckets de almacenamiento separados para diferentes funciones. - **Usar VPCs:** Desplegar funciones dentro de Nubes Privadas Virtuales para un mejor aislamiento de red. ```yaml provider: vpc: securityGroupIds: - sg-xxxxxxxx subnetIds: - subnet-xxxxxx ``` - **Limitar Permisos de Funciones:** Asegurarse de que las funciones no puedan acceder o interferir con los recursos de otras funciones a menos que sea explícitamente necesario. --- ### **Protección de Datos Inadecuada** Datos no encriptados en reposo o en tránsito pueden ser expuestos, llevando a brechas de datos o manipulación. #### **Estrategias de Mitigación** - **Encriptar Datos en Reposo:** Utilizar características de encriptación de servicios en la nube. ```yaml resources: Resources: MyDynamoDBTable: Type: AWS::DynamoDB::Table Properties: SSESpecification: SSEEnabled: true ``` - **Encriptar Datos en Tránsito:** Usar HTTPS/TLS para todas las transmisiones de datos. - **Comunicación API Segura:** Hacer cumplir protocolos de encriptación y validar certificados. - **Gestionar Claves de Encriptación de Forma Segura:** Utilizar servicios de claves gestionadas y rotar claves regularmente. --- ### **Falta de Manejo Adecuado de Errores** Mensajes de error detallados pueden filtrar información sensible sobre la infraestructura o la base de código, mientras que excepciones no manejadas pueden llevar a caídas de la aplicación. #### **Estrategias de Mitigación** - **Mensajes de Error Genéricos:** Evitar exponer detalles internos en las respuestas de error. ```javascript javascriptCopy code// Ejemplo en Node.js exports.hello = async (event) => { try { // Lógica de la función } catch (error) { console.error(error); return { statusCode: 500, body: JSON.stringify({ message: 'Error Interno del Servidor' }), }; } }; ``` - **Manejo Centralizado de Errores:** Gestionar y sanitizar errores de manera consistente en todas las funciones. - **Monitorear y Registrar Errores:** Rastrear y analizar errores internamente sin exponer detalles a los usuarios finales. --- ### **Prácticas de Despliegue Inseguras** Configuraciones de despliegue expuestas o acceso no autorizado a pipelines de CI/CD pueden llevar a despliegues de código malicioso o configuraciones incorrectas. #### **Estrategias de Mitigación** - **Asegurar Pipelines de CI/CD:** Implementar controles de acceso estrictos, autenticación multifactor (MFA) y auditorías regulares. - **Almacenar Configuración de Forma Segura:** Mantener archivos de despliegue libres de secretos codificados y datos sensibles. - **Usar Herramientas de Seguridad de Infraestructura como Código (IaC):** Emplear herramientas como **Checkov** o **Terraform Sentinel** para hacer cumplir políticas de seguridad. - **Despliegues Inmutables:** Prevenir cambios no autorizados después del despliegue adoptando prácticas de infraestructura inmutable. --- ### **Vulnerabilidades en Plugins y Extensiones** Usar plugins de terceros no verificados o maliciosos puede introducir vulnerabilidades en sus aplicaciones serverless. #### **Estrategias de Mitigación** - **Evaluar Plugins a Fondo:** Evaluar la seguridad de los plugins antes de la integración, favoreciendo aquellos de fuentes reputadas. - **Limitar el Uso de Plugins:** Usar solo los plugins necesarios para minimizar la superficie de ataque. - **Monitorear Actualizaciones de Plugins:** Mantener los plugins actualizados para beneficiarse de parches de seguridad. - **Aislar Entornos de Plugins:** Ejecutar plugins en entornos aislados para contener posibles compromisos. --- ### **Exposición de Puntos Finales Sensibles** Funciones accesibles públicamente o APIs sin restricciones pueden ser explotadas para operaciones no autorizadas. #### **Estrategias de Mitigación** - **Restringir el Acceso a Funciones:** Usar VPCs, grupos de seguridad y reglas de firewall para limitar el acceso a fuentes confiables. - **Implementar Autenticación Robusta:** Asegurarse de que todos los puntos finales expuestos requieran autenticación y autorización adecuadas. - **Usar API Gateways de Forma Segura:** Configurar API Gateways para hacer cumplir políticas de seguridad, incluyendo validación de entradas y limitación de tasa. - **Deshabilitar Puntos Finales No Utilizados:** Revisar regularmente y deshabilitar cualquier punto final que ya no esté en uso. --- ### **Permisos Excesivos para Miembros del Equipo y Colaboradores Externos** Conceder permisos excesivos a miembros del equipo y colaboradores externos puede llevar a acceso no autorizado, brechas de datos y uso indebido de recursos. Este riesgo se agrava en entornos donde múltiples individuos tienen diferentes niveles de acceso, aumentando la superficie de ataque y el potencial de amenazas internas. #### **Estrategias de Mitigación** - **Principio de Menor Privilegio:** Asegurarse de que los miembros del equipo y colaboradores tengan solo los permisos necesarios para realizar sus tareas. --- ### **Seguridad de Claves de Acceso y Claves de Licencia** **Claves de Acceso** y **Claves de Licencia** son credenciales críticas utilizadas para autenticar y autorizar interacciones con el CLI de Serverless Framework. - **Claves de Licencia:** Son identificadores únicos requeridos para autenticar el acceso a Serverless Framework Versión 4 que permite iniciar sesión a través del CLI. - **Claves de Acceso:** Credenciales que permiten al CLI de Serverless Framework autenticarse con el Dashboard de Serverless Framework. Al iniciar sesión con el cli `serverless`, se generará y almacenará una clave de acceso en la **computadora portátil**. También puede configurarse como una variable de entorno llamada `SERVERLESS_ACCESS_KEY`. #### **Riesgos de Seguridad** 1. **Exposición a Través de Repositorios de Código:** - Codificar o comprometer accidentalmente Claves de Acceso y Claves de Licencia en sistemas de control de versiones puede llevar a acceso no autorizado. 2. **Almacenamiento Inseguro:** - Almacenar claves en texto claro dentro de variables de entorno o archivos de configuración sin la encriptación adecuada aumenta la probabilidad de filtraciones. 3. **Distribución Inadecuada:** - Compartir claves a través de canales no seguros (por ejemplo, correo electrónico, chat) puede resultar en la interceptación por actores maliciosos. 4. **Falta de Rotación:** - No rotar regularmente las claves extiende el período de exposición si las claves son comprometidas. 5. **Permisos Excesivos:** - Claves con permisos amplios pueden ser explotadas para realizar acciones no autorizadas en múltiples recursos. {{#include ../banners/hacktricks-training.md}}