Documentación de Oracle Cloud Infrastructure

Notas sobre el uso de claves gestionadas por el cliente con Autonomous Database

Proporciona información adicional y notas sobre el uso de claves gestionadas por el cliente con Autonomous Database

Tema principal: Gestión de claves de cifrado en Autonomous Database

Precaución para las claves de cifrado gestionadas por el cliente cuando la clave no es accesible

Después de cambiar a claves gestionadas por el cliente, es posible que algunas operaciones de la base de datos se vean afectadas cuando no se puede acceder a la clave.

Si la base de datos no puede acceder a la clave por algún motivo, como una interrupción de red, Autonomous Database gestiona la interrupción de la siguiente manera:

  • Hay un período de gracia de 2 horas en el que la base de datos permanece activa y en ejecución.

  • Si no se puede acceder a la clave al final del período de gracia de 2 horas, el estado del ciclo de vida de la base de datos se define en Inaccesible. En este estado, las conexiones existentes se borran y no se permiten nuevas conexiones.

  • Si Autonomous Data Guard está activado al utilizar Oracle Cloud Infrastructure Vault, durante o después del período de gracia de 2 horas, puede intentar realizar manualmente una operación de failover. El failover automático de Autonomous Data Guard no se dispara cuando se utilizan claves de cifrado gestionadas por el cliente y no se puede acceder a Oracle Cloud Infrastructure Vault.

    Nota

    Solo Oracle Cloud Infrastructure Vault está soportado con Autonomous Data Guard.

  • Si Autonomous Database está parada, no puede iniciar la base de datos cuando no se puede acceder a las claves.

    En este caso, la solicitud de trabajo que se muestra al hacer clic en el separador Solicitudes de trabajo de la página de detalles de Autonomous Database en la consola de Oracle Cloud Infrastructure muestra: 

    The Vault service is not accessible. 
Your Autonomous Database could not be started. Please contact Oracle Support.

Precaución para utilizar claves de cifrado gestionadas por el cliente cuando la clave maestra está desactivada o suprimida

Después de cambiar a claves gestionadas por el cliente, es posible que algunas operaciones de la base de datos se vean afectadas si la clave maestra está desactivada o suprimida.

  • Para operaciones de desactivación/supresión de claves donde la clave de cifrado maestra Estado es cualquiera de las siguientes:

    Almacén de Claves Key State (Estado de la clave)
    Almacén de Oracle Cloud Infrastructure (OCI)
    • DISABLING
    • DISABLED
    • DELETING
    • DELETED
    • SCHEDULING_DELETION
    • PENDING_DELETION
    Sistema de gestión de claves (KMS) de AWS
    • Disabled
    • PendingDeletion
    Almacén de claves de Azure
    • DISABLED
    • DELETED
    Oracle Key Vault (OKV)
    • COMPROMISED
    • DEACTIVATED
    • DESTROYED

    La base de datos se convierte en inaccesible una vez que el estado clave del ciclo de vida pasa a uno de estos estados. Cuando la clave está en cualquiera de estos estados, Autonomous Database borra las conexiones existentes y no permite nuevas conexiones.

    La base de datos a la que no se puede acceder puede tardar hasta 15 minutos después de las operaciones clave (Autonomous Database comprueba el proveedor de claves a intervalos de 15 minutos).

  • Si desactiva o suprime la clave de Oracle Cloud Infrastructure Vault que utiliza su instancia de Autonomous Database mientras Autonomous Data Guard está activado, Autonomous Data Guard no realizará un failover automático.

    Nota

    Solo Oracle Cloud Infrastructure Vault está soportado con Autonomous Data Guard.

  • Si activa una clave desactivada, la base de datos pasa automáticamente al estado Disponible.

  • Si suprime la clave maestra, puede comprobar el historial de claves en la consola de Oracle Cloud Infrastructure para buscar las claves que se han utilizado para la base de datos. El historial muestra el nombre de la clave, junto con un registro de hora de activación. Si una de las claves anteriores de la lista de historial aún está disponible, puede restaurar la base de datos a la hora en que la base de datos estaba utilizando esa clave o puede clonarla a partir de una copia de seguridad para crear una nueva base de datos con ese registro de hora.

Consulte View History for Customer-Managed Encryption Keys on Autonomous Database para obtener más información.

Precaución para utilizar copias de seguridad e historial de claves de cifrado gestionadas por el cliente

Después de cambiar a claves gestionadas por el cliente, es posible que algunas operaciones de la base de datos se vean afectadas si la clave maestra se rota, se desactiva o se suprime y no tiene una clave válida para restaurar los datos de una copia de seguridad guardada anteriormente o de una clonación.

  • Se recomienda crear una nueva clave que no se haya utilizado para la rotación en los últimos 60 días y utilizar esa clave para la rotación. Esto garantiza que puede volver a una copia de seguridad si la clave actual se suprime o se desactiva.

  • Al realizar varias rotaciones de clave de cifrado en un plazo de 60 días, se recomienda crear una nueva clave para cada operación de rotación de clave de cifrado maestra o especificar una clave que no se haya utilizado en los últimos 60 días. Esto ayuda a guardar al menos una clave que puede utilizar para recuperar los datos de una copia de seguridad, en el caso de que una clave de cifrado maestra gestionada por el cliente esté desactivada o suprimida.

