Preparando usuários e grupos para a Proteção de Informações do Azure

Nota

Você está procurando por Microsoft Purview Information Protection, anteriormente Microsoft Information Protection (MIP)?

O suplemento Proteção de Informações do Azure foi retirado e substituído por rótulos incorporados 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 em geral.

Antes de implantar a Proteção de Informações do Azure para sua organização, verifique se você tem contas para usuários e grupos na ID do Microsoft Entra para o locatário da sua organização.

Há diferentes maneiras de criar essas contas para usuários e grupos, que incluem:

• Você cria os usuários no centro de administração do Microsoft 365 e os grupos no centro de administração do Exchange Online.

• Você cria os usuários e grupos no portal do Azure.

• Você cria os usuários e o grupo usando os cmdlets do Azure AD PowerShell e do Exchange Online.

• Você cria os usuários e grupos em seu Ative Directory local e sincroniza-os com o Microsoft Entra ID.

• Você cria os usuários e grupos em outro diretório e sincroniza-os com o Microsoft Entra ID.

Quando você cria usuários e grupos usando os três primeiros métodos dessa lista, com uma exceção, eles são criados automaticamente na ID do Microsoft Entra e a Proteção de Informações do Azure pode usar essas contas diretamente. No entanto, muitas redes corporativas usam um diretório local para criar e gerenciar usuários e grupos. A Proteção de Informações do Azure não pode usar essas contas diretamente; você deve sincronizá-los com o Microsoft Entra ID.

A exceção mencionada no parágrafo anterior são as listas de distribuição dinâmicas que você pode criar para o Exchange Online. Ao contrário das listas de distribuição estáticas, esses grupos não são replicados para a ID do Microsoft Entra e, portanto, não podem ser usados pela Proteção de Informações do Azure.

Como os usuários e grupos são usados pela Proteção de Informações do Azure

Há três cenários para usar usuários e grupos com a Proteção de Informações do Azure:

Para atribuir etiquetas aos utilizadores quando configura a política de Proteção de Informações do Azure para que as etiquetas possam ser aplicadas a documentos e e-mails. Somente os administradores podem selecionar esses usuários e grupos:

• A política padrão de Proteção de Informações do Azure é atribuída automaticamente a todos os usuários na ID do Microsoft Entra do seu locatário. No entanto, você também pode atribuir rótulos adicionais a usuários ou grupos especificados usando políticas de escopo.

Para atribuir direitos de utilização e controlos de acesso quando utiliza o serviço Azure Rights Management para proteger documentos e e-mails. Os administradores e usuários podem selecionar estes usuários e grupos:

• Os direitos de utilização determinam se um utilizador pode abrir um documento ou e-mail e como pode utilizá-lo. Por exemplo, se eles só podem lê-lo, ou lê-lo e imprimi-lo, ou lê-lo e editá-lo.

• Os controlos de acesso incluem uma data de expiração e se é necessária uma ligação à Internet para o acesso.

Para configurar o serviço Azure Rights Management para dar suporte a cenários específicos e, portanto, apenas os administradores selecionam esses grupos. Os exemplos incluem a configuração do seguinte:

• Superusuários, para que serviços ou pessoas designadas possam abrir conteúdo criptografado, se necessário, para Descoberta Eletrônica ou recuperação de dados.

• Administração delegada do serviço Azure Rights Management.

• Controles de integração para dar suporte a uma implantação em fases.

Requisitos da Proteção de Informações do Azure para contas de usuário

Para atribuir etiquetas:

• Todas as contas de usuário no Microsoft Entra ID podem ser usadas para configurar políticas de escopo que atribuem rótulos adicionais aos usuários.

Para atribuir direitos de uso e controles de acesso e configurar o serviço Azure Rights Management:

• Para autorizar usuários, dois atributos no Microsoft Entra ID são usados: proxyAddresses e userPrincipalName.

• O atributo proxyAddresses do Microsoft Entra armazena todos os endereços de email de uma conta e pode ser preenchido de diferentes maneiras. Por exemplo, um usuário no Microsoft 365 que tem uma caixa de correio do Exchange Online automaticamente tem um endereço de email armazenado nesse atributo. Se você atribuir um endereço de email alternativo para um usuário do Microsoft 365, ele também será salvo nesse atributo. Ele também pode ser preenchido pelos endereços de email sincronizados a partir de contas locais.

  A Proteção de Informações do Azure pode usar qualquer valor neste atributo proxyAddresses do Microsoft Entra, desde que o domínio tenha sido adicionado ao seu locatário (um "domínio verificado"). Para obter mais informações sobre como verificar domínios:

  • Para Microsoft Entra ID: Adicionar um nome de domínio personalizado ao Microsoft Entra ID

  • Para o Office 365: Adicionar um domínio ao Office 365

