Rol PUBLIC en Oracle

Los roles facilitan la concesión y revocación de privilegios para los usuarios de una base de datos relacional. En lugar de gestionar los privilegios para cada usuario de forma individual, se administran los privilegios para cada rol y todos los cambios se aplican a todos los usuarios que están asignados a ese rol. Las organizaciones a menudo crean múltiples roles para adaptarse a sus necesidades únicas.

Sin embargo, la mayoría de las bases de datos vienen con un rol predefinido llamado PUBLIC. En este blog, explicamos qué significa el rol PUBLIC en Oracle y las principales mejores prácticas para usarlo.

¿Qué es el rol PUBLIC en Oracle?

El rol PUBLIC es un rol especial que todo usuario de base de datos hereda implícitamente al ser creado. La documentación de Oracle 11g establece que el rol PUBLIC es accesible para todos los usuarios de la base de datos y, por lo tanto, todos los privilegios y roles otorgados al rol PUBLIC son accesibles para cada usuario. Aunque un administrador puede emitir un comando para conceder o revocar el rol PUBLIC a un usuario en particular, estos comandos no tienen ningún efecto práctico; el usuario siempre tendrá este rol.

Es interesante señalar que la vista DBA_ROLES no enumera el rol PUBLIC:

      SQL> SELECT * FROM DBA_ROLES WHERE ROLE =’PUBLIC’;

no rows selected
      

Sin embargo, al consultar la tabla SYS.USER$ se muestra que PUBLIC sí existe y su valor de type# de 0 indica que es un rol:

      SQL> SELECT user#, type#, name FROM SYS.USER$ WHERE type# = 0 ORDER BY 1;
      

La naturaleza implícita de la asignación del rol PUBLIC a todos los usuarios de la base de datos se puede ver en el siguiente ejemplo. Otorgar el privilegio CONNECT al rol PUBLIC permitirá que sea heredado por el nuevo usuario sin necesidad de otorgarlo explícitamente.

      SQL> CREATE USER bob IDENTIFIED BY MyPassword;

SQL> conn bob/MyPassword;
      

Mejores prácticas para el rol PUBLIC

El rol PUBLIC no debe utilizarse para la gestión de privilegios de usuario. En otras palabras, nunca asigne un privilegio o rol a PUBLIC a menos que la intención sea otorgar esos privilegios y roles a todos los usuarios actuales de la base de datos y a cualquier nuevo usuario que pueda crearse en el futuro.

De hecho, otorgar privilegios y roles directamente al rol PUBLIC se clasifica como un hallazgo por la Agencia de Sistemas de Información de Defensa (DISA): la Guía de Implementación Técnica de Seguridad (STIG) de DISA identificación de vulnerabilidad V-61435 establece que no se deben otorgar privilegios de base de datos o sistema a PUBLIC, y V-61443 establece que los permisos de rol de aplicación no deben asignarse a PUBLIC.

Comprender el porqué requiere algo de contexto. En un entorno de base de datos contenedor (CDB) o base de datos conectable (PDB), existe el concepto de roles comunes y roles locales. En una CDB, los roles comunes se crean en la raíz y son conocidos por todos los contenedores actuales y futuros. En un entorno de PDB, los roles locales son locales a un PDB específico; solo se pueden utilizar dentro del PDB en el que están definidos.

Sin embargo, en un entorno multiinquilino de Oracle, los roles son un poco más complicados. Por defecto, todos los privilegios que Oracle otorga al rol PUBLIC se conceden de manera local y común. Según Oracle, nunca se deben otorgar privilegios al rol PUBLIC de manera común. En otras palabras, nunca conceda ningún tipo de privilegio al rol PUBLIC en la raíz o CDB. Aunque es posible modificar el rol PUBLIC dentro de cada CDB por separado, esto no se recomienda a menos que sea necesario.

Cualquier privilegio otorgado por el usuario al rol PUBLIC puede ser revocado sin consecuencias adversas. Pero se debe tener cuidado al revocar los privilegios predeterminados otorgados al rol PUBLIC como parte de la creación de la base de datos, ya que esos privilegios podrían ser otorgados nuevamente durante un futuro proceso de actualización o parcheo.

Para obtener ayuda en la enumeración de todos los roles y privilegios de Oracle, incluido el rol PUBLIC, considere invertir en una solución de terceros como Netwrix StealthAUDIT, que puede generar informes detallados de derechos de forma predeterminada.