Modelos de criptografia de dados

Para entender como os provedores de recursos do Azure implementam a criptografia em repouso, você precisa entender os diferentes modelos de criptografia e suas vantagens e desvantagens. Para garantir um idioma comum e uma taxonomia, os provedores de recursos do Azure compartilham essas definições.

O Azure criptografa automaticamente dados inativos por padrão usando chaves gerenciadas pela plataforma. Opcionalmente, você pode escolher outras abordagens de gerenciamento de chaves com base em seus requisitos de segurança e conformidade. A criptografia do lado do servidor inclui três cenários:

  • Criptografia do lado do servidor usando chaves gerenciadas pela plataforma (padrão).

    • Os provedores de recursos do Azure executam as operações de criptografia e descriptografia.
    • A Microsoft gerencia as chaves automaticamente.
    • Habilitado por padrão sem nenhuma configuração necessária.
    • Funcionalidade de nuvem completa.
  • Criptografia do lado do servidor usando chaves gerenciadas pelo cliente no Azure Key Vault (opcional).

    • Os provedores de recursos do Azure executam as operações de criptografia e descriptografia.
    • Você controla as chaves pelo Azure Key Vault.
    • Requer a configuração e o gerenciamento do cliente.
    • Funcionalidade de nuvem completa.
  • Criptografia do lado do servidor usando chaves gerenciadas pelo cliente em hardware controlado pelo cliente (opção avançada).

    • Os provedores de recursos do Azure executam as operações de criptografia e descriptografia.
    • Você controla as chaves no hardware controlado pelo cliente.
    • Configuração complexa e suporte limitado ao serviço do Azure.
    • Funcionalidade de nuvem completa.

Modelos de criptografia do lado do servidor referem-se à criptografia executada pelo serviço do Azure. Nesse modelo, o provedor de recursos executa as operações de criptografia e descriptografia. Por exemplo, o Armazenamento do Azure pode receber dados em operações de texto simples e realizar a criptografia e descriptografia internamente. O provedor de recursos pode usar chaves de criptografia que a Microsoft ou o cliente gerenciam, dependendo da sua configuração.

Diagrama mostrando um serviço Azure realizando criptografia do lado do servidor e armazenando dados criptografados com chaves de criptografia gerenciadas.

Cada um dos modelos de criptografia do lado do servidor em repouso tem características distintas do gerenciamento de chaves. Essas características incluem onde e como você cria e armazena chaves de criptografia, bem como os modelos de acesso e os procedimentos de rotação de chave.

Para criptografia do lado do cliente, considere:

  • Os serviços do Azure não podem ver dados descriptografados.
  • Os clientes gerenciam e armazenam chaves no local (ou em outros repositórios seguros). Os serviços do Azure não têm acesso a chaves.
  • Funcionalidade de nuvem reduzida.

Os modelos de criptografia suportados no Azure se dividiram em dois grupos principais: criptografia do cliente e criptografia do lado do servidor. Independentemente do modelo de criptografia em repouso usado, os serviços do Azure sempre recomendam o uso de um transporte seguro, como TLS ou HTTPS. Portanto, a criptografia de endereços no transporte por meio do protocolo de transporte. Isso não deveria ser um fator importante para determinar qual modelo de criptografia em repouso usar.

Modelo de criptografia de cliente

O modelo de criptografia do cliente refere-se à criptografia que o serviço ou aplicação chamadora realiza fora do provedor de recursos ou do Azure. O aplicativo de serviço no Azure ou em um aplicativo em execução no data center do cliente pode executar a criptografia. Em ambos os casos, quando você usa esse modelo de criptografia, o provedor de recursos do Azure recebe um blob de dados criptografado sem a possibilidade de descriptografar os dados de nenhuma forma ou de acessar as chaves de criptografia. Nesse modelo, o serviço de chamada ou aplicativo manipula o gerenciamento de chaves e o mantém opaco para o serviço do Azure.

Diagrama mostrando uma aplicação criptografando dados antes de enviar dados criptografados para um serviço Azure.

Criptografia do lado do servidor usando chaves gerenciadas pela plataforma (padrão)

Para a maioria das organizações, o requisito essencial é garantir que os dados estejam criptografados sempre que estiverem em repouso. A criptografia do lado do servidor, utilizando chaves gerenciadas pela plataforma (anteriormente chamadas de chaves gerenciadas por serviços), atende a esse requisito ao fornecer criptografia automática por padrão. Essa abordagem permite a criptografia em repouso sem exigir configurar ou gerenciar chaves de criptografia. A Microsoft cuida de tarefas de gerenciamento de chaves, como emissão, rotação e backup de chaves.

A maioria dos serviços do Azure implementa esse modelo como comportamento padrão, criptografando automaticamente os dados em repouso usando chaves gerenciadas pela plataforma sem exigir qualquer ação do cliente. O provedor de recursos do Azure cria as chaves, coloca-as em um armazenamento seguro e recupera-as quando necessário. O serviço tem acesso total às chaves e mantém controle total sobre o gerenciamento do ciclo de vida das credenciais. Esse controle oferece forte proteção contra criptografia sem nenhuma sobrecarga de gerenciamento.

