Fase de migração 2: configuração do lado do servidor para AD RMS

Artigo
01/04/2024

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

Etapa 4: exportar dados de configuração do AD RMS e importá-los para a Proteção de Informações do Azure

Esta etapa é um processo de duas partes:

Exporte os dados de configuração do AD RMS exportando os TPDs (domínios de publicação confiáveis) para um arquivo .xml. Esse processo é igual para todas as migrações.
Importe os dados de configuração para a Proteção de Informações do Azure. Há diferentes processos para esta etapa, dependendo da configuração de implantação atual do AD RMS e da topologia preferida para a chave de locatário do Azure RMS.

Exportar os dados de configuração do AD RMS

Execute o procedimento a seguir em todos os clusters do AD RMS, para todos os domínios de publicação confiáveis que têm conteúdo protegido para sua organização. Você não precisa executar este procedimento em clusters somente de licenciamento.

Como exportar os dados de configuração (informações de domínio de publicação confiável)

Faça logon no cluster do AD RMS como um usuário com permissões de administração do AD RMS.
No console de gerenciamento do AD RMS (Active Directory Rights Management Services), expanda o nome do cluster do AD RMS, expanda Políticas de Confiança e clique em Domínios de Publicação Confiáveis.
No painel de resultados, selecione o domínio de publicação confiável e, no painel Ações, clique em Exportar Domínio de Publicação Confiável.
Na caixa de diálogo Exportar Domínio de Publicação Confiável:
- Clique em Salvar como e salve no caminho e com um nome de arquivo de sua escolha. Especifique .xml como a extensão do nome de arquivo (isso não é acrescentado automaticamente).
- Especifique e confirme uma senha forte. Lembre-se dessa senha, porque você precisará dela mais tarde, quando importar os dados de configuração para a Proteção de Informações do Azure.
- Não marque a caixa de seleção para salvar o arquivo de domínio confiável no RMS versão 1.0.

Depois de exportar todos os domínios de publicação confiáveis, você poderá iniciar o procedimento para importar esses dados para a Proteção de Informações do Azure.

Observe que os domínios de publicação confiáveis incluem as chaves SLC (Certificado de Licenciante para Servidor) para descriptografar arquivos protegidos anteriormente, portanto, é importante que você exporte (e depois importe para o Azure) todos os domínios de publicação confiáveis e não apenas o que está ativo no momento.

Por exemplo, você terá vários domínios de publicação confiáveis se tiver atualizado os servidores do AD RMS do modo criptográfico 1 para o modo criptográfico 2. Se você não exportar e importar o domínio de publicação confiável que contém a chave arquivada que usou o modo criptográfico 1, no final da migração, os usuários não poderão abrir o conteúdo protegido com a chave do modo criptográfico 1.

Importar os dados de configuração para a Proteção de Informações do Azure

Os procedimentos exatos para esta etapa dependem da configuração de implantação atual do AD RMS e da topologia preferencial da chave de locatário da Proteção de Informações do Azure.

A implantação atual do AD RMS está usando uma das seguintes configurações para a chave de SLC:

Proteção de senha no banco de dados do AD RMS. Essa é a configuração padrão.
Proteção por HSM usando um HSM (Módulo de Segurança de Hardware) nCipher.
Proteção por HSM usando um HSM (Módulo de Segurança de Hardware) de um fornecedor diferente do nCipher.
Protegido por senha usando um provedor criptográfico externo.

Observação

Para obter mais informações sobre como usar módulos de segurança de hardware com o AD RMS, confira Usando o AD RMS com módulos de segurança de hardware.

As duas opções de topologia de chave de locatário da Proteção de Informações do Azure são: a Microsoft gerencia a chave de locatário (gerenciada pela Microsoft) ou você gerencia a chave de locatário (gerenciada pelo cliente) no Azure Key Vault. Quando você gerencia sua própria chave de locatário da Proteção de Informações do Azure, às vezes ela é designada como BYOK (Bring Your Own Key). Para obter mais informações, confira o artigo Planejamento e implementação da sua chave de locatário da Proteção de Informações do Azure.

Use a tabela a seguir para identificar qual procedimento usar para a migração.

