Avaliar os requisitos soberanos

  • Artigo

A Microsoft Cloud Adoption Framework para o Azure é uma estrutura de ciclo de vida completo que ajuda arquitetos de nuvem, profissionais de TI e tomadores de decisão de negócios a atingirem suas metas de adoção de nuvem. Ele fornece práticas recomendadas, documentação e ferramentas que ajudam a criar e implementar estratégias de negócios e tecnologia para a nuvem. 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 planejamento, para que as decisões estratégicas sobre a adoção da nuvem estejam alinhadas com esses requisitos de soberania.

Este artigo destaca áreas onde as organizações podem querer avaliar, identificar e documentar os seus requisitos de soberania, e fornece recomendações sobre onde estes requisitos podem caber nos seus esforços de planejamento mais amplos associados ao Cloud Adoption Framework para Azure.

Identificar dados de soberania

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

As organizações que seguem o Cloud Adoption Framework para o Azure identificam cargas de trabalho candidatas a migrar para a nuvem durante a fase de planejamento 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 nuvem do estado de destino.

A Microsoft usa muitos tipos de dados, como informações pessoais fornecidas à Microsoft e dados de clientes que são carregados em serviços de nuvem para fornecer serviços online e profissionais. As responsabilidades de proteção de dados da Microsoft estão documentadas no Adendo 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. O DPA especifica os diferentes tipos de dados que a Microsoft gerencia e descreve as práticas usadas pela Microsoft para proteger esses tipos de dados.

Muitas organizações têm programas de governança de dados existentes que especificam requisitos para o tratamento de dados confidenciais e podem usar essas 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 seus dados em um serviço de nuvem, é sua responsabilidade classificar, rotular e gerenciar com precisão os dados de acordo com seus requisitos de tratamento de dados. Algumas organizações podem querer usar a adoção da nuvem 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 nuvem, consulte Classificação de dados no Azure e Guias de governança da nuvem.

Exemplos de requisitos de soberania de dados

As organizações que têm requisitos rigorosos de soberania de dados talvez precisem planejas alguns dos seguintes cenários representativos quando migrarem cargas de trabalho para a nuvem.

Rotulagem de classificação de dados

Os rótulos de classificação identificam recursos com requisitos especiais de manipulação. Embora os rótulos de classificação sejam aplicados a documentos, eles também podem ser aplicados a ativos. Os clientes podem utilizar os recursos de marcação nativas no Azure para aplicar rótulos de classificação a recursos como serviços de computação e armazenamento de dados e para estruturas lógicas no Azure, como assinaturas e grupos de gerenciamento.

Para obter mais informações, consulte Marcação no Azure e Descoberta Eletrônica do Microsoft Purview.

Limites de classificação de dados

Quando uma organização opta por agregar dados (ou aplicativos) de classificação semelhante, um perímetro de segurança é frequentemente implantado para servir como limite do local onde o armazenamento de dados é permitido. Quando os clientes implementam cargas de trabalho no Azure, podem utilizar assinaturas e grupos de gerenciamento para criar limites lógicos dentro do ambiente de nuvem da organização. Esses limites ajudam a mitigar os riscos de confidencialidade relacionados ao acesso não autorizado e aos riscos de privacidade relacionados à agregação e atribuição de dados.

As organizações que têm requisitos rigorosos de soberania de dados talvez queiram considerar se querem organizar o seu ambiente em um modelo hierárquico, onde níveis mais elevados de privilégios herdam níveis mais baixos de privilégios (por exemplo, como no modelo Bell-LaPadula), ou se preferem implementar um modelo não hierárquico onde controles de acesso obrigatórios são usados para criar limites que compartimentam partes do ambiente do resto do ambiente. As decisões sobre como uma organização gerencia 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 mais informações, consulte Grupos de Gerenciamento no Azure e Governança de Dados.

Residência de dados

As organizações que devem cumprir os requisitos de residência de dados devem prestar especial atenção aos serviços do Azure de que necessitam para suportar uma carga de trabalho e onde esses serviços estão geograficamente disponíveis. Os serviços do Azure são implantados em regiões que oferecem suporte a conexões de rede de baixa latência e recursos como zonas de disponibilidade. Essas regiões são agrupadas em regiões geográficas, o que fornece resiliência extra e recursos de recuperação de desastres.

Se uma organização precisa manter a residência de 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 implantados globalmente e não oferecem residência de dados dentro de uma determinada região ou geografia para os dados armazenados nesse serviço.

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

Propriedade, custódia e portabilidade de dados

Os clientes com requisitos rigorosos de soberania de dados têm muitas vezes muitas dúvidas sobre quem retém a propriedade dos dados armazenados no Azure, quem pode acessar esses dados e o que acontece com esses dados, se um cliente optar por mover a sua carga de trabalho para outra plataforma. Esses requisitos podem variar em escopo e especificidade, mas geralmente tendem a estar relacionados à questão fundamental do que acontece com os dados quando você os hospeda em um Microsoft cloud service.

Para ajudar a resolver essas questões em alto nível e fornecer aos clientes um ponto de partida para identificar seus requisitos de soberania de dados que se aplicam aos provedores de serviços de nuvem, a Microsoft publicou uma série de artigos sobre proteção e gerenciamento de dados de clientes que abordam muitas dessas questões, e aquelas os artigos estão disponíveis online na Central de Confiabilidade.

Para obter mais informações, consulte Gerenciamento de Dados na Microsoft.

Mantenha a soberania operacional na nuvem

