db2_audit

Auditoria en DB2

Ramón Pinuaga Cascales

[email protected]

Índice

1. Introducción

2. Cuentas de usuario

3. Roles y privilegios

4. DB2 SQL

5. Vías de acceso

6. Inyección de SQL

7. Registro

8. Sistema operativo

1. Introducción

El tema central de esta ponencia es la auditoria de seguridad en bases de datos DB2, desde un enfoque practico.

¿A que nos referimos con “enfoque practico”? Pues al enfoque que analiza la seguridad desde el punto de vista del atacante que pretende acceder a información sensible o utilizar la base de datos para atacar otros sistemas. (Basado en pentest)

Pero no olvidaremos al defensor. Daremos consejos a los administradores para defender sus sistemas frente a posibles ataques.

Historia

DB2 es la marca tras la que IBM comercializa una de sus familias de productos de gestión de la información.

Aunque tradicionalmente cuando se habla de DB2 se habla del producto estrella de esta serie, la base de datos relacional DB2 UDB (Universal DataBase).

En esta ponencia cuando hablamos de DB2 nos referiremos únicamente a la base de datos UDB.

DB2 como base de datos tiene una larga historia, y algunos la consideran la primera base de datos comercial en soportar SQL.

Diferencias entre plataformas

Las versiones actuales de DB2 corren sobre multitud de plataformas, que según sus características podemos agrupar en 3 grandes grupos:– DB2 para z/OS (antiguamente OS/390)– DB2 para iSeries (AS/400)– DB2 para sistemas Unix/Windows

Aunque el núcleo común es muy similar, el comportamiento de la base de datos en las distintas plataformas presenta algunas peculiaridades en el aspecto que mas nos interesa: la seguridad.

DB2 para z/OS

Para una lista completa de diferencias podemos consultar la tabla que aparece en la siguiente pagina:– http://www-03.ibm.com/servers/enable/site/db2/db2common.ht

ml

Las peculiaridades en cuanto a la seguridad de DB2 en esta plataforma respecto a las otras, se deben principalmente a las características del propio sistema operativo. (Sistema comparticionado, pocas herramientas de red, sistema de ficheros especial)

DB2 para AS/400

En los AS/400 la base de datos DB2 viene integrada fuertemente en el propio sistema operativo constituyendo uno de los pilares del mismo.

La base de datos cuenta con un catalogo propio que se compone de una serie de vistas y tablas que contienen información sobre todos los elementos de la base de datos y contiene incluso entradas para objetos de la base de datos creados usando métodos tradicionales de AS/400, no-SQL.

El catalogo se encuentra en los esquemas: QSYS y QSYS2

Catalogo DB2 para AS/400

Se incluye una capa de compatibilidad con los catálogos ISO a través del esquema “SYSCAT” que funciona como sinónimo de “INFORMATION_SCHEMA” y con los catálogos DB2 para otras plataformas a través del esquema “SYSIBM”.

Estas 3 sentencias serian equivalentes:– SELECT * FROM QSYS2.TABLES WHERE TABLE_SCHEMA

= 'WORK'

– SELECT * FROM SYCAT.TABLES WHERE TABSCHEMA = ‘WORK’

– SELECT * FROM SYSIBM.TABLES WHERE TABLE_SCHEMA = 'WORK‘

Llamada a programas AS/400

DB2 para AS/400 también cuenta con otra peculiaridad respecto a las demás plataformas.

Existe de serie un procedimiento almacenado llamado “qcmdexc” que permite activar cualquier programa iSeries desde SQL si recibe los parámetros adecuados.

Ejemplo:– CALL QSYS.QCMDEXC('CALL PGM (MYLIB/MYPGM)',

0000000022.00000)

DB2 para Unix/Windows

Es habitual referirse a esta variante como DB2 LUW: Linux-Unix-Windows.

En estas plataformas la base de datos DB2 se instala como un componente mas.

La mayoría de ejemplos de esta ponencia se basan en esta variante de DB2.

Índice

1. Introducción



4. DB2 SQL

5. Vías de acceso


7. Registro



Uno de los factores más característicos de DB2 en contraste con otras bases de datos es su forma de gestionar las cuentas de usuario.

DB2 no cuenta con un sistema de autenticación propio, tiene que basarse en uno externo.

Esto limita los ataques posibles. No es posible consultar y/o crear usuarios directamente desde la propia base de datos.

