Cuentas de Esquema Único en Oracle 18c y 19c
Antes de Oracle 18c, crear un usuario exigía definir su método de autenticación. En 12c, 11g y 10g se usaban principalmente tres métodos: contraseña, externo y global. Con contraseña, el hash se almacena en la tabla interna user$. Con autenticación externa o global no se guarda contraseña en la base de datos y la verificación ocurre fuera del motor.
Oracle 18c introdujo las Cuentas de Esquema Único mediante la cláusula NO AUTHENTICATION. Este tipo de cuenta no permite inicio de sesión directo y, por tanto, reduce la exposición de los esquemas de aplicación con privilegios elevados. La configuración no solo aplica al crear el usuario, también puede activarse sobre un usuario existente con ALTER USER.
Ejemplo de creación de una cuenta de esquema: SQL> CREATE USER usef_schema NO AUTHENTICATION; Resultado: User created. El inicio de sesión directo fallará con ORA-01017 o ORA-01005 y no se almacena contraseña en user$. En la vista dba_users, el campo AUTHENTICATION_TYPE aparecerá como NONE para este usuario.
La concesión de privilegios y roles funciona igual que con cualquier usuario. Ejemplos: SQL> grant connect, resource to usef_schema; SQL> alter user usef_schema quota unlimited on users; SQL> alter user usef_schema default tablespace users; Con estos permisos, usuarios autorizados pueden crear y administrar objetos en el esquema, por ejemplo SQL> grant connect, unlimited tablespace, create any table, select any table to usef; Conectar como usef y crear objetos en usef_schema: SQL> conn usef/a; SQL> create table usef_schema.mytbl as select * from dual; Si usef no tiene privilegios suficientes, operaciones como drop en objetos de usef_schema devolverán ORA-01031.
Acceso mediante proxy y auditoría unificada
Las Cuentas de Esquema Único se consumen de forma segura con una conexión proxy, delegando la autenticación en otro usuario. Ejemplo para permitir que usef se conecte como proxy al esquema: SQL> ALTER USER usef_schema GRANT CONNECT THROUGH usef; Conexión local: SQL> conn usef[usef_schema]/a. Conexión remota: SQL> conn usef[usef_schema]/a@//host:1521/servicio. Se puede verificar el esquema activo con show user y mediante el contexto de sesión con sys_context, confirmando que el usuario de proxy es el que autentica y el esquema efectivo es usef_schema.
Bajo conexión proxy, el usuario de proxy actúa sobre los objetos del esquema. Por ejemplo, si antes no era posible eliminar la tabla mytbl, ahora SQL> drop table usef_schema.mytbl; funcionará si los privilegios lo permiten.
Puede otorgarse el privilegio de proxy a múltiples usuarios. Ejemplo: SQL> ALTER USER usef_schema GRANT CONNECT THROUGH nima; En auditoría unificada, el campo DBPROXY_USERNAME mostrará el usuario que actuó como proxy y se podrá asociar con una policy como mypol1. Ejemplos: SQL> create audit policy mypol1 roles dba; SQL> audit policy mypol1 by usef_schema; Tras operaciones como drop table o create table realizadas por nima[usef_schema], los registros aparecerán en unified_audit_trail con el usuario de proxy identificado. Para revisar la lista de proxies activos sobre el esquema, la vista proxy_users mostrará entradas como USEF y NIMA asociados al cliente USEF_SCHEMA.
Diferencias entre 18c y 19c con privilegios administrativos
En Oracle 18c no es posible otorgar privilegios administrativos como SYSDBA o SYSOPER a Cuentas de Esquema Único. Un intento de SQL> grant sysdba to USEF_SCHEMA; devolverá ORA-40366. En Oracle 19c esta limitación se elimina y sí es posible otorgar privilegios administrativos a este tipo de cuentas.
Cambiar el método de autenticación
En cualquier momento se puede abandonar el modo de Esquema Único definiendo una credencial. Ejemplo: SQL> alter user usef_schema identified by a; Tras esto, el usuario podrá iniciar sesión con contraseña y en dba_users AUTHENTICATION_TYPE pasará a PASSWORD. Inversamente, también puede volver a modo Esquema Único: SQL> alter user usef no authentication; con lo que de nuevo se impide el inicio de sesión directo.
Buenas prácticas y casos de uso
Las Cuentas de Esquema Único son especialmente útiles para esquemas de aplicaciones con alto nivel de privilegios, donde la autenticación y el acceso se controlan desde un usuario de servicio o un pool de conexiones. Combinadas con auditoría unificada, políticas de mínimos privilegios, vistas de seguridad y proxy, ayudan a endurecer la superficie de ataque y a simplificar el gobierno de accesos.
Cómo podemos ayudarte desde Q2BSTUDIO
En Q2BSTUDIO integramos estas prácticas en soluciones de software a medida y aplicaciones a medida, optimizando la seguridad y el rendimiento de tus bases de datos en entornos híbridos y cloud. Diseñamos arquitecturas seguras, automatizamos despliegues y aplicamos ciberseguridad avanzada y pruebas de pentesting para proteger tus datos críticos. Si estás migrando o operando Oracle en la nube, te acompañamos con nuestros servicios cloud AWS y Azure para garantizar alta disponibilidad, cifrado, backup y observabilidad de extremo a extremo.
Nuestro equipo también impulsa la modernización de datos con servicios inteligencia de negocio y analítica avanzada. Implementamos modelos de ia para empresas, agentes IA y cuadros de mando con power bi, conectando de forma segura tus esquemas Oracle con pipelines de datos y capas semánticas. Además, desarrollamos integraciones y portales operativos como parte de nuestro enfoque de desarrollo de software a medida, asegurando que tus procesos y aplicaciones evolucionen con la misma velocidad que tu negocio.
Palabras clave estratégicas
Aplicaciones a medida, software a medida, inteligencia artificial, ciberseguridad, servicios cloud aws y azure, servicios inteligencia de negocio, ia para empresas, agentes IA, power bi.