O que é segurança sem servidor?

O que é computação sem servidor?

A computação sem servidor refere-se a um modelo de computação em nuvem no qual o provedor de nuvem executa o servidor e gerencia dinamicamente a alocação de recursos da máquina. AWS Lambda Functions, Google nuvem Functions e Azure Functions são estruturas populares sem servidor que criam aplicativos.

Uma arquitetura sem servidor oferece o benefício de escalabilidade automatizada e quase infinita. Muito pouco se interpõe entre os desenvolvedores e o código implantado, o que acelera o tempo de lançamento no mercado e facilita a manutenção e o teste de funções individuais. Por fim, a quantidade real de recursos do aplicativo consumidos impacta os preços, o que significa que você paga apenas pelo que usa, resultando em custos mais baixos.

Serverless representa uma mudança adicional de responsabilidades do cliente para o provedor de nuvem. Sem infraestrutura envolvida, há uma diminuição significativa nas despesas gerais de operações.

Transferir o gerenciamento da infraestrutura para seu provedor de nuvem permite que você se concentre no desenvolvimento de soluções para atender sua organização e seus clientes. Ele ajuda você a manter o foco em suas vantagens competitivas exclusivas e frequentemente resulta em economia de custos não apenas em computação, mas também na transferência de pessoas para o desenvolvimento.

Como o Serverless melhora a segurança?

Aqui estão alguns pontos-chave:

1. Os provedores de nuvem cuidam do sistema operacional, da segurança do tempo de execução e dos patches. Ao implantar um aplicativo sem servidor, você cede o controle da maior parte da pilha ao seu provedor de nuvem, e ele fornece serviços como gerenciamento de chaves. Você não possui mais proteção SO, direitos de administrador, SSH e segmentação. AWS, Microsoft e Google são confiáveis em manter suas partes da pilha corrigidas e seguras, portanto, dar a eles uma porção maior da pilha certamente melhora as coisas nesse sentido.
2. Apátrida/Efêmero. Além disso, a natureza efêmera e sem estado da computação sem servidor dificulta a vida dos invasores. Funções sem servidor, como AWS Lambda, são executadas por alguns segundos e depois morrem. Os recipientes são reciclados. O fato de funções sem servidor irem e virem, sem memória, reduz o risco de ataques de longo prazo.
3. Visibilidade em aplicativos sem servidor – O benefício. O fato de os aplicativos sem servidor serem estruturados como um grande número de pequenas funções na nuvem oferece uma oportunidade fantástica de segurança. As ferramentas de segurança de aplicativos geralmente fazem de tudo para analisar e instrumentar seu aplicativo empacotado apenas para poder observar ou filtrar o fluxo interno de seu aplicativo.
4. Microsserviço menor = A capacidade de construir papéis mínimos e adequados para cada função. Mudar para microsserviços menores permite que você faça um IAM mais refinado. Você tem a oportunidade de aplicar políticas de segurança a cada uma dessas pequenas coisas, o que pode reduzir significativamente a superfície de ataque.

Contanto que qualquer função dentro de um contêiner precise de acesso para leitura do S3, todas as funções dentro desse contêiner também terão esse privilégio. Com o AWS Lambda, você tem a oportunidade de aplicar privilégios a funções individuais e garantir que tais privilégios sejam restritos apenas ao menor escopo necessário. Se houver uma vulnerabilidade em uma de suas funções, um invasor terá acesso apenas aos recursos limitados dessa função, e não ao grande conjunto de permissões para conceder um contêiner.

Quais são os desafios da segurança sem servidor?

Com a mudança na estrutura dos aplicativos sem servidor, surgem alguns novos desafios.

