Clave administrada por el cliente de Azure Monitor

  • Artículo

Los datos de Azure Monitor se cifran con claves administradas por Microsoft. Puede usar su propia clave de cifrado para proteger los datos y las consultas guardadas en las áreas de trabajo. Las claves administradas por el cliente de Azure Monitor proporcionan mayor flexibilidad para administrar los controles de acceso a los registros. Una vez configurados, los nuevos datos ingeridos en áreas de trabajo vinculadas se cifran con la clave almacenada en Azure Key Vaulto Azure Key Vault administrado "HSM".

Revise las limitaciones y restricciones antes de la configuración.

Información general de la clave administrada por el cliente

El cifrado en reposo es un requisito común de privacidad y seguridad en las organizaciones. Puede dejar que Azure administre por completo el cifrado en reposo, mientras dispone de varias opciones para administrar minuciosamente el cifrado o las claves de cifrado.

Azure Monitor garantiza que todos los datos y las consultas guardadas se cifren en reposo mediante claves administradas por Microsoft (MMK). Puede cifrar los datos con su propia clave en Azure Key Vault para controlar el ciclo de vida de la clave y la capacidad de revocar el acceso a los datos. El uso del cifrado de Azure Monitor es idéntico a la forma en que funciona el cifrado de Azure Storage.

La clave administrada por el cliente se entrega en clústeres dedicados que proporcionan un mayor nivel de protección y control. Los datos se cifran en el almacenamiento dos veces, una vez en el nivel de servicio mediante claves administradas por Microsoft o claves administradas por el cliente, y otra vez en el nivel de infraestructura mediante dos algoritmos de cifrado diferentes y dos claves diferentes. El cifrado doble protege en caso de que uno de los algoritmos o claves de cifrado puedan estar en peligro. El clúster dedicado también permite proteger los datos con Caja de seguridad.

Los datos ingeridos en los últimos 14 días o usados recientemente en las consultas se mantienen en la caché activa (respaldada por SSD) para la eficacia de las consultas. Los datos del SSD se cifran con las claves de Microsoft, con independencia de la configuración de la clave administrada por el cliente, pero el control sobre el acceso al SSD se ciñe a la revocación de claves

El modelo de precios de clústeres dedicados de Log Analytics requiere un nivel de compromiso a partir de 100 GB por día.

Funcionamiento de las claves administradas por el cliente en Azure Monitor

Azure Monitor usa la identidad administrada para conceder acceso a su instancia de Azure Key Vault. La identidad del clúster de Log Analytics se admite en el nivel de clúster. Para permitir una clave administrada por el cliente en varias áreas de trabajo, un recurso de clúster de Log Analytics funciona como una conexión de identidad intermedia entre la instancia de Key Vault y las áreas de trabajo de Log Analytics. El almacenamiento del clúster usa la identidad administrada que está asociada al clúster para la autenticación en Azure Key Vault a través de Microsoft Entra ID.

Los clústeres admiten dos tipos de identidad administrada: Asignado por el sistema y asignado por el usuario, mientras que una sola identidad se puede definir en un clúster en función del escenario.

  • La identidad administrada asignada por el sistema es más sencilla y se genera automáticamente con la creación del clúster cuando la identidad type se establece en "SystemAssigned". Esta identidad se puede usar más adelante para conceder acceso de almacenamiento a su instancia de Key Vault para las operaciones de encapsulado y desencapsulado.
  • La identidad administrada asignada por el usuario permite configurar la clave administrada por el cliente durante la creación del clúster, al concederle permisos en Key Vault antes de crearlo.

Puede aplicar la configuración de clave administrada por el cliente a un nuevo clúster o a un clúster existente vinculado a áreas de trabajo e ingesta de datos. Los nuevos datos ingeridos en las áreas de trabajo vinculadas se cifran con su clave, mientras que los datos más antiguos ingeridos antes de la configuración permanecen cifrados con la clave de Microsoft. Las consultas no se ven afectadas por la configuración de claves administradas por el cliente y se realizan en datos antiguos y nuevos sin problemas. Puede desvincular las áreas de trabajo del clúster en cualquier momento. Los nuevos datos ingeridos tras la desvinculación se cifran con la clave de Microsoft, y las consultas se realizan en datos antiguos y nuevos sin problemas.

