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 claves de cifrado gestionadas por el cliente cuando no se puede acceder a la clave

Después de cambiar a claves gestionadas por el cliente, algunas operaciones de base de datos pueden verse 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 la red, Autonomous Database gestiona la interrupción de la siguiente forma:

  • 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 activa cuando utiliza claves de cifrado gestionadas por el cliente y no se puede acceder a Oracle Cloud Infrastructure Vault.

    Nota

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

  • Si Autonomous Database se para, no podrá iniciar la base de datos cuando no se pueda 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.

Advertencia sobre el uso de 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, algunas operaciones de base de datos pueden verse afectadas si la clave maestra está desactivada o suprimida.

  • Para operaciones de desactivación o supresión de claves en las que el valor de Estado de la clave de cifrado maestra sea cualquiera de los siguientes:

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

    La base de datos pasa a ser Inaccesible después de que el estado del ciclo de vida de la clave pase 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.

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

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

    Nota

    Solo está soportado Oracle Cloud Infrastructure Vault 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 hayan 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 antiguas de la lista del 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 bien puede clonarla desde una copia de seguridad para crear una nueva base de datos con ese registro de hora.

Consulte Visualización del historial de claves de cifrado gestionadas por el cliente en Autonomous Database para obtener más información.

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

Después de cambiar a claves gestionadas por el cliente, algunas operaciones de base de datos pueden afectar si se rota, desactiva o suprime la clave maestra y no tiene una clave válida para restaurar los datos desde una copia de seguridad guardada o desde 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 ha suprimido o desactivado.

  • 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 permite 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 Visualización del historial de claves de cifrado gestionadas por el cliente en Autonomous Database para obtener más información.

Notas sobre las 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

Al utilizar claves gestionadas por Oracle, solo puede cambiar a claves gestionadas por el cliente desde la base de datos principal. 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 de Más acciones está desactivada en una base de datos en espera.

Tenga en cuenta lo siguiente al utilizar 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 conmutación 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 un failover 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 está utilizando Autonomous Database con claves gestionadas por el cliente mientras Autonomous Data Guard está activado, Autonomous Data Guard no realiza un failover automático.

  • Las claves de cifrado gestionadas por el 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 Vault en arrendamiento remoto

Para utilizar claves de cifrado maestras gestionadas por el cliente con un almacén 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 Vault y la instancia de Autonomous Database.