Como funciona o Azure RMS? Under the hood (Como funciona o Azure RMS? Nos bastidores)

Uma coisa importante a entender sobre como o Azure RMS funciona é que esse serviço de proteção de dados da Proteção de Informações do Azure não vê nem armazena seus dados como parte do processo de proteção. As informações que você protege 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 Azure RMS simplesmente torna os dados em um documento ilegíveis para qualquer pessoa além de 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 para esse documento.

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

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 é protegido e, em seguida, aberto com êxito por um utilizador ou serviço autorizado. O documento é protegido por uma chave de conteúdo (a chave verde nesta imagem). Ele é exclusivo para cada documento e é colocado no cabeçalho do arquivo, onde é protegido pela chave raiz do locatário da Proteção de Informações do Azure (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 de proteção quando o Azure RMS está criptografando e descriptografando, autorizando e aplicando restrições, a fórmula secreta nunca é enviada para o Azure.

Para obter uma descrição detalhada do que está acontecendo, consulte a seção Passo a passo de como o Azure RMS funciona: Primeiro uso, proteção de conteúdo, consumo de conteúdo neste artigo.

Para obter detalhes técnicos sobre os algoritmos e comprimentos de chave que o Azure RMS usa, consulte a próxima seção.

Controles criptográficos usados pelo Azure RMS: algoritmos e comprimentos de chave

Mesmo que você não precise saber em detalhes como essa tecnologia funciona, você pode ser perguntado sobre os controles criptográficos que ela usa. Por exemplo, para confirmar que a proteção de segurança é padrão do setor.

Controles criptográficos	Uso no Azure RMS
Algoritmo: AES Comprimento da chave: 128 bits e 256 bits [1]	Proteção de conteúdo
Algoritmo: RSA Comprimento da chave: 2048 bits [2]	Proteção de chaves
SHA-256	Assinatura do certificado

Nota de rodapé 1

256 bits é usado pelo cliente do Azure Information Protection nos seguintes cenários:

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

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

• Proteção 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. 1024 bits são suportados para os seguintes cenários opcionais:

• Durante uma migração do local se o cluster 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 o conteúdo anteriormente protegido pelo AD RMS possa continuar a ser aberto pelo serviço Azure Rights Management após a migração.

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

Para cada documento ou email protegido pelo Azure RMS, o Azure RMS cria uma única chave AES (a "chave de conteúdo"), e essa chave é incorporada ao documento e persiste através de edições do documento.

A chave de conteúdo é protegida com a chave RSA da organização (a "chave de locatário da Proteção de Informações do Azure") 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 essa chave só pode ser alterada por um administrador da Proteção de Informações do Azure se a organização estiver usando uma chave de locatário gerenciada pelo cliente (conhecida como "traga sua própria chave" ou BYOK).

Esta chave de inquilino está protegida nos serviços online da Microsoft, num ambiente altamente controlado e sob monitorização apertada. Quando você usa uma chave de locatário gerenciada pelo cliente (BYOK), essa segurança é aprimorada pelo uso de uma matriz de HSMs (módulos de segurança de hardware) high-end 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 Planejando e implementando sua chave de locatário da Proteção de Informações do Azure.

As licenças e certificados enviados para um dispositivo Windows são protegidos com a chave privada do dispositivo do cliente, que é criada na primeira vez que um utilizador no dispositivo utiliza o Azure RMS. Essa chave privada, por sua vez, é protegida 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 protegidas no dispositivo.

Passo a passo de como o Azure RMS funciona: Primeiro uso, proteção de conteúdo, consumo de conteúdo

Para entender com mais detalhes como o Azure RMS funciona, vamos percorrer um fluxo típico depois que o serviço Azure Rights Management é ativado e quando um usuário usa pela primeira vez o serviço Rights Management em seu computador Windows (um processo às vezes conhecido como inicializar o ambiente do usuário ou inicializar), protege o conteúdo (um documento ou email) e, em seguida , consome (abre e usa) conteúdo que foi protegido por outra pessoa.

Depois que o ambiente do usuário for inicializado, esse usuário poderá proteger documentos ou consumir documentos protegidos nesse computador.

Nota

Se esse usuário for movido para outro computador Windows ou outro usuário usar esse mesmo computador Windows, o processo de inicialização será repetido.

Inicializando o ambiente do usuário

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

O que está acontecendo na etapa 1: O cliente RMS no computador primeiro se conecta ao serviço Azure Rights Management e 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 está acontecendo na etapa 2: depois que o usuário é autenticado, a conexão é redirecionada automaticamente para o locatário da Proteção de Informações do Azure da organização, que emite certificados que permitem que o usuário se autentique no serviço Azure Rights Management para consumir conteúdo protegido e proteger o conteúdo offline.

Um desses certificados é o certificado de conta de direitos, muitas vezes abreviado para RAC. Este certificado autentica o usuário no Microsoft Entra ID e é válido por 31 dias. O certificado é renovado automaticamente pelo cliente RMS, 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 desse certificado é armazenada no Azure para que, se o usuário for movido para outro dispositivo, os certificados sejam criados usando as mesmas chaves.

Proteção de conteúdo

Quando um utilizador protege um documento, o cliente RMS executa as seguintes ações num documento desprotegido:

O que está acontecendo na etapa 1: O cliente RMS 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 está acontecendo na etapa 2: Em seguida, o cliente RMS 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 validade. Essas configurações podem ser definidas em um modelo que um administrador configurou anteriormente ou especificado no momento em que o conteúdo é protegido (às vezes chamado de "política ad hoc").

O principal atributo do Microsoft Entra usado para identificar os usuários e grupos selecionados é o atributo Microsoft Entra ProxyAddresses, 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 RMS usa a chave da organização que foi 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 RMS 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 está acontecendo na etapa 3: Finalmente, o cliente RMS incorpora a política em um arquivo com o corpo do documento criptografado anteriormente, que juntos compõem um documento protegido.

Este 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údos

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

O que está acontecendo 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 Microsoft Entra ProxyAddresses é usado para a conta do usuário e grupos aos quais o usuário é membro. Por motivos de desempenho, a associação ao 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 vez disso.

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

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

O que está acontecendo na etapa 3: Finalmente, o cliente RMS pega a licença de uso criptografado e a descriptografa com sua própria chave privada de usuário. Isso permite que o cliente RMS 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.

Nota

Quando os usuários externos à sua organização consomem conteúdo que você protegeu, o fluxo de consumo é o mesmo. O que muda nesse cenário é como o usuário é autenticado. Para obter mais informações, consulte Quando compartilho um documento protegido com alguém fora da minha empresa, como esse usuário é autenticado?

Variações

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

• Proteção de email: quando o Exchange Online e a Criptografia de Mensagem do Office 365 com novos recursos são usados para proteger 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 acontece do lado do serviço em uma sessão do navegador da Web em uma cópia temporariamente armazenada em cache do e-mail de saída.

• Dispositivos móveis: quando os dispositivos móveis protegem ou consomem arquivos com o serviço Azure Rights Management, os fluxos de processo são muito 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 proteger 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 proteger o conteúdo, os dispositivos móveis enviam uma política e o serviço Azure Rights Management envia-lhes uma licença de publicação e uma chave simétrica para proteger o documento. Para consumir conteúdo, quando os dispositivos móveis se conectam ao serviço Azure Rights Management e se autenticam, eles enviam a política de documentos para o serviço Azure Rights Management e solicitam uma licença de uso 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 usam TLS para proteger a troca de chaves e outras comunicações.

• Conector RMS: Quando o serviço Azure Rights Management é usado com o conector RMS, 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 SharePoint Server) 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 que são usados em cada lado. Este cenário permite que você use o serviço Azure Rights Management com serviços locais.

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

