Partilhar via

Avaliar os requisitos de soberania

  • Artigo

O Microsoft Cloud Adoption Framework para o Azure é uma estrutura de ciclo de vida completo que ajuda que arquitetos de cloud, profissionais de TI e decisores de negócios atinjam as suas metas de adoção de cloud. Fornece as melhores práticas, documentação e ferramentas que ajudam a criar e implementar estratégias de negócios e tecnologia para a cloud. As organizações do setor público que têm requisitos rigorosos de soberania podem incorporar os seus objetivos de soberania nos seus esforços de planeamento, para que as decisões estratégicas sobre a adoção da cloud estejam alinhadas com estes requisitos de soberania.

Este artigo realça as áreas onde as organizações podem querer avaliar, identificar e documentar os seus requisitos de soberania e fornece recomendações sobre onde estes requisitos se podem encaixar em esforços de planeamento mais amplos associados ao Cloud Adoption Framework para o Azure.

Identificar dados soberanos

Os requisitos de soberania de dados podem incluir mandatos para reter a propriedade dos dados e especificar métodos para o armazenamento, a utilização e a transmissão de dados. Às vezes, os requisitos de soberania dos dados também podem incluir limitações ou mandatos relativos à residência dos dados. Compreender estes requisitos no início do percurso de uma organização para a cloud pode ajudar a estabelecer padrões de conceção comuns para a soberania dos dados, em vez de se esperar que os proprietários das cargas de trabalho desenvolvam soluções para cumprir os requisitos de soberania.

As organizações que seguem o Cloud Adoption Framework para o Azure identificam cargas de trabalho candidatas a migrar para a cloud durante a fase de planeamento e, em seguida, concebem o ambiente para acolher estas cargas de trabalho durante a fase de preparação. Estas atividades podem permitir que uma organização identifique tipos de dados soberanos que requerem tratamento especial no ambiente de cloud do estado de destino.

A Microsoft utiliza muitos tipos de dados, como informações pessoais fornecidas à Microsoft e dados de clientes que são carregados em serviços de cloud para fornecer serviços online e profissionais. As responsabilidades de proteção de dados da Microsoft estão documentadas na Adenda de Proteções de Dados (DPA) de Produtos e Serviços da Microsoft e incluídas nos contratos de uma organização com a Microsoft. A DPA especifica os diferentes tipos de dados que a Microsoft gere e descreve as práticas utilizadas pela Microsoft para os proteger.

Muitas organizações têm programas de governação de dados existentes que especificam requisitos para o processamento de dados confidenciais e podem utilizar estas informações para determinar se os requisitos de soberania de dados se aplicam a todas ou apenas a um subconjunto de classificações de dados. Quando uma organização carrega e mantém os seus dados num serviço de cloud, é sua responsabilidade classificar, etiquetar e gerir com precisão os dados de acordo com os seus requisitos de processamento de dados. Algumas organizações podem querer utilizar a adoção da cloud como uma oportunidade para rever os seus programas de classificação de dados.

Para obter mais informações sobre como a classificação de dados se aplica à adoção da cloud, consulte Classificação de dados no Azure e Guias de governação na cloud.

Exemplos de requisitos de soberania de dados

As organizações que têm requisitos rigorosos de soberania de dados podem ter de planear alguns dos seguintes cenários representativos quando migrarem cargas de trabalho para a cloud.

Etiquetagem de classificação de dados

Os etiquetas de classificação identificam recursos com requisitos especiais de processamento. Embora as etiquetas de classificação sejam aplicadas a documentos, também podem ser aplicados a ativos. Os clientes podem utilizar as funcionalidades de etiquetagem nativas do Azure para aplicar etiquetas de classificação a recursos como serviços de computação e arquivos de dados e para estruturas lógicas no Azure, como subscrições e grupos de gestão.

Para obter mais informações, consulte Etiquetagem no Azure e Soluções de Deteção de Dados Eletrónicos do Microsoft Purview.

Limites de classificação de dados

Quando uma organização opta por agregar dados (ou aplicações) de classificação semelhante, é frequentemente implementado um perímetro de segurança para servir como limite da localização onde o armazenamento de dados é permitido. Quando os clientes implementam cargas de trabalho no Azure, podem utilizar subscrições e grupos de gestão para criar limites lógicos dentro do ambiente de cloud da organização. Estes limites ajudam a mitigar os riscos de confidencialidade relacionados com o acesso não autorizado e aos riscos de privacidade relacionados com a agregação e a atribuição de dados.

As organizações que têm requisitos rigorosos de soberania de dados podem querer considerar se desejam organizar o seu ambiente num modelo hierárquico, onde níveis superiores de privilégios herdam níveis inferiores de privilégios (por exemplo, como no modelo Bell-LaPadula), ou se preferem implementar um modelo não hierárquico onde controlos de acesso obrigatórios são utilizados para criar limites que compartimentam partes do ambiente do resto do ambiente. As decisões sobre como uma organização gere os limites de classificação de dados são cruciais ao conceber Zonas de Destino na fase de preparação do Cloud Adoption Framework para o Azure.

