Nota:
El acceso a esta página requiere autorización. Puede intentar iniciar sesión o cambiar directorios.
El acceso a esta página requiere autorización. Puede intentar cambiar los directorios.
Se aplica a: Cifrado de doble clave Microsoft Purview, Microsoft Purview, Microsoft Purview Information Protection
Descripción del servicio para: Microsoft Purview
El cifrado de doble clave (DKE) le permite proteger los datos altamente confidenciales para cumplir requisitos especializados. DKE le permite mantener el control de las claves de cifrado. Usa dos claves para proteger los datos; una clave bajo su control y una segunda clave se almacena de forma segura en Microsoft Azure. Usted mantiene el control de una de sus claves mediante el servicio de cifrado de doble clave. La visualización de datos protegidos con el Cifrado de doble clave requiere acceso a ambas claves.
DKE le ayuda a cumplir los requisitos normativos de varias normativas y estándares, como el Reglamento General de Protección de Datos (RGPD), la Ley de Portabilidad y Responsabilidad de Seguros de Salud (HIPAA), la Ley Gramm-Leach-Bliley (GLBA), la ley de localización de datos de Rusia, la Ley Federal Nº 242-FZ, la Ley Federal de Privacidad de Australia de 1988 y la Ley de Privacidad de Nueva Zelanda de 1993.
Después de configurar el servicio DKE y las claves, aplique protección al contenido altamente confidencial mediante etiquetas de confidencialidad.
Escenarios de implementación admitidos
DKE admite varias configuraciones diferentes, incluidas las implementaciones locales y en la nube. Estas implementaciones ayudan a garantizar que los datos cifrados permanezcan opacos dondequiera que se almacenen.
Puede alojar el servicio de cifrado de doble clave usado para solicitar la clave en una ubicación de su elección (servidor de administración de claves local o en la nube). Usted mantiene el servicio como lo haría con cualquier otra aplicación. El cifrado de doble clave le permite controlar el acceso al servicio de cifrado de doble clave. Puede almacenar los datos altamente confidenciales en las instalaciones o moverlos a la nube. El cifrado de doble clave le da el control para almacenar los datos y la clave en la misma ubicación geográfica.
Para obtener más información sobre las claves raíz de inquilino predeterminadas basadas en la nube, consulte Administración de la clave raíz del servicio Azure Rights Management.
Cuándo su organización debe adoptar DKE
DKE no es para todas las organizaciones ni para todos los datos. Supongamos que un panorama de datos organizacional típico tiene la siguiente estructura:
Datos no confidenciales (alrededor del 80 % de los datos): la mayoría de los datos de una organización pertenecen a esta categoría. No hay problemas ni preocupaciones con el traslado de estos datos a la nube hoy en día. Mover estos datos a la nube puede ser beneficioso y la organización puede usar la seguridad integrada en la nube.
Confidencial (alrededor del 15 % de los datos): los datos confidenciales deben protegerse. La organización espera que el proveedor de servicios en la nube proporcione seguridad al tiempo que mejora la productividad de esta categoría de datos para que puedan cumplir con las regulaciones de cumplimiento. Desea asegurarse de que estos datos se etiquetan correctamente con Microsoft Purview Information Protection y están protegidos con control de acceso y directivas de retención y auditoría.
Altamente confidencial (alrededor del 5 % de los datos): este conjunto es la joya de la corona de la organización y debe protegerse estrictamente. La organización no quiere que nadie tenga acceso a estos datos. Esta categoría de datos también puede tener requisitos normativos para tener las claves en la misma región geográfica que los datos. Es posible que las claves también deban estar bajo la estricta custodia de la organización. Este contenido tiene la clasificación más alta en su organización ("Top Secret") y el acceso está restringido a solo unas pocas personas. Lo que buscan los usuarios malintencionados son datos altamente confidenciales. La pérdida de estos datos puede dañar la reputación de la organización y romper la confianza con sus clientes.
Como se ha mencionado, el cifrado de doble clave está pensado para los datos más confidenciales que están sujetos a los requisitos de protección más estrictos. Debe realizar la debida diligencia para identificar los datos correctos que se deben cubrir con esta solución antes de la implementación. En algunos casos, es posible que tengas que restringir el ámbito y usar otras soluciones. Por ejemplo, para la mayoría de los datos, considere la posibilidad de Microsoft Purview Information Protection con claves administradas por Microsoft o traiga su propia clave (BYOK). Estas soluciones son suficientes para documentos que no están sujetos a protecciones mejoradas ni requisitos normativos. Además, estas soluciones le permiten utilizar los servicios de Microsoft 365 más potentes; servicios que no se pueden usar con contenido cifrado DKE. Por ejemplo:
- Reglas de flujo de correo, como antimalware y correo no deseado, que requieren visibilidad de los datos adjuntos
- Microsoft Delve
- eDiscovery
- Búsqueda e indexación de contenido
- Office Web Apps, incluida la funcionalidad de coautoría
- Copilot
Los datos cifrados DKE no son accesibles en reposo para los servicios de Microsoft 365, incluido Copilot. Mientras usa los datos cifrados por DKE en Office, los datos siguen sin ser accesibles para Copilot y no puede usar Copilot en las aplicaciones mientras usa datos cifrados por DKE.
Las aplicaciones o servicios externos que no están integrados con DKE a través del SDK de Microsoft Information Protection no pueden realizar acciones en los datos cifrados. El SDK de Microsoft Information Protection 1.7+ admite el Cifrado de doble clave. Las aplicaciones que se integran con nuestro SDK pueden razonar sobre estos datos con permisos e integraciones suficientes.
Cuando los datos cifrados de DKE están en uso en una aplicación de Office, es posible que otros servicios de Microsoft 365 puedan acceder a ellos, en función de la versión de Office:
En las últimas versiones de Office, los datos cifrados por DKE en uso tampoco son accesibles para los servicios de Microsoft 365. Dado que este cambio se implementa al mismo tiempo que el control de privacidad independiente para las etiquetas de confidencialidad que impide el envío de contenido etiquetado a experiencias conectadas para su análisis, puede identificar las versiones mínimas de Office mediante la tabla de funcionalidades y la fila Impedir experiencias conectadas que analizan contenido.
En versiones anteriores de Office, los datos cifrados por DKE en uso son accesibles para los servicios de Microsoft 365 a menos que use una configuración de directiva para desactivar las experiencias conectadas que analizan el contenido. Para más información, consulte Usar la configuración de directivas para administrar los controles de privacidad de las Aplicaciones de Microsoft 365 para empresas.
Use las funcionalidades de Microsoft Purview Information Protection (clasificación y etiquetado) para proteger la mayoría de los datos confidenciales y usar DKE solo para los datos críticos. El cifrado de doble clave es relevante para datos confidenciales en sectores altamente regulados, como los servicios financieros y la atención médica.
Características de etiquetas de confidencialidad que no admiten DKE
Dado que DKE no usa una clave basada en la nube administrada por el servicio Azure Rights Management, varias características de etiqueta de confidencialidad no pueden funcionar con contenido cifrado de DKE:
Coautoría y autoguardado
- La coautoría y el autoguardado no se admiten para los documentos de Office cifrados con DKE. Las etiquetas con DKE aún se muestran en las aplicaciones de Office, pero la coautoría y el autoguardado están deshabilitados cuando se aplica la etiqueta. Para obtener más información, consulte la coautoría para archivos cifrados con etiquetas de confidencialidad.
Files en SharePoint y OneDrive
- SharePoint y OneDrive no pueden procesar archivos cifrados por DKE. Estos archivos no se pueden abrir en Office para la Web y las características de colaboración, como la coautoría, eDiscovery, la prevención de pérdida de datos y la búsqueda, no funcionan para los archivos cifrados con DKE en estas ubicaciones. Para obtener más información, vea Habilitar etiquetas de confidencialidad para archivos en SharePoint y OneDrive.
Etiqueta predeterminada para una biblioteca de documentos de SharePoint
- Una etiqueta de confidencialidad que usa DKE no se puede establecer como la etiqueta de confidencialidad predeterminada para una biblioteca de documentos de SharePoint. Para obtener más información, vea Configurar una etiqueta de confidencialidad predeterminada para una biblioteca de documentos de SharePoint.
Componentes y páginas de Loop
- Las etiquetas de confidencialidad configuradas con DKE no se admiten para los componentes y páginas de Loop. Para obtener más información, consulta Etiquetas de confidencialidad para páginas y componentes de Loop.
Reuniones y chat de Teams
- Las etiquetas DKE no se pueden usar para proteger elementos de calendario, reuniones de Teams y chat. Las reuniones y el chat requieren un cifrado que usa el servicio Azure Rights Management. Para obtener más información, consulte Usar etiquetas de confidencialidad para proteger elementos de calendario, reuniones de Teams y chat.
Si sus organizaciones tienen alguno de los siguientes requisitos, puede usar DKE para ayudar a proteger su contenido:
- Tiene requisitos reglamentarios para mantener claves dentro de un límite geográfico.
- Todas las claves que tiene para el cifrado y descifrado de datos se conservan en su centro de datos.
Flujo de trabajo de cifrado DKE
En esta sección, se divide el flujo de trabajo en pasos independientes para ilustrar cómo se usan dos claves para proteger un documento de Office.
Paso 1: Arranque
El cliente de Microsoft Office realiza tareas de configuración de inicio y envía solicitudes e información al servicio de cifrado de Azure Rights Management. Este proceso también se denomina arranque. Entre las tareas se incluyen la autorización del usuario con el Microsoft Entra ID, la descarga de certificados y plantillas, etc. Las tareas de arranque son tareas de conexión por primera vez y de inicio que proporcionan al usuario acceso a las directivas de cifrado de Azure Rights Management.
Paso 2: recopilar y almacenar en caché la clave pública del servicio Azure Rights Management
La aplicación de Office recupera la clave pública del Azure Key Vault en el servicio de cifrado en función del usuario autorizado que usa Microsoft Entra ID. Una vez recopilada, el cliente almacena en caché la clave durante 30 días de manera predeterminada. Una vez almacenado en caché, el cliente no tiene que volver a arrancar en el servicio Azure Rights Management hasta que expire la clave. Como administrador, puede configurar un período de almacenamiento en caché diferente para el servicio de Azure Rights Management. Debe establecer un período de caché para esta clave o aceptar el valor predeterminado de 30 días. Sin un período de caché, la publicación sin conexión no funciona.
Paso 3: Solicitar la clave pública DKE
El cliente de Office solicita la otra clave pública desde el servicio de Cifrado de doble clave según el usuario autorizado con Microsoft Entra ID.
Paso 4: Recopilar y almacenar en caché la clave DKE
El servicio de Cifrado de doble clave envía esta clave pública al cliente de Office. El cliente almacena en caché la clave en el dispositivo durante el tiempo que lo haya configurado. A diferencia de la clave de Azure,
No es necesario configurar un período de caché para la clave hospedada por el servicio de cifrado de doble clave.
Si desea configurar un período de caché, puede configurarlo cuando implemente el servicio de cifrado de doble clave o después de implementarlo.
Paso 5: Proteger el documento con la clave DKE
El cliente de Microsoft Office cifra la parte de los metadatos que controla el acceso al contenido mediante la clave pública que se recuperó del servicio de cifrado de doble clave.
Paso 6: Proteger el documento con la clave de Azure
El cliente de Microsoft Office cifra la parte ya cifrada de los metadatos del documento con la clave pública de Azure.
Los datos ahora están protegidos con ambas claves.
Requisitos del sistema y de licencia para DKE
En esta sección se detallan los requisitos de configuración y del sistema servidor y cliente que deben cumplirse para poder implementar correctamente DKE en su entorno.
requisitos de licencia para DKE
Para conocer las opciones de licencia para el cifrado de doble clave, consulte Cifrado de doble clave de Microsoft Purview Information Protection en la descripción del servicio Microsoft Purview.
El servicio Azure Rights Management es necesario para DKE
DKE funciona con etiquetas de confidencialidad y requiere cifrado con administración de derechos de Microsoft Purview Information Protection.
Requisitos de etiquetado DKE para aplicaciones de Office
Use etiquetas de confidencialidad integradas en las aplicaciones de Office para admitir DKE en Word, Excel, PowerPoint y Outlook. Para ver las versiones compatibles, consulte las tablas de funcionalidades y la fila Cifrado de doble clave (DKE).
DKE en equipos cliente
Los usuarios aplican etiquetas de sensibilidad DKE a través de estas interfaces.
Etiquetado de confidencialidad en aplicaciones de Windows Office
Etiquetador de archivos de Microsoft Purview Information Protection en el Explorador de archivos de Windows
PowerShell de Microsoft Purview Information Protection
Escáner de Microsoft Purview Information Protection
Instale los requisitos previos en cada equipo cliente en el que desee proteger y usar documentos protegidos.
Entornos admitidos para almacenar y ver contenido protegido por DKE
Aplicaciones compatibles. Aplicaciones Microsoft 365 para empresas clientes en Windows, incluidos Word, Excel, PowerPoint y Outlook.
Soporte técnico de contenido en línea. Puede almacenar documentos y archivos protegidos con el cifrado de doble clave en línea tanto en SharePoint como en OneDrive. Debe etiquetar y proteger los documentos y archivos con DKE por parte de las aplicaciones compatibles antes de cargarlos en estas ubicaciones. Puede compartir contenido cifrado por correo electrónico, pero no puede ver documentos y archivos cifrados en línea. En su lugar, debe ver el contenido protegido con las aplicaciones de escritorio y los clientes compatibles en el equipo local.
Etiquetar escenarios fuera de las aplicaciones de Office. Aplicar etiquetas DKE fuera de las aplicaciones de Office con el etiquetador de archivos de Microsoft Purview Information Protection en el Explorador de archivos, las opciones de clic derecho, los cmdlets de etiquetado de PowerShell de Microsoft Purview Information Protection o el escáner de Microsoft Purview Information Protection.
Ver contenido protegido por DKE fuera de las aplicaciones de Office. Puede usar el Visor de Microsoft Purview Information Protection para usar correos electrónicos y documentos protegidos por DKE, como PDF.
Escenarios de solo cifrar y no reenviar. Cifrar solo y No reenviar no son compatibles con DKE en Outlook. Todas las demás aplicaciones de Office admiten etiquetas de permisos definidas por el usuario con DKE.