Serverless Security é realmente importante?
O que é computação sem servidor (Serverless Computing)?
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. O AWS Lambda Functions, o Google Cloud Functions e o Azure Functions são estruturas sem servidor populares que criam aplicativos.
Uma arquitetura sem servidor oferece o benefício do dimensionamento automatizado e quase infinito. Há muito pouco 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 de aplicativos consumidos afeta o preço, o que significa que você paga apenas pelo que usa, resultando em custos mais baixos.
O Serverless representa uma mudança adicional de responsabilidades do cliente para o provedor de nuvem. Como não há infraestrutura envolvida, há uma redução significativa na sobrecarga das operações.
A transferência do gerenciamento da infraestrutura para o provedor de nuvem permite que você se concentre no desenvolvimento de soluções para atender à sua organização e aos seus clientes. Isso o ajuda a manter o foco em suas vantagens competitivas exclusivas e, com frequência, resulta em economia de custos não apenas em computação, mas também na transferência de pessoas para o desenvolvimento.
O que é segurança sem servidor?
A segurança sem servidor exige uma mudança de paradigma na forma como as organizações veem a segurança dos aplicativos. Em vez de criar segurança em torno do próprio aplicativo usando firewalls de última geração, as organizações devem criar segurança adicional em torno das funções dentro dos aplicativos hospedados por provedores de nuvem terceirizados. Essa camada adicional de segurança garante o endurecimento adequado do aplicativo e o controle de acesso com privilégios mínimos para que cada função faça nem mais nem menos do que foi projetada para fazer, ajudando as organizações a melhorar sua postura de segurança e a manter a conformidade.
Como o Serverless melhora a segurança?
Aqui estão alguns pontos:
Os provedores de nuvem cuidam do sistema operacional, da segurança do tempo de execução e dos patches.
Ao implantar aplicativos sem servidor, você cede o controle sobre a maior parte da pilha ao provedor de nuvem, e ele fornece serviços como o gerenciamento de chaves. Você não é mais o proprietário do endurecimento do sistema operacional, dos direitos de administrador, do SSH e da segmentação. A AWS, a Microsoft e o Google são confiáveis em manter suas partes da pilha corrigidas e protegidas, portanto, dar a eles uma parte maior da pilha certamente melhora as coisas nesse sentido.
Sem estado/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 o AWS Lambda, são executadas por alguns segundos e depois morrem. Os contêineres são reciclados. O fato de as funções sem servidor irem e virem, sem memória, reduz o risco de ataques de longo prazo.
Visibilidade dos 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 para a segurança. As ferramentas de segurança de aplicativos geralmente se esforçam muito para analisar e instrumentar seu aplicativo empacotado apenas para poder observar ou filtrar o fluxo interno do seu aplicativo.
Microsserviços menores = capacidade de criar funções mínimas e adequadas para cada função. A mudança 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 sua superfície de ataque.
Enquanto qualquer função dentro de um contêiner precisar de acesso para ler 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 esses privilégios sejam restritos apenas ao menor escopo necessário. Se houver uma vulnerabilidade em uma de suas funções, um invasor só terá acesso aos recursos limitados dessa função, e não ao grande conjunto de permissões para conceder a um contêiner.
Quais são os desafios de segurança sem servidor?
Com a mudança na estrutura dos aplicativos sem servidor, surgem alguns novos desafios.
A visibilidade da segurança se torna mais difícil. A quantidade total de informações e o número de recursos aumentam com o serverless. Isso dificulta 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.
- Protocolos, vetores e pontos de ataque se multiplicaram em todas as funções, e protocolo = um ponto de ataque em potencial. Isso exige abordagens exclusivas para a segurança do Google Functions, do Azure Functions e do AWS Lambda.
- 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ção com menos privilégios.
Observabilidade em aplicativos sem servidor – O desafio. Os aplicativos sem servidor usam serviços diferentes de vários provedores de nuvem, em várias versões e regiões. Para entender sua superfície de ataque e os possíveis riscos, 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 criar e manter.
Onde implantar a segurança sem servidor?
Com aplicativos sem servidor, não há lugar para colocar a segurança clássica, como WAF, firewall e IDS. Construir barreiras entre os invasores e os recursos não é simples por vários motivos.
Embora implantações mais rápidas e mais frequentes possam ser muito positivas, a velocidade do serverless pode gerar novos desafios na configuração da segurança.
As ferramentas de segurança podem adicionar tempo ao processamento, que você deve multiplicar 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.
Erosão do perímetro. Os aplicativos tradicionais tinham um limite claro. O exterior e o interior eram distintos, e podíamos fazer a segurança no perímetro. Embora não seja ideal que a segurança permaneça exclusivamente no perímetro, ainda era possível construir um muro.
Os aplicativos sem servidor são mais porosos e de granulação fina. Composto por dezenas ou centenas de funções, os aplicativos sem servidor são pequenos microsserviços com suas próprias políticas, função, API, trilha de auditoria etc. Isso altera a superfície de ataque. Em vez de um pequeno número de pontos de entrada com muitas funcionalidades ocultas por trás de cada um, agora há mais pontos de entrada, cada um com uma pequena parte do aplicativo por trás. Para defender seu aplicativo, agora é necessário pensar em cada ponto de entrada.
Vários eventos podem acionar funções, como:
- Eventos de armazenamento em nuvem (por exemplo, AWS S3, armazenamento Blob do Azure, Google Cloud Storage)
- Processamento de dados de fluxo (por exemplo, AWS Kinesis)
- Alterações em 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)
Quais são as 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. Veja a seguir algumas das ameaças de segurança sem servidor exclusivas dessa nova arquitetura de aplicativos.
1. A ameaça de funções com excesso de privilégios
Com os aplicativos sem servidor, você tem a oportunidade de aplicar privilégios a funções individuais e garantir que esses privilégios sejam restritos apenas ao menor escopo necessário. Isso pode permitir que você minimize significativamente sua superfície de ataque, bem como atenue o impacto de qualquer ataque.
Infelizmente, uma pesquisa recente da Check Point descobriu que a grande maioria dos desenvolvedores não está aproveitando essa oportunidade. Nossa pesquisa descobriu que 98% das funções em aplicativos sem servidor estão em risco, sendo que 16% são consideradas “graves”.
Além disso, a maioria dessas funções é provisionada com mais permissões do que o necessário, o que poderia ser removido para melhorar a segurança da função e do aplicativo.
Ao analisar as funções, a Check Point atribui uma pontuação de risco a cada função. Isso se baseia nos pontos fracos de postura descobertos e leva em conta não apenas a natureza do ponto fraco, mas também o contexto em que ele ocorre.
Depois de analisar 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 que a Check Point descobriu são permissões desnecessárias, enquanto o restante está relacionado a códigos e configurações vulneráveis.
2. O ataque de “Groundhog Day”
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 seus aplicativos a longo prazo. Além disso, essa é uma das muitas vantagens de segurança do serverless. No entanto, o simples fato de isso tornar a vida mais difícil para os invasores não significa que eles interromperão os ataques; eles apenas mudarão a estratégia.
A curta duração das funções sem servidor significa que as ameaças à segurança sem servidor podem mudar de forma. Os invasores podem criar um ataque muito mais curto que apenas rouba, por exemplo, alguns números de cartão de crédito. Essa única rodada do ataque se repete continuamente no que chamamos de ataque “Groundhog Day”.
3. Poisoning the Well
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 forma de os invasores contornarem a natureza efêmera dos aplicativos sem servidor é por meio de um ataque upstream, ou “Poisoning the Well”.
Os aplicativos nativos da nuvem tendem a incluir muitos módulos e bibliotecas com código de várias 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 mal-intencionado em seus aplicativos de nuvem pode ligar para casa, obter instruções e causar estragos.
4. Maior tempo para configuração de 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.
A arquitetura sem servidor traz o benefício de aumentar a velocidade de desenvolvimento de aplicativos. Infelizmente, a abordagem tradicional de segurança, em que os desenvolvedores escrevem código 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á para o serverless.
Se os desenvolvedores precisarem esperar que a segurança abra portas, funções de IAM ou grupos de segurança para eles, o benefício do aumento da velocidade será rapidamente eliminado. Com muita frequência, a solução é remover o SecOps da equação, o que pode, de fato, ser um risco.
Por outro lado, a configuração de permissões para os inúmeros recursos sem servidor e as interações entre eles é uma tarefa demorada. Além disso, “gastar” o tempo dos desenvolvedores nessa configuração de segurança pode rapidamente se tornar caro, além de não ser o uso ideal do tempo deles. Aproveitar a automação, como a plataforma CloudGuard, pode aumentar a segurança sem servidor sem gastar muito tempo do desenvolvedor.
5. Maior tempo para processamento de segurança
Outra vantagem do serverless é que você paga apenas pelo que realmente consome, o que pode resultar em redução de custos. 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 da seção de aplicativos em seu aplicativo pode potencialmente adicionar trabalho extra às suas funções, o que pode aumentar os custos. Embora o aumento do tempo de processamento em prol da segurança seja um investimento inteligente, ele 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 mencionado acima, não se trata exatamente de uma ameaça, mas de um desafio que você terá de enfrentar ao proteger sua arquitetura sem servidor.
Read this article in English.
Fonte
Douglas Bernardini
Cybersecurity Specialist & Cloud Computing Expert with +10 years experience in IT infrastructure.
Specialist delivering assets for development teams in Google Cloud Platform (GCP) and Amazon web services (AWS)
Hands-on cloud security enterprise architect, with experience in SIEM/SOC, IAM, cryptography, pentest, network topologies, operating systems, databases, and applications.
Experience in DevSecOps analysis to discover vulnerabilities in software, identifying CI/CD risks gaps and recommending secure-coding process (S-SDLC).
PDF's
