Fase de migração 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 Migração 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 Ative Directory para impedir que os computadores descubram sua infraestrutura local do Rights Management. Isso é opcional para os clientes existentes que você migrou 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 e 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, certifique-se de que iniciou sessão como administrador empresarial de domínio e, em seguida, utilize o seguinte procedimento:

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

  2. Clique na guia SCP .

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

  4. Selecione Remover SCP atual e clique em OK.

Agora monitorize a atividade dos seus servidores AD RMS. Por exemplo, verifique as solicitações no relatório Integridade do Sistema, na tabela ServiceRequest ou audite o acesso do usuário ao conteúdo protegido.

Quando tiver confirmado que os clientes RMS já não estão a comunicar com estes servidores e que os clientes estão a utilizar com êxito a Proteção de Informações do Azure, pode remover a função de servidor AD RMS destes servidores. Se você estiver usando servidores dedicados, talvez prefira a etapa cautelar de primeiro desligar os servidores por um período de tempo. Isso lhe dá tempo para garantir que não haja problemas relatados que possam exigir que você reinicie esses servidores para continuidade de serviço enquanto investiga por que os clientes não estão usando a Proteção de Informações do Azure.

Depois de desprovisionar os servidores AD RMS, aproveite a oportunidade para revisar o modelo e os 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 rótulos de sensibilidade e o cliente de rotulagem unificado, use o portal de conformidade do Microsoft Purview. Para obter mais informações, consulte a documentação do Microsoft 365.

Importante

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

Configuração adicional para computadores que executam o Office 2010

Importante

O suporte estendido do Office 2010 terminou em 13 de outubro de 2020. Para obter mais informações, consulte 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 que eles não têm credenciais para abrir conteúdo protegido. Para resolver esses problemas, crie um redirecionamento de rede para esses computadores, que redireciona o AD RMS URL FQDN para o endereço IP local do computador (127.0.0.1). Você pode fazer isso configurando o arquivo de hosts locais em cada computador ou usando o 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 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, que tenha o endereço IP 127.0.0.1.

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

Para clientes de dispositivos móveis e computadores Mac: remova os registos SRV DNS que criou quando implementou a extensão de dispositivo móvel 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 em cache as informações do AD RMS. Para esses computadores, esse processo pode levar até 30 dias.

Para forçar os computadores Mac a executar o processo de descoberta imediatamente, no porta-chaves, procure por "adal" e exclua todas as entradas ADAL. Em seguida, execute os seguintes comandos nestes computadores:


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 todos os seus computadores Windows existentes migraram para a Proteção de Informações do Azure, não há motivo para continuar a usar controles de integração e manter o grupo AIPMigrated que você criou para o processo de migração.

Remova os controles de integração primeiro e, em seguida, você pode excluir o grupo AIPMigrated e qualquer método de implantação de software que você criou 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 suas credenciais de administrador global:

    Connect-AipService

  2. Execute o seguinte comando e digite Y para confirmar:

    Set-AipServiceOnboardingControlPolicy -UseRmsUserLicense $False

    Observe que esse comando remove qualquer imposição de licença para o serviço de proteção do Azure Rights Management, para que todos os computadores 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 não há GUID exibido para o SecurityGroupOjbectId

Por fim, se você estiver usando o Office 2010 e tiver habilitado a tarefa Gerenciamento de Modelo de Política de Direitos do AD RMS (Automatizado) na biblioteca do Agendador de Tarefas do Windows, desabilite essa tarefa porque ela não é usada pelo cliente do Azure Information Protection.

Essa tarefa normalmente é habilitada usando a política de grupo e dá suporte a uma implantação do AD RMS. Você pode encontrar essa tarefa no seguinte local: Cliente do Microsoft>Windows>Ative Directory Rights Management Services.

Importante

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

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

Esta etapa é necessária quando a migração estiver concluída se a implantação do AD RMS estiver usando o Modo Criptográfico 1 do RMS, pois esse modo usa uma chave de 1024 bits e SHA-1. Considera-se que esta configuração oferece um nível de proteção inadequado. 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, que resulta em uma chave de 2048 bits e SHA-256.

Mesmo que sua implantação do AD RMS estivesse usando o Modo Criptográfico 2, ainda recomendamos que você faça esta etapa porque uma nova chave ajuda a proteger seu locatário de possíveis violações de segurança para sua chave AD RMS.

Quando você rechave sua chave de locatário da Proteção de Informações do Azure (também conhecida como "rolar sua chave"), a chave atualmente ativa é arquivada e a Proteção de Informações do Azure começa a usar uma chave diferente que você especifica. Essa chave diferente pode ser uma nova chave que você cria no Cofre de Chaves do Azure ou a chave padrão que foi 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 da sua chave original, mas faça esta etapa assim que a migração for concluída.

Para rechavear sua chave 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 que foi 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, para que você possa 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 Cofre da Chave do Azure, repita o processo de criação de chaves para seu locatário da Proteção de Informações do Azure e execute o cmdlet Use-AipServiceKeyVaultKey novamente para especificar o URI dessa nova chave.

Para obter 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óximos passos

Agora que você concluiu a migração, revise o roteiro de implantação do AIP para classificação, rotulagem e proteção para identificar quaisquer outras tarefas de implantação que você possa precisar fazer.