Se seus requisitos de localidade de dados estiverem relacionados à restrição de quem pode acessar os dados, a implementação de métodos de criptografia poderá ser uma estratégia aplicável. Ao usar sistemas de gerenciamento de chaves externos para gerenciar as chaves fornecidas fora do Google Cloud, é possível implantar uma arquitetura multirregional para atender aos seus requisitos de localidade. Sem as chaves disponíveis, os dados não podem ser descriptografados.
Chaves de criptografia fornecidas pelo cliente (CSEK): use a CSEK com o Cloud Storage e o Compute Engine. O Google usa sua chave para proteger as chaves geradas pelo Google que são usadas para criptografar e descriptografar seus dados.
Se você fornecer uma chave de criptografia fornecida pelo cliente, o Google não armazenará permanentemente sua chave nos servidores do Google nem gerará sua chave. Em vez disso, forneça sua chave para cada operação. Ela será removida dos servidores do Google após a conclusão da operação.
Ao gerenciar sua própria infraestrutura de chaves, considere cuidadosamente os problemas de latência e confiabilidade e implemente os processos apropriados de alta disponibilidade e recuperação para seu gerenciador de chaves externo. Também é preciso entender os requisitos de RTO. As chaves são essenciais para gravar os dados. Portanto, o RPO não é a preocupação crítica porque nenhum dado pode ser gravado sem as chaves. A preocupação real é o RTO porque sem suas chaves, não é possível criptografar ou gravar dados com segurança.
Ao arquitetar a DR para cargas de trabalho restritas por localidade, você precisa garantir que os dados em repouso estejam localizados na região de que você precisa. Configurar os serviços de armazenamento de objetos e arquivos do Google Cloud para atender aos seus requisitos
Além dos recursos discutidos na seção do Cloud Storage do artigo Elementos básicos da recuperação de desastres, ao projetar a DR para cargas de trabalho restritas por localidade, considere a redundância geográfica. Redundância geográfica refere-se ao armazenamento de dados de forma redundante em pelo menos duas áreas geográficas separadas por no mínimo 160 km. Objetos armazenados em locais birregionais e multirregionais têm redundância geográfica independentemente da classe de armazenamento. A redundância geográfica garante a máxima disponibilidade dos seus dados, mesmo durante interrupções em grande escala, como desastres naturais. Para regiões duplas, é possível conseguir redundância geográfica usando duas regiões específicas. Para multirregiões, é possível conseguir redundância geográfica usando qualquer combinação de data centers na multirregião especificada, o que pode incluir data centers que não estão explicitamente listados como regiões disponíveis.
A sincronização de dados entre os buckets ocorre de forma assíncrona. Se você precisa de um alto grau de confiança de que os dados foram gravados em uma região alternativa para atender aos valores de RTO e RPO, uma estratégia é usar dois buckets de região única. Em seguida, grave duas vezes o objeto ou grave-o em um bucket e faça com que o Cloud Storage copie (rewriteTo) o segundo bucket.
Se seus requisitos restringirem o uso de uma única região (por exemplo, Londres ou Zurique), você estará restrito a essa região e não poderá implementar uma arquitetura geograficamente redundante usando apenas o Google Cloud. Nesse cenário, use uma ou mais das seguintes técnicas:
Adote uma estratégia híbrida ou de várias nuvens. Essa abordagem permite escolher outra solução de nuvem ou local na mesma área geográfica da sua região do Google Cloud. É possível armazenar cópias dos dados nos buckets do Cloud Storage no local ou usar o Cloud Storage como destino para os dados de backup.
Se você estiver usando a AWS como seu outro provedor de nuvem, consulte o guia de interoperabilidade do Cloud Storage para saber como configurar o acesso ao Amazon S3 usando as ferramentas do Google Cloud.