Share via

Gerenciado pela Microsoft: 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 a Microsoft gerenciar sua chave de locatário para a Proteção de Informações do Azure (o padrão), use as seções a seguir para obter mais informações sobre as operações do ciclo de vida que são relevantes para essa topologia.

Revogar a chave de locatário

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:

  • Você migrou do AD RMS (Active Directory Rights Management Services) com uma chave de modo criptográfico 1. Quando a migração estiver concluída, você deseja alterar para uma chave que use o modo criptográfico 2.

  • 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 está comprometida.

Para rechavear, é possível selecionar uma chave gerenciada pela Microsoft diferente para se tornar a chave de locatário, mas não é possível criar uma nova chave gerenciada pela Microsoft. Para criar uma nova chave, é necessário alterar a topologia de chave para ser gerenciada pelo cliente (BYOK).

Você terá mais de uma chave gerenciada pela Microsoft se tiver migrado do AD RMS (Active Directory Rights Management Services) e tiver escolhido a topologia de chave gerenciada pela Microsoft para a Proteção de Informações do Azure. Nesse cenário, você tem pelo menos duas chaves gerenciadas pela Microsoft para o locatário. Uma chave, ou mais, é a chave ou as chaves que você importou do AD RMS. Você também terá a chave padrão criada automaticamente para o locatário da Proteção de Informações do Azure.

Para selecionar uma chave diferente para ser a chave de locatário ativa para a Proteção de Informações do Azure, use o cmdlet Set-AipServiceKeyProperties do módulo AIPService. Para ajudar na identificação de qual chave usar, use o cmdlet Get-AipServiceKeys. É possível identificar a chave padrão criada automaticamente para o locatário da Proteção de Informações do Azure executando o seguinte comando:

(Get-AipServiceKeys) | Sort-Object CreationTime | Select-Object -First 1

Para alterar a topologia de chave para ser gerenciada pelo cliente (BYOK), confira Planejamento e implementação da sua chave de locatário da Proteção de Informações do Azure.

Fazer backup e recuperar a chave de locatário

A Microsoft é responsável por efetuar backup da chave de locatário e nenhuma ação é necessária de sua parte.

Exportar a chave de locatário

É possível exportar a configuração e a chave de locatário da Proteção de Informações do Azure seguindo as instruções nas três etapas a seguir:

Etapa 1: Iniciar a exportação

  • Entre em contato com o Suporte da Microsoft para abrir um caso de suporte da Proteção de Informações do Azure com uma solicitação de exportação de chave da Proteção de Informações do Azure. Você deve provar que é um administrador global do locatário e entender que esse processo leva vários dias para ser confirmado. Aplicam-se taxas de Suporte Standard; exportar a chave de locatário não é um serviço de suporte gratuito.

Etapa 2: Aguardar a verificação

  • A Microsoft verifica se a solicitação para liberar a chave de locatário da Proteção de Informações do Azure é legítima. Esse processo pode levar até três semanas.

Etapa 3: Receber instruções de chave do CSS

  • O CSS (Serviços de Atendimento ao Cliente) da Microsoft envia a configuração e a chave de locatário da Proteção de Informações do Azure criptografadas em um arquivo protegido por senha. Esse arquivo tem uma extensão do nome de arquivo .tpd. Para fazer isso, o CSS primeiro envia a você (como a pessoa que iniciou a exportação) uma ferramenta por e-mail. Você deve executar a ferramenta em um prompt de comando da seguinte maneira:

    AadrmTpd.exe -createkey

    Isso gera um par de chaves RSA e salva as metades públicas e privadas como arquivos na pasta atual. Por exemplo: PublicKey-FA29D0FE-5049-4C8E-931B-96C6152B0441.txt e PrivateKey-FA29D0FE-5049-4C8E-931B-96C6152B0441.txt.

    Responda ao e-mail do CSS, anexando o arquivo em que o nome começa com PublicKey. Em seguida, o CSS envia um arquivo TPD como um arquivo .xml criptografado com a chave RSA. Copie esse arquivo para a mesma pasta que você executou a ferramenta AadrmTpd originalmente e execute a ferramenta novamente, usando o arquivo que começa com PrivateKey e o arquivo do CSS. Por exemplo:

    AadrmTpd.exe -key PrivateKey-FA29D0FE-5049-4C8E-931B-96C6152B0441.txt -target TPD-77172C7B-8E21-48B7-9854-7A4CEAC474D0.xml

    A saída desse comando deve ser dois arquivos: um contém a senha de texto sem formatação para o TPD protegido por senha e o outro é o próprio TPD protegido por senha. Os arquivos têm um novo GUID, por exemplo:

    • Password-5E4C2018-8C8C-4548-8705-E3218AA1544E.txt

    • ExportedTPD-5E4C2018-8C8C-4548-8705-E3218AA1544E.xml

      Efetue backup desses arquivos e armazene-os com segurança para garantir que você possa continuar a descriptografar o conteúdo protegido com essa chave de locatário. Além disso, se você estiver migrando para o AD RMS, poderá importar esse arquivo TPD (o arquivo que começa com ExportedTDP) para o servidor do AD RMS.

Etapa 4: Em andamento: proteger a chave de locatário

Depois de receber a chave de locatário, mantenha-a bem protegida, porque se alguém tiver acesso a ela, poderá descriptografar todos os documentos que são protegidos por ela.

Se o motivo para exportar a chave de locatário for porque você não deseja mais usar a Proteção de Informações do Azure, como uma melhor prática, desative agora o serviço Azure Rights Management do locatário da Proteção de Informações do Azure. Não demore a fazer isso depois de receber a chave de locatário, pois essa precaução ajuda a minimizar as consequências se a chave de locatário for acessada por alguém que não deveria ter acesso a ela. Para obter instruções, confira Encerramento e desativação do Azure Rights Management.

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. Confira a seção Rechavear a chave de locatário neste artigo.
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.
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 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.