Compartir a través de

Rotar o alternar una Clave de cliente o una clave de disponibilidad

  • Artículo

Precaución

Implemente solo una clave de cifrado que use con clave de cliente cuando los requisitos de seguridad o cumplimiento determinen que debe revertir la clave. No elimine ni deshabilite las claves que estén o estén asociadas a directivas, incluidas las versiones anteriores de las claves que usó. Al deshacer las claves, hay contenido cifrado con las claves anteriores. Por ejemplo, mientras que los buzones activos se vuelven a cifrar con frecuencia, los buzones inactivos, desconectados y deshabilitados todavía se pueden cifrar con las claves anteriores. Microsoft SharePoint realiza una copia de seguridad del contenido con fines de restauración y recuperación, por lo que es posible que todavía haya contenido archivado mediante claves anteriores.

Sugerencia

Si no es cliente de E5, use la prueba de 90 días de soluciones de Microsoft Purview para explorar cómo las funcionalidades adicionales de Purview pueden ayudar a su organización a administrar las necesidades de cumplimiento y seguridad de los datos. Comience ahora en el centro de pruebas del portal de cumplimiento de Microsoft Purview. Obtenga más información sobre términos de suscripción y prueba.

Windows 365 soporte técnico para la clave de cliente de Microsoft Purview está en versión preliminar pública y está sujeto a cambios.

Acerca de cómo revertir la clave de disponibilidad

Microsoft no expone el control directo de la clave de disponibilidad a los clientes. Por ejemplo, solo puede revertir (girar) las claves que posee en Azure Key Vault. Microsoft 365 implementa las claves de disponibilidad en una programación definida internamente. No hay ningún acuerdo de nivel de servicio (SLA) orientado al cliente para estos lanzamientos de claves. Microsoft 365 gira la clave de disponibilidad mediante el código de servicio de Microsoft 365 en un proceso automatizado. Los administradores de Microsoft pueden iniciar el proceso de lanzamiento. La clave se enrolla mediante mecanismos automatizados sin acceso directo al almacén de claves. El acceso al almacén de secretos de clave de disponibilidad no se aprovisiona para los administradores de Microsoft. La rotación de clave de disponibilidad aplica el mismo mecanismo usado para generar inicialmente la clave. Para obtener más información sobre la clave de disponibilidad, consulte Descripción de la clave de disponibilidad.

Importante

Los clientes pueden inscribir de forma eficaz las claves de disponibilidad de Exchange al crear un nuevo DEP, ya que se genera una clave de disponibilidad única para cada DEP que cree. Las claves de disponibilidad de clave de cliente para SharePoint y OneDrive existen en el nivel de bosque y se comparten entre dep y clientes, lo que significa que la reversión solo se produce en una programación definida internamente por Microsoft. Para mitigar el riesgo de no revertir la clave de disponibilidad cada vez que se crea un nuevo DEP, SharePoint, OneDrive y Teams implementan la clave intermedia del inquilino (TIK), la clave encapsulada por las claves raíz del cliente y la clave de disponibilidad, cada vez que se crea un nuevo DEP.

Acerca de cómo revertir las claves raíz administradas por el cliente

Hay dos maneras de revertir las claves raíz administradas por el cliente: actualizar las claves existentes solicitando una nueva versión de la clave y actualizando el DEP, o creando y usando una clave recién generada y DEP. Las instrucciones para cada método de rolling your keys se encuentran en la sección siguiente.

Solicitar una nueva versión de cada clave raíz existente que quiera revertir

Para solicitar una nueva versión de una clave existente, use el mismo cmdlet, Add-AzKeyVaultKey, con la misma sintaxis y el mismo nombre de clave que usó originalmente para crear la clave. Una vez que haya terminado de revertir cualquier clave asociada a una directiva de cifrado de datos (DEP), ejecute otro cmdlet para actualizar el DEP existente para asegurarse de que clave de cliente usa la nueva clave. Realice este paso en cada Key Vault de Azure (AKV).

