O que é segurança sem servidor?

Aplicativos sem servidor exigem segurança sem servidor

A cada grande avanço no desenvolvimento de software e nas operações de TI, ocorre uma mudança nos vetores de ataque e nos riscos de segurança. Nos primeiros dias da virtualização para contêineres, os profissionais de segurança tiveram que se adaptar e encontrar novas maneiras de fortalecer, defender e governar sua infraestrutura. O conceito de um aplicativo sem servidor apresenta uma das maiores mudanças de paradigma já vistas quando se trata de segurança de aplicativos.

Tradicionalmente, as organizações protegiam seus aplicativos com base em ferramentas baseadas em infraestrutura e rede. Eles inspecionariam o tráfego com um firewall, tentariam detectar atividades mal-intencionadas com um sistema de detecção de intrusão ou protegeriam os aplicativos com a tecnologia de autoproteção de aplicativos em tempo de execução, ou RASP. Mesmo com contêineres, as organizações ainda podem contar com a segurança da infraestrutura subjacente até certo ponto.

Um aplicativo sem servidor consiste em serviços de nuvem distribuídos trabalhando juntos, como um bucket S3 que aciona uma função Lambda, que, por sua vez, aciona o DynamoDB^®. Nessa arquitetura, não há espaço para firewalls, ferramentas IDS/IPS ou qualquer tipo de agente de instrumentação ou métodos de proteção baseados em servidor. Em vez de se concentrar na inspeção da rede e nas listas de controle de acesso, o modelo sem servidor muda o foco da segurança para permissões de IAM, proteção comportamental e código forte.

Vetores de ataque sem servidor

A adoção da segurança sem servidor oferece aos aplicativos uma grande vantagem do ponto de vista da segurança, pois as organizações não precisam mais se preocupar com a segurança da infraestrutura, da rede ou do host. No entanto, surgiram novos vetores de ataque e ataques conhecidos foram reimaginados para ambientes sem servidor. Vamos dar uma olhada em um exemplo (para ver a lista completa, consulte o artigo Top 12 Risks for Serverless Applicationsda Cloud Security Alliance):

Injeção de dados de eventos

As falhas de injeção em aplicativos, que estão entre os riscos mais comuns até o momento, foram abordadas detalhadamente em muitos guias de práticas recomendadas de codificação segura. Em um nível mais alto, as falhas de injeção ocorrem quando uma entrada não confiável é passada diretamente para um intérprete antes de ser executada ou avaliada. No contexto da arquitetura sem servidor, no entanto, as injeções de dados de eventos de função não estão estritamente limitadas à entrada direta do usuário (como a entrada de uma chamada de API da Web). A maioria das arquiteturas sem servidor oferece uma infinidade de fontes de eventos que podem acionar a execução de uma função sem servidor.

Os exemplos de fontes de injeção de dados de eventos incluem:

• Eventos de armazenamento em nuvem (por exemplo, AWS S3^®, Azure Blob Storage, Google Cloud Storage)
• Eventos de banco de dados NoSQL (por exemplo, AWS DynamoDB, Azure Cosmos DB^®)
• Eventos do banco de dados SQL
• Eventos de processamento de fluxo (por exemplo, Amazon Kinesis^®)
• Alterações de código e novos repositórios de código
• Chamadas de API HTTP

Cada entrada de evento pode incluir diferentes formatos de mensagem, e várias partes dessas mensagens de evento podem conter entradas controladas pelo invasor ou perigosas de outra forma. O rico conjunto de fontes de eventos aumenta a superfície de ataque em potencial e introduz complexidades ao tentar proteger as funções sem servidor contra injeções de dados de eventos. Isso é especialmente verdadeiro porque as arquiteturas sem servidor não são tão bem compreendidas quanto os ambientes da Web, onde os desenvolvedores sabem quais partes da mensagem não devem ser confiáveis (por exemplo, parâmetros GET/POST, cabeçalhos HTTP etc.).

Proteção de aplicativos sem servidor

A segurança sem servidor eficaz se concentra em garantir a integridade do código, permissões rígidas e análise comportamental.

• Acesso e permissões: Mantenha o acesso com privilégios mínimos para funções sem servidor e outros serviços. Por exemplo, se uma função do AWS Lambda precisar acessar uma tabela do DynamoDB, certifique-se de que ela só possa executar a ação específica que a lógica de negócios exige.
• Varredura de vulnerabilidades: Garanta a integridade do código e do modelo de infraestrutura como código verificando regularmente se há dependências vulneráveis de terceiros, erros de configuração e funções excessivamente permissivas.
• Proteção de tempo de execução: Use a proteção de tempo de execução para detectar entradas de eventos maliciosos e comportamentos anômalos de funções e limitar, conforme necessário, a capacidade de cada função de acessar arquivos, hosts, a Internet e gerar processos filhos.

Perguntas frequentes sobre serverless