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

Descrição do serviço Microsoft Purview

Use as informações a seguir se quiser entender detalhadamente como o serviço do Azure Rights Management funciona. Você não precisa saber esse nível de informação para configurar ou aplicar as configurações de criptografia para proteger seus dados.

Um conceito importante a ser entendido sobre o serviço Azure Rights Management é que esse serviço não vê nem armazena seus dados como parte do processo de criptografia. As informações que você criptografa nunca são enviadas ou armazenadas no Azure, a menos que você as armazene explicitamente no Azure ou use outro serviço de nuvem que as armazene no Azure. O serviço do Azure Rights Management simplesmente torna os dados em um item ilegíveis para qualquer pessoa que não seja usuários e serviços autorizados:

• Os dados são criptografados no nível do aplicativo e incluem uma política que define o uso autorizado desse item.

• Quando um item criptografado é usado por um usuário legítimo ou é processado por um serviço autorizado, os dados no item são descriptografados e os direitos definidos na política são impostos.

Em um alto nível, você pode ver como esse processo funciona na imagem a seguir. Um documento que contém a fórmula secreta é criptografado e, em seguida, aberto com êxito por um usuário ou serviço autorizado. O documento é criptografado 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 arquivo onde é criptografada pela chave raiz do locatário do Azure Rights Management (a chave vermelha nesta imagem). Sua chave de locatário pode ser gerada e gerenciada pela Microsoft, ou você pode gerar e gerenciar sua própria chave de locatário.

Durante todo o processo criptografado, quando o serviço Azure Rights Management está criptografando e descriptografando, autorizando e impondo restrições, a fórmula secreta nunca é enviada ao Azure.

Para obter uma descrição detalhada do que está acontecendo, confira o passo a passo de como o serviço funciona: primeiro uso, criptografia de conteúdo, seção de consumo de conteúdo neste artigo.

Para obter detalhes sobre os algoritmos e comprimentos de chave que o serviço usa, consulte Controles criptográficos: algoritmos e comprimentos de chave.

Controles criptográficos: algoritmos e comprimentos de chave

Mesmo que você não precise saber em detalhes como essa tecnologia funciona, talvez seja questionado sobre os controles criptográficos que ela usa. Por exemplo, para confirmar se a criptografia é padrão do setor.

Nota de rodapé 1: 256 bits é usado pelo cliente de Proteção de Informações do Microsoft Purview nos seguintes cenários:

• Criptografia genérica (.pfile).

• Criptografia nativa para documentos PDF quando o documento foi criptografado com o padrão ISO para criptografia PDF ou o documento criptografado resultante tem uma extensão de nome de arquivo .ppdf.

• Criptografia nativa para arquivos 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. Há suporte para 1024 bits nos seguintes cenários opcionais:

• Durante uma migração do local, se o cluster do Active Directory Rights Management Services (AD RMS) estiver em execução no Modo Criptográfico 1.

• Para chaves arquivadas que foram criadas localmente antes da migração, para que o conteúdo que foi criptografado anteriormente pelo AD RMS possa continuar a ser aberto 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 email protegido pelo serviço Azure Rights Management, o serviço cria uma única chave AES (a "chave de conteúdo") e essa chave é incorporada ao documento e persiste por meio de edições do documento.

A chave de conteúdo é criptografada com a chave RSA da organização (a "chave de locatário do Azure Rights Management") como parte da política no documento, e a política também é assinada pelo autor do documento. Essa chave de locatário é comum a todos os documentos e emails protegidos pelo serviço Azure Rights Management para a organização e a chave de locatário só pode ser alterada por um administrador do serviço se a organização estiver usando uma chave de locatário gerenciada pelo cliente (conhecida como "traga sua própria chave" ou BYOK).

Essa chave de locatário está protegida nos serviços online da Microsoft, em um ambiente altamente controlado e sob monitoramento rigoroso. Quando você usa uma BYOK (chave de locatário gerenciada pelo cliente), essa segurança é reforçada pelo uso de uma matriz de HSMs (módulos de segurança de hardware) de última geração em cada região do Azure, sem a capacidade de as chaves serem extraídas, exportadas ou compartilhadas em nenhuma circunstância. Para obter mais informações sobre a chave de locatário e o BYOK, consulte Gerenciando a chave raiz do serviço Azure Rights Management.

