Multi-cloud: por que os controles de segurança não funcionam da mesma forma
Adotar mais de um provedor de nuvem não significa apenas administrar duas plataformas. O desafio real é manter a segurança consistente sem presumir que serviços com nomes parecidos oferecem os mesmos recursos, configurações ou resultados. Identidade, registros de atividade, rede, criptografia e serviços gerenciados podem seguir regras diferentes – e uma pequena divergência pode se transformar em uma falha importante.
Há várias razões para uma empresa operar em ambientes distintos: exigências regionais, aquisições, custos, necessidades específicas de determinados serviços ou decisões tomadas por equipes diferentes ao longo do tempo. A estratégia pode fazer sentido. O risco surge quando a governança tenta tratar AWS, Azure, Google Cloud e outros provedores como versões intercambiáveis de uma única plataforma.
A política corporativa pode ser comum, mas sua implementação raramente será idêntica. Uma regra como “não utilizar credenciais permanentes em workloads” expressa um objetivo claro. Para cumpri-lo, porém, cada provedor pode exigir mecanismos próprios de identidade, federação, funções e relações de confiança. O princípio permanece; a configuração muda.
Identidade exige mais do que copiar permissões
O gerenciamento de identidades e acessos (IAM) costuma ser um dos primeiros pontos em que a equivalência entre nuvens falha. Papéis, herança de permissões, escopos, delegação e identidades de workload são organizados de maneiras diferentes. Assim, uma configuração considerada restritiva em uma plataforma pode conceder acesso mais amplo em outra.
Por isso, traduzir privilégios não é uma tarefa de copiar e colar. A organização precisa definir o que cada identidade deve poder fazer, em quais recursos e sob quais condições. Depois, deve implementar esse resultado usando os mecanismos adequados de cada ambiente e verificar se as permissões efetivas correspondem à intenção.
Listas de verificação baseadas apenas em nomes – como “IAM habilitado”, “logs ativados” ou “criptografia configurada” – oferecem pouca garantia. Elas confirmam a presença de um recurso, mas não demonstram que o controle está cobrindo os ativos certos ou reduzindo o risco esperado.
Centralizar logs não garante visibilidade uniforme
Enviar registros de todas as nuvens para um SIEM é um passo útil, mas não resolve automaticamente o monitoramento. Os eventos podem ter formatos, campos, períodos de retenção e significados diferentes. Em um provedor, uma alteração de privilégio pode aparecer em um único registro; em outro, pode ser necessário correlacionar várias ocorrências para entender o que aconteceu.
Uma operação de segurança precisa conseguir responder às mesmas perguntas em cada ambiente: quem realizou a mudança, quando, de onde, usando qual identidade e sobre qual escopo? Se essas respostas dependem de interpretações distintas ou de dados ausentes, houve centralização de registros, mas não necessariamente visibilidade consistente.
Configuração e proteção de dados também variam
A infraestrutura como código ajuda a padronizar implantações, mas não elimina todas as exceções. Recursos podem ser criados manualmente, serviços gerenciados podem exigir ajustes próprios e diferentes pipelines podem aplicar configurações distintas. Por isso, é importante detectar desvios entre o estado aprovado e o estado realmente existente na nuvem.
A mesma atenção vale para dados. Chaves, regiões de armazenamento, replicação, criptografia e retenção não são necessariamente equivalentes entre provedores. Uma informação classificada como sensível deve receber proteção compatível com sua classificação, mesmo que o mecanismo usado para isso seja diferente em cada plataforma.
Um modelo corporativo de classificação ajuda a separar o objetivo de segurança do serviço escolhido. Em vez de exigir uma configuração idêntica em todos os ambientes, a empresa define requisitos verificáveis – por exemplo, quais dados podem ser armazenados em determinada região, como as chaves devem ser protegidas e por quanto tempo os registros precisam ser mantidos.
Como construir consistência sem uniformizar as nuvens
O rascunho do NIST IR 8613, publicado em 2026, organiza desafios de segurança e conformidade associados a arquiteturas multi-cloud. Entre os pontos destacados estão as diferenças entre serviços nativos, a complexidade operacional e a dificuldade de aplicar capacidades centralizadas em provedores distintos.
Na prática, uma estratégia consistente começa por definir resultados, e não configurações idênticas. Para cada controle, a organização deve descrever o risco que pretende reduzir, os sistemas abrangidos, os responsáveis e as evidências necessárias para demonstrar que o requisito está sendo cumprido.
Em seguida, é preciso criar uma matriz de controles por provedor. Ela relaciona cada objetivo corporativo aos recursos nativos usados em cada nuvem, aponta limitações e registra eventuais compensações. Quando uma plataforma não oferece exatamente o mesmo mecanismo, a diferença precisa ser documentada e avaliada – não ignorada.
A automação pode reforçar esse trabalho. Políticas como código, verificações contínuas de configuração e alertas para mudanças inesperadas ajudam a identificar desvios antes que se tornem incidentes. Essas ferramentas devem testar o comportamento real dos recursos, e não apenas confirmar que um modelo ou uma política foi aplicado.
Também é essencial definir responsabilidades por plataforma. A diversidade de ambientes amplia o conhecimento necessário: dominar profundamente IAM, rede, registros e serviços gerenciados em várias nuvens é difícil. Treinamento específico, responsáveis claros e revisão técnica reduzem o risco de configurações familiares na aparência, mas inadequadas na prática.
Padrões corporativos são úteis, desde que admitam exceções justificadas. Se um serviço não se encaixa no modelo comum, a equipe deve explicar a diferença, avaliar o risco, propor controles compensatórios e estabelecer um prazo para revisão. Uma exceção sem responsável ou data de reavaliação tende a se tornar permanente sem que ninguém perceba.
Por fim, a consistência precisa ser medida. Testes periódicos devem verificar se as permissões estão adequadas, se os registros permitem reconstruir ações relevantes, se as configurações continuam conformes e se os dados mantêm a proteção exigida. Comparar esses resultados entre provedores revela lacunas que uma política escrita, por si só, não consegue mostrar.
Multi-cloud seguro não significa fazer todas as nuvens operarem de maneira igual. Significa estabelecer objetivos comuns, implementar cada controle conforme as características da plataforma e comprovar que o resultado de segurança é equivalente.