Como o Azure RMS funciona? Nos bastidores

Algo importante de entender sobre o funcionamento do Azure RMS é que esse serviço de proteção de dados da Proteção de Informações do Azure não consulta nem armazena seus dados como parte do processo de proteção. As informações que você protege nunca são enviadas nem 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 transforma os dados em um documento ilegível para usuários e serviços que não sejam autorizados:

• Os dados são criptografados no nível do aplicativo e incluem uma política que define o uso autorizado desse 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 impostos.

Em linhas gerais, 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 sucesso por um usuário ou serviço autorizado. O documento é protegido por uma chave de conteúdo (a chave verde nesta imagem). Ela é exclusiva para cada documento e é colocada no cabeçalho do arquivo em que é protegida pela chave raiz do locatário da Proteção de Informações do Azure (a chave vermelha nesta imagem). A chave do locatário pode ser gerada e gerenciada pela Microsoft, ou você pode gerar e gerenciar sua própria chave de locatário.

Durante o processo de proteção, quando o Azure RMS está criptografando e descriptografando, autorizando e impondo 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 detalhadamente como essa tecnologia funciona, é possível que você seja interrogado sobre os controlos criptográficos que ela usa. Por exemplo, para confirmar que a proteção de segurança é padrão do setor.

Nota de rodapé 1

256 bits é usado pelo cliente da Proteção de Informações do Azure nos seguintes cenários:

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

• Proteção nativa para documentos PDF quando o documento tiver sido protegido com a norma ISO para criptografia PDF ou o documento protegido resultante tiver uma extensão do 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 está ativado. 1024 bits é compatível com os seguintes cenários opcionais:

• Durante uma migração do local quando o cluster do AD RMS é executado no Modo Criptográfico 1.

• Para chaves arquivadas que foram criadas localmente antes da migração, para que o conteúdo que era protegido anteriormente pelo AD RMS possa continuar a ser aberto pelo serviço Azure Rights Management após a migração.

Como as chaves de criptografia 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 é inserida no documento, persistindo após as edições do mesmo.

