Compartir a través de

Claves administradas 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 de las áreas de trabajo. Las claves administradas por el cliente en Azure Monitor le proporcionan control sobre el ciclo de vida de la clave de cifrado y el acceso a los registros. Una vez configurado, los nuevos datos ingeridos en áreas de trabajo vinculadas se cifran con la clave en 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 con la capacidad de revocar los datos de acceso, cifre los datos con su propia clave en Azure Key Vault o HSM administrado de Azure Key Vault. La funcionalidad de 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 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 de SSD se cifran con claves administradas por Microsoft, independientemente de si configura claves administradas por el cliente, pero el control sobre el acceso SSD se adhiere a larevocació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 de Log Analytics actúa como 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: 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 el clúster cuando identitytype se establece en SystemAssigned. Esta identidad se usa más adelante para concederle acceso de almacenamiento a su almacén de claves para el cifrado y descifrado de datos.
  • La identidad administrada asignada por el usuario le permite configurar claves administradas por el cliente al crear un clúster, siempre que identitytype esté establecido en UserAssigned y se le concedan permisos en el 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. La desvinculación de áreas de trabajo de un clúster se puede realizar 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. Azure Key Vault, 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. Bóveda de claves
  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 claves de cifrado

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

  • 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 se usa para derivar DEKs, que son las claves que se usan para cifrar cada bloque de datos escritos en el disco.
  • Al configurar el KEK administrado por el cliente en el clúster, el almacenamiento del clúster realiza solicitudes wrap y unwrap a Key Vault para el cifrado y 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.

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 dedicado
  3. Concesión de permisos a tu Key Vault
  4. Actualización de un clúster dedicado con detalles del identificador de clave
  5. Vinculación de áreas de trabajo

Una configuración de clave administrada por el cliente no admite la configuración de detalles de identidad e identificador de clave. Realice estas operaciones a través de PowerShell, la CLI o las solicitudes REST .

Permisos necesarios

Para realizar acciones relacionadas con el clúster, 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, como los proporcionados por el rol integrado de colaborador de Log Analytics, por ejemplo
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.

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

Un portafolio de productos de Azure Key Management enumera las bóvedas 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.

Importante

El procedimiento recomendado consiste en configurar una notificación a través de Azure Event Grid para responder eficazmente a eventos de Azure Key Vault, como una clave próxima a la expiración. Cuando la clave expira, la ingesta y las consultas no se ven afectadas, pero no se puede realizar una actualización en la clave hasta que se póngase en contacto con el soporte técnico.

Captura de pantalla de configuración de eliminación suave y protección contra 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 identitytype como SystemAssigned o UserAssigned al crear el clúster para permitir el acceso a Key Vault para que se puedan efectuar las operaciones de cifrado y descifrado de datos.

Por ejemplo, agregue estas propiedades en el cuerpo de la solicitud para la identidad administrada asignada por el sistema.

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

Nota:

El tipo de identidad se puede cambiar después de crear el clúster sin interrupciones en la ingesta o las consultas, con las consideraciones siguientes:

  • La identidad y la clave no se pueden actualizar simultáneamente para un clúster. Actualice en dos operaciones consecutivas.
  • Al actualizar SystemAssigned a UserAssigned, conceda la identidad de UserAssign en Key Vault y luego actualice en el clúster.
  • Al actualizar UserAssigned a SystemAssigned, conceda la identidad de SystemAssigned en Key Vault y luego actualice en el clúster.

Siga el procedimiento que se muestra en el artículo sobre 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 un rol con permisos de Microsoft.Authorization/roleAssignments/write y Microsoft.Authorization/roleAssignments/delete, como administrador de acceso de usuario o propietario.

    1. Abra su Key Vault en el portal de Azure y seleccione 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 Azure Portal y seleccione Políticas de acceso> Política de acceso de Vault> + Agregar política de acceso para crear una política con estas configuraciones:

    • 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.

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 mediante los roles de Propietario o Colaborador que contiene la acción */write, o bien mediante el rol de 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 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 cuál es el método adecuado antes de actualizar los detalles del id. 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.

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

Importante

Este paso solo debe realizarse después del aprovisionamiento de clústeres. Si conecta áreas de trabajo e importa datos antes del aprovisionamiento, los datos importados se eliminan y no se pueden recuperar.

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

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

Revocación de claves

Importante

  • La manera recomendada de revocar el acceso a los datos es deshabilitar la clave o eliminar 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 este enfoque, 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 en una hora o antes, y el almacenamiento deja de estar disponible. 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 anteriormente permanecerán en el almacenamiento siempre que se no se eliminen el clúster ni las áreas de trabajo. 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 habilitada la clave y unwrap se realiza correctamente, los datos SSD se vuelven a cargar desde el almacenamiento. 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:

  • Rotación automática: actualice las propiedades "keyVaultProperties" del 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 actualice 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 con una nueva en el clúster, obtiene el estado de revocación de clave.

Se podrá acceder a todos los datos tanto durante la operación de rotación de claves como después de ella. Los datos siempre se cifran con la clave de cifrado de cuenta (AEK), que se cifra con la 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 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.

Captura de pantalla de Guardar libro.

Nota:

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

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 sobre la política de cifrado en reposo de su cuenta de almacenamiento le permite proteger las consultas guardadas y las alertas de búsqueda de registros con una 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. Este detalle es importante, ya que las consultas guardadas se almacenan en table storage y solo se pueden cifrar en la creación de la cuenta de almacenamiento.
  • 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 consultas 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 contienen resultados de búsqueda ni la consulta de alerta. Use dimensiones de alerta para obtener el contexto de 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

Lockbox le proporciona la capacidad para aprobar o rechazar la solicitud del ingeniero de Microsoft para que acceda a sus datos durante una solicitud de soporte técnico.

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

Obtén más información sobre Buzón 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.

  • 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 un error: "region-name doesn't support Double Encryption for clusters", todavía puede crear el clúster sin cifrado Double, 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.

  • Se permite eliminar un área de trabajo vinculada mientras esté conectada al clúster. Si decide recuperar el área de trabajo durante el período de eliminación temporal, el área de trabajo vuelve a su 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 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.

  • 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 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.

  • 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 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:

    • El almacenamiento de operaciones normales almacena en caché AEK durante breves períodos de tiempo y vuelve a Key Vault para unwrap periódicamente.

    • 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 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 se encuentra en el estado de aprovisionamiento o en el estado de actualización, la actualización falla.

  • 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 su nombre reservado. 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 especifica inmediatamente KeyVaultProperties, es posible que la operación falle hasta que se asigne una identidad al clúster y se otorgue acceso a Key Vault.

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

  • 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 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 con '' notación para asegurarse de que el almacenamiento use siempre la versión de clave más reciente automáticamente.

  • 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 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 suave y protección contra purga. 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.

Pasos siguientes