Compartir vía

Claves administradas por el cliente de Azure Monitor

Azure Monitor cifra los datos mediante claves administradas por Microsoft. Puede usar su propia clave de cifrado para proteger los datos de las áreas de trabajo. Mediante el uso de claves administradas por el cliente en Azure Monitor, se controla el ciclo de vida de la clave de cifrado y el acceso a los registros. Después de configurar las claves administradas por el cliente, los nuevos datos ingeridos en áreas de trabajo vinculadas se cifran mediante la clave de Azure Key Vault o HSM administrado de Azure Key Vault (módulo de seguridad de hardware).

Información general de la clave administrada por el cliente

El cifrado de datos en reposo es un requisito común de privacidad y seguridad en las organizaciones. Puede dejar que Azure administre completamente el cifrado en reposo, o bien puede usar varias opciones para administrar estrechamente el cifrado y 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). El uso del cifrado de Azure Monitor es idéntico a la manera en que funciona el cifrado de Azure Storage.

Para controlar el ciclo de vida de la clave y revocar el acceso a los datos, cifre los datos mediante su propia clave en Azure Key Vault o Azure Key Vault Managed HSM. La funcionalidad claves administradas por el cliente está disponible en clústeres dedicados y proporciona un mayor nivel de protección y control.

Los datos ingeridos en clústeres dedicados se cifran dos veces : en el nivel de servicio mediante claves administradas por Microsoft o claves administradas por el cliente, y en el nivel de infraestructura mediante dos algoritmos de cifrado diferentes y dos claves diferentes. El cifrado doble protege en el hipotético caso de que uno de los algoritmos o claves de cifrado puedan estar en peligro. Los clústeres dedicados también permiten proteger los datos mediante la 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. Azure Monitor cifra los datos SSD mediante claves administradas por Microsoft, independientemente de si configura claves administradas por el cliente, pero el control sobre el acceso SSD se adhiere a la revocación de claves.

Importante

Los clústeres dedicados utilizan un modelo de precios por niveles de compromiso de un mínimo de 100 GB al día.

Cómo funcionan las claves administradas por el cliente en Azure Monitor

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

Los clústeres admiten dos tipos de identidad administrada: asignados por el sistema y asignados por el usuario.

  • La identidad administrada asignada por el sistema es más sencilla y se genera automáticamente junto con el clúster al configurar identitytype a SystemAssigned. Use esta identidad para conceder acceso de almacenamiento de clúster a Key Vault para el cifrado y el descifrado de datos.
  • La identidad administrada asignada por el usuario le permite configurar claves administradas por el cliente al crear el clúster, cuando configura identitytype en UserAssigned y le concede permisos en su Almacén de Claves antes de la creación del clúster.

Configure las claves administradas por el cliente en un nuevo clúster o un clúster dedicado existente con áreas de trabajo vinculadas que ingieren datos. Puede desvincular áreas de trabajo de un clúster en cualquier momento. Los nuevos datos ingeridos en las áreas de trabajo vinculadas se cifran con su clave, mientras que los más antiguos permanecen cifrados con la claves administradas por Microsoft. La configuración no interrumpe la ingesta ni las consultas y estas se realizan tanto en los datos antiguos como en los nuevos sin problemas. Al desvincular áreas de trabajo de un clúster, los nuevos datos ingeridos se cifran con claves administradas por Microsoft.

Importante

La funcionalidad de claves administradas por el cliente es regional. El almacén de claves de Azure, el clúster dedicado y las áreas de trabajo vinculadas deben estar en la misma región, pero pueden estar en distintas suscripciones.

Captura de pantalla de la 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 propaga al almacenamiento de clúster dedicado subyacente.
  3. Clúster dedicado
  4. Áreas de trabajo vinculadas a un clúster dedicado

Tipos de clave de cifrado

El cifrado de datos de almacenamiento usa tres tipos de claves:

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

