Implicações de segurança do serverless: da infraestrutura ao OWASP

Por sua própria natureza, o serverless (FaaS) resolve algumas das maiores preocupações de segurança atuais. Ao eliminar o gerenciamento da infraestrutura, transfere as questões de segurança para o provedor da plataforma. Infelizmente, os invasores não vão simplesmente desistir: eles vão se adaptar a essa nova realidade. Mais especificamente, o FaaS vai redirecionar o foco dos invasores dos servidores para as questões de aplicação destacadas pelo OWASP — e os defensores devem ajustar suas prioridades de acordo.

Este artigo aborda quais preocupações de segurança o serverless ajuda a resolver e quais não. Cada um destes tópicos provavelmente renderia um artigo completo (que talvez eu escreva mais adiante!), mas aqui vou deixar de lado os detalhes de correção e gerenciamento de riscos para focar no panorama geral.

Veja um resumo rápido das principais áreas de atenção.

Agora, vamos aos detalhes!

Como o serverless ajuda na segurança?

O serverless transfere a responsabilidade pelo gerenciamento dos servidores do responsável pela aplicação para o provedor da plataforma. Esses servidores dão bastante trabalho para proteger, mas os especialistas que gerenciam as plataformas fazem isso muito bem. Por isso, veja as três principais ameaças à segurança que o serverless reduz drasticamente.

1. Nenhum servidor sem correções, nenhum binário vulnerável

Em primeiro lugar, o serverless praticamente elimina a principal fonte de explorações bem-sucedidas hoje: servidores sem correções. Esses servidores usam binários com vulnerabilidades conhecidas porque não receberam as atualizações de segurança mais recentes dessas dependências. Segundo a maioria das estimativas, as dependências com vulnerabilidades conhecidas estão por trás da grande maioria das explorações bem-sucedidas atuais.

Embora o serverless não elimine a necessidade de manter os servidores atualizados, essa responsabilidade passa para o provedor da plataforma. Gerenciar servidores é uma de suas principais competências; por isso, é muito pouco provável que as máquinas fiquem desatualizadas.

2. A negação de serviço vira uma questão de cobrança

Os ataques de negação de serviço (DoS) impedem um servidor de atender a solicitações legítimas e repetem o ataque até que todos os servidores capazes de atender a uma solicitação fiquem indisponíveis. Com FaaS, os servidores são provisionados sob demanda e descartados (estou ignorando as otimizações de desempenho específicas de cada plataforma), o que torna sem sentido a ideia de “derrubar um servidor”. Sempre que uma nova solicitação chega, legítima ou não, a plataforma provisiona um servidor e executa a função solicitada.

Vale lembrar que, embora conceitualmente o serverless elimine o DoS como ameaça à disponibilidade, as plataformas impõem limites de simultaneidade que você deve conhecer. Por padrão, o AWS Lambda limita a 600 execuções simultâneas de funções. Além disso, um ataque DoS ainda pode gerar uma conta de uso enorme, algo quase tão desagradável quanto o próprio ataque. Portanto, não seja complacente com o tempo de execução nem com as vulnerabilidades ReDoS.

3. A imutabilidade elimina servidores comprometidos

Em muitos ataques, explorar uma vulnerabilidade é apenas o primeiro passo. Em vez de repetir os ataques, os invasores tentam comprometer o servidor e instalar um agente malicioso para realizar ataques posteriores e mais profundos. Alguns dos ataques mais danosos, como as violações sofridas pela Sony e pela Target, envolvem servidores comprometidos desse tipo.

No FaaS, os servidores são imutáveis e têm vida curta, o que elimina implicitamente a possibilidade de um servidor comprometido permanecer ativo por muito tempo. Essa proteção pouco reduz a chance de um ataque bem-sucedido, mas ajuda bastante a limitar o que pode acontecer depois da exploração e, com isso, os danos que o ataque pode causar.

Quais preocupações de segurança continuam iguais?

Como vimos, o serverless tira das nossas mãos, como responsáveis pelas aplicações, algumas ameaças importantes. Isso significa que os invasores vão simplesmente desistir de atacar aplicações serverless? É claro que não.

Veja as três principais preocupações de segurança que o serverless não resolve. Embora o FaaS não agrave essas questões, a eliminação das ameaças mencionadas anteriormente naturalmente faz com que elas subam na lista de prioridades dos invasores. Por isso, é mais importante do que nunca prestar atenção a esses riscos e resolvê-los.

4. As vulnerabilidades no seu código continuam lá

O serverless tira boa parte do “entorno” das suas mãos, mas o que sobra é o seu próprio código — inclusive as vulnerabilidades. As vulnerabilidades na aplicação (por exemplo, cross-site scripting e injeção de SQL) continuam graves quando exploradas, e as técnicas de mitigação (como validação de entradas e acesso programático ao banco de dados) são tão importantes quanto sempre foram.

