Como funciona o RMS do Azure? Não há nada a fazer

Uma coisa importante a compreender sobre como o Azure RMS funciona é que este serviço de proteção de dados do Azure Information Protection não vê nem armazena os seus dados como parte do processo de proteção. As informações que protege nunca são enviadas ou armazenadas no Azure, a menos que as armazene explicitamente no Azure ou utilize outro serviço em nuvem que as armazene no Azure. O Azure RMS torna simplesmente os dados num documento ilegíveis para outras pessoas além dos 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 documento.

• Quando um documento protegido é utilizado por um utilizador legítimo ou é processado por um serviço autorizado, os dados no documento são deciptados e os direitos definidos na política são aplicados.

Num nível elevado, pode ver como este processo funciona na imagem seguinte. 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 está protegido por uma chave de conteúdo (a tecla verde nesta imagem). É exclusiva para cada documento e é colocada no cabeçalho de ficheiro onde está protegida pela sua chave de raiz de inquilino do Azure Information Protection (a chave vermelha nesta imagem). A sua chave de inquilino pode ser gerida e gerida pela Microsoft ou pode gerar e gerir a sua própria chave de inquilino.

Ao longo do processo de proteção quando o Azure RMS está a encriptar e decifrar, 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, consulte a secção Instruções sobre como o Azure RMS funciona: Primeira utilização, proteção de conteúdos, consumo de conteúdos neste artigo.

Para obter detalhes técnicos sobre os algoritmos e os comprimentos de chave utilizados pelo Azure RMS, consulte a secção seguinte.

Controlos criptgráficos utilizados pelo Azure RMS: Algoritmos e comprimentos de teclas

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

Controlos criptgráficos	Utilizar no Azure RMS
Algoritmo: AES Comprimento da chave: 128 bits e 256 bits [1]	Proteção de conteúdos
Algoritmo: RSA Comprimento da chave: 2048 bits [2]	Proteção por chave
SHA-256	Assinatura de certificados

Nota de rodapé 1

O cliente de 256 bits é utilizado pelo Information Protection Azure nos seguintes cenários:

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

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

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

Nota de rodapé 2

A duração da chave é de 2048 bits quando o serviço Azure Rights Management é ativado. A opção de 1024 bits é suportada nos seguintes cenários opcionais:

• Durante uma migração a partir do local se o cluster AD RMS estiver a ser executada no Modo Criptgráfico 1.

• No caso das chaves arquivadas que foram criadas no local antes da migração, para que os conteúdos anteriormente protegidos pelo AD RMS possam continuar a ser abertos pelo serviço do 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 e-mail protegido pelo Azure RMS, o Azure RMS cria uma única chave AES (a "chave de conteúdo") e essa chave é incorporada no documento e perdura pelas edições do documento.

A chave de conteúdo está protegida com a chave RSA da organização (Information Protection chave de inquilino do Azure Information Protection) 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 protegidos pelo serviço de Gestão de Direitos do Azure para a organização e esta chave só pode ser alterada por um administrador do Azure Information Protection se a organização estiver a utilizar uma chave de inquilino gerida pelo cliente (conhecida como "trazer a sua própria chave" ou BYOK).

Esta chave de inquilino está protegida no sistema serviços online 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 através da utilização de uma matriz de módulos de segurança de hardware de alto-fim (HSMs) em cada região do Azure, sem a capacidade de extrair, exportar ou partilhar chaves em qualquer circunstância. Para obter mais informações sobre a chave de inquilino e a BYOK, consulte Planear e implementar a sua chave de inquilino do Azure Information Protection de inquilino.

As licenças e certificados enviados para um dispositivo Windows são protegidos com a chave privada do dispositivo cliente, que é criada quando um utilizador no dispositivo utiliza o Azure RMS pela primeira vez. Por sua vez, esta chave privada está protegida pela DPAPI no cliente, que protege estes segredos ao utilizar uma chave derivada da palavra-passe do utilizador. Nos dispositivos móveis, as chaves são utilizadas apenas uma vez, pelo que, uma vez que não estão armazenadas nos clientes, estas chaves não precisam de estar protegidas no dispositivo.

Walkthrough of how Azure RMS works: First use, content protection, content consumption

Para compreender mais detalhadamente como o Azure RMS funciona, vamos abordar um fluxo típico após o serviço do Azure Rights Management ser ativado e quando um utilizador utiliza pela primeira vez o serviço de Gestão de Direitos no seu computador Windows (um processo por vezes conhecido como inicializar o ambiente de utilizador ou o arranque), protege os conteúdos (um documento ou e-mail) e consome (abre e utiliza) conteúdo que foi protegido por outra pessoa.

Após o ambiente de utilizador ser inicializado, esse utilizador poderá então proteger documentos ou consumir documentos protegidos nesse computador.

Nota

Se este utilizador mudar para outro computador Windows computador ou outro utilizador utilizar o mesmo Windows computador, o processo de inicialização será repetido.

Inicializar o ambiente de utilizador

Antes de um utilizador poder proteger conteúdo ou consumir conteúdo protegido num Windows computador, o ambiente de utilizador tem de estar preparado no dispositivo. Este é um processo único e ocorre automaticamente sem intervenção do utilizador quando um utilizador tenta proteger ou consumir conteúdo protegido:

O que está a acontecer no passo 1: o cliente RMS no computador liga-se primeiro ao serviço Azure Rights Management e autentica o utilizador ao utilizar a Azure Active Directory conta.

