A tecnologia serverless não está imune a riscos e ameaças. Nossa pesquisa de segurança fornece uma análise abrangente dos possíveis cenários de comprometimento e ataque em implantações e serviços serverless.
Arquiteturas serverless e sua segurança
A grande mudança para a computação serverless é iminente. De acordo com uma pesquisa de 2019, 21% das empresas já adotaram esse tipo de tecnologia, enquanto 39% a estão considerando. A tecnologia serverless atrai muitas empresas, uma vez que permite que elas se concentrem na criação de um código melhor para suas aplicações, ao invés de gerenciar e proteger a infraestrutura necessária para executá-las.
A computação serverless refere-se à tecnologia que oferece suporte a serviços de back-end e permite que as empresas aproveitem a transferência de certas responsabilidades para provedores de serviços em nuvem (CSPs), como Amazon Web Services (AWS), incluindo gerenciamento de capacidade, patching e disponibilidade. Com essa computação, as empresas podem criar aplicações de back-end sem estar diretamente envolvidas na disponibilidade e escalabilidade. O termo “serverless”, no entanto, não significa que este modelo de computação não usa servidores, porque usa. Acontece que as empresas não precisam mais estar diretamente envolvidas na manutenção e proteção de servidores.
A segurança de arquiteturas serverless é garantida em sua maior parte por CSPs, que lidam com a segurança dos componentes de computação de infraestrutura da tecnologia serverless. É por isso que esta tecnologia é considerada relativamente mais segura do que outros modelos de computação em nuvem. Entretanto, como qualquer outra tecnologia existente, não é imune a riscos e ameaças.
Nosso artigo de pesquisa “Protegendo Pontos Fracos em Arquiteturas Serverless: Riscos e Recomendações” visa esclarecer as considerações de segurança em ambientes serverless e ajudar os usuários a manter suas implantações serverless o mais seguras possível. Ele se concentra nos serviços oferecidos pela AWS, que tem a mais ampla variedade de ofertas disponíveis no mercado de serviços serverless.
Serviços conectados em uma arquitetura serverless
Entender como uma arquitetura serverless opera envolve compreender os diferentes serviços envolvidos nela. Aqui, discutimos os serviços conectados em uma arquitetura serverless AWS.
Exemplos de serviços interconectados em uma arquitetura serverless da AWS
Amazon S3
O Amazon Simple Storage Service (Amazon S3) é um serviço de armazenamento de objeto para uma quantidade escalável de dados que oferece suporte a uma variedade de casos de uso, como aplicações móveis, análise de big data e dispositivos de Internet das coisas (IoT). O Amazon S3 permite que as empresas gerenciem objetos, que são armazenados em depósitos por meio de APIs.
Amazon API Gateway
O Amazon API Gateway permite a criação, publicação, manutenção, monitoramento e proteção fácil e eficiente de APIs. Ele atua como um portal para aplicações permitindo que elas acessem funcionalidades de serviço de back-end ou dados usando APIs RESTful e APIs WebSocket.
AWS Lambda
Um dos serviços serverless mais populares da atualidade, o AWS Lambda permite que as empresas executem código sem o incômodo de provisionamento e manutenção de servidor. Com ele, os desenvolvedores podem executar o código e pagar apenas pelo número de instâncias quando o código é acionado. O AWS Lambda permite que eles se concentrem em suas tarefas sem ter que gerenciar o hardware ou garantir que o sistema operacional e todas as aplicações instaladas estejam atualizadas.
AWS IAM
O AWS Identity and Access Management (AWS IAM) permite que os desenvolvedores gerenciem credenciais e permissões de segurança para confirmar o acesso a serviços e recursos serverless.
Configurações incorretas e práticas de codificação não seguras
Os principais CSPs, como a AWS, incentivam os usuários a seguirem o princípio de menor privilégio ao conceder permissões para tarefas específicas. Eles também fornecem maneiras para os usuários aplicarem a abordagem de negação padrão, que garante que cada serviço não possa se comunicar ou não seja acessível a outro, a menos que as permissões necessárias sejam concedidas. A atribuição e verificação manual de privilégios aumenta a segurança, mas pode ser difícil para os usuários, especialmente devido a uma combinação complexa de serviços conectados. Consequentemente, os usuários podem introduzir ou ignorar configurações incorretas e riscos, como os seguintes, ao proteger serviços serverless.
Amazon S3
Os buckets do Amazon S3 que são deixados abertos ou acessíveis publicamente podem fornecer uma abertura para que agentes mal-intencionados procurem dados confidenciais. Dados críticos ou partes de código que não deveriam ser publicamente visíveis também podem ser expostos quando os buckets do Amazon S3 são usados para hospedar tipos de conteúdo que eles não deveriam hospedar em primeiro lugar.
AWS Lambda
As funções do AWS Lambda podem ser exploradas por agentes mal-intencionados por meio de técnicas de injeção usadas em código ruim ou vulnerável. Enquanto isso, dados confidenciais podem ser expostos se o código de uma função do AWS Lambda for projetado para retornar variáveis e for acessível de serviços externos. Agentes mal-intencionados também podem tirar proveito das credenciais salvas nas funções do AWS Lambda como variáveis para obter acesso à conta de um usuário. Além disso, atacantes podem explorar códigos ruins para salvar suas ferramentas e scripts maliciosos dentro de uma pasta /tmp do ambiente de execução do AWS Lambda, na qual os arquivos podem ser persistentes o suficiente para lançar ataques ou exfiltrar dados confidenciais.
Amazon API Gateway
Quando um endpoint do Amazon API Gateway é deixado aberto e exposto, ele pode ser explorado para acionar um ataque de negação de serviço (DoS) em uma tentativa de comprometer ou desligar o serviço por trás dele. Agentes mal-intencionados que procuram infligir danos financeiros a uma empresa também podem abusar de um endpoint aberto do Amazon API Gateway para consultar uma função do AWS Lambda sem parar, o que faria com que a conta da empresa aumentasse.
AWS IAM
Possivelmente devido a restrições de tempo, os desenvolvedores às vezes optam por fazer políticas excessivamente permissivas para garantir a comunicação entre os componentes do sistema, o que é facilitado pelo AWS IAM. Mas esse afrouxamento das permissões obviamente afeta a segurança dos serviços serverless com os quais o AWS IAM é usado.
Quais as consequências de código ruim em um sistema serverless?
Para destacar ainda mais os riscos de implementação de código incorreto em um sistema serverless, criamos uma prova de conceito que envolve uma função AWS Lambda concedida com permissões altas. Por meio deste vídeo, mostramos como as práticas de codificação inadequadas podem permitir que agentes mal-intencionados alterem com sucesso o tempo limite da função do AWS Lambda e subsequentemente realizem outras atividades, como escalonamento de privilégios e exfiltração de dados.
Impacto nas empresas de riscos de segurança para serviços serverless
Como os serviços serverless têm funções stateless, os dados nesses serviços permanecem ocultos e não são armazenados na memória. Ao mover dados de serviços serverless para locais externos, as empresas devem estar cientes de como os dados são movidos para evitar vazamentos. Foi o que aconteceu quando um banco de dados contendo meio milhão de documentos jurídicos e financeiros confidenciais foi exposto devido a uma configuração incorreta que ocorreu quando as políticas de acesso foram alteradas.
Também é importante saber onde os dados estão armazenados para garantir que não haja problemas de conformidade, como quando mais de 36.000 registros de presidiários de várias instalações correcionais nos EUA vazaram, porque um repositório de dados associado a uma aplicação baseada em nuvem foi deixado aberto. O comprometimento da aplicação ou serviço de uma empresa pode muito bem resultar em interrupção dos negócios e danos à reputação.
Protegendo serviços e implantações serverless
Os serviços serverless não estão acima dos riscos e ameaças. Na verdade, nossa pesquisa fornece uma discussão abrangente sobre os possíveis cenários de comprometimento e ataque envolvendo serviços serverless. Entretanto, existem maneiras de manter os serviços serverless e os deploys seguros.
Os usuários devem entender que o modelo de responsabilidade compartilhada, no qual o CSP e o usuário mantêm zonas de responsabilidade para manter o ambiente de nuvem seguro, também se aplica à computação serverless. Em nosso artigo de pesquisa, fornecemos maneiras pelas quais serviços e implantações serverless podem ser protegidos contra riscos e ameaças por meio de práticas recomendadas e soluções de segurança. Também damos recomendações sobre como criar aplicações seguras serverless.
À medida que mais empresas mudam para a tecnologia serverless e mais aplicações são criadas nela, manter os serviços e implantações serverless seguros se torna mais crítico. Nosso documento de pesquisa “Protegendo Pontos Fracos em Arquiteturas Serverless: Riscos e Recomendações” fornece informações vitais e orientações que as empresas podem usar para manter seus ambientes serverless protegidos contra configurações incorretas, erros e práticas de codificação inseguras, quer já estejam usando tecnologia serverless ou estejam apenas planejando mudar para ele.
