Cloudמַעֲלוֹת
Maturidade de cloud com IA: de força em força, degrau por degrau
Um modelo de cinco níveis para maturidade de cloud, como medir pelos seis pilares, onde a IA encurta a subida e o que fazer nos primeiros 90 dias.
וְעָשִׂיתָ מַעֲקֶה לְגַגֶּךָ
ve'asita ma'akeh legagecha · farás um parapeito para o teu telhado · Devarim 22:8
Blog/Artigos · Cloud
Cloud security com IA: farás um parapeito para o teu telhado
Responsabilidade compartilhada, guardrail preventivo e detectivo, identidade como perímetro e postura corrigida por pull request.
A Torá manda quem constrói uma casa nova fazer um parapeito no telhado, para que ninguém caia dali. A obrigação é de quem constrói, antes de alguém se machucar, e vale mesmo que nunca ninguém tenha caído. É a melhor definição que eu conheço de guardrail preventivo em cloud. O parapeito fica pronto antes da primeira pessoa subir, e ele não depende do cuidado de quem sobe.
Quem constrói o parapeito: a responsabilidade compartilhada
O provedor de cloud protege a infraestrutura física, o hipervisor e os serviços que ele opera. O cliente protege o que coloca em cima: dado, identidade, configuração e aplicação. A linha entre os dois muda conforme o modelo de serviço, e a maior parte dos incidentes que eu investiguei aconteceu do lado do cliente, em configuração que ninguém revisou.
Duas camadas nunca saem da mão do cliente, em nenhum modelo: o dado e a identidade. Bucket público, chave de acesso esquecida num repositório e papel com permissão de administrador para uma função Lambda são falhas do cliente mesmo no serviço mais gerenciado.
Figura 1Modelo de responsabilidade compartilhada, por tipo de serviço
| Camada | IaaS | PaaS | SaaS |
|---|---|---|---|
| Dado e classificação | cliente | cliente | cliente |
| Identidade e acesso | cliente | cliente | cliente |
| Aplicação | cliente | cliente | provedor |
| Sistema operacional e patch | cliente | provedor | provedor |
| Controle de rede do workload | cliente | compartilhado | provedor |
| Infraestrutura física e hipervisor | provedor | provedor | provedor |
Guardrail preventivo e detectivo, em camadas
Guardrail preventivo impede a ação antes de ela acontecer. Na AWS, a Service Control Policy da organização é o parapeito mais alto: nenhuma identidade da conta consegue fazer o que a SCP nega, nem o administrador local. Desligar a trilha de auditoria, sair da organização e usar região não autorizada são as primeiras negações que eu aplico.
Guardrail detectivo percebe o que o preventivo não cobre. Registro de configuração, detecção de ameaça e agregação de achados rodam em todas as contas desde o dia em que a conta nasce, por baseline automatizado. Conta nova sem baseline é a porta mais comum de entrada que eu já vi.
Figura 2Camadas de guardrail numa organização AWS, da mais ampla à mais específica
- Organização SCPnega o que ninguém pode fazer: desligar CloudTrail, sair da organização, usar região proibida
- Conta baselineCloudTrail, Config, GuardDuty e Security Hub ativos desde a criação
- Identidade IAMacesso por SSO, permission boundary, sem chave de longa duração
- Rede VPCworkload em subnet privada, endpoint para serviço gerenciado, saída controlada
- Dado KMScriptografia com chave gerenciada, bloqueio de acesso público no S3
- Detecção CSPMachado agregado, priorizado e com dono, revisado todo dia
Identidade é onde o ataque acontece
Em cloud o atacante raramente quebra criptografia ou explora hipervisor. Ele obtém uma credencial com permissão um pouco maior que a necessária e anda por ela. Uma permissão de passar papel para um serviço, combinada com a capacidade de criar esse serviço, é suficiente para herdar um papel administrativo.
O caminho de escalonamento quase nunca aparece olhando uma política isolada. Ele aparece no grafo: quem pode assumir quem, em qual conta, com qual condição. Num dos meus projetos a análise read-only de um ambiente de laboratório encontrou 12 caminhos de escalonamento cross-account chegando a 9 alvos sensíveis.
Figura 3Exemplo de caminho de escalonamento de privilégio
- 01Credencial vazadadesenvolvedor com iam:PassRole e lambda:CreateFunction
- 02Nova funçãocria uma função e passa para ela um papel mais privilegiado
- 03Papel herdadoo código da função roda com o papel administrativo
- 04Confiança cross-accounto papel pode assumir outro papel na conta de produção
- 05Alvo sensíveldado de cliente ou chave de criptografia em produção
IA sobre a postura: priorizar e corrigir por pull request
Ferramenta de postura em cloud gera milhares de achados em ambiente grande. Tratar por severidade nominal leva o time a corrigir primeiro o que é fácil, e o recurso exposto à internet com dado sensível fica esperando na mesma fila de uma tag ausente.
A priorização que funciona combina exposição, sensibilidade do dado e caminho de ataque. Depois de priorizado, o achado vira correção no código de infraestrutura, por pull request, com revisão. Corrigir pelo console resolve o achado e cria drift, e o próximo apply do Terraform desfaz a correção.
Figura 4De achado de postura a correção no código de infraestrutura
- 01AchadosCSPM e detecção de ameaça agregados por conta
- 02Deduplicaçãoo mesmo problema em cem recursos vira um caso
- 03IAPriorizaçãoexposição, sensibilidade do dado e caminho de ataque
- 04IAExplicaçãorisco em linguagem de negócio e dono provável
- 05IAPull requestcorreção no Terraform, com plano anexado
- 06Revisão e applypessoa aprova, pipeline aplica, achado fecha sozinho
O parapeito em código
Um parapeito bom é simples, visível e difícil de remover. A SCP abaixo nega três ações que nenhuma conta de uma organização deveria conseguir executar: parar ou apagar a trilha de auditoria e sair da organização. Ela é pequena de propósito, porque guardrail preventivo com muitas regras vira fonte de incidente.
A política vive no repositório de infraestrutura, com revisão obrigatória e teste de que a negação funciona. Mudar o parapeito é mudança crítica, com registro, e passa pelo mesmo rito de qualquer alteração em produção.
Figura 5Service Control Policy que protege a trilha de auditoria
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "ProtegeTrilhaDeAuditoria",
"Effect": "Deny",
"Action": [
"cloudtrail:StopLogging",
"cloudtrail:DeleteTrail",
"organizations:LeaveOrganization"
],
"Resource": "*"
}
]
}Para levar
Cloud security começa pelo que é seu no modelo compartilhado e se sustenta em parapeitos construídos antes de alguém subir no telhado: SCP na organização, baseline em toda conta, identidade com menor privilégio e postura corrigida por código. A IA prioriza, explica e redige a correção; o parapeito continua sendo responsabilidade de quem constrói.
Quem escreve: Juliano Vince de Campos
Gerente de Operações, Tecnologia e Infraestrutura (SRE) numa central de registros. Trabalho com tecnologia desde 2009 e com cibersegurança em tempo integral desde 2015, em infraestrutura crítica, fintech e banking. Escrevo sobre o que eu opero: confiabilidade, segurança, governança e IA que passa por gate antes de chegar em produção.
