Como funciona o serviço Azure Rights Management: Detalhes técnicos

Utilize as seguintes informações se quiser compreender detalhadamente como funciona o serviço Azure Rights Management . Não precisa de saber este nível de informações para configurar ou aplicar as definições de encriptação para proteger os seus dados.

Um conceito importante a compreender sobre o serviço Azure Rights Management é que este serviço não vê nem armazena os seus dados como parte do processo de encriptação. As informações encriptadas nunca são enviadas ou armazenadas no Azure, a menos que as armazene explicitamente no Azure ou utilize outro serviço cloud que as armazene no Azure. O serviço Azure Rights Management torna os dados num item ilegíveis para qualquer pessoa que não seja utilizadores e serviços autorizados:

• Os dados são encriptados ao nível da aplicação e incluem uma política que define a utilização autorizada para esse item.

• Quando um item encriptado é utilizado por um utilizador legítimo ou processado por um serviço autorizado, os dados no item são desencriptados e os direitos definidos na política são impostos.

A um nível elevado, pode ver como este processo funciona na imagem seguinte. Um documento que contém a fórmula secreta é encriptado e, em seguida, aberto com êxito por um utilizador ou serviço autorizado. O documento é encriptado por uma chave de conteúdo (a chave verde nesta imagem). A chave de conteúdo é exclusiva para cada documento e é colocada no cabeçalho do ficheiro onde é encriptada pela chave de raiz do inquilino do Azure Rights Management (a chave vermelha nesta imagem). A sua chave de inquilino pode ser gerada e gerida pela Microsoft ou pode gerar e gerir a sua própria chave de inquilino.

Ao longo do processo encriptado quando o serviço Azure Rights Management está a encriptar e desencriptar, autorizar e impor restrições, a fórmula secreta nunca é enviada para o Azure.

Para obter uma descrição detalhada do que está a acontecer, veja a secção Instruções sobre como o serviço funciona: Primeira utilização, encriptação de conteúdo, consumo de conteúdos neste artigo.

Para obter detalhes sobre os algoritmos e os comprimentos de chave que o serviço utiliza, veja a secção seguinte.

Controlos criptográficos: algoritmos e comprimentos de chave

Mesmo que não precise de saber detalhadamente como funciona esta tecnologia, poderá ser-lhe perguntado sobre os controlos criptográficos que utiliza. Por exemplo, para confirmar que a encriptação é padrão da indústria.

Nota de rodapé 1

Os 256 bits são utilizados pelo cliente Proteção de Informações do Microsoft Purview nos seguintes cenários:

• Encriptação genérica (.pfile).

• Encriptação nativa para documentos PDF quando o documento tiver sido encriptado com a norma ISO para encriptação PDF ou o documento encriptado resultante tiver uma extensão de nome de ficheiro .ppdf.

• Encriptação nativa para ficheiros de texto ou imagem (como .ptxt ou .pjpg).

Nota de rodapé 2

2048 bits é o comprimento da chave quando o serviço Azure Rights Management é ativado. Os 1024 bits são suportados para os seguintes cenários opcionais:

• Durante uma migração a partir do local, se o cluster do AD RMS estiver em execução no Modo Criptográfico 1.

• Para chaves arquivadas que foram criadas no local antes da migração, para que os conteúdos anteriormente encriptados pelo AD RMS possam continuar a ser abertos pelo serviço Azure Rights Management após a migração.

Como as chaves criptográficas são armazenadas e protegidas

Para cada documento ou e-mail protegido pelo serviço Azure Rights Management, o serviço cria uma única chave AES (a "chave de conteúdo") e essa chave é incorporada no documento e persiste através das edições do documento.

A chave de conteúdo é encriptada com a chave RSA da organização (a "chave de inquilino do Azure Rights Management") como parte da política no documento e a política também é assinada pelo autor do documento. Esta chave de inquilino é comum a todos os documentos e e-mails que estão protegidos pelo serviço Azure Rights Management para a organização e esta chave só pode ser alterada por um administrador do serviço se a organização estiver a utilizar uma chave de inquilino gerida pelo cliente (conhecida como "traga a sua própria chave" ou BYOK).

Esta chave de inquilino está protegida no serviços online da Microsoft, num ambiente altamente controlado e sob monitorização próxima. Quando utiliza uma chave de inquilino gerida pelo cliente (BYOK), esta segurança é melhorada pela utilização de uma matriz de módulos de segurança de hardware (HSMs) de alta gama em cada região do Azure, sem a capacidade de extrair, exportar ou partilhar as chaves em qualquer circunstância. Para obter mais informações sobre a chave de inquilino e o BYOK, veja Managing the root key for your Azure Rights Management service (Gerir a chave de raiz do serviço Azure Rights Management).

