Customer Key no Microsoft 365: quando a conversa sobre chaves chega ao Teams

Quem administra Microsoft 365 sabe que os dados da organização estão sempre criptografados em repouso. BitLocker e Distributed Key Manager (DKM) cuidam disso na camada de disco, e a Microsoft gerencia as chaves. Para a maioria dos cenários, esse modelo funciona. Mas quando o assunto é conformidade regulatória, setor financeiro, dados sujeitos a residência ou simplesmente a decisão de não terceirizar o controle das chaves de criptografia, a conversa muda.

Ela muda para o Microsoft Purview Customer Key.

Customer Key é o recurso que permite que você traga e gerencie suas próprias chaves de criptografia para proteger dados em repouso no Microsoft 365. As chaves ficam no Azure Key Vault (ou no Managed HSM, que oferece certificação FIPS 140-2 Level 3), e a Microsoft as usa sob sua autorização explícita. A base legal disso está nos Online Services Terms (OST), que descrevem como a Microsoft trata os dados de cliente. Fonte: visão geral do Customer Key ((abre em nova aba)).

A página de visão geral do Customer Key no Microsoft Learn explica que o recurso cobre dados de Exchange, SharePoint, OneDrive, Teams e Windows 365 Cloud PCs (Enterprise e Frontline, nos modos Dedicated e Shared). É uma camada adicional de criptografia que se soma ao BitLocker e ao DKM, não uma substituição. Fonte: visão geral do Customer Key ((abre em nova aba)).

O que muda para o TeamsLink para esta seção

Aqui a conversa fica interessante. Quando se fala em criptografia no Microsoft 365, muita gente pensa primeiro em Exchange e SharePoint. O Teams, por ser mais recente, nem sempre entra na lista. Mas o Customer Key cobre o Teams sim, e de um jeito específico.

Os dados do Teams protegidos pelo Customer Key incluem mensagens de chat, mensagens de mídia, gravações de chamadas e reuniões (desde que armazenadas no armazenamento do Teams), notificações, sugestões do Cortana e mensagens de status. É importante notar que arquivos compartilhados no Teams e gravações salvos no SharePoint ou no OneDrive não são cobertos pela política de dados do Teams, eles entram na política de criptografia do SharePoint. Fonte: visão geral do Customer Key, seção Learn about data encryption policies ((abre em nova aba)).

Outros recursos que ficam de fora: Teams Live Events, Viva Engage e Planner. Cada um tem seu próprio mecanismo de proteção. Fonte: visão geral do Customer Key, seção Learn about data encryption policies ((abre em nova aba)).

A criptografia do Teams acontece por meio de uma Data Encryption Policy (DEP) do tipo "multi-workload". Essa política é única por tenant e cobre, além do Teams, dados de Windows 365 Cloud PCs, interações do Microsoft 365 Copilot, caixas postais do Exchange que não tenham uma DEP própria e dados do Purview Information Protection (como esquemas do Exact Data Match e configurações de rótulo de confidencialidade). Você pode criar várias DEPs, mas apenas uma fica ativa por vez. Fonte: visão geral do Customer Key, seção DEP for Multiple Microsoft 365 workloads ((abre em nova aba)).

Como funciona na práticaLink para esta seção

O Customer Key opera com uma hierarquia de chaves. Você fornece duas chaves raiz, armazenadas em dois cofres do Azure Key Vault em assinaturas diferentes do Azure. A Microsoft recomenda usar assinaturas separadas justamente para que pessoas diferentes administrem cada chave, isso reduz o risco de uma ação acidental ou maliciosa comprometer as duas ao mesmo tempo. Fonte: guia de configuração do Customer Key ((abre em nova aba)).

Quando uma DEP é criada, o Microsoft 365 gera uma chave intermediária que é criptografada três vezes: uma com cada uma das suas chaves e uma terceira com a availability key, que a Microsoft protege. A availability key funciona como uma chave de emergência: se você perder o acesso às duas chaves no Key Vault, ela permite recuperar os dados e re-criptografá-los com uma nova DEP. Para Exchange e multi-workload, ela também garante continuidade durante indisponibilidades temporárias do Key Vault em operações internas como anti-malware, eDiscovery e indexação. Fonte: documentação da availability key ((abre em nova aba)).

Para o SharePoint, a hierarquia é um pouco diferente: uma Tenant Intermediate Key (TIK) é criptografada com suas chaves, e dela derivam site keys, blob keys e, por fim, a criptografia dos fragmentos de arquivo no Azure Blob Storage. Fonte: documentação da availability key, seção SharePoint and OneDrive ((abre em nova aba)).

O que é preciso para começarLink para esta seção

A configuração exige alguns passos que estão bem documentados no Microsoft Learn, mas vale destacar os requisitos principais.

Você precisa de duas assinaturas pagas do Azure (assinaturas Free, Trial, Sponsorship, MSDN ou Legacy Support não são elegíveis). Cada chave fica em um Key Vault separado, com soft delete e purge protection habilitados e período de retenção de 90 dias. As chaves são do tipo RSA, com até 4.096 bits. Não podem ter data de expiração, se tiverem, o Customer Key Onboarding Service as rejeita. Fonte: guia de configuração do Customer Key, seção Prerequisites ((abre em nova aba)).

