Mover um workload para uma região pode cumprir um requisito de localização e ainda deixar inalterados jurisdição, acesso privilegiado, chaves de criptografia, cadeia de software e dependências de recuperação. Comece pelo risco que precisa controlar e desenhe a operação em torno dele.
O Cloud Sovereignty Framework da Comissão Europeia avalia oito objetivos de soberania e combina níveis de garantia com uma pontuação baseada em 48 critérios. Em abril de 2026, a Comissão concedeu um contrato de cloud a quatro provedores; a explicação e a orientação de implementação publicadas em junho descrevem o framework e as lições da contratação. É uma ferramenta de avaliação para compras públicas, não uma certificação universal que resolva automaticamente o risco jurídico ou técnico de cada cliente.
A Comissão também propôs o Cloud and AI Development Act. A proposta descreve quatro níveis de garantia para soberania de cloud e IA, mas ainda é uma proposta legislativa. Acompanhe sua tramitação sem tratar o texto preliminar como obrigação já vigente.
Residência de dados responde onde determinados dados são armazenados ou processados. Soberania é mais ampla: quem governa e opera o serviço, quais leis podem se aplicar, quem consegue acessar, quem controla as chaves, como hardware e software são fornecidos e se o cliente consegue continuar operando ou sair. Geopatriação é mover workloads ou dependências para jurisdições escolhidas por motivos estratégicos, regulatórios ou de resiliência. É uma estratégia de posicionamento, não uma propriedade de segurança por si só.
| Risco | Controle de arquitetura | Evidência a manter | Sinal de falha |
|---|---|---|---|
| Localização dos dados | Classifique cada armazenamento e processamento; restrinja região, réplica, backup, log, telemetria e exportação de suporte. | Inventário de recursos, avaliação de política, mapa de fluxo, local do backup e responsável por exceções. | Novo recurso fora da geografia aprovada ou cópia desconhecida. |
| Jurisdição e acesso | Revise entidade contratada, propriedade/controle, subprocessadores, suporte, divulgação e salvaguardas de transferência com assessoria jurídica. | Versão do contrato, lista de subprocessadores, compromissos de acesso, avaliação e data de revisão. | Mudança de controle, suporte, termos legais ou subcontratado. |
| Identidade e operação | Identidade federada, MFA resistente a phishing, papéis limitados, elevação temporária, aprovação para suporte sensível e break-glass separado. | Concessões, sessões, aprovações, revisão de acesso e exercício emergencial. | Admin persistente do fornecedor, conta compartilhada ou sessão sem log. |
| Criptografia e chaves | Criptografe em trânsito e repouso; escolha controle de chaves conforme ameaça; teste rotação, revogação, backup e comportamento do serviço. | Propriedade da chave, política, rotação, logs de acesso, recuperação e limitações do provedor. | Chave somente sob controle do provedor quando se exige independência, ou perda irrecuperável. |
| Portabilidade e saída | Prefira APIs e formatos documentados; separe dados do negócio da lógica proprietária; ensaie exportação, restore e encerramento contratual. | Inventário de exportação, tempo/custo medidos, restore, dependências e runbook de saída. | Dependência proprietária não testada, exportação inutilizável ou recuperação acima do RTO. |
| Recuperação regional | Defina RTO/RPO, replique apenas dados permitidos, mantenha credenciais e artefatos independentes e teste identidade, DNS, secrets e observabilidade. | Linha do exercício, perda de dados, aprovações, retorno e lacunas restantes. | Região secundária depende do control plane afetado ou não pode receber dados legalmente. |
Uma segunda região não é automaticamente um local seguro de recuperação. Replicação pode ultrapassar uma fronteira de residência; um tenant de identidade compartilhado pode derrubar as duas regiões; um serviço central de chaves pode impedir recuperação; e bancos proprietários podem inviabilizar a saída. Para cada serviço crítico, documente geografia permitida, categorias que podem replicar, credenciais independentes, capacidade necessária e quem pode ativar o plano.
Registre para cada workload obrigações legais, controle operacional, proteção técnica, resiliência e portabilidade em campos separados. Um provedor pode ser forte em uma dimensão e fraco em outra. Não reduza tudo a uma caixa “soberano”: publique evidências, premissas e riscos residuais para o responsável pelo serviço.
Um catálogo de workloads conectado à classificação de dados e jurisdições; verificações de policy-as-code para regiões e identidade; coletor de evidências de acesso; testes de ciclo de chaves e recuperação; grafo de dependências de control planes e subprocessadores; pacote de exportação portável; e painel trimestral de exercícios de recuperação/saída. Cada controle teria responsável, fonte de evidência, validade, exceção e rota de alerta.
Escolha o posicionamento cloud a partir do threat model e do plano de continuidade. Verifique localização, exposição jurídica, acesso operacional, controle criptográfico, cadeia de fornecedores e saída com evidências. Reavalie após mudança legal, contratual, aquisição, região, subprocessador, suporte ou dependência crítica.
Nota jurídica: este é um texto de engenharia, não aconselhamento jurídico. Transferências de dados, regras setoriais, compras públicas e leis nacionais dependem dos dados, da entidade, do serviço e da jurisdição vigente.