En Oracle, tenemos una gama importante de productos, que permiten de manera eficiente y efectiva, brindar un nivel de seguridad de alto nivel, acorde con las necesidades y estándares internacionales, solicitados por entidades regulatorias.
Dentro de la base de datos, podemos realizar una gran cantidad de acciones, que nos permite de alguna forma, sentirnos seguros cada noche a la hora de irnos a descansar.
Sin embargo, como en ennumeradas ocasiones lo he dicho en mis charlas de productos de seguridad de Oracle, debemos tener en claro, que el DBA, siempre ha sido tratado como un dios y no debe porque ser un dios, en el tema de la base de datos.
Con Oracle Database Vault, un producto, licenciable sólamente en la versión Enterprise Edition de la base de datos Oracle, podemos hacer una separación de roles, de tal manera, que el DBA, no realice funciones, que no son de su competencia.
Qué debe estar haciendo un DBA a media noche del día sábado ( día no laboral ), pegado a la base de datos de producción, consultando la tabla de salarios del esquema de planillas.?
Oracle Database Vault, entre muchas otras cosas, puede filtrar e impedir este tipo de acciones, aún, cuando el usuario sea SYS o SYSTEM.
Pero para los simples mortales que cuentan con la versión One Edition o Standard Edition, que podemos hacer.?
Como hago yo, para impedir, el fraude más común, que un DBA puede hacer en una base de datos, como lo es el "ROBO DE IDENTIDAD".?
Es posible, realizar esta acción en una base de datos Oracle 11gR2, a pesar, que en la nueva versión en la tabla del diccionario de la base de datos DBA_USERS, en la columna de "Password", esta encriptada y no se pueden ver, aún codificados, los valores almacenados, aunque sea SYS o SYSTEM, los que estan consultando la tabla.?
La respuesta es: SI, si se puede hacer "Robo de Identidad" en una base de datos 11gR2, contando con los permisos adecuados en una cuenta común de usuario, o por parte de la persona que maneja las cuentas con privilegios SYSDBA, como SYS o SYSTEM.
Veamos como:
Vamos a crear un usuario en nuestra base de datos.
SQL> create user demo2 identified by demo2;
User created.
Le vamos a dar privilegios de poderse logear y crear una sesión de trabajo en la base de datos.
SQL> grant create session to demo2;
Grant succeeded.
Ahora veamos el contenido de la tabla DBA_USERS y que es lo que guarda en la columna de "PASSWORD".
SQL> desc dba_users
Name Null? Type
------------------------------ -------- --------------
USERNAME NOT NULL VARCHAR2(30)
USER_ID NOT NULL NUMBER
PASSWORD VARCHAR2(30)
ACCOUNT_STATUS NOT NULL VARCHAR2(32)
LOCK_DATE DATE
EXPIRY_DATE DATE
DEFAULT_TABLESPACE NOT NULL VARCHAR2(30)
TEMPORARY_TABLESPACE NOT NULL VARCHAR2(30)
CREATED NOT NULL DATE
PROFILE NOT NULL VARCHAR2(30)
INITIAL_RSRC_CONSUMER_GROUP VARCHAR2(30)
EXTERNAL_NAME VARCHAR2(4000)
PASSWORD_VERSIONS VARCHAR2(8)
EDITIONS_ENABLED VARCHAR2(1)
AUTHENTICATION_TYPE VARCHAR2(8)
SQL> select username, account_status, password_versions, password from dba_users
2 where username='DEMO2';
USERNAME ACCOUNT_STATUS PASSWORD
--------------------- ------------------ --------
PASSWORD
-------------
DEMO2 OPEN 10G 11G
SQL> column username format a10;
SQL> column account_status format a10;
SQL> /
USERNAME ACCOUNT_ST PASSWORD PASSWORD
---------- ---------- -------- ----------
DEMO2 OPEN 10G 11G
Como pueden observar, la columna de "Password", se muestra en blanco, evitando que aquellas personas que tengan acceso a la tabla del diccionario de la base de datos, puedan conocer, en formato encriptado, el valor guardado para el usuario respectivo, como palabra clave.
SQL> select * from v$version;
BANNER
-------------------------------------------------
Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 - Production
PL/SQL Release 11.2.0.1.0 - Production
CORE 11.2.0.1.0 Production
TNS for 32-bit Windows: Version 11.2.0.1.0 - Production
NLSRTL Version 11.2.0.1.0 - Production
Sin embargo, veamos, como conectado con el usuario SYS a la base de datos, tengo acceso a la vista USER$, en la cuál, también se encuentra la columna "Password".
SQL> show user
USER is "SYS"
SQL> desc sys.user$
Name Null? Type
-------------- -------- --------------
USER# NOT NULL NUMBER
NAME NOT NULL VARCHAR2(30)
TYPE# NOT NULL NUMBER
PASSWORD VARCHAR2(30)
DATATS# NOT NULL NUMBER
TEMPTS# NOT NULL NUMBER
CTIME NOT NULL DATE
PTIME DATE
EXPTIME DATE
LTIME DATE
RESOURCE$ NOT NULL NUMBER
AUDIT$ VARCHAR2(38)
DEFROLE NOT NULL NUMBER
DEFGRP# NUMBER
DEFGRP_SEQ# NUMBER
ASTATUS NOT NULL NUMBER
LCOUNT NOT NULL NUMBER
DEFSCHCLASS VARCHAR2(30)
EXT_USERNAME VARCHAR2(4000)
SPARE1 NUMBER
SPARE2 NUMBER
SPARE3 NUMBER
SPARE4 VARCHAR2(1000)
SPARE5 VARCHAR2(1000)
SPARE6 DATE
A la hora de realizar la consulta a la vista, ahora si tengo acceso al código almacenado y encriptado del usuario, en la base de datos, correspondiente al usuario respectivo.
SQL> select name, password from sys.user$ where name='DEMO2';
NAME PASSWORD
------------ -----------------
DEMO2 1175C8499AEA4DEC
Conociendo este dato, ahora el asunto es meramente, un juego de niños. Yo podría cambiar el password al usuario "demo2", logearme en la base de datos a través de SQL o el aplicativo, teniendo así, acceso al grupo de privilegios asignados por aplicación; correr un proceso "X" y luego, simplemente, volver a cambiar la clave, al valor original, sin que el usuario dueño de la cuenta, se entere, de que su cuenta y seguridad, ha sido "HACKEADA".
SQL> alter user demo2 identified by oracle;
User altered.
SQL> connect demo2/oracle
Connected.
SQL> alter user demo2 identified by values '1175C8499AEA4DEC';
User altered.
SQL> connect demo2/demo2;
Connected.
SQL>
Recuerde que estadísticamente hablando, la mayor cantidad de ataques a los sistemas, se originan dentro de la organización y no fuera de ella.
Conozca al personal que tiene a su cargo y determine, cuál es el papel protagonista que puede jugar en el engranaje de la seguridad de su información y establezca mecanismos, que le permita mitigar, una acción indebida.
La clave de los usuarios SYS y SYSTEM, deben estar en manos de un grupo mínimo de personas. Si al menos confía en su DBA, no permita que personas ajenas a él, conozcan las claves de tan potenciales usuarios dentro de la base de datos.
Busque como asegurar sus sistemas ahora y no espere, a que la edad de retiro le alcance, para empezar a hacer algo.
La seguridad no es un juego de niños; tampoco lo es la información de su organización. Si usted se empeña en asegurar algo, habrán 10 o más, pensando y analizando, en como romper ese cerco.
Algunos cuentan con mucha suerte y nunca sufren ningún tipo de problema, otros sin embargo, no son tan suertudos en el tema. Sino que lo digan CITI y SONY, en los últimos días.