Implantação atual do AD RMS	Topologia de chave de locatário da Proteção de Informações do Azure escolhida	Instruções de migração
Proteção de senha no banco de dados do AD RMS	gerenciada pela Microsoft	Confira o procedimento de migração de chave protegida por software para chave protegida por software após esta tabela. Este é o caminho de migração mais simples e requer apenas a tranferência dos dados de configuração para a Proteção de Informações do Azure.
Proteção por HSM usando um módulo de segurança de hardware (HSM) nCipher nShield	Gerenciado pelo cliente (BYOK)	Confira o procedimento de migração de chave protegida por HSM para chave protegida por HSM após esta tabela. Isso requer o conjunto de ferramentas BYOK do Azure Key Vault e três conjuntos de etapas para primeiro transferir a chave do HSM local para os HSMs do Azure Key Vault, depois autorizar o serviço Azure Rights Management da Proteção de Informações do Azure para usar a chave de locatário e, finalmente, transferir os dados de configuração para a Proteção de Informações do Azure.
Proteção de senha no banco de dados do AD RMS	Gerenciado pelo cliente (BYOK)	Confira o procedimento de migração de chave protegida por software para chave protegida por HSM após esta tabela. Isso requer o conjunto de ferramentas BYOK do Azure Key Vault e quatro conjuntos de etapas para primeiro extrair a chave de software e importá-la para um HSM local, depois transferir a chave do HSM local para os HSMs da Proteção de Informações do Azure, transferir os dados do cofre de chaves para a Proteção de Informações do Azure e, por fim, transferir os dados de configuração para a Proteção de Informações do Azure.
Proteção por HSM usando um HSM (Módulo de Segurança de Hardware) de um fornecedor diferente do nCipher	Gerenciado pelo cliente (BYOK)	Entre em contato com o fornecedor do HSM para obter instruções sobre como transferir a chave deste HSM para um módulo de segurança de hardware (HSM) nCipher nShield. Em seguida, siga as instruções para o procedimento de migração de chave protegida por HSM para chave protegida por HSM após esta tabela.
Protegido por senha usando um provedor criptográfico externo	Gerenciado pelo cliente (BYOK)	Entre em contato com o fornecedor do provedor criptográfico para obter instruções sobre como transferir a chave para um módulo de segurança de hardware (HSM) nCipher nShield. Em seguida, siga as instruções para o procedimento de migração de chave protegida por HSM para chave protegida por HSM após esta tabela.

Se você tiver uma chave protegida por HSM que não pode exportar, ainda poderá migrar para a Proteção de Informações do Azure configurando o cluster do AD RMS para um modo somente leitura. Nesse modo, o conteúdo protegido anteriormente ainda pode ser aberto, mas o conteúdo recém-protegido usa uma nova chave de locatário gerenciada por você (BYOK) ou gerenciada pela Microsoft. Para obter mais informações, confira Há uma atualização disponível para o Office oferecer suporte a migrações de AD RMS para Azure RMS.

Antes de iniciar esses procedimentos de migração de chaves, verifique se você pode acessar os arquivos .xml criados anteriormente quando exportou os domínios de publicação confiáveis. Por exemplo, eles podem ser salvos em um pen drive USB que você migra do servidor do AD RMS para a estação de trabalho conectada à Internet.

Observação

Independentemente de como você armazena esses arquivos, use as melhores práticas de segurança para protegê-los, pois esses dados incluem a chave privada.

Para concluir a Etapa 4, escolha e selecione as instruções para o caminho de migração:

Etapa 5: Ativar o serviço Azure Rights Management

Abra uma sessão do PowerShell e execute os seguintes comandos:

Conecte-se ao serviço Azure Rights Management e, quando solicitado, especifique as credenciais de administrador global:
```
Connect-AipService
```
Ative o serviço Azure Rights Management:
```
Enable-AipService
```

E se o locatário da Proteção de Informações do Azure já estiver ativado? Se o serviço Azure Rights Management já estiver ativado para a organização e você tiver criado modelos personalizados que deseja usar após a migração, exporte e importe esses modelos. Esse procedimento é abordado na próxima etapa.

Etapa 6: Configurar modelos importados

Como os modelos que você importou têm um estado padrão de Arquivado, você deve alterar esse estado para Publicado se quiser que os usuários possam usar esses modelos com o serviço Azure Rights Management.

Os modelos importados do AD RMS têm a mesma aparência e comportamento dos modelos personalizados que você pode criar no portal do Azure. Para alterar os modelos importados a serem publicados para que os usuários possam vê-los e selecioná-los em aplicativos, confira Configurar e gerenciar modelos da Proteção de Informações do Azure.

Além de publicar os modelos recém-importados, há apenas duas alterações importantes para os modelos que talvez você precise fazer antes de continuar com a migração. Para obter uma experiência mais consistente para os usuários durante o processo de migração, não faça alterações adicionais nos modelos importados e não publique os dois modelos padrão que vêm com a Proteção de Informações do Azure ou crie novos modelos no momento. Em vez disso, aguarde até que o processo de migração seja concluído e você tenha desprovisionado os servidores do AD RMS.

