Preparando usuários e grupos da Proteção de Informações do Azure
Observação
Está procurando pela Proteção de Informações do Microsoft Purview, conhecida anteriormente como MIP (Proteção de Informações da Microsoft)?
O suplemento Proteção de Informações do Azure é desativado e substituído por rótulos internos 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 para o público em geral.
Antes de implantar a Proteção de Informações do Azure na organização, verifique se há contas de usuários e de grupos no Microsoft Entra ID para o locatário da sua organização.
Há diferentes maneiras de criar essas contas de usuários e grupos, como:
Criar os usuários no Centro de administração do Microsoft 365 e os grupos no Centro de administração do Exchange Online.
Criar os usuários e grupos no Portal do Azure.
Criar os usuários e grupos usando os cmdlets do PowerShell do Azure AD e do Exchange Online.
Criar os usuários e grupos no Active Directory local e sincronizá-los com o Microsoft Entra ID.
Criar os usuários e grupos em outro diretório e sincronizá-los com o Microsoft Entra ID.
Quando os usuários e grupos são criados com os três primeiros métodos nessa lista, com uma exceção, eles são criados automaticamente no Microsoft Entra ID e, assim, a Proteção de Informações do Azure pode usar essas contas diretamente. No entanto, várias redes empresariais 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ê deverá sincronizá-las com o Microsoft Entra ID.
A exceção mencionada no parágrafo anterior são 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 o Microsoft Entra ID 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 de uso de usuários e grupos na Proteção de Informações do Azure:
Para atribuir rótulos a usuários ao configurar a política da Proteção de Informações do Azure para que os rótulos possam ser aplicados a documentos e emails. Somente os administradores podem selecionar esses usuários e grupos:
- A política padrão da Proteção de Informações do Azure é atribuída automaticamente a todos os usuários no Microsoft Entra ID do seu locatário. No entanto, você também pode atribuir rótulos adicionais para usuários ou grupos especificados usando políticas de escopo.
Para atribuir direitos de uso e controles de acesso ao usar o serviço Azure Rights Management para proteger documentos e emails. Os administradores e usuários podem selecionar estes usuários e grupos:
Os direitos de uso determinam se um usuário pode abrir um documento ou email e como ele pode usá-lo. Por exemplo, se ele pode apenas ler, ler e imprimir ou ler e editar o documento.
Os controles de acesso incluem uma data de expiração e se uma conexão com a Internet é necessária para o acesso.
Para configurar o serviço Azure Rights Management para dar suporte a cenários específicos e, portanto, apenas administradores podem selecionar esses grupos. Exemplos incluem configurar o seguinte:
Superusuários, para que serviços ou pessoas designadas possam abrir o conteúdo criptografado em caso de 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 rótulos:
- Todas as contas de usuário no Microsoft Entra ID podem ser usadas para configurar políticas de escopo que atribuem rótulos adicionais a usuários.
Para atribuir direitos de uso e controles de acesso e configurar o serviço Azure Rights Management:
Para autorizar usuários, são usados dois atributos no Microsoft Entra ID: proxyAddresses e userPrincipalName.
O atributo proxyAddresses do Microsoft Entra ID armazena todos os endereços de email de uma conta e pode ser populado de várias maneiras. Por exemplo, um usuário do Microsoft 365 que tem um endereço de email do Exchange Online tem automaticamente um endereço de email armazenado nesse atributo. Se você atribuir um endereço de email alternativo a um usuário do Microsoft 365, ele também será salvo nesse atributo. Ele também pode ser populado por endereços de email sincronizados de contas locais.
A Proteção de Informações do Azure pode usar qualquer valor nesse atributo proxyAddresses do Microsoft Entra ID, desde que o domínio seja adicionado ao locatário (um "domínio verificado"). Para obter mais informações sobre a verificação de domínios:
Para o 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 no seu locatário não tem valores no atributo proxyAddresses do Microsoft Entra. Por exemplo, ao criar um usuário no Portal do Azure ou criar um usuário do Microsoft 365 que não tenha uma caixa de correio.
Atribuindo direitos de uso e controles de acesso a usuários externos
Além de usar o proxyAddresses e o userPrincipalName do Microsoft Entra para os usuários do seu locatário, a Proteção de Informações do Azure também usa esses atributos da mesma forma para autorizar usuários de outro locatário.
Outros métodos de autorização:
Para endereços de email que não estão no Microsoft Entra ID, a Proteção de Informações do Azure pode autorizá-los quando eles são autenticados com uma conta Microsoft. No entanto, nem todos os aplicativos podem abrir conteúdo protegido quando uma conta Microsoft é usada para autenticação. Mais informações
Quando um email é enviado usando a Criptografia de Mensagens do Office 365 com novos recursos para um usuário que não tem uma conta do Microsoft Entra ID, o usuário é autenticado pela primeira vez usando a federação com um provedor de identidade de rede social ou usando uma senha de uso único. Em seguida, o endereço de email especificado no email protegido é usado para autorizar o usuário.
Requisitos da Proteção de Informações do Azure para contas de grupo
Para atribuir rótulos:
Para configurar políticas de escopo que atribuem rótulos adicionais a membros de grupos, você pode usar qualquer tipo de grupo no Microsoft Entra ID que tenha um endereço de email contendo um domínio verificado do locatário do usuário. Um grupo que tem um endereço de email é conhecido como um 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. Você não pode usar um grupo de segurança (dinâmico ou estático), porque esse tipo de grupo não tem um endereço de email. Também não é possível usar uma lista de distribuição dinâmica do Exchange Online porque esse grupo não é replicado para o Microsoft Entra ID.
Para atribuir direitos de uso e controles de acesso:
- Você pode usar qualquer tipo de grupo no Microsoft Entra ID que tenha um endereço de email contendo um domínio verificado do locatário do usuário. Um grupo que tem um endereço de email é conhecido como um 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 do seu locatário, com uma exceção. Essa exceção ocorre ao configurar controles de integração para usar um grupo, que precisa ser um grupo de segurança no Microsoft Entra ID do locatário.
Você pode usar qualquer grupo do Microsoft Entra ID (com ou sem um endereço de email) de um domínio verificado do seu locatário para a 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 no locatário, a Proteção de Informações do Azure também usa esse atributo da mesma forma para autorizar grupos de outro locatário.
Usando contas do Active 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, sincronize-as com o Microsoft Entra ID. Para facilitar a implantação, é recomendável 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.
Ao sincronizar suas contas, você não precisa sincronizar todos os atributos. Para obter uma lista dos atributos que precisam ser sincronizados, confira a seção Azure RMS na documentação do Microsoft Entra.
Na lista de atributos do Azure Rights Management, veja que para usuários, os atributos do AD local mail, proxyAddresses e userPrincipalName são necessários para a sincronização. Os valores para mail e proxyAddresses são sincronizados com o atributo proxyAddresses do Microsoft Entra. Para obter mais informações, confira Como o atributo proxyAddresses é populado no Microsoft Entra ID
Confirmando se os usuários e grupos estão preparados para a Proteção de Informações do Azure
Você pode usar o PowerShell do Azure AD 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.
Observação
Os módulos Azure AD e MSOnline PowerShell estão preteridos desde 30 de março de 2024. Para saber mais, leia a atualização de preterição. Após essa data, o suporte a esses módulos se limitará à assistência à migração para o SDK do Microsoft Graph PowerShell e às correções de segurança. Os módulos preteridos continuarão funcionando até 30 de março de 2025.
Recomendamos migrar para o Microsoft Graph PowerShell para interagir com o Microsoft Entra ID (antigo Azure AD). Para perguntas comuns sobre migração, consulte as Perguntas Frequentes sobre Migração. Observação: As versões 1.0.x do MSOnline poderão sofrer interrupções após 30 de junho de 2024.
Por exemplo, usando o módulo V1 do PowerShell para o Microsoft Entra ID, MSOnline, em uma sessão do PowerShell, primeiro se conecte ao serviço e forneça suas credenciais de administrador global:
Connect-MsolService
Observação: se esse comando não funcionar, você poderá executar Install-Module MSOnline para instalar o módulo MSOnline.
Em seguida, configure sua sessão do PowerShell para que ela não trunque 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
A primeira verificação é para certificar-se de que os usuários que você deseja usar com a Proteção de Informações do Azure são exibidos.
Em seguida, verifique se a coluna ProxyAddresses está populada. Se estiver, os valores de email nesta coluna poderão ser usados para autorizar o usuário da Proteção de Informações do Azure.
Se a coluna ProxyAddresses não estiver populada, o valor no UserPrincipalName será usado para autorizar o usuário para o serviço Azure Rights Management.
Por exemplo:
| Nome para Exibição | 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 para Jagannath Reddy será autorizada usando jagannathreddy@contoso.com.
A conta de usuário para Ankur Roy poderá 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. Essa é a configuração recomendada, mas se não for possível alterar o UPN para corresponder ao endereço de email, você precisará executar as seguintes etapas:
Se o nome de domínio no valor do UPN for um domínio verificado do seu locatário do Microsoft Entra, adicione o valor do UPN como outro endereço de email no Microsoft Entra ID para que o valor do UPN 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 do 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 poderá ser autorizado como membro de um grupo se o endereço de email do grupo usar um nome de domínio verificado.
Se o UPN não for roteável (por exemplo, ankurroy@contoso.local), configure uma ID de logon alternativo para os usuários e forneça instruções para que eles entrem no Office usando esse logon alternativo. Você também precisa definir uma chave do Registro para o Office.
Com as alterações de UPN para os usuários, haverá uma perda de continuidade dos negócios por pelo menos 24 horas ou até que as alterações de UPN sejam refletidas adequadamente no sistema.
Para obter mais informações, confira Configurando a ID de logon alternativo e Aplicativos do Office periodicamente solicitam credenciais para o SharePoint, OneDrive e o Lync Online.
Dica
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
Observação
Com as alterações de UPN para os usuários, haverá uma perda de continuidade dos negócios por pelo menos 24 horas ou até que as alterações de UPN sejam refletidas adequadamente no sistema.
Confirmar se as contas de grupo estão prontas para a Proteção de Informações do Azure
Para confirmar as contas de grupo, use o seguinte comando:
Get-MsolGroup | select DisplayName, ProxyAddresses
Verifique se os grupos que você deseja usar com a Proteção de Informações do Azure são exibidos. 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.
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. Para fazer isso, você pode usar o PowerShell (por exemplo, Get-MsolGroupMember) ou o 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 encontrar a ID do objeto e o nome de 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 da ID do objeto e do nome de 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 email de um usuário ou grupo, será recomendável adicionar o endereço de email antigo como um segundo endereço de email (também conhecido como endereço proxy, alias ou endereço de email alternativo) para o usuário ou grupo. Quando você fizer isso, o endereço de email antigo será adicionado ao atributo proxyAddresses do Microsoft Entra. Essa ação de administração da conta garante a continuidade dos negócios de todos os direitos de uso e outras configurações que foram salvos quando o endereço de email antigo estava em uso.
Se você não puder fazer isso, o usuário ou o grupo com o novo endereço de email correrá o risco de ter o acesso negado a documentos e emails que tenham sido protegidos anteriormente com o endereço de email antigo. Nesse caso, você precisará repetir a configuração de proteção para salvar o novo endereço de email. Por exemplo, se o usuário ou grupo tiver recebido direitos de uso em modelos ou rótulos, edite esses modelos ou rótulos e especifique o novo endereço de email com os mesmos direitos de uso que haviam sido concedidos para o endereço de email antigo.
Observe que é raro um grupo alterar seu endereço de email e se você atribuir direitos de uso a um grupo em vez de a usuários individuais, não fará diferença se o endereço de email do usuário for alterado. Nesse cenário, os direitos de uso são atribuídos ao endereço de email do grupo e não a endereços de email de usuários individuais. Esse é o método mais provável (e recomendado) para um administrador configurar direitos de uso que protegem documentos e emails. No entanto, é mais comum que os usuários atribuam permissões personalizadas para usuários individuais. Como nem sempre é possível saber se foi usada uma conta de usuário ou de grupo para conceder acesso, é mais seguro sempre adicionar o endereço de email antigo como um segundo endereço de email.
Cache de associação a um grupo da 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 a um grupo. Isso significa que as alterações na associação de grupo no Microsoft Entra ID 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 todas as alterações ou testes que você fizer ao usar grupos para conceder direitos de uso, configurar o serviço Azure Rights Management ou configurar políticas de escopo.
Próximas etapas
Depois de confirmar que os usuários e grupos podem ser usados com a Proteção de Informações do Azure e que está tudo pronto para começar a proteger documentos e emails, verifique se é necessário ativar o serviço Azure Rights Management. Esse serviço deve ser ativado para que você possa proteger os documentos e emails da organização:
A partir de fevereiro de 2018: se sua assinatura que inclui o Azure Rights Management ou a Proteção de Informações do Azure tiver sido obtida durante ou após esse mês, o serviço será ativado automaticamente para você.
Se a sua assinatura foi obtida antes de fevereiro de 2018: você mesmo deve ativar o serviço.
Para obter mais informações, que incluem a verificação do status de ativação, confira Ativando o serviço de proteção da Proteção de Informações do Azure.