gitea-mirror/hacktricks-cloud
1
0
Fork 0
mirror of https://github.com/HackTricks-wiki/hacktricks-cloud.git synced 2026-07-29 07:00:29 -07:00
Code Issues Packages Projects Releases Wiki Activity

Translated ['src/banners/hacktricks-training.md', 'src/pentesting-ci-cd/

Browse Source
This commit is contained in:
Translator
2025-01-02 01:17:32 +00:00
parent 6b8f1f076b
commit 17d930d963
221 changed files with 1540 additions and 1546 deletions
Download Patch File Download Diff File Expand all files Collapse all files
src/pentesting-ci-cd/serverless.com-security.md
+21 -21
View File
@@ -34,7 +34,7 @@ handler: handler.hello
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, runtime, eventos, variáveis de ambiente e outras configurações.
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:
@@ -70,7 +70,7 @@ rate: rate(10 minutes)
<summary>Recurso</summary>
**Recursos** permitem que você defina recursos de nuvem adicionais dos quais seu serviço depende, como bancos de dados, buckets de armazenamento ou funções IAM.
**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
@@ -254,7 +254,7 @@ plugins:
<summary>Hooks</summary>
**Hooks** permitem que você execute scripts ou comandos personalizados em pontos específicos do ciclo de vida da implantação. Eles são definidos usando plugins ou dentro do `serverless.yml` para realizar ações antes ou depois das implantações.
**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:
@@ -323,7 +323,7 @@ method: get
{{#endtab }}
{{#endtabs }}
4. Crie um provedor AWS, acessando o **painel** em `https://app.serverless.com/<org name>/settings/providers?providerId=new&provider=aws`.
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.
@@ -399,7 +399,7 @@ Type: String
```
</details>
5. O tutorial pede para criar o arquivo `createCustomer.js`, que basicamente criará um novo endpoint de API tratado 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.
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" }}
@@ -481,19 +481,19 @@ TableName: ${self:service}-customerTable-${sls:stage}
{{#endtab }}
{{#endtabs }}
6. Implemente-o executando **`serverless deploy`**
1. A implantação será realizada via um CloudFormation Stack
2. Observe que as **lambdas estão expostas via API gateway** e não via URLs diretas
7. **Teste-o**
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
### **Funções e Permissões IAM Mal Configuradas**
### **Papéis e Permissões IAM Mal Configurados**
Funções IAM excessivamente permissivas podem conceder acesso não autorizado a recursos em nuvem, levando a vazamentos de dados ou manipulação de recursos.
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, uma função com permissões apenas para gerar logs será criada, como:
Quando nenhuma permissão é especificada para uma função Lambda, um papel com permissões apenas para gerar logs será criado, como:
<details>
@@ -545,7 +545,7 @@ Action:
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 da função.
- **Use Funções Separadas:** Diferencie funções com base nos requisitos.
---
@@ -553,7 +553,7 @@ Resource: arn:aws:dynamodb:${aws:region}:${aws:accountId}:table/${self:service}-
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**!
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!**
@@ -671,7 +671,7 @@ Recursos compartilhados e isolamento inadequado podem levar a elevações de pri
#### **Estratégias de Mitigação**
- **Isolar Funções:** Atribua recursos e funções IAM distintos para garantir operação independente.
- **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.
@@ -714,7 +714,7 @@ SSEEnabled: true
### **Falta de Tratamento Adequado de Erros**
Mensagens de erro detalhadas podem vazar informações sensíveis sobre a infraestrutura ou a base de código, enquanto exceções não tratadas podem levar a falhas na aplicação.
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**
@@ -768,7 +768,7 @@ Usar plugins de terceiros não verificados ou maliciosos pode introduzir vulnera
### **Exposição de Endpoints Sensíveis**
Funções acessíveis publicamente ou APIs sem restrições podem ser exploradas para operações não autorizadas.
Funções publicamente acessíveis ou APIs sem restrições podem ser exploradas para operações não autorizadas.
#### **Estratégias de Mitigação**
@@ -791,10 +791,10 @@ Conceder permissões excessivas a membros da equipe e colaboradores externos pod
### **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 a CLI do Serverless Framework.
**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 a CLI do Serverless Framework se autentique com o Dashboard do Serverless Framework. Ao fazer login com a 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`.
- **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**
@@ -807,6 +807,6 @@ Conceder permissões excessivas a membros da equipe e colaboradores externos pod
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 vários recursos.
- Chaves com permissões amplas podem ser exploradas para realizar ações não autorizadas em múltiplos recursos.
{{#include ../banners/hacktricks-training.md}}