Clave administrada por el cliente de Azure Monitor

  • Artículo
  • Tiempo de lectura: 23 minutos

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 configurada, los nuevos datos de las áreas de trabajo vinculadas se cifran con la clave almacenada en Azure Key Vault o Azure Key Vault Managed "HSM".

Se recomienda revisar la sección Limitaciones y restricciones que aparece más abajo antes de proceder con 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). También tiene la opción de cifrar los datos con su propia clave en Azure Key Vault, con control sobre el ciclo de vida de las claves y la capacidad de revocar el acceso a los datos en cualquier momento. 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 en clústeres dedicados se cifran dos veces, una vez en el nivel de servicio mediante claves administradas por Microsoft o claves administradas por el cliente, y una 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. En este caso, la capa adicional de cifrado también protege los datos. El clúster dedicado también le permite proteger los datos con un control de 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 500 GB por día y puede tener valores de 500, 1000, 2000 o 5000 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 la clave administrada por el cliente en varias áreas de trabajo, un nuevo 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 de clúster usa la identidad administrada que está asociada al recurso de clúster para autenticar el acceso y acceder a Azure Key Vault mediante Azure Active Directory.

Después de la configuración de la clave administrada por el cliente, los nuevos datos ingeridos en las áreas de trabajo vinculadas asociadas a su clúster dedicado se cifran con la clave. Puede desvincular las áreas de trabajo del clúster en cualquier momento. Después, los nuevos datos se introducen en el almacenamiento de clúster y se cifran con la clave de Microsoft, mientras que puede consultar los datos nuevos y antiguos 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.

Información general de la clave administrada por el cliente

  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 Azure Active Directory.

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")

Cree o use una instancia de Azure Key Vault existente en la región en la que se planea el clúster y 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.

Configuración de la eliminación temporal y la protección de purga

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

Cree una directiva de acceso en Key Vault para conceder permisos al clúster. Estos permisos los utiliza el almacenamiento de clúster subyacente. Abra su instancia de Key Vault en Azure Portal y haga clic en Directivas de acceso y luego 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

Concesión de permisos a Key Vault

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.

Concesión de permisos a Key Vault

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 Storage 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 purgarán 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 desencapsular el cifrado periódicamente y, una vez habilitada la clave, el desencapsulado se realiza correctamente, los datos SSD se vuelven a cargar desde el almacenamiento y la ingesta de datos y la consulta se reanudan en 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 "". El almacenamiento usará automáticamente las versiones más recientes.
  • 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 seguirá usando la clave anterior. Si deshabilita o elimina la clave anterior antes de actualizar con una nueva en el clúster, obtendrá 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 registro

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 le permite almacenar consultas de búsquedas guardadas y de alertas del registro cifradas con su clave en su propia cuenta de almacenamiento cuando se conecta al área de trabajo.

Nota

Las consultas de Log Analytics se pueden guardar en varios almacenes según el escenario usado. Las consultas permanecen cifradas con la clave de Microsoft ("MMK") en los escenarios siguientes, con independencia de la configuración de la clave administrada por el cliente: Libros en Azure Monitor, paneles de Azure, Azure Logic Apps, Azure Notebooks y runbooks de automatización.

Al vincular su propio almacenamiento (BYOS) al área de trabajo, el servicio almacena las búsquedas guardadas y las consultas de alertas de registro en la cuenta de almacenamiento. Con el control sobre la cuenta de almacenamiento y la directiva encryption-at-rest, puede proteger las búsquedas guardadas y las alertas de registro 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 en la que se encuentra el área de trabajo de Log Analytics.
  • Las búsquedas guardadas en el almacenamiento se consideran artefactos de servicio y su formato puede cambiar.
  • Las búsquedas guardadas existentes se eliminan 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, que se puede usar tanto para las búsquedas guardadas como para las consultas de alertas de registro.
  • Las alertas del registro desencadenadas no contendrán resultados de búsqueda ni consultas de alertas. Puede usar dimensiones de alerta para obtener contexto en las alertas desencadenadas.

Configuración de BYOS para las consultas de búsquedas guardadas

Vincule una cuenta de almacenamiento de Consulta para mantener las consultas de búsquedas 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.

