Como verificar onde seus dados são armazenados antes de migrar para a nuvem

Saber em qual região um recurso é armazenado ajuda a avaliar requisitos de residência, latência, redundância e recuperação. A localização deve ser revisada por serviço e por recurso: no Cloud Storage, por exemplo, o tipo de localização determina como a informação é replicada.

Para uma migração regulada, separe três perguntas: onde os dados principais são armazenados, onde podem ser replicados ou processados e quais entidades podem acessá-los. A localização deve ser avaliada por recurso e por serviço, junto com as condições aplicáveis à organização.

A localização também afeta decisões técnicas. No Google Cloud Storage, uma região, uma birregião e uma multirregião têm comportamentos distintos de redundância e custo; colocar o armazenamento perto da computação pode ajudar o desempenho. Escolha a localização conforme o requisito concreto, não porque o nome geográfico parece suficiente.

No Google Cloud Storage, uma região é um lugar geográfico específico; uma birregião compreende duas regiões e uma multirregião abrange uma zona geográfica ampla com duas ou mais regiões. O tipo de localização determina como a informação é replicada e tarifada. As opções concretas dependem do serviço.

Não assuma que um código de região identifica um único edifício. No Cloud Storage, o Google distingue localizações regionais, birregionais e multirregionais; os objetos de uma birregião são replicados nas regiões que a compõem, enquanto uma multirregião cobre uma zona geográfica mais ampla. A granularidade configurada pelo cliente depende do serviço e não deve ser confundida com a localização física de cada cópia.

Nem todos os serviços de um mesmo projeto herdam uma localização única. A documentação do Firebase indica que produtos como Cloud Firestore e Cloud Storage requerem localizações configuradas por instância ou bucket, e que algumas funções têm uma região padrão se outra não for especificada. Uma configuração do projeto não prova automaticamente onde estão todos os seus recursos.

Comece por inventariar os serviços que conterão dados pessoais ou confidenciais: bancos de dados, buckets, discos, backups, filas, registros e serviços de análise. Para cada item, anote o identificador do recurso, o serviço, a região configurada, a conta ou projeto proprietário e as dependências que podem gerar cópias ou processamento adicional. A unidade de verificação é o recurso, não apenas a conta em nuvem.

No Google Cloud Storage, a localização faz parte dos metadados do bucket e pode ser consultada com permissões adequadas. A documentação oficial distingue região, birregião e multirregião, e especifica que a localização escolhida influencia a replicação e o preço. No Firebase, o guia de localizações descreve onde revisar a localização de bancos de dados, buckets, backends e funções; alguns produtos, como Gemini Developer API no Firebase AI Logic, são descritos como globais.

O guia do AWS DataSync indica que, para transferir dados para um bucket Amazon S3 ou a partir dele, é criada uma localização de transferência e o DataSync recebe acesso ao bucket por meio de um papel IAM. Essa configuração descreve o acesso necessário para a transferência.

O Azure Portal permite administrar recursos e vê-los organizados por serviço e grupo de recursos. Para verificar a residência, identifique a região concreta de cada recurso e verifique separadamente as funções que o acompanham, como redundância geográfica, recuperação de desastres e serviços de monitoramento. Uma região de implantação não demonstra que todo dado derivado ou auxiliar tem o mesmo alcance territorial.

Antes de atribuir valor a uma certificação ISO/IEC 27001 em uma migração, identifique o escopo específico do certificado: a entidade certificada, os serviços incluídos, as regiões cobertas e as atividades sujeitas à auditoria. Essa verificação é necessária porque o escopo pode variar conforme o provedor e não garante automaticamente a residência dos dados em uma localização específica.

Os provedores publicam escopos que podem variar por serviço ou geografia. Por exemplo, a Esri explica que o escopo de sua certificação ISO 27001 para ArcGIS ISO Cloud se aplica a serviços hospedados em sua localização regional europeia e não se estende automaticamente à APAC. Também esclarece que as certificações da AWS ou Microsoft Azure sobre a infraestrutura subjacente não ampliam por si mesmas o escopo da certificação da Esri.

A página de conformidade da OVHcloud distingue os serviços incluídos e aponta um perímetro específico para data centers dos Estados Unidos. Como verificação prática, solicite o certificado e revise seu escopo para o serviço contratado. Uma certificação apoia controles incluídos nesse escopo.

Avalie separadamente segurança, privacidade, conformidade e localização. Verifique o escopo concreto de cada certificado ou relatório: pode identificar a entidade, os serviços e as localizações incluídas. A OVHcloud, por exemplo, indica que seus certificados e relatórios cobrem serviços hospedados em seus data centers, com um perímetro específico para os Estados Unidos.

Para conhecer a localização de um recurso, consulte os metadados ou a configuração de localização oferecida pelo serviço. No Cloud Storage, a localização do bucket faz parte de seus metadados e pode ser consultada com as permissões adequadas.

Outro erro é assumir que todos os serviços de um mesmo projeto têm uma localização única. O Firebase distingue recursos cuja localização é configurada por instância, bucket ou backend, e produtos para os quais não se pode selecionar uma localização, como Gemini Developer API no Firebase AI Logic. Revise a localização conforme o produto e o recurso.

Por fim, não confunda disponibilidade regional com a localização de cada objeto. As opções de redundância podem implicar réplicas em várias regiões; isso pode ser desejável para resiliência, mas deve caber nas restrições de residência. Confirme qual modalidade está ativa, como se comporta a recuperação e se existem restrições para mudar ou mover a localização.

Antes de aprovar a transferência, converta o requisito legal e operacional em verificações que possam ser demonstradas e mantidas. Uma captura de tela pode servir como registro pontual, mas não substitui uma cláusula contratual nem um procedimento de controle de mudanças. Mantenha a configuração e sua data de revisão no inventário de ativos.

• Identifique cada serviço e recurso que armazenará, replicará ou processará dados sensíveis.
• Registre região, zona se aplicável, modalidade de redundância e localização de backups.
• Verifique no console ou metadados a localização efetiva e quem tem permissões para modificá-la.
• Revise as localizações de registros, suporte, monitoramento, análise e serviços conectados.
• Solicite certificados e relatórios com escopo, entidade, serviço, geografia e validade identificáveis.
• Contraste residência e transferências com o contrato, os termos do serviço e a análise legal aplicável.
• Defina quem revisará mudanças de região, novas réplicas e exceções após a migração.

A decisão final não consiste em escolher um país a partir de uma etiqueta de produto, mas em verificar que a arquitetura satisfaz o requisito. Documente as localizações e modalidades de redundância configuradas para cada recurso e avalie qualquer componente cuja localização você não possa determinar em relação às necessidades da carga de trabalho.

O resultado prático é um arquivo por carga de trabalho: recursos identificados, localizações documentadas, escopo contratual e certificações pertinentes, junto com responsáveis e controles de mudança. Se você não puder demonstrar a localização de uma peça crítica, não a trate como equivalente às outras nem presuma que fica coberta pela região principal.