Por ejemplo:

  1. Inicie sesión en su suscripción de Azure con Azure PowerShell. Para obtener instrucciones, consulte Inicio de sesión con Azure PowerShell.

  2. Ejecute el cmdlet Add-AzKeyVaultKey como se muestra en el ejemplo siguiente:

    Add-AzKeyVaultKey -VaultName Contoso-CK-EX-NA-VaultA1 -Name Contoso-CK-EX-NA-VaultA1-Key001 -Destination HSM -KeyOps @('wrapKey','unwrapKey') -NotBefore (Get-Date -Date "12/27/2016 12:01 AM")

    En este ejemplo, dado que existe una clave denominada Contoso-CK-EX-NA-VaultA1-Key001 en el almacén Contoso-CK-EX-NA-VaultA1 , el cmdlet crea una nueva versión de la clave. Esta operación conserva las versiones de clave anteriores en el historial de versiones de la clave. Necesita la versión de clave anterior para descifrar los datos que sigue cifrando. Una vez completada la puesta en marcha de cualquier clave asociada a un DEP, ejecute un cmdlet adicional para asegurarse de que clave de cliente comienza a usar la nueva clave. En las secciones siguientes se describen los cmdlets con más detalle.

    Actualización de las claves para los DEP de varias cargas de trabajo

    Al implementar cualquiera de las claves de Azure Key Vault asociadas a un DEP usado con varias cargas de trabajo, debe actualizar el DEP para que apunte a la nueva clave. Este proceso no gira la clave de disponibilidad. La propiedad DataEncryptionPolicyID no cambia al actualizarla con una nueva versión de la misma clave.

    Para indicar a Customer Key que use la nueva clave para cifrar varias cargas de trabajo, complete estos pasos:

    1. En el equipo local, con una cuenta profesional o educativa que tenga permisos de administrador global o administrador de cumplimiento en su organización, conéctese a Exchange PowerShell.

    2. Ejecute el cmdlet Set-M365DataAtRestEncryptionPolicy:

      Set-M365DataAtRestEncryptionPolicy -Identity <Policy>  -Refresh

      Donde Policy es el nombre o identificador único de la directiva.

    Actualización de las claves para los DEP de Exchange

    Al deshacer cualquiera de las claves de Azure Key Vault asociadas a un DEP usado con Exchange, debe actualizar el DEP para que apunte a la nueva clave. Esta acción no gira la clave de disponibilidad. La propiedad DataEncryptionPolicyID del buzón no cambia al actualizarla con una nueva versión de la misma clave.

    Para indicar a la clave de cliente que use la nueva clave para cifrar los buzones de correo, complete estos pasos:

    1. En el equipo local, con una cuenta profesional o educativa que tenga permisos de administrador global o administrador de cumplimiento en su organización, conéctese a Exchange PowerShell.

    2. Ejecute el cmdlet Set-DataEncryptionPolicy:

        Set-DataEncryptionPolicy -Identity <Policy> -Refresh

      Donde Policy es el nombre o identificador único de la directiva.

Uso de una clave recién generada para el DEP

Al optar por usar claves recién generadas en lugar de actualizar las existentes, el proceso para actualizar las directivas de cifrado de datos difiere. En lugar de actualizar una directiva existente, debe crear y asignar una nueva directiva de cifrado de datos adaptada a la nueva clave.

  1. Para crear una nueva clave y agregarla al almacén de claves, siga las instrucciones que se encuentran en Adición de una clave a cada almacén de claves mediante la creación o importación de una clave.

  2. Una vez agregado al almacén de claves, debe crear una nueva directiva de cifrado de datos con el URI de clave de la clave recién creada. Puede encontrar instrucciones sobre cómo crear y asignar directivas de cifrado de datos en Administrar clave de cliente para Microsoft 365.

Actualización de las claves para SharePoint y OneDrive

SharePoint solo le permite lanzar una clave a la vez. Si desea revertir ambas claves en un almacén de claves, espere a que se complete la primera operación. Microsoft recomienda escalonar las operaciones para evitar este problema. Al implementar cualquiera de las claves de Azure Key Vault asociadas a un DEP usado con SharePoint y OneDrive, debe actualizar el DEP para que apunte a la nueva clave. Esta acción no gira la clave de disponibilidad.

  1. Ejecute el cmdlet Update-SPODataEncryptionPolicy de la siguiente manera:

    Update-SPODataEncryptionPolicy  <SPOAdminSiteUrl> -KeyVaultName <ReplacementKeyVaultName> -KeyName <ReplacementKeyName> -KeyVersion <ReplacementKeyVersion> -KeyType <Primary | Secondary>

    Aunque este cmdlet inicia la operación de sustitución de claves para SharePoint y OneDrive, la acción no se completa inmediatamente.

  2. Para ver el progreso de la operación de sustitución de claves, ejecute el cmdlet Get-SPODataEncryptionPolicy de la siguiente manera:

    Get-SPODataEncryptionPolicy <SPOAdminSiteUrl>