Modificar uma arquitetura de zona de aterrissagem do Azure para atender aos requisitos em vários locais

As organizações em muitos setores estão sujeitas a requisitos regulamentares, incluindo requisitos de residência de dados, segurança de dados e soberania de dados. Algumas organizações precisam estar em conformidade com regulamentações conflitantes em vários locais geográficos. Nesse caso, eles precisam modificar sua arquitetura de zona de aterrissagem do Azure de acordo com todos os regulamentos aplicáveis.

Por exemplo, pode haver dois regulamentos conflitantes, o Regulamento A e o Regulamento B. O Regulamento A pode exigir residência de dados no país ou região A, e o Regulamento B pode exigir residência de dados no país ou região B.

Esses conflitos regulamentares podem aplicar-se:

• Organizações multinacionais, como corporações multinacionais ou organizações não governamentais (ONGs), que devem cumprir as regulamentações locais nos países ou regiões em que operam.

• Fornecedores independentes de software (ISVs) que fornecem soluções para organizações em vários locais, e a solução deve estar em conformidade com as regulamentações locais em cada local.

• ISVs que fornecem soluções para organizações multinacionais que precisam estar em conformidade com as regulamentações locais de cada país ou região em que operam.

Se você só precisa atender a um único conjunto de requisitos regulatórios, consulte Personalizar a arquitetura da zona de aterrissagem do Azure para atender aos requisitos.

Considerações regulamentares

Os requisitos regulamentares estão normalmente relacionados com proteção de dados, residência de dados, transferências de dados, isolamento ou autorização de pessoal. Esses requisitos podem entrar em conflito entre várias localizações geográficas. Por exemplo, um regulamento da União Europeia (UE) pode exigir residência de dados em um país da UE, enquanto um regulamento do Reino Unido pode exigir residência de dados no Reino Unido.

Se os regulamentos levarem a controles de política conflitantes, você deverá ajustar a arquitetura da zona de aterrissagem do Azure e as atribuições de política de acordo. Para obter mais informações, consulte a seção deste artigo, Cenários que exigem modificação.

Quando vários regulamentos se aplicam, você não precisa modificar a arquitetura da zona de aterrissagem do Azure se:

• Vários regulamentos exigem atribuições idênticas da Política do Azure.

• Os controlos de um regulamento são um superconjunto de outro regulamento. Os controlos de superconjunto aplicam-se automaticamente a ambos os regulamentos.

• Os controles em vários regulamentos não se sobrepõem. Quando você implementa vários conjuntos de controle, uma única implementação abrange todos os regulamentos. As atribuições de Política do Azure são complementares.

• Vários regulamentos têm diferentes tipos de implementação. Do ponto de vista regulatório, não importa qual implementação você escolher. Por exemplo, pode haver dois regulamentos que têm cada um um modelo de autorização diferente, mas ambos os modelos de autorização são aceitáveis. Você pode escolher a implementação que melhor se adapta à sua organização.

Gorjeta

Você deve se esforçar para ter o menor número possível de atribuições de políticas e exceções ou isenções.

Considerações para ISVs

Existem três modelos de implantação para ISVs.

• Software como serviço (SaaS) puro: O ISV fornece a solução como um serviço.

• Cliente implantado: o cliente implanta a solução em seu próprio ambiente.

• SaaS de implantação dupla: este modelo combina o modelo implantado pelo cliente e o modelo SaaS puro.

Em um modelo SaaS puro, o ISV é responsável por gerenciar a conformidade em nome do cliente. O ISV deve demonstrar conformidade ao cliente e, potencialmente, aos auditores ou reguladores. Se você usar o modelo SaaS, sua arquitetura poderá estar sujeita a várias regulamentações que podem entrar em conflito. O ISV deve gerir a conformidade com estes vários regulamentos. Para obter mais informações, consulte a seção deste artigo, Cenários que exigem modificação.

Em um modelo implantado pelo cliente, o cliente é responsável por gerenciar a conformidade. Para este modelo, o ISV não precisa modificar as zonas de pouso. No entanto, a solução é implantada em uma zona de aterrissagem que o cliente implanta, incluindo quaisquer controles de política e políticas personalizadas.

Gorjeta

Os ISVs podem direcionar iniciativas políticas para requisitos de conformidade específicos para testar uma solução. Essa prática pode ajudar a minimizar a chance de conflitos com as políticas que os clientes usam para atender aos requisitos de conformidade.

