As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá.
Elaboração de estratégias para uma expansão global
Pesquisa
Gostaríamos muito de ouvir você. Forneça feedback sobre o AWS PRA respondendo a uma breve pesquisa
O AWS Security Assurance Services
As seguintes perguntas são comuns e somente você pode respondê-las para seu caso de uso:
-
Onde os dados pessoais dos meus clientes precisam residir?
-
Onde os dados dos meus clientes estão armazenados?
-
Como e onde os dados pessoais podem cruzar fronteiras?
-
O acesso humano ou de serviços aos dados entre regiões constitui uma transferência?
-
Como posso ter certeza de que nenhum governo estrangeiro vai acessar os dados pessoais dos meus clientes?
-
Onde posso armazenar meus backups e locais quentes e frios?
-
Para manter os dados locais, devo manter uma zona de pouso da AWS em todas as regiões em que forneço serviços? Ou posso usar uma zona de pouso do AWS Control Tower existente?
Para requisitos de residência de dados, diferentes implantações de arquitetura podem funcionar melhor para diferentes organizações. Algumas organizações podem exigir que os dados pessoais de seus clientes permaneçam em uma região específica. Nesse caso, você pode ficar preocupado em como cumprir os regulamentos em geral e, ao mesmo tempo, cumprir essas obrigações. Independentemente da situação, há várias considerações ao escolher uma estratégia de implantação de várias contas.
Para definir os principais componentes do projeto de arquitetura, trabalhe em estreita colaboração com suas equipes de conformidade e contrato para confirmar os requisitos de onde, quando e como os dados pessoais podem cruzar as Regiões da AWS. Determine o que se qualifica como uma transferência de dados, como mover, copiar ou visualizar. Além disso, entenda se há controles específicos de resiliência e proteção de dados que devem ser implementados. As estratégias de backup e recuperação de desastres exigem failover entre regiões? Nesse caso, determine quais regiões você pode usar para armazenar seus dados de backup. Determine se há algum requisito para criptografia de dados, como um algoritmo de criptografia específico ou módulos de segurança de hardware dedicados para a geração de chaves. Depois de se alinhar com as partes interessadas em conformidade sobre esses tópicos, comece a considerar abordagens de projeto para seu ambiente de várias contas.
Confira três abordagens que você pode usar para planejar sua estratégia de várias contas da AWS, em ordem crescente de segregação da infraestrutura:
Também é importante lembrar que a conformidade com a privacidade pode não se limitar apenas à soberania de dados. Leia o restante deste guia para entender as possíveis soluções para muitos outros desafios, como gerenciamento de consentimento, solicitações de titulares de dados, governança de dados e viés de IA.
Zona de pouso central com regiões gerenciadas
Se você deseja expandir globalmente, mas já estabeleceu uma arquitetura de várias contas na AWS, é comum querer usar a mesma zona de pouso de várias contas (MALZ) para gerenciar outras Regiões da AWS. Nessa configuração, você continuará operando serviços de infraestrutura, como registro em log, fábrica de contas e administração geral na sua zona de pouso existente do AWS Control Tower, na região em que você a criou.
Para workloads de produção, você pode operar implantações regionais estendendo a zona de pouso do AWS Control Tower para uma nova região. Ao fazer isso, você pode estender a governança do AWS Control Tower para a nova região. Dessa forma, você pode manter os armazenamentos de dados pessoais em uma região gerenciada específica. Os dados ainda residem em contas que se beneficiam dos serviços de infraestrutura e da governança do AWS Control Tower. No AWS Organizations, as contas que contêm dados pessoais ainda são agrupadas em uma UO de dados pessoais dedicada, em que todas as barreiras de proteção de soberania de dados no AWS Control Tower são implementadas. Além disso, as workloads específicas da região estão contidas em contas dedicadas, em vez de estabelecer contas de produção que podem conter a mesma workload em várias regiões.
Essa implantação pode ser a mais econômica, mas é necessária uma consideração adicional para controlar o fluxo de dados pessoais entre Conta da AWS e fronteiras regionais. Considere o seguinte:
-
Os logs podem conter dados pessoais, portanto, algumas configurações adicionais podem ser necessárias para conter ou ocultar campos sensíveis para evitar a transferência entre regiões durante a agregação. Para obter mais informações e as práticas recomendadas para controlar a agregação de logs entre regiões, consulte Armazenamento de log centralizado neste guia.
-
Considere o isolamento de VPCs e o fluxo de tráfego de rede bidirecional apropriado no projeto do AWS Transit Gateway. Você pode limitar quais anexos do gateway de trânsito são permitidos e aprovados, além de limitar quem ou o que pode alterar as tabelas de rotas da VPC.
-
Talvez seja necessário impedir que membros da sua equipe de operações de nuvem acessem dados pessoais. Por exemplo, logs de aplicações que contêm dados de transações de clientes podem ser considerados de maior sensibilidade do que outras fontes de logs. Aprovações adicionais e barreiras de proteção técnicas podem ser necessárias, como controle de acesso baseado em perfil e controle de acesso baseado em atributo. Além disso, os dados podem estar sujeitos a limitações de residência quando se trata de acesso. Por exemplo, dados em uma região A só podem ser acessados de dentro dessa região.
O diagrama a seguir mostra uma zona de pouso centralizada com implantações regionais.
Zonas de pouso regionais
Ter mais de uma MALZ pode ajudar você a atingir requisitos de conformidade mais rígidos, isolando completamente as workloads que processam dados pessoais em comparação com as workloads não materiais. A agregação centralizada de registros em log do AWS Control Tower pode ser configurada por padrão e, portanto, simplificada. Com essa abordagem, você não precisa manter exceções para registro em log com fluxos separados de logs que exigem ocultação. Você pode até mesmo ter uma equipe de operações de nuvem local e dedicada para cada MALZ, o que limita o acesso do operador à residência local.
Muitas organizações têm implantações separadas de zona de pouso baseadas nos EUA e na UE. Cada zona de pouso regional tem uma postura de segurança única e abrangente e governança associada para contas na região. Por exemplo, a criptografia de dados pessoais usando HSMs dedicados pode não ser necessária em workloads em uma MALZ, mas pode ser necessária em outra MALZ.
Embora essa estratégia possa ser escalada para atender a muitos requisitos atuais e futuros, é importante compreender os custos adicionais e a sobrecarga operacional associados à manutenção de várias MALZs. Para obter mais informações, consulte Preços do AWS Control Tower
O diagrama a seguir mostra zonas de pouso separadas em duas regiões.
Nuvem soberana europeia da AWS
Algumas organizações exigem uma separação completa de suas workloads que operam no Espaço Econômico Europeu (EEE) e workloads que operam em outros lugares. Nessa situação, considere a nuvem soberana europeia da AWS
A nuvem soberana europeia da AWS é física e logicamente separada das Regiões da AWS existentes, ao mesmo tempo em que oferece a mesma segurança, disponibilidade e performance. Somente funcionários da AWS localizados na UE têm controle das operações e do suporte da nuvem soberana europeia da AWS. Se você tiver requisitos rigorosos de residência de dados, a nuvem soberana europeia da AWS mantém todos os metadados que você cria (como os perfis, as permissões, os rótulos de recursos e as configurações que eles usam para executar a AWS) na UE. A nuvem soberana europeia da AWS também possui seus próprios sistemas de métricas de faturamento e uso.
Para essa abordagem, você usará um padrão semelhante ao da seção anterior, Zonas de pouso regionais. No entanto, para os serviços que você fornece aos clientes europeus, você pode implantar uma MALZ dedicada na nuvem soberana europeia da AWS.