Autenticación de clientes

DB2 soporta multitud de mecanismos para autenticar a los clientes que intentan acceder a la base de datos:– SERVER (“default” para conexiones remotas)– SERVER_ENCRYPT– CLIENT– KERBEROS– KRB_SERVER_ENCRYPT– DCS – DCS_ENCRYPT – DCE – DCE_SERVER_ENCRYPT

En la mayoría de los casos, se utiliza el método “SERVER”, que se basa en utilizar la autenticación del sistema operativo del servidor.

Usuarios habituales

Como hemos comentado, los usuarios normalmente son gestionados por el sistema operativo del servidor.

Esto hace que durante el proceso de instalación de la base de datos, sea necesario crear una serie de usuarios en el sistema.

No podemos por lo tanto hablar de “usuarios por defecto”, aunque los nombres que se suele asignar a estos usuarios suelen repetirse:– db2admin (Windows)– db2inst1, dasusr1, db2as, db2fenc1 (Unix)

Las contraseñas suelen ser también bastante predecibles si el administrador no se ha preocupado en exceso:– Contraseña = usuario– db2– ibmdb2

Puntos a revisar

Eliminar los usuarios no utilizados a nivel del sistema operativo.

Comprobar que las contraseñas utilizadas son robustas (Y la política de contraseñas del sistema operativo).

Ajustar la seguridad del mecanismo de autenticación del sistema operativo a la criticidad de la información contenida en la base de datos.

Utilizar SERVER_ENCRYPT en lugar de SERVER en la medida de lo posible.

Índice

1. Introducción



4. DB2 SQL

5. Vías de acceso


7. Registro



Una vez el usuario ha sido autenticado, es ya el “security manager” de la propia base de datos el que asigna los privilegios con los que cuenta en el sistema.

La autorización se controla según distintos parámetros:– Autorización explicita, según los privilegios se le hayan asignado

específicamente a ese usuario.– Según los privilegios del grupo al que pertenezca.– Autorización implícita, que se le asigna automáticamente al creador

de un objeto.– Privilegios indirectos asociados a un package.

Todos los usuarios pertenecen al grupo “PUBLIC”.

Cuando la autenticación la gestiona el sistema operativo, cualquier usuario del equipo cuenta con acceso a la base de datos (como public).

Niveles de autoridad

DB2 emplea varios niveles de autoridad para las tareas administrativas:Asignados a nivel de instancia:

– SYSADM / System Administrator: Nivel de mayor autoridad. Sin limitaciones.

– SYSCTRL / System Control: Primer nivel de control.– SYSMAINT / System Maintenance– SYSMON / System MonitorAsignados a nivel de la base de datos:

– DBADM / Database Administrator: Es el segundo nivel de mayor autoridad.

– LOAD / Load– IMPLICIT_SCHEMA: Permite crear un esquema nuevo y

objetos dentro de el.– CREATE_EXTERNAL_RUOTINE: Permite crear

procedimientos almacenados, métodos y funciones definidas por el usuario. (Nuevo en UDB v8.1)

Niveles de autoridad

Elementos con privilegios

Elementos a los que se les puede asignar privilegios de acceso:– Database– Object– Schema– Tablespace– Table– Index– View– Package– Routine– Sequence– Server– Nickname

Privilegios de acceso

Privilegios de acceso a Tablas:– CONTROL– ALTER– SELECT– INSERT– UPDATE– DELETE– INDEX– REFERENCES

Ejemplo:– GRANT SELECT ON EMPLOYEE TO USER DEMO – GRANT SELECT ON EMPLOYEE TO GROUP DEMO – REVOKE SELECT ON EMPLOYEE FROM USER DEMO

Privilegios de acceso

Niveles de acceso

Para asignar los privilegios de acceso a la mayoría de elementos de una base de datos, el usuario debe tener autoridad SYSADM, DBADM; o contar con los privilegios de CONTROL sobre el elemento.

Los privilegios solo pueden ser asignados a elementos existentes.

Para asignar el privilegio de CONTROL, el usuario debe tener autoridad SYSADM o DBADM.

Por defecto, el creador de un elemento recibe el privilegio de CONTROL sobre el mismo.

Consultar la configuración de acceso

La configuración de los privilegios de acceso puede ser consultada a través de una serie de vistas del sistema disponibles en el catalogo “SYSCAT”.

