Partekatu honen bidez:

Configurar claves administradas por el cliente para la cuenta de Azure Cosmos DB existente con Azure Key Vault

  • Artikulua

SE APLICA A: NoSQL MongoDB Gremlin Table

La habilitación de una segunda capa de cifrado para los datos en reposo mediante claves administradas por el cliente al crear una nueva cuenta de Azure Cosmos DB ya está disponible con carácter general desde hace algún tiempo. En el siguiente paso, tenemos la capacidad de habilitar CMK en cuentas de Azure Cosmos DB existentes.

Esta característica elimina la necesidad de migrar datos a una nueva cuenta para habilitar CMK. Ayuda a mejorar la seguridad y la postura de cumplimiento de los clientes.

La habilitación de CMK inicia un proceso asincrónico en segundo plano para cifrar todos los datos existentes de la cuenta, mientras que los nuevos datos entrantes se cifran antes de conservarse. No es necesario esperar a que la operación asincrónica se realice correctamente. El proceso de habilitación consume RU sin usar o de reserva para que no afecte a las cargas de trabajo de lectura y escritura. Puede consultar este vínculo para planear la capacidad una vez cifrada la cuenta.

Para empezar, habilite CMK en las cuentas existentes

Importante

Recorra exhaustivamente la sección de requisitos previos. Estas son consideraciones importantes.

Requisitos previos

Todos los pasos previos necesarios al configurar claves administradas por el cliente para las nuevas cuentas se aplican para habilitar CMK en la cuenta existente. Consulte los pasos aquí

Nota:

Es importante tener en cuenta que habilitar el cifrado en la cuenta de Azure Cosmos DB agregará una pequeña sobrecarga al identificador del documento, lo que limita el tamaño máximo del identificador de documento a 990 bytes en lugar de 1024 bytes. Si la cuenta tiene documentos con identificadores de más de 990 bytes, el proceso de cifrado producirá un error hasta que se eliminen esos documentos.

Para comprobar si la cuenta es compatible, puede usar la aplicación de consola proporcionada hospedada aquí para examinar la cuenta. Asegúrese de que usa el punto de conexión de la propiedad de cuenta "sqlEndpoint", independientemente de la API seleccionada.

Si desea deshabilitar la validación del lado servidor para esto durante la migración, póngase en contacto con el soporte técnico.

Pasos para habilitar CMK en la cuenta existente

Para habilitar CMK en una cuenta existente, actualice la cuenta con una plantilla de ARM estableciendo un identificador de clave Key Vault en la propiedad keyVaultKeyUri, como lo haría al habilitar CMK en una nueva cuenta. Este paso se puede realizar mediante la emisión de una llamada PATCH con la carga siguiente:

    {
        "properties": {
        "keyVaultKeyUri": "<key-vault-key-uri>"
        }
    }

La salida de este comando de la CLI para habilitar CMK espera a que finalice el cifrado de datos.

    az cosmosdb update --name "testaccount" --resource-group "testrg" --key-uri "https://keyvaultname.vault.azure.net/keys/key1"

Pasos necesarios para habilitar la clave administrada por el cliente en una cuenta de Azure Cosmos DB con copia de seguridad continua o una cuenta del almacén analítico

Para habilitar CMK en una cuenta existente que tenga habilitada la copia de seguridad continua y la restauración a un momento dado, es necesario seguir algunos pasos adicionales. Siga del paso 1 al paso 5 y las instrucciones para habilitar CMK en la cuenta existente.

  1. Configuración de la identidad administrada en la cuenta de Cosmos Configuración de identidades administradas con Microsoft Entra ID para la cuenta de Azure Cosmos DB

  2. Actualización de la cuenta de Cosmos para establecer la identidad predeterminada para que apunte a la identidad administrada agregada en el paso anterior

    Para la identidad administrada por el sistema:

    az cosmosdb update--resource-group $resourceGroupName --name $accountName --default-identity "SystemAssignedIdentity"

    Para la identidad administrada por el usuario:

    az cosmosdb update -n $sourceAccountName -g $resourceGroupName --default-identity "UserAssignedIdentity=/subscriptions/00000000-0000-0000-0000-00000000/resourcegroups/MyRG/providers/Microsoft.ManagedIdentity/userAssignedIdentities/MyID"

  3. Configuración de Keyvault como se indica en la documentación aquí

  4. Incorporación de la directiva de acceso en el almacén de claves para la identidad predeterminada establecida en el paso anterior

  5. Actualización de la cuenta de Cosmos para establecer el URI de KeyVault; esta actualización desencadena la habilitación de CMK en la cuenta 

    az cosmosdb update --name $accountName --resource-group $resourceGroupName --key-uri $keyVaultKeyURI 

Limitaciones conocidas

  • No se admite la habilitación de CMK en cuentas existentes de Azure Cosmos DB para Apache Cassandra.
  • La habilitación de CMK solo está disponible en un nivel de cuenta de Cosmos DB y no en colecciones.
  • No se admite la habilitación de CMK en cuentas existentes que también están habilitadas para vistas materializadas y todas las versiones y elimina el modo de fuente de cambios.
  • Asegúrese de que la cuenta no tenga documentos con id. grandes superiores a 990 bytes antes de habilitar CMK. Si no es así, obtendrá un error debido al límite máximo admitido de 1024 bytes después del cifrado.
  • Durante el cifrado de los datos existentes, se bloquean las acciones del plano de control, como "agregar región". Estas acciones se desbloquean y se pueden usar justo después de completar el cifrado.

Supervisar el progreso del cifrado resultante

