Modelos de encriptação de dados

Para compreender como os fornecedores de recursos Azure implementam encriptação em repouso, é necessário compreender os diferentes modelos de encriptação e as suas vantagens e desvantagens. Para garantir uma linguagem e taxonomia comuns, os fornecedores de recursos Azure partilham estas definições.

Azure encripta automaticamente os dados em repouso por padrão, usando chaves geridas pela plataforma. Pode, opcionalmente, escolher outras abordagens de gestão de chaves com base nos seus requisitos de segurança e conformidade. A encriptação do lado do servidor inclui três cenários:

• Encriptação do lado do servidor usando chaves geridas pela plataforma (por defeito).

  • Os fornecedores de recursos Azure realizam as operações de encriptação e desencriptação.
  • A Microsoft gere as chaves automaticamente.
  • Ativado por padrão, sem necessidade de configuração.
  • Funcionalidade total na cloud.

• Encriptação do lado do servidor usando chaves geridas pelo cliente no Azure Key Vault (opcional).

  • Os fornecedores de recursos Azure realizam as operações de encriptação e desencriptação.
  • Controlas as chaves através do Azure Key Vault.
  • Requer configuração e gestão do cliente.
  • Funcionalidade total na cloud.

• Encriptação do lado do servidor utilizando chaves geridas pelo cliente em hardware controlado pelo cliente (opção avançada).

  • Os fornecedores de recursos Azure realizam as operações de encriptação e desencriptação.
  • Controlas as chaves em hardware controlado pelo cliente.
  • Configuração complexa e suporte limitado de serviços Azure.
  • Funcionalidade total na cloud.

Modelos de encriptação do lado do servidor referem-se à encriptação que o serviço Azure realiza. Nesse modelo, o fornecedor de recursos realiza as operações de encriptação e desencriptação. Por exemplo, o Armazenamento do Azure pode receber dados em operações de texto sem formatação e executar a criptografia e descriptografia internamente. O fornecedor de recursos pode usar chaves de encriptação que a Microsoft ou o cliente gerem, dependendo da sua configuração.

Cada um dos modelos de encriptação em repouso do lado do servidor tem características distintivas de gestão de chaves. Estas características incluem onde e como criar e armazenar chaves de encriptação, bem como os modelos de acesso e os procedimentos de rotação de chaves.

Para criptografia do lado do cliente, considere:

• Os serviços Azure não conseguem ver dados desencriptados.
• Os clientes gerenciam e armazenam chaves no local (ou em outros repositórios seguros). Os serviços Azure não têm acesso às chaves.
• Funcionalidade na cloud reduzida.

Os modelos de encriptação suportados no Azure dividiram-se em dois grupos principais: encriptação do cliente e encriptação do lado do servidor. Independentemente do modelo de encriptação em repouso que utilize, os serviços Azure recomendam sempre o uso de um transporte seguro como TLS ou HTTPS. Portanto, encriptação de endereços no transporte através do protocolo de transporte. Não deveria ser um fator importante para determinar qual modelo de encriptação em repouso usar.

Modelo de criptografia do cliente

O modelo de encriptação do cliente refere-se à encriptação que o serviço ou aplicação que chama realiza fora do fornecedor de recursos ou do Azure. A aplicação de serviço no Azure ou uma aplicação a correr no centro de dados do cliente pode realizar a encriptação. Em qualquer dos casos, quando se utiliza este modelo de encriptação, o fornecedor de recursos do Azure recebe um blob de dados encriptado sem possibilidade de desencriptar os dados de qualquer forma ou aceder às chaves de encriptação. Neste modelo, o serviço ou aplicação que chama trata da gestão de chaves e mantém-na opaca ao serviço Azure.

Encriptação do lado do servidor usando chaves geridas pela plataforma (por defeito)

Para a maioria das organizações, o requisito essencial é garantir que os dados estão encriptados sempre que estiverem em repouso. A encriptação do lado do servidor, utilizando chaves geridas pela plataforma (anteriormente chamadas chaves geridas por serviços), cumpre este requisito ao fornecer encriptação automática por defeito. Esta abordagem permite encriptação em repouso sem precisar de configurar ou gerir chaves de encriptação. A Microsoft trata de tarefas de gestão de chaves, como emissão, rotação e backup de chaves.

A maioria dos serviços Azure implementa este modelo como comportamento padrão, encriptando automaticamente os dados em repouso através do uso de chaves geridas pela plataforma sem exigir qualquer ação do cliente. O provedor de recursos do Azure cria as chaves, coloca-as em armazenamento seguro e as recupera quando necessário. O serviço tem acesso total às chaves e mantém controlo total sobre a gestão do ciclo de vida das credenciais. Este controlo proporciona uma forte proteção contra encriptação sem qualquer sobrecarga de gestão.

A encriptação do lado do servidor, através do uso de chaves geridas pela plataforma, resolve a necessidade de encriptação em repouso sem qualquer overhead. O Azure permite esta encriptação por defeito em todos os serviços Azure, proporcionando proteção automática dos dados sem necessidade de qualquer configuração ou gestão. Beneficia de uma forte proteção contra encriptação imediatamente após armazenar dados nos serviços do Azure, sem necessidade de passos adicionais, custos ou gestão contínua.