Importante

La funcionalidad de la clave administrada por el cliente es regional. La instancia de Azure Key Vault, el clúster y las áreas de trabajo vinculadas deben estar en la misma región, pero pueden estar en distintas suscripciones.

Screenshot of customer-managed key overview.

  1. Key Vault
  2. Recurso de clúster de Log Analytics que tiene una identidad administrada con permisos para Key Vault: la identidad se admite en el nivel del almacenamiento de clúster dedicado
  3. Clúster dedicado
  4. Áreas de trabajo vinculadas a un clúster dedicado

Operación de claves de cifrado

Hay tres tipos de claves que se usan en el cifrado de datos de Storage:

  • "KEK": clave de cifrado de claves (su clave administrada por el cliente)
  • "AEK": clave de cifrado de la cuenta
  • "DEK": clave de cifrado de datos

Se aplican las reglas siguientes:

  • El almacenamiento de clúster tiene una clave de cifrado única para cada cuenta de almacenamiento, lo que se conoce como "AEK".
  • La "AEK" se usa para derivar "DEK", que son las claves que se usan para cifrar cada bloque de datos escritos en el disco.
  • Al configurar una clave en Key Vault y actualizar los detalles de la clave en el clúster, el almacenamiento del clúster realiza solicitudes para "encapsular" y "desencapsular" "AEK" para el cifrado y descifrado.
  • Esta "KEK" nunca abandona su instancia de Key Vault y, en el caso de una clave de "HSM" administrada, nunca abandona el hardware.
  • Azure Storage usa una identidad administrada asociada al recurso de Clúster para la autenticación. Accede a Azure Key Vault a través de Microsoft Entra ID.

Pasos de aprovisionamiento de la clave administrada por el cliente

  1. Creación de una instancia de Azure Key Vault y almacenamiento de la clave
  2. Creación de un clúster
  3. Concesión de permisos a la instancia de Key Vault
  4. Actualización del clúster con detalles del identificador de clave
  5. Vinculación de áreas de trabajo

La configuración de claves administradas por el cliente no se admite en Azure Portal actualmente, y el aprovisionamiento se puede realizar mediante PowerShell, la CLI o solicitudes REST.

Almacenamiento de la clave de cifrado de claves ("KEK")

Una cartera de productos de Azure Key Management enumera los almacenes y los HSM administrados que se pueden usar.

Cree o use una instancia de Azure Key Vault existente en la región planificada para el clúster. En el almacén de claves, genere o importe una clave que se usará para el cifrado de registros. Azure Key Vault se debe configurar como recuperable para proteger su clave y el acceso a los datos en Azure Monitor. Puede comprobar esta configuración en las propiedades de Key Vault: tanto la Eliminación temporal como la Protección de purga deben estar habilitadas.

Screenshot of soft delete and purge protection settings.

Esta configuración puede actualizarse en Key Vault a través de la CLI y PowerShell:

Crear clúster

Los clústeres usan la identidad administrada para el cifrado de datos con Key Vault. Configure la propiedad type de identidad en SystemAssigned al crear el clúster para permitir el acceso a la instancia de Key Vault para operaciones de "encapsulado" y "desencapsulado".

Configuración de identidad en el clúster para la identidad administrada asignada por el sistema

{
  "identity": {
    "type": "SystemAssigned"
    }
}

Siga el procedimiento que se muestra en el artículo Clústeres dedicados.

Concesión de permisos a Key Vault

