Fase 5 – tarefas pós-migração

  • Artigo

Use as informações a seguir para a fase 5 da migração do AD RMS para a Proteção de Informações do Azure. Esses procedimentos abrangem as etapas 10 a 12 de Migrar do AD RMS para a Proteção de Informações do Azure.

Etapa 10: Desprovisionar o AD RMS

Remova o SCP (Ponto de Conexão de Serviço) do Active Directory para impedir que as máquinas descubram sua infraestrutura local do Rights Management. Isso é opcional para os clientes existentes migrados devido ao redirecionamento que você configurou no Registro (por exemplo, executando o script de migração). No entanto, a remoção do SCP impede que novos clientes, serviços e ferramentas potencialmente relacionados ao RMS encontrem o SCP quando a migração for concluída. Neste ponto, todas as conexões de computador devem ir para o serviço Azure Rights Management.

Para remover o SCP, verifique se você está conectado como um administrador corporativo de domínio e use o seguinte procedimento:

  1. No console do Active Directory Rights Management Services, clique com o botão direito do mouse no cluster do AD RMS e clique em Properties.

  2. Clique na guia SCP.

  3. Marque a caixa de seleção Alterar SCP.

  4. Selecione Remove Current SCP e clique em OK.

Agora, monitore a atividade dos seus servidores AD RMS. Por exemplo, verifique as solicitações no relatório de integridade do sistema, na tabela ServiceRequest ou analise o acesso do usuário ao conteúdo protegido.

Depois de confirmar que os clientes do RMS não estão mais se comunicando com esses servidores e que os clientes estão usando com sucesso a Proteção de Informações do Azure, você pode remover a função de servidor AD RMS desses servidores. Se estiver usando servidores dedicados, talvez você prefira a etapa de precaução de primeiro desligar os servidores por um período de tempo. Isso oferece tempo para garantir que não haja problemas relatados que possam exigir a reinicialização desses servidores para continuidade do serviço enquanto você investiga por que os clientes não estão usando a Proteção de Informações do Azure.

Depois de desprovisionar seus servidores AD RMS, convém aproveitar a oportunidade para revisar seu modelo e rótulos. Por exemplo, converta modelos em rótulos, consolide-os para que os usuários tenham menos opções ou reconfigure-os. Este também seria um bom momento para publicar modelos padrão.

Para os rótulos de confidencialidade e o cliente de rotulagem unificada, use o portal de conformidade do Microsoft Purview. Para obter mais informações, confira a documentação do Microsoft 365.

Importante

No final dessa migração, seu cluster do AD RMS não pode ser usado com a Proteção de Informações do Azure e a opção de manter sua própria chave (HYOK).

Configuração adicional para máquinas com o Office 2010

Importante

O suporte estendido do Office 2010 terminou em 13 de outubro de 2020. Para obter mais informações, confira AIP e versões herdadas do Windows e do Office.

Se os clientes migrados executarem o Office 2010, os usuários poderão enfrentar atrasos na abertura de conteúdo protegido depois que nossos servidores AD RMS forem desprovisionados. Ou, os usuários podem ver mensagens indicando que eles não têm credenciais para abrir conteúdo protegido. Para resolver esses problemas, crie um redirecionamento de rede para essas máquinas, que redirecione o AD RMS URL FQDN para o endereço IP local da máquina (127.0.0.1). Você pode fazer isso configurando o arquivo de hosts locais em cada máquina ou usando DNS.

  • Redirecionamento via arquivo de hosts locais: adicione a seguinte linha no arquivo de hosts locais, substituindo <AD RMS URL FQDN> pelo valor do cluster do AD RMS, sem prefixos ou páginas da web:

    127.0.0.1 <AD RMS URL FQDN>

  • Redirecionamento via DNS: crie um novo registro de host (A) para seu AD RMS URL FQDN, com o endereço IP 127.0.0.1.

Etapa 11: Concluir tarefas de migração do cliente

Para clientes de dispositivos móveis e computadores Mac: remova os registros SRV DNS criados quando você implantou a extensão para dispositivos móveis do AD RMS.

Quando essas alterações de DNS forem propagadas, esses clientes descobrirão automaticamente e começarão a usar o serviço Azure Rights Management. No entanto, os computadores Mac que executam o Office Mac armazenam as informações do AD RMS em cache. Para esses computadores, esse processo pode levar até 30 dias.

Para forçar os computadores Mac a executar o processo de descoberta imediatamente, no keychain, procure "ADAL" e exclua todas as entradas ADAL. Execute os comandos a seguir nessas máquinas:


rm -r ~/Library/Cache/MSRightsManagement

rm -r ~/Library/Caches/com.microsoft.RMS-XPCService

