Leer en inglés

Compartir vía

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

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 las claves con capacidad para revocar datos de acceso, cifre los datos con su propia clave en Azure Key Vault o "HSM" administrado de Azure Key Vault. Las funcionalidad de claves administradas por el cliente está disponibles en clústeres dedicados y proporcionan 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 identity type 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 identity type esté establecido en UserAssigned y se le concedan permisos en el almacén de claves antes de la creación del clúster.

Puede configurar claves administradas por el cliente tanto en un clúster nuevo como en un clúster existente con áreas de trabajo vinculadas que ingieran datos. De igual forma, 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. Cuando se desvinculan á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. 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 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 administrada por el cliente "KEK" en un clúster, el almacenamiento de este realiza solicitudes de "encapsulamiento" y "desencapsulamiento" a Key Vault para el cifrado y descifrado "AEK".
  • La "KEK" nunca sale de Key Vault y si almacena la clave en un "HSM" administrado de Azure Key Vault, nunca deja el hardware.
  • 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 la instancia de Key Vault
  4. Actualización de un clúster dedicado con detalles del id. de clave
  5. Vinculación de áreas de trabajo

La configuración de una clave administrada por el cliente no se admite completamente en Azure Portal en la actualidad y el aprovisionamiento se puede realizar mediante solicitudes a PowerShell, a la CLI o a 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.

Captura de pantalla de la configuración de la eliminación temporal y de la protección de purga.

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

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.
Comprobación de 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 billingType 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.

Crear clúster

Los clústeres usan la identidad administrada para el cifrado de datos con Key Vault. Configure la propiedad identity type 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 al cuerpo de la solicitud para la identidad administrada asignada por el sistema.

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

Nota

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

  • La identidad y la clave no se pueden actualizar simultáneamente, por lo que hay que efectuar dos operaciones consecutivas
  • Actualización de SystemAssigned a UserAssigned: conceda la UserAssignidentidad en Key Vault y, después, actualice identity en el clúster
  • Actualización de UserAssigned a SystemAssigned: conceda la SystemAssignedidentidad en Key Vault y, después, actualice identity 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 Key Vault en Azure Portal y seleccione Configuración>Configuración de acceso>Control de acceso basado en rol de Azure y Aplicar
    2. Haga clic en el botón Ir a control de acceso (IAM) y agregue la asignación de roles de Usuario de cifrado del servicio criptográfico de Key Vault.
    3. Seleccione Identidad administrada en la pestaña Miembros y, después, seleccione la suscripción de 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 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

    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 usarán para encapsular y desencapsular "AEK".

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 vincula áreas de trabajo e ingiere datos antes del aprovisionamiento, los datos ingeridos se quitarán y no se podrán 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 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 identity type 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 las claves que se produzcan en un plazo de una hora, o antes, y el almacenamiento deja de estar disponible. Los nuevos datos ingeridos en áreas de trabajo vinculadas se quitan 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:

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

Captura de pantalla de guardar del libro.

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

  • La caja de seguridad no se aplica a las tablas con el plan 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 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.
    • No se puede cambiar la configuración de cifrado doble 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 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 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 identity type 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.

  • El plan de tabla auxiliar no admite claves administradas por el cliente. Los datos de las tablas con el plan auxiliar se cifran con claves administradas por Microsoft, incluso si protege los datos en el resto del área de trabajo de Log Analytics mediante su propia clave de cifrado.

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.

  • La tasa de acceso a Key Vault (la frecuencia con la que el almacenamiento del clúster accede a Key Vault para empaquetar y desempaquetar) 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.

  • 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 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 a 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: la clave no se puede recuperar. Key Vault debe establecerse para la eliminación temporal y protección de 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. Si intenta crear un clúster con ese nombre y obtener un conflicto, el clúster se encuentra en el proceso de eliminación.

Pasos siguientes