B Uso de OKM con el cifrado de datos transparente (TDE) de Advanced Security
En este apéndice, se describe el uso de OKM con cifrado de datos transparente (TDE) para gestionar el cifrado o el descifrado de información confidencial de bases de datos. Esta solución permite gestionar claves de cifrado para la base de datos Oracle con la misma tecnología de cifrado que se utiliza en las unidades de cinta Oracle StorageTek.
El cifrado de datos transparente, una característica de Oracle Database 11g R2, ofrece servicios de cifrado y descifrado de bases de datos para:
-
Productos Oracle Database
-
Oracle Real Application Clusters (Oracle RAC)
-
Oracle Data Guard
-
Oracle Exadata Database Machine
-
Oracle Recovery Manager (RMAN)
-
Oracle Data Pump
En este apéndice, se asume que está familiarizado con TDE. Consulte el documento Oracle Advanced Security Transparent Data Encryption Best Practices, disponible en la siguiente URL:
http://www.oracle.com/us/products/database/twp-transparent-data-encryption-bes-130696.pdf
Descripción general del cifrado de datos transparente (TDE)
En la Figura B-1, se muestra un cluster de OKM que incluye bases de datos Oracle con cifrado de datos transparente (TDE). Consulte el Capítulo 1, "Introducción" para obtener más información sobre los componentes básicos del cluster de OKM.
TDE ofrece servicios de cifrado por medio de un enfoque de claves de dos niveles para el cifrado de columnas de TDE y el cifrado de tablespaces de TDE. Se utiliza una clave de cifrado maestra en el primer nivel para cifrar las claves de cifrado de datos de tablas o tablespaces de segundo nivel que se almacenan en la base de datos.
TDE almacena la clave de cifrado maestra en un módulo de seguridad externo (Oracle Wallet o HSM). Ésta es una práctica de seguridad recomendada y es fundamental para mantener el nivel más alto de seguridad ante diferentes amenazas. El uso de OKM para el almacenamiento seguro de las claves de cifrado maestras de TDE es el enfoque recomendado.
Cuando TDE se configura para usar OKM, OKM crea y protege la clave de cifrado maestra AES de 256 bits. OKM protege las claves mediante la replicación (varias copias en todo el cluster) y mediante copias de seguridad del propio OKM.
Consulte la Guía de recuperación ante desastres de OKM para obtener información sobre la planificación de la recuperación ante desastres.
Proveedor PKCS#11 de OKM
Hay disponible un proveedor PKCS#11 para Oracle Solaris y Oracle Linux, el cual se ha certificado para utilizar TDE con OKM. Este proveedor se denomina "pkcs11_kms". TDE se puede configurar para usar el proveedor pkcs11_kms a través de la compatibilidad integrada para módulos de seguridad de hardware (HSM).
El proveedor pkcs11_kms interactúa con OKM para las operaciones de creación y recuperación de claves. Las aplicaciones de consumidor PKCS#11, como TDE, pueden utilizar el proveedor pkcs11_kms a fin de adquirir claves para las funciones de cifrado y descifrado. Estas aplicaciones identifican objetos de clave mediante una etiqueta definida por ellas. TDE genera esta etiqueta cuando se crea la clave maestra. El proveedor pkcs11_kms transfiere esta etiqueta a OKM, donde se mantiene como metadatos en la unidad de datos. En OKM, las claves están asociadas a unidades de datos y, en el proveedor pkcs11_kms, esta relación siempre es 1:1. Cada vez que se genera una nueva clave maestra, se crea una unidad de datos con la etiqueta de la clave, junto con el objeto de clave correspondiente.
Consulte "Ubicación de las claves maestras de TDE en OKM" para obtener más información.
Autenticación de TDE con OKM
Cualquier entidad que interactúe con OKM debe autenticarse, ya sea un usuario administrativo que inicia sesión, una unidad de cinta que recupera material de claves o un consumidor PKCS#11 como Oracle TDE.
TDE se autentica con OKM a través del token específico configurado para utilizar el proveedor pkcs11_kms. Este token usa una autenticación basada en contraseñas y certificados X.509 para la autenticación mutua de cada participante de la sesión, específicamente la instancia de Oracle Database y el nodo de cluster de OKM. Debe configurar TDE para que transfiera correctamente estas credenciales al token PKCS#11.
Para obtener instrucciones de configuración, consulte el documento Oracle Advanced Security Transparent Data Encryption Best Practices, al que se hace referencia al principio de este apéndice.
Gestión de credenciales de autenticación
OKM permite gestionar credenciales de autenticación par agentes mediante el proveedor pkcs11_kms. Puede restablecer frases de contraseña de agentes, y activar, desactivar o suprimir agentes de acuerdo con los requisitos de las políticas.
Si se detecta una infracción de seguridad, puede desactivar el agente correspondiente para denegar la recuperación de claves, a la vez que se permite que otros agentes que atienden otras aplicaciones o dispositivos mantengan su acceso.
Si restablece la frase de contraseña de un agente, elimine el directorio de perfiles en el que el proveedor pkcs11_kms almacena su configuración de ranura (por ejemplo, la ubicación definida por el directorio KMSTOKEN_DIR).
Equilibrio de carga y failover
El proveedor pkcs11_kms reconoce el cluster de OKM mediante los servicios de cluster de OKM, un equilibrador de carga y una lógica de failover de cluster. Para mantener de manera transparente el reconocimiento en el cliente del cluster de OKM, el proveedor pkcs11_kms realiza operaciones de detección de cluster periódicamente. Los cambios de red y los cambios en la disponibilidad de los dispositivos de gestión de claves o el cluster de OKM se gestionan por medio del agente en nombre del proveedor pkcs11_kms y TDE. Se equilibra la carga de las operaciones de generación y recuperación de claves de PKCS#11 entre los dispositivos de gestión de claves del cluster de OKM.
Para optimizar aún más el rendimiento de la recuperación de claves, es posible configurar los agentes para asociarlos con dispositivos de gestión de claves a través de sitios de OKM. Esta característica permite definir sitios de acuerdo con la topología de red. Por lo general, los agentes y los dispositivos de gestión de claves de un sitio tienen una latencia de red baja, en comparación con los agentes y los dispositivos de gestión de claves miembros de una WAN.
Cuando un segmento de red o un dispositivo de gestión de claves no están disponibles, la lógica de failover del agente selecciona otro dispositivo de gestión de claves para completar la operación. TDE no reconoce ningún failover, por lo que las operaciones de gestión de claves son sumamente fiables. El failover da prioridad a los dispositivos de gestión de claves que se encuentran en el mismo sitio que el agente.
Puede usar la utilidad kmscfg(1M) para ajustar la frecuencia de detección y las propiedades de failover del agente. Para obtener más información, consulte la página del comando man kmscfg.
Consideraciones de planificación
En las secciones siguientes, se tratan diferentes temas relacionados con la planificación:
-
Consideraciones de Oracle Database
-
Consideraciones de rendimiento y disponibilidad de OKM
-
Planificación de la recuperación ante desastres
-
Planificación de la red
-
Planificación de la gestión de claves
Consideraciones de Oracle Database
OKM es compatible con cualquiera de las siguientes configuraciones de Oracle Database:
-
Instancia única: Oracle RAC One Node
-
Arquitecturas de alta disponibilidad de Oracle Database
-
Oracle RAC
El uso de Oracle Database con Oracle Real Application Clusters (Oracle RAC) está certificado para OKM. Cada nodo del sistema Oracle RAC requiere un proveedor pkcs11_kms configurado para que lo utilice TDE. Todos los nodos deben tener el mismo ID de agente de OKM para la autenticación. Con Oracle RAC, la topología de red utiliza una red pública y privada. La red privada que se utiliza para el tráfico de nodo a nodo de Oracle RAC se puede compartir con la red de servicio de OKM a fin de mejorar el aislamiento del tráfico de recuperación de claves. Según la configuración de esta red privada, es probable que esto impida el failover del agente en dispositivos de gestión de claves externos a la red privada, por ejemplo, dispositivos de gestión de claves de un sitio remoto.
Consulte "Integración de OKM y TDE" para conocer los requisitos de almacenamiento compartido con Oracle RAC y los archivos de configuración del proveedor pkcs11_kms.
-
Oracle RAC Extended Cluster
En esta configuración, los dispositivos de gestión de claves del cluster de OKM deben colocarse en la red junto con los nodos de Oracle RAC para minimizar el tiempo de recuperación.
-
Oracle Exadata Database Machine
Consulte arriba "Oracle RAC".
-
-
Oracle Data Guard
Todas las bases de datos secundarias acceden al mismo cluster de OKM que utiliza la base de datos primaria.
-
Varias instancias de base de datos
Al ejecutar varias instancias de base de datos independientes en un host, se debe configurar un token PKCS#11 para cada instancia. Esto supone crear un agente de OKM para cada instancia de base de datos y autenticar el agente en OKM mediante el token. Utilice la herramienta kmscfg para completar esta tarea.
Al ejecutar varias instancias de base de datos con el mismo usuario del sistema operativo, pero con distintos agentes de OKM, debe establecer la variable de entorno KMSTOKEN_DIR en una ubicación diferente cada vez que invoca la utilidad kmscfg. Consulte "Configuración de OKM para TDE" para obtener más información sobre la utilidad kmscfg.
Para obtener más información sobre cómo ejecutar varias bases de datos en el mismo host, consulte el documento Oracle Advanced Security Transparent Data Encryption Best Practices, al que se hace referencia al principio de este apéndice.
-
Oracle RMAN
-
Oracle Data Pump
Consideraciones de rendimiento y disponibilidad de OKM
La recuperación de claves para TDE a través del token pkcs11_kms generalmente tarda entre 100 y 200 milisegundos por cada acceso del dispositivo de gestión de claves. Cuando se producen failovers, el tiempo de respuesta es un múltiplo de la cantidad de intentos de failover.
Las operaciones de copia de seguridad y transferencia de claves de OKM son actividades que consumen muchos recursos y, por lo tanto, pueden afectar el rendimiento de la base de datos de OKM. Planifique su estrategia con cuidado para determinar cuándo y dónde se realizarán las copias de seguridad de OKM.
Dado que las copias de seguridad de OKM se aplican a todo el cluster, pueden llevarse a cabo en los dispositivos de gestión de claves que no atienden instancias de Oracle Database. Las operaciones de transferencia de claves también se aplican a todo el cluster y se pueden efectuar en cualquier dispositivo de gestión de claves. Por lo tanto, se recomienda elegir un dispositivo de gestión de claves que no atienda instancias ocupadas de Oracle Database.
Planificación de la recuperación ante desastres
Para obtener información detallada sobre la planificación de la recuperación ante desastres de OKM, consulte la Guía de recuperación ante desastres de OKM, junto con las publicaciones de bases de datos Oracle.
Las decisiones relacionadas con la planificación de la recuperación ante desastres afectan la tarea de planificación de la red. El directorio de configuración del proveedor pkcs11 es un nuevo aspecto que se debe tener en cuenta para la planificación de la recuperación ante desastres. Considere diferentes escenarios de recuperación para esta área de almacenamiento para no tener que reconfigurar un token pkcs11_kms, especialmente cuando se comparte entre nodos de un sistema Oracle RAC.
Planificación de la red
La configuración del cluster de OKM se debe planificar de acuerdo con los servidores de Oracle Database y la estrategia de recuperación ante desastres de la empresa. Las opciones de red de OKM son muy flexibles e incluyen interfaces de hosts múltiples utilizadas por la red de servicio y gestión de OKM. Consulte la Guía de aseguramiento de sistemas de OKM para obtener más información.
Planificación de la gestión de claves
La planificación de la gestión de claves debe cumplir las políticas de seguridad y ciclo de vida de claves de la empresa. Naturalmente, estas consideraciones generarán debates sobre la retención de datos.
-
Consulte "Transición de estado" para obtener información sobre las fases de gestión de claves de NIST SP-800 y los estados correspondiente de las claves de OKM.
-
Consulte "Regeneración de claves debido a la caducidad basada en políticas de OKM" para obtener información sobre un problema que puede surgir cuando una política de claves no se establece en un período con la extensión adecuada.
Consideraciones de políticas de claves
Todas las claves maestras de TDE son claves AES de 256 bits generadas por OKM. Los dispositivos de gestión de claves pueden incluir Sun Crypto Accelerator 6000 PCIe Card, un HSM con la certificación FIPS 140-2 de nivel 3. Cuando los dispositivos de gestión de claves tienen este módulo de seguridad de hardware, el HSM crea sus claves. En caso contrario, las operaciones criptográficas utilizan el proveedor de tokens del software de la estructura criptográfica de Solaris. Consulte "Políticas de claves" para obtener más información.
Ciclo de vida de claves
El ciclo de vida de las claves es el principal elemento de configuración para las decisiones relacionadas con la planificación de políticas de claves. Los períodos de la fase operativa del ciclo de vida de las claves se deben determinar de acuerdo con las necesidades de retención de datos y la frecuencia con la que se volverán a generar las claves maestras de TDE. Consulte "Ciclo de vida de claves" para obtener más información.
Nota:
El DDL de TDE admite la especificación de varios tamaños para la clave maestra como los cuadros de diálogo de cifrado de esquemas de OKM. Sólo se pueden usar claves AES de 256 bits con OKM.Período de cifrado de políticas de claves
El período de cifrado de las políticas de claves define por cuánto tiempo se usará la clave en el estado de protección y procesamiento (cifrado y descifrado) del ciclo de vida. Este período se debe corresponder con el período de uso de la clave maestra antes de que se deba volver a generar (por ejemplo, un año como máximo para PCI).
Período criptográfico de políticas de claves
El período criptográfico de las políticas de claves representa el tiempo restante asignado para usar la clave maestra para descifrar datos durante el estado de procesamiento (descifrado) únicamente del ciclo de vida de las claves. La duración de este período debe ajustarse a los requisitos de retención de los datos protegidos por la clave maestra de TDE. Por lo general, este valor representa la cantidad de años correspondientes a la política de retención de datos de la empresa (por ejemplo, un período de retención de siete años para los registros fiscales de EE. UU.).
La frecuencia con la que se generarán las nuevas claves no debe ser una preocupación con TDE, ya que es probable que las operaciones de regeneración de claves sean poco frecuentes. Sin embargo, si se vuelve una preocupación, considere la posibilidad de extender el período de cifrado para la política de claves y de volver a generar las claves con menos frecuencia. También puede incrementar el parámetro de configuración del tamaño de la agrupación de claves de OKM para indicar a los dispositivos de gestión de claves que mantengan una agrupación más grande de claves disponibles.
Es posible definir varias políticas de claves para usar con diferentes tipos de bases de datos de acuerdo con las necesidades.
Control de acceso a claves mediante grupos de claves
Es posible que sea necesario controlar el acceso a las claves gestionadas por OKM cuando varias instancias de base de datos o varios agentes acceden al cluster de OKM para distintos fines.
Todos los agentes de OKM se asignan como mínimo a un grupo de claves (se requiere una asignación de grupo de claves predeterminada), que los autoriza a tener acceso a las claves de esos grupos. El grupo de claves predeterminado del agente es el único grupo de claves dentro del cual creará claves el agente del proveedor pkcs11_kms.
Considere el uso de varios grupos de claves cuando no sea necesario compartir claves maestras entre varias instancias de base de datos o hosts. Un ejemplo puede ser utilizar un grupo de claves para las instancias de base de datos de producción y otro para las bases de datos de desarrollo o prueba, con el fin de garantizar el aislamiento. OKM luego bloqueará los agentes del grupo de claves de la base de datos de prueba si intentan usar una clave maestra para una base de datos de producción. Ese intento también se marcará en el log de auditoría de OKM y puede indicar un error de configuración que podría interrumpir el funcionamiento de una base de datos de producción.
TDE también proporciona aislamiento de claves maestras a través de su convención de denominación de etiquetas de claves. En la especificación PKCS#11, no se requiere que las etiquetas de claves sean únicas. No obstante, OKM exige el uso de etiquetas únicas, independientemente del grupo de claves, para que el alcance del espacio de nombres de las etiquetas sea global para un cluster de OKM. Si se genera un conflicto de etiquetas entre diferentes claves maestras para distintas instancias de base de datos, siempre se devuelve la primera etiqueta creada. OKM denegará el acceso de cualquier agente que intente acceder a una clave que comparta una etiqueta idéntica perteneciente a otro grupo de claves. Esto se detecta durante una operación de regeneración de claves, y la solución alternativa es volver a generar la clave hasta que se cree una etiqueta diferente que no esté en conflicto con ninguna otra.
Consideraciones de destrucción de claves y datos
La destrucción de datos para cumplir con los requisitos de retención de datos puede comenzar con la destrucción de las claves maestras de TDE. Un elemento importante de la planificación es determinar cómo y cuándo se destruirán estas claves. OKM permite realizar esta tarea y supervisar las copias de seguridad de OKM, que incluyen estas claves. La gestión de las copias de seguridad de OKM es tanto un elemento de la planificación de la recuperación ante desastres como de la destrucción de claves.
Integración de OKM y TDE
En esta sección, se describe cómo instalar y configurar pkcs11_kms y el cluster de OKM para su uso con TDE.
Requisitos del sistema
Se admiten las siguientes versiones mínimas al utilizar OKM con TDE:
Oracle Key Manager
Oracle Key Manager 2.4.1 con Replication Schema versión 13
Las plataformas admitidas de gestión de OKM para la GUI y la CLI están documentadas en las notas de la versión del producto OKM, que incluyen consideraciones específicas para las plataformas Oracle Solaris y Microsoft Windows.
pkcs11_kms
-
Oracle Solaris 11 Express con SRU 12
-
pkcs11_kms para Oracle Solaris 11, x86 o SPARC, de 32 bits o 64 bits
-
pkcs11_kms para Oracle Solaris 10 Update 10, con el parche 147441-03 para x86 o el parche 147159-02 para SPARC, de 32 bits o 64 bits
-
Oracle Enterprise Linux (OEL) versión 5.5
-
Oracle Database 11.2.0.2 en una plataforma admitida de pkcs11_kms y el parche obligatorio 12626642
Instalación de OKM
El proceso de instalación del cluster de OKM se describe en la Guía de instalación de OKM. Por lo general, la instalación de OKM implica la contratación de los servicios profesionales de Oracle, para recibir ayudar con las opciones de servicios de planificación, instalación y configuración. Además, también se recomienda que su equipo de seguridad esté involucrado en el proceso de planificación.
Tras establecer un cluster de OKM en funcionamiento, siga los pasos de administración de OKM descritos en las secciones de configuración de este apéndice.
Instalación de pkcs11_kms
Debe instalar y configurar el proveedor PKCS#11 de OKM, pkcs11_kms, en los servidores de Oracle Database. Hay una distribución de pkcs11_kms disponible para cada una de las plataformas siguientes:
-
Oracle Solaris 11 o Solaris 11 Express
-
Oracle Solaris 10 Update 10
-
Oracle Enterprise Linux
Instalación de pkcs11_kms para Oracle Solaris 11 o Solaris 11 Express
Lleve a cabo los siguientes pasos para instalar pkcs11_kms:
-
Visualice la versión del paquete de pkcs_kms:
#> pkg info -r pkcs11_kms
Verifique la salida de este comando.
-
Para Solaris 11, escriba el siguiente comando:
#> pkg install system/library/security/pkcs11_kms
Para Solaris 11 Express, escriba el siguiente comando:
#> pkg install system/library/security/crypto/pkcs11_kms
-
Instale el proveedor en la estructura criptográfica de Solaris.
# cryptoadm install provider='/usr/lib/security/$ISA/pkcs11_kms.so.1'
Nota:
Las comillas simples son importantes. Consulte cryptoadm(1M). -
Escriba la siguiente secuencia de comandos para verificar la instalación:
# cryptoadm list -m -v \ provider='/usr/lib/security/$ISA/pkcs11_kms.so.1'
Nota:
Se muestra el mensaje "no slots presented" (sin ranuras presentes) hasta que se ejecuta kmscfg.
Instalación de pkcs11_kms para Oracle Solaris 10 Update 10
La distribución de pkcs se instala como "SUNWpkcs11kms" en las instalaciones de Solaris 10 Update 10.
-
Los sistemas SPARC requieren el parche de Solaris 147159-03 o posterior.
-
Los sistemas x86 requieren el parche de Solaris 147441-03 o posterior.
Para descargar los parches de Solaris, visite la siguiente URL:
https://patchstatus.us.oracle.com/patchstatus/
Lleve a cabo los siguientes pasos para instalar pkcs11_kms:
-
Escriba el siguiente comando para instalar el paquete de pkcs11_kms para la plataforma de hardware:
# pkgadd [-d path to parent dir of package] SUNWpkcs11kms
-
Instale el proveedor en la estructura criptográfica de Solaris.
# cryptoadm install provider='/usr/lib/security/$ISA/pkcs11_kms.so.1'
Nota:
Las comillas simples son importantes. Consulte cryptoadm(1M).
Instalación de pkcs11_kms para Oracle Enterprise Linux
pkcs11_kms se distribuye como "parche" 13245560 en el sitio My Oracle Support, en la siguiente URL:
http://www.myoraclesupport.com
Inicie sesión y haga clic en la ficha Patches & Updates (Parches y actualizaciones). A continuación, busque este ID de parche específico directamente, o realice una búsqueda en el producto Oracle Key Manager y la versión 2.5.
pkcs11_kms se distribuye como un paquete RPM. Utilice los comandos de RPM Package Manager para instalar este software.
Por ejemplo:
# rpm -i pkcs11kms-1.0.0-1.x86_64.rpm
Desinstalación de pkcs11_kms
Los siguientes comandos permiten desinstalar pkcs11_kms.
Desinstalación de pkcs11_kms para Oracle Solaris 11
Para desinstalar pkcs11_kms, escriba los siguientes comandos:
# cryptoadm uninstall \ provider='/usr/lib/security/$ISA/pkcs11_kms.so.1' # pkg uninstall system/library/security/pkcs11_kms
Desinstalación de pkcs11_kms para Oracle Solaris 10 Update 10
Para desinstalar pkcs11_kms, escriba el siguiente comando:
# pkgrm SUNWpkcs11kms
Desinstalación de pkcs11_kms para Oracle Enterprise Linux
Cuando se incluye en un paquete con Oracle Database, el proveedor pkcs11_kms se desinstalará siguiendo los pasos utilizados para desinstalar el producto Oracle Database. Si se instala por otro medio, siga los procedimientos inversos de la instalación mediante RPM.
Por ejemplo:
# rpm -e pkcs11kms-1.0.0-1.x86_64.rpm
Configuración de OKM para TDE
En la siguiente sección, se describe la configuración de TDE.
Configuración de TDE de Oracle Database
Cada servidor de Oracle Database debe ejecutar la versión 11.2.0.2 o posterior en una plataforma admitida de pkcs11_kms. Se debe instalar el parche obligatorio 12626642. Este parche está disponible en la siguiente URL:
https://updates.oracle.com/download/12626642.html
Una vez instalado, el archivo de la biblioteca compartida (pkcs_kms.so) también se debe configurar para el acceso de TDE. La ruta de la biblioteca es específica del sistema operativo:
-
/usr/lib/security/pkcs11_kms.so.1(Solaris únicamente, 32 bits) -
/usr/lib/security/amd64/pkcs11_kms.so.1(Solaris únicamente, 64 bits) -
/usr/lib64/pkcs11_kms.so.1(Linux únicamente, 64 bits)
Configuración del cluster de OKM para TDE
En la siguiente lista, se resumen las tareas necesarias para configurar el cluster de OKM para TDE:
-
Estas tareas asumen que hay un cluster operativo de OKM configurado con los usuarios y roles administrativos adecuados.
-
Todos los dispositivos de gestión de claves del cluster de OKM deben ejecutar como mínimo OKM 2.4.1 y Replication Schema versión 13.
-
Defina la política de claves.
Consulte:
-
Determine la definición del grupo.
Asigne la política de claves al grupo de claves y un nombre descriptivo al grupo.
Consulte:
-
Configure los agentes.
Consulte:
-
Asocie cada agente a un grupo de claves predeterminado.
Consulte: "Menú Key Group Assignment to Agents (Asignación de grupos de claves a agentes)"
ID de agente
El ID de agente puede ser cualquier elemento relevante para la configuración y se debe corresponder con el usuario de Oracle de la instancia de base de datos que se asociará al agente.
Frase de contraseña
Elija una frase de contraseña segura, ya que esta frase de contraseña también se configurará en el host de Oracle para la autenticación con OKM a través de las sentencias DDL que abren la cartera (por ejemplo, el token pkcs11_kms). Consulte "Creación de un agente" para obtener información sobre los requisitos de la frase de contraseña.
El indicador OneTimePassphrase se debe establecer en "false" para permitir la autenticación basada en contraseñas siempre que sea necesario abrir la "cartera" de TDE y también desde varios nodos de Oracle RAC con un ID de agente común. Para lograr un nivel de seguridad máximo, el indicador se puede establecer en el valor predeterminado "true", pero sólo funcionará en una configuración de Oracle Database de nodo único y no en Oracle RAC. Cuando OneTimePassphrase se establece en "true", el certificado X.509 del agente sólo se devuelve cuando el agente se autentica correctamente por primera vez. El proveedor pkcs11_kms almacena de manera segura la clave privada del certificado X.509 en un archivo PKCS#12 protegido mediante una frase de contraseña. El certificado X.509 y la clave privada correspondiente luego se utilizan para las transacciones del agente con OKM. Consulte kmscfg(1M) para conocer qué otra información almacena el proveedor pkcs11_kms.
Grupo de claves
Asigne el agente a los grupos de claves definidos para TDE. El proveedor pkcs11_kms sólo admite el grupo de claves predeterminado para las operaciones de creación de claves, incluidas las operaciones de regeneración. Todos los grupos de claves adicionales no predeterminados que se asocien al agente sólo permitirán la recuperación de claves a partir de las claves de esos grupos. Esta característica se puede aprovechar en los escenarios de bases de datos de sólo lectura o sólo descifrado, por ejemplo, para admitir una base de datos secundaria que nunca generará una clave maestra y que sólo necesita poder acceder a las claves maestras.
Configuración de pkcs11_kms para TDE
El proveedor pkcs11_kms se debe configurar en los nodos de Oracle Database que requerirán claves maestras de TDE. Lleve a cabo los siguientes pasos para configurar el proveedor pkcs11_kms:
-
Consideraciones del usuario del sistema operativo:
Configure el agente y el proveedor pkcs11_kms con la cuenta de usuario de Oracle Database. No se necesitan privilegios especiales para el usuario del sistema operativo. Cuando un host admite varios directorios raíz de Oracle, la configuración del token pkcs11_kms se debe establecer de acuerdo con la cuenta de usuario de cada propietario del software Oracle Database. Consulte la Guía de instalación de Oracle Database 11g versión 2 para obtener más información.
-
La utilidad kmscfg crea una configuración de ranura por usuario a la vez. Es posible definir otras configuraciones de ranura para un usuario individual, pero sólo una estará activa por cada proceso.
Precaución:
La ubicación predeterminada del directorio de configuraciones de ranura para el proveedor PKCS#11 de KMS es /var/kms/$USER en Solaris 11 Express y /var/user/$USER/kms en Solaris 11 SRU 5. Si planea actualizar el sistema Solaris 11 Express a Solaris 11 SRU 5, primero debe guardar la configuración de ranura en otro lugar.Por ejemplo:
# cd /var/kms/$USER# tar cvf ~/save_my_okm_config.tarDespués de la actualización, restaure la configuración de ranura en la nueva ubicación. Por ejemplo:
# mkdir -p /var/user/$USER/kms# cd /var/user/$USER/kms# tar xvf ~/save_my_okm_config.tar
Si no realiza una copia de seguridad de los datos de pcks11_kms antes de la actualización, los datos se perderán y la clave maestra utilizada por la base de datos Oracle para los datos cifrados no estará disponible.
La utilidad kmscfg almacena datos de configuración y de tiempo de ejecución en un directorio de configuración de KMS, en una de las siguientes rutas:
-
/var/user/$USER/kms (Solaris 11) -
/var/kms/$USER(Solaris 10u10 y Solaris 11 Express) -
/var/opt/kms/$USER(Oracle Enterprise Linux)
La variable de entorno $KMSTOKEN_DIR sustituye este directorio por la ubicación que elija el cliente.
Cuando se ejecuta kmscfg, se proporciona un nombre de "perfil". Este nombre se utiliza para el subdirectorio de tiempo de ejecución específico del agente, creado en el directorio de configuración descrito anteriormente.
-
-
Consulte la página del comando man kmscfg para conocer la ubicación predeterminada de sus configuraciones de ranura. Las configuraciones de ranura se pueden controlar mediante la variable de entorno KMSTOKEN_DIR para definir una ubicación de sistema de archivos y una configuración de ranura alternativas.
En Oracle RAC, cuando el perfil de agente se deba compartir entre los nodos de Oracle RAC, utilice la variable de entorno KMSTOKEN_DIR para indicar a kmscfg que cree el perfil con la ruta adecuada del sistema de archivos compartido. Si se establece la variable de entorno KMSTOKEN_DIR, se debe establecer de manera persistente para el shell en un archivo de configuración de shell (como .bashrc), para que siempre esté definida antes que la base de datos realice cualquier operación de PKCS#11.
-
Asigne espacio de almacenamiento en el sistema de archivos para la información de tiempo de ejecución y de configuración de ranura. Si planea utilizar Oracle RAC, defina el perfil en una ubicación de sistema de archivos compartida con permisos que los usuarios de los nodos de Oracle RAC puedan leer y escribir.
-
Asigne los requisitos de espacio para permitir el crecimiento en el log de cada agente. El archivo log se crea automáticamente y es una herramienta útil para resolver problemas. El espacio utilizado por el archivo KMSAgentLog.log se puede gestionar con una herramienta como logadm(1M) en Solaris o logrotate(8) en Oracle Enterprise Linux. Asignar 10 MB para el directorio de perfiles de cada agente resulta adecuado para la mayoría de las configuraciones.
-
Inicialice un proveedor pkcs11_kms con la utilidad kmscfg. En este paso, se define un perfil para el agente de OKM que luego se asociará con un token pkcs11_kms.
# kmscfg Profile Name: oracle Agent ID: oracle KMA IP Address: kma1
En este punto, ha definido una ranura pkcs11 y puede verificar la autenticación con OKM.
-
En los sistemas Solaris, verifique la autenticación mediante el comando cryptoadm(1M). Tenga en cuenta que el campo del indicador muestra CKF_LOGIN_REQUIRED en el siguiente ejemplo, lo que señala que la ranura aún no se configuró con un token autenticado.
solaris> cryptoadm list -v \ provider='/usr/lib/security/$ISA/pkcs11_kms.so.1' Provider: /usr/lib/security/$ISA/pkcs11_kms.so.1 Number of slots: 1 Slot #1 Description: Oracle Key Management System Manufacturer: Oracle Corporation PKCS#11 Version: 2.20 Hardware Version: 0.0 Firmware Version: 0.0 Token Present: True Slot Flags: CKF_TOKEN_PRESENT Token Label: KMS Manufacturer ID: Oracle Corporation Model: Serial Number: Hardware Version: 0.0 Firmware Version: 0.0 UTC Time: PIN Min Length: 1 PIN Max Length: 256 Flags: CKF_LOGIN_REQUIRED
-
Verifique que el token pkcs11_kms se pueda autenticar con el cluster de OKM.
En este ejemplo, se utiliza pktool(1) de Oracle Solaris, una utilidad que no está disponible para las plataformas Linux.
solaris> pktool inittoken currlabel=KMS Enter SO PIN: Token KMS initialized.
El indicador de SO (abreviatura de PKCS#11 para "Security Officer" o responsable de la seguridad) solicita la frase de contraseña secreta del agente, según la estableció en un paso anterior el administrador de OKM que creó el agente.
-
En los sistemas Solaris, verifique que el token se inicialice mediante la utilidad pktool(1) o el comando cryptoadm(1M) de la estructura criptográfica de Solaris. Observe que el indicador del token que se muestra en la salida del comando cryptoadm es ahora CKF_TOKEN_INITIALIZED:
solaris> cryptoadm list -v \ provider='/usr/lib/security/$ISA/pkcs11_kms.so.1' Provider: /usr/lib/security/$ISA/pkcs11_kms.so.1 Number of slots: 1 Slot #1 Description: Oracle Key Management System Manufacturer: Oracle Corporation PKCS#11 Version: 2.20 Hardware Version: 0.0 Firmware Version: 0.0 Token Present: True Slot Flags: CKF_TOKEN_PRESENT Token Label: KMS Manufacturer ID: Oracle Corporation Model: Serial Number: Hardware Version: 0.0 Firmware Version: 0.0 UTC Time: PIN Min Length: 1 PIN Max Length: 256 Flags: CKF_LOGIN_REQUIRED CKF_TOKEN_INITIALIZED
-
En los sistemas Solaris, verifique el estado de los tokens PKCS#11 visibles con la utilidad pktool(1):
glengoyne> pktool tokens Flags: L=Login required I=Initialized X=User PIN expired S=SO PIN expired Slot ID Slot Name Token Name Flags ------- --------- ---------- ----- 1 Sun Crypto Softtoken Sun Software PKCS#11 softtoken 2 Oracle Key Management System KMS L glengoyne>
Esto muestra que aún se requiere el inicio de sesión en el token. El significado de los indicadores de la salida de pktool se puede mostrar de la siguiente manera:
glengoyne> pktool tokens -h Usage: pktool -? (help and usage) pktool -f option_file pktool subcommand [options...]
donde los subcomandos pueden ser:
tokens * flags shown as: L=Login required I=Initialized E=User PIN expired S=SO PIN expired glengoyne> -
En los sistemas Solaris, use la utilidad pktool(1) para iniciar sesión en el token y realizar la autenticación con el dispositivo de gestión de claves del cluster de OKM especificado en el paso kmscfg(1) y la frase de contraseña creada por un administrador de OKM para el agente. Esta frase de contraseña se proporciona con el indicador de PIN del SO:
glengoyne> pktool inittoken currlabel=KMS Enter SO PIN: Token KMS initialized.
-
En los sistemas Solaris, verifique el estado de los tokens y compruebe que ahora estén inicializados con la utilidad pktool(1):
glengoyne> pktool tokens Flags: L=Login required I=Initialized X=User PIN expired S=SO PIN expired Slot ID Slot Name Token Name Flags ------- --------- ---------- ----- 1 Sun Crypto Softtoken Sun Software PKCS#11 softtoken 2 Oracle Key Management System KMS LI
-
En los sistemas Solaris, utilice el comando cryptoadm(1M) para verificar que el token pkcs11_kms esté inicializado. Para ello, solicite ver los mecanismos que admite:
glengoyne> cryptoadm list -m -p provider=/usr/lib/security/'$ISA'/pkcs11_kms.so.1 Mechanisms: CKM_AES_KEY_GEN CKM_AES_CBC CKM_AES_CBC_PAD glengoyne>
En los sistemas Solaris, use la utilidad pktool(1) para crear y enumerar las claves a través del proveedor pkcs11_kms de la siguiente manera:
# pktool genkey token=KMS keytype=aes keylen=256 label=MyKey-test1 # pktool list token=KMS objtype=key # pktool list token=KMS objtype=key label=MyKey-test1
Puede ver las claves del sistema OKM por medio de la GUI de OKM Manager o la CLI de OKM.
Nota:
Para Solaris, kmscfg(1) crea de forma predeterminada una sola configuración de ranura por usuario a la vez.Puede definir otras configuraciones de ranura, pero sólo una estará activa por cada proceso. Para ello, utilice la variable de entorno KMSTOKEN_DIR para definir una ubicación de sistema de archivos y una configuración de ranura alternativas.
El valor predeterminado para Solaris 11 es /var/user/$USERNAME/kms, pero puede crear sus propios esquemas de denominación. Una mejor práctica podría ser:
/var/user/$USERNAME/$AGENTID-$CLUSTER/Esta convención de denominación permite que Solaris tenga varias combinaciones de ranura-agente-cluster según los diferentes escenarios de uso.
Para algunas configuraciones de PKCS#11, se recomienda usar una ubicación alternativa, por ejemplo, TDE con Oracle RAC (consulte la sección de configuración de TDE arriba), para que cada nodo comparta los metadatos del proveedor pkcs11_kms).
-
-
Si desea configurar TDE para que utilice carteras de apertura automática, siga las instrucciones descritas en el documento Oracle Advanced Security Transparent Data Encryption Best Practices, al que se hace referencia al principio de este apéndice.
Operaciones continuas
En las siguientes secciones, se describen las tareas operativas recurrentes de OKM y TDE.
Migración de claves maestras desde Oracle Wallet
La cartera antigua se debe conservar, y OKM generará una nueva clave maestra que el sistema de gestión de claves protegerá.
Consulte el documento Oracle Advanced Security Transparent Data Encryption Best Practices, al que se hace referencia al principio de este apéndice.
TDE genera una etiqueta de clave única que identifica a cada clave maestra. Los valores reales de las claves nunca se muestran en texto sin formato hasta que se transfieren del token pkcs11_kms a TDE. La clave "creada" se extraerá de una agrupación de claves AES de 256 bits con estado de activación (replicadas de forma segura en varios dispositivos de gestión de claves). Esta clave luego se asociará con una política de claves de OKM de acuerdo con el agente específico utilizado por el token PKCS#11. A continuación, OKM gestionará la clave de acuerdo con el ciclo de vida de claves estipulado por la política.
Operación de regeneración de claves
El administrador de bases de datos Oracle debe efectuar las operaciones de regeneración de claves antes de lo estipulado por el ciclo de vida de las claves. De lo contrario, la base de datos no se iniciará.
Consulte los diferentes documentos de Oracle Database y TDE para conocer el DDL utilizado para realizar esta operación. La regeneración de claves también se puede realizar con Oracle Enterprise Manager.
Regeneración de claves debido a la caducidad basada en políticas de OKM
Una vez que una clave alcanza el estado posoperativo, cada recuperación de TDE generará una advertencia en los logs de auditoría de OKM, que indicará que se recuperó una clave posoperativa. La presencia de estos mensajes de auditoría indica que es hora de volver a generar la clave de cifrado maestra de la instancia de base de datos. El mensaje de auditoría de OKM identifica el agente y la clave que se recuperará para facilitar la identificación de la instancia de Oracle Database y la clave de cifrado maestra que alcanzó el estado posoperativo. Es posible configurar la notificación a través de informes de SNMP v3 o capturas de SNMP v2 en OKM para admitir la automatización de este proceso.
El proveedor pkcs11_kms intentará informar a sus consumidores PKCS#11 que la clave alcanzó el estado posoperativo. Para ello, se debe establecer el atributo "CKA_ENCRYPT" de PKCS#11 en "false" para la clave maestra.
Oracle Database 11g R2 continúa utilizando una clave para cifrar los datos una vez caducado el período de cifrado. Puede observar este comportamiento cuando en el log de alerta aparece el siguiente error:
HSM heartbeat died. Likely the connection has been lost. PKCS11 function C_EncryptInit returned PKCS11 error code: 104 HSM connection lost, closing wallet
Si se detecta este error, el administrador de bases de datos debe realizar las siguientes acciones:
-
Establecer la siguiente variable de entorno para el usuario asociado al token pkcs11_kms (generalmente, el perfil del usuario de Oracle):
# export PKCS11_KMS_ALLOW_ENCRYPT_WITH_DEACTIVATED_KEYS=1
-
Reiniciar la base de datos.
-
Volver a generar la clave maestra para la instancia de base de datos.
Para evitar el error descrito anteriormente, se recomienda usar un período de cifrado muy extenso en la política de claves de OKM asociada a los agentes de Oracle Database. También puede modificar el comportamiento del proveedor pkcs11_kms para desactivar la comprobación del estado de las claves. Para ello, establezca la variable de entorno descrita arriba en el Paso 1. Una vez definida esta variable, es posible abrir el HSM.
A pesar de esto, TDE continuará utilizando la clave y no realizará una operación automática de regeneración de claves. Los administradores de OKM que observan las advertencias de auditoría de la recuperación de claves posoperativas deben informar a un administrador de bases de datos que es hora de volver a generar la maestra clave de su instancia de base de datos.
Conversión desde otra solución HSM
Póngase en contacto con la asistencia técnica de Oracle para conocer los pasos específicos necesarios para realizar una conversión desde la solución HSM de otro proveedor a OKM.
Destrucción de claves
Antes de destruir las claves que alcanzaron la fase posoperativa, el administrador de OKM debe verificar que la clave ya no está en uso.
Los administradores de OKM son responsables de la destrucción periódica de claves en la fase posoperativa. La supresión de claves a través del proveedor pkcs11_kms no se admite en OKM y se trata de una operación restringida reservada para los usuarios de OKM a los que se asignó el rol de operador. Una vez que se destruye una clave, cualquier intento de recuperarla generará un error, incluidas las solicitudes C_FindObjects de PKCS#11.
Transferencia de claves para admitir Oracle RMAN u Oracle Data Pump
El uso de Oracle RMAN u Oracle Data Pump puede requerir que se proporcione la clave maestra en otro cluster de OKM, quizá en un sitio de recuperación ante desastres o con un socio. Las operaciones de transferencia de claves de OKM admiten este proceso por medio de los servicios de exportación e importación de claves seguras. Consulte "Transferencia de claves" para obtener más información.
Realice los siguientes pasos:
-
Establezca socios de transferencia de claves entre los clusters de OKM de origen y de destino.
-
Identifique las claves maestras de TDE que se exportarán para admitir las copias de seguridad de Oracle RMAN o los datos cifrados exportados mediante Oracle Data Pump.
-
Exporte las claves desde el cluster de OKM de origen. Se creará un archivo de exportación de claves seguras.
-
Transfiera el archivo de claves exportado al socio de transferencia.
-
El socio de transferencia de destino importará las claves en su cluster de OKM.
Ejecute una restauración de Oracle RMAN o una importación de Oracle Data Pump para volver a crear la instancia de base de datos que requiere las claves. Se deben llevar a cabo los pasos de configuración necesarios para usar TDE con OKM en la ubicación de importación. Luego, la operación de restauración o importación accede a OKM para obtener las claves maestras universales necesarias para descifrar las claves de columnas o tablespaces que utiliza la instancia de base de datos.
Gestión
Una vez que el sistema está activo, utilice las siguientes directrices para gestionar y supervisar la solución de manera eficaz.
Atestación, auditoría y supervisión
Oracle recomienda lo siguiente:
-
Consulte y supervise el historial activo de OKM del agente de TDE para ayudar a detectar problemas.
-
Los auditores pueden usar los eventos de auditoría de OKM para corroborar que TDE accede a sus claves maestras desde el cluster de OKM.
-
Configure un gestor de SNMP para OKM.
-
Explore el uso de la CLI de OKM para generar informes específicos de la empresa.
Ubicación de las claves maestras de TDE en OKM
Puede ubicar las claves maestras de TDE dentro de OKM mediante la herramienta de gestión de GUI o la CLI. TDE genera las etiquetas de las claves maestras y OKM utiliza el atributo "External Tag" de una unidad de datos para almacenar este valor. La generación de claves maestras de TDE (incluidas las operaciones de regeneración de claves) siempre crea un nuevo objeto de unidad de datos y un objeto de clave en el cluster de OKM.
Para ubicar una clave maestra de TDE, haga lo siguiente:
-
Realice una consulta en las unidades de datos de OKM y aplique a la lista el siguiente filtro ExternalTag: "ExternalTag" comienza con "ORACLE.TDE". Como todas las etiquetas de claves de TDE comienzan con esta cadena, se generará una lista con las unidades de datos de OKM creadas por TDE. Cada unidad de datos de OKM tendrá asociada una única clave maestra de TDE. Estas claves se pueden visualizar con la GUI de OKM a fin de examinar el estado del ciclo de vida y otras propiedades, como el grupo de claves, el estado de exportación o importación, y las copias de seguridad de OKM que contienen claves que fueron destruidas. Estas claves también se pueden visualizar con la CLI de OKM. Por ejemplo:
>okm listdu --kma=acme1 --user=joe \ --filter="ExternalTag=ORACLE.TDE"
-
Cuando varias instancias de Oracle Database comparten un cluster de OKM, el administrador de OKM puede identificar qué claves corresponden a una base de datos determinada. Para ello, se realiza una consulta en los eventos de auditoría del agente correspondiente a esa instancia de base de datos. Estos eventos de auditoría se pueden visualizar con la GUI de Oracle. Aplique al historial de auditoría del agente el filtro "Operation equals CreateDataUnit". Se obtiene una lista con los eventos de auditoría correspondientes a la creación de claves maestras de TDE. Los detalles de los eventos de auditoría brindan la información necesaria para identificar las unidades de datos específicas para las claves maestras. Estos eventos de auditoría también se pueden visualizar con la CLI de OKM. Por ejemplo:
>okm listauditevents --kma=acme1 --user=joe \ --filter="Operation=CreateDataUnit"
Resolución de problemas
En esta sección, se describen las condiciones de error que se pueden presentar al utilizar OKM con TDE.
No se puede recuperar la clave maestra
Oracle Database notifica uno de los siguientes errores cuando no se puede recuperar la clave maestra:
-
ORA-28362
-
ORA-06512
Si se detectan estos errores, siga los pasos de diagnóstico mencionados a continuación para identificar el problema:
-
Examine el archivo $ORACLE_BASE/diag/rdbms/$SID/$SID/trace/alert_$SID.log. Este archivo registra los mensajes de éxito o fallo relacionados con sentencias DDL de "modificación" utilizadas para acceder a la cartera de cifrado.
-
Examine el archivo KMSAgentLog.log en el directorio de configuración de pkcs11_kms ($KMSTOKEN_DIR/KMSAgentLog.log).
-
Verifique el estado general de OKM. Compruebe lo siguiente:
-
¿Están activos los dispositivos de gestión de claves?
-
¿Están bloqueados los dispositivos de gestión de claves?
-
¿Está agotada la agrupación de claves?
-
Fallos de ILOM/ELOM en el dispositivo de gestión de claves
-
Mensajes de la consola en el dispositivo de gestión de claves
-
-
Verifique el estado del token pkcs11_kms como se demostró anteriormente.
-
Verifique el estado del agente. Para ello, examine los eventos de auditoría de OKM de dicho agente para garantizar que esté inscrito y activado.
-
Verifique la conectividad de red del host de Oracle Database a los nodos de OKM.
-
Póngase en contacto con la asistencia técnica de Oracle. Es posible que deba proporcionar uno o más volcados del sistema del dispositivo de gestión de claves.
Pérdida del directorio de configuración de pkcs11_kms
Utilice el siguiente procedimiento para recuperar un perfil de tokens pkcs11_kms perdido o dañado:
-
Siga los pasos de configuración descritos en "Configuración de OKM para TDE".
-
Solaris únicamente: vuelva a completar los metadatos del token, utilizando el siguiente filtro de unidades de datos con OKM: "ExternalTag" comienza con "ORACLE.TDE".
-
Solaris únicamente: guarde los resultados de esta lista en un archivo (por ejemplo, "du.lst") y luego ejecute la siguiente secuencia de comandos de shell:
for label in `awk '{print $2}' < du.lst ` do pktool list token=KMS objtype=key label="${label}" done
No hay ranuras disponibles
El cliente recibe errores del tipo "No Slots Available" al ejecutar cualquier operación de PKCS#11.
-
Asegúrese de que la utilidad kmscfg se haya ejecutado correctamente.
-
Asegúrese de que el proveedor pkcs11_kms se haya instalado y configurado correctamente.
Error CKA_GENERAL_ERROR
El cliente recibe el error CKA_GENERAL_ERROR cuando intenta recuperar claves.
-
Verifique que el agente tenga un grupo de claves predeterminado en el cluster de OKM.
-
Consulte el archivo $KMSTOKEN_DIR/KMSAgentLog.log para obtener más información.
No se pudo abrir el archivo PKCS#12
Aparece el error "Could not open PKCS#12 file" en el archivo log $KMSTOKEN_DIR/KMSAgentLog.log.
-
Seleccione eventos de auditoría en el cluster de OKM para determinar si la frase de contraseña del agente se modificó recientemente.
-
Elimine el directorio <profile-name> en $KMSTOKEN_DIR.