Consulte View History for Customer-Managed Encryption Keys on Autonomous Database para obtener más información.

Notas para claves gestionadas por el cliente en OCI Vault con Autonomous Data Guard

Autonomous Data Guard está soportado al utilizar claves gestionadas por el cliente con el proveedor de claves Oracle Cloud Infrastructure Vault.

Nota

Cuando utiliza claves gestionadas por Oracle, solo puede cambiar a claves gestionadas por el cliente desde la base de datos primaria. Del mismo modo, cuando utiliza claves gestionadas por el cliente, solo puede rotar claves o cambiar a claves gestionadas por Oracle desde la base de datos primaria. La opción Gestionar clave de cifrado en Más acciones está desactivada en una base de datos en espera.

Tenga en cuenta lo siguiente cuando utilice Autonomous Data Guard con una base de datos en espera con claves gestionadas por el cliente:

  • Para que una base de datos en espera remota utilice la misma clave de cifrado maestra que la principal, la clave de cifrado maestra se debe replicar en la región remota.

    Las claves de cifrado gestionadas por el cliente solo están soportadas con una única base de datos en espera de Autonomous Data Guard entre regiones. No están soportadas varias bases de datos en espera entre regiones porque Oracle Cloud Infrastructure Vault solo soporta la replicación en una región remota.

  • La base de datos primaria y la base de datos en espera utilizan la misma clave. En caso de switchover o failover a la base de datos en espera, puede seguir utilizando la misma clave.

  • Al rotar la clave gestionada por el cliente en la base de datos primaria, esto se refleja en la base de datos en espera.

  • Al cambiar de claves gestionadas por el cliente a claves gestionadas por Oracle, el cambio se refleja en la base de datos en espera.

  • Cuando no se puede acceder a Oracle Cloud Infrastructure Vault, hay un período de gracia de 2 horas antes de que la base de datos pase al estado INACCESSIBLE. Puede realizar una conmutación por error durante o después de este período de gracia de 2 horas.

  • Si desactiva o suprime la clave de cifrado maestra de Oracle Cloud Infrastructure que utiliza Autonomous Database con claves gestionadas por el cliente mientras Autonomous Data Guard está activado, Autonomous Data Guard no realiza un failover automático.

  • Las entradas de cifrado gestionadas por cliente no están soportadas con Autonomous Data Guard entre arrendamientos.

Puede obtener más información en los siguientes enlaces:

Notas para claves de cifrado gestionadas por el cliente con clonaciones de refrescamiento

Muestra las limitaciones y notas para el uso de claves gestionadas por el cliente con clones de refrescamiento.

Nota

La opción de utilizar claves gestionadas por el cliente con una clonación de refrescamiento solo está disponible cuando la base de datos de origen utiliza el modelo de cálculo de ECPU.

Clonación de refrescamiento de la misma región con origen mediante claves de cifrado gestionadas por el cliente Notas

Autonomous Database soporta el uso de claves de cifrado gestionadas por el cliente con una clonación de refrescamiento en la misma región, de la siguiente manera:

  • Cuando la base de datos origen utiliza claves gestionadas por el cliente, puede crear una o más clonaciones de refrescamiento locales (la misma región). Las clonaciones de refrescamiento utilizan las mismas claves gestionadas por el cliente que la base de datos origen y no soportan la opción de seleccionar de forma independiente una clave diferente o de cambiar el tipo de clave en las clonaciones de refrescamiento.

  • Todos los proveedores de claves gestionadas por el cliente compatibles se admiten para una misma clonación de refrescamiento de región, incluidos: Oracle Cloud Infrastructure Vault, Microsoft Azure Key Vault, Amazon Web Services (AWS) Key Management Service (KMS) y Oracle Key Vault (OKV).

    Consulte Acerca de la administración de claves de cifrado maestras en Autonomous Database para obtener más información.

  • Puede cambiar el tipo de clave o rotar la clave en la base de datos de origen cuando la base de datos de origen tenga una o más clonaciones de refrescamiento locales. En este caso, después de cambiar la base de datos origen a un tipo de clave diferente o de rotar su clave, una clonación de refrescamiento sigue utilizando la clave antigua existente. Después de refrescar una clonación de refrescamiento, la clonación de refrescamiento cambia para utilizar el nuevo tipo de clave de origen o para utilizar la clave rotativa.

  • Al aprovisionar una clonación de refrescamiento a partir de un origen mediante una clave gestionada por el cliente, los grupos dinámicos y las políticas deben abarcar la clonación de refrescamiento para que la clonación de refrescamiento también pueda acceder a la clave. Si las políticas y los grupos dinámicos no incluyen la clonación de refrescamiento, el aprovisionamiento falla. Del mismo modo, si el origen ya tiene una clonación de refrescamiento y está cambiando de claves gestionadas por Oracle a claves gestionadas por el cliente, el conmutador no se realizará correctamente si los grupos dinámicos y las políticas no incluyen la clonación de refrescamiento.

    Consulte Requisitos para crear una clonación de refrescamiento para obtener más información.

