Funcionamiento del servicio Azure Rights Management: Detalles técnicos

Use la siguiente información si desea comprender en profundidad cómo funciona el servicio de Azure Rights Management. No es necesario conocer este nivel de información para configurar o aplicar la configuración de cifrado para proteger los datos.

Un concepto importante para comprender el servicio Azure Rights Management es que este servicio no ve ni almacena los datos como parte del proceso de cifrado. La información que cifra nunca se envía ni almacena en Azure, a menos que la almacene explícitamente en Azure o use otro servicio en la nube que la almacene en Azure. El servicio Azure Rights Management simplemente hace que los datos de un elemento sean ilegibles para cualquier persona que no sea usuarios y servicios autorizados:

• Los datos se cifran en el nivel de aplicación e incluyen una directiva que define el uso autorizado para ese elemento.

• Cuando un usuario legítimo usa un elemento cifrado o lo procesa un servicio autorizado, los datos del elemento se descifran y se aplican los derechos definidos en la directiva.

En un nivel alto, puede ver cómo funciona este proceso en la siguiente imagen. Un documento que contiene la fórmula secreta se cifra y, a continuación, un usuario o servicio autorizado lo abre correctamente. El documento se cifra mediante una clave de contenido (la clave verde de esta imagen). La clave de contenido es única para cada documento y se coloca en el encabezado de archivo donde está cifrada por la clave raíz del inquilino de Azure Rights Management (la clave roja de esta imagen). Microsoft puede generar y administrar la clave de inquilino, o bien puede generar y administrar su propia clave de inquilino.

A lo largo del proceso cifrado cuando el servicio de Azure Rights Management cifra y descifra, autoriza y aplica restricciones, la fórmula secreta nunca se envía a Azure.

Para obtener una descripción detallada de lo que sucede, consulte la sección Tutorial sobre cómo funciona el servicio: Primer uso, cifrado de contenido y consumo de contenido de este artículo.

Para obtener más información sobre los algoritmos y las longitudes de clave que usa el servicio, consulte la sección siguiente.

Controles criptográficos: algoritmos y longitudes de clave

Incluso si no necesita saber en detalle cómo funciona esta tecnología, es posible que se le pregunte sobre los controles criptográficos que usa. Por ejemplo, para confirmar que el cifrado es estándar del sector.

Nota al pie 1

El cliente de Microsoft Purview Information Protection usa 256 bits en los siguientes escenarios:

• Cifrado genérico (.pfile).

• Cifrado nativo para documentos PDF cuando el documento se ha cifrado con el estándar ISO para el cifrado PDF, o el documento cifrado resultante tiene una extensión de nombre de archivo .ppdf.

• Cifrado nativo para archivos de texto o imagen (como .ptxt o .pjpg).

Nota al pie 2

2048 bits es la longitud clave cuando se activa el servicio de Azure Rights Management. Se admiten 1024 bits para los siguientes escenarios opcionales:

• Durante una migración desde el entorno local si el clúster de AD RMS se ejecuta en modo criptográfico 1.

• En el caso de las claves archivadas que se crearon localmente antes de la migración, el servicio Azure Rights Management después de la migración puede seguir abriendo el contenido cifrado previamente por AD RMS.

Cómo se almacenan y protegen las claves criptográficas

Para cada documento o correo electrónico protegido por el servicio de Azure Rights Management, el servicio crea una única clave AES (la "clave de contenido") y esa clave se inserta en el documento y se conserva a través de ediciones del documento.

La clave de contenido se cifra con la clave RSA de la organización (la "clave de inquilino de Azure Rights Management") como parte de la directiva del documento, y la directiva también está firmada por el autor del documento. Esta clave de inquilino es común a todos los documentos y correos electrónicos protegidos por el servicio de Azure Rights Management para la organización y esta clave solo la puede cambiar un administrador para el servicio si la organización usa una clave de inquilino administrada por el cliente (conocida como "traiga su propia clave" o BYOK).

Esta clave de inquilino está protegida en el servicios en línea de Microsoft, en un entorno altamente controlado y bajo supervisión estrecha. Cuando se usa una clave de inquilino administrada por el cliente (BYOK), esta seguridad se mejora mediante el uso de una matriz de módulos de seguridad de hardware (HSM) de alta gama en cada región de Azure, sin la capacidad de extraer, exportar o compartir las claves bajo ninguna circunstancia. Para obtener más información sobre la clave de inquilino y BYOK, consulte Administración de la clave raíz para el servicio de Azure Rights Management.