• Contas da Microsoft: a Proteção de Informações do Azure pode autorizar endereços de email para consumo quando eles são 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.

Próximos passos

Para saber mais sobre o serviço Azure Rights Management, use os outros artigos na seção Compreender & Explore , como Como os aplicativos dão suporte ao serviço Azure Rights Management para saber como seus aplicativos existentes podem se integrar ao Azure Rights Management para fornecer uma solução de proteção de informações.

Revise a Terminologia da Proteção de Informações do Azure para que você esteja familiarizado com os termos que você pode encontrar ao configurar e usar o serviço Azure Rights Management e verifique também os Requisitos da Proteção de Informações do Azure antes de iniciar a implantação. Se você quiser mergulhar e experimentá-lo por si mesmo, use o início rápido e tutoriais:

• Guia de início rápido: implantar o cliente de etiquetagem unificada
• Tutorial: Instalando o scanner de etiquetagem unificada da Proteção de Informações do Azure (AIP)
• Tutorial: Localizando seu conteúdo confidencial com o mecanismo de varredura da Proteção de Informações do Azure (AIP)
• Tutorial: Impedindo o compartilhamento excessivo no Outlook usando a Proteção de Informações do Azure (AIP)

Se você estiver pronto para começar a implantar a proteção de dados para sua organização, use o roteiro de implantação do AIP para classificação, rotulagem e proteção para suas etapas de implantação e links para obter instruções de instruções.