Os requisitos de soberania operacional podem afetar a forma como um ambiente no Azure é projetado, atualizado e gerenciado. Por isso, é importante ter uma compreensão clara destes requisitos antes de os projetos técnicos serem finalizados 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 controle de acesso que limitam o acesso privilegiado por provedores de serviços de nuvem.
  • Orientações para alta disponibilidade e recuperação de desastres.

É importante compreender claramente a intenção e os riscos que esses requisitos atenuam, uma vez que muitos desses requisitos são atendidos na nuvem usando métodos diferentes dos comumente usados local.

Depois que a organização identificar os requisitos de soberania operacional, pode selecionar os controles de soberania técnicos e administrativos apropriados para fornecer o nível certo de mitigação e garantia de riscos. Ao selecionar controles de soberania, é importante compreender que a seleção de alguns recursos que podem fornecer soberania operacional extra limita as opções de uma organização para adotar 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 Contêineres 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 devem cumprir o conjunto mais restritivo de requisitos de soberania.

Além disso, alguns requisitos de soberania operacional, como o Autarky (por exemplo, podem funcionar independentemente de redes e sistemas externos) são inviáveis em plataformas de computação em nuvem de hiperescala como o Azure, que dependem de atualizações regulares da plataforma para manter os sistemas em um estado ideal.

Exemplos de requisitos de soberania operacional

Alguns requisitos comuns de soberania operacional, juntamente com exemplos de serviços e recursos relevantes do Azure que podem atender a esses requisitos, são os seguintes:

Segurança do software

Os requisitos de segurança de software podem incluir atividades de desenvolvimento, como aplicação de proteções criptográficas específicas, realização de revisões de código e realização de testes de penetração e segurança de aplicativos. Também pode incluir processos operacionais, como a implementação de controles de acesso, uso de tecnologias de criptografia e monitoramento de eventos de segurança.

A Microsoft fornece vários recursos para ajudar os clientes a atender 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 de nível de plataforma para 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 recursos 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 Ciclo de vida de desenvolvimento seguro da Microsoft e Melhores práticas de desenvolvimento seguro no Azure.

Segurança da infraestrutura

As cargas de trabalho executadas no Azure podem aproveitar os vários recursos que a Microsoft desenvolveu para garantir a integridade da plataforma. Os recursos incluem firmware, software e infraestrutura de host. As organizações podem ter requisitos de soberania operacional para isolar os seus dados dos operadores de nuvem. O Azure fornece capacidades que os clientes podem utilizar para se beneficiar da agilidade e resiliência da nuvem pública, mantendo ao mesmo tempo o isolamento dos provedores de serviços de nuvem e do seu pessoal administrativo. As organizações com requisitos relacionados ao atestado em nível de hardware, verificação de integridade de software (por exemplo, inicialização segura) e gerenciamento seguro de chaves podem revisar a integridade da plataforma da Microsoft e as práticas de segurança e acessar a documentação de auditoria para validar a implementação desses recursos.

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

A criptografia para dados em repouso, dados em trânsito e dados em uso pode ajudar a satisfazer uma ampla gama de requisitos de soberania operacional relacionados à confidencialidade e privacidade dos dados. No entanto, as organizações que necessitam destes recursos precisam planejar a criação e o gerenciamento de chaves de criptografia. O Azure fornece uma ampla variedade de modelos de criptografia de dados em repouso para os clientes escolherem, desde métodos de criptografia do lado do cliente que fornecem criptografia de conhecimento zero para dados hospedados na nuvem até chaves gerenciadas por serviço que oferecem o mais alto grau de interoperabilidade com serviços de nuvem nativos.

Além disso, as organizações que desejam minimizar a necessidade de confiança nos componentes da plataforma, como o sistema operacional host, o kernel, o hipervisor e a equipe administrativa, podem implementar a criptografia de dados em uso. A Computação Confidencial do Azure inclui vários serviços de computação implantados em enclaves de segurança com base em hardware que criptografam dados na memória usando o Intel Software Guard Extensions (SGX) ou o AMD Secure Encrypted Virtualization (SEV-SNP).

As organizações com requisitos de soberania operacional que exigem a implementação de criptografia devem familiarizar-se com as seguintes funcionalidades de criptografia 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 gerenciado pela Microsoft para operar a plataforma Azure como ao software gerenciado pelo cliente que faz parte de uma carga de trabalho. O modelo de responsabilidade compartilhada para a computação em nuvem transfere a responsabilidade administrativa do cliente para o provedor de serviços de nuvem. Dependendo do tipo de serviço de nuvem que está sendo consumido, a Microsoft poderá ser responsável por gerenciar e atualizar a infraestrutura bare-metal em nossos datacenters, sistemas operacionais e tempos de execução de 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 Microsoft Secure Development Lifecycle (SDL) com práticas de segurança operacional. As práticas incluem gerenciamento de segredos, testes de penetração e monitoramento de segurança, implementados pelo Microsoft Security Response Center.

Em casos raros, a Microsoft poderá exigir acesso aos dados do cliente para solucionar um problema que possa afetar os serviços. Os clientes com requisitos de soberania operacional relacionados com o controle de alterações e a gerenciamento de acesso privilegiado podem querer ativar o Sistema de Proteção de Dados do Cliente para Azure para que possam aprovar as solicitações 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 Hosts Dedicado do Azure, que permitem aos clientes utilizar Configurações de Manutenção para controlar as atividades de manutenção da plataforma ao nível do host. 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 hospedar cargas de trabalho.

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

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