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 y las consultas guardadas en las áreas de trabajo. Las claves administradas por el cliente de Azure Monitor proporcionan mayor flexibilidad para administrar los controles de acceso a los registros. Una vez configurados, los nuevos datos ingeridos en áreas de trabajo vinculadas se cifran con la clave almacenada en Azure Key Vaulto Azure Key Vault administrado "HSM".

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

Información general de la clave administrada por el cliente

El cifrado en reposo es un requisito común de privacidad y seguridad en las organizaciones. Puede permitir que Azure administre completamente el cifrado en reposo o puede usar varias opciones para administrar estrechamente las claves de cifrado y 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 administrar el ciclo de vida de las claves y poder revocar el acceso a los datos, puede cifrar los datos con su propia clave mediante Azure Key Vault.

Las claves administradas por el cliente están disponibles en clústeres dedicados y proporcionan un mayor nivel de protección y control. Los datos se cifran en el almacenamiento dos veces: en el nivel de servicio mediante claves administradas por Microsoft o claves administradas por el cliente, y en el nivel de infraestructura, con dos algoritmos de cifrado de diferentes y dos claves diferentes. El cifrado doble protege frente a un escenario en el que uno de los algoritmos de cifrado o claves podría 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 SSD se cifran con claves de 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 al menos 100 GB por 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 instancia de Azure Key Vault. La identidad del clúster de Log Analytics se admite en el nivel de clúster. Para permitir claves administradas por el cliente en varias áreas de trabajo, un recurso de clúster 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: 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 en un clúster nuevo o en un clúster existente que esté vinculado a áreas de trabajo y que ya esté ingiriendo datos. Los nuevos datos ingeridos en áreas de trabajo vinculadas se cifran con la clave y los datos más antiguos se ingieren antes de que la configuración permanezca cifrada con claves de Microsoft. La configuración de clave administrada por el cliente no afecta a las consultas, que siguen ejecutándose en datos antiguos y nuevos sin problemas. Puede desvincular áreas de trabajo de un clúster en cualquier momento. Nuevos datos que ingiere después de que el desvinculado se cifre con claves de Microsoft, y las consultas se realizan en datos antiguos y nuevos datos sin problemas.

Importante

La funcionalidad de claves administradas por el cliente es regional. 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.

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

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.
  • La "KEK" nunca sale de Key Vault y, si usa un "HSM administrado", nunca deja el hardware.
  • Azure Storage usa una identidad administrada asociada al recurso de Clúster para la autenticación. Accede a Azure Key Vault a través de Microsoft Entra ID.

Pasos de aprovisionamiento de la clave administrada por el cliente

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

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

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

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

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

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:

Crear clúster

Los clústeres usan la identidad administrada para el cifrado de datos con Key Vault. Configure la propiedad identity type en SystemAssigned o UserAssigned al crear el clúster para permitir el acceso a su almacén de claves para las operaciones de cifrado y descifrado de datos.

Configuración de identidad en el clúster 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 siguientes consideraciones

  • Actualización de SystemAssigned a UserAssigned: Conceder identidad UserAssign en Key Vault y, después, actualizar identity type en el clúster
  • Actualización de UserAssigned a SystemAssigned: dado que la identidad administrada asignada por el sistema se creó después de actualizar el clúster identitytype con SystemAssigned, se deben seguir los siguientes pasos
    1. Actualice el clúster y quite la clave: establezca keyVaultUri, keyName y keyVersion con el valor ""
    2. Actualice el clúster identitytype a SystemAssigned
    3. Actualice Key Vault y conceda permisos a la identidad
    4. Actualice la clave en el clúster

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

Concesión de permisos a Key Vault

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

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

    Para agregar asignaciones de roles, debe tener 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 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 por versión de clave explícita. Consulte Rotación de claves para determinar el método adecuado 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.

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.

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 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 clave dentro de una hora o antes y el almacenamiento no está 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