Rol público en SQL Server

Los roles de base de datos son similares a los grupos de Windows — en lugar de revocar o conceder acceso a cada usuario por separado, los administradores gestionan el acceso otorgando o revocando permisos de los roles y cambiando la membresía de los mismos. Utilizar roles facilita otorgar y revocar privilegios de manera precisa para los usuarios de la base de datos. Y dado que múltiples usuarios pueden ser miembros de un rol de base de datos SQL, puedes gestionar fácilmente los derechos para todo un grupo de usuarios a la vez.

En esta publicación, explicamos el rol public en Microsoft SQL Server y algunas de las mejores prácticas relacionadas con él. (Estamos utilizando deliberadamente letras minúsculas aquí, ya que así es como se escribe el rol public en el mundo de SQL Server, a diferencia del mundo de Oracle.)

Tipos de roles en SQL Server

Microsoft SQL Server ofrece varios tipos de roles preconstruidos:

• Fixed server roles — They are called “fixed” server roles because, except for the public role, they cannot be modified or drop
• Fixed database roles
• Aplicación rol — Un principal de base de datos que puede ser utilizado por una aplicación para ejecutarse con su propio conjunto de permisos (deshabilitado por defecto)
• Roles definidos por el usuario (a partir de SQL Server 2012) — Solo se pueden agregar permisos a nivel de servidor a los roles definidos por el usuario

Dónde encaja el Rol Público

Todas las plataformas de bases de datos vienen con un rol predefinido llamado public, pero la implementación de este rol varía según la plataforma. En SQL Server, el rol public es parte del rol fijo del servidor, y los permisos pueden ser otorgados a, denegados a o revocados de los permisos del rol public de SQL Server.

Cuando se crea un inicio de sesión de SQL Server, se asigna el rol público al inicio de sesión y no se puede revocar. Si al principal del servidor no se le otorgan o deniegan permisos específicos en un objeto protegible, el inicio de sesión heredará automáticamente los permisos para ese objeto que se otorgan al rol público.

Permisos asignados al rol público

Para mantener la seguridad de SQL Server y cumplir con varias regulaciones, incluyendo PCI DSS y HIPAA, necesitas conocer todos los roles a nivel de servidor y base de datos asignados a cada usuario. Revisemos los permisos a nivel de servidor asignados al rol público utilizando una consulta transact-SQL de Management Studio:

      SELECT sp.state_desc as "Permission State", sp.permission_name as "Permission",
sl.name "Principal Name",sp.class_desc AS "Object Class", ep.name "End Point"
FROM sys.server_permissions AS sp
  JOIN sys.server_principals AS sl
    ON sp.grantee_principal_id = sl.principal_id
  LEFT JOIN sys.endpoints AS ep
    ON sp.major_id = ep.endpoint_id
WHERE sl.name = 'public';
      

Como muestra la tabla anterior, solo se asignan cinco permisos a nivel de servidor al rol público. Tenga en cuenta que el permiso VIEW ANY DATABASE no otorga a los usuarios acceso a ningún objeto de la base de datos; solo les permite listar todas las bases de datos en una instancia de SQL Server. Por lo tanto, si crea un nuevo inicio de sesión y no asigna otros roles o permisos, el usuario solo podrá iniciar sesión en la instancia y no podrá hacer nada más.

Permisos cuando a un inicio de sesión de SQL Server se le asigna una base de datos predeterminada

Ahora, vamos a crear un inicio de sesión de SQL Server que utiliza la autenticación SQL asignando una base de datos predeterminada a ese usuario.

      USE [master]
GO
CREATE LOGIN [SQTest] WITH PASSWORD=N'nhggLboBn6SHolSWfipjzO/7GYw8M2RMbCt1LsCTK5M=', DEFAULT_DATABASE=[SBITS], CHECK_EXPIRATION=OFF, CHECK_POLICY=OFF
GO
      

