Segurança em AWS Lambda: permissões, segredos, logs e execução segura
Serverless não elimina responsabilidade de segurança. Veja como restringir permissões, segredos e exposição em funções Lambda.
Serverless reduz a superfície de infraestrutura, mas não elimina a responsabilidade de segurança da aplicação. Em funções Lambda, os riscos se concentram em permissões amplas demais na role de execução, segredos embutidos no código ou em variáveis, dependências vulneráveis, dados de evento tratados sem validação e exposição descontrolada via API Gateway ou Function URL. Como funções são pequenas e numerosas, é fácil acumular permissões e segredos sem revisão.
Este guia trata da segurança de funções Lambda de forma defensiva, com foco no que mais importa: menor privilégio na role, quem pode invocar a função, gestão de segredos, validação de eventos, dependências, logs e exposição. O objetivo é que cada função tenha exatamente o acesso de que precisa e nada além, e que só quem deve consiga acioná-la.
Role de execução com menor privilégio
Cada função deve ter sua própria role com permissões mínimas, específicas para o que ela faz. O anti-padrão comum é reutilizar uma role ampla em muitas funções, fazendo com que o comprometimento de uma função insignificante conceda acesso a recursos sensíveis. Modele permissões por função, restringindo ações e recursos a nomes concretos, sem curingas amplos em Action ou Resource.
{
"Effect": "Allow",
"Action": ["sqs:ReceiveMessage", "sqs:DeleteMessage"],
"Resource": "arn:aws:sqs:REGIAO:CONTA:fila-pedidos"
}Lembre que a função executa com as permissões da role, então qualquer falha no código que permita execução indevida herda esse acesso. Menor privilégio limita o estrago: se a role só pode ler uma fila específica e gravar em uma tabela, é só isso que um comprometimento alcança. Preste atenção especial a iam:PassRole na role de deploy, porque ele permite associar roles mais poderosas a novas funções, um caminho clássico de escalonamento.
Quem pode invocar a função
A role de execução responde o que a função pode fazer, mas a política baseada em recurso responde uma pergunta diferente e igualmente importante: quem pode invocar a função. Cada gatilho, como API Gateway, S3 ou EventBridge, ganha uma permissão de invocação. Concessões amplas demais aqui, como permitir invocação por qualquer origem de uma conta, abrem a função para acionamento indevido. Restrinja o principal e a origem ao gatilho legítimo.
As Function URLs merecem cuidado. Uma Function URL com autorização do tipo aberta expõe a função diretamente na internet sem autenticação, o que raramente é o desejado. Prefira autorização por IAM ou coloque a função atrás de API Gateway ou CloudFront, onde há authorizer, WAF e throttling. Uma Function URL aberta e esquecida é uma porta direta para a lógica da função.
Segredos, dependências e variáveis
Não coloque segredos no código nem em variáveis de ambiente em texto claro. Busque-os do Secrets Manager ou do Parameter Store em runtime, com a role autorizada a ler apenas os segredos necessários. As variáveis de ambiente do Lambda são visíveis para quem tem acesso à configuração da função, então não são local seguro para credenciais, mesmo com a criptografia em repouso. Quando usar variáveis para configuração não sensível, considere criptografá-las com uma chave KMS própria em vez da chave padrão.
- Uma role por função, com permissões mínimas e recursos nomeados
- Restringir quem pode invocar a função na política baseada em recurso
- Evitar Function URL aberta; preferir IAM, API Gateway ou CloudFront
- Buscar segredos do Secrets Manager ou Parameter Store em runtime
- Não usar variável de ambiente para credenciais sensíveis
- Manter dependências e layers atualizados e com scan de vulnerabilidades
- Definir timeout, memória e concorrência reservada adequados
Dependências de terceiros e layers podem trazer vulnerabilidades. Faça scan e atualize com regularidade, porque uma biblioteca vulnerável em uma função exposta é um caminho de ataque concreto. Considere o code signing para garantir que só artefatos assinados sejam implantados, o que dificulta a injeção de código malicioso no pipeline de deploy.
Validação de evento e superfície de ataque
A função recebe dados de eventos, e esses dados são entrada não confiável, mesmo vindo de serviços da AWS. Um evento de API Gateway carrega corpo, cabeçalhos e parâmetros controlados pelo cliente; uma mensagem de fila pode ter conteúdo colocado por um produtor comprometido; um evento de S3 traz nomes de objeto que um terceiro pode ter influenciado. Trate tudo isso como entrada a validar, e não como dado confiável só por chegar pela plataforma.
As classes de falha clássicas continuam válidas em serverless: injeção quando o dado do evento entra em uma consulta ou comando sem sanitização, desserialização insegura de payloads e travessia de caminho ao montar nomes de arquivo. Valide o esquema do evento, trate erros de forma explícita e escreva no armazenamento temporário sabendo que ele pode persistir entre invocações quentes da mesma função, então não deixe dados sensíveis lá entre execuções.
Exposição, logs e rede
Quando a função é exposta via API Gateway, valem todos os controles de autenticação e autorização do guia de API Gateway. Habilite logs no CloudWatch para cada função e monitore erros e invocações anômalas, como picos fora do padrão que podem indicar abuso. Vale lembrar do custo do abuso: um gatilho público sem limite pode ser acionado em massa e gerar despesa inesperada, o chamado esgotamento de carteira, então concorrência reservada e throttling na borda também protegem o orçamento.
Se a função precisa acessar recursos privados, como um banco, coloque-a na VPC adequada com Security Groups restritos, em vez de expor o recurso. A partir da VPC, controle a saída para a internet com o cuidado de sempre, porque uma função comprometida com saída livre pode exfiltrar dados. O GuardDuty tem proteção específica para Lambda que ajuda a detectar comunicação de rede suspeita a partir das funções.
Checklist prático
- Atribuir uma role de execução por função, com menor privilégio e recursos nomeados
- Evitar role ampla reutilizada em muitas funções
- Restringir quem pode invocar a função na política baseada em recurso
- Evitar Function URL aberta; preferir IAM, API Gateway ou CloudFront
- Buscar segredos do Secrets Manager ou Parameter Store em runtime
- Não armazenar credenciais em variáveis de ambiente
- Validar o esquema e o conteúdo de todo evento como entrada não confiável
- Fazer scan e atualizar dependências e layers, e avaliar code signing
- Definir timeout, memória e concorrência reservada adequados
- Aplicar autenticação e autorização quando exposta via API Gateway
- Habilitar logs no CloudWatch e monitorar anomalias e custo de invocação
- Colocar na VPC com Security Groups restritos quando acessar recursos privados
- Revisar permissões e gatilhos das funções periodicamente
Boas práticas
- Modele permissões por função, não uma role para todas
- Controle tanto o que a função faz quanto quem pode invocá-la
- Tire segredos do código e das variáveis de ambiente
- Trate os dados de evento como entrada não confiável e valide sempre
- Trate dependências como superfície de ataque
- Aplique os controles de API Gateway quando exposta
- Observe cada função com logs, métricas e atenção ao custo de abuso
- Use VPC e Security Groups para acesso a recursos privados
Erros comuns
Role ampla reutilizada em muitas funções
O comprometimento de uma função simples alcança recursos sensíveis.
Function URL aberta e esquecida
A lógica da função fica acessível na internet sem autenticação.
Segredos em variáveis de ambiente em texto claro
Credenciais visíveis para quem acessa a configuração da função.
Confiar nos dados do evento sem validar
Injeção, desserialização insegura e travessia de caminho continuam possíveis.
Dependências e layers desatualizados
Bibliotecas vulneráveis viram caminho de ataque em função exposta.
Gatilho público sem limite de concorrência
Invocação em massa sobrecarrega dependências e gera custo inesperado.
Quando procurar apoio especializado
Revisar permissões, segredos e exposição de funções serverless é parte dos serviços de Segurança de Aplicações e de Segurança AWS da GUARDIASEC, que avaliam o ambiente serverless com foco em menor privilégio e risco real.
Perguntas frequentes
Serverless é mais seguro por padrão?
Serverless reduz a superfície de infraestrutura, já que você não administra servidores, mas a responsabilidade de segurança da aplicação permanece. Permissões da role, segredos, validação de eventos, dependências e exposição continuam sob seu controle e são onde os riscos se concentram. Serverless muda o que você gerencia, não elimina a necessidade de menor privilégio e boas práticas.
Posso usar variáveis de ambiente para segredos no Lambda?
Não é recomendado para credenciais sensíveis. As variáveis de ambiente da função são visíveis para quem tem acesso à configuração dela, então funcionam como texto claro do ponto de vista de quem administra. O correto é buscar segredos do Secrets Manager ou do Parameter Store em runtime, com a role autorizada a ler apenas o necessário, mantendo o valor fora da configuração da função.
Por que uma role por função e não uma role compartilhada?
Porque uma role ampla compartilhada faz com que o comprometimento de qualquer função, mesmo uma trivial, conceda acesso a tudo o que a role permite. Atribuindo a cada função uma role com permissões mínimas e específicas, você limita o raio de impacto: um problema em uma função alcança apenas os poucos recursos que aquela função realmente usa.
Preciso validar os dados que chegam pelo evento?
Sim. Os dados do evento são entrada não confiável, mesmo vindo de serviços da AWS, porque muitas vezes têm origem em um cliente, em um produtor de fila ou em um objeto que um terceiro influenciou. As falhas clássicas de injeção, desserialização insegura e travessia de caminho continuam válidas em serverless. Valide o esquema, sanitize o conteúdo e trate erros de forma explícita.
Preciso colocar a Lambda na VPC?
Só quando ela precisa acessar recursos privados, como um banco em sub-rede privada. Nesse caso, coloque a função na VPC com Security Groups restritos, em vez de expor o recurso. Se a função não acessa nada privado, mantê-la fora da VPC simplifica a operação. A decisão depende do que a função realmente precisa alcançar.
Uma função pública pode gerar custo inesperado?
Pode. Um gatilho público sem limite, como uma Function URL aberta ou um endpoint sem throttling, permite invocação em massa que sobrecarrega dependências e gera despesa, um risco às vezes chamado de esgotamento de carteira. Defina concorrência reservada na função e throttling na borda, e monitore o volume de invocações para detectar picos anômalos cedo.
Guias relacionados
Próximo passo
Vamos avaliar os riscos do seu ambiente?
Conte seu cenário e definimos juntos o escopo certo. O objetivo é reduzir caminhos prováveis de ataque e elevar a maturidade de segurança, sem promessas absolutas.