Configurar direitos de utilização do Azure Information Protection
Este artigo descreve os direitos de uso que você pode configurar para serem aplicados automaticamente quando um rótulo ou modelo é selecionado por usuários, administradores ou serviços configurados.
Os direitos de uso são selecionados quando você configura rótulos de sensibilidade ou modelos de proteção para criptografia. Por exemplo, você pode selecionar funções que configuram um agrupamento lógico de direitos de uso ou configurar os direitos individuais separadamente. Como alternativa, os usuários podem selecionar e aplicar os próprios direitos de uso.
Para completar, este artigo inclui valores do portal clássico do Azure, que foi desativado em 08 de janeiro de 2018.
Importante
Use este artigo para entender como os direitos de uso são projetados para serem interpretados por aplicativos.
Os aplicativos podem variar em como implementam direitos de uso, e recomendamos consultar a documentação do seu aplicativo e realizar seus próprios testes para verificar o comportamento do aplicativo antes de implantá-lo na produção.
Direitos de utilização e descrições
A tabela a seguir lista e descreve os direitos de uso suportados pelo Rights Management e como eles são usados e interpretados. Eles são listados por seu nome comum, que normalmente é como você pode ver o direito de uso exibido ou referenciado, como uma versão mais amigável do valor de palavra única que é usado no código (o valor de política de codificação).
Nesta tabela:
A constante ou valor da API é o nome do SDK para uma chamada de API do SDK do MSIPC ou do Microsoft Purview Information Protection, usado quando você escreve um aplicativo que verifica um direito de uso ou adiciona um direito de uso a uma política.
O centro de administração de rotulagem é o portal de conformidade do Microsoft Purview, onde você configura rótulos de sensibilidade.
Direito de utilização | Description | Implementação |
---|---|---|
Nome comum: Editar conteúdo, Editar Codificação na política: DOCEDIT |
Permite ao usuário modificar, reorganizar, formatar ou classificar o conteúdo dentro do aplicativo, que inclui o Office na Web. Ele não concede o direito de salvar a cópia editada. No Word, a menos que você tenha o Office 365 ProPlus com uma versão mínima de 1807, esse direito não é suficiente para ativar ou desativar o recurso Controlar Alterações ou para usar todos os recursos de controle de alterações como revisor. Em vez disso, para usar todas as opções de controle de alterações requer o seguinte direito: Controle total. |
Direitos personalizados do Office: Como parte das opções Alterar e Controle Total. Nome no portal clássico do Azure: Editar conteúdo Nome no portal de conformidade do Microsoft Purview e no portal do Azure: Editar Conteúdo, Editar (DOCEDIT) Nome nos modelos do AD RMS: Editar Constante ou valor da API: MSIPC: Não aplicável. MIP SDK: DOCEDIT |
Nome comum: Guardar Codificação na política: EDIT |
Permite que o usuário salve o documento no local atual. No Office na Web, ele também permite que o usuário edite o conteúdo. Em aplicativos do Office, esse direito permite que o usuário salve o arquivo em um novo local e com um novo nome se o formato de arquivo selecionado tiver suporte interno para a proteção do Rights Management. A restrição de formato de arquivo garante que a proteção original não possa ser removida do arquivo. |
Direitos personalizados do Office: Como parte das opções Alterar e Controle Total. Nome no portal clássico do Azure: Salvar arquivo Nome no portal de conformidade do Microsoft Purview e no portal do Azure: Salvar (EDITAR) Nome nos modelos do AD RMS: Guardar Constante ou valor da API: MSIPC: IPC_GENERIC_WRITE L"EDIT" MIP SDK: EDIT |
Nome comum: Comentário Codificação na política: COMMENT |
Permite a opção de adicionar anotações ou comentários ao conteúdo. Esse direito está disponível no SDK, está disponível como uma política ad-hoc no módulo AzureInformationProtection e RMS Protection para Windows PowerShell e foi implementado em alguns aplicativos de fornecedores de software. No entanto, não é amplamente utilizado e não é suportado por aplicativos do Office. |
Direitos personalizados do Office: Não implementados. Nome no portal clássico do Azure: Não implementado. Nome no portal de conformidade do Microsoft Purview e no portal do Azure: Não implementado. Nome nos modelos do AD RMS: Não implementado. Constante ou valor da API: MSIPC: IPC_GENERIC_COMMENT L"COMMENT MIP SDK: COMMENT |
Nome comum: Salvar como, Exportar Codificação na política: EXPORTAR |
Habilita a opção de salvar o conteúdo em um nome de arquivo diferente (Salvar como). Para o cliente do Azure Information Protection, o arquivo pode ser salvo sem proteção e também reprotegido com novas configurações e permissões. Essas ações permitidas significam que um usuário que tem esse direito pode alterar ou remover um rótulo da Proteção de Informações do Azure de um documento ou email protegido. Esse direito também permite que o usuário execute outras opções de exportação em aplicativos, como Enviar para o OneNote. |
Direitos personalizados do Office: Como parte da opção Controle Total. Nome no portal clássico do Azure: Exportar conteúdo (Salvar como) Nome no portal de conformidade do Microsoft Purview e no portal do Azure: Salvar como, exportar (EXPORTAR) Nome nos modelos do AD RMS: Exportar (Guardar Como) Constante ou valor da API: MSIPC: IPC_GENERIC_EXPORT L"EXPORT" MIP SDK: EXPORT |
Nome comum: Forward Codificação na política: FORWARD |
Permite a opção de encaminhar uma mensagem de email e adicionar destinatários às linhas Para e Cc . Este direito não se aplica aos documentos; apenas mensagens de e-mail. Não permite que o encaminhador conceda direitos a outros usuários como parte da ação de encaminhamento. Ao conceder esse direito, conceda também o direito Editar Conteúdo, Editar (nome comum) e, adicionalmente, conceder o direito Salvar (nome comum) para garantir que a mensagem de e-mail protegida não seja entregue como um anexo. Especifique também esses direitos ao enviar um email para outra organização que usa o cliente Outlook ou o Outlook Web App. Ou, para usuários em sua organização que estão isentos de usar a proteção do Rights Management porque você implementou controles de integração. |
Direitos personalizados do Office: negados ao usar a política padrão Não Encaminhar . Nome no portal clássico do Azure: Encaminhar Nome no portal de conformidade do Microsoft Purview e no portal do Azure: Encaminhar (FORWARD) Nome nos modelos do AD RMS: Encaminhar Constante ou valor da API: MSIPC: IPC_EMAIL_FORWARD L"FORWARD" MIP SDK: FORWARD |
Nome comum: Controle total Codificação na política: PROPRIETÁRIO |
Concede todos os direitos ao documento e todas as ações disponíveis podem ser executadas. Inclui a capacidade de remover a proteção e reproteger um documento. Observe que esse direito de uso não é o mesmo que o proprietário do Rights Management. |
Direitos personalizados do Office: como a opção personalizada Controle Total. Nome no portal clássico do Azure: Controle Total Nome no portal de conformidade do Microsoft Purview e no portal do Azure: Controle Total (PROPRIETÁRIO) Nome nos modelos do AD RMS: Controlo Total Constante ou valor da API: MSIPC: IPC_GENERIC_ALL L"OWNER" MIP SDK: OWNER |
Nome comum: Imprimir Codificação na política: PRINT |
Habilita as opções para imprimir o conteúdo. | Direitos personalizados do Office: como a opção Imprimir Conteúdo em permissões personalizadas. Não é uma configuração por destinatário. Nome no portal clássico do Azure: Imprimir Nome no portal de conformidade do Microsoft Purview e no portal do Azure: Imprimir (PRINT) Nome nos modelos do AD RMS: Imprimir Constante ou valor da API: MSIPC: IPC_GENERIC_PRINT L"PRINT" MIP SDK: PRINT |
Nome comum: Responder Codificação na política: REPLY |
Habilita a opção Responder em um cliente de e-mail, sem permitir alterações nas linhas Para ou Cc . Ao conceder esse direito, conceda também o direito Editar Conteúdo, Editar (nome comum) e, adicionalmente, conceder o direito Salvar (nome comum) para garantir que a mensagem de e-mail protegida não seja entregue como um anexo. Especifique também esses direitos ao enviar um email para outra organização que usa o cliente Outlook ou o Outlook Web App. Ou, para usuários em sua organização que estão isentos de usar a proteção do Rights Management porque você implementou controles de integração. |
Direitos personalizados do Office: Não aplicável. Nome no portal clássico do Azure: Responder Nome no portal clássico do Azure: Responder (RESPONDER) Nome nos modelos do AD RMS: Responder Constante ou valor da API: MSIPC: IPC_EMAIL_REPLY MIP SDK: REPLY |
Nome comum: Responder a todos Codificação na política: REPLYALL |
Habilita a opção Responder a Todos em um cliente de email, mas não permite que o usuário adicione destinatários às linhas Para ou Cc . Ao conceder esse direito, conceda também o direito Editar Conteúdo, Editar (nome comum) e, adicionalmente, conceder o direito Salvar (nome comum) para garantir que a mensagem de e-mail protegida não seja entregue como um anexo. Especifique também esses direitos ao enviar um email para outra organização que usa o cliente Outlook ou o Outlook Web App. Ou, para usuários em sua organização que estão isentos de usar a proteção do Rights Management porque você implementou controles de integração. |
Direitos personalizados do Office: Não aplicável. Nome no portal clássico do Azure: Responder a Todos Nome no portal de conformidade do Microsoft Purview e no portal do Azure: Responder a todos (RESPONDER a TODOS) Nome nos modelos do AD RMS: Responder a Todos Constante ou valor da API: MSIPC: IPC_EMAIL_REPLYALL L"REPLYALL" MIP SDK: REPLYALL |
Nome comum: Ver, Abrir, Ler Codificação na política: VIEW |
Permite ao usuário abrir o documento e ver o conteúdo. No Excel, esse direito não é suficiente para classificar dados, o que requer o seguinte direito: Editar Conteúdo, Editar. Para filtrar dados no Excel, você precisa dos dois direitos a seguir: Editar Conteúdo, Editar e Copiar. |
Direitos personalizados do Office: como a opção Ler política personalizada, Exibir . Nome no portal clássico do Azure: Exibir Nome no portal de conformidade do Microsoft Purview e no portal do Azure: View, Open, Read (VIEW) Nome nos modelos do AD RMS: Ler Constante ou valor da API: MSIPC: IPC_GENERIC_READ L"VIEW" MIP SDK: VIEW |
Nome comum: Copiar Codificação na política: EXTRACT |
Permite opções para copiar dados (incluindo capturas de tela) do documento para o mesmo ou outro documento. Em algumas aplicações, também permite que todo o documento seja guardado de forma desprotegida. No Skype for Business e em aplicativos de compartilhamento de tela semelhantes, o apresentador deve ter esse direito para apresentar com êxito um documento protegido. Se o apresentador não tiver esse direito, os participantes não poderão visualizar o documento e ele será exibido como apagado para eles. |
Direitos personalizados do Office: como a opção de política personalizada Permitir que usuários com acesso de Leitura copiem conteúdo . Nome no portal clássico do Azure: Copiar e extrair conteúdo Nome no portal de conformidade do Microsoft Purview e no portal do Azure: Copiar (EXTRACT) Nome nos modelos do AD RMS: Extrair Constante ou valor da API: MSIPC: IPC_GENERIC_EXTRACT L"EXTRACT" MIP SDK: EXTRACT |
Nome comum: Ver Direitos Codificação na política: VIEWRIGHTSDATA |
Permite que o usuário veja a política aplicada ao documento. Não suportado por aplicações do Office ou clientes do Azure Information Protection. |
Direitos personalizados do Office: Não implementados. Nome no portal clássico do Azure: Exibir direitos atribuídos Nome no portal de conformidade do Microsoft Purview e no portal do Azure: View Rights (VIEWRIGHTSDATA). Nome nos modelos do AD RMS: Exibir direitos Constante ou valor da API: MSIPC: IPC_READ_RIGHTS L"VIEWRIGHTSDATA" MIP SDK: VIEWRIGHTSDATA |
Nome comum: Direitos de alteração Codificação na política: EDITRIGHTSDATA |
Permite que o usuário altere a política aplicada ao documento. Inclui incluindo a remoção de proteção. Não suportado por aplicações do Office ou clientes do Azure Information Protection. |
Direitos personalizados do Office: Não implementados. Nome no portal clássico do Azure: Alterar direitos Nome no portal de conformidade do Microsoft Purview e no portal do Azure: Edit Rights (EDITRIGHTSDATA). Nome nos modelos do AD RMS: Editar direitos Constante ou valor da API: MSIPC: PC_WRITE_RIGHTS L"EDITRIGHTSDATA" MIP SDK: EDITRIGHTSDATA |
Nome comum: Permitir macros Codificação na política: OBJMODEL |
Permite a opção de executar macros ou executar outro acesso programático ou remoto ao conteúdo de um documento. | Direitos personalizados do Office: como a opção de política personalizada Permitir acesso programático. Não é uma configuração por destinatário. Nome no portal clássico do Azure: Permitir macros Nome no portal de conformidade do Microsoft Purview e no portal do Azure: Permitir macros (OBJMODEL) Nome nos modelos do AD RMS: Permitir macros Constante ou valor da API: MSIPC: Não implementado. MIP SDK: OBJMODEL |
Direitos incluídos nos níveis de permissões
Alguns aplicativos agrupam os direitos de uso em níveis de permissões, para facilitar a seleção de direitos de uso que normalmente são usados juntos. Esses níveis de permissões ajudam a abstrair um nível de complexidade dos usuários, para que eles possam escolher opções baseadas em funções. Por exemplo, Revisor e Coautor. Embora essas opções geralmente mostrem aos usuários um resumo dos direitos, elas podem não incluir todos os direitos listados na tabela anterior.
Use a tabela a seguir para obter uma lista desses níveis de permissão e uma lista completa dos direitos de uso que eles contêm. Os direitos de utilização são listados pelo seu nome comum.
Nível de permissões | Aplicações | Direitos de utilização incluídos |
---|---|---|
Visualizador | Portal clássico do Azure Portal do Azure Cliente do Azure Information Protection para Windows |
Ver, Abrir, Ler; Direitos de Visualização; Resposta [1]; Responder a todos [1]; Permitir macros [2] Observação: para e-mails, use o Revisor em vez desse nível de permissão para garantir que uma resposta de e-mail seja recebida como uma mensagem de e-mail em vez de um anexo. O revisor também é necessário quando você envia um email para outra organização que usa o cliente Outlook ou o Outlook Web App. Ou, para usuários em sua organização que estão isentos de usar o serviço Azure Rights Management porque você implementou controles de integração. |
Revisor | Portal clássico do Azure Portal do Azure Cliente do Azure Information Protection para Windows |
Ver, Abrir, Ler; Poupar; Editar Conteúdo, Editar; Direitos de Visualização; Resposta: Responder a todos [3]; Avante [3]; Permitir macros [2] |
Coautor | Portal clássico do Azure Portal do Azure Cliente do Azure Information Protection para Windows |
Ver, Abrir, Ler; Poupar; Editar Conteúdo, Editar; Cópia; Direitos de Visualização; Permitir macros; Salvar como, exportar [4]; Impressão; Resposta [3]; Responder a todos [3]; Avançar [3] |
Coproprietário | Portal clássico do Azure Portal do Azure Cliente do Azure Information Protection para Windows |
Ver, Abrir, Ler; Poupar; Editar Conteúdo, Editar; Cópia; Direitos de Visualização; Direitos de Mudança; Permitir macros; Salvar como, exportar; Impressão; Resposta [3]; Responder a todos [3]; Avante [3]; Controlo Total |
Nota de rodapé 1
Não incluído no portal de conformidade do Microsoft Purview ou no portal do Azure.
Nota de rodapé 2
Para o cliente do Azure Information Protection para Windows, esse direito é necessário para a barra de Proteção de Informações em aplicativos do Office.
Nota de rodapé 3
Não aplicável ao cliente do Azure Information Protection para Windows.
Nota de rodapé 4
Não incluído no portal de conformidade do Microsoft Purview, no portal do Azure ou no cliente do Azure Information Protection para Windows.
Opção Não Encaminhar para e-mails
Os clientes e serviços do Exchange (por exemplo, o cliente Outlook, o Outlook na Web, as regras de fluxo de mensagens do Exchange e as ações DLP para o Exchange) têm uma opção adicional de proteção de direitos de informação para e-mails: Não Encaminhar.
Embora essa opção apareça para os usuários (e administradores do Exchange) como se fosse um modelo padrão do Rights Management que eles podem selecionar, Não Encaminhar não é um modelo. Isso explica por que você não pode vê-lo no portal do Azure quando exibe e gerencia modelos de proteção. Em vez disso, a opção Não Encaminhar é um conjunto de direitos de uso que é aplicado dinamicamente pelos usuários aos seus destinatários de email.
Quando a opção Não Encaminhar é aplicada a um e-mail, o e-mail é criptografado e os destinatários devem ser autenticados. Em seguida, os destinatários não podem encaminhá-lo, imprimi-lo ou copiá-lo. Por exemplo, no cliente Outlook, o botão Avançar não está disponível, as opções do menu Salvar como e Imprimir não estão disponíveis e você não pode adicionar ou alterar destinatários nas caixas Para, Cc ou Cco .
Os documentos desprotegidos do Office anexados ao e-mail herdam automaticamente as mesmas restrições. Os direitos de utilização aplicados a estes documentos são Editar Conteúdo, Editar; Poupar; Visualizar, Abrir, Ler e Permitir Macros. Se pretender direitos de utilização diferentes para um anexo ou se o seu anexo não for um documento do Office que suporte esta proteção herdada, proteja o ficheiro antes de o anexar ao e-mail. Em seguida, você pode atribuir os direitos de uso específicos necessários para o arquivo.
Diferença entre Não Encaminhar e não conceder o direito de uso Encaminhar
Há uma distinção importante entre aplicar a opção Não Encaminhar e aplicar um modelo que não concede o direito de uso Encaminhar a um e-mail: A opção Não Encaminhar usa uma lista dinâmica de usuários autorizados baseada nos destinatários escolhidos pelo usuário do e-mail original, enquanto os direitos no modelo têm uma lista estática de usuários autorizados que o administrador especificou anteriormente. Qual é a diferença? Vejamos um exemplo:
Um usuário deseja enviar por e-mail algumas informações para pessoas específicas no departamento de Marketing que não devem ser compartilhadas com mais ninguém. Ela deve proteger o e-mail com um modelo que restrinja os direitos (visualização, resposta e salvamento) do departamento de Marketing? Ou ela deve escolher a opção Não Encaminhar ? Ambas as opções resultariam em que os destinatários não poderiam encaminhar o e-mail.
Se ela aplicasse o modelo, os destinatários ainda poderiam compartilhar as informações com outras pessoas no departamento de marketing. Por exemplo, um destinatário pode usar o Explorer para arrastar e soltar o e-mail em um local compartilhado ou em uma unidade USB. Agora, qualquer pessoa do departamento de marketing (e o proprietário do e-mail) que tenha acesso a esse local pode visualizar as informações no e-mail.
Se ela aplicou a opção Não Encaminhar , os destinatários não poderão compartilhar as informações com ninguém no departamento de marketing, movendo o e-mail para outro local. Nesse cenário, somente os destinatários originais (e o proprietário do e-mail) poderão exibir as informações no e-mail.
Nota
Use Não Encaminhar quando for importante que apenas os destinatários escolhidos pelo remetente vejam as informações no e-mail. Use um modelo para e-mails para restringir direitos a um grupo de pessoas que o administrador especifica com antecedência, independentemente dos destinatários escolhidos pelo remetente.
Opção somente criptografia para e-mails
Quando o Exchange Online usa os novos recursos para a Criptografia de Mensagem do Office 365, uma nova opção Criptografar email fica disponível para criptografar os dados sem restrições adicionais.
Essa opção está disponível para locatários que usam o Exchange Online e pode ser selecionada da seguinte maneira:
- No Outlook na Web com a opção Criptografar ou um rótulo de confidencialidade configurado para Permitir que os usuários atribuam permissões e a opção Somente criptografia
- Como outra opção de proteção de direitos para uma regra de fluxo de mensagens
- Como uma ação DLP do Office 365
- A partir da aplicação Outlook para ambientes de trabalho e dispositivos móveis:
- Com um rótulo de sensibilidade configurado para Permitir que os usuários atribuam permissões e a opção Somente criptografia para Windows, macOS, iOS e Android quando você usa rotulagem interna com as versões mínimas listadas na tabela para recursos de rótulo de sensibilidade no Outlook.
- Com a opção Encriptar no Windows e macOS, para as versões listadas na tabela de versões suportadas para Aplicações Microsoft 365 por canal de atualização.
Para obter mais informações sobre a opção somente criptografia, consulte a seguinte postagem no blog quando ela foi anunciada pela primeira vez pela equipe do Office: Criptografar apenas a implementação na Criptografia de Mensagem do Office 365.
Quando esta opção é selecionada, o e-mail é criptografado e os destinatários devem ser autenticados. Em seguida, os destinatários têm todos os direitos de uso, exceto Salvar como, Exportar e Controle total. Essa combinação de direitos de uso significa que os destinatários não têm restrições, exceto que não podem remover a proteção. Por exemplo, um destinatário pode copiar do e-mail, imprimi-lo e encaminhá-lo.
Da mesma forma, por padrão, os documentos desprotegidos do Office anexados ao email herdam as mesmas permissões. Esses documentos são protegidos automaticamente e, quando são baixados, podem ser salvos, editados, copiados e impressos de aplicativos do Office pelos destinatários. Quando o documento é salvo por um destinatário, ele pode ser salvo em um novo nome e até mesmo em um formato diferente. No entanto, apenas os formatos de ficheiro que suportam proteção estão disponíveis para que o documento não possa ser guardado sem a proteção original. Se pretender direitos de utilização diferentes para um anexo ou se o seu anexo não for um documento do Office que suporte esta proteção herdada, proteja o ficheiro antes de o anexar ao e-mail. Em seguida, você pode atribuir os direitos de uso específicos necessários para o arquivo.
Como alternativa, você pode alterar essa herança de proteção de documentos especificando Set-IRMConfiguration -DecryptAttachmentForEncryptOnly $true
com o PowerShell do Exchange Online. Use essa configuração quando não precisar manter a proteção original do documento depois que o usuário for autenticado. Quando os destinatários abrem a mensagem de e-mail, o documento não está protegido.
Se você precisar de um documento anexado para manter a proteção original, consulte Proteger a colaboração de documentos usando a Proteção de Informações do Azure.
Nota
Se vir referências a DecryptAttachmentFromPortal, este parâmetro foi preterido para Set-IRMConfiguration. A menos que você tenha definido anteriormente esse parâmetro, ele não está disponível.
Criptografar automaticamente documentos PDF com o Exchange Online
Quando o Exchange Online usa os novos recursos para a Criptografia de Mensagem do Office 365, você pode criptografar automaticamente documentos PDF desprotegidos quando eles são anexados a um email criptografado. O documento herda as mesmas permissões que as da mensagem de email. Para habilitar essa configuração, defina EnablePdfEncryption $True com Set-IRMConfiguration.
Os destinatários que ainda não têm um leitor instalado que suporte o padrão ISO para criptografia de PDF podem instalar um dos leitores listados em leitores de PDF que suportam a Proteção de Informações do Microsoft Purview. Como alternativa, os destinatários podem ler o documento PDF protegido no portal OME.
Emissor do Rights Management e proprietário do Rights Management
Quando um documento ou email é protegido usando o serviço Azure Rights Management, a conta que protege esse conteúdo se torna automaticamente o emissor do Rights Management para esse conteúdo. Esta conta é registada como o campo emissor nos registos de utilização.
O emissor do Rights Management recebe sempre o direito de utilização do Controlo Total para o documento ou correio eletrónico e, além disso:
Se as configurações de proteção incluírem uma data de validade, o emissor do Rights Management ainda poderá abrir e editar o documento ou e-mail após essa data.
O emissor do Rights Management pode sempre aceder ao documento ou e-mail offline.
O emissor do Rights Management ainda pode abrir um documento depois que ele for revogado.
Por padrão, essa conta também é o proprietário do Rights Management para esse conteúdo, que é o caso quando um usuário que criou o documento ou e-mail inicia a proteção. Mas há alguns cenários em que um administrador ou serviço pode proteger o conteúdo em nome dos usuários. Por exemplo:
Um administrador protege arquivos em massa em um compartilhamento de arquivos: A conta de administrador no Microsoft Entra ID protege os documentos para os usuários.
O conector Rights Management protege documentos do Office em uma pasta do Windows Server: A conta principal de serviço no Microsoft Entra ID criada para o conector RMS protege os documentos para os usuários.
Nesses cenários, o emissor do Rights Management pode atribuir o proprietário do Rights Management a outra conta usando os SDKs da Proteção de Informações do Azure ou o PowerShell. Por exemplo, ao usar o cmdlet Protect-RMSFile PowerShell com o cliente do Azure Information Protection, você pode especificar o parâmetro OwnerEmail para atribuir o proprietário do Rights Management a outra conta.
Quando o emissor do Rights Management protege em nome dos utilizadores, a atribuição ao proprietário do Rights Management garante que o proprietário do documento ou e-mail original tem o mesmo nível de controlo para o seu conteúdo protegido como se ele próprio tivesse iniciado a proteção.
Por exemplo, o usuário que criou o documento pode imprimi-lo, mesmo que ele agora esteja protegido com um modelo que não inclui o direito de uso de impressão. O mesmo usuário sempre pode acessar seu documento, independentemente da configuração de acesso offline ou da data de expiração que possa ter sido configurada nesse modelo. Além disso, como o proprietário do Rights Management tem o direito de uso do Controle Total, esse usuário também pode reproteger o documento para conceder acesso a usuários adicionais (quando o usuário se torna o emissor do Rights Management, bem como o proprietário do Rights Management), e esse usuário pode até remover a proteção. No entanto, apenas o emissor do Rights Management pode rastrear e revogar um documento.
O proprietário do Rights Management para um documento ou email é registrado como o campo de e-mail do proprietário nos logs de uso.
Nota
O proprietário do Rights Management é independente do proprietário do sistema de arquivos do Windows. Eles geralmente são os mesmos, mas podem ser diferentes, mesmo que você não use os SDKs ou o PowerShell.
Rights Management use license (Licença de utilização do Rights Management)
Quando um usuário abre um documento ou email que foi protegido pelo Azure Rights Management, uma licença de uso do Rights Management para esse conteúdo é concedida ao usuário. Esta licença de utilização é um certificado que contém os direitos de utilização do utilizador para o documento ou mensagem de correio eletrónico e a chave de encriptação que foi utilizada para encriptar o conteúdo. A licença de uso também contém uma data de expiração, se isso tiver sido definido, e por quanto tempo a licença de uso é válida.
Um usuário deve ter uma licença de uso válida para abrir o conteúdo, além de seu certificado de conta de direitos (RAC), que é um certificado concedido quando o ambiente do usuário é inicializado e, em seguida, renovado a cada 31 dias.
Durante a duração da licença de uso, o usuário não é reautenticado ou reautorizado para o conteúdo. Isso permite que o usuário continue a abrir o documento ou e-mail protegido sem uma conexão com a Internet. Quando o período de validade da licença de uso expirar, na próxima vez que o usuário acessar o documento ou e-mail protegido, o usuário deverá ser reautenticado e reautorizado.
Quando documentos e mensagens de e-mail são protegidos usando um rótulo ou um modelo que define as configurações de proteção, você pode alterar essas configurações em seu rótulo ou modelo sem ter que proteger novamente o conteúdo. Se o usuário já tiver acessado o conteúdo, as alterações entrarão em vigor depois que sua licença de uso expirar. No entanto, quando os usuários aplicam permissões personalizadas (também conhecidas como uma política de direitos ad-hoc) e essas permissões precisam ser alteradas depois que o documento ou e-mail é protegido, esse conteúdo deve ser protegido novamente com as novas permissões. As permissões personalizadas para uma mensagem de email são implementadas com a opção Não Encaminhar.
O período de validade da licença de uso padrão para um locatário é de 30 dias e você pode configurar esse valor usando o cmdlet do PowerShell, Set-AipServiceMaxUseLicenseValidityTime. Você pode definir uma configuração mais restritiva para quando a proteção é aplicada usando um rótulo de confidencialidade configurado para atribuir permissões agora ou um modelo:
Quando você configura um rótulo de confidencialidade, o período de validade da licença de uso obtém seu valor da configuração Permitir acesso offline.
Para obter mais informações e orientações para definir essa configuração para um rótulo de confidencialidade, consulte a tabela de recomendações das instruções de como configurar permissões agora para um rótulo de confidencialidade.
Quando você configura um modelo usando o PowerShell, o período de validade da licença de uso obtém seu valor do parâmetro LicenseValidityDuration nos cmdlets Set-AipServiceTemplateProperty e Add-AipServiceTemplate .
Para obter mais informações e orientações para definir essa configuração usando o PowerShell, consulte a ajuda para cada cmdlet.
Consulte Também
- Restringir o acesso ao conteúdo usando rótulos de sensibilidade para aplicar criptografia
- Configuring super users for Azure Information Protection and discovery services or data recovery (Configurar superutilizadores para o Azure Information Protection e serviços de deteção ou recuperação de dados)