Si iniciamos sesión como ese usuario y listamos todos los permisos a nivel de base de datos para la base de datos predeterminada del usuario SBITS, podemos ver qué permisos tienen. Como se muestra a continuación, el usuario Stealth no tiene ningún permiso en la base de datos SBITS aunque esa sea la base de datos predeterminada del usuario. En otras palabras, el hecho de que se asigne una base de datos de usuario predeterminada a un inicio de sesión de usuario, no significa que el usuario podrá ver los objetos de la base de datos o los datos.

Para verificar esto, podemos usar el siguiente script:

      EXECUTE AS LOGIN= 'SQTest';
GO
USE SBITS
GO
SELECT dp.state_desc AS "Class Description", dp.permission_name AS "Permission Name",
SCHEMA_NAME(ao.schema_id) AS "Schema Name", ao.name AS "Object Name"
FROM sys.database_permissions dp
 LEFT JOIN sys.all_objects ao
  ON dp.major_id = ao.object_id
 JOIN sys.database_principals du
  ON dp.grantee_principal_id = du.principal_id
WHERE du.name = 'TestLoginPerms'
 AND ao.name IS NOT NULL
ORDER BY ao.name;
REVERT
      

Permisos heredados por el rol público en la base de datos maestra

Dado que el inicio de sesión del usuario Stealth forma parte del rol public por defecto, veamos los permisos heredados por el rol public en la base de datos master.

      USE master;
GO
 SELECT sp.state_desc AS "Permission State", sp.permission_name AS "Permission",
 SCHEMA_NAME(ao.schema_id) AS 'Schema', ao.name AS "Object Name"
 FROM sys.database_permissions sp
  LEFT JOIN sys.all_objects ao
     ON sp.major_id = ao.object_id
   JOIN sys.database_principals dp
     ON sp.grantee_principal_id = dp.principal_id
 WHERE dp.name = 'public'
 AND ao.name IS NOT NULL
 ORDER BY ao.name
      

In SQL Server 2016, there are 2,089 permissions stored in the master database granted to the public role. While it might seem daunting, they are all SELECT permissions and do not allow the user Stealth to make any changes in the master database. However, it is good practice to revoke some of the permissions based on the security policies in your organization. However, exercise caution while revoking them because some are required by users for normal operations in certain circumstances.

Simplificando la revisión y gestión de roles

En lugar de recurrir a complejos scripts personalizados para descubrir los problemas relacionados con el rol público en una instancia a la vez, considere usar Netwrix Access Analyzer. Esta plataforma de gobernanza de acceso a datos puede enumerar todos los roles y privilegios de SQL Server, incluyendo los roles públicos de SQL Server y los roles de base de datos pública de SQL Server, y producir informes detallados de derechos de forma predeterminada. Proporciona una vista integral del rol público a través de todos los SQL Servers en su empresa y le ayuda a remediar cualquier problema con solo hacer clic en un botón.

Mejores prácticas para el rol público en SQL Server

Recomendamos las siguientes mejores prácticas en lo que respecta al rol público en SQL Server:

• No otorgue privilegios adicionales al rol público fuera de los privilegios predeterminados, bajo ninguna circunstancia. Si es necesario, haga uso de un rol definido por el usuario.
• No modifique los permisos a nivel de servidor del rol público, ya que hacerlo puede impedir que los usuarios se conecten a la base de datos.
• Revise los permisos públicos cada vez que actualice su SQL Server ya que Microsoft a menudo realiza cambios en el rol público.

Preguntas frecuentes

¿Qué es el rol de base de datos pública?

Los permisos otorgados al rol de base de datos público son heredados por cada usuario de la base de datos.

¿Qué permisos tiene el rol público en SQL Server?

Cada inicio de sesión de SQL Server pertenece al rol de servidor público. Cuando a un principal de servidor no se le han otorgado o denegado permisos específicos en un objeto protegible, el usuario hereda los permisos otorgados a ese objeto para el rol público.