Configuración de BYOS para las consultas de alertas del registro

Vincule una cuenta de almacenamiento de Alertas para mantener las consultas de alertas de registro 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 (versión preliminar)

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.

En Azure Monitor, tiene este control sobre los datos en las áreas de trabajo vinculadas al clúster dedicado. El control Caja de seguridad se aplica a los datos almacenados en un clúster dedicado en el que se mantiene aislado en el almacenamiento del clúster en su suscripción protegida de la Caja de seguridad.

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 Azure Active Directory (Azure AD), 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é durante la vigencia del problema de disponibilidad, lo que supera 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 producirá un error en la actualización.

  • Si se produce un error de conflicto al crear un clúster, es posible que haya eliminado el clúster en los últimos 14 días y que esté en un estado de eliminación temporal. El nombre del clúster permanece reservado durante el período de eliminación temporal y no se puede crear un nuevo clúster con ese nombre. El nombre se libera después del período de eliminación temporal cuando el clúster se elimina de forma permanente.

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

  • Si crea un clúster y especifica el valor de KeyVaultProperties inmediatamente, puede producirse un error en la operación, ya que la directiva de acceso no se puede definir hasta que se asigne la identidad del sistema al clúster.

  • Si actualiza un clúster existente con KeyVaultProperties y la directiva de acceso de clave "Get" no se encuentra en Key Vault, se producirá 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 actualiza la versión de 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 de identificador de clave del clúster para reanudar la ingesta de datos y la capacidad de consultar los datos.

  • Algunas operaciones son largas y pueden tardar un tiempo en completarse. Estas operaciones son las de creación de clúster, actualización de la clave de clúster y eliminación de 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

    Creación de un clúster

    • 400: El nombre del clúster no es válido. El nombre del clúster puede contener los caracteres a-z, A-Z, 0-9 y una longitud de 3 a 63.
    • 400: El cuerpo de la solicitud es NULL o tiene un formato incorrecto.
    • 400: El nombre de "SKU" no es válido. Establezca el nombre de la "SKU" en capacityReservation.
    • 400: Se proporcionó Capacity, pero la "SKU" no es capacityReservation. Establezca el nombre de la "SKU" en capacityReservation.
    • 400: Falta Capacity en la "SKU". Establezca el valor de Capacity en 500, 1000, 2000 o 5000 GB/día.
    • 400: Capacity está bloqueado durante 30 días. Se permite la reducción de la capacidad 30 días después de la actualización.
    • 400: No se estableció ninguna "SKU". Establezca el nombre de la "SKU" en capacityReservation y el valor de Capacity en 500, 1000, 2000 o 5000 GB/día.
    • 400: Identity es NULL o está vacío. Establezca Identity en el tipo systemAssigned.
    • 400: KeyVaultProperties se estableció en la creación. Actualice KeyVaultProperties después de la creación del clúster.
    • 400: No se puede ejecutar la operación ahora. La operación asincrónica está en un estado distinto del correcto. El clúster debe completar su operación antes de realizar cualquier operación de actualización.

    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 intenta crear un clúster con ese nombre y obtiene un conflicto, el clúster se encuentra en eliminación temporal durante 14 días. Puede ponerse en contacto con soporte técnico para recuperarlo o usar otro nombre para crear un nuevo clúster.

    Eliminación del clúster:

    • 409: No se puede eliminar un clúster mientras está en estado de aprovisionamiento. Espere a que se complete la operación asincrónica e inténtelo de nuevo.

    Vinculación del área de trabajo

    • 404: No se encuentra el área de trabajo. El área de trabajo que especificó no existe o se eliminó.
    • 409: Operación en curso de vinculación o desvinculación del área de trabajo.
    • 400: No se encontró el clúster, el clúster que especificó no existe o se eliminó. Si intenta crear un clúster con ese nombre y obtiene un conflicto, el clúster se encuentra en eliminación temporal durante 14 días. Puede ponerse en contacto con el soporte técnico para recuperarlo.

    Desvinculación del área de trabajo

    • 404: No se encuentra el área de trabajo. El área de trabajo que especificó no existe o se eliminó.
    • 409: Operación en curso de vinculación o desvinculación del área de trabajo.

Pasos siguientes