Las licencias y certificados que se envían a un dispositivo Windows se cifran con la clave privada del dispositivo del cliente. Esta clave privada se crea la primera vez que un usuario del dispositivo usa el servicio Azure Rights Management. Esta clave privada, a su vez, se cifra con DPAPI en el cliente, que protege estos secretos mediante una clave derivada de la contraseña del usuario. En los dispositivos móviles, las claves solo se usan una vez, por lo que, dado que no se almacenan en los clientes, estas claves no necesitan cifrarse en el dispositivo.

Tutorial sobre cómo funciona el servicio: primer uso, cifrado de contenido, consumo de contenido

Para comprender con más detalle cómo funciona el servicio Azure Rights Management, vamos a recorrer un flujo típico después de activar el servicio Azure Rights Management y cuando un usuario usa por primera vez el servicio Rights Management desde su equipo Windows (un proceso que a veces se conoce como inicialización del entorno de usuario o arranque), cifra el contenido. (un documento o correo electrónico) y, a continuación, consume (abre y usa) contenido que ha sido cifrado por otra persona.

Una vez inicializado el entorno de usuario, ese usuario puede cifrar documentos o consumir documentos cifrados en ese equipo.

Inicialización del entorno de usuario

Antes de que un usuario pueda cifrar contenido o consumir contenido cifrado en un equipo Windows, el entorno de usuario debe estar preparado en el dispositivo. Se trata de un proceso único y se produce automáticamente sin intervención del usuario cuando un usuario intenta cifrar o consumir contenido cifrado:

Lo que sucede en el paso 1: el cliente del servicio de Azure Rights Management que se ejecuta en el equipo se conecta primero al servicio y el servicio autentica al usuario mediante su cuenta de Microsoft Entra.

Cuando la cuenta del usuario está federada con Microsoft Entra identificador, esta autenticación es automática y no se le piden credenciales al usuario.

Lo que sucede en el paso 2: una vez autenticado el usuario, la conexión se redirige automáticamente al inquilino de la organización, que emite certificados que permiten al usuario autenticarse en el servicio Azure Rights Management con el fin de consumir contenido cifrado y cifrar el contenido sin conexión.

Uno de estos certificados es el certificado de cuenta de derechos, a menudo abreviado a RAC. Este certificado autentica al usuario para Microsoft Entra identificador y es válido durante 31 días. El cliente renueva automáticamente el certificado, siempre que la cuenta de usuario siga en Microsoft Entra identificador y la cuenta esté habilitada. Un administrador no puede configurar este certificado.

Una copia de este certificado se almacena en Azure para que, si el usuario se mueve a otro dispositivo, los certificados se creen mediante las mismas claves.

Cifrado de contenido

Cuando un usuario cifra un documento, el cliente del servicio Azure Rights Management realiza las siguientes acciones en un documento sin cifrar:

Lo que sucede en el paso 1: el cliente crea una clave aleatoria (la clave de contenido) y cifra el documento mediante esta clave con el algoritmo de cifrado simétrico AES.

Lo que sucede en el paso 2: el cliente crea un certificado que incluye una directiva para el documento que incluye los derechos de uso para usuarios o grupos, y otras restricciones, como una fecha de expiración. Esta configuración se puede definir con la configuración de cifrado de etiquetas de confidencialidad que un administrador configuró o especificó anteriormente en el momento en que se cifra el contenido (a veces denominados "permisos definidos por el usuario" o una "directiva ad hoc").

El atributo de Microsoft Entra principal que se usa para identificar los usuarios y grupos seleccionados es el atributo ProxyAddresses Microsoft Entra, que almacena todas las direcciones de correo electrónico de un usuario o grupo. Sin embargo, si una cuenta de usuario no tiene ningún valor en el atributo ProxyAddresses de AD, se usa el valor UserPrincipalName del usuario en su lugar.

A continuación, el cliente usa la clave de la organización que se obtuvo cuando se inicializó el entorno de usuario y usa esta clave para cifrar la directiva y la clave de contenido simétrica. El cliente también firma la directiva con el certificado del usuario que se obtuvo cuando se inicializó el entorno de usuario.

Lo que sucede en el paso 3: por último, el cliente inserta la directiva en un archivo con el cuerpo del documento cifrado anteriormente, que juntos componen un documento cifrado.

Este documento se puede almacenar en cualquier lugar o compartirse mediante cualquier método y la directiva siempre permanece con el documento cifrado.

Consumo de contenido

Cuando un usuario quiere consumir un documento cifrado, el cliente comienza solicitando acceso al servicio Azure Rights Management:

Lo que sucede en el paso 1: el usuario autenticado envía la directiva de documento y los certificados del usuario al servicio Azure Rights Management. El servicio descifra y evalúa la directiva y crea una lista de derechos (si los hay) que el usuario tiene para el documento. Para identificar al usuario, se usa el atributo Microsoft Entra ProxyAddresses para la cuenta del usuario y los grupos a los que pertenece el usuario. Por motivos de rendimiento, la pertenencia a grupos se almacena en caché. Si la cuenta de usuario no tiene ningún valor para el atributo Microsoft Entra ProxyAddresses, se usa el valor de Microsoft Entra UserPrincipalName.

Lo que sucede en el paso 2: el servicio extrae la clave de contenido de AES de la directiva descifrada. A continuación, esta clave se cifra con la clave RSA pública del usuario que se obtuvo con la solicitud.

A continuación, la clave de contenido cifrada se inserta en una licencia de uso cifrada con la lista de derechos de usuario, que luego se devuelve al cliente.

Lo que sucede en el paso 3: por último, el cliente toma la licencia de uso cifrada y la descifra con su propia clave privada de usuario. Esto permite al cliente descifrar el cuerpo del documento según sea necesario y representarlo en la pantalla.

El cliente también descifra la lista de derechos y los pasa a la aplicación, que aplica esos derechos en la interfaz de usuario de la aplicación.

Variaciones

En los tutoriales anteriores se tratan los escenarios estándar, pero hay algunas variaciones:

• Email cifrado: cuando se usan Exchange Online y Cifrado de mensajes de Microsoft Purview para cifrar los mensajes de correo electrónico, la autenticación para el consumo también puede usar la federación con un proveedor de identidades sociales o mediante un código de acceso único. A continuación, los flujos de proceso son muy similares, salvo que el consumo de contenido se produce en el lado del servicio en una sesión del explorador web a través de una copia almacenada temporalmente en caché del correo electrónico saliente.

• Dispositivos móviles: cuando los dispositivos móviles cifran o consumen archivos con el servicio Azure Rights Management, los flujos de proceso son más sencillos. Los dispositivos móviles no pasan primero por el proceso de inicialización del usuario porque, en su lugar, cada transacción (para cifrar o consumir contenido) es independiente. Al igual que con los equipos Windows, los dispositivos móviles se conectan al servicio Azure Rights Management y se autentican. Para cifrar el contenido, los dispositivos móviles envían una directiva y el servicio Azure Rights Management les envía una licencia de publicación y una clave simétrica para cifrar el documento. Para consumir contenido cifrado, cuando los dispositivos móviles se conectan al servicio Azure Rights Management y se autentican, envían la directiva de documento al servicio Azure Rights Management y solicitan una licencia de uso para consumir el documento. En respuesta, el servicio Azure Rights Management envía las claves y restricciones necesarias a los dispositivos móviles. Ambos procesos usan TLS para proteger el intercambio de claves y otras comunicaciones.

• Conector de Rights Management: cuando se usa el servicio Azure Rights Management con el conector rights management, los flujos de proceso siguen siendo los mismos. La única diferencia es que el conector actúa como retransmisión entre los servicios locales (como Exchange Server y SharePoint Server) y el servicio Azure Rights Management. El propio conector no realiza ninguna operación, como la inicialización del entorno de usuario o el cifrado o descifrado. Simplemente retransmite la comunicación que normalmente iría a un servidor de AD RMS, controlando la traducción entre los protocolos que se usan en cada lado. Este escenario le permite usar el servicio Azure Rights Management con servicios locales.

• Cifrado genérico (.pfile): cuando el servicio de Azure Rights Management cifra genéricamente un archivo, el flujo es básicamente el mismo para el cifrado de contenido, salvo que el cliente crea una directiva que concede todos los derechos. Cuando se consume el archivo, se descifra antes de pasarlo a la aplicación de destino. Este escenario le permite cifrar todos los archivos, incluso si no admiten de forma nativa el servicio de Azure Rights Management.

• Cuentas de Microsoft: el servicio Azure Rights Management puede autorizar el consumo de direcciones de correo electrónico cuando se autentican con una cuenta de Microsoft. Sin embargo, no todas las aplicaciones pueden abrir contenido cifrado cuando se usa una cuenta Microsoft para la autenticación. Más información.

Pasos siguientes

Para obtener información general menos técnica del servicio de Azure Rights Management, consulte Información sobre el servicio de Azure Rights Management.

Si está listo para los pasos recomendados de implementación que incluyen el cifrado para proteger los datos, consulte Implementación de una solución de protección de la información con Microsoft Purview.