Consulte Creación de una clonación de refrescamiento para una instancia de de Autonomous Database para obtener más información.

Clonación de refrescamiento entre regiones con origen mediante claves de cifrado gestionadas por el cliente Notas

Autonomous Database soporta el uso de claves de cifrado gestionadas por el cliente con una clonación de refrescamiento entre regiones, de la siguiente manera:

  • Cuando la base de datos origen utiliza claves gestionadas por el cliente, puede crear una clonación de refrescamiento entre regiones. La clonación de refrescamiento utiliza las mismas claves gestionadas por el cliente que la base de datos origen y no soporta la opción de seleccionar de forma independiente una clave diferente o de cambiar el tipo de clave en la clonación de refrescamiento.

    En este caso, solo OCI Vault está soportado para la clonación de refrescamiento entre regiones y la clave del origen se debe replicar en la región remota.

  • El proveedor de claves gestionado por el cliente con soporte con una clonación de refrescamiento entre regiones es: Oracle Cloud Infrastructure Vault.

    Consulte Acerca de la administración de claves de cifrado maestras en Autonomous Database para obtener más información.

  • Cuando una clonación de refrescamiento entre regiones utiliza una clave gestionada por el cliente, los grupos dinámicos y las políticas deben abarcar la clonación de refrescamiento. Si las políticas y los grupos dinámicos no incluyen la clonación de refrescamiento, el aprovisionamiento falla. Del mismo modo, si el origen ya tiene una clonación de refrescamiento y está cambiando de claves gestionadas por Oracle a claves gestionadas por el cliente, el conmutador no se realizará correctamente si los grupos dinámicos y las políticas no incluyen la clonación de refrescamiento.

    Consulte Requisitos para crear una clonación de refrescamiento para obtener más información.

Consulte Creación de un clon de refrescamiento entre arrendamientos o entre regiones para obtener más información.

Clonación de refrescamiento entre arrendamientos con origen mediante claves de cifrado gestionadas por el cliente (Notas)

Autonomous Database no soporta el uso del cifrado gestionado por el cliente con un clon de refrescamiento entre arrendamientos.

Consulte Creación de un clon de refrescamiento entre arrendamientos o entre regiones para obtener más información.

Restauración de la Base de Datos de Origen con una Clonación de Refrescamiento mediante Claves de Cifrado Gestionadas por el Cliente Notas

Si una base de datos origen tiene una clonación de refrescamiento y la base de datos origen se restaura a partir de copias de seguridad, la base de datos origen comenzará a utilizar la clave que estaba en uso en el momento en que se restauró la base de datos origen.

En este caso, tenga en cuenta los siguientes casos:

  • Si la clonación de refrescamiento estaba retrasada y su punto de refrescamiento era anterior al punto de restauración, lo que significa que la clonación de refrescamiento tenía datos anteriores a la base de datos de origen restaurada, comenzará a utilizar la misma clave que la base de datos de origen después del siguiente refrescamiento (un refrescamiento vuelve a crear la clonación de refrescamiento a partir de la base de datos de origen).

  • Si el punto de refrescamiento de la clonación de refrescamiento era posterior al punto de restauración, lo que significa que la clonación de refrescamiento tenía datos más recientes que la base de datos de origen restaurada, la clonación de refrescamiento se vuelve a crear automáticamente cuando alcanza el mismo punto en el tiempo con los refrescamientos. En ese momento, debería empezar a mostrar la misma clave que el origen.

Consulte Restauración y recuperación de su instancia de Autonomous Database para obtener más información.

Clonación de refrescamiento desconectada mediante claves de cifrado gestionadas por el cliente Notas

Si se desconecta una clonación de refrescamiento con una base de datos de origen que utiliza claves gestionadas por el cliente, la clonación de refrescamiento se puede volver a conectar a la base de datos de origen. Si mientras la clonación de refrescamiento se desconecta del origen, la clave de la base de datos origen cambia, la clonación de refrescamiento cambia para utilizar la nueva clave cuando la clonación de refrescamiento se vuelve a conectar y refresca.

Notas para claves gestionadas por el cliente con almacén en arrendamiento remoto

Para utilizar claves de cifrado maestras gestionadas por el cliente con un almacén de claves en un arrendamiento remoto, tenga en cuenta lo siguiente:

Al utilizar claves de cifrado maestras gestionadas por el cliente con un almacén en un arrendamiento remoto, el almacén y la instancia de Autonomous Database deben estar en la misma región. Para cambiar el arrendamiento, en la página de conexión, haga clic en Cambiar arrendamiento. Después de cambiar el arrendamiento, asegúrese de seleccionar la misma región para la instancia de Vault y Autonomous Database.