• O atributo userPrincipalName do Microsoft Entra é usado somente quando uma conta em seu locatário não tem valores no atributo proxyAddresses do Microsoft Entra. Por exemplo, você cria um usuário no portal do Azure ou cria um usuário para o Microsoft 365 que não tem uma caixa de correio.

Atribuir direitos de utilização e controlos de acesso a utilizadores externos

Além de usar o proxy Addresses do Microsoft Entra e o userPrincipalName do Microsoft Entra para usuários em seu locatário, a Proteção de Informações do Azure também usa esses atributos da mesma maneira para autorizar usuários de outro locatário.

Outros métodos de autorização:

• Para endereços de email que não estão na ID do Microsoft Entra, a Proteção de Informações do Azure pode autorizá-los quando forem autenticados com uma conta da Microsoft. No entanto, nem todos os aplicativos podem abrir conteúdo protegido quando uma conta da Microsoft é usada para autenticação. Mais informações

• Quando um email é enviado usando a Criptografia de Mensagem do Office 365 com novos recursos para um usuário que não tem uma conta no Microsoft Entra ID, o usuário é primeiro autenticado usando federação com um provedor de identidade social ou usando uma senha de uso único. Em seguida, o endereço de e-mail especificado no e-mail protegido é usado para autorizar o usuário.

Requisitos da Proteção de Informações do Azure para contas de grupo

Para atribuir etiquetas:

• Para configurar políticas de escopo que atribuem rótulos adicionais aos membros do grupo, você pode usar qualquer tipo de grupo no ID do Microsoft Entra que tenha um endereço de email que contenha um domínio verificado para o locatário do usuário. Um grupo que tem um endereço de email é frequentemente chamado de grupo habilitado para email.

  Por exemplo, você pode usar um grupo de segurança habilitado para email, um grupo de distribuição estático e um grupo do Microsoft 365. Não pode utilizar um grupo de segurança (dinâmico ou estático) porque este tipo de grupo não tem um endereço de e-mail. Também não é possível usar uma lista de distribuição dinâmica do Exchange Online porque esse grupo não é replicado para a ID do Microsoft Entra.

Para atribuir direitos de utilização e controlos de acesso:

• Você pode usar qualquer tipo de grupo no Microsoft Entra ID que tenha um endereço de email que contenha um domínio verificado para o locatário do usuário. Um grupo que tem um endereço de email é frequentemente chamado de grupo habilitado para email.

Para configurar o serviço Azure Rights Management:

• Você pode usar qualquer tipo de grupo no Microsoft Entra ID que tenha um endereço de email de um domínio verificado em seu locatário, com uma exceção. Essa exceção é quando você configura controles de integração para usar um grupo, que deve ser um grupo de segurança no Microsoft Entra ID para seu locatário.

• Você pode usar qualquer grupo no Microsoft Entra ID (com ou sem um endereço de email) de um domínio verificado em seu locatário para administração delegada do serviço Azure Rights Management.

Atribuindo direitos de uso e controles de acesso a grupos externos

Além de usar o proxyAddresses do Microsoft Entra para grupos em seu locatário, a Proteção de Informações do Azure também usa esse atributo da mesma maneira para autorizar grupos de outro locatário.

Usando contas do Ative Directory local para a Proteção de Informações do Azure

Se você tiver contas gerenciadas localmente que deseja usar com a Proteção de Informações do Azure, deverá sincronizá-las com a ID do Microsoft Entra. Para facilitar a implantação, recomendamos que você use o Microsoft Entra Connect. No entanto, você pode usar qualquer método de sincronização de diretório que atinja o mesmo resultado.

Quando você sincroniza suas contas, não precisa sincronizar todos os atributos. Para obter uma lista dos atributos que devem ser sincronizados, consulte a seção Azure RMS da documentação do Microsoft Entra.

Na lista de atributos do Azure Rights Management, você verá que, para os usuários, os atributos do AD local de email, proxyAddresses e userPrincipalName são necessários para sincronização. Os valores para email e proxyAddresses são sincronizados com o atributo proxyAddresses do Microsoft Entra. Para obter mais informações, consulte Como o atributo proxyAddresses é preenchido no Microsoft Entra ID

Confirmando que seus usuários e grupos estão preparados para a Proteção de Informações do Azure

