hacktricks-cloud/src/pentesting-ci-cd/serverless.com-security.md

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

¡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.

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.

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.

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.

custom:
hooks:
before:deploy:deploy: echo "Starting deployment..."

Tutorial

Este es un resumen del tutorial oficial de la documentación:

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:

# 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 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" }}

exports.hello = async (event) => {
return {
statusCode: 200,
body: JSON.stringify({
message: "Go Serverless v4! Your function executed successfully!",
}),
}
}

{{#endtab }} {{#tab name="serverless.yml" }}

# "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/<org name>/settings/providers?providerId=new&provider=aws.
5. 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
6. Esta plantilla genera un rol llamado SFRole-<ID> 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" }}

"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" }}

# "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
7. El despliegue se realizará a través de un CloudFormation Stack
8. Tenga en cuenta que las lambdas están expuestas a través de API gateway y no a través de URLs directas
9. Pruébelo
10. 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.

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:

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.

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.

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.

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.

provider:
apiGateway:
throttle:
burstLimit: 200
rateLimit: 100

• Configuración Segura de CORS: Restringir orígenes, métodos y encabezados permitidos.

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.

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.

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.

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}}