Compartilhar via

Criptografia com chaves gerenciadas pelo cliente no Microsoft Cloud for Sovereignty

  • Artigo

Os clientes que planejam implementar o Microsoft Cloud for Sovereignty podem exigir o uso de recursos de criptografia de dados para atender os requisitos de soberania de dados. Os clientes com requisitos rigorosos de soberania de dados devem desenvolver planos para implementar o gerenciamento de chaves na nuvem. Este artigo orienta arquitetos de nuvem, proprietários de sistemas criptográficos e outros tomadores de decisões técnicas a desenvolver um plano para implementar a criptografia em nível de plataforma no Azure. O planejamento da criptografia no nível da plataforma geralmente envolve identificar requisitos de gerenciamento de chaves, fazer escolhas tecnológicas e selecionar designs e opções de configuração para os serviços do Azure a serem usados. Esse processo envolve a tomada de decisões técnicas em três domínios:

  • Defina os principais requisitos de gerenciamento: o que sua organização precisa fazer para proteger dados confidenciais de clientes e material criptográfico confidencial?
  • Selecione recursos de criptografia de dados para proteger os dados do cliente: como, onde e quando você deve criptografar dados do cliente no Azure?
  • Selecione soluções de gerenciamento de chaves para proteger as chaves dos clientes: qual armazenamento de chaves você deve usar para proteger as chaves de criptografia de dados usadas para criptografar dados dos clientes no Azure?

Definir os requisitos do gerenciamento de chaves

Os requisitos para o gerenciamento de chaves podem incluir requisitos técnicos sobre os serviços criptográficos usados e os requisitos operacionais relacionados ao desempenho, segurança e soberania. O ponto de partida recomendado para tomar decisões sobre quando e como criptografar dados em cargas de trabalho do Azure é o sistema de classificação de dados de uma organização. Ao alinhar os requisitos de criptografia com as classificações de dados, em vez de sistemas ou soluções específicas, as organizações têm mais flexibilidade para selecionar o nível ideal de criptografia durante o planejamento da migração de cargas de trabalho.

Basear os requisitos de criptografia na classificação de dados também permite uma abordagem em níveis, em que as cargas de trabalho com nível crítico menor podem aproveitar soluções mais simples, reservando as configurações mais complexas para as cargas de trabalho com um nível mais alto de risco inerente. Um exemplo desta abordagem seria permitir o uso de chaves gerenciadas pela Microsoft para criptografar contas de armazenamento para ambientes de desenvolvimento, exigindo ao mesmo tempo que as contas de armazenamento de produção usem chaves de criptografia gerenciadas pelo cliente.

Depois de uma organização compreender claramente como seus requisitos de criptografia se relacionam com suas classificações de dados, ela poderá iniciar o processo de seleção de recursos para os serviços do Azure que planeja consumir. Alguns desses recursos podem funcionar de forma diferente dos sistemas locais semelhantes, portanto, recomenda-se que as organizações se familiarizem com a forma como a criptografia funciona no Azure e a rever recomendações e melhores práticas para desenvolver soluções de criptografia. Os artigos a seguir fornecem perspectivas adicionais sobre algumas das escolhas técnicas que os clientes devem fazer e podem ser um ponto de partida útil para iniciar uma conversa sobre os objetivos do gerenciamento de chaves na nuvem de uma organização.

Selecionar recursos de criptografia de dados

Muitos serviços do Azure permitem a criptografia usando chaves que são geradas, armazenadas e gerenciadas inteiramente pelo Azure, sem qualquer interação com o cliente. Essas chaves gerenciadas pela plataforma podem ajudar as organizações a implementar a criptografia com pouca sobrecarga operacional. No entanto, os clientes com requisitos rigorosos de soberania de dados talvez precisem selecionar recursos específicos de criptografia da plataforma para proteger dados confidenciais enquanto estão em repouso em um determinado serviço do Azure.

Para dados altamente confidenciais, muitos serviços do Azure comumente usados permitem que os clientes implementem a criptografia dupla usando Chaves Gerenciadas pelo Cliente (CMK). A implementação de chaves gerenciadas pelo cliente nos serviços do Azure pode ajudar os clientes a proteger os dados armazenados nesses serviços contra o acesso não autorizado.

A implementação de chaves gerenciadas pelo cliente no Azure pode aumentar o custo e a complexidade de uma carga de trabalho, portanto, recomenda-se que as organizações avaliem a necessidade desse recurso para cada carga de trabalho e nível de classificação de dados. A implementação de chaves gerenciadas pelo cliente somente para as cargas de trabalho e tipos de dados que precisam delas pode ajudar a reduzir a sobrecarga operacional para cargas de trabalho que não lidam com dados confidenciais.

Se forem necessárias chaves gerenciadas pelo cliente, elas deverão ser configuradas para cada respectivo serviço do Azure. As organizações podem ajudar a simplificar os esforços de planejamento de implantação ou de migração estabelecendo padrões para toda a organização e padrões de design repetíveis para implementar esses recursos. Os artigos a seguir fornecem mais informações sobre como a criptografia de dados em repouso é configurada no Azure:

