Compartilhar via

Gerenciado pelo cliente: operações de ciclo de vida da chave de locatário

  • Artigo

Observação

Está procurando pela Proteção de Informações do Microsoft Purview, conhecida anteriormente como MIP (Proteção de Informações da Microsoft)?

O suplemento Proteção de Informações do Azure é desativado e substituído por rótulos internos aos seus aplicativos e serviços do Microsoft 365. Saiba mais sobre o status de suporte de outros componentes da Proteção de Informações do Azure.

O cliente Microsoft Purview Information Protection (sem o suplemento) está disponível para o público em geral.

Se você gerenciar a chave de locatário para a Proteção de Informações do Azure (o cenário Bring Your Own Key, ou BYOK), use as seções a seguir para obter mais informações sobre as operações do ciclo de vida relevantes para essa topologia.

Revogar a chave de locatário

Há muito poucos cenários em que é possível precisar revogar a chave em vez de rechavear. Quando você revoga a chave, todo o conteúdo que foi protegido pelo locatário usando essa chave ficará inacessível para todos (incluindo a Microsoft, seus administradores globais e superusuários), a menos que você tenha um backup da chave que possa restaurar. Depois de revogar sua chave, não será possível proteger novo conteúdo até criar e configurar uma nova chave de locatário para a Proteção de Informações do Azure.

Para revogar a chave de locatário gerenciada pelo cliente, no Azure Key Vault, altere as permissões no cofre de chaves que contém a chave de locatário da Proteção de Informações do Azure para que o serviço Azure Rights Management não possa mais acessar a chave. Essa ação efetivamente revoga a chave de locatário para a Proteção de Informações do Azure.

Ao cancelar a assinatura da Proteção de Informações do Azure, a Proteção de Informações do Azure para de usar sua chave de locatário e nenhuma ação é necessária de sua parte.

Rechavear a chave de locatário

O rechaveamento também é conhecido como rotação de chaves. Ao realizar essa operação, a Proteção de Informações do Azure para de usar a chave de locatário existente para proteger documentos e emails e começa a usar uma chave diferente. As políticas e os modelos são resignados imediatamente, mas, para clientes e serviços existentes que usam a Proteção de Informações do Azure, essa mudança é gradual. Portanto, por um período, alguns novos conteúdos continuam a ser protegidos com a chave de locatário antiga.

Para rechavear, é necessário configurar o objeto chave do locatário e especificar a chave alternativa a ser usada. Em seguida, a chave usada anteriormente é marcada automaticamente como arquivada para a Proteção de Informações do Azure. Essa configuração garante que o conteúdo protegido por essa chave permaneça acessível.

Exemplos de quando pode ser necessário rechavear para a Proteção de Informações do Azure:

  • Sua empresa foi dividida em duas ou mais empresas. Quando você rechavear a chave de locatário, a nova empresa não terá acesso ao novo conteúdo que os funcionários publicarem. Eles podem acessar o conteúdo antigo se tiverem uma cópia da chave de locatário antiga.

  • Você deseja migrar de uma topologia de gerenciamento de chaves para outra.

  • Você acredita que a cópia mestra da chave de locatário (a cópia em sua posse) está comprometida.

Para rechavear para outra chave que você gerencia, é possível criar uma nova chave no Azure Key Vault ou usar uma chave diferente que já esteja no Azure Key Vault. Em seguida, siga os mesmos procedimentos que você fez para implementar o BYOK para a Proteção de Informações do Azure.

  1. Somente se a nova chave estiver em um cofre de chaves diferente daquele que você já está usando para a Proteção de Informações do Azure: Autorize a Proteção de Informações do Azure a usar o cofre de chaves, usando o cmdlet Set-AzKeyVaultAccessPolicy.

  2. Se a Proteção de Informações do Azure ainda não souber sobre a chave que você deseja usar, execute o cmdlet Use-AipServiceKeyVaultKey.

  3. Configure o objeto de chave do locatário usando o cmdlet Set-AipServiceKeyProperties.

Para obter mais informações sobre cada uma dessas etapas:

Fazer backup e recuperar a chave de locatário

Como você está gerenciando a chave de locatário, você é responsável por fazer backup da chave que a Proteção de Informações do Azure usa.

Se você gerou a chave de locatário no local, em um HSM nCipher: para fazer backup da chave, faça backup do arquivo de chave tokenizada, do arquivo mundial e dos cartões de administrador. Quando você transfere a chave para o Azure Key Vault, o serviço salva o arquivo de chave tokenizado para proteger contra falhas de qualquer nó de serviço. Esse arquivo está vinculado ao universo de segurança para a região ou instância específica do Azure. No entanto, não considere esse arquivo de chave tokenizado como um backup completo. Por exemplo, se você precisar de uma cópia de texto sem formatação de sua chave para usar fora de um HSM nCipher, o Azure Key Vault não poderá recuperá-la para você, porque ele tem apenas uma cópia não recuperável.

O Azure Key Vault tem um cmdlet de backup que é possível usar para fazer backup de uma chave baixando-a e armazenando-a em um arquivo. Como o conteúdo baixado é criptografado, ele não pode ser usado fora do Azure Key Vault.

Exportar a chave de locatário

Se você usar o BYOK, não poderá exportar a chave de locatário do Azure Key Vault ou da Proteção de Informações do Azure. A cópia no Azure Key Vault não é recuperável.

Responder a uma violação

Nenhum sistema de segurança, por mais forte que seja, está completo sem um processo de resposta a violações. A chave de locatário pode ser comprometida ou roubada. Mesmo quando bem protegida, vulnerabilidades podem ser encontradas na tecnologia de chave da geração atual ou nos comprimentos de chave e algoritmos atuais.

A Microsoft tem uma equipe dedicada para responder a incidentes de segurança em seus produtos e serviços. Quando há um relatório confiável de um incidente, essa equipe se empenha em investigar o escopo, a causa raiz e as mitigações. Se esse incidente afetar os ativos, a Microsoft notificará os administradores globais do locatário por email.

Se houver uma violação, a melhor ação que você ou a Microsoft podem tomar depende do escopo da violação; a Microsoft ajudará você durante esse processo. A tabela a seguir mostra algumas situações típicas e a resposta provável, embora a resposta exata dependa das informações reveladas durante a investigação.

Descrição do incidente Resposta provável
A chave de locatário foi vazada. Rechaveie a chave de locatário. Consulte Rechaveie a chave de locatário.
Um indivíduo não autorizado ou malware obteve direitos para usar a chave de locatário, mas a chave em si não foi vazada. Rechavear a chave de locatário não ajuda nesta situação e requer análise da causa raiz. Se um bug no processo ou no software foi responsável pelo acesso do indivíduo não autorizado, essa situação deve ser resolvida.
Vulnerabilidade descoberta na tecnologia HSM de geração atual. A Microsoft deve atualizar os HSMs. Se houver motivos para acreditar que a vulnerabilidade expôs chaves, a Microsoft instruirá todos os clientes a rechavear as chaves de locatário.
A vulnerabilidade descoberta no algoritmo RSA, o comprimento da chave ou os ataques de força bruta se tornam computacionalmente viáveis. A Microsoft deve atualizar o Azure Key Vault ou a Proteção de Informações do Azure para oferecer suporte a novos algoritmos e comprimentos de chave mais longos que sejam resilientes, além de instruir todos os clientes a rechavear a chave de locatário.