Você pode usar o Azure AD PowerShell para confirmar se os usuários e grupos podem ser usados com a Proteção de Informações do Azure. Você também pode usar o PowerShell para confirmar os valores que podem ser usados para autorizá-los.

Nota

Os módulos Azure AD e MSOnline PowerShell foram preteridos a partir de 30 de março de 2024. Para saber mais, leia a atualização de descontinuação. Após essa data, o suporte para esses módulos é limitado à assistência de migração para o SDK do Microsoft Graph PowerShell e correções de segurança. Os módulos preteridos continuarão a funcionar até 30 de março de 2025.

Recomendamos migrar para o Microsoft Graph PowerShell para interagir com o Microsoft Entra ID (anteriormente Azure AD). Para perguntas comuns sobre migração, consulte as Perguntas frequentes sobre migração. Nota: As versões 1.0.x do MSOnline podem sofrer interrupções após 30 de junho de 2024.

Por exemplo, usando o módulo V1 PowerShell para Microsoft Entra ID, MSOnline, em uma sessão do PowerShell, primeiro conecte-se ao serviço e forneça suas credenciais de administrador global:

Connect-MsolService

Nota: Se este comando não funcionar, você pode executar Install-Module MSOnline para instalar o módulo MSOnline.

Em seguida, configure sua sessão do PowerShell para que ela não trunce os valores:

$Formatenumerationlimit =-1

Confirmar se as contas de usuário estão prontas para a Proteção de Informações do Azure

Para confirmar as contas de usuário, execute o seguinte comando:

Get-Msoluser | select DisplayName, UserPrincipalName, ProxyAddresses

Sua primeira verificação é certificar-se de que os usuários que você deseja usar com a Proteção de Informações do Azure sejam exibidos.

Em seguida, verifique se a coluna ProxyAddresses está preenchida. Se for, os valores de email nesta coluna podem ser usados para autorizar o usuário para a Proteção de Informações do Azure.

Se a coluna ProxyAddresses não for preenchida, o valor no UserPrincipalName será usado para autorizar o usuário para o serviço Azure Rights Management.

Por exemplo:

Nome a apresentar	UserPrincipalName	ProxyAddresses
Jagannath Reddy	jagannathreddy@contoso.com	{}
Ankur Roy	ankurroy@contoso.com	{SMTP:ankur.roy@contoso.com, smtp: ankur.roy@onmicrosoft.contoso.com}

Neste exemplo:

• A conta de usuário de Jagannath Reddy será autorizada pela jagannathreddy@contoso.com.

• A conta de usuário de Ankur Roy pode ser autorizada usando ankur.roy@contoso.com e ankur.roy@onmicrosoft.contoso.com, mas não ankurroy@contoso.com.

Na maioria dos casos, o valor de UserPrincipalName corresponde a um dos valores no campo ProxyAddresses . Esta é a configuração recomendada, mas se não puder alterar o UPN para corresponder ao endereço de e-mail, deve seguir os seguintes passos:

1. Se o nome de domínio no valor UPN for um domínio verificado para seu locatário do Microsoft Entra, adicione o valor UPN como outro endereço de email na ID do Microsoft Entra para que o valor UPN agora possa ser usado para autorizar a conta de usuário para a Proteção de Informações do Azure.

   Se o nome de domínio no valor UPN não for um domínio verificado para seu locatário, ele não poderá ser usado com a Proteção de Informações do Azure. No entanto, o usuário ainda pode ser autorizado como membro de um grupo quando o endereço de e-mail do grupo usa um nome de domínio verificado.

2. Se o UPN não for roteável (por exemplo, ankurroy@contoso.local), configure a ID de login alternativa para os usuários e instrua-os sobre como entrar no Office usando esse logon alternativo. Você também deve definir uma chave do Registro para o Office.

   Com as alterações do UPN para os usuários, haverá uma perda de continuidade de negócios por pelo menos 24 horas ou até que as alterações do UPN sejam refletidas corretamente no sistema.

   Para obter mais informações, consulte Configurando ID de Logon Alternativo e os aplicativos do Office solicitam periodicamente credenciais para SharePoint, OneDrive e Lync Online.

Gorjeta

Você pode usar o cmdlet Export-Csv para exportar os resultados para uma planilha para facilitar o gerenciamento, como pesquisa e edição em massa para importação.

Por exemplo: Get-MsolGroup | select DisplayName, ProxyAddresses | Export-Csv -Path UserAccounts.csv

Nota

