# Serverless.com Security

{{#include ../banners/hacktricks-training.md}}

## Informações Básicas

### Organização

Uma **Organização** é a entidade de nível mais alto dentro do ecossistema do Serverless Framework. Ela representa um **grupo coletivo**, como uma empresa, departamento ou qualquer entidade grande, que abrange múltiplos projetos, equipes e aplicações.

### Equipe

A **Equipe** são os usuários com acesso dentro da organização. As equipes ajudam a organizar os membros com base em funções. **`Colaboradores`** podem visualizar e implantar aplicativos existentes, enquanto **`Administradores`** podem criar novos aplicativos e gerenciar as configurações da organização.

### Aplicação

Um **App** é um agrupamento lógico de serviços relacionados dentro de uma Organização. Ele representa uma aplicação completa composta por múltiplos serviços serverless que trabalham juntos para fornecer uma funcionalidade coesa.

### **Serviços**

Um **Serviço** é o componente central de uma aplicação Serverless. Ele representa todo o seu projeto serverless, encapsulando todas as funções, configurações e recursos necessários. Geralmente é definido em um arquivo `serverless.yml`, um serviço inclui metadados como o nome do serviço, configurações do provedor, funções, eventos, recursos, plugins e variáveis personalizadas.
```yaml
service: my-service
provider:
name: aws
runtime: nodejs14.x
functions:
hello:
handler: handler.hello
```
<details>

<summary>Função</summary>

Uma **Função** representa uma única função serverless, como uma função AWS Lambda. Ela contém o código que é executado em resposta a eventos.

Está definida na seção `functions` em `serverless.yml`, especificando o manipulador, tempo de execução, eventos, variáveis de ambiente e outras configurações.
```yaml
functions:
hello:
handler: handler.hello
events:
- http:
path: hello
method: get
```
</details>

<details>

<summary>Evento</summary>

**Eventos** são gatilhos que invocam suas funções serverless. Eles definem como e quando uma função deve ser executada.

Os tipos comuns de eventos incluem solicitações HTTP, eventos agendados (jobs cron), eventos de banco de dados, uploads de arquivos e mais.
```yaml
functions:
hello:
handler: handler.hello
events:
- http:
path: hello
method: get
- schedule:
rate: rate(10 minutes)
```
</details>

<details>

<summary>Recurso</summary>

**Recursos** permitem que você defina recursos adicionais de nuvem dos quais seu serviço depende, como bancos de dados, buckets de armazenamento ou funções IAM.

Eles são especificados na seção `resources`, frequentemente usando a sintaxe do 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
```
</details>

<details>

<summary>Provedor</summary>

O objeto **Provedor** especifica o provedor de serviços em nuvem (por exemplo, AWS, Azure, Google Cloud) e contém configurações relevantes para esse provedor.

Inclui detalhes como o runtime, região, estágio e credenciais.
```yaml
yamlCopy codeprovider:
name: aws
runtime: nodejs14.x
region: us-east-1
stage: dev
```
</details>

<details>

<summary>Estágio e Região</summary>

O estágio representa diferentes ambientes (por exemplo, desenvolvimento, homologação, produção) onde seu serviço pode ser implantado. Ele permite configurações e implantações específicas para cada ambiente.
```yaml
provider:
stage: dev
```
A região especifica a região geográfica onde seus recursos serão implantados. É importante para considerações de latência, conformidade e disponibilidade.
```yaml
provider:
region: us-west-2
```
</details>

<details>

<summary>Plugins</summary>

**Plugins** estendem a funcionalidade do Serverless Framework adicionando novos recursos ou integrando-se a outras ferramentas e serviços. Eles são definidos na seção `plugins` e instalados via npm.
```yaml
plugins:
- serverless-offline
- serverless-webpack
```
</details>

<details>

<summary>Camadas</summary>

**Camadas** permitem que você empacote e gerencie código compartilhado ou dependências separadamente de suas funções. Isso promove a reutilização e reduz o tamanho dos pacotes de implantação. Elas são definidas na seção `layers` e referenciadas por funções.
```yaml
layers:
commonLibs:
path: layer-common
functions:
hello:
handler: handler.hello
layers:
- { Ref: CommonLibsLambdaLayer }
```
</details>

<details>

<summary>Variáveis e Variáveis Personalizadas</summary>

**Variáveis** permitem configuração dinâmica ao permitir o uso de espaços reservados que são resolvidos no momento da implantação.

- **Sintaxe:** A sintaxe `${variable}` pode referenciar variáveis de ambiente, conteúdos de arquivos ou outros parâmetros de configuração.

```yaml
functions:
hello:
handler: handler.hello
environment:
TABLE_NAME: ${self:custom.tableName}
```

* **Variáveis Personalizadas:** A seção `custom` é usada para definir variáveis e configurações específicas do usuário que podem ser reutilizadas em todo o `serverless.yml`.

```yaml
custom:
tableName: my-dynamodb-table
stage: ${opt:stage, 'dev'}
```

</details>

<details>

<summary>Saídas</summary>

**Saídas** definem os valores que são retornados após um serviço ser implantado, como ARNs de recursos, endpoints ou outras informações úteis. Elas são especificadas na seção `outputs` e frequentemente usadas para expor informações a outros serviços ou para fácil acesso após a implantação.
```yaml
¡outputs:
ApiEndpoint:
Description: "API Gateway endpoint URL"
Value:
Fn::Join:
- ""
- - "https://"
- Ref: ApiGatewayRestApi
- ".execute-api."
- Ref: AWS::Region
- ".amazonaws.com/"
- Ref: AWS::Stage
```
</details>

<details>

<summary>Funções e Permissões IAM</summary>

**Funções e Permissões IAM** definem as credenciais de segurança e os direitos de acesso para suas funções e outros recursos. Elas são gerenciadas sob as configurações do `provider` ou de funções individuais para especificar as permissões necessárias.
```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}
```
</details>

<details>

<summary>Variáveis de Ambiente</summary>

**Variáveis** permitem que você passe configurações e segredos para suas funções sem codificá-los diretamente. Elas são definidas na seção `environment` para o provedor ou funções individuais.
```yaml
provider:
environment:
STAGE: ${self:provider.stage}
functions:
hello:
handler: handler.hello
environment:
TABLE_NAME: ${self:custom.tableName}
```
</details>

<details>

<summary>Dependências</summary>

**Dependências** gerenciam as bibliotecas e módulos externos que suas funções requerem. Elas são normalmente gerenciadas por meio de gerenciadores de pacotes como npm ou pip, e empacotadas com seu pacote de implantação usando ferramentas ou plugins como `serverless-webpack`.
```yaml
plugins:
- serverless-webpack
```
</details>

<details>

<summary>Hooks</summary>

**Hooks** permitem que você execute scripts ou comandos personalizados em pontos específicos do ciclo de vida de implantação. Eles são definidos usando plugins ou dentro do `serverless.yml` para realizar ações antes ou depois das implantações.
```yaml
custom:
hooks:
before:deploy:deploy: echo "Starting deployment..."
```
</details>

### Tutorial

Este é um resumo do tutorial oficial [**da documentação**](https://www.serverless.com/framework/docs/tutorial):

1. Crie uma conta na AWS (Serverless.com começa na infraestrutura da AWS)
2. Crie uma conta em serverless.com
3. Crie um aplicativo:
```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)
```
Isso deve ter criado um **app** chamado `tutorialapp` que você pode verificar em [serverless.com](serverless.com-security.md) e uma pasta chamada `Tutorial` com o arquivo **`handler.js`** contendo algum código JS com um código `helloworld` e o arquivo **`serverless.yml`** declarando essa função:

{{#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. Crie um provedor AWS, acessando o **dashboard** em `https://app.serverless.com/<org name>/settings/providers?providerId=new&provider=aws`.
1. Para dar acesso ao `serverless.com` ao AWS, será solicitado que você execute uma pilha do cloudformation usando este arquivo de configuração (no momento da escrita): [https://serverless-framework-template.s3.amazonaws.com/roleTemplate.yml](https://serverless-framework-template.s3.amazonaws.com/roleTemplate.yml)
2. Este template gera um papel chamado **`SFRole-<ID>`** com **`arn:aws:iam::aws:policy/AdministratorAccess`** sobre a conta com uma Identidade de Confiança que permite que a conta AWS do `Serverless.com` acesse o papel.

<details>

<summary>Yaml roleTemplate</summary>
```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
```
</details>

<details>

<summary>Relação de Confiança</summary>
```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"
}
}
}
]
}
```
</details>

5. O tutorial pede para criar o arquivo `createCustomer.js`, que basicamente criará um novo endpoint de API gerenciado pelo novo arquivo JS e pede para modificar o arquivo `serverless.yml` para que ele gere uma **nova tabela DynamoDB**, defina uma **variável de ambiente**, o papel que estará usando as lambdas geradas.

{{#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. Faça o deploy executando **`serverless deploy`**
1. O deployment será realizado via um CloudFormation Stack
2. Note que as **lambdas estão expostas via API gateway** e não via URLs diretas
7. **Teste**
1. O passo anterior imprimirá as **URLs** onde suas funções lambda de endpoints da API foram implantadas

## Revisão de Segurança do Serverless.com

### **Papéis e Permissões IAM Mal Configurados**

Papéis IAM excessivamente permissivos podem conceder acesso não autorizado a recursos em nuvem, levando a vazamentos de dados ou manipulação de recursos.

Quando nenhuma permissão é especificada para uma função Lambda, um papel com permissões apenas para gerar logs será criado, como:

<details>

<summary>Permissões mínimas da lambda</summary>
```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"
}
]
}
```
</details>

#### **Estratégias de Mitigação**

- **Princípio do Menor Privilégio:** Atribua apenas as permissões necessárias a cada função.

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

- **Use Funções Separadas:** Diferencie funções com base nos requisitos.

---

### **Segredos Inseguros e Gerenciamento de Configuração**

Armazenar informações sensíveis (por exemplo, chaves de API, credenciais de banco de dados) diretamente em **`serverless.yml`** ou código pode levar à exposição se os repositórios forem comprometidos.

A maneira **recomendada** de armazenar variáveis de ambiente no arquivo **`serverless.yml`** do serverless.com (no momento da redação) é usar os provedores `ssm` ou `s3`, que permitem obter os **valores de ambiente dessas fontes no momento da implantação** e **configurar** as variáveis de ambiente das **lambdas** com o **texto claro dos valores**!

> [!CAUTION]
> Portanto, qualquer pessoa com permissões para ler a configuração das lambdas dentro da AWS poderá **acessar todas essas variáveis de ambiente em texto claro!**

Por exemplo, o seguinte exemplo usará SSM para obter uma variável de ambiente:
```yaml
provider:
environment:
DB_PASSWORD: ${ssm:/aws/reference/secretsmanager/my-db-password~true}
```
E mesmo que isso impeça a codificação rígida do valor da variável de ambiente no arquivo **`serverless.yml`**, o valor será obtido no momento da implantação e será **adicionado em texto claro dentro da variável de ambiente da lambda**.

> [!TIP]
> A maneira recomendada de armazenar variáveis de ambiente usando serveless.com seria **armazená-las em um segredo da AWS** e apenas armazenar o nome do segredo na variável de ambiente e o **código da lambda deve coletá-lo**.

#### **Estratégias de Mitigação**

- **Integração com o Secrets Manager:** Use serviços como **AWS Secrets Manager.**
- **Variáveis Criptografadas:** Aproveite os recursos de criptografia do Serverless Framework para dados sensíveis.
- **Controles de Acesso:** Restringir o acesso a segredos com base em funções.

---

### **Código e Dependências Vulneráveis**

Dependências desatualizadas ou inseguras podem introduzir vulnerabilidades, enquanto o manuseio inadequado de entradas pode levar a ataques de injeção de código.

#### **Estratégias de Mitigação**

- **Gerenciamento de Dependências:** Atualize regularmente as dependências e escaneie em busca de vulnerabilidades.

```yaml
plugins:
- serverless-webpack
- serverless-plugin-snyk
```

- **Validação de Entrada:** Implemente validação e sanitização rigorosas de todas as entradas.
- **Revisões de Código:** Realize revisões minuciosas para identificar falhas de segurança.
- **Análise Estática:** Use ferramentas para detectar vulnerabilidades na base de código.

---

### **Registro e Monitoramento Inadequados**

Sem registro e monitoramento adequados, atividades maliciosas podem passar despercebidas, atrasando a resposta a incidentes.

#### **Estratégias de Mitigação**

- **Registro Centralizado:** Agregue logs usando serviços como **AWS CloudWatch** ou **Datadog**.

```yaml
plugins:
- serverless-plugin-datadog
```

- **Ativar Registro Detalhado:** Capture informações essenciais sem expor dados sensíveis.
- **Configurar Alertas:** Configure alertas para atividades suspeitas ou anomalias.
- **Monitoramento Regular:** Monitore continuamente logs e métricas em busca de potenciais incidentes de segurança.

---

### **Configurações Inseguras do API Gateway**

APIs abertas ou mal protegidas podem ser exploradas para acesso não autorizado, ataques de Negação de Serviço (DoS) ou ataques entre sites.

#### **Estratégias de Mitigação**

- **Autenticação e Autorização:** Implemente mecanismos robustos como OAuth, chaves de API ou JWT.

```yaml
functions:
hello:
handler: handler.hello
events:
- http:
path: hello
method: get
authorizer: aws_iam
```

- **Limitação de Taxa e Controle de Fluxo:** Previna abusos limitando as taxas de solicitação.

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

- **Configuração Segura de CORS:** Restringir origens, métodos e cabeçalhos permitidos.

```yaml
functions:
hello:
handler: handler.hello
events:
- http:
path: hello
method: get
cors:
origin: https://yourdomain.com
headers:
- Content-Type
```

- **Usar Firewalls de Aplicação Web (WAF):** Filtrar e monitorar solicitações HTTP em busca de padrões maliciosos.

---

### **Isolamento de Funções Insuficiente**

Recursos compartilhados e isolamento inadequado podem levar a elevações de privilégio ou interações não intencionais entre funções.

#### **Estratégias de Mitigação**

- **Isolar Funções:** Atribua recursos distintos e funções IAM para garantir operação independente.
- **Particionamento de Recursos:** Use bancos de dados ou buckets de armazenamento separados para diferentes funções.
- **Usar VPCs:** Implante funções dentro de Nuvens Privadas Virtuais para melhor isolamento de rede.

```yaml
provider:
vpc:
securityGroupIds:
- sg-xxxxxxxx
subnetIds:
- subnet-xxxxxx
```

- **Limitar Permissões de Funções:** Garantir que as funções não possam acessar ou interferir nos recursos umas das outras, a menos que explicitamente necessário.

---

### **Proteção de Dados Inadequada**

Dados não criptografados em repouso ou em trânsito podem ser expostos, levando a vazamentos de dados ou adulterações.

#### **Estratégias de Mitigação**

- **Criptografar Dados em Repouso:** Utilize recursos de criptografia do serviço em nuvem.

```yaml
resources:
Resources:
MyDynamoDBTable:
Type: AWS::DynamoDB::Table
Properties:
SSESpecification:
SSEEnabled: true
```

- **Criptografar Dados em Trânsito:** Use HTTPS/TLS para todas as transmissões de dados.
- **Comunicação Segura da API:** Imponha protocolos de criptografia e valide certificados.
- **Gerenciar Chaves de Criptografia de Forma Segura:** Use serviços de chave gerenciados e gire as chaves regularmente.

---

### **Falta de Tratamento Adequado de Erros**

Mensagens de erro detalhadas podem vazar informações sensíveis sobre a infraestrutura ou base de código, enquanto exceções não tratadas podem levar a falhas de aplicação.

#### **Estratégias de Mitigação**

- **Mensagens de Erro Genéricas:** Evite expor detalhes internos nas respostas de erro.

```javascript
javascriptCopy code// Exemplo em Node.js
exports.hello = async (event) => {
try {
// Lógica da função
} catch (error) {
console.error(error);
return {
statusCode: 500,
body: JSON.stringify({ message: 'Erro Interno do Servidor' }),
};
}
};
```

- **Tratamento Centralizado de Erros:** Gerencie e sanitize erros de forma consistente em todas as funções.
- **Monitorar e Registrar Erros:** Rastreie e analise erros internamente sem expor detalhes aos usuários finais.

---

### **Práticas de Implantação Inseguras**

Configurações de implantação expostas ou acesso não autorizado a pipelines de CI/CD podem levar a implantações de código malicioso ou configurações incorretas.

#### **Estratégias de Mitigação**

- **Pipelines de CI/CD Seguros:** Implemente controles de acesso rigorosos, autenticação multifator (MFA) e auditorias regulares.
- **Armazenar Configurações de Forma Segura:** Mantenha arquivos de implantação livres de segredos codificados e dados sensíveis.
- **Usar Ferramentas de Segurança de Infraestrutura como Código (IaC):** Empregue ferramentas como **Checkov** ou **Terraform Sentinel** para impor políticas de segurança.
- **Implantações Imutáveis:** Previna alterações não autorizadas após a implantação adotando práticas de infraestrutura imutável.

---

### **Vulnerabilidades em Plugins e Extensões**

Usar plugins de terceiros não verificados ou maliciosos pode introduzir vulnerabilidades em suas aplicações serverless.

#### **Estratégias de Mitigação**

- **Avaliar Plugins Minuciosamente:** Avalie a segurança dos plugins antes da integração, favorecendo aqueles de fontes respeitáveis.
- **Limitar o Uso de Plugins:** Use apenas plugins necessários para minimizar a superfície de ataque.
- **Monitorar Atualizações de Plugins:** Mantenha os plugins atualizados para se beneficiar de correções de segurança.
- **Isolar Ambientes de Plugins:** Execute plugins em ambientes isolados para conter possíveis compromissos.

---

### **Exposição de Endpoints Sensíveis**

Funções publicamente acessíveis ou APIs sem restrições podem ser exploradas para operações não autorizadas.

#### **Estratégias de Mitigação**

- **Restringir Acesso a Funções:** Use VPCs, grupos de segurança e regras de firewall para limitar o acesso a fontes confiáveis.
- **Implementar Autenticação Robusta:** Garantir que todos os endpoints expostos exijam autenticação e autorização adequadas.
- **Usar API Gateways de Forma Segura:** Configure API Gateways para impor políticas de segurança, incluindo validação de entrada e limitação de taxa.
- **Desativar Endpoints Não Utilizados:** Revise regularmente e desative quaisquer endpoints que não estejam mais em uso.

---

### **Permissões Excessivas para Membros da Equipe e Colaboradores Externos**

Conceder permissões excessivas a membros da equipe e colaboradores externos pode levar a acesso não autorizado, vazamentos de dados e uso indevido de recursos. Esse risco é aumentado em ambientes onde múltiplos indivíduos têm níveis variados de acesso, aumentando a superfície de ataque e o potencial para ameaças internas.

#### **Estratégias de Mitigação**

- **Princípio do Menor Privilégio:** Garantir que membros da equipe e colaboradores tenham apenas as permissões necessárias para realizar suas tarefas.

---

### **Segurança de Chaves de Acesso e Chaves de Licença**

**Chaves de Acesso** e **Chaves de Licença** são credenciais críticas usadas para autenticar e autorizar interações com o Serverless Framework CLI.

- **Chaves de Licença:** São identificadores únicos necessários para autenticar o acesso à versão 4 do Serverless Framework, que permite login via CLI.
- **Chaves de Acesso:** Credenciais que permitem que o Serverless Framework CLI se autentique com o Dashboard do Serverless Framework. Ao fazer login com o CLI `serverless`, uma chave de acesso será **gerada e armazenada no laptop**. Você também pode configurá-la como uma variável de ambiente chamada `SERVERLESS_ACCESS_KEY`.

#### **Riscos de Segurança**

1. **Exposição Através de Repositórios de Código:**
- Codificar ou cometer acidentalmente Chaves de Acesso e Chaves de Licença em sistemas de controle de versão pode levar a acesso não autorizado.
2. **Armazenamento Inseguro:**
- Armazenar chaves em texto claro dentro de variáveis de ambiente ou arquivos de configuração sem criptografia adequada aumenta a probabilidade de vazamento.
3. **Distribuição Inadequada:**
- Compartilhar chaves por canais não seguros (por exemplo, e-mail, chat) pode resultar em interceptação por atores maliciosos.
4. **Falta de Rotação:**
- Não girar regularmente as chaves estende o período de exposição se as chaves forem comprometidas.
5. **Permissões Excessivas:**
- Chaves com permissões amplas podem ser exploradas para realizar ações não autorizadas em múltiplos recursos.

{{#include ../banners/hacktricks-training.md}}