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 normativos, incluindo residência de dados, segurança de dados e requisitos de 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.

Tais conflitos regulamentares podem aplicar-se a:

• 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 normativos, consulte Personalizar a arquitetura da zona de aterrissagem do Azure para atender aos requisitos.

Considerações regulatórias

Os requisitos normativos geralmente estão relacionados à proteção de dados, residência de dados, transferências de dados, isolamento ou liberaçã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 controles de superconjunto se aplicam 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 todas as regulamentações. As atribuições da 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 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.

Considerações para ISVs

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

• Software puro como serviço (SaaS): 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: esse 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 gerenciar a conformidade para esses 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.

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 utilizam 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 globais de TI 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 aterrissagem de acordo.

Em um cenário centralizado , a equipe central de TI é responsável pelo gerenciamento da 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 pouso.

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 se essas soluções são implantadas em todas as zonas de aterrissagem das organizações locais.

Cenários que exigem 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 precisa ser disponibilizada para vários locais geográficos ou classificações de dados.

A quantidade de modificações necessárias depende do nível de isolamento que o regulamento exige. Quanto mais condições um regulamento tiver, mais a zona de desembarque precisa 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á uma modificação extensa. 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. 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 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 normativos. Você pode usar grupos de gerenciamento e o 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.

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

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 gerenciamento

Se você não precisar de locatários separados do Microsoft Entra para fornecer isolamento estrito, implante 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 regulamentações conflitantes.

Você pode implantar uma arquitetura de zona de aterrissagem 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.

Compartilhar o grupo de gerenciamento de plataforma

Se a regulamentação permitir, o grupo de gerenciamento da plataforma pode ser compartilhado. Você pode criar grupos de gerenciamento separados no grupo de gerenciamento de 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. Talvez você precise de conjuntos de políticas diferentes para cada grupo de gerenciamento de plataforma se a regulamentação impor 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 o compartilhamento da infraestrutura de gerenciamento de identidade e chave, 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 compartilhada 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

Muitos regulamentos têm requisitos relacionados ao processamento e armazenamento de dados em uma determinada localização geográfica, 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. Talvez não haja nenhuma regulamentação que exija que você duplique a infraestrutura em várias regiões, mas talvez seja necessário para fins de latência. As políticas atribuídas precisam oferecer suporte à duplicação de infraestrutura 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 regulamentos. 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ê poderá usar o design a seguir.

Próximas etapas

• Zonas de aterrissagem do Azure e vários locatários do Microsoft Entra
• Considerações sobre ISV para zonas de aterrissagem do Azure
• Microsoft Cloud Adoption Framework para o Azure
• Microsoft Entra ID e residência de dados
• Visã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