As licenças e certificados enviados para um dispositivo Windows são encriptados com a chave privada do dispositivo do cliente. Esta chave privada é criada da primeira vez que um utilizador no dispositivo utiliza o serviço Azure Rights Management. Esta chave privada, por sua vez, é encriptada com DPAPI no cliente, que protege estes segredos através de uma chave derivada da palavra-passe do utilizador. Nos dispositivos móveis, as chaves são utilizadas apenas uma vez, pelo que, como não são armazenadas nos clientes, estas chaves não precisam de ser encriptadas no dispositivo.

Instruções sobre como o serviço funciona: Primeira utilização, encriptação de conteúdo, consumo de conteúdo

Para compreender mais detalhadamente como funciona o serviço Azure Rights Management, vamos percorrer um fluxo típico depois de o serviço Azure Rights Management ser ativado e quando um utilizador utiliza pela primeira vez o serviço Rights Management a partir do respetivo computador Windows (um processo por vezes conhecido como inicialização do ambiente de utilizador ou bootstrapping), encripta o conteúdo (um documento ou e-mail), e, em seguida, consome (abre e utiliza) conteúdos que foram encriptados por outra pessoa.

Após a inicialização do ambiente de utilizador, esse utilizador pode encriptar documentos ou consumir documentos encriptados nesse computador.

Inicializar o ambiente de utilizador

Antes de um utilizador poder encriptar conteúdo ou consumir conteúdo encriptado num computador Windows, o ambiente de utilizador tem de ser preparado no dispositivo. Trata-se de um processo único e ocorre automaticamente sem intervenção do utilizador quando um utilizador tenta encriptar ou consumir conteúdo encriptado:

O que está a acontecer no passo 1: o cliente do serviço Azure Rights Management que é executado no computador liga-se primeiro ao serviço e o serviço autentica o utilizador com a respetiva conta de Microsoft Entra.

Quando a conta do utilizador é federada com Microsoft Entra ID, esta autenticação é automática e não são pedidas credenciais ao utilizador.

O que acontece no passo 2: após a autenticação do utilizador, a ligação é automaticamente redirecionada para o inquilino da organização, que emite certificados que permitem ao utilizador autenticar-se no serviço Azure Rights Management para consumir conteúdo encriptado e encriptar conteúdo offline.

Um destes certificados é o certificado de conta de direitos, muitas vezes abreviado para RAC. Este certificado autentica o utilizador para Microsoft Entra ID e é válido durante 31 dias. O certificado é renovado automaticamente pelo cliente, desde que a conta de utilizador ainda esteja no Microsoft Entra ID e a conta esteja ativada. Este certificado não é configurável por um administrador.

Uma cópia deste certificado é armazenada no Azure para que, se o utilizador mudar para outro dispositivo, os certificados sejam criados com as mesmas chaves.

Encriptação de conteúdo

Quando um utilizador encripta um documento, o cliente do serviço Azure Rights Management executa as seguintes ações num documento não encriptado:

O que está a acontecer no passo 1: o cliente cria uma chave aleatória (a chave de conteúdo) e encripta o documento com esta chave com o algoritmo de encriptação simétrica AES.

O que está a acontecer no passo 2: o cliente cria um certificado que inclui uma política para o documento que inclui os direitos de utilização para utilizadores ou grupos e outras restrições, como uma data de expiração. Estas definições podem ser definidas com definições de encriptação de etiquetas de confidencialidade que um administrador configurou anteriormente ou especificadas no momento em que o conteúdo é encriptado (por vezes referido como "permissões definidas pelo utilizador" ou uma "política ad hoc").

O atributo principal Microsoft Entra utilizado para identificar os utilizadores e grupos selecionados é o atributo Microsoft Entra ProxyAddresses, que armazena todos os endereços de e-mail de um utilizador ou grupo. No entanto, se uma conta de utilizador não tiver valores no atributo AD ProxyAddresses, é utilizado o valor UserPrincipalName do utilizador.

Em seguida, o cliente utiliza a chave da organização que foi obtida quando o ambiente de utilizador foi inicializado e utiliza esta chave para encriptar a política e a chave de conteúdo simétrico. O cliente também assina a política com o certificado do utilizador que foi obtido quando o ambiente de utilizador foi inicializado.

O que está a acontecer no passo 3: por fim, o cliente incorpora a política num ficheiro com o corpo do documento encriptado anteriormente, que, em conjunto, compõem um documento encriptado.

Este documento pode ser armazenado em qualquer lugar ou partilhado através de qualquer método e a política permanece sempre com o documento encriptado.

Consumo de conteúdo

Quando um utilizador quer consumir um documento encriptado, o cliente começa por pedir acesso ao serviço Azure Rights Management:

O que está a acontecer no passo 1: o utilizador autenticado envia a política de documentos e os certificados do utilizador para o serviço Azure Rights Management. O serviço desencripta e avalia a política e cria uma lista de direitos (se aplicável) que o utilizador tem para o documento. Para identificar o utilizador, o atributo Microsoft Entra ProxyAddresses é utilizado para a conta do utilizador e os grupos aos quais o utilizador é membro. Por motivos de desempenho, a associação a grupos é colocada em cache. Se a conta de utilizador não tiver valores para o atributo Microsoft Entra ProxyAddresses, é utilizado o valor no Microsoft Entra UserPrincipalName.

O que está a acontecer no passo 2: o serviço extrai a chave de conteúdo AES da política desencriptada. Em seguida, esta chave é encriptada com a chave RSA pública do utilizador que foi obtida com o pedido.

A chave de conteúdo encriptada novamente é incorporada numa licença de utilização encriptada com a lista de direitos de utilizador, que é devolvida ao cliente.

O que está a acontecer no passo 3: por fim, o cliente utiliza a licença de utilização encriptada e desencripta-a com a sua própria chave privada de utilizador. Isto permite ao cliente desencriptar o corpo do documento conforme for necessário e compõe-o no ecrã.

O cliente também desencripta a lista de direitos e transmite-a para a aplicação, que impõe esses direitos na interface de utilizador da aplicação.

Variações

As instruções anteriores abrangem os cenários padrão, mas existem algumas variações:

• Email encriptação: quando Exchange Online e Criptografia de Mensagens do Microsoft Purview são utilizados para encriptar mensagens de e-mail, a autenticação para consumo também pode utilizar a federação com um fornecedor de identidade social ou através de um código de acesso único. Em seguida, os fluxos do processo são muito semelhantes, exceto que o consumo de conteúdo ocorre do lado do serviço numa sessão do browser através de uma cópia temporariamente colocada em cache do e-mail de saída.

• Dispositivos móveis: quando os dispositivos móveis encriptam ou consomem ficheiros com o serviço Azure Rights Management, os fluxos de processo são mais simples. Os dispositivos móveis não passam primeiro pelo processo de inicialização do utilizador porque, em vez disso, cada transação (para encriptar ou consumir conteúdo) é independente. Tal como acontece com os computadores Windows, os dispositivos móveis ligam-se ao serviço Azure Rights Management e autenticam-se. Para encriptar conteúdo, os dispositivos móveis submetem uma política e o serviço Azure Rights Management envia-lhes uma licença de publicação e uma chave simétrica para encriptar o documento. Para consumir conteúdo encriptado, quando os dispositivos móveis se ligam ao serviço Azure Rights Management e se autenticam, enviam a política de documentos para o serviço Azure Rights Management e pedem uma licença de utilização para consumir o documento. Em resposta, o serviço Azure Rights Management envia as chaves e restrições necessárias para os dispositivos móveis. Ambos os processos utilizam o TLS para proteger a troca de chaves e outras comunicações.

• Conector Rights Management: quando o serviço Azure Rights Management é utilizado com o conector Rights Management, os fluxos de processo permanecem os mesmos. A única diferença é que o conector funciona como um reencaminhamento entre os serviços no local (como Exchange Server e o SharePoint Server) e o serviço Azure Rights Management. O conector em si não efetua operações, como a inicialização do ambiente do utilizador ou a encriptação ou desencriptação. Simplesmente reencaminha a comunicação que normalmente iria para um servidor do AD RMS, ao processar a tradução entre os protocolos que são utilizados em cada lado. Este cenário permite-lhe utilizar o serviço Azure Rights Management com serviços no local.

• Encriptação genérica (.pfile): quando o serviço Azure Rights Management encripta genericamente um ficheiro, o fluxo é basicamente o mesmo para a encriptação de conteúdo, exceto que o cliente cria uma política que concede todos os direitos. Quando o ficheiro é consumido, é desencriptado antes de ser transmitido para a aplicação de destino. Este cenário permite-lhe encriptar todos os ficheiros, mesmo que não suportem nativamente o serviço Azure Rights Management.

• Contas Microsoft: o serviço Azure Rights Management pode autorizar endereços de e-mail para consumo quando são autenticados com uma conta Microsoft. No entanto, nem todas as aplicações podem abrir conteúdo encriptado quando uma conta Microsoft é utilizada para autenticação. Mais informações.

Próximas etapas

Para obter uma descrição geral menos técnica do serviço Azure Rights Management, veja Saiba mais sobre o serviço Azure Rights Management.

Se estiver pronto para implementar os passos recomendados que incluem encriptação para proteger os seus dados, veja Implementar uma solução de proteção de informações com o Microsoft Purview.