1. A visibilidade da segurança se torna mais difícil. A quantidade total de informações e o número de recursos aumentam com a tecnologia sem servidor. Isso prejudica sua capacidade de entender todos os dados. Com um bilhão de eventos em seu registro todos os dias, é um desafio obter inteligência das montanhas de dados para uma verdadeira observabilidade.
2. Protocolos, vetores e pontos de ataque se multiplicaram para todas as funções, e Protocolo = um ponto potencial de ataque. Isso requer abordagens exclusivas para segurança do Google Functions, Azure Functions e AWS Lambda.
3. Mais recursos = mais permissões para gerenciar. Mais recursos equivalem a mais permissões para gerenciar, criando desafios na determinação de permissões para todas essas interações. A tecnologia automatizada pode detectar riscos de configuração e gerar automaticamente permissões de funções com privilégios mínimos.
4. Observabilidade em aplicativos sem servidor – o desafio. Os aplicativos sem servidor usam diferentes serviços de vários provedores de nuvem, em diversas versões e regiões. Para compreender a superfície de ataque e os riscos potenciais, você precisa de uma visão abrangente de todo o seu ecossistema sem servidor. À medida que seu aplicativo se propaga, essa visão focada na segurança pode ser cada vez mais desafiadora de construir e manter.

Onde Implantar Segurança sem Servidor?

Com o aplicativo sem servidor, não há onde colocar a segurança clássica, como WAF, firewall e IDS. Construir barreiras entre invasores e recursos não é simples por vários motivos.

1. Embora a implantação mais rápida e frequente possa ser muito positiva, a velocidade do serverless pode levantar novos desafios na configuração da segurança.
2. As ferramentas de segurança podem aumentar o tempo de processamento, que deve ser multiplicado por todas as solicitações. Felizmente, a maioria das práticas recomendadas de Segurança sem servidor não exige nenhum tempo de processamento adicional.
3. Erosão do Perímetro. O aplicativo tradicional tinha um limite claro. O exterior e o interior eram distintos e podíamos fazer segurança no perímetro. Embora não seja ideal que a segurança permaneça exclusivamente no perímetro, ainda foi possível construir um muro.

Os aplicativos sem servidor são mais porosos e refinados. Composto por dezenas ou centenas de funções, os aplicativos serverless são pequenos microsserviços com políticas, funções, API, trilha de auditoria próprias, etc. Isso muda a superfície de ataque, em vez de um pequeno número de pontos de entrada com muitas funcionalidades escondidas atrás de cada um, agora existem mais pontos de entrada, cada um com uma pequena parte do aplicativo por trás dele. Defender seu aplicativo agora exige pensar em cada ponto de entrada.

Vários eventos podem acionar funções, como:

• Eventos de armazenamento em nuvem (por exemplo AWS S3, armazenamento de Blobs do Azure, armazenamento em nuvem do Google)
• Processamento de dados de fluxo (por exemplo AWS Kinesis)
• Mudanças nos bancos de dados (por exemplo AWS DynamoDB, Azure CosmosDB)
• Modificações de código (por exemplo AWS CodeCommit)
• Notificações (por exemplo, SMS, e-mails, IoT)

O que são ameaças à segurança sem servidor?

Embora as motivações dos invasores permaneçam as mesmas, as táticas que eles usarão com aplicativos sem servidor devem mudar. A seguir estão algumas das ameaças à Segurança sem Servidor exclusivas desta nova arquitetura de aplicativo.

1. A ameaça das funções superprivilegiadas

Com o aplicativo sem servidor, você tem a oportunidade de aplicar privilégios a funções individuais e garantir que tais privilégios sejam restritos apenas ao menor escopo necessário. Isso pode permitir minimizar significativamente sua superfície de ataque, bem como mitigar o impacto de qualquer ataque.

Infelizmente, uma pesquisa recente da Check Point descobriu que a grande maioria dos desenvolvedores não está aproveitando esta oportunidade. Nossa pesquisa descobriu que 98% das funções em aplicativos sem servidor estão em risco, sendo 16% consideradas “graves”. Além disso, a maioria dessas funções recebe mais permissões do que o necessário, que podem ser removidas para melhorar a segurança da função e do aplicativo.

