Uma função que corre durante 80 milissegundos e depois desaparece não devia ser um risco de segurança grave. Mas é. O relatório M-Trends 2026 da Mandiant, construído a partir de mais de 500 mil horas de investigações forenses em 2025, mostra que a exploração de vulnerabilidades continua a ser o vetor de entrada mais comum, com 32% dos casos analisados. E o Cost of a Data Breach Report 2026 da IBM, elaborado com o Ponemon Institute junto de 602 organizações, situa o custo médio de uma fuga de dados em 4,99 milhões de dólares, um aumento de 12% face ao ano anterior. Nenhum destes dois relatórios fala exclusivamente de funções serverless. Mas ambos descrevem exatamente o tipo de erro que mais afeta AWS Lambda, Azure Functions e Cloudflare Workers: permissões a mais, segredos mal guardados e configurações que ninguém revisou antes de ir para produção.
Este artigo compara as três plataformas serverless mais usadas em 2026 pelo ângulo que raramente aparece nos benchmarks de desempenho: o risco de configuração. Quem tem a superfície de ataque mais pequena, quem gere identidades com mais rigor e quem torna mais fácil, ou mais difícil, detetar um erro antes que alguém o explore.
O que muda na segurança quando não há servidor para proteger
A promessa do serverless sempre foi simples: escreve o código, a plataforma trata do resto. Só que “o resto” inclui um conjunto de decisões de segurança que, numa arquitetura tradicional, ficavam centralizadas numa equipa de infraestrutura. Numa função Lambda, Azure Function ou Worker, essas decisões espalham-se por centenas de ficheiros de configuração, políticas IAM e variáveis de ambiente escritas por equipas de produto que raramente têm formação em segurança cloud.
A superfície de ataque de uma função serverless não é só o código que o programador escreveu. Inclui a política de identidade associada à função, os gatilhos que a invocam, os destinos para onde envia dados, o armazenamento temporário, os registos gerados e, sobretudo, os segredos injetados no arranque. Um erro em qualquer um destes pontos pode transformar uma função inofensiva num ponto de entrada para toda a conta cloud.
O modelo de responsabilidade partilhada também muda de forma que nem sempre é óbvia para equipas que vêm de infraestrutura tradicional. Num servidor próprio, a equipa controla o sistema operativo, a rede e a aplicação. No serverless, o fornecedor assume o sistema operativo e o isolamento entre clientes, mas a política de identidade, os segredos e a lógica de autorização dentro da própria função continuam inteiramente nas mãos de quem escreve o código. É uma divisão de trabalho que reduz uma categoria de risco, falhas no sistema operativo subjacente, mas não elimina a necessidade de pensar em segurança, apenas a desloca para um ponto diferente da arquitetura.
Cold start: mais do que um problema de desempenho
O tempo de arranque frio, ou cold start, costuma discutir-se como questão de latência, mas tem uma face de segurança menos falada. Plataformas que mantêm instâncias sempre prontas para evitar arranques lentos também mantêm memória e credenciais residentes por mais tempo, alargando a janela em que um processo comprometido pode ser reutilizado por outro pedido. A AWS resolve isto com concorrência provisionada, a Microsoft com instâncias “always ready” no plano Premium e Flex Consumption, e a Cloudflare evita o problema pela raiz: os isolados V8 não têm máquina virtual nem contentor para arrancar, pelo que não existe a mesma fase de arranque de sistema operativo que afeta os concorrentes.
AWS Lambda: IAM, VPC e a superfície mais estudada do mercado
O AWS Lambda é a plataforma serverless mais antiga das três e, por isso, também a mais documentada em termos de riscos. O seu modelo de segurança assenta quase todo no IAM: cada função recebe um papel de execução com uma política que define exatamente a que serviços pode aceder. Na teoria, isto permite um controlo granular quase perfeito. Na prática, é comum encontrar funções com políticas demasiado abertas, porque é mais rápido copiar uma política “AdministratorAccess” do que escrever uma política mínima função a função.
Segundo a documentação oficial da AWS, uma função Lambda pode usar entre 128 MB e 10.240 MB de memória, com um tempo de execução máximo de 900 segundos em invocações normais, podendo chegar a 5.400 segundos em funções assíncronas que usam Lambda Managed Instances. O limite de concorrência por omissão é de 1.000 execuções simultâneas por conta e região, ajustável para dezenas de milhares mediante pedido. As variáveis de ambiente estão limitadas a 4 KB no total e são cifradas automaticamente com AWS KMS, mas a gestão de rotação e versionamento de segredos continua a depender do AWS Secrets Manager ou do SSM Parameter Store, serviços pagos à parte.
A ligação a uma rede privada virtual é possível através de interfaces de rede elásticas, o que permite isolar funções de recursos internos sensíveis, mas também adiciona outra camada de configuração que pode falhar. Esta combinação de flexibilidade e complexidade explica por que motivo o AWS Lambda aparece com tanta frequência em auditorias de ferramentas de CSPM: há simplesmente mais botões para configurar mal.
Azure Functions: identidades geridas e limites que variam por plano
A Microsoft reformulou a sua oferta serverless em torno do plano Flex Consumption, que substitui gradualmente o antigo plano Consumption. Segundo a documentação da Microsoft Learn, o plano Consumption legado está a ser retirado do Linux a partir de 30 de setembro de 2028, e as aplicações com o runtime v3 em Linux deixam de funcionar depois de 30 de setembro de 2026. Quem ainda não migrou tem pouco tempo de manobra.
Em termos de segurança, a grande vantagem do Azure Functions é a integração nativa com o Microsoft Entra ID através de identidades geridas, atribuídas pelo sistema ou pelo utilizador. Isto elimina, em muitos casos, a necessidade de guardar credenciais explícitas no código ou nas variáveis de ambiente, porque a função autentica-se diretamente junto de outros serviços Azure usando um token gerido pela plataforma. É um modelo mais próximo do “sem segredos” do que o IAM da AWS ou o sistema de secrets da Cloudflare.
Os limites variam bastante por plano. No Flex Consumption, a memória por instância está fixada em três opções, 512 MB, 2.048 MB ou 4.096 MB, o tempo de execução por omissão é de 30 minutos e pode ser efetivamente ilimitado, com um período de tolerância de 60 minutos durante a redução de escala. O armazenamento temporário é de apenas 0,8 GB e não existe armazenamento persistido próprio, ao contrário do plano Premium, que oferece até 61 GB temporários e 250 GB persistidos. Isto obriga a decisões de arquitetura mais cuidadosas: uma função que grava ficheiros temporários grandes pode simplesmente falhar no Flex Consumption sem aviso prévio claro.
Um ponto curioso: ao contrário da AWS e da Cloudflare, a Microsoft não publica valores fixos de preço por execução na sua página oficial de preços. A tabela pública mostra apenas marcadores de posição e remete explicitamente para a calculadora de preços do Azure, porque o valor final depende da região, da moeda e do tipo de acordo comercial. O que a Microsoft confirma por escrito é a oferta gratuita: 250.000 execuções e 100.000 GB-s por mês no Flex Consumption, ou 1 milhão de pedidos e 400.000 GB-s por mês no plano Consumption legado.
Cloudflare Workers: isolados V8 sem máquina virtual
O Cloudflare Workers parte de uma arquitetura fundamentalmente diferente. Em vez de arrancar uma máquina virtual ou um contentor por cada função, a Cloudflare corre o código dentro de isolados V8, o mesmo motor de isolamento que separa abas no navegador Chrome. Isto elimina uma classe inteira de configurações de segurança que, na AWS ou no Azure, podem correr mal: não há VPC para configurar, não há política de rede para esquecer, não há imagem de contentor para corrigir.
Por outro lado, isso tem um preço em flexibilidade e em superfície de controlo. Segundo a documentação oficial da Cloudflare, cada isolado está limitado a 128 MB de memória, somando o heap de JavaScript e qualquer alocação WebAssembly. O tempo de CPU por pedido é de apenas 10 milissegundos no plano gratuito, subindo para um máximo configurável de 5 minutos no plano pago, com um valor por omissão de 30 segundos. Para gatilhos Cron ou consumidores de filas, o limite pode chegar aos 15 minutos. O tamanho máximo do pacote de código é de 64 MiB descomprimidos, e o número de sub-pedidos por invocação está limitado a 50 no plano gratuito e a 10.000 no plano pago, expansível até 10 milhões mediante pedido.
Secrets no Wrangler: simples, mas sem rotação automática
A gestão de segredos na Cloudflare passa pelo comando wrangler secret put, que cifra o valor e o associa ao Worker no momento do deploy. É um fluxo simples e difícil de configurar mal, porque não há uma política de permissões complexa para escrever. A desvantagem é que não existe um serviço equivalente ao AWS Secrets Manager ou ao Azure Key Vault com rotação automática, versionamento e auditoria de acesso integradas. Para equipas que precisam de rodar chaves de API regularmente por exigência de conformidade, isso significa construir esse processo por fora da plataforma.
Tabela comparativa: limites técnicos e modelo de segurança
A tabela seguinte junta os valores oficiais publicados pela AWS, pela Microsoft e pela Cloudflare nas respetivas páginas de documentação técnica, válidos em outubro de 2026. Os valores do Azure Functions referem-se ao plano Flex Consumption, atualmente recomendado pela Microsoft para novas aplicações serverless.
| Característica | AWS Lambda | Azure Functions (Flex Consumption) | Cloudflare Workers |
|---|---|---|---|
| Memória máxima | 10.240 MB | 4.096 MB | 128 MB por isolado |
| Tempo de execução máximo | 900 s (5.400 s em Managed Instances assíncronas) | Sem limite fixo, com tolerância de 60 min na redução de escala | 300 s no plano pago; 10 ms de CPU no gratuito |
| Concorrência/instâncias máximas | 1.000 por omissão, ajustável a dezenas de milhares | 1.000 por grupo de funções | Sem limite de instâncias (modelo de isolados) |
| Armazenamento temporário | 512 MB a 10.240 MB (/tmp) | 0,8 GB | Sem armazenamento em disco local |
| Armazenamento persistido nativo | Não (requer S3/EFS) | 0 GB no Flex Consumption | Via KV, R2 ou Durable Objects |
| Tamanho máximo do pacote | 250 MB descomprimido (50 MB via API) | Variável por plano | 64 MiB descomprimido |
| Modelo de identidade | Papéis IAM por função | Identidades geridas (Microsoft Entra ID) | Tokens de API e bindings no wrangler.toml |
| Gestão de segredos nativa | Variáveis de ambiente cifradas com KMS + Secrets Manager | Application Settings cifradas + Azure Key Vault | Wrangler secrets (sem rotação automática) |
| Integração com rede privada | VPC via ENI | Integração com rede virtual (VNet) | Sem conceito de VPC tradicional |
| Variáveis de ambiente | 4 KB no total | 32 KB (Web Functions) | 64 variáveis grátis / 128 pagas, 5 KB cada |
| Comportamento de cold start | Mitigável com concorrência provisionada | Mitigável com instâncias “always ready” | Sem máquina virtual a arrancar (isolados V8) |
| Camadas/extensões | 5 camadas por função | Extensões via NuGet/npm | Módulos ES e bindings nativos |
Preços: tabela comparativa de custos
O preço por si só não é uma medida de segurança, mas influencia diretamente decisões que têm impacto na segurança, como quanta concorrência provisionada uma equipa está disposta a pagar para reduzir cold starts, ou se vale a pena manter instâncias sempre ativas para evitar picos de latência que mascaram comportamento anómalo nos registos.
| Plataforma / plano | Nível gratuito mensal | Preço por pedidos/execuções | Preço por computação |
|---|---|---|---|
| AWS Lambda | 1 milhão de pedidos + 400.000 GB-s | 0,20 $ por milhão de pedidos | 0,0000166667 $ por GB-s |
| Azure Functions (Consumption legado) | 1 milhão de pedidos + 400.000 GB-s | Não publicado (ver calculadora de preços) | Não publicado (ver calculadora de preços) |
| Azure Functions (Flex Consumption) | 250.000 execuções + 100.000 GB-s | Não publicado (ver calculadora de preços) | Não publicado (ver calculadora de preços) |
| Cloudflare Workers (gratuito) | 100.000 pedidos/dia, 10 ms de CPU por pedido | Sem custo dentro do limite | Sem custo dentro do limite |
| Cloudflare Workers (pago) | 10 milhões de pedidos + 30 milhões de ms de CPU, por 5 $/mês mínimo | 0,30 $ por milhão adicional de pedidos | 0,02 $ por milhão adicional de ms de CPU |
A Microsoft é a única das três a não publicar valores fixos de preço por execução na sua página pública, remetendo sempre para a calculadora oficial. Isto dificulta comparações diretas e é, só por si, um pequeno sintoma do problema mais amplo deste artigo: quanto mais camadas de abstração existem entre a configuração e o resultado final, mais fácil é cometer um erro sem perceber.
O que os dados da Mandiant e da IBM revelam sobre erros de configuração
O relatório M-Trends 2026 da Mandiant, publicado pela Google Cloud e assente em mais de 500 mil horas de investigações forenses conduzidas em 2025, mostra que o tempo médio de permanência de um atacante numa rede comprometida subiu de 11 para 14 dias. É um dado contraintuitivo: ao mesmo tempo, a deteção interna por parte das próprias organizações subiu de 43% em 2024 para 52% em 2025, segundo o mesmo relatório, confirmado também pela comunidade da Google Cloud. As equipas estão a ver mais, mas não necessariamente a reagir mais depressa. A exploração de vulnerabilidades continua a ser o vetor de entrada mais frequente, representando 32% das intrusões analisadas pela Mandiant em 2025.
O Cost of a Data Breach Report 2026 da IBM, elaborado com o Ponemon Institute junto de 602 organizações afetadas por fugas de dados, acrescenta outra camada à história: o custo médio global de uma violação chegou aos 4,99 milhões de dólares, um aumento de 12% em relação ao ano anterior e o valor mais alto já registado pelo estudo. A IBM atribui parte deste aumento a ataques acelerados ou conduzidos por inteligência artificial, que cresceram 56% segundo o mesmo relatório, e que, em média, acrescentaram cerca de 1 milhão de dólares ao custo de cada violação analisada.
Nenhum destes números fala especificamente de Lambda, Azure Functions ou Workers. Mas ambos descrevem o padrão de risco que mais ameaça arquiteturas serverless: superfícies de ataque dispersas, permissões difíceis de auditar e uma janela de deteção que continua a alargar-se, mesmo com mais visibilidade interna. É também por isso que a configuração segura subiu para segundo lugar na lista OWASP Top 10 de 2025, um sinal direto de que o problema não está a diminuir.
Cinco falhas reais que começaram numa configuração errada
Nenhum dos casos abaixo foi causado especificamente por uma função Lambda, Azure Function ou Worker mal configurada. Mas todos partilham exatamente o padrão de erro que este artigo descreve, aplicado a armazenamento, identidade e redes na cloud, e qualquer um deles podia ter tido origem numa função serverless com permissões a mais.
| Caso | Ano | Causa | Dados afetados |
|---|---|---|---|
| Capital One | 2019 | SSRF + firewall mal configurada + papel IAM demasiado permissivo | 106 milhões de pessoas; multa de 80 milhões $ da OCC e acordo de 190 milhões $ |
| Toyota | 2023 | Sistema cloud definido como público em vez de privado | 2,15 milhões de clientes no Japão, expostos durante cerca de 9 anos e meio |
| Microsoft (investigação de IA) | 2023 | Token SAS demasiado permissivo partilhado publicamente | 38 terabytes, incluindo mais de 30.000 mensagens internas do Teams |
| Pegasus Airlines | 2022 | Bucket AWS S3 exposto sem proteção de acesso | 6,5 terabytes, cerca de 23 milhões de ficheiros |
| SL Data Services | 2024 | Bucket S3 público, sem palavra-passe nem cifra | 644.869 ficheiros PDF, 713,1 GB de dados sensíveis |
O caso Capital One continua a ser o mais citado em formação de segurança cloud porque junta os três ingredientes que também ameaçam o serverless: uma vulnerabilidade de aplicação, uma política de rede mal configurada e, sobretudo, um papel IAM com permissões muito acima do necessário. É exatamente o mesmo erro que acontece quando alguém anexa a política “AdministratorAccess” a uma função Lambda só porque é mais rápido do que escrever uma política mínima.
O caso da Microsoft é particularmente relevante para quem usa Azure Functions, porque envolveu precisamente o tipo de token de acesso partilhado que muitas integrações serverless no Azure usam para aceder a contas de armazenamento. Um token mal escopado pode dar acesso a toda a conta de armazenamento, não só à pasta que a função deveria usar.
Gestão de segredos: variáveis de ambiente, Key Vault e Wrangler
A forma como cada plataforma trata segredos é talvez a diferença mais prática entre as três para equipas pequenas sem uma função dedicada de segurança cloud. No AWS Lambda, as variáveis de ambiente são cifradas por omissão com uma chave gerida pelo AWS KMS, mas a rotação automática exige ligar a função ao AWS Secrets Manager, que cobra por segredo armazenado e por chamada à API. É comum ver equipas a ignorar este passo e a deixar chaves de API estáticas em variáveis de ambiente durante meses.
No Azure Functions, as Application Settings também ficam cifradas em repouso, mas a plataforma incentiva de forma mais direta o uso de referências ao Azure Key Vault, que suportam rotação e são sincronizadas automaticamente até 24 horas após a renovação do certificado, segundo a documentação da Microsoft Learn. Combinado com identidades geridas, isto significa que, numa configuração bem feita, uma Azure Function pode nunca ter de guardar uma credencial explícita.
O Cloudflare Workers simplifica o processo com o comando wrangler secret put, que cifra o valor ao nível da plataforma. É rápido e difícil de configurar mal, mas não existe um cofre central equivalente ao Key Vault ou ao Secrets Manager, nem rotação automática. Para equipas que já usam ferramentas dedicadas de gestão de segredos, isso normalmente não é um problema, mas para quem depende só da plataforma, é um ponto a vigiar.
Registo, auditoria e resposta a incidentes em ambiente serverless
Quando algo corre mal numa função serverless, a primeira pergunta de qualquer equipa de resposta a incidentes é simples: o que é que esta função podia fazer, e o que é que ela fez de facto? A qualidade dos registos determina se essa pergunta se responde em minutos ou em dias.
O AWS Lambda integra-se diretamente com o CloudTrail e o CloudWatch Logs, o que permite reconstruir com bastante detalhe que papel IAM foi usado, que recursos foram acedidos e quando. É o ecossistema de auditoria mais maduro das três plataformas, em parte porque é também o mais antigo. O Azure Functions oferece um nível semelhante através do Azure Monitor e do Application Insights, com a vantagem de poder correlacionar diretamente eventos de identidade do Microsoft Entra ID com execuções de funções específicas, o que facilita perceber se uma identidade gerida foi usada de forma anómala.
O Cloudflare Workers é o que menos recursos de auditoria granular oferece por omissão. Os registos (Workers Logs e Logpush) mostram execuções, erros e metadados de pedidos, mas não existe um equivalente direto ao CloudTrail que documente cada alteração de configuração na conta. Para organizações sujeitas a requisitos formais de retenção forense, isso normalmente significa exportar logs para um SIEM externo desde o primeiro dia, em vez de confiar apenas nas ferramentas nativas da plataforma.
Residência de dados e RGPD: o que isto significa na Europa
Para equipas em Portugal e no resto da União Europeia, a comparação entre estas três plataformas não pode ignorar onde os dados ficam guardados e processados. O AWS Lambda corre apenas na região escolhida pelo cliente no momento da criação da função, por exemplo eu-west-1 na Irlanda ou eu-west-3 em Paris, e é essa escolha, feita manualmente, que determina se os dados de um cidadão europeu nunca saem do território da União. O mesmo princípio aplica-se ao Azure Functions, com regiões como West Europe nos Países Baixos ou North Europe na Irlanda, geridas através do portal Azure e vinculadas contratualmente às cláusulas-tipo de proteção de dados da Microsoft.
O Cloudflare Workers funciona de forma estruturalmente diferente, porque a sua proposta de valor é precisamente correr o código o mais próximo possível do utilizador final, nos centros de dados da rede global da Cloudflare. Isto significa que, por omissão, uma função pode ser executada em qualquer ponto da rede, incluindo fora da Europa. Para organizações sujeitas ao RGPD que precisam de garantir processamento dentro da União, a Cloudflare oferece a funcionalidade Regional Services, que restringe onde o tráfego é desencriptado e processado, mas essa restrição tem de ser configurada explicitamente. Quem assume que “é a Cloudflare, corre onde for mais rápido” sem rever esta definição pode estar, sem saber, a processar dados pessoais fora da jurisdição esperada, o que é exatamente o tipo de erro de configuração silencioso que este artigo descreve ao longo de todas as secções anteriores.
Casos de uso: quando escolher cada plataforma
Não há uma resposta universal, e qualquer artigo que prometa uma só não está a ser honesto. Estes são os cenários onde cada plataforma tende a fazer mais sentido, tendo em conta tanto a segurança como a operação diária:
- Aplicações empresariais com requisitos de conformidade rígidos, como RGPD ou setor financeiro: AWS Lambda com VPC dedicada e AWS Secrets Manager, ou Azure Functions com identidades geridas e Key Vault, dão o controlo de auditoria mais detalhado.
- Equipas pequenas sem função de segurança dedicada: Cloudflare Workers reduz a superfície de configuração que pode falhar, à custa de menos controlo fino sobre identidade.
- APIs com latência crítica e tráfego global distribuído: Cloudflare Workers, pela arquitetura de isolados V8 sem máquina virtual a arrancar em cada pedido.
- Processamento de dados que exige mais de 128 MB de memória ou mais de cinco minutos de execução: AWS Lambda, pelos limites de memória até 10.240 MB e tempo de execução que pode chegar a 90 minutos em cenários assíncronos.
- Organizações já profundamente integradas no ecossistema Microsoft 365 e Entra ID: Azure Functions, pela integração nativa de identidade que elimina segredos explícitos em muitos fluxos.
- Protótipos e MVPs com orçamento limitado: o nível gratuito do Cloudflare Workers, 100.000 pedidos por dia, sem cartão de crédito obrigatório, é o mais simples de testar sem compromisso financeiro.
Guia de migração entre AWS Lambda, Azure Functions e Cloudflare Workers
Migrar entre plataformas serverless raramente é uma questão de copiar e colar código. Os modelos de identidade, os limites de memória e o comportamento de cold start são diferentes o suficiente para exigirem um processo estruturado. Eis os passos que reduzem o risco de levar um erro de configuração antigo para a nova plataforma:
- Faz um inventário de todas as permissões que a função atual usa de facto, não as que a política lhe permite. Ferramentas de análise de acesso da própria cloud ajudam a identificar permissões concedidas mas nunca invocadas.
- Documenta todos os segredos, chaves de API e tokens que a função consome, e decide se vão migrar para o Secrets Manager, o Key Vault ou o Wrangler secrets da plataforma de destino.
- Reescreve a política de identidade do zero no destino, em vez de tentar traduzir literalmente uma política IAM da AWS para uma identidade gerida do Azure ou um binding do Cloudflare. Os modelos não são equivalentes ponto a ponto.
- Testa os limites de memória e tempo de execução da plataforma de destino contra cargas de trabalho reais, não só contra testes sintéticos. Uma função que usa 2 GB de memória no Lambda pode simplesmente não correr num Worker, limitado a 128 MB.
- Configura o armazenamento temporário e persistido de forma explícita. O Flex Consumption do Azure, por exemplo, só oferece 0,8 GB de armazenamento temporário, bem menos do que muitas equipas assumem ao migrar do plano Consumption legado.
- Replica a estratégia de registo e auditoria antes da migração completa, não depois. Se a plataforma de destino não tiver um equivalente direto ao CloudTrail, configura a exportação para um SIEM externo no primeiro dia.
- Corre as duas plataformas em paralelo durante um período de transição, com tráfego dividido, para comparar comportamento de erro e latência antes de desligar a versão antiga.
- Revê o novo ambiente com uma ferramenta de CSPM ou CNAPP antes de o declarar concluído, para detetar configurações herdadas por omissão que ninguém reviu manualmente.
Vantagens e desvantagens de cada plataforma
Resumindo os pontos fortes e fracos de cada plataforma do ponto de vista estrito de segurança e gestão de risco:
- Vantagens do AWS Lambda: controlo IAM granular, maior limite de memória e tempo de execução, integração profunda com CloudTrail para auditoria forense.
- Desvantagens do AWS Lambda: complexidade de configuração elevada, risco real de políticas IAM demasiado permissivas, custos adicionais para rotação de segredos.
- Vantagens do Azure Functions: identidades geridas que reduzem a necessidade de segredos explícitos, boa correlação de eventos com o Microsoft Entra ID, forte integração com Key Vault.
- Desvantagens do Azure Functions: preços pouco transparentes na página pública, limites de armazenamento temporário baixos no Flex Consumption, transição forçada do plano Consumption legado a decorrer até 2028.
- Vantagens do Cloudflare Workers: superfície de configuração mínima, isolados V8 sem arranque de máquina virtual, nível gratuito generoso e simples de testar.
- Desvantagens do Cloudflare Workers: limite de memória de apenas 128 MB, sem cofre central de segredos com rotação automática, auditoria nativa menos detalhada do que a concorrência.
Veredito final: qual é mais segura por omissão
Não há uma plataforma objetivamente “mais segura” nas três, porque a segurança serverless depende tanto da arquitetura da plataforma como das decisões de configuração de quem a usa. Dito isto, os dados oficiais permitem uma conclusão com algum peso: o Cloudflare Workers tem a menor superfície de configuração possível de errar, simplesmente porque tem menos opções para configurar. Isso reduz o risco de erro humano, mas também reduz o controlo fino disponível para quem precisa de políticas de identidade muito específicas.
O Azure Functions, com identidades geridas e integração com o Key Vault, oferece provavelmente o melhor equilíbrio entre segurança por omissão e flexibilidade, desde que a organização já esteja dentro do ecossistema Microsoft Entra ID. Sem essa base, a complexidade de configuração aproxima-se da do Lambda.
O AWS Lambda continua a ser a escolha mais flexível e mais bem documentada, mas é também a que exige mais disciplina de configuração para evitar repetir o padrão de erro visível no caso Capital One. Dado que a exploração de configurações e vulnerabilidades continua a ser o vetor de entrada mais comum em 32% das intrusões analisadas pela Mandiant em 2025, a escolha da plataforma importa menos do que o processo de revisão de permissões que a acompanha, seja ela qual for.
Perguntas frequentes
Qual destas três plataformas é mais segura por omissão?
Nenhuma é objetivamente superior em todos os critérios. O Cloudflare Workers tem a menor superfície de configuração para errar, o Azure Functions tem a melhor integração de identidade sem segredos explícitos, e o AWS Lambda tem o sistema de auditoria mais maduro. A escolha depende do perfil de risco e do ecossistema já existente na organização.
O que é um cold start e porque importa para a segurança, além do desempenho?
É o tempo que uma plataforma demora a iniciar uma nova instância de execução para responder a um pedido. Além de afetar a latência, instâncias mantidas sempre prontas para evitar cold starts também mantêm memória e credenciais residentes por mais tempo, o que pode alargar a janela de exposição em caso de compromisso de um processo.
AWS Lambda ou Azure Functions: qual tem melhor gestão de identidade?
O Azure Functions tem vantagem no conceito, graças às identidades geridas do Microsoft Entra ID, que podem eliminar segredos explícitos em muitos fluxos. O AWS Lambda tem vantagem na granularidade das políticas IAM, que permitem um controlo mais fino, mas exigem mais trabalho manual para evitar permissões excessivas.
O Cloudflare Workers é adequado para aplicações empresariais sensíveis?
Pode ser, mas exige compensar a ausência de um cofre central de segredos com rotação automática recorrendo a ferramentas externas de gestão de segredos. Para dados sujeitos a requisitos formais de retenção forense, também é preciso configurar exportação de registos para um SIEM externo, porque a auditoria nativa é menos detalhada do que a da AWS ou do Azure.
Como é que uma função serverless mal configurada pode causar uma fuga de dados?
O padrão mais comum é uma política de identidade com permissões acima do necessário, combinada com um segredo exposto em variáveis de ambiente ou num token mal escopado. É exatamente o mecanismo visível no caso Capital One de 2019 e no caso do token SAS da Microsoft em 2023, ambos resultado de permissões demasiado amplas em recursos cloud.
É possível migrar uma função Lambda diretamente para o Azure Functions ou para o Cloudflare Workers?
O código pode, em muitos casos, ser adaptado com alterações moderadas, mas a política de identidade, a gestão de segredos e os limites de memória e armazenamento temporário têm de ser reconstruídos do zero em cada plataforma. Não existe uma tradução automática de uma política IAM da AWS para uma identidade gerida do Azure ou para um binding do Cloudflare.
Quanto custa, em média, corrigir um erro de configuração que resulta numa fuga de dados?
Segundo o Cost of a Data Breach Report 2026 da IBM, o custo médio global de uma violação de dados chegou aos 4,99 milhões de dólares, 12% acima do ano anterior. O relatório atribui parte do aumento a ataques acelerados por inteligência artificial, que acrescentam, em média, cerca de 1 milhão de dólares ao custo total de uma violação.
Que ferramentas ajudam a detetar configurações inseguras em ambientes serverless?
Ferramentas de CSPM e CNAPP, como as comparadas em artigos anteriores sobre Sysdig, Orca e Lacework, analisam continuamente permissões, segredos expostos e configurações de rede em contas cloud, sinalizando desvios antes que sejam explorados. Combinadas com uma política de menor privilégio desde o início do projeto, reduzem significativamente a probabilidade de repetir os erros documentados nos casos descritos neste artigo.