Em um modelo SaaS de implantação dupla, todas as considerações para o modelo SaaS puro e implantado pelo cliente se aplicam.

Considerações para organizações multinacionais

As organizações multinacionais usam várias estruturas para organizar sua governança de TI.

• Estrutura descentralizada: as funções de TI são governadas localmente em cada localização geográfica.

• Estrutura centralizada: as funções de TI são governadas a partir de um local centralizado, normalmente a sede da organização.

• Estrutura híbrida: as funções de TI globais são fornecidas centralmente, enquanto as funções de TI necessárias apenas localmente são controladas em cada localização geográfica.

Em um cenário descentralizado , a equipe de TI local é responsável por gerenciar a conformidade e pode adaptar sua zona de destino de acordo.

Em um cenário centralizado , a equipe central de TI é responsável por gerenciar a conformidade e deve garantir que as soluções atendam aos requisitos de conformidade locais de todas as localizações geográficas onde a organização multinacional opera. Os requisitos de conformidade de várias localizações geográficas podem entrar em conflito e pode ser necessário modificar as zonas de desembarque.

Em um cenário híbrido , as considerações para os cenários descentralizado e centralizado se aplicam. A organização centralizada fornece soluções que as organizações locais precisam implantar em seu ambiente. A organização centralizada também testa que essas soluções são implantadas em todas as zonas de desembarque das organizações locais.

Cenários que requerem modificação

Talvez seja necessário modificar as zonas de aterrissagem se houver conjuntos de políticas conflitantes atribuídos a várias implantações. Pode haver várias soluções ou uma única solução que precise ser disponibilizada para vários locais geográficos ou classificações de dados.

A quantidade de modificação necessária depende do nível de isolamento exigido pelo regulamento. Quanto mais condições um regulamento tiver, mais a zona de desembarque terá de ser modificada. Por exemplo, se os regulamentos exigirem condições como pessoal liberado, vários provedores de identidade ou diretórios, infraestrutura de gerenciamento separada ou infraestrutura de conectividade separada, a zona de pouso exigirá modificações extensas. Se os regulamentos exigirem apenas que a infraestrutura de aplicativos e conectividade seja isolada, a zona de pouso precisará de modificações mínimas.

Locatários do Microsoft Entra

Recomendamos o uso de um único locatário do Microsoft Entra para a maioria dos cenários, incluindo cenários multinacionais. No entanto, há cenários em que você pode preferir ou exigir vários locatários do Microsoft Entra, como:

• Se você precisar separar o locatário corporativo do Microsoft Entra do locatário SaaS do Microsoft Entra para melhorar a segurança e criar limites claros entre o produto e as operações comerciais.

• Se forem aplicadas regulamentações conflitantes e você precisar de locatários separados do Microsoft Entra para regimes regulatórios diferentes. Por exemplo, os regulamentos podem ter requisitos de autorização e nacionalidade que precisam de isolamento completo entre locatários do Microsoft Entra ou requisitos de residência de dados que exigem locatários separados. Os cenários comuns incluem um ISV que precisa implantar instâncias isoladas de uma solução SaaS ou uma organização multinacional que precisa implantar instâncias isoladas da mesma solução.

Ao colaborar entre vários locatários do Microsoft Entra, você precisa planejar cuidadosamente os desafios e necessidades significativos. Crie apenas o número mínimo de locatários do Microsoft Entra necessários para atender aos requisitos operacionais ou regulamentares. Você pode usar grupos de gerenciamento e RBAC (controle de acesso baseado em função) do Azure para controlar o acesso a assinaturas e recursos em um único locatário, conforme descrito na próxima seção.

Gorjeta

O locatário do Microsoft Entra selecionado para sua zona de aterrissagem não afeta sua autenticação no nível do aplicativo. Você ainda pode usar outros provedores de identidade, independentemente do locatário escolhido. Para clientes do setor público e clientes em setores regulamentados, as identidades de usuário final geralmente são fornecidas quando você se integra a um provedor de identidade aprovado, como um provedor de identidade de propriedade do governo ou certificado.

Os diagramas a seguir mostram opções que você pode usar para organizar locatários do Microsoft Entra.

Gorjeta

Se você tiver vários locatários do Microsoft Entra para atender aos requisitos regulamentares, nomeie os locatários com base na localização geográfica em vez de regulamentos específicos, por exemplo, contoso-ops-us.com no diagrama de exemplo.

