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

Artigo
10/18/2023

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 Migração 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 em duas partes:

Exporte os dados de configuração do AD RMS exportando os domínios de publicação confiáveis (TPDs) para um arquivo .xml. Este processo é o mesmo para todas as migrações.
Importe os dados de configuração para a Proteção de Informações do Azure. Há processos diferentes para esta etapa, dependendo da configuração atual de implantação do AD RMS e da topologia preferida da 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 AD RMS, para todos os domínios de publicação confiáveis que tenham conteúdo protegido para sua organização. Não é necessário executar este procedimento em clusters somente de licenciamento.

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

Faça logon no cluster AD RMS como um usuário com permissões de administração do AD RMS.
No console de gerenciamento do AD RMS (Ative Directory Rights Management Services), expanda o nome do cluster AD RMS, expanda Diretivas 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 em um nome de arquivo de sua escolha. Certifique-se de especificar .xml como a extensão de nome de arquivo (isso não é anexado 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 selecione a caixa de verificação para guardar o ficheiro de domínio fidedigno no RMS versão 1.0.

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

Observe que os domínios de publicação confiáveis incluem as chaves do Certificado de Licenciante de Servidor (SLC) 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 atualmente ativo.

Por exemplo, você terá vários domínios de publicação confiáveis se tiver atualizado seus servidores 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 sua configuração de implantação atual do AD RMS e da sua topologia preferida para sua chave de locatário da Proteção de Informações do Azure.

Sua implantação atual do AD RMS está usando uma das seguintes configurações para sua chave de certificado de licenciante de servidor (SLC):

Proteção por senha no banco de dados AD RMS. Esta é a configuração predefinida.
Proteção HSM usando um módulo de segurança de hardware (HSM) nCipher.
Proteção HSM usando um módulo de segurança de hardware (HSM) de um fornecedor diferente do nCipher.
Protegido por senha usando um provedor criptográfico externo.

Nota

Para obter mais informações sobre como usar módulos de segurança de hardware com o AD RMS, consulte 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 sua chave de locatário (gerenciada pela Microsoft) ou você gerencia sua chave de locatário (gerenciada pelo cliente) no Cofre de Chaves do Azure. Quando você gerencia sua própria chave de locatário da Proteção de Informações do Azure, às vezes é chamada de "traga sua própria chave" (BYOK). Para obter mais informações, consulte Planejando e implementando o artigo da chave de locatário da Proteção de Informações do Azure.

Use a tabela a seguir para identificar qual procedimento usar para sua 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 por senha no banco de dados AD RMS	Gerenciado pela Microsoft	Consulte o procedimento de migração de chave protegida por software para chave protegida por software após esta tabela. Esse é o caminho de migração mais simples e requer apenas que você transfira seus dados de configuração para a Proteção de Informações do Azure.
Proteção HSM usando um módulo de segurança de hardware nCipher nShield (HSM)	Gerenciado pelo cliente (BYOK)	Consulte 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 a usar sua chave de locatário e, finalmente, transferir seus dados de configuração para a Proteção de Informações do Azure.
Proteção por senha no banco de dados AD RMS	Gerenciado pelo cliente (BYOK)	Consulte 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 sua 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 em seguida seus dados do Cofre da Chave para a Proteção de Informações do Azure e, finalmente, transferir seus dados de configuração para a Proteção de Informações do Azure.
Proteção HSM usando um módulo de segurança de hardware (HSM) de um fornecedor diferente do nCipher	Gerenciado pelo cliente (BYOK)	Entre em contato com o fornecedor do seu HSM para obter instruções sobre como transferir sua chave desse 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 seu provedor de criptografia para obter instruções sobre como transferir sua 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 possa exportar, ainda poderá migrar para a Proteção de Informações do Azure configurando seu cluster 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, consulte Uma atualização está disponível para o Office dar suporte a migrações do AD RMS para o Azure RMS.

Antes de iniciar esses procedimentos de migração de chave, verifique se você pode acessar os arquivos de .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ê move do servidor AD RMS para a estação de trabalho conectada à Internet.

Nota

No entanto, você armazena esses arquivos, use as práticas recomendadas de segurança para protegê-los, pois esses dados incluem sua 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 suas 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 sua organização e você tiver criado modelos personalizados que deseja usar após a migração, exporte e importe esses modelos. Este procedimento é abordado na próxima etapa.

Etapa 6: Configurar modelos importados

Como os modelos importados 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 aparência e se comportam como modelos personalizados que você pode criar no portal do Azure. Para alterar modelos importados a serem publicados para que os usuários possam vê-los e selecioná-los em aplicativos, consulte Configurando e gerenciando modelos para a Proteção de Informações do Azure.

Além de publicar seus modelos recém-importados, há apenas duas alterações importantes para os modelos que você pode precisar 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 AD RMS.

As alterações de modelo que você pode precisar fazer para esta 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 seus modelos no AD RMS utilizavam o grupo ANYONE , poderá ter de adicionar manualmente utilizadores ou grupos.

No AD RMS, o grupo QUALQUER PESSOA concedeu direitos a todos os utilizadores autenticados pelo Ative Directory local e este grupo não é suportado pela Proteção de Informações do Azure. O equivalente do armário é um grupo criado automaticamente para todos os usuários em seu locatário do Microsoft Entra. Se estiver a utilizar o grupo QUALQUER PESSOA para os seus modelos AD RMS, poderá ter de adicionar utilizadores e os direitos que pretende conceder-lhes.

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, você deve primeiro fazer o seguinte:

Identifique esses modelos e anote sua ID de modelo, executando Get-AipServiceTemplate.
Exporte os modelos usando o cmdlet do PowerShell do Azure RMS, Export-AipServiceTemplate.
Importe os modelos usando o cmdlet do Azure RMS PowerShell, 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 seus modelos no AD RMS utilizaram o grupo ANYONE

Se seus modelos no AD RMS usavam 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 a Contoso: AllStaff-7184AB3F-CCD1-46F3-8233-3E09E9CF0E66@contoso.onmicrosoft.com. Este grupo contém todos os utilizadores do seu inquilino 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 na ID do Microsoft Entra. Por exemplo, esse grupo pode se parecer com o seguinte para Contoso: contoso.onmicrosoft.com. Para adicionar esse grupo, a opção exibe Adicionar <nome> da organização - Todos os membros.

Se não tiver certeza se seus modelos do AD RMS incluem o grupo ANYONE, você pode usar o seguinte exemplo de script do Windows PowerShell para identificar esses modelos. Para obter mais informações sobre como usar o Windows PowerShell com o AD RMS, consulte Usando o Windows PowerShell para administrar o AD RMS.

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

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

Exemplo de script do Windows PowerShell para identificar modelos do AD RMS que incluem o grupo ANYONE

Esta seção contém o script de exemplo para ajudá-lo a identificar quaisquer modelos do AD RMS que tenham o grupo ANYONE definido, conforme descrito na seção anterior.

Declaração de exoneração de responsabilidade: Este script de exemplo não é suportado em nenhum programa ou serviço de suporte padrão da Microsoft. Este script de exemplo é fornecido no estado em que se encontra sem garantia de qualquer 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óximos passos

Vá para a fase 3 - configuração do lado do cliente.

Partilhar via