Segurança de Aplicações e Funções Serverless

A computação sem servidor (Functions as a Service, FaaS) permite que os desenvolvedores implantem funções individuais invocadas por eventos — solicitações HTTP, mensagens de filas, acionadores de bancos de dados ou temporizadores agendados — sem gerenciar os servidores subjacentes. Entre as principais plataformas estão o AWS Lambda, o Google Cloud Functions e o Azure Functions. O provedor de nuvem gerencia a aplicação de correções, o dimensionamento e a infraestrutura. Embora isso reduza a carga operacional, transfere o modelo de responsabilidade de segurança: o provedor protege o ambiente de execução, mas o desenvolvedor é o único responsável pelo código da função, pelas permissões e pela configuração.

As funções sem servidor apresentam uma superfície de ataque distinta em comparação com aplicações tradicionais: normalmente, as funções têm vida curta (de segundos a minutos), o que torna o EDR tradicional e o monitoramento de rede menos eficazes; elas são orientadas a eventos, ou seja, muitas fontes de entrada diferentes (eventos do S3, API Gateway, SNS) podem acionar sua execução; frequentemente são executadas com permissões do IAM que permitem acessar outros recursos da nuvem; e consomem dependências de terceiros (pacotes npm e pip) que podem conter código malicioso. A superfície de ataque é definida pelas entradas de eventos, pelas permissões do IAM e pelas cadeias de confiança das dependências.

A vulnerabilidade de segurança sem servidor mais comum são as funções do IAM com privilégios excessivos. Quando os desenvolvedores precisam que uma função acesse um bucket do S3, pode ser tentador atribuir s3:* (acesso total ao S3) para evitar erros de permissão. Uma função comprometida ou vulnerável com essa função do IAM poderá ler, gravar ou excluir qualquer bucket da conta. A defesa consiste em aplicar rigorosamente funções do IAM com menor privilégio: cada função deve ter uma função dedicada que conceda somente as permissões mínimas necessárias para as tarefas específicas daquela função. Ferramentas como o AWS IAM Access Analyzer e o Cloudsplaining identificam automaticamente funções do Lambda com privilégios excessivos.

A injeção de eventos ocorre quando dados controlados por um invasor presentes na carga útil de um evento são processados de forma insegura pelo código da função. Como as funções sem servidor podem ser acionadas por muitas fontes de eventos — cabeçalhos HTTP, parâmetros de consulta, registros de alterações de bancos de dados, corpos de mensagens de filas e conteúdo de e-mails — qualquer uma delas pode transportar cargas úteis maliciosas. Os tipos comuns de injeção incluem: injeção de SQL, quando a função consulta um banco de dados usando dados do evento; injeção de NoSQL (operadores do MongoDB em cargas JSON); injeção de comandos, quando os dados do evento são usados em comandos do OS; e SSRF (falsificação de solicitações do lado do servidor), quando URLs provenientes dos dados do evento são acessadas. A validação das entradas e as consultas parametrizadas são defesas essenciais.

As funções sem servidor frequentemente dependem de dezenas de pacotes de terceiros. Essas dependências introduzem riscos à cadeia de fornecimento: um pacote malicioso ou comprometido pode executar código arbitrário no ambiente de execução da função, acessar variáveis de ambiente (que geralmente contêm segredos), realizar conexões de rede de saída e usar a função do IAM da função para acessar recursos da nuvem. Ataques de grande repercussão, como o comprometimento do pacote npm event-stream (2018), e inúmeros pacotes de typosquatting demonstram esse risco. As defesas incluem fixação de dependências, verificação SCA no CI/CD e uma quantidade mínima de dependências.

As funções sem servidor geralmente recebem segredos por meio de variáveis de ambiente configuradas no console da nuvem. Essas variáveis de ambiente ficam visíveis para qualquer pessoa com acesso do IAM à configuração do Lambda e podem ser acessadas por qualquer código executado dentro da função. Práticas recomendadas: evite armazenar segredos diretamente como variáveis de ambiente em texto simples; em vez disso, armazene ARNs ou nomes de segredos e recupere os segredos em tempo de execução usando o AWS Secrets Manager ou o Parameter Store; habilite a criptografia KMS para as variáveis de ambiente do Lambda quando estiverem armazenadas; e nunca registre variáveis de ambiente (muitos registradores de depuração despejam todas as variáveis de ambiente quando ocorre um erro).