Los privilegios asignados por el sistema tienen a “SYSIBM” como otorgante. Las autoridades SYSADM, SYSMAINT, SYSCTRL y SYSMON no aparecen en estas vistas.

Ejemplos:– SELECT * FROM SYSCAT.DBAUTH WHERE GRANTEE =

'PUBLIC'

– SELECT * FROM SYSCAT.TABAUTH WHERE GRANTEE = 'PUBLIC'

Tablas de privilegios

Las siguientes vistas contienen toda la información sobre privilegios de acceso:– SYSCAT.DBAUTH: Privilegios de base de datos – SYSCAT.TABAUTH: Privilegios de tablas y vistas– SYSCAT.COLAUTH: Privilegios de columnas– SYSCAT.PACKAGEAUTH: Privilegios de paquetes.– SYSCAT.INDEXAUTH: Privilegios de índices– SYSCAT.SCHEMAAUTH: Privilegios de esquemas– SYSCAT.PASSTHRUAUTH: Privilegios de servidores– SYSCAT.ROUTINEAUTH: Privilegios de funciones, métodos y

procedimientos almacenados

Privilegios de instancia

Como hemos visto los privilegios de instancia se definen externamente y no pueden ser consultados desde la propia base de datos.

Para obtener acceso a ellos tenemos que utilizar un comandos especifico:– db2 get dbm cfg

SYSADM group name (SYSADM_GROUP) =

SYSCTRL group name (SYSCTRL_GROUP) =

SYSMAINT group name (SYSMAINT_GROUP) = DEMO

SYSMON group name (SYSMON_GROUP) =

Para modificar alguno de estos valores utilizaremos:

– db2 update dbm cfg using SYSADM_GROUP DEMO

Privilegios de PUBLIC por defecto

En una instalación por defecto de DB2, el grupo PUBLIC (o sea cualquier usuario) puede:

– Hacer SELECT en el catalogo del sistema.

– Crear un nuevo esquema (gracias a la autoridad IMPLICIT_SCHEMA) y objetos dentro de este.

– No puede hacer IMPORT ni LOAD de ficheros.

– No puede crear funciones ni procedimientos almacenados, ya que no cuenta con la autoridad CREATE_EXTERNAL_ROUTINE (En versiones anteriores a la 8.1 si, ya que no existe esta autoridad).

– No cuenta con acceso a la tabla “sysibm.sysdummy1”.

Privilegios de PUBLIC por defecto

Puntos a revisar

Privilegios de autoridad a nivel de instancia. Privilegios de autoridad a nivel de base de datos.

(DBAUTH) Privilegios de acceso a las tablas del sistema. Privilegios de modificación de tablas. Privilegios de creación de funciones y procedimientos

almacenados. Privilegios del grupo “PUBLIC”.

Hardening de usuarios

Además de las medidas anteriores, si nuestras necesidades de seguridad son altas, podemos realizar un paso mas y restringir al máximo el acceso de los usuarios no autorizados.

Para ellos vamos a configurar la base de datos para que impida el acceso a los usuarios del grupo “PUBLIC”, es decir todos aquellos que no han sido explícitamente autorizados.– revoke connect,createtab,bindadd,implict_schema on database from

public

A partir de ahora, cualquier usuario que quiera acceder a la base de datos deberá ser autorizado expresamente por el administrador.

Como ultima medida podemos revocar el acceso de los usuarios a las vistas y tablas del catalogo del sistema. (SYSCAT.*)

Índice

1. Introducción



4. DB2 SQL

5. Vías de acceso


7. Registro


4. DB2 SQL

El lenguaje SQL a pesar de estar definido como un estándar es implementado por cada fabricante con una serie de características particulares.

Estas características van a modificar en gran medida la forma de atacar la base de datos, especialmente cuando se hace mediante inyección de SQL.

Estas peculiaridades también van a ser útiles a la hora de hacer fingerprinting de la base de datos cuando el ataque se realice a ciegas.

Características

Permite subSELECT. No permite subquery (excepto select). Permite UNION. No permite mas de una sentencia SQL por línea. Los mensajes de error no muestran información

detallada (en algunas configuraciones si). No permite SELECT sin FROM. Cuenta con Procedimientos Almacenados y con

Funciones definidas por el usuario. Fin de sentencia con "--". No permite valor de campo NULL en UNIONes. Concatenación con “||”.