A chave de conteúdo é protegida com a chave RSA da organização (a "chave do 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 do locatário é comum a todos os documentos e emails protegidos pelo serviço Azure Rights Management da organização e ela só poderá ser alterada por um administrador da Proteção de Informações do Azure se a organização estiver usando uma chave do locatário gerenciada pelo cliente (conhecida como "Bring Your Own Key" ou BYOK).

Essa chave do locatário é protegida nos serviços online da Microsoft, em um ambiente altamente controlado e sob monitoramento rigoroso. Quando você usa uma chave do locatário gerenciada pelo cliente (BYOK), essa segurança é reforçada pelo uso de uma matriz de HSMs (módulos de segurança de hardware) de alto nível em cada região do Azure, sem a capacidade de extrair, exportar ou compartilhar as chaves em nenhuma circunstância. Para obter mais informações sobre a chave do locatário e o BYOK, consulte Planejando e implementando a sua chave de locatário da Proteção de Informações do Azure.

As licenças e os certificados que são enviados a um dispositivo Windows são protegidos com a chave privada do dispositivo do cliente, que é criada na primeira vez em que o usuário do dispositivo usa o Azure RMS. Esta chave privada, por sua vez, é protegida com a DPAPI (API de Proteção de Dados) 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 elas não são armazenadas nos clientes, elas 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 em mais detalhes como o Azure RMS funciona, vamos examinar 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 do Rights Management em seu computador Windows (um processo também conhecido como inicializar o ambiente do usuário ou inicialização), protege o conteúdo (um documento ou email) e, em seguida, consome (abre e usa) o conteúdo que foi protegido por outra pessoa.

Depois de inicializar o ambiente do usuário, esse usuário poderá proteger documentos ou consumir documentos protegidos nesse computador.

Inicializando o ambiente do usuário

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

O que acontece 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 ao Microsoft Entra ID, essa autenticação é automática e não é solicitado que o usuário insira credenciais.

O que acontece na etapa 2: depois que o usuário é autenticado, a conexão é automaticamente redirecionada para o locatário da Proteção de Informações do Azure da organização, que emite certificados que permitem que o usuário seja autenticado no serviço Azure Rights Management para consumir conteúdo protegido e proteger conteúdo offline.

Um desses certificados é o certificado de conta de direitos, frequentemente abreviado como RAC. Esse certificado autentica o usuário no Microsoft Entra ID e é válido por 31 dias. Ele é renovado automaticamente pelo cliente RMS, 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 do certificado é armazenada no Azure, portanto, se o usuário mudar para outro dispositivo, os certificados serão criados usando as mesmas chaves.

Proteção de conteúdo

Quando um usuário protege um documento, o cliente RMS realiza as seguintes ações em um documento não protegido:

O que acontece 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 acontece na etapa 2: o cliente RMS cria um certificado que inclui uma política para o documento com 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 em um modelo configurado previamente por um administrador ou especificadas no momento em que o conteúdo é protegido (processo também conhecido como "política ad hoc").

O atributo principal 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 do UserPrincipalName do usuário será usado em seu lugar.

Em seguida, o cliente RMS usará a chave da organização, que foi obtida quando o ambiente do usuário foi inicializado, para criptografar a política e a chave simétrica de conteúdo. O cliente RMS também assinará 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: finalmente, o cliente RMS insere a política em um arquivo com o corpo do documento já criptografado, que juntos, compõem um documento protegido.

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

Consumo de conteúdo

Quando o usuário quer consumir um documento protegido, primeiro o cliente RMS solicita o acesso ao serviço Azure Rights Management:

O que acontece na etapa 1: o usuário autenticado envia a política do documento 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 (caso haja alguma) 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 para os grupos dos quais ele é membro. Por motivos de desempenho, a associação a um grupo é armazenada em cache. Se a conta de usuário não tiver nenhum valor para o atributo ProxyAddresses do Microsoft Entra, será usado o valor do UserPrincipalName do Microsoft Entra.

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

A chave de conteúdo recriptografada é inserida em uma licença de uso criptografada com a lista de direitos do usuário que, em seguida, é devolvida ao cliente RMS.

O que acontece na etapa 3: finalmente, o cliente RMS obtém a licença de uso criptografada e descriptografa-a com sua própria chave privada do usuário. Isso permite que o cliente RMS descriptografe o corpo do documento, conforme o necessário, e renderize-o na tela.

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

Variações

As orientações anteriores cobrem os cenários normais, mas há algumas variações:

• Proteção de email: quando o Exchange Online e a Criptografia de Mensagens 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 uma senha de uso único. Depois, os fluxos de processo são muito semelhantes, exceto que o consumo de conteúdo acontece no lado do serviço em uma sessão do navegador da Web sobre uma cópia do email de saída armazenada em cache temporariamente.

• Dispositivos móveis: quando os dispositivos móveis protegem ou consomem arquivos com o serviço Azure Rights Management, os fluxos do processo são muito mais simples. Os dispositivos móveis não passam primeiro pelo processo de inicialização do usuário porque, nesse caso, cada transação (para proteger ou consumir conteúdo) é independente. Como com computadores Windows, os dispositivos móveis conectam-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 retorna uma licença de publicação e uma chave simétrica para proteger o documento. Para consumir o conteúdo, quando os dispositivos móveis se conectam ao serviço Azure Rights Management e se autenticam, eles enviam a política do documento 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. Os dois 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 do processo são 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 realiza nenhuma operação, como a inicialização do ambiente do usuário, a criptografia ou a descriptografia. Ele simplesmente retransmite a comunicação que geralmente seria enviada para um servidor AD RMS, manipulando a conversão entre os protocolos que são usados em cada lado. Este cenário permite usar o serviço Azure Rights Management com serviços locais.

• Proteção genérica (.pfile): quando o serviço Azure Rights Management protege um arquivo genericamente, o fluxo é basicamente o mesmo que o da proteção de conteúdo exceto que o cliente RMS cria uma política que concede todos os direitos. Quando o arquivo é consumido, ele é descriptografado antes de ser passado para o aplicativo de destino. Este cenário permite proteger todos os arquivos, mesmo que eles não sejam nativamente compatíveis com o RMS.

• Contas 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 Microsoft. No entanto, nem todos os aplicativos podem abrir conteúdo protegido quando uma conta Microsoft é usada para autenticação. Mais informações.

Próximas etapas

Para saber mais sobre o serviço Azure Rights Management, consulte os outros artigos da seção Entender e explorar, como Como os aplicativos permitem o serviço Azure Rights Management para saber como integrar seus aplicativos existentes ao Azure Rights Management para fornecer uma solução de proteção de informações.

Examine a Terminologia da Proteção de Informações do Azure para familiarizar-se com os termos que podem aparecer durante a configuração e o uso do serviço Azure Rights Management e confira também os Requisitos da Proteção de Informações do Azure antes de iniciar sua implantação. Se quiser começar diretamente e experimentá-lo por conta própria, use o início rápido e os tutoriais:

• Guia de início rápido: implantar o cliente de rotulagem unificada
• Tutorial: como instalar o identificador de rotulagem unificada da AIP (Proteção de Informações do Azure)
• Tutorial: como localizar conteúdo confidencial com o scanner da AIP (Proteção de Informações do Azure)
• Tutorial: como impedir o compartilhamento excessivo no Outlook usando a AIP (Proteção de Informações do Azure)

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