Diagrama mostrando o armazenamento de chaves gerenciadas pela Microsoft para criptografia do lado do servidor usando chaves gerenciadas pela plataforma.

A criptografia do lado do servidor, usando chaves gerenciadas pela plataforma, atende à necessidade de criptografia em repouso sem nenhuma sobrecarga. O Azure habilita essa criptografia por padrão em todos os serviços do Azure, oferecendo proteção automática de dados sem necessidade de configuração ou gerenciamento. Você se beneficia de uma proteção forte contra criptografia imediatamente ao armazenar dados nos serviços do Azure, sem necessidade de etapas extras, custos ou gerenciamento contínuo.

A criptografia do lado do servidor, usando chaves gerenciadas pela plataforma, significa que o serviço tem acesso total para armazenar e gerenciar as chaves. Embora algumas organizações possam querer gerenciar 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 esse modelo. Em muitos casos, uma organização pode determinar que restrições de recursos ou riscos de uma solução local são maiores do que o risco de gerenciar chaves de criptografia em repouso na nuvem. No entanto, esse modelo pode não ser suficiente para organizações que exigem controlar a criação ou o ciclo de vida das chaves de criptografia ou para que diferentes profissionais gerenciem as chaves de criptografia de um serviço do que aqueles que o gerenciam (segregação do gerenciamento de chaves do modelo geral de gestão do serviço).

Acesso à chave

Quando você usa criptografia do lado do servidor com chaves gerenciadas pela plataforma, o serviço cuida da criação, armazenamento e acesso ao serviço de chaves. Normalmente, os provedores fundamentais de recursos do Azure armazenam chaves de criptografia de dados em um armazenamento próximo aos dados e rapidamente acessível, enquanto as chaves de criptografia de chave permanecem em um armazenamento interno seguro.

Vantagens

  • Configuração simples.
  • A Microsoft gerencia a rotação de chaves, o backup e a redundância.
  • Você não incorre em custos ou riscos associados à implementação de um esquema de gerenciamento de chaves personalizado.

Considerações

  • Sem controle sobre as chaves de criptografia (especificação da chave, ciclo de vida, revogação, e assim por diante). Essa opção é adequada para a maioria dos casos de uso, mas pode não atender aos requisitos de conformidade especializados.
  • Não há capacidade de separar o gerenciamento de chaves do modelo de gerenciamento geral para o serviço. As organizações que exigem separação de tarefas podem precisar de chaves gerenciadas pelo cliente.

Criptografia do lado do servidor usando chaves gerenciadas pelo cliente no Azure Key Vault e no Azure Key Vault Managed HSM (opcional)

Para cenários em que as organizações têm requisitos específicos para controlar suas chaves de criptografia além da criptografia gerenciada pela plataforma padrão, você pode opcionalmente escolher criptografia do lado do servidor usando chaves gerenciadas pelo cliente no Key Vault ou no Azure Key Vault Managed HSM. Essa abordagem se baseia na criptografia padrão em repouso, permitindo que você use suas próprias chaves enquanto o Azure continua cuidando das operações de criptografia e descriptografia.

Alguns serviços podem armazenar apenas a chave raiz de criptografia (KEK) no Azure Key Vault e armazenar a chave de criptografia de dados criptografados (DEK) em um local interno mais próximo dos dados. Nesse cenário, você pode usar o modelo bring your own key (BYOK) para importar chaves para o Key Vault ou gerar novas chaves no Key Vault, e então usá-las para criptografar os recursos desejados. Enquanto o provedor de recursos realiza as operações de criptografia e descriptografia, ele usa seu KEK configurado como chave raiz para todas as operações de criptografia.

A perda das chaves de criptografia de chave significa perda de dados. Por esse motivo, não exclua chaves. Sempre faça backup de chaves ao criá-las ou girá-las. Quando é feito o rodízio de KEK, o serviço encapsula as chaves de criptografia de dados com a nova versão da chave – os dados subjacentes não são recriptografados. Tanto as versões antigas quanto as novas de chave devem permanecer ativadas até que todas as chaves de criptografia de dados sejam encapsuladas com a nova versão da chave. Para proteger contra o apagamento criptográfico acidental ou mal-intencionado, a Proteção contra exclusão reversível e limpeza deve estar habilitada em qualquer cofre que armazene chaves de criptografia importantes. Em vez de excluir uma chave, defina "enabled" como "false" na chave de criptografia. Use controles de acesso para revogar o acesso a usuários ou serviços individuais no Azure Key Vault ou no HSM Gerenciado.

Warning

Se você suspeitar que uma chave está comprometida, não a desative ou exclua imediatamente. Desabilitar ou excluir uma chave deixa indisponíveis todos os serviços que dependem dela, mas não invalida nenhuma cópia da chave cujo backup tenha sido feito e que tenha sido restaurada em outro cofre. Essas cópias permanecem totalmente funcionais. Em vez disso, troque para uma nova chave e migre todos os serviços dependentes antes de desativar a chave comprometida. Para obter o procedimento completo de resposta a incidentes, consulte as considerações de segurança de backup e a resposta a comprometimento de chave.