rm -r ~/Library/Caches/Microsoft\ Rights\ Management\ Services

rm -r ~/Library/Containers/com.microsoft.RMS-XPCService

rm -r ~/Library/Containers/com.microsoft.RMSTestApp

rm ~/Library/Group\ Containers/UBF8T346G9.Office/DRM.plist

killall cfprefsd

Quando todas as máquinas Windows existentes tiverem migrado para a Proteção de Informações do Azure, não haverá razão para continuar a usar controles de integração e manter o grupo AIPMigrated que você criou para o processo de migração.

Primeiro remova os controles de integração e, em seguida, exclua o grupo AIPMigrated e outro método de implantação de software criado para implantar os scripts de migração.

Para remover os controles de integração:

  1. Em uma sessão do PowerShell, conecte-se ao serviço Azure Rights Management e, quando solicitado, especifique as credenciais de administrador global:

    Connect-AipService

  2. Execute o comando a seguir e insira Y para confirmar:

    Set-AipServiceOnboardingControlPolicy -UseRmsUserLicense $False

    Observe que esse comando remove imposições de licença para o serviço de proteção do Azure Rights Management, para que todas as máquinas possam proteger documentos e emails.

  3. Confirme se os controles de integração não estão mais definidos:

    Get-AipServiceOnboardingControlPolicy

    Na saída, License deve mostrar False, e nenhum GUID deve ser exibido para o SecurityGroupOjbectId

Por fim, se estiver usando o Office 2010 e tiver habilitado a tarefa de Gerenciamento de Modelo de Política de Direitos do AD RMS (Automatizado) na biblioteca do Agendador de Tarefas do Windows, desabilite essa tarefa, pois ela não é usada pelo cliente da Proteção de Informações do Azure.

Essa tarefa geralmente é habilitada usando a política de grupo e é compatível com a uma implantação do AD RMS. Você encontra essa tarefa no seguinte local: Cliente do Microsoft>Windows>Active Directory Rights Management Services.

Importante

O suporte estendido do Office 2010 terminou em 13 de outubro de 2020. Para obter mais informações, confira AIP e versões herdadas do Windows e do Office.

Etapa 12: rechavear as chave de locatário da Proteção de Informações do Azure

Esta etapa é necessária quando a migração for concluída se a implantação do AD RMS usar o Modo Criptográfico 1 do RMS, pois esse modo usa uma chave de 1024 bits e SHA-1. Considera-se que essa configuração oferece um nível inadequado de proteção. A Microsoft não endossa o uso de comprimentos de chave mais baixos, como chaves RSA de 1024 bits, e o uso associado de protocolos que oferecem níveis inadequados de proteção, como SHA-1.

A rechaveamento resulta em proteção que usa o Modo Criptográfico RMS 2, retornando uma chave de 2048 bits e SHA-256.

Mesmo que sua implantação do AD RMS use o Modo Criptográfico 2, ainda recomendamos esta etapa, pois uma nova chave ajuda a proteger seu locatário de possíveis violações de segurança à sua chave do AD RMS.

Ao recodificar sua chave de locatário da Proteção de Informações do Azure (também conhecida como "rolar sua chave"), a chave ativa atualmente é arquivada e a Proteção de Informações do Azure começa a usar uma chave diferente especificada por você. Essa chave diferente pode ser uma nova chave criada no Azure Key Vault ou a chave padrão criada automaticamente para seu locatário.

A mudança de uma chave para outra não acontece imediatamente, mas ao longo de algumas semanas. Como não é imediato, não espere até suspeitar de uma violação na chave original. Faça essa etapa assim que a migração for concluída.

Para fazer o rechaveamento de locatário da Proteção de Informações do Azure:

  • Se sua chave de locatário for gerenciada pela Microsoft: execute o cmdlet do PowerShell Set-AipServiceKeyProperties e especifique o identificador de chave para a chave criada automaticamente para seu locatário. Você pode identificar o valor a ser especificado executando o cmdlet Get-AipServiceKeys. A chave que foi criada automaticamente para seu locatário tem a data de criação mais antiga, portanto, você pode identificá-la usando o seguinte comando:

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

  • Se sua chave de locatário for gerenciada por você (BYOK): no Azure Key Vault, repita o processo de criação de chave para seu locatário da Proteção de Informações do Azure e execute o cmdlet Use-AipServiceKeyVaultKey novamente para especificar o URI para essa nova chave.

Para mais informações sobre como gerenciar sua chave de locatário da Proteção de Informações do Azure, consulte Operações para sua chave de locatário da Proteção de Informações do Azure.

Próximas etapas

Agora que você concluiu a migração, revise o roteiro de implantação do AIP para classificação, rotulagem e proteção para identificar outras tarefas de implantação que talvez sejam necessárias.