Habilitar CMK en una cuenta existente es una operación asincrónica que inicia una tarea en segundo plano que cifra todos los datos existentes. Por lo tanto, la solicitud de la API de REST para habilitar CMK proporciona en su respuesta una dirección URL "Azure-AsyncOperation". El sondeo de esta dirección URL con solicitudes GET devuelve el estado de la operación general, que finalmente se realiza correctamente. Este mecanismo se describe completamente en este artículo.

La cuenta de Cosmos DB puede seguir usándose y los datos se pueden seguir escribiendo sin esperar a que la operación asincrónica se realice correctamente. El comando de la CLI para habilitar CMK espera a que finalice el cifrado de datos.

Para permitir que una cuenta de Cosmos DB existente se use en la CMK, es necesario realizar un examen para asegurarse de que la cuenta no tiene "identificadores grandes". Un "identificador grande" es un identificador de documento que supera la longitud de 990 caracteres. Este examen es obligatorio para la migración de la CMK y Microsoft lo realiza automáticamente. Durante este proceso, es posible que vea un error.

ERROR: (InternalServerError) Error inesperado en el examen del documento para la migración de la CMK. Vuelva a intentar la operación y,

Esto sucede cuando el proceso de examen usa más RU que las aprovisionadas en la colección, lo que produce un error 429. Una solución para este problema será aumentar temporalmente sus RU significativamente. Como alternativa, puede usar la aplicación de consola proporcionada hospedada aquí para examinar sus colecciones.

Nota:

Si desea deshabilitar la validación del lado servidor para esto durante la migración, póngase en contacto con el soporte técnico. Esto es aconsejable solo si está seguro de que no hay identificadores grandes. Si se encuentra un identificador grande durante el cifrado, el proceso se detendrá hasta que se haya solucionado.

Si tiene más preguntas, póngase en contacto con Soporte técnico de Microsoft.

Preguntas más frecuentes

¿Cuáles son los factores de los que depende el tiempo de cifrado?

La habilitación de CMK es una operación asincrónica y depende de que haya suficientes RU sin usar disponibles. Se recomienda habilitar CMK durante las horas de poca actividad y, si procede, puede aumentar las RU antes, para acelerar el cifrado. También es una función directa del tamaño de los datos.

¿Tenemos que prepararnos para el tiempo de inactividad?

La habilitación de CMK inicia un proceso asincrónico en segundo plano para cifrar todos los datos. No es necesario esperar a que la operación asincrónica se realice correctamente. La cuenta de Azure Cosmos DB está disponible para lecturas y escrituras y no es necesario un tiempo de inactividad.

¿Puede aumentar la RU una vez que se ha desencadenado la CMK?

Se recomienda aumentar las RU antes de desencadenar CMK. Una vez que se desencadena la CMK, algunas operaciones del plano de control se bloquean hasta que se completa el cifrado. Este bloque puede impedir que el usuario aumente las RU una vez que se desencadene la CMK.

Para permitir que una cuenta de Cosmos DB existente se use en la CMK, Microsoft realiza automáticamente un examen de identificadores grandes para abordar una de las limitaciones conocidas enumeradas anteriormente. Este proceso también consume RU adicionales y es una buena idea aumentar significativamente las RU para evitar el error 429.

¿Hay alguna manera de invertir el cifrado o deshabilitarlo después de desencadenar CMK?

Una vez desencadenado el proceso de cifrado de datos mediante la CMK, no se puede revertir.

¿La habilitación del cifrado mediante CMK en una cuenta existente tiene un impacto en el tamaño de los datos y en las lecturas y escrituras?

Como cabría esperar, al habilitar CMK hay un ligero aumento en el tamaño de los datos y las RU para dar cabida al procesamiento adicional de cifrado y descifrado.

¿Debe realizar una copia de seguridad de los datos antes de habilitar CMK?

La habilitación de CMK no supone ninguna amenaza de pérdida de datos.

¿Se cifran las copias de seguridad antiguas como parte de la copia de seguridad periódica?

No. Las copias de seguridad periódicas antiguas no están cifradas. Las nuevas copias de seguridad generadas después de habilitar CMK están cifradas.

¿Cuál es el comportamiento de las cuentas existentes habilitadas para la copia de seguridad continua?

Cuando la CMK está activada, el cifrado también se activa para copias de seguridad continuas. Una vez activada la clave administrada por el cliente, todas las cuentas restauradas en adelante estarán habilitadas para ella.

¿Cuál es el comportamiento si la CMK está habilitada en la cuenta habilitada para PITR y restauramos la cuenta a la hora en que se deshabilitó la CMK?

En este caso, la CMK está habilitada explícitamente en la cuenta de destino restaurada por los siguientes motivos:

  • Una vez que la CMK está habilitada en la cuenta, no hay ninguna opción para deshabilitar CMK.
  • Este comportamiento está en línea con el diseño actual de la restauración de la cuenta habilitada para clave administrada por el cliente con copia de seguridad periódica

¿Qué ocurre cuando el usuario revoca la clave mientras la migración de la CMK está en curso?

El estado de la clave se comprueba cuando se desencadena el cifrado de CMK. Si la clave de Azure Key Vault está en buen estado, se inicia el cifrado y el proceso se completa sin realizar ninguna comprobación adicional. Incluso si se revoca la clave o el almacén de claves de Azure se elimina o no está disponible, el proceso de cifrado se realiza correctamente.

¿Podemos habilitar el cifrado de CMK en nuestra cuenta de producción existente?

Sí. Recorra exhaustivamente la sección de requisitos previos. Se recomienda probar primero todos los escenarios en las cuentas que no son de producción y, una vez que se sienta cómodo, puede considerar las cuentas de producción.

Pasos siguientes