¿Cómo funciona Azure RMS? En segundo plano

Una cuestión importante que hay que comprender acerca del funcionamiento de Azure RMS es que el servicio de protección de datos de Azure Information Protection no ve ni almacena sus datos como parte del proceso de protección. La información que protege nunca se envía o se almacena en Azure, a menos que la almacene de manera explícita en Azure o use otro servicio en la nube que lo haga. Azure RMS simplemente hace que los datos de un documento sean ilegibles para cualquiera que no sea un usuario y servicio autorizado:

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

• Cuando un usuario legítimo usa un documento protegido o un servicio autorizado procesa este documento, se descifran los datos en el documento y se aplican los derechos que se definen en la directiva.

En un nivel alto, puede ver cómo funciona este proceso en la siguiente imagen. Se protege un documento que contiene la fórmula secreta y luego lo abre correctamente un usuario o servicio autorizado. El documento se protege con una clave de contenido (la clave verde de esta imagen). Es única para cada documento y se coloca en el encabezado de archivo donde se protege mediante la clave raíz de inquilino de Azure Information Protection (la clave roja de esta imagen). Microsoft puede generar y administrar la clave de inquilino o puede generarla y administrarla usted mismo.

A lo largo del proceso de protección en el que Azure RMS cifra y descifra, autoriza y aplica restricciones, la fórmula secreta nunca se envía a Azure.

Para una descripción detallada de lo que está sucediendo, consulte la sección Tutorial de cómo funciona Azure RMS: Primer uso, protección de contenido, consumo de contenido de este artículo.

Para información técnica acerca de los algoritmos y longitudes de clave que usa Azure RMS, consulte la siguiente sección.

Controles criptográficos que utiliza Azure RMS: Algoritmos y longitudes de clave

Aunque no es necesario conocer en detalle cómo funciona esta tecnología, es posible que se le pregunte acerca de los controles criptográficos que usa. Por ejemplo, para confirmar que la protección de seguridad es un estándar del sector.

Controles criptográficos	Uso en Azure RMS
Algoritmo: AES Longitud de la clave: 128 bits y 256 bits [1]	Protección de contenido
Algoritmo: RSA Longitud de la clave: 2048 bits [2]	Protección de claves
SHA-256	Firma de certificados

Nota al pie 1

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

• Protección genérica (.pfile).

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

• Protección nativa para archivos de texto o imagen (como .ptxt o .pjpg).

Nota al pie 2

La longitud de la clave cuando el servicio Azure Rights Management está activado es de 2048 bits. La longitud de clave de 1024 bits es compatible para los siguientes escenarios opcionales:

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

• Para las claves archivadas que se crearon en el entorno local antes de la migración, para que el servicio Azure Rights Management después de la migración pueda seguir abriendo el contenido que anteriormente estuvo protegido por AD RMS.

Almacenamiento y protección de las claves criptográficas de Azure RMS

Para cada documento o correo electrónico que protege, Azure RMS crea una sola clave AES ("clave de contenido") y esa clave se inserta en el documento y se mantiene aunque se edite el documento.

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

Esta clave de inquilino está protegida en los servicios en línea de Microsoft, en un entorno muy controlado y bajo una estrecha supervisión. Cuando se usa una clave de inquilino administrada por el cliente (BYOK), esta seguridad mejora gracias al uso de una matriz de módulos de alto nivel de seguridad de hardware (HSM) en cada región de Azure, sin la posibilidad de que se extraigan, exporten o compartan las claves bajo ninguna circunstancia. Para más información acerca de la clave de inquilino y BYOK, consulte Planeamiento e implementación de su clave de inquilino de Azure Information Protection.

Las licencias y los certificados que se envían a un dispositivo Windows están protegidos con la clave privada de dispositivo del cliente, que se crea la primera vez que un usuario del dispositivo usa Azure RMS. Esta clave privada, a su vez, está protegida con DPAPI en el cliente, que protege estos secretos con una clave derivada de la contraseña del usuario. En los dispositivos móviles, las claves se usan solo una vez, de modo que, como no se almacenan en los clientes, no es necesario proteger estas claves en el dispositivo.