Ao analisar funções, a Check Point atribui uma pontuação de risco a cada função. Isto se baseia nas fraquezas posturais descobertas e leva em consideração não apenas a natureza da fraqueza, mas também o contexto em que ela ocorre. Depois de verificar dezenas de milhares de funções em aplicativos ativos, descobrimos que a maioria dos aplicativos sem servidor simplesmente não está sendo implantada com a segurança necessária para minimizar os riscos. Os maiores problemas de postura de segurança descobertos pela Check Point são permissões desnecessárias, enquanto o restante está relacionado a códigos e configurações vulneráveis.

2. O Ataque do Dia da Marmota

O fato de as funções sem servidor serem efêmeras e de curta duração torna mais difícil para os invasores persistirem em seu aplicativo a longo prazo. Além disso, esta é uma das muitas vantagens de segurança do serverless. Contudo, o simples facto de isto tornar a vida mais difícil aos atacantes não significa que eles irão parar os ataques; eles apenas mudarão a estratégia.

A curta duração das funções serverless significa que as ameaças à Segurança sem Servidor podem mudar de forma. Os invasores podem construir um ataque muito mais curto que apenas roube, por exemplo, alguns números de cartão de crédito. Esta única rodada de ataque se repete continuamente no que chamamos de ataque do “Dia da Marmota”.

3. Envenenando o Poço

Apesar da curta vida útil dos recursos nativos da nuvem, os invasores ainda podem encontrar maneiras de obter persistência de longo prazo em seu aplicativo. Uma maneira pela qual os invasores podem contornar a natureza efêmera do aplicativo sem servidor é por meio de um ataque upstream, ou “Envenenando o Poço”.

Os aplicativos nativos da nuvem tendem a incluir muitos módulos e bibliotecas com código de diversas fontes de terceiros. Os invasores trabalham para incluir códigos maliciosos em projetos comuns. Então, depois de envenenar o poço, o código malicioso em seus aplicativos em nuvem pode ligar para casa, obter instruções e causar estragos.

4. Aumento do tempo de configuração da segurança sem servidor

Embora isso não seja exatamente uma “ameaça” à segurança, é mais um desafio e um possível obstáculo aos seus esforços para proteger sua arquitetura sem servidor.

Serverless transmite o benefício de maior velocidade de desenvolvimento de aplicativos. Infelizmente, a abordagem tradicional de segurança, em que os desenvolvedores escrevem códigos e empacotam cargas de trabalho e as operações de segurança colocam controles de segurança em torno dessas cargas de trabalho, simplesmente não funcionará sem servidor.

Se os desenvolvedores precisarem esperar que a segurança abra portas, funções IAM ou grupos de segurança para eles, o benefício do aumento da velocidade será rapidamente reduzido. Muitas vezes, a solução é remover o SecOps da equação, o que pode, de facto, ser um risco.

Por outro lado, configurar permissões para uma infinidade de recursos sem servidor e interações entre eles é uma tarefa demorada. Além disso, 'gastar' o tempo dos desenvolvedores nessa configuração de segurança pode rapidamente ficar caro, além de não ser o uso ideal de seu tempo. Aproveitar a automação, como a plataforma CloudGuard, pode aumentar a segurança sem servidor sem dedicar muito tempo ao desenvolvedor.

5. Maior tempo para processamento de segurança

Outro benefício do serverless é que você paga apenas pelo que realmente consome, o que pode resultar em custos reduzidos. No entanto, pagar exatamente pelo que você usa significa que qualquer aumento no tempo de processamento aumentará os custos.

Colocar um excesso de configuração de segundos de aplicativo em seu aplicativo pode adicionar trabalho extra às suas funções, o que pode aumentar os custos. Embora adicionar tempo de processamento por uma questão de segurança seja um investimento inteligente, requer uma implementação adequada para evitar aumentos de custos excessivos e desnecessários.

Semelhante ao aumento do tempo para configuração de segurança sem servidor acima, não é exatamente uma ameaça, mas sim um desafio que você terá que enfrentar ao proteger sua arquitetura sem servidor.