Encriptação com chaves geridas pelo cliente na Microsoft Cloud for Sovereignty

Artigo
04/12/2024

Os clientes que planeiam implementar a Microsoft Cloud for Sovereignty podem exigir a utilização de funcionalidades de encriptação de dados para satisfazer os requisitos de soberania de dados. Os clientes com requisitos rigorosos de soberania de dados devem desenvolver planos para implementar a gestão de chaves na cloud. Este artigo orienta arquitetos de cloud, proprietários de sistemas criptográficos e outros decisores técnicos para desenvolver um plano para implementar a encriptação ao nível da plataforma no Azure. O planeamento da encriptação ao nível da plataforma geralmente envolve a identificação de requisitos de gestão de chaves, a criação de escolhas tecnológicas e a seleção de estruturas e opções de configuração para os serviços do Azure a serem utilizados. Este processo envolve a tomada de decisões técnicas em três domínios:

Defina os principais requisitos de gestão: o que a sua organização precisa de fazer para proteger dados confidenciais de clientes e material criptográfico confidencial?
Selecione funcionalidades de encriptação de dados para proteger os dados dos clientes: como, onde e quando deve encriptar dados de clientes no Azure?
Selecione soluções de gestão de chaves para proteger as chaves dos clientes: qual arquivo de chaves deve utilizar para proteger as chaves de encriptação de dados utilizadas para encriptar dados dos clientes no Azure?

Definir os requisitos da gestão de chaves

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

Basear os requisitos de encriptação na classificação de dados também permite uma abordagem em camadas, em que as cargas de trabalho com nível crítico menor podem tirar partido de 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 a utilização de chaves geridas pela Microsoft para encriptar contas de armazenamento para ambientes de desenvolvimento, exigindo ao mesmo tempo que as contas de armazenamento de produção utilizem chaves de encriptação Geridas pelo cliente.

Depois de uma organização compreender claramente como os seus requisitos de encriptação se relacionam com as suas classificações de dados, poderá iniciar o processo de seleção de funcionalidades para os serviços do Azure que planeia consumir. Algumas destas funcionalidades podem funcionar de forma diferente dos sistemas no local semelhantes, portanto, recomenda-se que as organizações se familiarizem com a forma como a encriptação funciona no Azure e a revejam as recomendações e melhores práticas para conceber soluções de encriptação. Os artigos seguinte fornecem perspetivas 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 gestão de chaves na cloud de uma organização.

Selecionar funcionalidades de encriptação de dados

Muitos serviços do Azure permitem a encriptação utilizando chaves que são geradas, armazenadas e geridas inteiramente pelo Azure, sem qualquer interação com o cliente. Estas Chaves Geridas pela Plataforma podem ajudar as organizações a implementar a encriptação com pouca sobrecarga operacional. No entanto, os clientes com requisitos rigorosos de soberania de dados talvez precisem de selecionar funcionalidades específicas de encriptação da plataforma para proteger dados confidenciais enquanto estão inativos num determinado serviço do Azure.

Para dados altamente confidenciais, muitos serviços do Azure habitualmente utilizados permitem que os clientes implementem a encriptação dupla utilizando Chaves Geridas pelo Cliente (CMK). A implementação de chaves geridas 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 geridas 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 desta funcionalidade recurso para cada carga de trabalho e o nível de classificação de dados. A implementação de chaves geridas pelo cliente apenas para as cargas de trabalho e os 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 Geridas pelo Cliente, estas deverão ser configuradas para cada respetivo serviço do Azure. As organizações podem ajudar a simplificar os esforços de planeamento de implementação ou migração estabelecendo normas para toda a organização e padrões de conceção repetíveis para implementar estas funcionalidades. Os seguintes artigos fornecem mais informações sobre como a encriptação de dados inativa é configurada no Azure:

Saiba como configurar os serviços do Azure habitualmente utilizados para encriptar dados inativos utilizando Chaves Geridas pelo Cliente:

Selecionar soluções de gestão de chaves