As práticas recomendadas continuam as mesmas. Use ferramentas de teste de segurança estático (SAST) e dinâmico (DAST), facilite a validação de entradas e prefira listas de permissões sempre que possível. O guia OWASP Top Ten traz ótimas recomendações sobre o tema, assim como sua folha de dicas.

5. Inclusão de dependências vulneráveis da aplicação

À primeira vista, as funções FaaS parecem conter apenas o seu código — mas isso não é bem verdade. Elas também incluem dependências da aplicação, obtidas do npm (Node.js), PyPI (Python), Maven (Java) ou de outras plataformas relevantes. Esses pacotes de código são como pequenos componentes de infraestrutura incorporados à sua aplicação.

As dependências de aplicações se parecem com as dependências de servidores frequentemente exploradas. Elas são onipresentes, baixadas bilhões de vezes por mês; é difícil acompanhar quais pacotes você usa; e muitas têm vulnerabilidades, que são divulgadas regularmente. Os invasores já exploram dependências vulneráveis de aplicações. Sem o caminho fácil das dependências vulneráveis de servidores, eles vão passar a atacar essas entidades semelhantes com força total.

As vulnerabilidades conhecidas são tão fáceis de descobrir para você quanto para os invasores. Para proteger as dependências da aplicação, é preciso ter acesso a um bom banco de dados e a ferramentas automatizadas que impeçam continuamente a inclusão de novos pacotes vulneráveis e alertem sobre problemas recém-divulgados. Com a Snyk, todo esse processo fica muito fácil, e recomendo que você experimente! Caso contrário, escolha a ferramenta que melhor atenda às suas necessidades e à sua plataforma, mas não deixe esse problema de lado.

6. Dados “em repouso” igualmente acessíveis

Por fim, o serverless não impede que invasores acessem seu banco de dados. Se alguém obtiver acesso aos seus dados por meio de uma das vulnerabilidades mencionadas, de credenciais vazadas, de um funcionário interno comprometido ou de qualquer outra forma, o FaaS não fará diferença.

Se você armazena informações confidenciais, criptografe-as corretamente. Algoritmos criptográficos de código aberto estão amplamente disponíveis, então não há justificativa para deixar de usá-los. Além disso, evite dar acesso ao banco de dados a todo mundo (até mesmo só para leitura!) e conceda acesso apenas às pessoas e aos sistemas que realmente precisam dele. O FaaS permite um controle mais granular, limitando o acesso às funções que usam o banco de dados diretamente. Por fim, não exponha seus repositórios de dados diretamente à internet: como vimos no recente ataque ao MongoDB e nas declarações explícitas do Redis, esses sistemas foram criados para uso interno.

Marquei esta questão como “neutra”, já que o serverless não prejudica a segurança dos dados em repouso. No entanto, como as funções são sempre sem estado, em alguns casos o estado — incluindo os dados confidenciais armazenados nele — passa de um armazenamento local (por exemplo, sistema de arquivos ou memória) para um armazenamento em rede (por exemplo, Redis ou filas). Aplique a esses armazenamentos temporários as mesmas práticas de segurança de dados que você usa para armazenamentos persistentes, como bancos de dados.

Quais preocupações de segurança o serverless agrava?

O serverless não cria novas preocupações de segurança, mas amplifica algumas delas. A arquitetura que ele impulsiona significa que adotamos mais certas práticas e, com isso, ampliamos as preocupações de segurança associadas a elas. Vamos analisar as três principais áreas em que o serverless dificulta a segurança.

7. Serviços de terceiros e dados “em trânsito”

O FaaS não faz você armazenar mais dados, mas certamente faz com que você mova mais dados de um lado para o outro. Dados que antes permaneciam na máquina agora passam entre funções muitas vezes, frequentemente com pequenas alterações entre chamadas. Além disso, a granularidade e a natureza sem estado levam a um maior uso de serviços de terceiros, o que exige enviar e receber dados pela rede.

Cada vez que nos comunicamos, existe o risco de os dados serem vazados ou adulterados. Além disso, ao nos comunicarmos, confiamos implicitamente os dados enviados e recebidos à outra parte, criando uma oportunidade para que essa confiança seja explorada. Como há mais comunicação no FaaS, precisamos dar mais atenção a esse risco e nos proteger melhor contra ele.

A segurança de dados é um tema amplo, mas recomendo focar em duas áreas: criptografia e confiança. Primeiro, criptografe todos os dados usando HTTPS ou chaves e um KMS. Ambas as técnicas também ajudam a validar a identidade da outra parte. Segundo, desconfie de todas as entradas recebidas de uma função ou serviço com o qual você se comunica, mesmo que seja outra função. Se uma função confiar implicitamente em outra — quanto mais em um serviço de terceiros —, você logo criará uma cadeia frágil que se rompe quando um componente se torna malicioso ou é comprometido.