Hay dos modelos de permisos en Key Vault para conceder permisos al clúster y al almacenamiento subyacente: Control de acceso basado en roles de Azure (RBAC de Azure) y directivas de acceso de Key Vault (heredadas).

  1. Asignación de RBAC de Azure que controla (recomendado)

    Para agregar asignaciones de roles, debe tener los permisos Microsoft.Authorization/roleAssignments/write y Microsoft.Authorization/roleAssignments/delete, como Administrador de acceso de usuario o Propietario.

    Abra Key Vault in Azure Portal, haga clic en Configuración de acceso en Configuración y, a continuación, seleccione la opción Control de acceso basado en roles de Azure. A continuación, escriba Control de acceso (IAM) y agregue la asignación de roles de Usuario de cifrado del servicio criptográfico de Key Vault.

    Screenshot of Grant Key Vault RBAC permissions.

  2. Asignación de una directiva de acceso de Key Vault (heredada)

    Abra su instancia de Key Vault en Azure Portal y haga clic en Directivas de acceso, seleccione Política de acceso a Vault y luego haga clic en + Agregar directiva de acceso para crear una directiva con esta configuración:

    • Permisos de clave: seleccione Obtener, Encapsular clave y Desencapsular clave.
    • Seleccione la entidad de seguridad: en función del tipo de identidad usado en el clúster (identidad administrada asignada por el sistema o por el usuario)
      • Identidad administrada asignada por el sistema: escriba el nombre del clúster o el identificador de la entidad de seguridad del clúster
      • Identidad administrada asignada por el usuario: escriba el nombre de identidad

    Screenshot of Grant Key Vault access policy permissions.

    El permiso Obtener es necesario para comprobar que su instancia de Azure Key Vault está configurada como recuperable con el fin de proteger su clave y el acceso a sus datos de Azure Monitor.

Actualización del clúster con detalles del identificador de clave

