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 expansão global
Pesquisa
Gostaríamos muito de ouvir de você. Forneça feedback sobre o AWS PRA respondendo a uma breve pesquisa
AWS
Os Serviços de Garantia de Segurança
As perguntas a seguir 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 do meu cliente sã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 acesse os dados pessoais dos meus clientes?
-
Onde posso armazenar meus backups e sites ativos ou desativados?
-
Para manter os dados locais, devo manter um AWS landing zone em todas as regiões em que presto serviços? Ou posso usar uma AWS Control Tower landing zone 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 estar preocupado em como cumprir os regulamentos em geral e, ao mesmo tempo, cumprir essas obrigações. Não importa a 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 ser cruzados Regiões da AWS. Determine o que se qualifica como 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 geração de chaves. Depois de se alinhar com as partes interessadas em conformidade sobre esses tópicos, comece a considerar abordagens de design para seu ambiente de várias contas.
A seguir estão três abordagens que você pode usar para planejar sua estratégia de AWS várias contas, 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 dos 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 preconceito de IA.
Landing zone central com regiões gerenciadas
Se você deseja expandir globalmente, mas já estabeleceu uma arquitetura de várias contas AWS, é comum usar a mesma landing zone de várias contas (MALZ) para gerenciar outras. Regiões da AWS Nessa configuração, você continuaria operando serviços de infraestrutura, como registro, fábrica de contas e administração geral, a partir de sua AWS Control Tower landing zone existente, na região em que você a criou.
Para cargas de trabalho de produção, você pode operar implantações regionais estendendo a AWS Control Tower landing zone para uma nova região. Ao fazer isso, você pode estender a AWS Control Tower governança 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 AWS Control Tower governança. Em AWS Organizations, as contas que contêm dados pessoais ainda são acumuladas em uma UO de Dados Pessoais dedicada, na qual todas as barreiras de soberania de dados são implementadas. AWS Control Tower Além disso, as cargas de trabalho específicas da região estão contidas em contas dedicadas, em vez de estabelecer contas de produção que podem conter a mesma carga de trabalho 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 fronteiras regionais. Considere o seguinte:
-
Os registros podem conter dados pessoais, portanto, algumas configurações adicionais podem ser necessárias para conter ou redigir campos confidenciais para evitar a transferência entre regiões durante a agregação. Para obter mais informações e práticas recomendadas para controlar a agregação de registros entre regiões, consulte Armazenamento centralizado de registros este guia.
-
Considere o isolamento VPCs e o fluxo de tráfego de rede bidirecional apropriado no AWS Transit Gateway design. Você pode limitar quais anexos do Transit Gateway 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, registros de aplicativos que contêm dados de transações de clientes podem ser considerados de maior confidencialidade do que outras fontes de registro. Aprovações adicionais e proteções técnicas podem ser necessárias, como controle de acesso baseado em funções e controle de acesso baseado em atributos. 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 landing zone centralizada com implantações regionais.
Zonas de pouso regionais
Ter mais de um MALZ pode ajudá-lo a atingir requisitos de conformidade mais rígidos, isolando completamente as cargas de trabalho que processam dados pessoais em comparação com as cargas de trabalho não materiais. AWS Control Tower a agregação centralizada de registros pode ser configurada por padrão e, portanto, simplificada. Com essa abordagem, você não precisa manter exceções para registro com fluxos separados de registros que exigem redação. Você pode até mesmo ter uma equipe de operações de nuvem local e dedicada para cada MALZ, o que limita o acesso da operadora à residência local.
Muitas organizações têm implantações separadas de landing zone baseadas nos EUA e na UE. Cada landing zone 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 dados dedicados HSMs pode não ser necessária em cargas de trabalho em um MALZ, mas pode ser necessária em outro MALZ.
Embora essa estratégia possa ser dimensionada para atender a muitos requisitos atuais e futuros, é importante compreender os custos adicionais e a sobrecarga operacional associados à manutenção de vários 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.
AWS Nuvem soberana europeia
Algumas organizações exigem uma separação completa de suas cargas de trabalho que operam no Espaço Econômico Europeu (EEA) e cargas de trabalho que operam em outros lugares. Nessa situação, considere a Nuvem Soberana AWS Europeia
A AWS European Sovereign Cloud é física e logicamente separada da existente Regiões da AWS, ao mesmo tempo em que oferece a mesma segurança, disponibilidade e desempenho. Somente AWS funcionários localizados na UE têm controle das operações e do suporte da Nuvem Soberana AWS Europeia. Se você tiver requisitos rigorosos de residência de dados, a AWS European Sovereign Cloud mantém todos os metadados que você cria (como as funções, permissões, rótulos de recursos e configurações que eles usam para executar) na UE. AWS A AWS European Sovereign Cloud também possui seus próprios sistemas de medição de faturamento e uso.
Para essa abordagem, você usaria 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 um MALZ dedicado na AWS European Sovereign Cloud.