A negação de serviço contra funções sem servidor pode ocorrer por meio de uma inundação de invocações — um invasor capaz de acionar uma função repetidamente pode esgotar o limite de simultaneidade da conta (o padrão do Lambda é de 1.000 execuções simultâneas por região), impedindo a execução de outras funções da conta. As funções que processam entradas controladas pelo usuário devem implementar limitação de taxa no nível do API Gateway, validar limites de tamanho das cargas úteis e definir valores de tempo limite adequados para evitar execuções descontroladas. As funções também podem ser alvo de ataques de expansão no estilo Billion Laughs durante a análise de XML/YAML, caso a entrada não tenha um limite de tamanho.

Por padrão, as funções do AWS Lambda são executadas em uma VPC gerenciada pela AWS com acesso à Internet, mas sem acesso aos recursos da sua VPC privada (bancos de dados RDS, ElastiCache e APIs privadas). Para acessar recursos privados, o Lambda deve ser configurado para ser executado dentro da sua VPC, com sub-redes e grupos de segurança específicos. No entanto, as funções do Lambda associadas a uma VPC não têm acesso à Internet por padrão — elas precisam de um NAT Gateway para acessar a Internet de saída. Os grupos de segurança associados às funções do Lambda devem seguir regras de menor privilégio: permitir somente as portas e os destinos específicos necessários. Evite usar regras de saída 0.0.0.0/0 nos grupos de segurança de funções de produção.

O monitoramento da segurança sem servidor exige abordagens diferentes das usadas no monitoramento tradicional de hosts. Como as funções são efêmeras, os agentes baseados em host são impraticáveis. O monitoramento eficaz utiliza: o AWS CloudTrail para registrar todas as chamadas de API do Lambda (invocações, alterações de configuração e assunções de funções); o CloudWatch Logs Insights para consultar os registros de execução das funções em busca de padrões anômalos; o Amazon GuardDuty para detectar ameaças, incluindo atividades de rede incomuns do Lambda; e ferramentas comerciais de segurança nativas de ambientes sem servidor, como o Protego (agora parte da Check Point) ou o monitoramento sem servidor do Datadog, que instrumenta as funções por meio de camadas para fornecer visibilidade em tempo de execução.

Testar a segurança sem servidor exige ferramentas específicas: o PureSec CLI (agora Check Point) e o Prowler verificam configurações da nuvem em busca de configurações incorretas em ambientes sem servidor; as ferramentas DAST podem testar funções acionadas por HTTP quanto a vulnerabilidades de injeção; a análise estática do código das funções, com ferramentas como Bandit (Python) ou plug-ins de segurança do ESLint, detecta padrões de codificação inseguros; e os testes manuais devem enumerar todas as fontes de eventos capazes de acionar cada função e testar cada uma delas com cargas úteis malformadas e maliciosas. O OWASP Serverless Top 10 fornece uma lista abrangente de verificação de vulnerabilidades específica para arquiteturas sem servidor.

A computação sem servidor amplia o modelo de responsabilidade compartilhada, transferindo-o ainda mais para o provedor. O provedor de nuvem é responsável por: o ambiente de execução da função, as correções do OS, a segurança da infraestrutura subjacente e as instalações físicas. O cliente continua responsável por: segurança do código da função, design das permissões do IAM, gerenciamento de segredos, validação das entradas, gerenciamento de dependências, configuração de registros e políticas de rede. A redução da responsabilidade pela infraestrutura não significa redução da responsabilidade pela segurança — apenas muda o foco do investimento em segurança, principalmente para a segurança no nível da aplicação e do IAM.

Avalie sua compreensão dos conceitos do CompTIA Security+ (SY0-701) apresentados nesta lição.

Nesta lição, você aprendeu que: as funções do IAM com privilégios excessivos são o principal risco em ambientes sem servidor — cada função precisa de uma função dedicada com menor privilégio; os ataques de injeção de eventos exploram qualquer fonte de eventos que entregue dados controlados por um invasor a funções sem validação das entradas; e o risco da cadeia de fornecimento de dependências provenientes de pacotes de terceiros pode comprometer a execução das funções, permitindo acesso a credenciais do IAM e segredos. A seguir, exploraremos a verificação de segurança da infraestrutura como código para detectar configurações incorretas antes da implantação.