Embora os recursos como a encriptação dupla com chaves geridas pelo cliente possam ajudar a proteger os dados do cliente que são mantidos nos serviços do Azure, as soluções de gestão de chaves baseadas na cloud ajudam a proteger as chaves de encriptação e outros materiais criptográficos que são utilizados para encriptar dados confidenciais. Os clientes com requisitos rigorosos de soberania de dados devem selecionar uma solução de gestão 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 processam dados confidenciais podem beneficiar da garantia adicional fornecida por soluções como o HSM Gerido do Azure, incluindo módulos de segurança de hardware validados FIPS-140-2 Nível 3 que apresentam controlos de segurança adicionais para proteger o material criptográfico armazenado.

Os artigos seguinte fornecem orientações que os clientes podem utilizar para selecionar um armazenamento de chaves apropriado para os seus cenários identificados. Também fornecem informações sobre como a Microsoft gere os serviços criptográficos utilizados pelos clientes como parte da sua solução de encriptação.

Modelos de operações para a gestão de chaves

O Azure Key Vault implementa o controlo de acesso baseado em funções de diferentes formas, dependendo se está a utilizar o escalão Standard/Premium do Azure Key Vault ou do HSM Gerido do Azure Key Vault. Estas diferenças no controlo de acesso podem afetar a forma como uma organização utiliza estas funcionalidades. Esta secção descreve estas diferenças e como podem afetar a forma como uma organização opta por conceber os respetivos processos operacionais para a gestão de chaves de cloud.

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. Estas salvaguardas são implementadas e validadas no hardware HSM subjacente que suporta os serviços do Key Vault no Azure. Como resultado, as funcionalidades RBAC no Azure Key Vault dependem das capacidades RBAC do hardware subjacente.

O HSM Gerido do Azure Key Vault tira partido das atribuições RBAC locais implementadas ao nível do hardware e permite atribuições de função no âmbito do domínio de segurança (por exemplo, ao nível do HSM) ou numa base por chave. Isto significa que a criação de chaves requer permissões administrativas sobre 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 existe. O impacto deste design é que qualquer pessoa que precise de armazenar uma chave numa instância do mHSM deve ter permissões totais para todas as chaves armazenadas nesse domínio de segurança ou solicitar chaves de uma equipa centralizada que tenha essas permissões necessárias sobre o domínio de segurança. Isto representa uma mudança em relação à orientação para o Azure Key Vault, que recomenda a criação de cofres de chaves separados para cada aplicação.

Operações de gestão de chaves no HSM Gerido do Azure Key Vault

Para desenvolver processos operacionais para a gestão de chaves, os clientes devem determinar se necessitam do HSM Gerido do Azure Key Vault como parte da arquitetura da solução. As organizações que planeiam utilizar o HSM gerido devem primeiro familiarizar-se com os modelos de controlo de acesso utilizados para administração e operações criptográficas e entender como o controlo de acesso baseado em função é atribuído.

Saiba mais sobre o controlo de acesso no HSM gerido:

As organizações que planeiam utilizar o HSM do Azure Key Vault devem rever a lista de funções RBAC incorporadas e operações permitidas para o HSM gerido e planear especificamente abordar os seguintes cenários de operações:

Criação de uma nova chave no HSM gerido
Operações de gestão de uma chave existente utilizando o plano de controlo, tais como atualizações de chaves ou rotação de chaves
Utilização do plano de dados de uma chave existente por uma aplicação ou serviço

Atualmente, a única forma de atribuir permissões para criar uma nova chave é atribuir uma função como Crypto User que inclua também outras permissões, como a rotação e a eliminação de chaves. Como resultado, conceder a um membro da equipa da aplicação as permissões necessárias para criar as suas próprias chaves no HSM gerido provavelmente violará os princípios de privilégio mínimo, uma vez que esse utilizador também teria permissões administrativas para todas as chaves no HSM. Este problema pode ser resolvido através da introdução de uma equipa centralizada com permissões elevadas que podem facilitar pedidos de criação de chaves ou através da introdução de automatização que pode facilitar novos pedidos de criação de chaves através de processos de gestão de serviços de TI que utilizam a API REST de HSM Gerido.