Se aplican las reglas siguientes:

  • El almacenamiento del clúster tiene una clave de cifrado única para cada cuenta de almacenamiento, que se conoce como AEK.
  • El AEK genera DEKs, que son las claves que cifran cada bloque de datos escritos en el disco.
  • Al configurar la KEK administrada por el cliente en el clúster, el almacenamiento del clúster envía wrap y unwrap solicitudes a tu Key Vault para el cifrado y el descifrado de AEK.
  • La KEK nunca deja Key Vault. Si almacena su clave en un módulo de seguridad de hardware (HSM) administrado por Azure Key Vault, tampoco deja ese dispositivo.
  • Azure Storage usa una identidad administrada asociada al clúster para la autenticación. Accede a Azure Key Vault a través de Microsoft Entra ID.

Permisos necesarios

Para realizar las acciones relacionadas con el clúster necesarias para aprovisionar y administrar claves administradas por el cliente para un clúster dedicado, necesita estos permisos:

Acción Permisos o roles necesarios
Creación de un clúster dedicado permisos Microsoft.Resources/deployments/* y Microsoft.OperationalInsights/clusters/write
Por ejemplo, como se proporcionan con el rol integrado colaborador de Log Analytics
Cambiar las propiedades del clúster Permisos Microsoft.OperationalInsights/clusters/write, como los proporcionados por el rol integrado de colaborador de Log Analytics, por ejemplo.
Vincular áreas de trabajo a un clúster Permisos Microsoft.OperationalInsights/clusters/write, Microsoft.OperationalInsights/workspaces/write y Microsoft.OperationalInsights/workspaces/linkedservices/write, como los proporcionados por el rol integrado de colaborador de Log Analytics, por ejemplo
Comprobación del estado de vinculación del área de trabajo Permisos Microsoft.OperationalInsights/workspaces/read para el área de trabajo de Log Analytics, proporcionados por el rol integrado de lector de Log Analytics, por ejemplo
Obtención de clústeres o comprobación del estado de aprovisionamiento de un clúster Permisos Microsoft.OperationalInsights/clusters/read, como los proporcionados por el rol integrado de lector de Log Analytics, por ejemplo
Actualizar el nivel de compromiso o el tipo de facturación en un clúster Permisos Microsoft.OperationalInsights/clusters/write, como los proporcionados por el rol integrado de colaborador de Log Analytics, por ejemplo.
Conceder los permisos necesarios Rol de propietario o colaborador, que tiene permisos */write, o el rol integrado de colaborador de Log Analytics, que tiene permisos Microsoft.OperationalInsights/*.
Desvinculación de un área de trabajo de un clúster Permisos Microsoft.OperationalInsights/workspaces/linkedServices/delete, como los proporcionados por el rol integrado de colaborador de Log Analytics, por ejemplo.
Eliminación de un clúster dedicado Permisos Microsoft.OperationalInsights/clusters/delete, como los proporcionados por el rol integrado de colaborador de Log Analytics, por ejemplo.

Pasos de aprovisionamiento de claves administradas por el cliente

Siga estos pasos para configurar claves administradas por el cliente en un clúster dedicado:

  1. Crear o asignar la KEK de Azure Key Vault (clave de almacenamiento)
  2. Hacer coincidir los tipos de identidad gestionada del clúster dedicado con el acceso a Key Vault
  3. Concesión de permisos de Key Vault a la identidad administrada
  4. Actualización del clúster dedicado con detalles de identificador de clave
  5. Verificación del aprovisionamiento de clústeres dedicados
  6. Vinculación de áreas de trabajo al clúster dedicado

Crear o asignar el KEK de Azure Key Vault (clave de almacenamiento)

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

Cree o use una instancia de Azure Key Vault existente en la región en la que exista el clúster dedicado o donde planee que resida. Genere o importe una clave en Azure Key Vault para usarla para el cifrado de registros. Debe configurar Azure Key Vault como recuperable para proteger la clave y el acceso a los datos en Azure Monitor. Puede comprobar esta configuración en las propiedades de Key Vault. Habilite la eliminación temporal y la protección de purga.

Importante

Para responder eficazmente a eventos de Azure Key Vault, como una clave próxima a la expiración, configure las notificaciones a través de Azure Event Grid. Cuando la clave expira, la ingesta y las consultas no se ven afectadas, pero no se puede actualizar la clave en el clúster. Para solucionarlo, siga estos pasos:

  1. Identifique la clave usada en la página de información general del clúster en Azure Portal, en Vista JSON.
  2. Amplíe la fecha de expiración de la clave en Azure Key Vault.
  3. Actualice el clúster con la clave activa, preferiblemente con el valor ''de versión , para usar siempre la versión más reciente automáticamente.

Captura de pantalla de configuración de eliminación suave y protección contra purga.

Puede actualizar esta configuración en Key Vault mediante la CLI y PowerShell:

Hacer coincidir los tipos de identidad administrada del clúster dedicado para el acceso a Key Vault

Los clústeres dedicados usan su identidad administrada para acceder a la KEK de Key Vault para cifrar los datos. El tipo de identidad administrada del clúster dedicado debe coincidir con la identidad de asignación de roles de Key Vault para permitir operaciones de cifrado y descifrado de datos.

Establezca la identitytype propiedad en SystemAssigned o UserAssigned al crear el clúster.

Por ejemplo, agregue los siguientes valores en el cuerpo de la solicitud para crear un clúster con una identidad administrada asignada por el sistema:

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

Nota:

Puede cambiar el tipo de identidad después de crear el clúster sin interrumpir la ingesta o las consultas, con las siguientes consideraciones:

  • No se puede actualizar la identidad y la clave simultáneamente para un clúster. Actualícelos en dos operaciones consecutivas.
  • Al actualizar SystemAssigned a UserAssigned, conceda UserAssigned identidad en Key Vault y, a continuación, actualice identity en el clúster dedicado.
  • Al actualizar UserAssigned a SystemAssigned, conceda SystemAssigned identidad en Key Vault y, a continuación, actualice identity en el clúster dedicado.

Para más información sobre cómo crear un clúster dedicado, consulte Creación y administración de un clúster dedicado.

Concesión de permisos de Key Vault a la identidad administrada

Key Vault tiene dos modelos de permisos para conceder acceso al clúster dedicado y al almacenamiento subyacente: control de acceso basado en rol de Azure (recomendado) y directivas de acceso de almacén (heredadas).

  1. Asignar RBAC de Azure (recomendado)

    Para agregar asignaciones de roles, debe tener un rol con permisos de Microsoft.Authorization/roleAssignments/write y Microsoft.Authorization/roleAssignments/delete, como administrador de acceso de usuario o propietario.

    1. Abra tu Bóveda de Claves en el portal de Azure y seleccione Configuración>Configuración de acceso>Control de acceso basado en roles de Azure y Aplicar.
    2. Seleccione Ir al control de acceso (IAM) y agregue la asignación de rol de Usuario de Cifrado del Servicio Criptográfico de Key Vault.
    3. Seleccione Identidad administrada en la pestaña Miembros y seleccione la suscripción para la identidad y la identidad como miembro.

    Captura de pantalla de Concesión de permisos de RBAC de Key Vault.

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

    Abra su Key Vault en el portal de Azure y seleccione Directivas de acceso>Directiva de acceso a bóveda>+ Agregar directiva de acceso para crear una directiva con esta configuración:

    • Permisos de clave: seleccione Obtener>Encapsular clave y Desencapsular Clave.
    • Seleccione un principal según el tipo de identidad usado en el clúster (identidad administrada asignada por el sistema o asignada 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

    Captura de pantalla de Concesión de permisos de directiva de acceso de 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.

Actualizar el clúster dedicado con detalles del identificador de clave

Todas las operaciones del clúster requieren el permiso de acción Microsoft.OperationalInsights/clusters/write. Los roles Propietario o Colaborador, que incluyen la */write acción, pueden conceder este permiso. El rol de Colaborador de análisis de registros, que también concede este permiso, incluye la Microsoft.OperationalInsights/* acción.

En este paso se actualiza el almacenamiento de clúster dedicado con la clave y la versión que se van a usar para AEKwrap y unwrap.

Importante

  • La rotación de claves puede ser automática o por versión de clave explícita. Consulte Rotación de claves para determinar un enfoque adecuado antes de actualizar los detalles del identificador de clave en el clúster dedicado.
  • Las actualizaciones de clúster dedicadas no deben incluir tanto los detalles de identidad como del identificador de clave en la misma operación. Si necesita actualizar ambos, la actualización debe realizarse en dos operaciones consecutivas.

Captura de pantalla de Concesión de permisos de 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

Verificar el aprovisionamiento de clúster dedicado

Compruebe que el estado de aprovisionamiento del clúster es Succeeded antes de vincular áreas de trabajo al clúster. Si vincula áreas de trabajo e ingiere datos antes del aprovisionamiento, el proceso quita los datos ingeridos y no puede recuperarlos.

Compruebe el estado de aprovisionamiento mediante la CLI, PowerShell o la API REST, tal y como se detalla en la sección Actualización del clúster dedicado con detalles del identificador de clave .

Importante

Realice este paso solo después del aprovisionamiento del clúster. Si vincula áreas de trabajo e ingiere datos antes del aprovisionamiento, el proceso quita los datos ingeridos y no puede recuperarlos.

Para vincular un área de trabajo, consulte Creación y administración de un clúster dedicado.

Revocación de claves

Importante

  • Para revocar el acceso a los datos, deshabilite la clave o elimine la directiva de acceso en 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 esta estrategia, ya que no se puede revertir sin contactar con el soporte técnico.

El almacenamiento del clúster siempre respeta los cambios en los permisos de clave y deja de estar disponible en una hora o antes si la clave está deshabilitada o se elimina la directiva de acceso. Los nuevos datos ingeridos en áreas de trabajo vinculadas se eliminan 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 previamente permanecen siempre que el clúster y las áreas de trabajo no se eliminen. La directiva de retención de datos rige los datos inaccesibles y lo purga cuando se alcanza el período de 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 de SSD se eliminan en la operación de revocación de claves y se vuelven inaccesibles. El almacenamiento del clúster intenta llegar a Key Vault para operaciones wrap y unwrap periódicamente. Una vez que la clave está habilitada y unwrap se completa con éxito, los datos SSD se vuelven a cargar desde el almacenamiento del clúster dedicado. La funcionalidad de ingesta y consulta de datos se reanuda en un plazo de 30 minutos.

Rotación de claves

La rotación de clave tiene dos modos:

  • Autorrotación: actualice "keyVaultProperties" en el clúster y omita la propiedad "keyVersion" o 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 las propiedades "keyVaultProperties" y la versión de la clave en la propiedad "keyVersion". La rotación de claves requiere una actualización explícita de la propiedad "keyVersion" en el clúster. Para obtener más información, consulte Actualizar clúster con detalles del identificador de clave. Si genera una nueva versión de clave en Key Vault, pero no actualiza la clave en el clúster, el almacenamiento del clúster sigue usando la clave anterior. Si deshabilita o elimina la clave anterior antes de actualizar una nueva en el clúster, escriba el estado de revocación de claves .

Se podrá acceder a todos los datos tanto durante la operación de rotación de claves como después de ella. El clúster siempre cifra los datos con la Clave de Cifrado de Cuenta (AEK), que se cifra con su nueva versión de 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 usado en Log Analytics es expresivo y puede contener información confidencial en la sintaxis de consulta o los comentarios. Las organizaciones con estrictos requisitos normativos y de cumplimiento deben mantener esta información cifrada mediante una clave administrada por el cliente. Al vincular una cuenta de almacenamiento al área de trabajo, Azure Monitor le permite almacenar las consultas guardadas, las funciones y las alertas de búsqueda de registros cifradas con la clave.

Nota:

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

Al vincular tu cuenta de almacenamiento para gestionar las consultas guardadas, el servicio almacena tanto las consultas guardadas como las consultas de alertas de búsqueda de registros en tu cuenta de almacenamiento. Al tener control sobre la directiva de cifrado en reposo de la cuenta de almacenamiento, puede proteger las consultas guardadas y las alertas de búsqueda de registros mediante una clave administrada por el cliente. Usted es responsable de los costos asociados a esa cuenta de almacenamiento.

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

  • Necesita permisos de escritura en el área de trabajo y la cuenta de almacenamiento.
  • La cuenta de almacenamiento debe ser StorageV2 y en la misma región que el área de trabajo de Log Analytics.
  • Al vincular una cuenta de almacenamiento para consultas guardadas, el servicio quita las consultas y funciones guardadas existentes del área de trabajo para la privacidad. Si necesita estas consultas, copie las consultas y funciones guardadas existentes antes de la configuración. Puede ver las consultas guardadas mediante PowerShell o al exportar una plantilla en Automation en el área de trabajo.
  • Las consultas guardadas en un paquete de consultas no se almacenan en una cuenta de almacenamiento vinculada y no se pueden cifrar mediante una clave administrada por el cliente. Se recomienda guardar como consulta heredada para proteger las consultas mediante una clave administrada por el cliente.
  • Las consultas guardadas y las funciones de la cuenta de almacenamiento vinculada son artefactos de servicio y su formato podría cambiar.
  • La consulta de historial y anclar al panel no se admiten al vincular la cuenta de almacenamiento para las consultas guardadas.
  • Puede vincular una cuenta de almacenamiento única o independiente para consultas guardadas y consultas de alertas de búsqueda de registros.
  • Para mantener las consultas y funciones cifradas con la clave, configure la cuenta de almacenamiento vinculada mediante una clave administrada por el cliente. Realice esta operación al crear la cuenta de almacenamiento o posterior.

Configuración de la cuenta de almacenamiento vinculada para consultas guardadas

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

Nota:

La operación traslada las consultas guardadas y las funciones desde tu área de trabajo a una tabla en tu cuenta de almacenamiento. Puede desvincular la Cuenta de Almacenamiento para que las consultas y funciones guardadas se trasladen de nuevo a su área de trabajo. Actualice el explorador si las consultas guardadas o las funciones no aparecen en Azure Portal después de la operación.

N/D

Clave administrada por el cliente para Libros

Azure Monitor también te permite almacenar consultas de cuaderno cifradas con tu clave en tu propia cuenta de almacenamiento. Tenga en cuenta la misma consideración que se describe en Clave administrada por el cliente para consultas guardadas y alertas de búsqueda de registros.

Seleccione Guardar contenido en una cuenta de Azure Storage en la operación Guardar del libro.

Captura de pantalla de Guardar libro.

Consideraciones antes de establecer la clave administrada por el cliente para las consultas de alertas de registro guardadas

  • El clúster guarda consultas de alerta como blobs en la cuenta de almacenamiento.
  • Las alertas de búsqueda de registros desencadenadas no contienen resultados de búsqueda ni la consulta de alerta. Use dimensiones de alerta para obtener el contexto de las alertas desencadenadas.
  • Para mantener las consultas y funciones cifradas mediante la clave, configure la cuenta de almacenamiento vinculada con una clave administrada por el cliente. Realice esta operación al crear la cuenta de almacenamiento o posterior.

Configurar la cuenta de almacenamiento vinculada para consultas de alerta 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

Caja de seguridad del cliente

Con Lockbox, puede aprobar o rechazar solicitudes de los ingenieros de Microsoft para acceder a sus datos durante las interacciones de soporte técnico con el cliente.

Los clústeres dedicados de Log Analytics admiten Lockbox, que concede permiso para acceder a los datos a nivel de suscripción.

Para más información, consulte Lockbox del cliente para Microsoft Azure.

Consideraciones y límites

  • Puede crear hasta cinco clústeres activos en cada región y suscripción.

  • Puede tener hasta siete clústeres reservados (activos o eliminados recientemente) en cada región y suscripción.

  • Puede vincular hasta 1000 áreas de trabajo de Log Analytics a un clúster.

  • Puede realizar hasta 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.

  • Las actualizaciones del clúster no deben incluir tanto detalles de identidad como de identificador de clave en la misma operación. Para actualizar ambos, use dos operaciones consecutivas.

  • Lockbox no está disponible actualmente en China.

  • Lockbox no se aplica a las tablas con el plan de tabla auxiliar.

  • 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 enviando una GET solicitud en el clúster y observando que el isDoubleEncryptionEnabled valor es true para clústeres con cifrado doble habilitado.

  • Si crea un clúster y recibe el error "region-name no admite el cifrado doble para clústeres", puede crear el clúster sin cifrado doble agregando "properties": {"isDoubleEncryptionEnabled": false} en el cuerpo de la solicitud REST.

  • No se puede cambiar la configuración de cifrado doble después de crear el clúster.

  • La operación de recuperación se permite para un área de trabajo eliminada que todavía estaba vinculada al clúster. Solo es posible durante el período de eliminación temporal . La recuperación devuelve el área de trabajo a su estado anterior y permanece vinculada 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 que la configuración permanezcan cifrados con claves de Microsoft. Puede consultar los datos ingeridos antes y después de la configuración de la clave administrada por el cliente sin problemas.

  • Debe configurar Azure Key Vault como recuperable. Estas propiedades no están habilitadas de forma predeterminada y debe configurarlas mediante la CLI o PowerShell:

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

  • 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, pero pueden estar en suscripciones diferentes.

  • 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 puede usar una clave administrada por el cliente con la identidad administrada asignada por el usuario si Key Vault está en una instancia de Private-Link (red virtual). Use una identidad administrada asignada por el sistema en este escenario.

Solución de problemas

  • Comportamiento por disponibilidad de Key Vault:

    • Durante la operación de ingesta normal, el almacenamiento en clúster dedicado almacena en caché AEK durante breves períodos de tiempo y accede a Key Vault periódicamente para unwrap.

    • Durante los errores de conexión de Key Vault, el almacenamiento del clúster dedicado gestiona los errores transitorios (tiempos de espera, fallos de conexión, fallos de DNS) manteniendo las claves en la memoria caché durante la incidencia para superar las interrupciones temporales y la disponibilidad intermitente. Las funciones de consulta e ingesta continúan sin interrupción.

  • Frecuencia de acceso de Key Vault: la frecuencia con la que el almacenamiento del clúster accede a Key Vault para operaciones de wrap y unwrap está entre 6 y 60 segundos.

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

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

  • Se produce un error al vincular un área de trabajo a un clúster si el área de trabajo está vinculada a otro clúster.

  • Si crea un clúster y se especifica KeyVaultProperties inmediatamente, es posible que se produzca un error en la operación hasta que se asigne una identidad al clúster y se conceda permiso a Key Vault.

  • Si actualiza un clúster existente con KeyVaultProperties y Get y falta la directiva de acceso de claves en Key Vault, la operación fallará.

  • Si no logra implementar su clúster, compruebe que su Azure Key Vault, clúster y las áreas de trabajo vinculadas estén en la misma región. Pueden estar en suscripciones distintas.

  • Si gira la clave en Key Vault y no actualiza los nuevos detalles del identificador de clave en el clúster, el clúster sigue usando la clave anterior y los datos se vuelven inaccesibles. Actualice los detalles del nuevo identificador de clave en el clúster para reanudar la funcionalidad de ingesta y consulta de datos. Actualice la versión de la clave utilizando la notación '' para asegurarse de que el almacenamiento dedicado del clúster siempre utilice automáticamente la versión más reciente de la clave.

  • Algunas operaciones son de larga duración y pueden tardar un tiempo en completarse, incluida la creación del clúster, la actualización de clave de clúster y la eliminación del clúster. Para comprobar el estado de la operación, envíe una GET solicitud al clúster o al área de trabajo y observe la respuesta. Por ejemplo, un área de trabajo desvinculada no tiene clusterResourceId en 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: la clave no se puede recuperar. Key Vault debe configurarse con eliminación temporal y protección contra purgas. Consulte la documentación de Key Vault.
    • 400: la operación no se puede ejecutar 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 el clúster. Si intenta crear un clúster con ese nombre y encuentra un conflicto, el clúster está en proceso de eliminación.

Contenido relacionado

  • Last updated on