8. Mais flexibilidade amplia a superfície de ataque

Uma das principais vantagens do serverless é a flexibilidade, que permite transferir o fluxo de controle para o cliente e atender a mais casos de uso sem alterar o código do lado do servidor. Infelizmente, mais flexibilidade também dá aos invasores mais oportunidades de fazer seu sistema executar ações indesejadas. Nas palavras de Mark Nunnikhoven: “Os desenvolvedores se concentram em resolver um problema; a segurança analisa o que mais pode ser feito com essas soluções”.

A única forma de lidar com esse risco é tratar cada função como seu próprio perímetro de segurança. Isso significa que cada função precisa higienizar entradas e saídas, proteger seus dados e cuidar da segurança do próprio código e de suas dependências. Hoje, a maioria dos sistemas tem um perímetro rígido, mas um interior pouco protegido. O FaaS amplia muito esse perímetro e exige um conjunto mais abrangente de defesas.

Felizmente, o FaaS oferece duas ótimas oportunidades para aplicar essa proteção abrangente. Primeiro, as funções são naturalmente menores, o que facilita (embora não seja trivial) definir melhor o que podem e não podem fazer em comparação com uma aplicação completa, além de aplicar essas regras no código e nos testes unitários. Segundo, funções costumam ser invocadas por usuários externos por meio do API Gateway, que permite definir um modelo ou esquema para as chamadas e impor restrições mais rigorosas às entradas e saídas permitidas. Aproveite essas oportunidades e proteja cada função individualmente.

9. O monitoramento de segurança fica extremamente difícil

Com o serverless, fica ridiculamente fácil implantar código. Colocar uma função em produção praticamente não custa nada, e os custos de execução são tão baixos e granulares que uma função pouco utilizada mal aparece na conta. Isso significa que não há incentivo financeiro para não implantar uma função nem para removê-la depois. Para piorar, não há uma maneira fácil de acompanhar quem usa uma função, então removê-la depois de implantada é arriscado — abrindo caminho para milhares de funções raramente usadas em produção.

Reduzir as barreiras à implantação é ótimo para a produtividade, mas cria um pesadelo de segurança. Cada função implantada é um possível alvo de ataque, com vulnerabilidades que podem ser exploradas para invadir suas redes privadas, manipular seu banco de dados ou realizar ataques em seu nome. As dependências de aplicações incorporadas a essas funções ficam desatualizadas, e novas vulnerabilidades são descobertas nelas, facilitando a automação desses ataques. A complexidade dos sistemas de monitoramento é o que torna as dependências vulneráveis tão fáceis de explorar e tão difíceis de proteger.

Para piorar, as soluções atuais de monitoramento de segurança não funcionam em um ambiente sem servidor. A maioria delas exige um agente em um servidor de longa duração (que agora não existe); tem uma sobrecarga de inicialização e execução alta demais para ser viável em FaaS; e não consegue escalar sob demanda como as plataformas sem servidor. Além disso, essas soluções são estruturadas em torno de uma aplicação de ponta a ponta, e sua lógica e interface não foram projetadas para a granularidade extrema do ambiente sem servidor.

Esse é um desafio de todo o ecossistema e exige novas abordagens. Acompanhe de perto quais funções são implantadas, quem as utiliza e quais dependências elas usam. Embora o custo operacional de executar uma função seja baixo, não se esqueça do custo total de propriedade, que inclui o risco maior de manter em produção código não utilizado, vulnerável ou desatualizado.

Com o tempo, precisamos que as soluções de monitoramento de segurança em tempo de execução evoluam e se adaptem para funcionar sem agentes, com baixa sobrecarga e em grande escala. Também precisamos de alternativas às soluções de monitoramento de infraestrutura que permitam acompanhar dependências vulneráveis de aplicações em todas as funções e ajudem você a atualizar ou remover funções problemáticas. Aqui na Snyk, vamos fazer a nossa parte e estamos trabalhando para ampliar nossa solução de CI/CD para dependências vulneráveis de aplicações, de modo que ela monitore diretamente as funções implantadas — fale com a gente se quiser participar da versão beta!

Resumo

A computação sem servidor é incrível e está revolucionando a forma como operamos aplicações. Com ela, chega também ao mundo da segurança um evento sísmico de proporções semelhantes: algumas preocupações de segurança são resolvidas, outras ganham importância e as prioridades das demais mudam. Neste post, tentei destacar as três principais áreas em que FaaS é melhor, equivalente ou pior para a segurança na web em comparação com outras técnicas de computação em nuvem. Veja a seguir uma tabela resumida:

Como a computação sem servidor é recente, temos a oportunidade de tornar as práticas e ferramentas de segurança parte natural do desenvolvimento de aplicações sem servidor. Estou particularmente animado para ver essa abordagem crescer e alcançar todo o seu potencial, tanto para operações quanto para segurança.