Para cenários de chaves gerenciadas pelo cliente, use o Azure Key Vault Premium tier (HSM-backed) como mínimo para requisitos de conformidade que exigem chaves protegidas pelo HSM. Use o Azure Key Vault Managed HSM para cargas de trabalho que exigem soberania de chaves ou capacidade dedicada de HSM. Para organizações que possuem requisitos regulatórios ou contratuais que exigem que o material-chave resida fisicamente fora da infraestrutura da Microsoft, o Azure Key Vault Managed HSM também suporta gerenciamento externo de chaves (prévia), que mantém o KEK em um HSM operado pelo cliente totalmente fora do Azure.

Observação

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

Acesso à chave

No modelo de criptografia do lado do servidor que usa chaves gerenciadas pelo cliente no Azure Key Vault, o serviço acessa as chaves para criptografar e descriptografar conforme necessário. Você torna as chaves de criptografia em repouso acessíveis a um serviço por meio de uma política de controle de acesso. Essa política concede o acesso de identidade de serviço para receber a chave. Você pode configurar um serviço do Azure que opera em nome de uma assinatura associada, com uma identidade dentro dessa assinatura. 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 então apresenta o token ao Key Vault para obter uma chave que ele possa acessar.

Para operações que utilizam chaves de criptografia, você 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 uso na criptografia ou na descriptografia de dados em repouso, a identidade de serviço sob a qual a instância do serviço Resource Manager é executada deve ter UnwrapKey (para obter a chave para descriptografia) e WrapKey (para inserir uma chave no Key Vault ao criar uma nova chave).

Observação

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

Vantagens

  • Controle total sobre as teclas usadas. Chaves de criptografia são gerenciadas no seu Key Vault sob seu controle.
  • Você pode criptografar múltiplos serviços usando uma chave raiz.
  • Você pode segregar a gestão de chaves do modelo geral de gestão do serviço.
  • Você pode definir serviço e localização da chave em diferentes regiões.

Desvantagens

  • Você tem total responsabilidade pelo gerenciamento de chaves de acesso.
  • Você tem total responsabilidade pelo gerenciamento de ciclo de vida chave.
  • Sobrecarga adicional de instalação e configuração.

Criptografia do lado do servidor usando chaves gerenciadas pelo cliente em hardware controlado pelo cliente (opção especializada)

Alguns serviços do Azure habilitam o modelo de gerenciamento de chaves HYOK (Host Your Own Key) para organizações com requisitos de segurança especializados. Esse modo de gerenciamento é útil em cenários altamente regulados que exigem criptografia de dados em repouso e gerenciamento de chaves em um repositório proprietário completamente fora do controle da Microsoft. Vai além da criptografia gerenciada por plataforma padrão e das chaves opcionais gerenciadas pelo cliente no Azure Key Vault.

Neste modelo, o serviço deve usar a chave de um site externo para descriptografar o DEK. As garantias de desempenho e disponibilidade são afetadas e a configuração é significativamente mais complexa. Além disso, como o serviço não tem acesso ao DEK durante as operações de criptografia e descriptografia, as garantias gerais de segurança desse modelo são semelhantes às que acontecem quando as chaves são gerenciadas pelo cliente no Azure Key Vault. Como resultado, esse modelo não é apropriado para a maioria das organizações, a menos que elas tenham requisitos regulatórios ou de segurança muito específicos que não possam ser atendidos com chaves gerenciadas pela plataforma ou chaves gerenciadas pelo cliente no Azure Key Vault. Devido a essas limitações, a maioria dos serviços do Azure não suporta criptografia do lado do servidor usando chaves gerenciadas pelo cliente em hardware controlado pelo cliente. Uma das duas chaves na Criptografia de Chave Dupla , segue esse modelo.

Acesso à chave

Quando você usa criptografia do lado do servidor com chaves gerenciadas pelo cliente em hardware controlado pelo cliente, você mantém as chaves de criptografia em um sistema que configura. Os serviços do Azure que dão suporte a esse modelo fornecem uma maneira de estabelecer uma conexão segura com um repositório de chaves fornecido pelo cliente.

Vantagens

  • Você tem controle total sobre a chave raiz porque uma loja fornecida pelo cliente gerencia as chaves de criptografia.
  • Você pode criptografar múltiplos serviços usando uma chave raiz.
  • Você pode segregar a gestão de chaves do modelo geral de gestão do serviço.
  • Você pode definir serviço e localização da chave em diferentes regiões.

Desvantagens

  • Você tem total responsabilidade pelo armazenamento de chaves, segurança, desempenho e disponibilidade.
  • Você tem total responsabilidade pelo gerenciamento de chaves de acesso.
  • Você tem total responsabilidade pelo gerenciamento de ciclo de vida chave.
  • Você 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 data center do cliente e os data centers do Azure.