Saiba como configurar os serviços do Azure comumente usados para criptografar dados em repouso usando chaves gerenciadas pelo cliente:

Selecionar soluções de gerenciamento de chaves

Embora os recursos como a criptografia dupla com chaves gerenciadas pelo cliente possam ajudar a proteger os dados do cliente que são mantidos nos serviços do Azure, as soluções de gerenciamento de chaves baseadas em nuvem ajudam a proteger as chaves de criptografia e outros materiais criptográficos que são utilizados para criptografar dados confidenciais. Os clientes com requisitos rigorosos de soberania de dados devem selecionar uma solução de gerenciamento de chaves adequada com base nas suas necessidades de garantia e no perfil de risco das suas cargas de trabalho.

As cargas de trabalho que lidam com dados confidenciais podem se beneficiar da garantia adicional fornecida por soluções como o HSM gerenciado do Azure, incluindo módulos de segurança de hardware com validação FIPS-140-2 Nível 3 que apresentam controles de segurança extras para proteger o material criptográfico armazenado.

Os artigos a seguir fornecem orientações que os clientes podem usar para selecionar um armazenamento de chaves apropriado para seus cenários identificados. Eles também fornecem informações sobre como a Microsoft gerencia os serviços criptográficos usados pelos clientes como parte de sua solução de criptografia.

Modelos de operações para o gerenciamento de chaves

O Azure Key Vault implementa o controle de acesso baseado em função de maneiras diferentes, dependendo se você estiver usando a camada Standard/Premium do Azure Key Vault ou o HSM gerenciado do Azure Key Vault. Essas diferenças no controle de acesso podem afetar a maneira como uma organização usa esses recursos. Esta seção descreve essas diferenças e como elas podem afetar a maneira como uma organização escolhe projetar seus processos operacionais para o gerenciamento de chaves na nuvem.

Restrições de conformidade para validação FIPS-140 Nível 3

A validação FIPS-140 Nível 3 requer identificação do operador baseada em identidade. Essas proteções são implementadas e validadas no hardware HSM subjacente que oferece suporte aos serviços do Key Vault no Azure. Como resultado, os recursos de RBAC no Azure Key Vault dependem dos recursos de RBAC do hardware subjacente.

O HSM gerenciado do Azure Key Vault aproveita as atribuições de RBAC locais implementadas no nível de hardware e permite atribuições de função no escopo do domínio de segurança (por exemplo, em todo HSM) ou por chave. Isso significa que a criação da chaves exige permissões administrativas em todo o domínio de segurança, uma vez que as permissões não podem ser atribuídas a uma chave que ainda não exista. O impacto desse design é que qualquer pessoa que precise armazenar uma chave em uma instância mHSM deve ter permissões totais para todas as chaves armazenadas nesse domínio de segurança ou solicitar chaves de uma equipe centralizada que tenha as permissões necessárias sobre o domínio de segurança. Isso representa uma mudança em relação às diretrizes do Azure Key Vault que recomendam a criação de cofres de chaves separados para cada aplicativo.

Operações de gerenciamento de chaves no HSM gerenciado do Azure Key Vault

Para desenvolver processos operacionais para o gerenciamento de chaves, os clientes devem determinar se precisam do HSM gerenciado do Azure Key Vault como parte da arquitetura da solução. As organizações que planejam usar o HSM gerenciado devem primeiro se familiarizar com os modelos de controle de acesso usados para a administração e operações criptográficas e entender como o controle de acesso baseado em função é atribuído.

Saiba mais sobre o controle de acesso no HSM gerenciado:

As organizações que planejam usar o HSM do Azure Key Vault devem revisar a lista de funções RBAC internas e operações permitidas para o HSM gerenciado e planejar especificamente a abordagem dos seguintes cenários de operações:

  • Criação de uma chave no HSM gerenciado
  • Operações de gerenciamento de uma chave existente usando o plano de controle, como atualizações ou rotação de chaves
  • Uso do plano de dados de uma chave existente por um aplicativo ou serviço

No momento, a única maneira de atribuir permissões para criar uma chave é atribuindo uma função como Crypto User que também inclua outras permissões, como rotação e exclusão de chaves. Como resultado, conceder a um membro da equipe do aplicativo as permissões necessárias para criar suas próprias chaves no HSM gerenciado provavelmente pode violar os princípios de privilégios mínimos, já que esse usuário também teria permissões administrativas para todas as chaves no HSM. Esse problema pode ser resolvido introduzindo uma equipe centralizada com permissões elevadas que pode facilitar solicitações de criação de chaves ou introduzindo automação que pode facilitar novas solicitações de criação de chaves por meio de processos de gerenciamento de serviços de TI que aproveitam a API REST do HSM gerenciado.

Conteúdo relacionado