As alterações de modelo que talvez você precise fazer nesta etapa:

Se você criou modelos personalizados da Proteção de Informações do Azure antes da migração, deverá exportá-los e importá-los manualmente.
Se os modelos no AD RMS usaram o grupo ANYONE, talvez seja necessário adicionar usuários ou grupos manualmente.

No AD RMS, o grupo ANYONE concedeu direitos a todos os usuários autenticados pelo Active Directory local, e esse grupo não tem suporte na Proteção de Informações do Azure. O equivalente mais próximo é um grupo criado automaticamente para todos os usuários no locatário do Microsoft Entra. Se você estava usando o grupo ANYONE para os modelos do AD RMS, talvez seja necessário adicionar usuários e os direitos que deseja conceder a eles.

Procedimento se você criou modelos personalizados antes da migração

Se você criou modelos personalizados antes da migração, antes ou depois de ativar o serviço Azure Rights Management, os modelos não estarão disponíveis para os usuários após a migração, mesmo que tenham sido definidos como Publicados. Para disponibilizá-los aos usuários, é necessário primeiro fazer o seguinte:

Identifique esses modelos e anote a ID de modelo, executando o Get-AipServiceTemplate.
Exporte os modelos usando o cmdlet do PowerShell do Azure RMS, Export-AipServiceTemplate.
Importe os modelos usando o cmdlet do PowerShell do Azure RMS, Import-AipServiceTemplate.

Em seguida, você pode publicar ou arquivar esses modelos como faria com qualquer outro modelo criado após a migração.

Procedimento se os modelos no AD RMS usaram o grupo ANYONE

Se os modelos no AD RMS usaram o grupo ANYONE, o grupo equivalente mais próximo na Proteção de Informações do Azure é chamado AllStaff-7184AB3F-CCD1-46F3-8233-3E09E9CF0E66@<tenant_name>.onmicrosoft.com. Por exemplo, esse grupo pode ter a seguinte aparência para Contoso: AllStaff-7184AB3F-CCD1-46F3-8233-3E09E9CF0E66@contoso.onmicrosoft.com. Esse grupo contém todos os usuários do locatário do Microsoft Entra.

Quando você gerencia modelos e rótulos no portal do Azure, esse grupo é exibido como o nome de domínio do locatário no Microsoft Entra ID. Por exemplo, esse grupo pode ter a seguinte aparência para Contoso: contoso.onmicrosoft.com. Para adicionar esse grupo, a opção exibe Adicionar <nome da organização> – Todos os membros.

Se você não tiver certeza se os modelos do AD RMS incluem o grupo ANYONE, poderá usar o script de exemplo do Windows PowerShell a seguir para identificar esses modelos. Para obter mais informações sobre como usar o Windows PowerShell com o AD RMS, confira Como usar o Windows PowerShell para administrar o AD RMS.

Você pode adicionar facilmente usuários externos a modelos ao converter esses modelos em rótulos no portal do Azure. Em seguida, no painel Adicionar permissões, selecione Inserir detalhes para especificar manualmente os endereços de email desses usuários.

Para obter mais informações sobre essa configuração, confira Como configurar um rótulo para a proteção do Rights Management.

Script de exemplo do Windows PowerShell para identificar modelos do AD RMS que incluem o grupo ANYONE

Esta seção contém o script de exemplo para ajudar você a identificar modelos do AD RMS que tenham o grupo ANYONE definido, conforme descrito na seção anterior.

Aviso de isenção de responsabilidade: não há suporte para esse script de exemplo em nenhum serviço ou programa de suporte Standard da Microsoft. Esse script de exemplo é fornecido no estado em que se encontra, sem garantias de nenhum tipo.

import-module adrmsadmin

New-PSDrive -Name MyRmsAdmin -PsProvider AdRmsAdmin -Root https://localhost -Force

$ListofTemplates=dir MyRmsAdmin:\RightsPolicyTemplate

foreach($Template in $ListofTemplates)
{
                $templateID=$Template.id

                $rights = dir MyRmsAdmin:\RightsPolicyTemplate\$Templateid\userright

     $templateName=$Template.DefaultDisplayName

        if ($rights.usergroupname -eq "anyone")

                         {
                           $templateName = $Template.defaultdisplayname

                           write-host "Template " -NoNewline

                           write-host -NoNewline $templateName -ForegroundColor Red

                           write-host " contains rights for " -NoNewline

                           write-host ANYONE  -ForegroundColor Red
                         }
 }
Remove-PSDrive MyRmsAdmin -force

Próximas etapas

Acesse Fase 3: configuração no lado do cliente.