Para obter mais informações, consulte Grupos de Gestão no Azure e Governação de dados.

Residência dos dados

As organizações que têm de cumprir os requisitos de residência dos dados devem prestar especial atenção aos serviços do Azure de que necessitam para o suporte de uma carga de trabalho e onde estes serviços estão geograficamente disponíveis. Os serviços do Azure são implementados em regiões que suportam ligações de rede de baixa latência e funcionalidades como zonas de disponibilidade. Estas regiões são agrupadas em regiões geográficas, o que fornece funcionalidades adicionais de resiliência e recuperação após desastre.

Se uma organização precisar de manter a residência dos dados para a sua carga de trabalho, terá de garantir que os serviços do Azure utilizados estão disponíveis na sua região e geografia preferidas. Além disso, alguns serviços são implementados globalmente e não oferecem a residência dos dados dentro de uma determinada região ou geografia para os dados armazenados neste serviço.

Para obter mais informações sobre Residência dos Dados, regiões e zonas de disponibilidade do Azure, bem como disponibilidade regional dos serviços do Azure, consulte os seguintes artigos:

Propriedade, custódia e portabilidade dos dados

Os clientes com requisitos rigorosos de soberania de dados frequentemente têm muitas dúvidas sobre quem retém a propriedade dos dados armazenados no Azure, quem pode aceder a estes dados e o que acontece com estes dados se um cliente optar por mover a sua carga de trabalho para outra plataforma. Estes requisitos podem variar em termos de âmbito e especificidade, mas geralmente tendem a estar relacionados com a questão fundamental do que acontece com os dados quando os aloja num Microsoft Cloud Service.

Para ajudar a resolver estas questões a um nível elevado e fornecer aos clientes um ponto de partida para identificar os seus requisitos de soberania de dados que se aplicam aos fornecedores de serviços de cloud, a Microsoft publicou uma série de artigos sobre a proteção e gestão de dados de clientes que abordam muitas destas questões, e esses artigos estão disponíveis online no Centro de Confiança.

Para obter mais informações, consulte Gestão de dados na Microsoft.

Manter a soberania operacional na cloud

Os requisitos de soberania operacional podem afetar a forma como um ambiente no Azure é concebido, atualizado e gerido. Por isso, é importante ter uma compreensão clara destes requisitos antes de as conceções técnicas serem finalizadas como parte da fase de preparação do Cloud Adoption Framework para o Azure. Os requisitos comuns de soberania operacional podem incluir:

  • Limitações quanto à localização e nacionalidade do pessoal administrativo.
  • Requisitos de controlo de acesso que limitam o acesso privilegiado por fornecedores de serviços de cloud.
  • Mandatos para elevada disponibilidade e recuperação após desastre.

É importante compreender claramente a intenção e os riscos que estes requisitos atenuam, uma vez que muitos destes requisitos são atendidos na cloud utilizando métodos diferentes dos habitualmente utilizados no local.

Depois de a organização identificar os requisitos de soberania operacional, pode selecionar os controlos de soberania técnicos e administrativos apropriados para fornecer o nível certo de mitigação e garantia de riscos. Ao selecionar controlos de soberania, é importante compreender que a seleção de algumas capacidades que podem fornecer soberania operacional adicional limita as opções de uma organização para a adoção de outros serviços do Azure.

Por exemplo, uma organização que requer computação confidencial para as suas cargas de trabalho do Azure tem de limitar as suas opções de arquitetura a serviços que podem ser executados na Computação Confidencial do Azure, como Máquinas Virtuais Confidenciais ou Contentores Confidenciais. Por esta razão, muitas vezes é uma boa ideia associar os requisitos de soberania operacional a uma determinada classificação de dados, em vez de adotar uma abordagem onde todas as cargas de trabalho e dados têm de cumprir o conjunto mais restritivo de requisitos de soberania.

Além disso, alguns requisitos de soberania operacional, como o Autarky (por exemplo, ser capaz de funcionar independentemente das redes e sistemas externos) não são viáveis em plataformas de computação na cloud em hiperescala como o Azure, que dependem de atualizações regulares da plataforma para manter os sistemas num estado ideal.

Exemplos de requisitos de soberania operacional

Alguns requisitos comuns de soberania operacional, juntamente com exemplos de serviços e capacidades relevantes do Azure que podem cumprir estes requisitos, são os seguintes:

Segurança do software

Os requisitos de segurança do software podem incluir atividades de desenvolvimento, como aplicação de salvaguardas criptográficas específicas, realização de revisões de código e realização de testes de penetração e segurança de aplicações. Também pode incluir processos operacionais, como a implementação de controlos de acesso, a utilização de tecnologias de encriptação e a monitorização de eventos de segurança.

A Microsoft fornece várias capacidades para ajudar os clientes a cumprir aos requisitos de soberania operacional para software desenvolvido pela Microsoft e pelo cliente. A Microsoft segue o Ciclo de Vida de Desenvolvimento Seguro (SDL) ao desenvolver software ao nível da plataforma para o Azure. As 12 práticas do SDL são incorporadas aos processos e procedimentos de engenharia da Microsoft e são avaliadas regularmente como parte das atividades de garantia da Microsoft. Além disso, a Microsoft fornece capacidades para ajudar os clientes a adotarem as práticas do Ciclo de Vida de Desenvolvimento Seguro como parte do ciclo de vida de desenvolvimento de software.

