En esta sección, se describen los mecanismos de seguridad específicos que ofrece el producto.
Los clientes que tienen agentes con cifrado activado se preocupan fundamentalmente por lo siguiente:
Divulgación de información por incumplimiento de políticas
Pérdida o destrucción de datos
Demora inaceptable en la restauración de los datos en caso de fallo catastrófico (por ejemplo, en un sitio donde la continuidad comercial se vea afectada)
Modificación de datos no detectada
Los objetivos de las funciones de seguridad de Oracle Key Manager son los siguientes:
Proteger datos cifrados contra la divulgación.
Minimizar la exposición a ataques.
Proporcionar suficiente fiabilidad y disponibilidad.
En esta sección de la guía de seguridad, se intenta ofrecer una visión general de las amenazas contra las que el sistema está diseñado para proteger y del modo en que se combinan las funciones de seguridad individuales para evitar ataques.
Las funciones de seguridad críticas que brindan estas protecciones son:
Autenticación: garantiza que solo las personas autorizadas puedan acceder al sistema y a los datos.
Autorización: privilegios y datos de control de acceso al sistema; este control de acceso complementa la autenticación para garantizar que solo las personas adecuadas tengan acceso.
Auditoría: permite a los administradores detectar los intentos de violación del mecanismo de autenticación y los intentos de violación o las violaciones del control de acceso.
Para obtener más información sobre cuestiones de autenticación y seguridad relativas a Oracle Key Manager, consulte Documentación técnica de autenticación y seguridad de Oracle Key Manager versión 2.x en:
La arquitectura de Oracle Key Manager proporciona autenticación mutua entre todos los elementos del sistema: de dispositivo de gestión de claves a dispositivo de gestión de claves, de agente a dispositivo de gestión de claves y de la CLI o la GUI de Oracle Key Manager al dispositivo de gestión de claves para las operaciones de usuario.
Cada elemento del sistema (por ejemplo, un nuevo agente de cifrado) se incorpora al sistema mediante la creación de un ID y una frase de contraseña en el OKM que, luego, se introduce en el elemento que se va a agregar. Por ejemplo, cuando se agrega una unidad de cinta al sistema, el agente y el dispositivo de gestión de claves ejecutan automáticamente un protocolo de desafío/respuesta que se basa en la frase de contraseña compartida y permite que el agente obtenga el certificado de autoridad de certificación root y un nuevo par de claves junto con un certificado firmado para el agente. Con el certificado de autoridad de certificación root, el certificado de agente y el par de claves en su lugar, el agente puede ejecutar el protocolo de seguridad de capa de transporte (TLS) para todas las comunicaciones subsiguientes con los dispositivos de gestión de claves. Todos los certificados son certificados X.509.
OKM actúa como autoridad de certificación root para generar un certificado root que los dispositivos de gestión de claves usan cuando es necesario para derivar (autofirmar) los certificados empleados por los agentes, los usuarios y los nuevos dispositivos de gestión de claves.
El control de acceso puede ser de los siguientes tipos:
Control de acceso basado en roles y usuarios
Protección por quórum
Oracle Key Manager proporciona la capacidad de definir varios usuarios, cada uno con un ID de usuario y una frase de contraseña. A cada usuario se le otorga uno o más roles predefinidos. Estos roles determinan qué operaciones puede realizar un usuario en un sistema de Oracle Key Manager. Estos roles son los siguientes:
Responsable de la seguridad: gestión y configuración de Oracle Key Manager
Operador: configuración de agentes y operaciones diarias
Responsable de conformidad: definición de grupos de claves y control de acceso de agentes a grupos de claves
Operado de copias de seguridad: ejecución de operaciones relativas a las copias de seguridad
Auditor: supervisión de pistas de auditoría del sistema
Miembro del quórum: supervisión y aprobación de operaciones de quórum pendientes
El responsable de la seguridad se define durante el proceso de QuickStart, donde se configura un dispositivo de gestión de claves en un cluster de OKM. Luego, un usuario debe iniciar sesión en el cluster como responsable de la seguridad mediante la GUI de Oracle Key Manager a fin de crear usuarios adicionales. El responsable de la seguridad puede optar por asignar varios roles a un usuario en particular, o bien puede asignar un rol en particular a varios usuarios.
Para obtener más información acerca de las operaciones permitidas por cada rol y el modo en que un responsable de seguridad crea usuarios y les asigna roles, consulte la Guía de administración de Oracle Key Manager que se incluye en las bibliotecas de documentación de Oracle Key Manager en el siguiente enlace:
http://www.oracle.com/technetwork/documentation/tape-storage-curr-187744.html#crypto
Este control de acceso basado en roles admite los roles operativos de la publicación especial 800-60 del National Institute of Standards and Technology (NIST) para separar funciones operativas.
Algunas operaciones son tan críticas que requieren un nivel de seguridad adicional. Entre estas operaciones, se incluye la agregación de un dispositivo de gestión de claves a un cluster de OKM, el desbloqueo de un dispositivo de gestión de claves, la creación de usuarios y la agregación de roles a usuarios. Para implementar esta seguridad, el sistema usa un conjunto de credenciales de división de claves, además del acceso basado en roles descrito anteriormente.
Las credenciales de división de claves son un conjunto de pares de ID de usuario y frases de contraseña más la cantidad mínima necesaria de estos pares para que el sistema active la compleción de ciertas operaciones. A las credenciales de división de claves también se las llama "quórum" y a la cantidad mínima, "umbral de quórum".
Oracle Key Manager permite hasta diez pares de ID de usuario y frase de contraseña de división de claves, y un umbral que debe definirse. Estos se definen durante el proceso de QuickStart, cuando se configura el primer dispositivo de gestión de claves en un cluster de OKM. Los ID de usuario y las frases de contraseña de división de claves difieren de los ID de usuario y las frases de contraseña que se usan para iniciar sesión en el sistema. Cuando un usuario intenta realizar una operación que requiere la aprobación del quórum, el umbral definido de ID de usuario y frases de contraseña de división de claves debe aprobar dicha operación antes de que el sistema la ejecute.
Cada dispositivo de gestión de claves registra los eventos de auditoría para las operaciones que realiza, incluidas las emitidas por agentes, usuarios y dispositivos de gestión de claves pares en el cluster de OKM. Los dispositivos de gestión de claves también registran eventos de auditoría cuando un agente, un usuario o un dispositivo de gestión de claves par no logra autoautenticarse. Se registran los eventos de auditoría que indican una infracción de seguridad. El fallo de autenticación es un ejemplo de un evento de auditoría que indica una infracción de seguridad. Si los agentes SNMP se identifican en el cluster de OKM, los dispositivos de gestión de claves también envían el comando SNMP INFORM a los agentes SNMP si detectan una infracción de seguridad. Si syslog remoto está configurado, el dispositivo de gestión de claves también envía estos mensajes de auditoría a servidores configurados. Consulte Syslog remoto.
El usuario debe iniciar sesión correctamente en el cluster de OKM y debe tener un rol asignado antes de que se le permita ver los eventos de auditoría.
Los dispositivos de gestión de claves gestionan sus eventos de auditoría. Los dispositivos de gestión de claves eliminan eventos de auditoría antiguos en función de los límites y los términos de retención (recuentos). El responsable de la seguridad puede modificar estos límites y términos de retención según sea necesario.
Oracle Key Manager proporciona otras funciones de seguridad. Para obtener más información sobre estas y otras funciones de OKM, consulte Visión general de Oracle Key Manager en el siguiente enlace:
El protocolo de comunicación entre un agente y un dispositivo de gestión de claves, un usuario y un dispositivo de gestión de claves y un dispositivo de gestión de claves y un dispositivo de gestión de claves par es el mismo. En cada caso, el sistema usa una frase de contraseña para la entidad que inicia la comunicación para ejecutar un protocolo de desafío/respuesta. Si el proceso se realiza correctamente, la entidad obtiene un certificado y la clave privada correspondiente. Este certificado y la clave privada pueden establecer un canal de seguridad de capa de transporte (TLS) (sockets seguros). Se efectúa la autenticación mutua, y cada punto final de cualquier conexión autentica a la otra parte. En OKM 3.1 con dispositivos de gestión de claves, siempre se usa TLS 1.2 para el tráfico de replicación entre pares.
Los dispositivos de gestión de claves tienen un módulo de seguridad de hardware disponible, el cual se pide por separado. Este módulo de seguridad de hardware, que es una tarjeta Sun Cryptographic Accelerator (SCA) 6000, obtuvo la certificación FIPS 140-2 nivel 3 y proporciona claves de cifrado del estándar de cifrado avanzado (AES) de 256 bits (este certificado caducó el 31 de diciembre de 2015 y no se renovará, se proporcionará un módulo de seguridad de hardware alternativo en una versión posterior). La tarjeta SCA 6000 admite un modo operativo de FIPS 140-2, nivel 3, y OKM usa siempre la tarjeta en este modo. Cuando el cluster de OKM opera en un modo que cumple con FIPS, las claves de cifrado no dejan el límite criptográfico de la tarjeta SCA 6000 en modo no encapsulado. La tarjeta SCA 6000 usa un generador de números aleatorios aprobado por FIPS, según lo especificado en el estándar DSA de generador de números aleatorios FIPS 186-2 mediante el uso de SHA-1 para generar claves de cifrado.
Cuando un dispositivo de gestión de claves no se configura con una tarjeta SCA 6000, la criptografía se realiza con un token variable de PKCS#11 de la estructura criptográfica de Solaris (SCF). La SCF se configura en el modo FIPS 140, según se describe en las políticas de seguridad FIPS 140-2 de Solaris más recientes.
Oracle Key Manager usa el encapsulado de claves de AES (RFC 3994) con claves de cifrado de clave de 256 bits para proteger las claves simétricas cuando se crean, se almacenan en el dispositivo de gestión de claves, se transmiten a agentes o entre archivos de transferencia de claves.
Cuando el primer dispositivo de gestión de claves de un cluster de OKM se inicia, el dispositivo de gestión de claves genera una gran agrupación de claves. Cuando se agregan dispositivos de gestión de claves adicionales al cluster, las claves se replican en los nuevos dispositivos de gestión de claves y así quedan listos para usar para cifrar datos. Cada dispositivo de gestión de claves que se agrega al cluster genera una agrupación de claves y las replica en dispositivos de gestión de claves pares en el cluster. Todos los dispositivos de gestión de claves generan nuevas claves en la medida de lo necesario para mantener el tamaño de la agrupación de claves, de modo que las claves listas estén siempre disponibles para los agentes. Cuando un agente requiere una nueva clave, el agente contacta con un dispositivo de gestión de claves en el cluster y solicita una nueva clave. El dispositivo de gestión de claves toma una clave lista de la agrupación de claves y la asigna al grupo de claves por defecto del agente y a la unidad de datos. Luego, el dispositivo de gestión de claves replica las actualizaciones de bases de datos en toda la red para los demás dispositivos de gestión de claves del cluster. Más adelante, el agente puede contactar con otro dispositivo de gestión de claves en el cluster para recuperar la clave. En ningún momento se transmite ningún material de clave de texto no cifrado en la red.
En diciembre de 2013, el Instituto Nacional de Normas y Tecnología (NIST, National Institute of Standards and Technology) otorgó el certificado de validación FIPS 140-2 nivel 1 N.º 2061 al módulo de estructura criptográfica de núcleo de Oracle Solaris en Solaris 11. En enero de 2014, el NIST otorgó el certificado de validación FIPS 140-2 nivel 1 N.º 2076 a la estructura criptográfica de espacio de usuario de Oracle Solaris con SPARC T4 y SPARC T5. El dispositivo de gestión de claves Oracle Key Manager 3.1.0 ahora se basa en Solaris 11.3, que todavía se está sometiendo a las pruebas de validación de FIPS 140-2. La estructura criptográfica de núcleo de Oracle Solaris de un dispositivo de gestión de claves Oracle Key Manager 3.1.0 se configura según lo detallado en Política de seguridad de estructura criptográfica de núcleo de Oracle. Asimismo, el dispositivo de gestión de claves también se configura según lo detallado en Política de seguridad de estructura criptográfica de espacio de usuario de Oracle Solaris con SPARC T4 y T5. OKM se actualizará con políticas de seguridad más recientes de Solaris a medida que dichas políticas estén disponibles.