O licenciamento é outro ponto que merece atenção. O Customer Key está disponível no Microsoft 365 E5/A5/G5, no Office 365 E5/A5/G5 e no Microsoft Purview Suite. A página de descrição de serviço do Purview detalha que, para políticas multi-workload, o tenant precisa ter ao menos tantas licenças de Customer Key quantos usuários com licença de Exchange ou Teams, o que for maior. O SharePoint é licenciado separadamente. A Microsoft valida a contagem de licenças periodicamente; se o número de licenças elegíveis for insuficiente, a criptografia volta para o padrão gerenciado pela Microsoft. Fonte: descrição de serviço do Microsoft Purview, seção Customer Key Licensing ((abre em nova aba)).

No seu tenant, confirme com a página de descrição de serviço do Purview se o plano contratado inclui Customer Key. E confira também se as service principals necessárias estão registradas no Microsoft Entra ID: M365DataAtRestEncryption (para multi-workload), Office 365 Exchange Online e Office 365 SharePoint Online. Fonte: guia de configuração, seção Register the required Service Principals ((abre em nova aba)).

E na hora de sair?Link para esta seção

Um dos argumentos mais fortes a favor do Customer Key é o controle sobre a saída. Se você decidir encerrar o serviço com a Microsoft ou remover uma porção específica dos dados armazenados na nuvem, é possível revogar as chaves e solicitar a purga dos dados. A Microsoft descreve esse processo como "cryptographic deletion": sem as chaves, os dados se tornam ilegíveis. Fonte: guia de gerenciamento, seção Revoke your keys and start the data purge path ((abre em nova aba)).

Esse caminho só funciona para DEPs de caixa postal individual, não para políticas multi-workload. A purga de uma DEP multi-workload não é suportada justamente porque criptografa dados de vários workloads e usuários ao mesmo tempo. Fonte: guia de gerenciamento, seção Revoke your keys and start the data purge path ((abre em nova aba)). Para Exchange, o processo envolve remover as permissões de wrap/unwrap do Key Vault, acionar o cmdlet Set-DataEncryptionPolicy com o parâmetro -PermanentDataPurgeRequested e assinar um documento legal com a Microsoft. Fonte: guia de gerenciamento, seção Revoke your Customer Keys for Exchange ((abre em nova aba)).

Para SharePoint e OneDrive, a purga via Customer Key não é suportada. Se a saída for definitiva do Microsoft 365, o caminho documentado é a exclusão do tenant no Microsoft Entra ID. Fonte: guia de gerenciamento, seção Revoke your Customer Keys for SharePoint and OneDrive ((abre em nova aba)).

O que o Customer Key não fazLink para esta seção

Nenhum recurso resolve tudo, e o Customer Key tem limites claros. Ele criptografa dados em repouso na nuvem, mas não protege dados on-premises. Se você tem caixas postais ou arquivos locais, precisa de BitLocker ou outra solução separada. Fonte: visão geral do Customer Key, seção Customer Key with hybrid deployments ((abre em nova aba)).

Ele também não substitui o Customer Lockbox. Os dois são complementares: o Customer Key controla as chaves de criptografia, e o Customer Lockbox controla o acesso de engenheiros da Microsoft aos seus dados. Um não elimina a necessidade do outro. Fonte: visão geral do Customer Key ((abre em nova aba)).

E, por fim, a configuração e a gestão do Customer Key são operações sensíveis. A própria documentação da Microsoft alerta: erros com essas chaves podem causar interrupção de serviço ou perda permanente de dados. Não é um recurso para configurar sem planejamento, sem backup das chaves e sem entender a hierarquia de criptografia envolvida. Fonte: guia de configuração do Customer Key ((abre em nova aba)).

Para quem vale a penaLink para esta seção

O Customer Key faz sentido quando a organização tem requisitos regulatórios que exigem controle explícito sobre as chaves de criptografia, setor financeiro, saúde, governo, dados de pesquisa sujeitos a residência. Também faz sentido quando a política de governança de dados da empresa simplesmente determina que a Microsoft não pode ser a única detentora das chaves.

Para quem está começando, o caminho é: leia a visão geral no Microsoft Learn, confira o licenciamento, crie as assinaturas do Azure e os Key Vaults com soft delete e purge protection, registre as service principals e use o Customer Key Onboarding Service no modo Validate antes de ativar. Validar não custa nada e evita surpresas. Fonte: guia de configuração, seção Onboard using the Customer Key Onboarding Service ((abre em nova aba)).

Fontes consultadasLink para esta seção

1. Visão geral do Customer Key ((abre em nova aba))
2. Guia de configuração do Customer Key ((abre em nova aba))
3. Guia de gerenciamento do Customer Key ((abre em nova aba))
4. Documentação da availability key ((abre em nova aba))
5. Descrição de serviço do Microsoft Purview (licenciamento) ((abre em nova aba))