As licenças e certificados enviados para um dispositivo Windows são criptografados com a chave privada do dispositivo do cliente. Essa chave privada é criada na primeira vez que um usuário no dispositivo usa o serviço Azure Rights Management. Essa chave privada, por sua vez, é criptografada com DPAPI no cliente, que protege esses segredos usando uma chave derivada da senha do usuário. Em dispositivos móveis, as chaves são usadas apenas uma vez, portanto, como não são armazenadas nos clientes, essas chaves não precisam ser criptografadas no dispositivo.

Passo a passo de como o serviço funciona: primeiro uso, criptografia de conteúdo, consumo de conteúdo

Para entender com mais detalhes como o serviço Azure Rights Management funciona, vamos percorrer um fluxo típico após a ativação do serviço Azure Rights Management e quando um usuário usa pela primeira vez o serviço Rights Management em seu computador Windows (um processo às vezes conhecido como inicialização do ambiente do usuário ou inicialização), criptografa o conteúdo (um documento ou email) e, em seguida, consome (abre e usa) conteúdo que foi criptografado por outra pessoa.

Depois que o ambiente do usuário é inicializado, esse usuário pode criptografar documentos ou consumir documentos criptografados nesse computador.

Inicializando o ambiente do usuário

Antes que um usuário possa criptografar conteúdo ou consumir conteúdo criptografado em um computador Windows, o ambiente do usuário deve estar preparado no dispositivo. Esse é um processo único e acontece automaticamente sem intervenção do usuário quando um usuário tenta criptografar ou consumir conteúdo criptografado:

O que acontece na etapa 1: O cliente do serviço Azure Rights Management executado no computador primeiro se conecta ao serviço e o serviço autentica o usuário usando sua conta do Microsoft Entra.

Quando a conta do usuário é federada com o Microsoft Entra ID, essa autenticação é automática e o usuário não é solicitado a fornecer credenciais.

O que acontece na etapa 2: depois que o usuário é autenticado, a conexão é redirecionada automaticamente para o locatário da organização, que emite certificados que permitem que o usuário se autentique no serviço Azure Rights Management para consumir conteúdo criptografado e criptografar conteúdo offline.

Um desses certificados é o certificado de conta de direitos. Esse certificado, geralmente abreviado como RAC, autentica o usuário no Microsoft Entra ID e é válido por 31 dias. O certificado é renovado automaticamente pelo cliente, desde que a conta de usuário ainda esteja no Microsoft Entra ID e a conta esteja habilitada. Esse certificado não é configurável por um administrador.

Uma cópia desse certificado é armazenada no Azure para que, se o usuário migrar para outro dispositivo, os certificados sejam criados usando as mesmas chaves.

Criptografia de conteúdo

Quando um usuário criptografa um documento, o cliente do serviço Azure Rights Management executa as seguintes ações em um documento não criptografado:

O que acontece na etapa 1: o cliente cria uma chave aleatória (a chave de conteúdo) e criptografa o documento usando essa chave com o algoritmo de criptografia simétrica AES.

O que acontece na etapa 2: o cliente cria um certificado que inclui uma política para o documento que inclui os direitos de uso para usuários ou grupos e outras restrições, como uma data de expiração. Essas configurações podem ser definidas com configurações de criptografia de rótulo de confidencialidade que um administrador configurou anteriormente ou especificou no momento em que o conteúdo é criptografado (às vezes chamadas de "permissões definidas pelo usuário" ou "política ad hoc").

O principal atributo do Microsoft Entra usado para identificar os usuários e grupos selecionados é o atributo ProxyAddresses do Microsoft Entra, que armazena todos os endereços de email de um usuário ou grupo. No entanto, se uma conta de usuário não tiver nenhum valor no atributo ProxyAddresses do AD, o valor UserPrincipalName do usuário será usado.

Em seguida, o cliente usa a chave da organização obtida quando o ambiente do usuário foi inicializado e usa essa chave para criptografar a política e a chave de conteúdo simétrica. O cliente também assina a política com o certificado do usuário que foi obtido quando o ambiente do usuário foi inicializado.

O que acontece na etapa 3: por fim, o cliente insere a política em um arquivo com o corpo do documento criptografado anteriormente, que, juntos, compõem um documento criptografado.

Esse documento pode ser armazenado em qualquer lugar ou compartilhado usando qualquer método, e a política sempre permanece com o documento criptografado.

Consumo de conteúdo

Quando um usuário deseja consumir um documento criptografado, o cliente começa solicitando acesso ao serviço Azure Rights Management:

O que acontece na etapa 1: o usuário autenticado envia a política de documentos e os certificados do usuário para o serviço Azure Rights Management. O serviço descriptografa e avalia a política e cria uma lista de direitos (se houver) que o usuário tem para o documento. Para identificar o usuário, o atributo ProxyAddresses do Microsoft Entra é usado para a conta do usuário e os grupos dos quais o usuário é membro. Por motivos de desempenho, a associação de grupo é armazenada em cache. Se a conta de usuário não tiver valores para o atributo Microsoft Entra ProxyAddresses, o valor no Microsoft Entra UserPrincipalName será usado em seu lugar.

O que acontece na etapa 2: o serviço extrai a chave de conteúdo do AES da política descriptografada. Essa chave é criptografada com a chave RSA pública do usuário que foi obtida com a solicitação.

A chave de conteúdo criptografada novamente é então incorporada a uma licença de uso criptografada com a lista de direitos do usuário, que é então devolvida ao cliente.

O que está acontecendo na etapa 3: Por fim, o cliente pega a licença de uso criptografado e a descriptografa com sua própria chave privada de usuário. Isso permite que o cliente descriptografe o corpo do documento conforme necessário e o renderize na tela.

O cliente também descriptografa a lista de direitos e os passa para o aplicativo, que impõe esses direitos na interface do usuário do aplicativo.

Variações

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

• Criptografia de Email: quando o Exchange Online e a Criptografia de Mensagens do Microsoft Purview são usados para criptografar mensagens de email, a autenticação para consumo também pode usar a federação com um provedor de identidade social ou usando uma senha de uso único. Em seguida, os fluxos de processo são muito semelhantes, exceto que o consumo de conteúdo ocorre no lado do serviço em uma sessão do navegador da Web em uma cópia temporariamente armazenada em cache do email de saída.

• Dispositivos móveis: quando dispositivos móveis criptografam ou consomem arquivos 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 usuário porque, em vez disso, cada transação (para criptografar ou consumir conteúdo) é independente. Assim como acontece com os computadores Windows, os dispositivos móveis se conectam ao serviço Azure Rights Management e se autenticam. Para criptografar conteúdo, os dispositivos móveis enviam uma política e o serviço do Azure Rights Management envia uma licença de publicação e uma chave simétrica para criptografar o documento. Para consumir conteúdo criptografado, quando os dispositivos móveis se conectam ao serviço do Azure Rights Management e se autenticam, eles enviam a política do documento para o serviço do Azure Rights Management e solicitam uma licença de uso para consumir o documento. Em resposta, o serviço do Azure Rights Management envia as chaves e restrições necessárias para os dispositivos móveis. Ambos os processos usam TLS para proteger a troca de chaves e outras comunicações.

• Conector do Rights Management: quando o serviço do Azure Rights Management é usado com o conector do Rights Management, os fluxos de processo permanecem os mesmos. A única diferença é que o conector atua como uma retransmissão entre os serviços locais (como o Exchange Server e o Servidor do SharePoint) e o serviço Azure Rights Management. O conector em si não executa nenhuma operação, como a inicialização do ambiente do usuário ou criptografia ou descriptografia. Ele simplesmente retransmite a comunicação que normalmente iria para um servidor AD RMS, manipulando a tradução entre os protocolos usados em cada lado. Este cenário permite que você use o serviço Azure Rights Management com serviços locais.

• Criptografia genérica (.pfile): quando o serviço do Azure Rights Management criptografa genericamente um arquivo, o fluxo é basicamente o mesmo para a criptografia de conteúdo, exceto que o cliente cria uma política que concede todos os direitos. Quando o arquivo é consumido, ele é descriptografado antes de ser passado para o aplicativo de destino. Esse cenário permite criptografar todos os arquivos, mesmo que eles não ofereçam suporte nativo ao serviço Azure Rights Management.

• Contas Microsoft: O serviço Azure Rights Management pode autorizar endereços de email para consumo quando eles são autenticados com uma conta Microsoft. No entanto, nem todos os aplicativos podem abrir conteúdo criptografado quando uma conta Microsoft é usada para autenticação. Cenários suportados para abrir documentos protegidos.

Próximas etapas

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

Se você estiver pronto para a implantação, as etapas recomendadas que incluem criptografia para proteger seus dados, consulte Implantar uma solução de proteção de informações com o Microsoft Purview.