Cuentas de Esquema Único en Oracle 18c y 19c

Antes de Oracle 18c, la creación de usuarios exigía definir su método de autenticación. En las versiones clásicas 12c, 11g y 10g, los métodos más comunes eran: contraseña, externa y global. Con contraseña, la base de datos guarda el hash del password en la tabla interna user$. Con autenticación externa y global, no se guarda ninguna contraseña y la verificación se realiza fuera de la base de datos.

Oracle 18c introdujo una novedad clave: crear un usuario sin especificar autenticación mediante la cláusula NO AUTHENTICATION. Este tipo de cuenta, conocida como Schema Only Account, no permite inicio de sesión directo. Es una medida excelente para reforzar la seguridad en esquemas de aplicación con altos privilegios. Además, no es algo exclusivo del momento de creación; se puede aplicar a usuarios ya existentes con ALTER USER.

Ejemplo de creación de un esquema sin autenticación: CREATE USER usef_schema NO AUTHENTICATION; El inicio de sesión directo fallará con errores como ORA-01017 o ORA-01005 y no habrá password almacenado 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 otros usuarios. Por ejemplo, se pueden otorgar connect y resource, establecer cuota ilimitada en el tablespace users y definir el tablespace por defecto. Con estos permisos, un usuario con privilegios adecuados puede crear y administrar objetos en el esquema usef_schema, por ejemplo tablas, vistas o índices. Si ese usuario carece de privilegios suficientes, operaciones como drop sobre objetos de usef_schema fallarán con ORA-01031.

Para trabajar con un Schema Only Account sin habilitar el inicio de sesión directo, se recomienda usar conexión proxy. Basta con permitir el acceso proxy con ALTER USER usef_schema GRANT CONNECT THROUGH usef. Después, se puede conectar localmente con sintaxis como CONN usef[usef_schema]/a o de forma remota con CONN usef[usef_schema]/a@//host:puerto/servicio. Al verificar el contexto de sesión, se observará que session_user y session_schema apuntan al esquema usef_schema y que el usuario proxy activo es usef. Bajo esta conexión proxy, el usuario podrá realizar operaciones que antes no podía, como eliminar una tabla del esquema.

La autenticación proxy puede concederse a múltiples usuarios. Por ejemplo, permitir que nima se conecte a usef_schema con ALTER USER usef_schema GRANT CONNECT THROUGH nima. Si se habilita auditoría unificada, es posible detectar qué usuario proxy realizó la acción. Un flujo típico sería crear una política de auditoría para roles dba, auditarla para el esquema objetivo y luego, tras ejecutar operaciones como drop table o create table bajo la sesión proxy de nima, consultar unified_audit_trail. La columna DBPROXY_USERNAME mostrará el nombre del usuario proxy que actuó. Para listar los usuarios proxy configurados de un cliente concreto se puede consultar la vista proxy_users, donde se mostrará la relación proxy y cliente junto con las banderas de activación de roles.

Restricciones y diferencias por versión. En Oracle 18c no es posible otorgar privilegios administrativos como SYSDBA o SYSOPER a cuentas de tipo Schema Only Account y el intento arrojará ORA-40366. En Oracle 19c, esta limitación se levanta y ya es posible conceder privilegios administrativos a este tipo de cuentas. Así, se puede crear usef_schema con NO AUTHENTICATION y posteriormente otorgar SYSDBA según la necesidad operativa y las políticas de seguridad.

Cambio de modo de autenticación. Es sencillo alternar entre un usuario con contraseña y una Schema Only Account. Para abandonar el modo solo esquema, utilice ALTER USER USEF_SCHEMA IDENTIFIED BY a y el usuario quedará habilitado para iniciar sesión con contraseña, reflejándose AUTHENTICATION_TYPE como PASSWORD en dba_users. Del mismo modo, puede revertirse a modo solo esquema con ALTER USER usef NO AUTHENTICATION si desea bloquear el inicio de sesión directo de nuevo.

Buenas prácticas de seguridad y operación. Emplee cuentas de solo esquema para aislar la lógica de datos y reducir la superficie de ataque, combinado con conexión proxy y políticas de auditoría unificada para trazabilidad. Planifique roles y privilegios mínimos necesarios, cuotas de tablespace y políticas de contraseñas para los usuarios proxy. Integre estas decisiones con sus controles de ciberseguridad, segmentación de redes y gestión de secretos, especialmente si su base de datos se ejecuta en entornos de servicios cloud aws y azure.

En Q2BSTUDIO ayudamos a equipos de TI y negocios a diseñar arquitecturas seguras y escalables alrededor de sus bases de datos Oracle, integrando automatización, observabilidad y gobierno del dato. Somos una empresa de desarrollo de software a medida y aplicaciones a medida, especialistas en inteligencia artificial, ciberseguridad, servicios cloud aws y azure, servicios inteligencia de negocio y power bi, además de soluciones de ia para empresas y agentes IA. Si busca acelerar la entrega de producto sin comprometer la seguridad, podemos acompañarle de punta a punta, desde la definición de la estrategia hasta la puesta en producción.

Descubra cómo impulsamos sus plataformas con servicios cloud, optimización de costes y arquitectura híbrida visitando nuestro servicio de servicios cloud aws y azure. Y si su foco es fortalecer la protección de sus datos y operaciones, conozca nuestro enfoque de pruebas de intrusión, gestión de vulnerabilidades y cumplimiento con ciberseguridad y pentesting. Nuestro objetivo es que sus soluciones de software a medida sean seguras, eficientes y preparadas para crecer.

Palabras clave recomendadas para posicionamiento: 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.