Todas las operaciones del clúster requieren el permiso de acción Microsoft.OperationalInsights/clusters/write. Este permiso se puede conceder a través del rol Propietario o Colaborador que contiene la acción */write o a través del rol Colaborador de Log Analytics que contiene la acción Microsoft.OperationalInsights/*.

En este paso se actualiza el almacenamiento de clúster dedicado con la clave y la versión que se usarán para encapsular y desencapsular "AEK".

Importante

  • La rotación de claves puede ser automática o requerir una actualización de clave explícita. Consulte Rotación de claves para determinar la estrategia adecuada antes de actualizar los detalles del identificador de clave del clúster.
  • La actualización del clúster no debe incluir los detalles de identidad y de identificador de clave en la misma operación. Si necesita actualizar ambos valores, la actualización debe realizarse en dos operaciones consecutivas.

Screenshot of Grant Key Vault permissions.

Actualice KeyVaultProperties en el clúster con los detalles del identificador de clave.

Esta operación es asincrónica y puede tardar un tiempo en completarse.

N/D

Importante

Este paso solo debe realizarse después del aprovisionamiento de clústeres. Si vincula áreas de trabajo e ingiere datos antes del aprovisionamiento, los datos ingeridos se quitarán y no se podrán recuperar.

Necesita permisos de "escritura" en el área de trabajo y en el clúster para realizar esta operación. Incluye Microsoft.OperationalInsights/workspaces/write y Microsoft.OperationalInsights/clusters/write.

Siga el procedimiento que se muestra en el artículo Clústeres dedicados.

Revocación de claves

Importante

  • La manera recomendada para revocar el acceso a los datos es deshabilitar la clave o eliminar la directiva de acceso de su instancia de Key Vault.
  • Al establecer la opción identitytype del clúster en None, también se revoca el acceso a los datos, pero no se recomienda este enfoque, ya que no se puede revertir sin contactar con el soporte técnico.

El almacenamiento de clúster siempre respetará los cambios en los permisos de las claves en el plazo de una hora (normalmente antes), y el almacenamiento dejará de estar disponible. Los nuevos datos ingeridos en áreas de trabajo vinculadas se descartan y no se pueden recuperar. No se puede acceder a los datos en estas áreas de trabajo y se producirá un error en las consultas. Los datos ingeridos anteriormente permanecerán en el almacenamiento siempre que se no se eliminen el clúster ni las áreas de trabajo. Los datos inaccesibles se rigen por la directiva de retención de datos y se purgan cuando se alcance la retención. Los datos ingeridos en los últimos 14 días y los datos usados recientemente en las consultas también se mantienen en la caché activa (respaldada por SSD) para la eficacia de las consultas. Los datos en SSD se eliminan con la operación de revocación de claves y se convierten en inaccesibles. El almacenamiento del clúster intenta llegar a Key Vault para encapsular y desencapsular periódicamente, y una vez habilitada la clave, se hace la desencapsulación correctamente, los datos SSD se vuelven a cargar desde el almacenamiento y la ingesta de datos y la consulta se reanudan en un plazo de 30 minutos.

Rotación de claves

La rotación de clave tiene dos modos:

  • Autorotation: actualice el clúster con "keyVaultProperties", pero omita la propiedad "keyVersion" o esta establézcala en "". Storage usa automáticamente la versión de clave más reciente.
  • Actualización de la versión de clave explícita: actualice el clúster con la versión de la clave en la propiedad "keyVersion". La rotación de claves requiere una actualización de "keyVaultProperties" explícita en el clúster; consulte Actualización del clúster con detalles del identificador de clave. Si genera la nueva versión de la clave en la instancia de Key Vault, pero no la actualiza en el clúster, el almacenamiento de clúster sigue usando la clave anterior. Si deshabilita o elimina la clave anterior antes de actualizar con una nueva en el clúster, obtiene el estado de revocación de clave.

Todos los datos permanecen accesibles después de la operación de rotación de claves. Los datos siempre se cifran con la clave de cifrado de cuenta ("AEK"), que se cifra con la nueva versión de la clave de cifrado de claves ("KEK") en Key Vault.

Clave administrada por el cliente para consultas guardadas y alertas de búsqueda de registros

El lenguaje de consulta utilizado en Log Analytics es expresivo y puede contener información confidencial en los comentarios o en la sintaxis de la consulta. Algunas organizaciones requieren que dicha información se mantenga protegida en el marco de la directiva de la clave administrada por el cliente y debe guardar las consultas cifradas con su clave. Azure Monitor permite almacenar las consultas guardadas y las alertas de búsqueda de registros cifradas con la clave en su propia cuenta de almacenamiento cuando esté vinculada al área de trabajo.

Clave administrada por el cliente para Libros

Con las consideraciones mencionadas para clave administrada por el cliente para las consultas guardadas y las alertas de búsqueda de registros, Azure Monitor le permite almacenar consultas de libro cifradas con la clave en su propia cuenta de almacenamiento, al seleccionar Guardar contenido en una cuenta de Azure Storage en la operación "Guardar" del libro.

Screenshot of Workbook save.

Nota:

Las consultas permanecen cifradas con la clave de Microsoft ("MMK") en los siguientes escenarios, independientemente de la configuración de la clave administrada por el cliente: paneles de Azure, aplicación lógica de Azure, Azure Notebooks y Runbooks de automatización.

Al vincular la cuenta de almacenamiento para las consultas guardadas, el servicio almacena las consultas guardadas y las consultas de alertas de búsqueda de registros en la cuenta de almacenamiento. Tener control en la cuenta de almacenamiento directiva de cifrado en reposo, puede proteger las consultas guardadas y las alertas de búsqueda de registros con la clave administrada por el cliente. Sin embargo, será responsable de los costos asociados a esa cuenta de almacenamiento.

Consideraciones antes de establecer la clave administrada por el cliente en las consultas

  • Debe tener permisos de "escritura" en el área de trabajo y la cuenta de almacenamiento.
  • Asegúrese de crear la cuenta de almacenamiento en la misma región que el área de trabajo de Log Analytics, con cifrado de clave administrada por el cliente. Esto es importante, ya que las consultas guardadas se almacenan en una tabla de almacenamiento y solo se pueden cifrar al crear la cuenta de Storage.
  • Las consultas guardadas en el paquete de consultas no se cifran con la clave administrada por el cliente. Seleccione Guardar como consulta heredada al guardar consultas en su lugar, para protegerlas con clave administrada por el cliente.
  • Las búsquedas guardadas en el almacenamiento se consideran artefactos de servicio y su formato puede cambiar.
  • Al vincular una cuenta de almacenamiento para consultas, se eliminarán las consultas guardadas existentes del área de trabajo. Copie las búsquedas guardadas que necesite antes de esta configuración. Puede ver las búsquedas guardadas mediante PowerShell.
  • No se admiten las consultas "historial" y "anclar al panel" al vincular la cuenta de Storage para las consultas.
  • Puede vincular una única cuenta de almacenamiento a un área de trabajo para las consultas guardadas y las consultas de alertas de búsqueda de registros.
  • Las alertas de búsqueda de registros se guardan en Blob Storage y el cifrado de claves administradas por el cliente se pueden configurar en la creación de la cuenta de almacenamiento o posterior.
  • Las alertas de búsqueda de registros desencadenadas no contendrán resultados de búsqueda ni consulta de alertas. Puede usar dimensiones de alerta para obtener contexto en las alertas desencadenadas.

Configurar BYOS para consultas guardadas

Vincule una cuenta de almacenamiento para consultas para mantener las consultas guardadas en la cuenta de almacenamiento.

N/D

Después de la configuración, se guardará en el almacenamiento cualquier nueva consulta de búsqueda guardada.

Configurar BYOS para consultas de alertas de búsqueda de registros

Vincule una cuenta de almacenamiento para Alertas para mantener alerta de búsqueda de registros consultas en la cuenta de almacenamiento.

N/D

Después de la configuración, se guardará en el almacenamiento cualquier nueva consulta de alertas.

Caja de seguridad del cliente

Caja de seguridad le proporciona el control para aprobar o rechazar la solicitud de ingeniero de Microsoft para acceder a los datos durante una solicitud de soporte técnico.

La caja de seguridad se proporciona en un clúster dedicado en Azure Monitor, donde se concede permiso para acceder a los datos en el nivel de suscripción.

Más información sobre Caja de seguridad del cliente de Microsoft Azure

Operaciones de la clave administrada por el cliente

La clave administrada por el cliente se proporciona en un clúster dedicado, y se hace referencia a estas operaciones en el artículo sobre el clúster dedicado.

  • Obtención de todos los clústeres de un grupo de recursos
  • Obtención de todos los clústeres de una suscripción
  • Actualización de la reserva de capacidad en el clúster
  • Actualización de billingType en el clúster
  • Desvinculación de un área de trabajo de un clúster
  • Eliminación de clúster

Limitaciones y restricciones

  • Se puede crear un máximo de cinco clústeres activos en cada región y suscripción.

  • Pueden existir un número máximo de siete clústeres reservados (activos o eliminados recientemente) en cada región y suscripción.

  • Se pueden vincular un máximo de 1000 áreas de trabajo de Log Analytics a un clúster.

  • Se permite un máximo de dos operaciones de vinculación de áreas de trabajo en un área de trabajo determinada en un período de 30 días.

  • Actualmente no se admite el traslado de un clúster a otro grupo de recursos o a otra suscripción.

  • La actualización del clúster no debe incluir los detalles de identidad y de identificador de clave en la misma operación. En caso de que deba actualizar ambos valores, la actualización debe realizarse en dos operaciones consecutivas.

  • La caja de seguridad no está disponible actualmente en China.

  • El cifrado doble se configura automáticamente para los clústeres creados a partir de octubre de 2020 en las regiones compatibles. Puede comprobar si el clúster está configurado para el cifrado doble mediante el envío de una solicitud GET en el clúster y observando que el valor isDoubleEncryptionEnabled sea true para los clústeres con el cifrado doble habilitado.

    • Si crea un clúster y recibe un error que indica que la región no admite el cifrado doble para clústeres, puede crear el clúster sin cifrado doble si agrega "properties": {"isDoubleEncryptionEnabled": false} en el cuerpo de la solicitud REST.
    • La configuración de cifrado doble no se puede cambiar después de crear el clúster.

La eliminación de un área de trabajo vinculada se permite mientras se vincula al clúster. Si decide recuperar el área de trabajo durante el período de eliminación temporal, vuelve al estado anterior y permanece vinculado al clúster.

  • El cifrado de la clave administrada por el cliente se aplica a los datos recién ingeridos después del tiempo de configuración. Los datos que se ingieren antes de la configuración, permanecen cifrados con la clave de Microsoft. Puede consultar fácilmente los datos ingeridos antes y después de la configuración de la clave administrada por el cliente.

  • La instancia de Azure Key Vault debe configurarse como recuperable. Las siguientes propiedades no están habilitadas de forma predeterminada y deben configurarse mediante la CLI o PowerShell:

    • Eliminación temporal.
    • La protección de purgas debe estar activada si quiere tener protección frente a posibles eliminaciones forzadas de secretos o del almacén, incluso después de su eliminación temporal.

  • Su instancia de Azure Key Vault, el clúster y las áreas de trabajo deben estar en la misma región y en el mismo inquilino de Microsoft Entra ID, pero pueden estar en distintas suscripciones.

  • Al establecer la opción identitytype del clúster en None, también se revoca el acceso a los datos, pero no se recomienda este enfoque, ya que no se puede revertir sin contactar con el soporte técnico. La forma recomendada de revocar el acceso a sus datos es la revocación de la clave.

  • No se puede usar una clave administrada por el cliente con una identidad administrada asignada por el usuario si su instancia de Key Vault está en un vínculo privado (vNet). En este escenario puede usar la identidad administrada asignada por el sistema.

  • Actualmente, las consultas asincrónicas de trabajos de búsqueda no se admiten en el escenario de clave administrada por el cliente.

Solución de problemas

  • Comportamiento por disponibilidad de Key Vault:

    • En el funcionamiento normal, el almacenamiento almacena en caché la "AEK" durante breves períodos de tiempo y vuelve regularmente a Key Vault para desajustarla.

    • Errores de conexión de Key Vault: el almacenamiento controla los errores transitorios (tiempos de espera, errores de conexión y problemas de "DNS"). Para ello, permite que las claves permanezcan en caché mientras dure el problema de disponibilidad, lo que salva las interrupciones momentáneas y los problemas de disponibilidad. Las funciones de consulta e ingesta continúan sin interrupción.

  • Frecuencia de acceso a Key Vault: la frecuencia con la que el almacenamiento en clúster de Azure accede a Key Vault para las operaciones de encapsulado y desencapsulado es de entre 6 y 60 segundos.

  • Si actualiza el clúster mientras está en el estado de aprovisionamiento o actualización, se produce un error en la actualización.

  • Si recibe un error de conflicto al crear un clúster, es posible que se haya eliminado un clúster con el mismo nombre en los últimos 14 días y se mantenga reservado. El nombre del clúster eliminado estará disponible 14 días después de la eliminación.

  • La vinculación del área de trabajo al clúster producirá un error si esta está vinculada a otro clúster.

  • Si crea un clúster y especifica KeyVaultProperties inmediatamente, la operación puede producir un error hasta que se asigne la identidad en el clúster y se conceda en Key Vault.

  • Si actualiza un clúster existente con KeyVaultProperties y la directiva de acceso de clave "Get" no se encuentra en Key Vault, se produce un error en la operación.

  • Si no puede implementar el clúster, compruebe que la instancia de Azure Key Vault, el clúster y las áreas de trabajo vinculadas se encuentran en la misma región. Puede estar en distintas suscripciones.

  • Si rota la clave en Key Vault y no actualiza los nuevos detalles del identificador de clave en el clúster, el clúster seguirá usando la clave anterior y los datos serán inaccesibles. Actualice los nuevos detalles del identificador de clave en el clúster para reanudar la ingesta y consulta de datos. Puede actualizar la versión de la clave con "''" para que el almacenamiento siempre use automáticamente la última versión de clave.

  • Algunas operaciones son de larga duración y pueden tardar un tiempo en completarse, como la creación del clúster, la actualización de claves de clúster y la eliminación del clúster. Para comprobar el estado de funcionamiento, envíe una solicitud GET al clúster o al área de trabajo y observe la respuesta. Por ejemplo, un área de trabajo desvinculada no tendrá el elemento clusterResourceId en la sección features.

  • Mensajes de error

    Actualización del clúster:

    • 400: El clúster está en estado de eliminación. La operación asincrónica está en curso. El clúster debe completar su operación antes de realizar cualquier operación de actualización.
    • 400: KeyVaultProperties no está vacío, pero tiene un formato incorrecto. Consulte actualización de identificador de clave.
    • 400: No se pudo validar la clave en Key Vault. Podría deberse a la falta de permisos o a que la clave no existe. Verifique que estableció la clave y la directiva de acceso en Key Vault.
    • 400: No se puede recuperar la clave. Key Vault debe establecerse para la eliminación temporal y protección de purga. Consulte la documentación de Key Vault.
    • 400: No se puede ejecutar la operación ahora. Espere a que se complete la operación asincrónica e inténtelo de nuevo.
    • 400: El clúster está en estado de eliminación. Espere a que se complete la operación asincrónica e inténtelo de nuevo.

    Obtención del clúster

    • 404: No se encontró el clúster; es posible que se haya eliminado. Si intentase crear un clúster con ese nombre y obtuviera un conflicto, el clúster se encontrará en proceso de eliminación.

Pasos siguientes