Escolher uma região de nuvem pode parecer uma decisão de infraestrutura: seleciona-se uma localização e implementam-se nela as aplicações. No entanto, exigir que os dados permaneçam numa região também afeta cópias, registos, suporte, análise e recuperação após falhas. Pode ser um requisito necessário, uma preferência comercial ou uma medida que não resolve o risco mais importante.
Para decidir quando precisa de residência de dados por região, comece pelos dados e pelas obrigações aplicáveis, não por um mapa de centros de dados. A questão prática é saber que informação deve permanecer onde, em que condições e durante que fases do seu ciclo de vida. Depois, compare esse requisito com a arquitetura e os controlos efetivamente oferecidos pelo fornecedor.
Residência, localização e soberania não são a mesma coisa
A residência de dados refere-se, em geral, à localização geográfica onde determinados dados são armazenados. A localização pode descrever requisitos mais específicos sobre onde são processados, alojados ou conservados. Já a soberania de dados costuma dizer respeito às leis e autoridades que podem ter jurisdição sobre os dados ou sobre a entidade que os controla. O uso destes termos não é uniforme: confirme o significado de cada um no contrato e no quadro aplicável.
O facto de um dado estar armazenado numa região não prova, por si só, que nunca sairá dela nem que apenas pessoal local lhe poderá aceder. Uma operação de suporte, uma réplica, uma cópia de segurança ou um serviço externo podem envolver outros países ou jurisdições, dependendo da arquitetura e das condições do serviço. Por outro lado, uma organização pode restringir o acesso e as transferências sem exigir que todo o processamento ocorra num único local.
Por isso, separe as perguntas: onde os dados são guardados, onde são processados, quem lhes pode aceder, que transferências ocorrem e que entidade presta cada serviço. Se uma política exigir apenas baixa latência ou continuidade, a residência não será necessariamente a resposta.
Comece pelos dados e processos afetados
Faça um inventário prático dos fluxos de informação do produto. Não precisa de começar por classificar cada campo de todas as bases de dados: agrupe os dados por função, sensibilidade, origem e utilização. Considere, por exemplo, informações de clientes, dados de conta, conteúdos enviados, registos técnicos, telemetria e dados derivados para análise. Não parta do princípio de que os registos ou as cópias contêm menos informação sensível do que a base de dados principal.
Para cada grupo, documente o percurso: onde é recolhido, onde é processado, que sistemas o recebem, durante quanto tempo é conservado e como é eliminado. Inclua ambientes de desenvolvimento e teste se puderem conter dados reais, bem como exportações, ferramentas de observabilidade e fornecedores integrados. Esta visão ajuda a detetar situações em que o armazenamento principal está limitado a uma região, mas uma dependência conserva registos ou cópias noutra localização.
Em seguida, associe cada requisito a dados e processos concretos. Uma exigência vaga como «tudo tem de ficar no país» é difícil de validar. Uma formulação operacional é mais útil: que categorias estão abrangidas, se o requisito inclui processamento e cópias, que exceções existem e que provas são necessárias para demonstrar o cumprimento.
Confirme as obrigações e expectativas antes de escolher uma região
O requisito pode ter várias origens: legislação aplicável, contrato com um cliente, política interna, condições de um concurso ou expectativa do mercado. Estas fontes não são equivalentes. A conclusão depende do tipo de dados, das partes, das operações e das jurisdições relevantes; não decorre simplesmente de os utilizadores estarem num determinado país.
Envolva as equipas jurídica, de privacidade, segurança, compras e negócio. Peça-lhes que confirmem o âmbito e distingam uma obrigação vinculativa de uma preferência. Nos contratos, reveja as cláusulas sobre localização, subcontratantes, acesso do suporte, transferências, notificação de alterações e eliminação no fim do serviço. Se o requisito for ambíguo, registe a interpretação acordada e quem a aprovou, em vez de a converter diretamente numa decisão técnica difícil de reverter.
Também é importante ouvir o cliente sem transformar cada pedido numa arquitetura especial. Pergunte que risco pretende reduzir e que provas aceitaria. Por vezes, a preocupação é o acesso não autorizado, a continuidade do serviço ou a latência; cada situação pode exigir controlos diferentes. Uma região de armazenamento não substitui a análise do acesso, da encriptação, da gestão de chaves nem das obrigações relativas a transferências.
Armazenamento regional ou controlos de acesso
Uma região dedicada pode simplificar a demonstração do local de residência de determinados dados e ajudar a cumprir compromissos contratuais específicos. Também pode reduzir a latência para utilizadores próximos, embora isso dependa da conceção global e da distribuição dos serviços. Em contrapartida, pode limitar as opções de redundância, criar diferenças entre regiões ou exigir implementações e operações separadas.
Se a principal preocupação for quem pode aceder aos dados, avalie controlos de identidade, privilégios mínimos, registo de acessos, encriptação e gestão de chaves. Se a preocupação for uma transferência internacional, identifique os fluxos e os mecanismos que os regulam, com apoio jurídico. Se estiver em causa a continuidade, conceba a recuperação após falhas e confirme onde os dados são restaurados. Nenhum destes controlos elimina automaticamente um requisito explícito de residência, mas pode ser mais adequado quando a necessidade real é outra.
Antes de assumir um compromisso, confirme as capacidades concretas do serviço contratado. A expressão «região selecionada» pode não abranger todos os componentes. Peça documentação sobre cada serviço e pergunte que opções existem para restringir localizações, acessos e transferências. Não presuma que o fornecedor aplica a mesma política a bases de dados, cópias, registos e ferramentas de suporte.
Avalie as dependências e toda a operação
Trace o percurso para além do armazenamento principal. No mínimo, reveja:
- Cópias e recuperação: localização de cópias de segurança, réplicas, instantâneos e destino de uma restauração. A política de residência deve esclarecer se todos estão abrangidos.
- Registos e observabilidade: localização de registos, métricas, rastos, alertas e despejos de erros; confirme se podem incluir identificadores ou conteúdos.
- Suporte e administração: quem pode aceder, a partir de onde, com que autorização e que registo é mantido. O alojamento regional não implica necessariamente suporte local.
- Análise e integrações: destinos das exportações, ferramentas ligadas, armazéns de dados e fornecedores secundários.
- Retenção e eliminação: prazos, eliminação de cópias e tratamento dos dados quando a conta é encerrada ou se muda de fornecedor.
Uma arquitetura pode parecer conforme em produção e falhar durante uma restauração, uma exportação ou uma investigação de incidentes. Por isso, teste o requisito através de cenários operacionais, não apenas com base numa declaração comercial. Se a resposta do fornecedor não identificar os limites do serviço ou depender de pressupostos, trate a situação como uma incerteza a resolver antes do lançamento.
Matriz prática: uma região, várias regiões ou arquitetura híbrida
Use estas opções como ponto de partida, não como soluções universais:
- Uma região: pode ser suficiente quando o requisito está bem delimitado, o serviço e as dependências permitem manter nela os dados relevantes e o impacto na disponibilidade e na recuperação é aceitável.
- Várias regiões: pode ser adequada para resiliência, desempenho ou presença em diferentes mercados, desde que as obrigações permitam a replicação e se saiba onde fica cada cópia. A redundância entre regiões pode entrar em conflito com uma restrição territorial.
- Arquitetura híbrida: pode separar categorias de dados ou funções, mantendo certos dados numa localização e utilizando serviços partilhados para outros componentes. Acrescenta interfaces, controlos e testes; é necessário demonstrar que os fluxos entre componentes respeitam as regras definidas.
A decisão deve considerar tanto a obrigação como a operação: custo da complexidade, objetivos de recuperação, latência, capacidade da equipa e facilidade de mudar de fornecedor. Se não existir um requisito que justifique a segregação, evite criar uma exceção regional que a equipa não consiga manter. Se existir, identifique claramente o que fica excluído e como essas exceções são controladas.
Perguntas ao fornecedor e revisão da decisão
Antes de contratar ou migrar, pergunte que regiões estão disponíveis para cada serviço, que dados cada componente processa e onde são guardadas as cópias, os registos e os metadados relevantes. Peça esclarecimentos sobre a gestão do suporte, dos subcontratantes, das transferências e da recuperação após falhas. Confirme também se é possível obter provas verificáveis e o que acontece quando o fornecedor altera a arquitetura ou as condições.
Documente a decisão, incluindo o requisito, as categorias de dados, os fluxos abrangidos, as exceções, os controlos, as dependências e os responsáveis. Registe as questões pendentes e os critérios para voltar a analisar o assunto. Reveja a decisão quando mudarem os mercados, o produto, os fornecedores, os contratos ou as obrigações aplicáveis, e após incidentes ou testes de recuperação que revelem um fluxo não considerado.
Em suma, exija residência regional quando uma obrigação ou um risco identificado o justificar e for possível definir o seu âmbito de forma verificável. Se a necessidade for desempenho, acesso ou resiliência, compare primeiro as medidas concebidas para esses objetivos. A melhor decisão é a que satisfaz o requisito real sem criar uma promessa geográfica mais ampla do que a arquitetura consegue cumprir.