Tutorial de cómo funciona Azure RMS: Primer uso, protección de contenido, consumo de contenido

Para comprender con más detalle el funcionamiento de Azure RMS, examinemos un flujo típico que se produce tras la activación del servicio Azure Rights Management y cuando un usuario usa por primera vez el servicio Rights Management en su equipo Windows (un proceso que a veces se conoce como inicialización del entorno del usuario o arranque), protege contenido (un documento o correo electrónico) y, a continuación, consume (abre y usa) el contenido que ha protegido otra persona.

Una vez se inicia el entorno del usuario, ese usuario puede proteger los documentos o consumir documentos protegidos en ese equipo.

Nota:

Si este usuario se mueve a otro equipo Windows, u otro usuario utiliza este mismo equipo Windows, se repite el proceso de inicialización.

Inicialización del entorno de usuario

Antes de que un usuario pueda proteger el contenido o consumir contenido protegido en un equipo Windows, se debe preparar el entorno del usuario en el dispositivo. Este es un proceso único y ocurre de manera automática sin intervención del usuario cuando un usuario intenta proteger o consumir contenido protegido:

¿Qué ocurre en el paso 1?: En el equipo, el cliente de RMS se conecta primero al servicio Azure Rights Management y autentica al usuario mediante su cuenta de Microsoft Entra.

Cuando la cuenta de usuario está federada con Microsoft Entra ID, esta autenticación es automática y al usuario no se le solicitan las credenciales.

¿Qué ocurre en el paso 2?: Cuando se autentica el usuario, la conexión se redirige automáticamente al inquilino de Azure Information Protection de la organización, que emite certificados que permiten al usuario autenticarse en el servicio Azure Rights Management para consumir contenido protegido y para proteger contenido sin conexión.

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

Se almacena una copia de este certificado en Azure, por lo que si el usuario se mueve a otro dispositivo, se crean los certificados mediante las mismas claves.

Protección de contenido

Cuando un usuario protege un documento, el cliente de RMS realiza las siguientes acciones en un documento desprotegido:

¿Qué ocurre en el paso 1?: El cliente de RMS crea una clave aleatoria (la clave de contenido) y descifra el documento usando esta clave con el algoritmo de cifrado simétrico de AES.

¿Qué ocurre en el paso 2?: El cliente de RMS crea a continuación un certificado que incluye una directiva para el documento que contiene a su vez los derechos de utilización para usuarios o grupos y otras restricciones, como una fecha de expiración. Estas opciones se pueden definir en una plantilla que un administrador haya configurado anteriormente, o bien especificarse al proteger el contenido (a veces se denomina "directiva ad-hoc").

El atributo de Microsoft Entra principal que se usa para identificar los usuarios y grupos seleccionados es el atributo ProxyAddresses de Microsoft Entra ID, 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 utiliza en su lugar el valor de UserPrincipalName del usuario.

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

¿Qué ocurre en el paso 3?: Por último, el cliente de RMS inserta la directiva en un archivo con el cuerpo del documento cifrado anteriormente y, en conjunto, constituyen un documento protegido.

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

Consumo de contenido

Cuando un usuario quiere consumir un documento protegido, el cliente de RMS se inicia solicitando acceso al servicio Azure Rights Management:

¿Qué ocurre en el paso 1: El usuario autenticado envía la directiva del 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 (en caso de haberlos) que el usuario tiene para el documento. Para identificar al usuario, se usa el atributo ProxyAddresses de Microsoft Entra correspondiente a la cuenta del usuario y a los grupos de los que el usuario es miembro. Por motivos de rendimiento, la pertenencia a grupos se almacena en caché. Si la cuenta de usuario no tiene valores para el atributo ProxyAddresses de Microsoft Entra, alternativamente se usa el valor de UserPrincipalName de Microsoft Entra.

¿Qué ocurre en el paso 2: El servicio extrae después la clave de contenido de AES desde la directiva descifrada. Esta clave se cifra a continuación con la clave de RSA pública del usuario que se obtuvo con la solicitud.

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