Com as alterações do UPN para os usuários, haverá uma perda de continuidade de negócios por pelo menos 24 horas ou até que as alterações do UPN sejam refletidas corretamente no sistema.

Confirmar se as contas de grupo estão prontas para a Proteção de Informações do Azure

Para confirmar contas de grupo, use o seguinte comando:

Get-MsolGroup | select DisplayName, ProxyAddresses

Certifique-se de que os grupos que pretende utilizar com a Proteção de Informações do Azure são apresentados. Para os grupos exibidos, os endereços de email na coluna ProxyAddresses podem ser usados para autorizar os membros do grupo para o serviço Azure Rights Management.

Em seguida, verifique se os grupos contêm os usuários (ou outros grupos) que você deseja usar para a Proteção de Informações do Azure. Você pode usar o PowerShell para fazer isso (por exemplo, Get-MsolGroupMember) ou usar seu portal de gerenciamento.

Para os dois cenários de configuração do serviço Azure Rights Management que usam grupos de segurança, você pode usar o seguinte comando do PowerShell para localizar a ID do objeto e o nome para exibição que podem ser usados para identificar esses grupos. Você também pode usar o portal do Azure para localizar esses grupos e copiar os valores para a ID do objeto e o nome para exibição:

Get-MsolGroup | where {$_.GroupType -eq "Security"}

Considerações para a Proteção de Informações do Azure se os endereços de email forem alterados

Se você alterar o endereço de e-mail de um usuário ou grupo, recomendamos que adicione o endereço de e-mail antigo como um segundo endereço de e-mail (também conhecido como endereço proxy, alias ou endereço de e-mail alternativo) ao usuário ou grupo. Quando você fizer isso, o endereço de email antigo é adicionado ao atributo proxyAddresses do Microsoft Entra. Esta administração de conta garante a continuidade de negócios para quaisquer direitos de uso ou outras configurações que foram salvas quando o endereço de e-mail antigo estava em uso.

Se você não puder fazer isso, o usuário ou grupo com o novo endereço de e-mail corre o risco de ter o acesso negado a documentos e e-mails que foram protegidos anteriormente com o endereço de e-mail antigo. Nesse caso, você deve repetir a configuração de proteção para salvar o novo endereço de e-mail. Por exemplo, se o usuário ou grupo recebeu direitos de uso em modelos ou rótulos, edite esses modelos ou rótulos e especifique o novo endereço de e-mail com os mesmos direitos de uso que você concedeu ao endereço de e-mail antigo.

Observe que é raro um grupo alterar seu endereço de e-mail e, se você atribuir direitos de uso a um grupo em vez de usuários individuais, não importa se o endereço de e-mail do usuário muda. Nesse cenário, os direitos de uso são atribuídos ao endereço de email do grupo e não endereços de email de usuário individual. Este é o método mais provável (e recomendado) para um administrador configurar direitos de uso que protegem documentos e e-mails. No entanto, os usuários normalmente podem atribuir permissões personalizadas para usuários individuais. Como nem sempre é possível saber se uma conta de usuário ou grupo foi usado para conceder acesso, é mais seguro sempre adicionar o endereço de e-mail antigo como um segundo endereço de e-mail.

Cache de associação de grupo pela Proteção de Informações do Azure

Por motivos de desempenho, a Proteção de Informações do Azure armazena em cache a associação ao grupo. Isso significa que quaisquer alterações na associação de grupo na ID do Microsoft Entra podem levar até três horas para entrar em vigor quando esses grupos são usados pela Proteção de Informações do Azure e esse período de tempo está sujeito a alterações.

Lembre-se de considerar esse atraso em quaisquer alterações ou testes que você faça quando usa grupos para conceder direitos de uso ou configurar o serviço Azure Rights Management ou quando configura políticas com escopo.

Próximos passos

Quando tiver confirmado que os seus utilizadores e grupos podem ser utilizados com a Proteção de Informações do Azure e estiver pronto para começar a proteger documentos e e-mails, verifique se precisa de ativar o serviço Azure Rights Management. Este serviço deve ser ativado antes que você possa proteger os documentos e e-mails da sua organização:

• A partir de fevereiro de 2018: se a sua subscrição que inclui o Azure Rights Management ou a Proteção de Informações do Azure tiver sido obtida durante ou após este mês, o serviço é ativado automaticamente para si.

• Se a sua subscrição tiver sido obtida antes de fevereiro de 2018: tem de ativar o serviço por conta própria.

Para obter mais informações, que incluem verificar o status da ativação, consulte Ativando o serviço de proteção da Proteção de Informações do Azure.