Para obter mais informações, consulte o Ciclo de Vida de Desenvolvimento Seguro da Microsoft e Melhores Práticas de Desenvolvimento Seguro no Azure.

Segurança de infraestrutura

As cargas de trabalho executadas no Azure podem aproveitar as várias funcionalidades que a Microsoft desenvolveu para garantir a integridade da plataforma. As funcionalidades incluem o firmware, o software e a infraestrutura do anfitrião. As organizações podem ter requisitos de soberania operacional para isolar os seus dados dos operadores de cloud. O Azure fornece capacidades que os clientes podem utilizar para tirar partido da agilidade e resiliência da cloud pública, mantendo ao mesmo tempo o isolamento dos fornecedores de serviços de cloud e do seu pessoal administrativo. As organizações com requisitos relacionados com o atestado ao nível do hardware, verificação de integridade do software (por exemplo, arranque seguro) e gestão segura de chaves podem rever a integridade da plataforma da Microsoft e as práticas de segurança e aceder a documentação de auditoria para validar a implementação destas funcionalidades.

Para obter mais informações, consulte Integridade e segurança da plataforma e Segurança da infraestrutura do Azure.

A encriptação para dados em repouso, dados em trânsito e dados em utilização pode ajudar a satisfazer uma ampla gama de requisitos de soberania operacional relacionados com a confidencialidade e privacidade dos dados. No entanto, as organizações que necessitam destas funcionalidades precisam de planear a criação e a gestão de chaves de encriptação. O Azure fornece uma ampla variedade de modelos de encriptação de dados em repouso para os clientes escolherem, desde métodos de encriptação do lado do cliente que fornecem encriptação de conhecimento zero para dados alojados na cloud até chaves geridas por serviço que oferecem o mais alto grau de interoperabilidade com os serviços de cloud nativos.

Além disso, as organizações que desejam minimizar a necessidade de confiança nos componentes da plataforma, como o SO do anfitrião, o kernel, o hipervisor e o pessoal administrativo, podem implementar a encriptação de dados em utilização. A Computação Confidencial do Azure inclui vários serviços de computação implementados em enclaves de segurança baseados em hardware que encriptam dados na memória utilizando Intel Software Guard Extensions (SGX) ou AMD Secure Encrypted Virtualization (SEV-SNP).

As organizações com requisitos de soberania operacional que exigem a implementação de encriptação devem familiarizar-se com as seguintes funcionalidades de encriptação no Azure:

Operações e resiliência

Os requisitos de segurança operacional podem aplicar-se tanto ao software ao nível da plataforma criado e gerido pela Microsoft para operar a plataforma do Azure como ao software gerido pelo cliente que faz parte de uma carga de trabalho. O modelo de responsabilidade partilhada para a computação na cloud transfere a responsabilidade administrativa do cliente para o fornecedor de serviços de cloud. Dependendo do tipo de serviço de cloud que está a ser consumido, a Microsoft poderá ser responsável por gerir e atualizar a infraestrutura bare-metal nos nossos datacenters, sistemas operativos e runtimes do serviço. A organização de engenharia de segurança da Microsoft implementa um programa de segurança operacional que se baseia nas práticas do Ciclo de Vida de Desenvolvimento Seguro (SDL) da Microsoft com práticas de segurança operacional. As práticas incluem gestão de segredos, testes de penetração e monitorização de segurança, implementados pelo Centro de Resposta de Segurança da Microsoft.

Em casos raros, a Microsoft poderá exigir acesso aos dados do cliente para resolver um problema que possa afetar os serviços. Os clientes com requisitos de soberania operacional relacionados com o controlo de alterações e a gestão de acessos privilegiados podem querer ativar o Sistema de Proteção de Dados do Cliente para o Azure para que possam aprovar os pedidos de acesso como parte dos fluxos de trabalho de suporte da Microsoft.

Além disso, os clientes com requisitos rigorosos para aprovação e agendamento de atualizações de software da plataforma podem querer considerar os Azure Dedicated Hosts, que permitem aos clientes utilizar Configurações de Manutenção para controlar as atividades de manutenção da plataforma ao nível do anfitrião. Além disso, os clientes devem rever os seus requisitos de resiliência para determinar se existem limitações baseadas na soberania nos serviços e regiões que são utilizados para alojar as cargas de trabalho.

Os requisitos de soberania operacional em torno da continuidade das operações (por exemplo, exigir que as cargas de trabalho sejam implementadas em configurações altamente disponíveis para manter o tempo de atividade) podem entrar em conflito com os requisitos de soberania dos dados relacionados com a residência dos dados (por exemplo, restringir as cargas de trabalho a um limite geográfico que não oferece localizações diversificadas).

As organizações devem avaliar estes requisitos antecipadamente e considerar a melhor forma de os equilibrar.