Para obter mais informações, consulte Zonas de aterrissagem do Azure e vários locatários do Microsoft Entra e considerações sobre ISV para zonas de aterrissagem do Azure.

Grupos de gestão

Se você não precisar de locatários separados do Microsoft Entra para fornecer isolamento estrito, deverá implantar várias zonas de aterrissagem do Azure em um único locatário do Microsoft Entra. Você pode ajustar a hierarquia do grupo de gerenciamento para atender aos requisitos de regulamentos conflitantes.

Você pode implantar uma arquitetura de zona de pouso completa para cada conjunto de regulamentos que deseja separar. Esse modelo requer a menor quantidade de personalização e permite que você aproveite a automação existente para implantação.

Nota

Este diagrama não mostra todos os grupos de gerenciamento.

Partilhar o grupo de gestão da plataforma

Se a regulamentação permitir, o grupo de gestão da plataforma pode ser partilhado. Você pode criar grupos de gerenciamento separados no grupo de gerenciamento da zona de aterrissagem para cada conjunto de regulamentos que precisam ser separados. Você pode atribuir as políticas apropriadas a cada um dos grupos de gerenciamento de aplicativos. As zonas de aterrissagem do aplicativo compartilham os grupos de gerenciamento que estão sob o grupo de gerenciamento da plataforma. Os recursos nos grupos de gerenciamento de aplicativos também podem ser separados por assinatura ou grupo de recursos.

Essa hierarquia de grupo de gerenciamento é um design simples e econômico para isolar aplicativos com regulamentações conflitantes. No entanto, nesse design, os grupos de gerenciamento de plataforma para conectividade, identidade/segurança e gerenciamento devem compartilhar o mesmo conjunto de políticas. Você pode precisar de conjuntos de políticas diferentes para cada grupo de gerenciamento de plataforma se a regulamentação impuser restrições ao compartilhamento de infraestrutura de conectividade, serviços de identidade, serviços de gerenciamento de chaves ou a infraestrutura a partir da qual todo o ambiente é gerenciado.

Isolar identidade e segurança

Se as regulamentações impedirem que você compartilhe a identidade e a infraestrutura de gerenciamento de chaves, você poderá dividir o grupo de gerenciamento da plataforma. Mantenha os grupos de gerenciamento para conectividade e gerenciamento no grupo de gerenciamento de plataforma compartilhada e tenha um grupo de gerenciamento de identidade e segurança associado a cada conjunto de regulamentos.

Essa hierarquia de grupo de gerenciamento é significativamente mais complexa do que um grupo de gerenciamento de plataforma totalmente compartilhado porque você precisa replicar parcialmente o grupo de gerenciamento de plataforma. Para limitar a complexidade, você pode implantar a hierarquia completa para cada um dos conjuntos de regulamentos e o ambiente compartilhado e ignorar ou excluir os grupos de gerenciamento supérfluos.

Isolar a conectividade

Muitas regulamentações têm requisitos relacionados ao processamento e armazenamento de dados em um determinado local geográfico, com poucos requisitos sobre como os usuários se conectam aos aplicativos. Para esses regulamentos, você pode compartilhar o gerenciamento de conectividade conforme mostrado na arquitetura anterior. Pode não haver nenhuma regulamentação que exija a duplicação da infraestrutura em várias regiões, mas talvez seja necessário fazê-lo para fins de latência. As políticas atribuídas devem suportar a duplicação de infraestruturas em várias regiões.

Quando as regulamentações têm requisitos de conectividade conflitantes, você pode criar um grupo de gerenciamento de conectividade associado a cada conjunto de regulamentações. Essa estrutura é semelhante à arquitetura anterior que associa grupos de gerenciamento de identidade e segurança a cada conjunto de regulamentos.

Se as regulamentações entrarem em conflito para conectividade e também identidade e segurança, você pode usar o design a seguir.

Próximos passos

• Zonas de aterrissagem do Azure e vários locatários do Microsoft Entra
• Considerações de ISV para zonas de aterrissagem do Azure
• Microsoft Cloud Adoption Framework para o Azure
• ID do Microsoft Entra e residência de dados
• Descrição geral do pilar de segurança
• Recomendações para gerenciamento de identidade e acesso
• Personalize a arquitetura da zona de aterrissagem do Azure para atender aos requisitos