Compartir a través de


Protección

En este tema se describen los estándares compatibles con la protección de DB2.

Estándares de cifrado para DB2

En la tabla siguiente se describen los estándares de cifrado admitidos para DB2.

Cifrado Authentication data
Kerberos No
Capa de sockets seguros (SSL) v3
Seguridad de la capa de transporte (TLS) v1
Estándar de cifrado avanzado (AES) No

Configuración de la protección

El proveedor de datos concede al grupo público DB2 permisos de ejecución en el paquete de DB2

Al crear paquetes de DB2, la Herramienta de acceso a datos y el proveedor de datos establecen en PUBLIC los permisos de ejecución de los paquetes de DB2, que incluye a todos los usuarios de DB2. Para aumentar la seguridad del servidor DB2, es recomendable revocar los permisos de ejecución en PUBLIC de dichos paquetes y conceder permisos de ejecución solamente a usuarios o grupos de DB2 seleccionados.

El asistente para orígenes de datos y los vínculos de datos almacenan las credenciales de autenticación (nombre de usuario y contraseña) como texto sin formato en el archivo de vínculo de datos universal (UDL) o en el de cadenas de conexión (TXT). Se recomienda configurar los proveedores de datos para que usen Enterprise Single Sign-On (ESSO), que almacena de forma segura asignaciones de cuentas de Windows Active Directory a credenciales de IBM DB2. Los proveedores de datos recuperan estas asignaciones en tiempo de ejecución para autenticar de forma segura a los usuarios de Windows en servidores remotos de bases de datos IBM DB2. Debe ejecutar el proveedor de datos en proceso con las herramientas de datos y el consumidor de datos.

El proveedor de datos se conecta mediante el uso de nombre de usuario y contraseña en texto sin formato y sin cifrar

El proveedor de datos se conecta a los equipos servidor de DB2 por medio de una red TCP/IP o SNA mediante la autenticación básica, en la que el nombre de usuario y la contraseña no están cifrados y se envían en texto sin formato. Es recomendable configurar el proveedor de datos para usar el cifrado de autenticación mediante Kerberos, Capa de sockets seguros (SSL) V3.0 o Seguridad de la capa de transporte (TLS) V1.0, o bien el cifrado de autenticación mediante AES.

El proveedor de datos envía y recibe datos sin cifrar

El proveedor de datos envía y recibe datos sin cifrar. Es recomendable configurar el proveedor de datos para usar el cifrado de datos mediante Capa de sockets seguros (SSL) V 3.0 o Seguridad de la capa de transporte (TLS) V 1.0.

Las herramientas de datos y los consumidores de datos leen y escriben archivos de conexión hacia y desde carpetas no seguras

Las herramientas de datos y los consumidores de datos pueden leer y escribir archivos de conexión hacia y desde carpetas no seguras. Debe almacenar los archivos de vínculo de datos universal (UDL) en Host Integration Server\Data Sources o en un directorio de programa y, a continuación, proteger la carpeta con derechos de administrador local. Debe conservar la información de conexión en los almacenes seguros de los consumidores de datos y de las herramientas de datos y, a continuación, ejecutar el proveedor de datos en proceso con las herramientas de datos y el consumidor de datos.

Los consumidores de datos y las herramientas de datos pueden solicitar conexiones con propiedades no válidas

Los consumidores de datos y las herramientas de datos pueden solicitar conexiones con valores de propiedad de conexión no válidos. Debe usar los consumidores de datos que crean conexiones con los objetos de conexión del proveedor de datos, en lugar de pasar pares nombre-valor de argumentos de cadenas de conexión sin comprobar. Debe establecer un valor de tiempo de espera de la conexión para cancelar los intentos de conexión no válidos.

Los consumidores de datos y las herramientas de datos pueden solicitar comandos con datos no válidos

Los consumidores de datos y las herramientas de datos pueden solicitar comandos con datos no válidos. Debe usar los consumidores de datos que crean comandos con el comando del proveedor de datos con objetos de parámetro para validar tipos de parámetro, en lugar de pasar cadenas de comandos sin comprobar con valores de datos en línea. Debe establecer un valor de tiempo de espera del comando para cancelar los intentos de comando no válidos. Debe usar la unidad de trabajo distribuida (DUW) de DRDA, en lugar de la unidad de trabajo remota (RUW), para proteger los consumidores de datos con transacciones de confirmación en dos fases.