¿Qué ocurre en el paso 3?: Por último, el cliente de RMS toma la licencia de uso cifrada y la descifra con su propia clave privada de usuario. Esto permite al cliente de RMS descifrar el cuerpo del documento cuando se necesita y representarlo en la pantalla.

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

Nota:

Cuando los usuarios externos a su organización consumen contenido que ha protegido, el flujo de consumo es el mismo. Lo que cambia en este escenario es cómo se autentica el usuario. Para más información, consulte Cuando comparto un documento protegido con una persona ajena a mi organización, ¿cómo se autentica ese usuario?

Variaciones

Los tutoriales anteriores cubren los escenarios estándar pero hay algunas variaciones:

• Protección de correo electrónico: Cuando Exchange Online y el cifrado de mensajes de Office 365 con nuevas funcionalidades se usan para proteger 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 de un solo uso. Posteriormente, los flujos de proceso son muy similares, salvo que el consumo de contenido se produce en el 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 protegen o consumen archivos con el servicio Azure Rights Management, los flujos del proceso son mucho más sencillos. Los dispositivos móviles no recorren primero el proceso de inicialización de usuario porque, en su lugar, cada transacción (para proteger o consumir contenido) es independiente. Como con equipos de Windows, los dispositivos móviles se conectan al servicio Azure Rights Management y se autentican. Para proteger 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 proteger el documento. Para consumir contenido, cuando los dispositivos móviles se conectan al servicio Azure Rights Management y se autentican, envían la directiva del documento al servicio Azure Rights Management y solicitan una licencia de usuario para consumir el documento. En respuesta, el servicio Azure Rights Management envía las restricciones y las claves necesarias a los dispositivos móviles. Ambos procesos usan TLS para proteger el intercambio de claves y otras comunicaciones.

• Conector RMS: Cuando se usa el servicio Azure Rights Management con el conector RMS, los flujos del proceso no cambian. La única diferencia es que el conector actúa como una retransmisión entre los servicios locales (como Exchange Server y SharePoint Server) y el servicio Azure Rights Management. El propio conector no lleva a cabo ninguna operación, como la inicialización del entorno del usuario, o cifrado o descifrado. Retransmite simplemente la comunicación que iría normalmente a un servidor AD RMS, controlando la traducción entre los protocolos que se usan en cada lado. Este escenario permite usar el servicio Azure Rights Management con servicios locales.

• Protección genérica (.pfile): Cuando el servicio Azure Rights Management protege un archivo genéricamente, el flujo es básicamente el mismo para la protección de contenido, con la excepción de que el cliente de RMS crea una directiva que concede todos los derechos. Cuando se consume el archivo, se descifra antes de pasarse a la aplicación de destino. Este escenario le permite proteger todos los archivos, aunque no admitan RMS de manera nativa.

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

Pasos siguientes

Para más información acerca del servicio Azure Rights Management, lea el resto de artículos de la sección Conceptos básicos y exploración, como Compatibilidad de aplicaciones con el servicio Azure Rights Management, para aprender de qué manera las aplicaciones existentes se pueden integrar con Azure Rights Management para proporcionar una solución de protección de la información.

Revise Terminología de Azure Information Protection para familiarizarse con los términos que se puede encontrar a medida que configure y use el servicio Azure Rights Management, y asegúrese de leer también Requisitos de Azure Information Protection antes de empezar su implementación. Si quiere algo más rápido y para poder probarlo personalmente, use las guías de inicio rápido y los tutoriales.

• Inicio rápido: Implementación del cliente de etiquetado unificado
• Tutorial: Instalación del examinador de etiquetado unificado de Azure Information Protection (AIP)
• Tutorial: Búsqueda del contenido confidencial con el examinador de Azure Information Protection (AIP)
• Tutorial: Evitar el uso compartido excesivo en Outlook con Azure Information Protection (AIP)

Si está listo para comenzar a implementar la protección de datos para su organización, utilice la Hoja de ruta de implementación de AIP para la clasificación, el etiquetado y la protección para ver los pasos de implementación y los vínculos a instrucciones de procedimientos.