A encriptação do lado do servidor, através do uso de chaves geridas pela plataforma, significa que o serviço tem acesso total para armazenar e gerir as chaves. Embora algumas organizações possam querer gerir as chaves porque esperam maior segurança, considere o custo e o risco associados a uma solução personalizada de armazenamento de chaves ao avaliar este modelo. Em muitos casos, uma organização pode determinar que as limitações de recursos ou os riscos de uma solução on-premises são maiores do que o risco de gestão na cloud das chaves de encriptação em repouso. No entanto, este modelo pode não ser suficiente para organizações que têm requisitos para controlar a criação ou o ciclo de vida das chaves de encriptação ou para que pessoas diferentes geram as chaves de encriptação de um serviço do que aquelas que o gerem (segregação da gestão de chaves do modelo global de gestão do serviço).

Chave de acesso

Quando utiliza encriptação do lado do servidor com chaves geridas pela plataforma, o serviço trata da criação, armazenamento e acesso ao serviço. Normalmente, os fornecedores de recursos subjacentes do Azure armazenam as chaves de encriptação de dados num repositório próximo dos dados e de acesso rápido, enquanto as chaves de encriptação de chaves ficam armazenadas num repositório interno seguro.

Vantagens

• Configuração simples.
• A Microsoft gere a rotação de chaves, backup e redundância.
• Não incorre em custos ou riscos associados à implementação de um esquema personalizado de gestão de chaves.

Considerações

• Sem controlo sobre as chaves de encriptação (especificação da chave, ciclo de vida, revogação, e assim por diante). Esta opção é adequada para a maioria dos casos de uso, mas pode não cumprir os requisitos de conformidade especializados.
• Não há capacidade de segregar a gestão-chave do modelo global de gestão do serviço. Organizações que exigem separação de funções podem necessitar de chaves geridas pelo cliente.

Encriptação do lado do servidor utilizando chaves geridas pelo cliente no Azure Key Vault e Azure Key Vault Managed HSM (opcional)

Para cenários em que as organizações têm requisitos específicos para controlar as suas chaves de encriptação para além da encriptação gerida pela plataforma por defeito, pode optar opcionalmente por encriptação do lado do servidor usando chaves geridas pelo cliente no Key Vault ou no Azure Key Vault Managed HSM. Esta abordagem baseia-se na encriptação padrão em repouso, permitindo-lhe usar as suas próprias chaves enquanto o Azure continua a tratar das operações de encriptação e desencriptação.

Alguns serviços podem armazenar apenas a chave de encriptação da chave raiz (KEK) no Azure Key Vault e armazenar a chave de encriptação de dados encriptados (DEK) numa localização interna mais próxima dos dados. Neste cenário, pode usar o modelo bring your own key (BYOK) para importar chaves para o Key Vault ou gerar novas chaves no Key Vault, e depois usá-las para encriptar os recursos desejados. Enquanto o fornecedor de recursos realiza as operações de encriptação e desencriptação, utiliza o seu KEK configurado como chave raiz para todas as operações de encriptação.

Perda de chaves de criptografia de chave significa perda de dados. Por esta razão, não apagues as chaves. Efetua sempre uma cópia de segurança das chaves quando as crias ou rodes. Quando um KEK é rotacionado, o serviço encapsula as chaves de encriptação de dados com a nova versão da chave — os dados subjacentes não são novamente encriptados. Tanto as versões antigas como as novas de chave devem permanecer ativadas até que todas as chaves de encriptação de dados estejam envolvidas com a nova versão da chave. Para proteger contra apagamentos criptográficos acidentais ou maliciosos, a proteção contra eliminação suave e purga deve estar ativada em qualquer cofre que armazene chaves de encriptação de chaves. Em vez de eliminar uma chave, defina a opção 'ativado' como false na chave de encriptação de chave. Use controles de acesso para revogar o acesso a usuários ou serviços individuais no Cofre de Chaves do Azure ou no HSM gerenciado.

Warning

Se suspeitar que uma chave está comprometida, não a desative ou apague imediatamente. Desativar ou eliminar uma chave coloca offline todos os serviços dependentes, mas não invalida quaisquer cópias da chave que tenham sido guardadas em cópia de segurança e restauradas noutro cofre. Essas cópias continuam totalmente funcionais. Em vez disso, rode para uma nova chave e migre todos os serviços dependentes antes de desativar a chave comprometida. Para o procedimento completo de resposta a incidentes, veja Considerações de segurança de backup e resposta a comprometimento de chaves.

Para cenários de chave geridos pelo cliente, use o Azure Key Vault Premium tier (HSM-backed) como mínimo para os requisitos de conformidade que exigem chaves protegidas pelo HSM. Use o Azure Key Vault Managed HSM para cargas de trabalho que requerem soberania de chave ou capacidade dedicada de HSM. Para organizações que têm requisitos regulamentares ou contratuais que obrigam o material-chave a residir fisicamente fora da infraestrutura da Microsoft, o Azure Key Vault Managed HSM também suporta gestão externa de chaves (preview), que mantém o KEK num HSM operado pelo cliente totalmente fora do Azure.