Quando a conta do utilizador é federada com a Azure Active Directory, esta autenticação é automática e não são solicitadas credenciais ao utilizador.

O que está a acontecer no passo 2: após o utilizador ser autenticado, a ligação é automaticamente redirecionada para o inquilino do Azure Information Protection da organização, que emite certificados que permitam ao utilizador autenticar para o serviço Azure Rights Management para consumir conteúdo protegido e proteger conteúdo offline.

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

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

Proteção de conteúdos

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

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

O que está a acontecer no passo 2: o cliente RMS cria, em seguida, 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 num modelo que um administrador configurou anteriormente ou especificou no momento em que o conteúdo é protegido (por vezes denominado "política ad hoc").

O atributo principal do Azure AD utilizado para identificar os utilizadores e grupos selecionados é o atributo ProxyAddresses do Azure AD, 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 RMS 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 RMS 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 do RMS incorpora a política num ficheiro com o corpo do documento encriptado anteriormente, que, em conjunto, constituem um documento protegido.

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 pretender consumir um documento protegido, o cliente de RMS começa por pedir acesso ao serviço do Azure Rights Management:

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

O que está a acontecer no passo 2: o serviço extrai a chave de conteúdo AES da política decibrida. Esta chave é então encriptado com a chave RSA pública do utilizador que foi obtida com o pedido.

Em seguida, a chave de conteúdo encriptado é incorporada numa licença de utilização encriptado com a lista de direitos de utilizador, que é então devolvida ao cliente do RMS.

O que está a acontecer no passo 3: por fim, o cliente do RMS utiliza a licença de utilização encriptado e decifra-a com a sua própria chave privada de utilizador. Isto permite ao cliente RMS decibrir o corpo do documento conforme for necessário e comprimi-lo no ecrã.

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

Nota

Quando os utilizadores externos à sua organização consomem conteúdo que protegeu, o fluxo de consumo é o mesmo. O que muda para este cenário, é a forma como o utilizador é autenticado. Para obter mais informações, consulte Quando partilho um documento protegido com alguém fora da minha empresa, como é que esse utilizador é autenticado?

Variações

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

• Proteção de e-mail: Quando a Exchange Online e Office 365 a Encriptação de Mensagens com novas capacidades são utilizadas para proteger 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 de utilização única. Em seguida, os fluxos de processos são muito semelhantes, exceto que o consumo de conteúdo ocorre no lado do serviço numa sessão do browser numa cópia temporariamente em cache do e-mail de saída.

• Dispositivos móveis: Quando os dispositivos móveis protegem ou consomem ficheiros com o serviço Azure Rights Management, os fluxos de processos são muito 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 proteger ou consumir conteúdos) é independente. Tal como com os Windows, os dispositivos móveis ligam-se ao serviço Azure Rights Management e e autenticam. Para proteger conteúdos, 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 proteger o documento. Para consumir conteúdos, quando os dispositivos móveis se ligam ao serviço Azure Rights Management e e se autenticam, enviam a política de documento para o serviço Azure Rights Management e pedem uma licença de utilização para utilizar o documento. Em resposta, o serviço Azure Rights Management envia as chaves e restrições necessárias aos dispositivos móveis. Ambos os processos utilizam o TLS para proteger a principal troca e outras comunicações.

• Conector RMS: quando o serviço Azure Rights Management é utilizado com o conector RMS, os fluxos de processo permanecem iguais. A única diferença é que o conector atua como um reenabrimento entre os serviços no local (como o Exchange Server e o SharePoint Server) e o serviço Azure Rights Management. A conexão em si não efetua quaisquer operações, como a inicialização do ambiente de utilizador, nem encriptação ou decifração. Este processo recorre simplesmente à comunicação que normalmente vai para um servidor AD RMS, tratando da tradução entre os protocolos utilizados em cada lado. Este cenário permite-lhe utilizar o serviço do Azure Rights Management com serviços no local.

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

• Contas Microsoft: O Azure Information Protection 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 protegido quando uma conta Microsoft é utilizada para autenticação. Mais informações.

Passos seguintes

Para saber mais sobre o serviço Azure Rights Management, utilize os outros artigos na secção Compreender o Explore, como Como as aplicações suportam o serviço Azure Rights Management para saber como as suas aplicações existentes podem ser integradas & com o Azure Rights Management para fornecer uma solução de proteção de informações.

Reveja a terminologia do Azure Information Protection para que esteja familiarizado com os termos que poderá encontrar à medida que está a configurar e a utilizar o serviço Azure Rights Management e certifique-se de que também verifica os Requisitos do Azure Information Protection antes de iniciar a implementação. Se quiser começar e experimentar, utilize o guia de introdução e tutoriais:

• Guia de Inserção: Implementar o cliente de etiquetagem unificado
• Tutorial: Instalar o scanner de etiquetas unificado Information Protection Azure Information Protection (AIP)
• Tutorial: Encontrar os seus conteúdos confidenciais com o scanner do Azure Information Protection (AIP)
• Tutorial: Impedir a oversharing Outlook utilizar o Azure Information Protection (AIP)

Se estiver pronto para começar a implementar a proteção de dados para a sua organização, utilize as informações gerais de implementação da AIP para classificação, etiquetagem e proteção para os seus passos de implementação e ligações para instruções de utilização.

Sugestão

Para obter informações adicionais e ajuda, utilize os recursos e ligações em Informações e suporte para o Azure Information Protection.