Operaciones básicas

Listar las bases de datos:– list database directory

Listar las tablas:– list tables (usuario)

– list tables for all (todas)

– select tabname from syscat.tables (todas)

– select table_name from sysibm.tables (usuario)

– select name from sysibm.systables (todas)

Listar las columnas de una tabla:– describe select * from sysibm.sysversions

– select colname from syscat.columns where tabname='SYSVERSIONS'

Operaciones básicas

Obtener la versión de la base de datos:– select versionnumber from sysibm.sysversions

Obtener una respuesta prefijada:– select 'loquesea' from sysibm.sysdummy1

– select 'loquesea' from sysibm.sysversions

Estructura de la base de datos

Como hemos visto en la sección anterior, DB2 cuenta con una jerarquía de elementos que componen la base de datos.

Los elementos mas importantes a analizar de cara a la seguridad son:– Base de datos

– Tablas

– Funciones y procedimientos almacenados.

Tablas importantes

sysibm.sysdummy1 -> Tabla dummy (equivalente a la tabla "dual" de oracle)

sysibm.systables -> Tablas (name)

sysibm.syscolumns -> Columnas (name, tbname)

sysibm.views -> Vistas (table_name, table_schema, table_catalog)

sysibm.usernames -> Usuarios para conexiones Outbound (puede no existir)

sysibm.sysversions -> Versión

Conversión de tipos

TIPO DESCRIPCION CONVERSION EJEMPLO

varchar texto - ‘xxxx’

integer numérico - 1

date fecha DATE(CADENA_FECHA)

DATE('2004-10-10')

time hora TIME(CADENA_HORA)

TIME('10.10.10')

timestamp fecha/hora TIMESTAMP(CADENA_FECHA, CADENA_HORA)

TIMESTAMP('2004-10-10', '10.10.10')

Índice

1. Introducción



4. DB2 SQL

5. Vías de acceso


7. Registro


5. Vías de acceso

Las formas en las que un posible atacante puede acceder a la base de datos son limitadas y necesitamos tenerlas bien controladas para proteger convenientemente cualquier punto de entrada en la base de datos.

Entre las posibles vías de acceso tendríamos:– Una shell en el equipo

– DB2 wire protocol

– ODBC directo

– ODBC indirecto

– Inyección de SQL

Shell en el equipo

Si tenemos acceso a una shell en el equipo donde se encuentra instalada la base de datos DB2 a auditar, acceder a la misma es automático.

El acceso a la base de datos puede realizarse a través de la herramienta CLP (Command Line Processor) que suele estar localizada en:– /home/db2inst1/sqllib/bin/db2 (Unix)

– "C:\Archivos de programa\IBM\SQLLIB\BIN\DB2CMD.exe" DB2SETCP.BAT DB2.EXE (Windows)

La conexión a la base de datos mediante esta herramienta se realiza sin la necesidad de introducir las credenciales de usuario.

DB2 wire protocol

También podemos obtener acceso a la base de datos DB2 de forma remota a través de un equipo que tenga instaladas las librerías cliente. (Se pueden obtener en la web de IBM)– http://www-306.ibm.com/software/data/db2/runtime.html

La conexión se realiza normalmente a través del puerto 50000/TCP. (Si este se encuentra reservado puede realizarse en el 50001/TCP y adelante.)

Aquí si es necesario introducir unas credenciales validas. Aunque como hemos visto valen las de cualquier usuario del equipo.

ODBC directo

Si disponemos de acceso a un equipo que tenga configurada una conexión ODBC con la base de datos a auditar, podemos utilizarla para acceder a la misma.

Si el DSN no se ha configurado con las credenciales necesarias, tendremos que conocer unas para establecer la conexión. (Aunque en la mayoría de casos si se encuentran preconfiguradas)

ODBC indirecto

Si conocemos un equipo con conexión ODBC a nuestra base de datos y no disponemos de acceso directo al mismo pero podemos instalar algún tipo de aplicación web en el, es posible crear nuestra propia pasarela SQL.

VBS/ASP:

<%

Set conn=server.createobject("ADODB.connection")

conn.open "DRIVER=IBM DB2 ODBC DRIVER; DBALIAS=SAMPLE; UID=db2admin; PWD=db2admin"

…

JAVA/JSP:

try {String dbURL="jdbc:db2://server:50000/books:user=db2admin;password=db2admin";String dbDriver = "com.ibm.db2.jcc.DB2BaseDataSource";

…

Inyección de SQL

Si detectamos alguna vulnerabilidad de inyección de SQL en una aplicación que trabaja contra nuestra base de datos DB2, podemos utilizarla para obtener acceso parcial a la misma.

El acceso es parcial porque el contexto en el que se trabaja es mucho mas limitado que los anteriores, ya que partimos de una sentencia SQL previa que debemos modificar y que nos impedirá realizar algunas acciones.

Puntos a revisar

Restringir en el servidor el acceso de los usuarios no privilegiados a las herramientas y librerías DB2.

Proteger mediante algún tipo de filtrado los puertos TCP utilizados para conexiones remotas en DB2.

Revisar el almacenamiento de las credenciales de acceso mediante ODBC.

Impedir que se instale código externo en los servidores conectados mediante ODBC a la base de datos.

Auditar el código de las aplicaciones que utilizan la base de datos mediante SQL.

Índice

1. Introducción



4. DB2 SQL

5. Vías de acceso


7. Registro



DB2 no es una base de datos fácil de atacar a través de inyección de SQL.

Como hemos visto en el apartado “características” del SQL de DB2, contamos con una serie de limitaciones importantes:– No se permiten subquerys ni mas de una query por sentencia.

– No es posible extraer información de la base de datos a través de los mensajes de error.

– El juego de funciones que podemos llamar desde un SELECT es muy pequeño por defecto, y no se conocen vulnerabilidades en ellas.

– Se permite utilizar UNION, pero no se permite utilizar el valor de campo “NULL” en las UNIONes, de forma que se complica el encontrar el tipo de campos validos.

Inyección de SQL

Después de tantas limitaciones, el mejor ataque que nos queda por lo tanto es el intentar extraer información de la base de datos mediante la creación de una sentencia UNION valida.

Si tampoco es posible obtener un UNION valido, solo nos queda extraer algo de información mediante un ataque a ciegas.

Para hacer esto podemos usar la función “substr”, por ejemplo:– AND substr((select USER from

sysibm.sysversions),1,1)=chr(68)

Fingerprinting

El primer paso para explotar una inyección de SQL, una vez comprobada que la aplicación es realmente vulnerable, será averiguar el tipo y si es posible, la versión de la base de datos.

Si el error no es ciego, y vemos los mensajes de error que genera la base de datos, será fácil averiguar el tipo de la base de datos.

Si el error es ciego, deberemos someter la inyección a una serie de sencillas pruebas lógicas. Por ejemplo:– value(1,1)=1

– USER=USER

– length(1)=4

Mensajes de error DB2

Errores descriptivos

Como he comentado, normalmente los mensajes de DB2 apenas muestran información útil sobre el error producido y no permiten extraer información de la base de datos.

Sin embargo en algunas configuraciones, los mensajes son mas explícitos y nos facilitan lograr una inyección útil.

Para lograr una UNION valida en estos casos:1. Hacemos UNION con 1 campo.2. Si nos muestra un error de "SQL0415: Operandos UNION no

compatibles" es que el tipo del campo no es correcto.3. Probamos otro tipo de datos en el campo.4. Si da un error de "SQL0421: Numero de operandos UNION no igual"

es que el tipo esta bien, y tenemos que añadir otro elemento a la unión.

5. Repetimos la operación hasta que demos con todas las columnas necesarias para hacer el UNION y los tipos de datos de cada una de ellas coincidan.

Inyección ciega

En el caso de que los mensajes de error no sean descriptivos o que la inyección sea ciega (no vemos ningún tipo de mensaje) debemos proceder a un ataque por fuerza bruta.

Tenemos que probar todas las combinaciones posibles de tipo de datos y de numero de campos hasta lograr una UNION correcta.

Para simplificar usaremos 2 valores:– 1 para campos de tipo numérico.

– '2005-01-28-16.09.04.00‘ para campos de tipo cadena y de tipo fecha.

Puntos a mirar

Revisar el código de las aplicaciones que realicen peticiones SQL contra la base de datos para evitar que se produzcan puntos de inyección.

En aplicaciones que se utilicen desde entornos de riesgo expuestos a Internet, limitar al máximo los privilegios del usuario utilizado para acceder a la base de datos.

Hacer que la aplicación en producción no muestre al usuario los posibles errores generados por la base de datos.

Índice

1. Introducción



4. DB2 SQL

5. Vías de acceso


7. Registro


7. Registro

Dentro del directorio base de la instancia DB2 se encuentran una serie de ficheros de log que es necesario revisar para detectar posibles usos irregulares de la base de datos.

Los ficheros mas destacables son: – db2diag.log: Contiene todos los mensajes de error y de

warning.

– jdbcerr.log: Errores en conexiones JDBC.

– instance_name.nfy: Notificaciones de administración. (Solo Unix, en Windows estos mensajes de manejan por el event log del sistema)

Logs

La localización de estos ficheros viene determinada por el parámetro de configuración DIAGPATH, aunque por defecto en suele ser: – /opt/db2/db2inst1/sqllib/db2dump/* (Unix)

– C:\Archivos de programa\IBM\SQLLIB\DB2\* (Windows)

El nivel de registro viene determinado por los parámetros de configuración DIAGLEVEL y NOTIFYLEVEL, que toman valores entre 0 y 4. Siendo normalmente 3 el valor por defecto.

Es recomendable elevarlos a 4 de la siguiente forma:– db2 update dbm cfg using DIAGLEVEL 4

Puntos a revisar

Comprobar que el nivel de registro (DIAGLEVEL y NOTIFYLEVEL) es suficiente (>=3).

Comprobar que los ficheros de registro no han sido borrados o alterados.

Comprobar en los registros que no existen eventos “anomalos” que puedan indicar una actividad ilegal en el sistema.

Índice

1. Introducción



4. DB2 SQL

5. Vías de acceso


7. Registro


8. Acceso al Sistema operativo

Una vez hemos comprobado la seguridad de los datos almacenados en la base de datos, podemos comprobar si es posible atacar otros sistemas a partir de este.

La configuración por defecto de DB2, impide a los usuarios con pocos privilegios el acceso a funciones del sistema operativo, pero si conseguimos acceso a una cuenta con autoridad suficiente o los privilegios de acceso se encuentran mal configurados, podemos intentar atacar el sistema operativo.

Ejecución de comandos

DB2 permite mapear llamadas a librerías del sistema en una función o en un procedimiento almacenado. De esta forma podemos realizar cualquier operación que nos permitan las librerías estándar. Por ejemplo ejecutar comandos a través de la llamada system():– create function cmdfunc(varchar(200)) returns integer language

C parameter style sql external name 'msvcrt.dll!system'

– select cmdfunc('dir > c:\test.txt') from sysibm.sysdummy1

En Unix:– create function linfunc(varchar(200)) returns integer language C

parameter style sql external name '/lib/libc.so.6!system'

– select linfunc('ls > /tmp/(test.txt') from sysibm.sysdummy1

Cambio de contraseña

Aunque hemos comentado que no se podía modificar la configuración de los usuarios desde la base de datos, si existe una operación que podemos realizar. Es posible cambiar la contraseña de un usuario del que conocemos sus credenciales a través del comando “connect” de la base de datos:– connect to <database> user <uid> using <password> new

<newpassword> confirm <again newpw>

Lectura de ficheros

Por ultimo tenemos la función “import” que nos permite leer ficheros del sistema. – create table mytable (data varchar(100));

– import from 'c:\boot.ini' of del insert into mytable;

– select * from mytable;

Aunque no puede ser invocada desde ODBC y requiere privilegios altos.

Puntos a revisar

Quitarle la autoridad CREATE_EXTERNAL_ROUTINE a todos los usuarios. Si es necesario crear alguna función o procedimiento se utilizara un usuario DBADM.

Quitarle la autoridad CONNECT a aquellos usuarios que no queremos que modifiquen su contraseña. (Ojo con esto porque tampoco podrán conectar a la base de datos)

Quitarle la autoridad LOAD a todos los usuarios.

Conclusiones

A pesar de no ser un sistema de base de datos demasiado popular y no haber sufrido análisis de vulnerabilidades tan intensivos como otras bases de datos, DB2 da una buena impresión en cuanto a seguridad y robustez.

Como se ha podido ver, auditar y securizar esta base de datos no es tan difícil como parecía inicialmente.

Espero que no os hayáis aburrido mucho y que estos conocimientos os sean útiles en el futuro…

db2_audit

Documents

Transcript of db2_audit