Nota

Para uma lista de serviços que suportam chaves geridas pelo cliente no Azure Key Vault e no Azure Key Vault Managed HSM, veja Serviços que suportam CMKs no Azure Key Vault e Azure Key Vault Managed HSM.

Chave de acesso

No modelo de encriptação do lado do servidor que utiliza chaves geridas pelo cliente no Azure Key Vault, o serviço acede às chaves para encriptar e desencriptar conforme necessário. Torna as chaves de encriptação em repouso acessíveis a um serviço através de uma política de controlo de acesso. Esta política concede à identidade do serviço acesso para receber a chave. Pode configurar um serviço Azure a correr em nome de uma subscrição associada com uma identidade nessa subscrição. O serviço pode executar a autenticação do Microsoft Entra e receber um token de autenticação identificando-se como esse serviço agindo em nome da assinatura. O serviço apresenta então o token ao Key Vault para obter uma chave a que possa aceder.

Para operações que utilizam chaves de encriptação, pode conceder à identidade de serviço acesso a qualquer uma das seguintes operações: decrypt, encrypt, unwrapKey, wrapKey, verify, sign, get, list, update, create, import, delete, backup e restore.

Para obter uma chave para utilizar na encriptação ou desencriptação de dados em repouso, a identidade de serviço utilizada pela instância do serviço Resource Manager tem de ter UnwrapKey (para obter a chave para desencriptação) e WrapKey (para inserir uma chave no Key Vault ao criar uma nova chave).

Nota

Para mais informações sobre a autorização do Key Vault, consulte Secure your Key vault.

Vantagens

• Controlo total sobre as teclas usadas. As chaves de encriptação são geridas no seu Key Vault sob o seu controlo.
• Pode encriptar vários serviços usando uma única chave raiz.
• Pode separar a gestão de chaves do modelo geral de gestão do serviço.
• Pode definir serviço e a localização da chave em diferentes regiões.

Desvantagens

• Tens total responsabilidade pela gestão do acesso às chaves.
• Tem total responsabilidade pela gestão do ciclo de vida chave.
• Custos adicionais e carga de configuração.

Encriptação do lado do servidor utilizando chaves geridas pelo cliente em hardware controlado pelo cliente (opção especializada)

Alguns serviços Azure permitem o modelo de gestão de chaves Host Your Own Key (HYOK) para organizações com requisitos de segurança especializados. Este modo de gestão é útil em cenários altamente regulados que exigem encriptação de dados em repouso e gestão de chaves num repositório proprietário completamente fora do controlo da Microsoft. Vai além da encriptação gerida pela plataforma predefinida e das chaves opcionais geridas pelo cliente no Azure Key Vault.

Neste modelo, o serviço deve usar a chave de um site externo para desencriptar o DEK. As garantias de desempenho e disponibilidade são afetadas, e a configuração torna-se significativamente mais complexa. Além disso, como o serviço não tem acesso ao DEK durante as operações de encriptação e desencriptação, as garantias globais de segurança deste modelo são semelhantes às geridas pelo cliente no Azure Key Vault. Como resultado, este modelo não é adequado para a maioria das organizações, a menos que tenham requisitos regulatórios ou de segurança muito específicos que não possam ser cumpridos com chaves geridas pela plataforma ou pelo cliente no Azure Key Vault. Devido a estas limitações, a maioria dos serviços Azure não suporta encriptação do lado do servidor usando chaves geridas pelo cliente em hardware controlado pelo cliente. Uma das duas chaves na Encriptação de Dupla Chave segue este modelo.

Chave de acesso

Quando utiliza encriptação do lado do servidor com chaves geridas pelo cliente em hardware controlado pelo cliente, mantém as chaves de encriptação de chaves num sistema configurado por si. Os serviços Azure que suportam este modelo fornecem uma forma de estabelecer uma ligação segura a uma loja de chaves fornecida pelo cliente.

Vantagens

• Tem controlo total sobre a chave raiz porque uma loja fornecida pelo cliente gere as chaves de encriptação.
• Pode encriptar vários serviços usando uma única chave raiz.
• Pode separar a gestão de chaves do modelo geral de gestão do serviço.
• Pode definir serviço e a localização da chave em diferentes regiões.

Desvantagens

• Tem total responsabilidade pelo armazenamento de chaves, segurança, desempenho e disponibilidade.
• Tens total responsabilidade pela gestão do acesso às chaves.
• Tem total responsabilidade pela gestão do ciclo de vida chave.
• Incorre em custos significativos de configuração, configuração e manutenção contínua.
• O modelo aumenta a dependência da disponibilidade da rede entre o centro de dados do cliente e os centros de dados Azure.

Conteúdos relacionados

• Serviços que suportam CMKs no Azure Key Vault e no Azure Key Vault Managed HSM
• Como a criptografia é usada no Azure
• Dupla encriptação