Planeamiento e implementación de su clave de inquilino de Azure Information Protection

Se aplica a: Azure Information Protection

Pertinente para: cliente de etiquetado unificado de AIP y cliente clásico de AIP

Nota

Para proporcionar una experiencia de cliente unificada y simplificada, el cliente clásico de Azure Information Protection y la administración de etiquetas en Azure Portal están en desuso desde el 31 de marzo de 2021. Aunque el cliente clásico sigue funcionando como está configurado, no se proporcionará ningún soporte adicional, y las versiones de mantenimiento ya no se publicarán para el cliente clásico.

Se recomienda migrar al etiquetado unificado y actualizar al cliente de etiquetado unificado. Obtenga más información en nuestro último blog sobre desuso.

La clave de inquilino de Azure Information Protection es una clave raíz para la organización. Otras claves se pueden derivar de esta clave raíz, incluidas las claves de usuario, las claves de equipo o las claves de cifrado de documentos. Cada vez que Azure Information Protection usa estas claves para su organización, se encadena criptográficamente a su clave de inquilino de Azure Information Protection raíz.

Además de la clave raíz de inquilino, su organización puede requerir la seguridad local para documentos específicos. La protección de claves local normalmente solo es necesaria para una pequeña cantidad de contenido y, por lo tanto, se configura junto con una clave raíz de inquilino.

Tipos de clave Azure Information Protection

La clave raíz de inquilino puede ser:

Si tiene contenido altamente confidencial que requiere protección local adicional, se recomienda usar el cifrado de clave doble (DKE).

Sugerencia

Si usa el cliente clásico y necesita protección local adicional, use la propiedad Hold Your Own Key (HYOK) en su lugar.

Claves raíz de inquilinos generadas por Microsoft

La clave predeterminada, generada automáticamente por Microsoft, es la clave predeterminada que se usa exclusivamente para Azure Information Protection para administrar la mayoría de los aspectos del ciclo de vida de la clave de inquilino.

Siga usando la clave predeterminada de Microsoft cuando desee implementar Azure Information Protection rápidamente y sin hardware especial, software o una suscripción de Azure. Entre los ejemplos se incluyen entornos de prueba u organizaciones sin requisitos normativos para la administración de claves.

Para la clave predeterminada, no se requieren pasos adicionales y puede ir directamente a introducción a la clave raíz del inquilino.

Nota

La clave predeterminada generada por Microsoft es la opción más simple con las mínimas sobrecargas administrativas.

En la mayoría de los casos, es posible que ni siquiera sepa que tiene una clave de inquilino, ya que puede suscribirse a Azure Information Protection y Microsoft controla el resto del proceso de administración de claves.

Protección de Bring Your Own Key (BYOK)

BYOK: la protección utiliza claves creadas por los clientes, ya sea en el Azure Key Vault o en el entorno local de la organización del cliente. A continuación, estas claves se transfieren a Azure Key Vault para una administración adicional.

Use BYOK cuando su organización tenga normas de cumplimiento para la generación de claves, incluido el control de todas las operaciones de ciclo de vida. Por ejemplo, cuando la clave debe estar protegida por un módulo de seguridad de hardware.

Para obtener más información, consulte Configuración de la protección de BYOK.

Una vez configurada, continúe con la introducción a la clave raíz de inquilino para obtener más información sobre el uso y la administración de la clave.

Cifrado de doble clave (DKE)

Pertinente para: solo cliente de etiquetado Unificado de AIP

La protección de DKE proporciona seguridad adicional para el contenido mediante dos claves: una creada y retenida por Microsoft en Azure y otra creada y mantenida en el entorno local por parte del cliente.

DKE requiere ambas claves para tener acceso al contenido protegido, asegurándose de que Microsoft y otros terceros nunca tengan acceso a los datos protegidos por su cuenta.

DKE se puede implementar en la nube o de forma local, lo que proporciona una flexibilidad total para las ubicaciones de almacenamiento.

Use DKE cuando su organización:

  • Desea asegurarse de que solo puedan descifrar el contenido protegido en todas las circunstancias.
  • No quiere que Microsoft tenga acceso a los datos protegidos por su cuenta.
  • Tiene requisitos normativos para contener claves dentro de un límite geográfico. Con DKE, las claves retenidas por el cliente se mantienen dentro del centro de datos del cliente.

Nota

DKE es similar a un cuadro de depósito de seguridad que requiere una clave de banco y una clave de cliente para obtener acceso. DKE: la protección requiere la clave de Microsoft y la clave conservada por el cliente para descifrar el contenido protegido.

Para obtener más información, vea cifrado de clave doble en la documentación de Microsoft 365.

Mantenga su propia clave (HYOK)

Pertinente para: solo cliente clásico de AIP

HYOK: la protección utiliza una clave creada y retenida por los clientes, en una ubicación aislada de la nube. Dado que HYOK-Protection solo permite el acceso a los datos de aplicaciones y servicios locales, los clientes que usan HYOK también tienen una clave basada en la nube para los documentos en la nube.

Use HYOK para los documentos que son:

  • Restringido a solo unas pocas personas
  • No se comparte fuera de la organización
  • Solo se consumen en la red interna.

Normalmente, estos documentos tienen la clasificación más alta de la organización, como "el secreto superior".

El contenido se puede cifrar mediante la protección de HYOK solo si tiene el cliente clásico. Sin embargo, si tiene contenido protegido por HYOK, se puede ver en el cliente de etiquetado clásico y unificado.

Para obtener más información, consulte los detalles de Hold Your Own Key (HYOK).

Pasos siguientes

Consulte cualquiera de los siguientes artículos para obtener más detalles sobre tipos específicos de claves:

Si va a migrar entre inquilinos, por ejemplo, después de una fusión de la empresa, le recomendamos que lea nuestra entrada de blog sobre fusiones y spinoffs para obtener más información.