Búsqueda de sitios web

Función pública en SQL Server

Las funciones de la base de datos son similares a los grupos de Windows: en lugar de revocar u otorgar acceso a cada usuario por separado, los administradores administran el acceso otorgando o revocando permisos de las funciones y cambiando la membresía de la función. El uso de roles facilita la concesión y revocación precisa de privilegios para los usuarios de bases de datos. Y dado que varios usuarios pueden ser miembros de una función de base de datos SQL, puede administrar fácilmente los derechos de un grupo completo de usuarios a la vez.

En esta publicación, explicamos la función pública en Microsoft SQL Server y algunas de las mejores prácticas relacionadas con ella. (Aquí utilizamos deliberadamente letras minúsculas, ya que así es como se escribe la función pública 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 prediseñados:

  • Funciones de servidor fijas : se denominan funciones de servidor "fijas" porque, excepto la función pública, no se pueden modificar ni eliminar.
  • Funciones de base de datos fijas
  • Rol de aplicación: entidad principal de base de datos que una aplicación puede utilizar para ejecutarse con su propio conjunto de permisos (deshabilitado de forma predeterminada).
  • 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 papel público

Todas las plataformas de bases de datos vienen con una función predefinida llamada pública, pero la implementación de esta función varía según la plataforma. En SQL Server, la función pública es parte de la función fija del servidor y se pueden otorgar, denegar o revocar permisos de la función pública de SQL Server.

Cuando se crea un inicio de sesión de SQL Server, la función pública se asigna al inicio de sesión y no se puede revocar. Si al servidor principal no se le otorgan o deniegan permisos específicos sobre un objeto asegurable, el inicio de sesión heredará automáticamente los permisos para ese objeto que se otorgan a la función pública.

Permisos asignados al rol público

Para mantener la seguridad de SQL Server y cumplir con muchas regulaciones, incluidas PCI DSS e HIPAA, necesita 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 mediante 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 a la función pública. Tenga en cuenta que el permiso VER CUALQUIER BASE DE DATOS no otorga a los usuarios acceso a ningún objeto de la base de datos; solo les permite enumerar 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, creemos un inicio de sesión de SQL Server que utilice 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 enumeramos todos los permisos a nivel de base de datos para la base de datos SBITS predeterminada del usuario, podemos ver qué permisos tiene. 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 o datos de la base de 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 la función pública en la base de datos maestra

Dado que el inicio de sesión del usuario Stealth es parte de la función pública de forma predeterminada, veamos los permisos heredados por la función pública en la base de datos maestra.

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

En SQL Server 2016, hay 2089 permisos almacenados en la base de datos maestra otorgados al rol público. Si bien puede parecer desalentador, todos son permisos SELECT y no permiten al usuario Stealth realizar ningún cambio en la base de datos maestra. Sin embargo, es una buena práctica revocar algunos de los permisos según las políticas de seguridad de su organización. Sin embargo, tenga cuidado al revocarlos porque los usuarios requieren algunos para operaciones normales en determinadas circunstancias.

Simplificación de la revisión y gestión de roles

En lugar de recurrir a scripts personalizados complejos para resolver los problemas relacionados con la función pública en una instancia a la vez, considere usar StealthAUDIT. Esta plataforma de gobernanza de acceso a datos puede enumerar todos los roles y privilegios de SQL Server, incluidos los roles públicos de SQL Server y los roles de bases de datos públicas de SQL Server, y producir informes de derechos detallados listos para usar. Proporciona una vista de panel único de la función pública en todos los servidores SQL de su empresa y le ayuda a solucionar cualquier problema con solo hacer clic en un botón.

Mejores prácticas para la función pública en SQL Server

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

  • No otorgue ningún privilegio adicional a la función pública fuera de los privilegios predeterminados, bajo ninguna circunstancia. Si es necesario, utilice un rol definido por el usuario.
  • No modifique los permisos a nivel de servidor para la función pública porque 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 suele realizar cambios en la función pública.

Preguntas más frecuentes

¿Cuál es la función de la base de datos pública?

Cada usuario de la base de datos hereda los permisos otorgados a la función de base de datos pública.

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

Cada inicio de sesión de SQL Server pertenece a la función de servidor público. Cuando a una entidad principal de servidor no se le han otorgado o denegado permisos específicos sobre un objeto asegurable, el usuario hereda los permisos otorgados sobre ese objeto a la función pública.

Artículos relacionados