Conexiones a esquemas Owners de Tablas
Seguridad Oracle y Usuarios PROXY
En el artículo anterior, hablamos de lo inconveniente que es permitir que aplicaciones y usuarios se conecten directamente a los esquemas owners de las tablas de una aplicación (de aquí en adelante llamaremos en términos genéricos usuario_owner). Esto viola varios principios de seguridad como, por ejemplo, dificultar el cambio de passwords en forma periódica y generar poca trazabilidad de usuarios y aplicaciones que se conectan a la base de datos. Además, se provocan una serie de riesgos de seguridad con distintos usuarios manejando la password del esquema owner de tablas.
Sin embargo, cuando se tiene un esquema owner con gran cantidad de tablas, es complejo disponer de un segundo usuario para conectarse en forma indirecta via sinónimos y privilegios adecuados. Lo anterior, porque normalmente no existe documentación para aplicar principio de mínimo privilegio.
Para resolver parcialmente el problema anterior, desde Oracle 9i R2 existe el concepto de Usuario PROXY, un usuario distinto al owner de las tablas, con usuario y pasword diferente, pero que a través de él es posible conectarse al esquema original, con exactamente los mismos privilegios del esquema owner de las tablas. De hecho, si se consulta la vista V$SESSION, estas conexiones siguen apareciendo con el nombre del esquema owner original. Pero como ya veremos, este tipo de conexiones pueden ser auditadas y controladas mediante otras vistas complementarias.
Para recordar los casos de uso en las conexiones a la base de datos que hacen normalmente las aplicaciones tenemos la siguiente figura 1 que ilustra el caso de uso normal (incorrecto) y la figura 2 que es el caso de uso con conexiones via usuarios proxy (recomendado).
Las figuras 1 y 2 muestran los dos casos: 1 la mala práctica que ya habíamos comentado antes en que las aplicaciones se conectan directamente al esquema owner de las tablas de la aplicación.
Y; 2, la buena práctica usando un usuario PROXY de propósito específico para cada aplicativo o necesidad. En esta segunda figura vemos dos usuarios proxy, uno para conectar la aplicación web llamada Aplicación General Ledger (es solo un ejemplo, puede ser cualquier aplicación) y otro, para uso de un DBlink desde una BD remota llamada BD3.
La aplicación 1 General Ledger, en vez de conectarse directamente al esquema owner de las tablas de este sistema, lo hace a través de un usuario PROXY, en representación de GL, el esquema owner de las tablas y que por lo mismo, ve exactamente los mismos objetos y privilegios como se hubiera conectado directamente al esquema GL.
Lo mismo ocurre con el Database Link que viene de la base de datos remota DB3. Esto tiene varias ventajas. Primero, si se quiere bloquear el acceso de la BD remota llamada BD3, por motivos de seguridad, solo se bloquea el usuario GL_PXY_DBL_BD3, que tiene el uso exclusivo de acceso a ese origen.
No se afecta a la aplicación GL que usa el usuario GL_PXY_MID_GLAPP. Nótese la nomenclatura y estándar de nombres. GL, es el esquema owner, luego PXY, indica que se trata de un usuario PROXY, MID, que por medio de este usuario se conectará una aplicación Middleware y finalmente GLAPP un shortname para el nombre del aplicativo propiamente tal.
¿Por qué usar usuarios proxy?
Hay dos razones principales para utilizar usuarios proxy.
- Algunas tareas del DBA, como crear database links privados o configurar trabajos utilizando el paquete DBMS_JOB, requieren que el administrador inicie sesión como un usuario específico. Esto puede presentar un problema si el DBA no conoce la contraseña.
- Si tiene varios desarrolladores trabajando en un esquema compartido. Permitir que varias personas compartan las mismas credenciales representa un riesgo de seguridad. En su lugar, se crea un usuario proxy independiente para cada individuo, lo que les permite conectarse con el propietario del esquema con sus propias credenciales. Si un usuario abandona un proyecto, o se retira de la organización, simplemente se bloquea o se descarta y ya no tendrá acceso al esquema compartido.
Usuario proxy y privilegio CONNECT THROUGH
Tal como lo habíamos comentado antes, desde la versión 2 de Oracle 9i, ha sido posible crear usuarios proxy. Esto nos permite acceder a un esquema a través de una combinación diferente de nombre de usuario y contraseña. Esto se hace utilizando la cláusula GRANT CONNECT THROUGH sobre el usuario de destino (usuario proxy)
Los scripts que implementan la solución del ejemplo de la figura 2 son los siguientes:
— Como super usuario SYS
SQL> conn sys/SysPassword1@//localhost:1521/pdb1 as sysdba
— Crea proxy user
SQL> CREATE USER gl_pxy_mid_glapp IDENTIFIED BY pxy_user_Password;
SQL> GRANT CREATE SESSION TO gl_pxy_mid_glapp;
Permitir que el usuario GL_PXY_MID_GLAPP establezca una conexión proxy con el usuario owner de tablas llamado GL
SQL> ALTER USER gl GRANT CONNECT THROUGH gl_pxy_mid_glapp;
Ahora podemos conectarnos con el usuario GL, utilizando las credenciales del usuario proxy.
SQL> conn gl_pxy_mid_glapp [gl]/pxy_user_Password @//localhost:1521/pdb1
SQL> show user
USER is «GL»
Se observa que el usuario proxy se conectó como el usuario owner GL, y si se consulta la vista v$session, se verá que aparece una sesión de GL, no la del usuario proxy. Entonces como sé cual es el usuario real que está conectado a la base de datos. Eso lo veremos más adelante en este artículo.
La autenticación de proxy se puede revocar mediante el siguiente comando.
SQL> ALTER USER gl REVOKE CONNECT THROUGH gl_pxy_mid_glapp;
Con este método, el administrador ahora puede configurar su cuenta privilegiada para conectarse mediante acceso a cualquier otro usuario, permitiéndole realizar tareas como ese usuario, sin tener que modificar la contraseña del usuario.
Identificación de usuarios proxy
Los usuarios proxy se pueden identificar mediante la vista PROXY_USERS
SQL> select * from proxy_users;
PROXY CLIENT AUT FLAGS
——————– —————————— — ———————————–
GL_PXY_MID_GLAPP GL NO PROXY MAY ACTIVATE ALL CLIENT ROLES
SQL>
La vista V$SESSION solo informa el usuario de destino (usuario owner) en la columna USERNAME, por lo que no podemos diferenciar qué usuarios son conexiones directas y cuáles son conexiones via proxy. Si se hace un JOIN con la vista V$SESSION_CONNECT_INFO (alias SCI en el script que se muestra más abajo) nos da acceso a la columna AUTHENTICATION_TYPE, que si contiene el valor «PROXY» para conexiones proxy. De esta manera podemos consultar solo las sesiones que utilizan autenticación de proxy.
SQL> select s.sid, s.serial#, s.username, s.osuser, sci.authentication_type
from v$session s, v$session_connect_info sci
where s.sid = sci.sid
and s.serial# = sci.serial#
and sci.authentication_type = ‘PROXY’;
Sin embargo, seguimos con el problema de identificar el nombre del usuario que realmente se conectó al esquema owner de la base de datos.
El nombre del usuario proxy (la cuenta personal del desarrollador) está disponible en el contexto de la sesión del sistema (función sys_context(‘userenv’,’proxy_user’)) y puede hacerse visible automáticamente en la vista v$session a través de un trigger de base de datos, para que el DBA pueda saber quién está conectado realmente a las cuentas compartidas en todo momento.
Nota: asegúrese de no estar utilizando la funcionalidad DBMS_SESSION.SET_IDENTIFIER para otras aplicaciones, antes de implementar el siguiente trigger de base de datos:
SQL> CREATE OR REPLACE TRIGGER db_session_pxy_user_trig
AFTER LOGON ON DATABASE
v_proxy_user varchar2;
BEGIN
v_proxy_user := sys_context(‘userenv’,’proxy_user’);
if v_proxy_user is not null then
dbms_session.set_identifier(v_proxy_user);
end if;
END;
— se consulta la vista v$session y aparece el nombre del usuario proxy
SQL> select username, osuser, client_identifier
from v$session where username=’USUARIO_OWNER’;
USERNAME OSUSER CLIENT_IDENTIFIER
———————– ——— ———————-
USUARIO_OWNER oracle USUARIO_PROXY
Finalmente, en la vista v$session, en la columna CLIENT_IDENTIFIER, podemos consultar el nombre del usuario proxy que está conectado a un usuario owner.
Un script más detallado de las sesiones proxy, desarrollado por Tim Hall es el siguiente:
— ———————————————————————————–
— File Name : https://oracle-base.com/dba/monitoring/proxy_sessions.sql
— Author : Tim Hall
— Description : Displays information on all database proxy sessions.
— Requirements : Access to the V$ views.
— Call Syntax : @proxy_sessions
— Last Modified: 01-JUN-2021
— ———————————————————————————–
set linesize 500
set pagesize 1000
column username format a30
column osuser format a20
column spid format a10
column service_name format a15
column module format a45
column machine format a30
column logon_time format a20
select nvl(s.username, ‘(oracle)’) as username,
s.osuser,
s.sid,
s.serial#,
p.spid,
s.lockwait,
s.status,
s.service_name,
s.machine,
s.program,
to_char(s.logon_time,’dd-mon-yyyy hh24:mi:ss’) as logon_time,
s.last_call_et as last_call_et_secs,
s.module,
s.action,
s.client_info,
s.client_identifier
from v$session s,
v$process p,
v$session_connect_info sci
where s.paddr = p.addr
and s.sid = sci.sid
and s.serial# = sci.serial#
and sci.authentication_type = ‘PROXY’
order by s.username, s.osuser;
set pagesize 14
En resumen, el uso de usuarios proxy en Oracle ofrece una solución intermedia para mitigar los riesgos de seguridad asociados a las conexiones directas a los esquemas owners de las tablas. Si bien no elimina por completo la necesidad de contar con documentación detallada sobre privilegios, sí permite un mejor control y trazabilidad de las conexiones a la base de datos.
