Permisos (motor de base de datos)

Se aplica a:SQL ServerAzure SQL DatabaseInstancia administrada de Azure SQLAzure Synapse AnalyticsAnalytics Platform System (PDW)Punto de conexión de SQL Analytics en Microsoft FabricAlmacén en Microsoft FabricBase de datos SQL en Microsoft Fabric

Cada protegible de SQL Server tiene permisos asociados que se pueden conceder a las entidades de seguridad. Los permisos de se administran en el nivel de servidor asignados a los inicios de sesión y roles de servidor, y en el nivel de base de datos asignados a usuarios de base de datos y roles base de datos. El modelo para Azure SQL Database tiene el mismo sistema para los permisos de base de datos, pero los permisos de nivel de servidor no están disponibles. Este artículo contiene una lista completa de los permisos. Para obtener una implementación típica de los permisos, consulte Introducción a los permisos del motor de base de datos.

El número total de permisos para SQL Server 2022 (16.x) es 292. Azure SQL Database expone 292 permisos. La mayoría de los permisos se aplica a todas las plataformas, pero otros no. Por ejemplo, no se puede conceder permisos de nivel de servidor en Azure SQL Database, y algunos permisos solo tienen sentido en Azure SQL Database. Con la nueva versión se van a implementar nuevos permisos gradualmente. SQL Server 2019 (15.x) expone 248 permisos. SQL Server 2017 (14.x) expone 238 permisos. SQL Server 2016 (13.x) expone 230 permisos. SQL Server 2014 (12.x) expone 219 permisos. SQL Server 2012 (11.x) expone 214 permisos. SQL Server 2008 R2 (10.50.x) expone 195 permisos. El artículo sys.fn_builtin_permissions especifica los permisos de las últimas versiones que son nuevos.

En SQL Database en Microsoft Fabric, solo se admiten roles y usuarios de nivel de base de datos. Los inicios de sesión, los roles y la sa cuenta de nivel de servidor no están disponibles. En la base de datos SQL de Microsoft Fabric, el identificador de Entra de Microsoft para los usuarios de la base de datos es el único método de autenticación admitido. Para obtener más información, consulte Autorización en la base de datos SQL en Microsoft Fabric.

Una vez que entienda los permisos necesarios, puede aplicar permisos de nivel de servidor a inicios de sesión o roles de servidor, y permisos de nivel de base de datos a usuarios o roles de base de datos mediante las instrucciones GRANT, REVOKE y DENY. Por ejemplo:

GRANT SELECT ON SCHEMA::HumanResources TO role_HumanResourcesDept;
REVOKE SELECT ON SCHEMA::HumanResources TO role_HumanResourcesDept;

Para obtener sugerencias sobre cómo planear un sistema de permisos, consulte Introducción a los permisos del motor de base de datos.

Convenciones de nomenclatura de permisos

A continuación se describen las convenciones generales que se siguen en la nomenclatura de permisos:

• CONTROL

  Confiere al receptor del permiso capacidades relacionadas con la propiedad. El receptor del permiso dispone de hecho de todos los permisos definidos para el elemento protegible. Una entidad de seguridad a la que se le haya concedido el permiso CONTROL también puede conceder permisos para el elemento protegible. Como el modelo de seguridad de SQL Server es jerárquico, el permiso CONTROL de un determinado ámbito incluye implícitamente el mismo permiso CONTROL para todos los elementos protegibles que abarca dicho ámbito. Por ejemplo, el permiso CONTROL en una base de datos implica todos los permisos de la base de datos, todos los permisos en todos los ensamblados y todos los esquemas de la misma, así como todos los permisos en los objetos de todos los esquemas que incluye la base de datos.

• ALTER

  Confiere la posibilidad de cambiar las propiedades, excepto la propiedad, de un elemento protegible determinado. Cuando se concede para un ámbito, ALTER también confiere la posibilidad de modificar, crear o quitar cualquier elemento protegible que esté contenido en ese ámbito. Por ejemplo, el permiso ALTER en un esquema incluye la posibilidad de crear, modificar y quitar objetos del esquema.

• ALTER ANY <Server Securable>, donde Server Securable puede ser cualquier elemento protegible del servidor.

  Confiere la posibilidad de crear, modificar o quitar instancias individuales del Protegible del servidor. Por ejemplo, ALTER ANY LOGIN concede la capacidad de crear, modificar o quitar cualquier inicio de sesión en la instancia.

• ALTER ANY <Database Securable>, donde Database Securable puede ser cualquier elemento protegible en el nivel de base de datos.

  Confiere la posibilidad de crear (CREATE), modificar (ALTER) o quitar (DROP) instancias individuales del Protegible de la base de datos. Por ejemplo, ALTER ANY SCHEMA concede la capacidad de crear, modificar o quitar cualquier esquema de la base de datos.

• ASUMIR LA RESPONSABILIDAD

  Permite al receptor del permiso tomar propiedad del elemento protegible para el que se concede este permiso.

• IMPERSONATE <Inicio de sesión>

  Permite al receptor suplantar el inicio de sesión.

• IMPERSONATE <Usuario>

  Permite al receptor suplantar al usuario.

• CREATE <Server Securable>

  Confiere al receptor la posibilidad de crear el Protegible del servidor.

• CREATE <Database Securable>

  Confiere al receptor la posibilidad de crear el Protegible de la base de datos.

• CREATE <Elemento protegible contenido en el esquema>

  Confiere la posibilidad de crear el elemento protegible contenido en el esquema. No obstante, para crear el elemento protegible en un esquema concreto se requiere el permiso ALTER en el esquema.

• VIEW DEFINICIÓN

  Permite al receptor obtener acceso a los metadatos.

• REFERENCES

  El permiso REFERENCES es necesario en una tabla para crear una restricción FOREIGN KEY que hace referencia a esa tabla.

  El permiso REFERENCES es necesario en un objeto para crear un FUNCTION o VIEW con la cláusula WITH SCHEMABINDING que hace referencia a dicho objeto.

Gráfico de los permisos de SQL Server

La siguiente imagen muestra los permisos y sus relaciones entre sí. Algunos de los permisos de nivel superior (como CONTROL SERVER) se muestran varias veces. En este artículo, el póster es demasiado pequeño para leerlo. Puede descargar el Póster de permisos del motor de base de datos a tamaño completo en formato PDF.

Permisos aplicables a elementos protegibles específicos

En la siguiente tabla se enumeran los principales tipos de permisos y los tipos de elementos protegibles a los que se pueden aplicar.

Permisos de SQL Server

La tabla siguiente contiene una lista completa de los permisos de SQL Server. Los permisos de Azure SQL Database solo están disponibles para elementos protegibles de base que se admiten. No se pueden conceder permisos de nivel de servidor en Azure SQL Database; sin embargo, en algunos casos los permisos de base de datos están disponibles en su lugar.

Nuevos permisos granulares agregados a SQL Server 2022

Los permisos siguientes se agregan a SQL Server 2022:

• Se han agregado 10 nuevos permisos para permitir el acceso a los metadatos del sistema.

• Se han agregado 18 nuevos permisos para eventos extendidos.

• Se han agregado 9 nuevos permisos con respecto a los objetos relacionados con la seguridad.

• Se han agregado 4 permisos para el libro de contabilidad.

• 3 permisos adicionales de base de datos.

Para obtener más información, consulte Nuevos permisos granulares para SQL Server 2022 y Azure SQL para mejorar la adhesión a PoLP.

Acceso a los permisos de metadatos del sistema

Nivel de servidor:

• VIEW CUALQUIER DEFINICIÓN DE SEGURIDAD
• VIEW CUALQUIER DEFINICIÓN DE RENDIMIENTO
• VIEW ESTADO DE SEGURIDAD DEL SERVIDOR
• VIEW ESTADO DE RENDIMIENTO DEL SERVIDOR
• VIEW CUALQUIER DEFINICIÓN PROTEGIDA CRIPTOGRÁFICAMENTE

Nivel de base de datos:

• VIEW DATABASE ESTADO DE SEGURIDAD
• VIEW DATABASE ESTADO DE RENDIMIENTO
• VIEW DEFINICIÓN DE SEGURIDAD
• VIEW DEFINICIÓN DE RENDIMIENTO
• VIEW DEFINICIÓN PROTEGIDA CRIPTOGRÁFICAMENTE

Sesiones de eventos extendidos

Nivel de servidor:

• CREA CUALQUIER EVENT SESSION
• SOLTAR CUALQUIERA EVENT SESSION
• Modificar cualquier opción de EVENT SESSION
• ALTER ANY EVENT SESSION ADD EVENT
• ALTER ANY EVENT SESSION DROP EVENT
• MODIFICAR CUALQUIER EVENT SESSION HABILITAR
• MODIFICAR CUALQUIER EVENT SESSION DESHABILITAR
• MODIFICAR CUALQUIER EVENT SESSION DESTINO DE ADICIÓN
• ALTER ANY EVENT SESSION DROP TARGET

Todos estos permisos están bajo el mismo permiso primario: ALTER ANY EVENT SESSION

Nivel de base de datos:

• CREA CUALQUIER DATABASEEVENT SESSION
• Soltar cualquier DATABASEEVENT SESSION
• MODIFICAR CUALQUIER OPCIÓN DATABASEEVENT SESSION
• ALTER ANY DATABASEEVENT SESSION ADD EVENT
• ALTER ANY DATABASEEVENT SESSION DROP EVENT
• ALTER ANY DATABASEEVENT SESSION HABILITAR
• ALTER ANY DATABASEEVENT SESSION DESHABILITAR
• MODIFICAR CUALQUIER DATABASEEVENT SESSION AGREGAR DESTINO
• MODIFICAR CUALQUIER DATABASEEVENT SESSION DESTINO DE DROP

Todos estos permisos están bajo el mismo permiso primario: ALTER ANY DATABASEEVENT SESSION

Permisos de objetos relacionados con la seguridad

• CONTROL (CREDENTIAL)
• CREATE LOGIN
• CREATE USER
• REFERENCIAS (CREDENTIAL)
• DESENMASCARAR (OBJECTO)
• DESENMASCARAR (SCHEMA)
• VIEW CUALQUIER REGISTRO DE ERRORES
• VIEW AUDITORÍA DE SEGURIDAD DEL SERVIDOR
• VIEW DATABASE AUDITORÍA DE SEGURIDAD

Permisos de libro de contabilidad

• ALTER LEDGER
• ALTERAR CONFIGURACIÓN DEL LIBRO MAYOR
• Habilitar Ledger
• VIEW CONTENIDO DEL LIBRO DE CONTABILIDAD

Otros permisos de base de datos

• ALTERAR CUALQUIER TRABAJO EXTERNO
• ALTERAR CUALQUIER FLUJO EXTERNO
• EJECUTAR CUALQUIER EXTERNO ENDPOINT

Resumen del algoritmo de comprobación de permiso

Comprobar los permisos puede ser complejo. El algoritmo de comprobación de permiso incluye la superposición de la pertenencia a grupos y el encadenamiento de propiedad, tanto el permiso explícito como el implícito, y puede ser afectado por los permisos en las clases protegibles y que contienen la entidad protegible. El proceso general del algoritmo es reunir todos los permisos pertinentes. Si no se encuentra ningún bloqueo DENY , el algoritmo busca un GRANT que proporcione acceso suficiente. El algoritmo contiene tres elementos esenciales, el contexto de seguridad, el espacio del permisoy el permiso necesario.

• Contexto de seguridad

  Es el grupo de entidades de seguridad que aportan los permisos para la comprobación de acceso. Estos son permisos relacionados con el inicio de sesión o usuario actual, a menos que el contexto de seguridad se haya cambiado a otro inicio de sesión o usuario mediante la EXECUTE AS instrucción . El contexto de seguridad incluye las entidades de seguridad siguientes:

  • Inicio de sesión

  • El usuario

  • Pertenecientes al rol

  • Pertenecientes al grupo Windows

  • Si se utiliza la firma de módulo, cualquier cuenta de inicio de sesión o de usuario da cuenta del certificado utilizado para firmar el módulo que el usuario está ejecutando actualmente, así como de los pertenecientes al rol asociados de ese entidad de seguridad.

• Área de permisos

  Es la entidad protegible y todas las clases protegibles que contiene la entidad protegible. Por ejemplo, una tabla (una entidad protegible) está contenida en la clase de esquema protegible y en la clase de base de datos protegible. El acceso puede verse afectado por permisos de nivel de tabla, esquema, base de datos y servidor. Para obtener más información, vea Jerarquía de permisos (motor de base de datos).

• Permiso necesario

  El tipo de permiso que se necesita. Por ejemplo, INSERT, UPDATE, DELETE, SELECT, EXECUTE, ALTER, CONTROL, etc.

  El acceso puede requerir varios permisos, como en los ejemplos siguientes:

  • Un procedimiento almacenado puede requerir tanto el permiso EXECUTE en el procedimiento almacenado como INSERT permisos en varias tablas a las que hace referencia el procedimiento almacenado.

  • Una vista de administración dinámica puede requerir tanto los permisos VIEW SERVER STATE como SELECT sobre la vista.

Pasos generales del algoritmo

Cuando el algoritmo está determinando si permite el acceso a un elemento protegible, los pasos precisos que utiliza pueden variar, dependiendo de las entidades de seguridad y de los elementos protegibles implicados. Sin embargo, el algoritmo da los siguientes pasos generales:

1. Omite la comprobación del permiso si el inicio de sesión es un miembro del rol fijo de servidor sysadmin o si el usuario es el usuario de dbo en la base de datos actual.

2. Permite el acceso si es aplicable el encadenamiento de propiedad y la comprobación de acceso en el objeto anterior de la cadena pasó la comprobación de seguridad.

3. Agrega las identidades de nivel del servidor, de base de datos y de módulo firmado que se asocian al autor de las llamadas para crear el contexto de seguridad.

4. Para ese contexto de seguridad, reúne todos los permisos que se conceden o deniegan para el espacio del permiso. El permiso puede indicarse explícitamente como GRANT, GRANT WITH GRANT o DENY; o los permisos pueden ser un permiso implícito o de cobertura GRANT o DENY. Por ejemplo, el permiso CONTROL sobre un esquema implica CONTROL sobre una tabla. Asimismo, CONTROL sobre una tabla implica SELECT. Por consiguiente, si se otorgó CONTROL sobre el esquema, se otorgó SELECT sobre la tabla. Si se denegó CONTROL sobre la tabla, también se denegó SELECT sobre ella.

   Note

   Un GRANT de un permiso a nivel de columna anula un DENY a nivel de objeto. Para obtener más información, vea DENY Permisos de objeto.

5. Identifique el permiso requerido.

6. La comprobación del permiso no se realiza correctamente si el permiso requerido es denegado directa o implícitamente a cualquiera de las identidades del contexto de seguridad para los objetos del espacio del permiso.

7. La comprobación de permisos se supera si no se ha denegado el permiso requerido y el permiso requerido contiene un GRANT o un permiso GRANT CON GRANT, ya sea de forma directa o implícita, para cualquiera de las identidades del contexto de seguridad para cualquier objeto del espacio de permisos.

Consideraciones especiales sobre los permisos de nivel de columna

Los permisos de nivel de columna se conceden con la sintaxis <table_name>(<column _name>). Por ejemplo:

GRANT SELECT ON OBJECT::Customer(CustomerName) TO UserJoe;

Un DENY de la tabla queda reemplazado por un GRANT de una columna. Sin embargo, un elemento posterior DENY de la tabla quitará la columna GRANT.

Examples

En los ejemplos de esta sección se muestra cómo se recupera la información sobre permisos.

A. Devolver la lista completa de los permisos que pueden concederse.

La siguiente instrucción devuelve todos los permisos del motor de base de datos mediante la función fn_builtin_permissions. Para obtener más información, consulte sys.fn_builtin_permissions.

SELECT * FROM fn_builtin_permissions(default);
GO

B. Devolver los permisos de una clase de objetos concreta

En el ejemplo siguiente se usa fn_builtin_permissions para ver todos los permisos que están disponibles para una categoría de elemento protegible. El ejemplo devuelve permisos de ensamblados.

SELECT * FROM fn_builtin_permissions('assembly');
GO

C. Devolver los permisos de un objeto concedidos a la entidad de seguridad que se ejecuta

En el ejemplo siguiente se usa fn_my_permissions para devolver una lista de los permisos efectivos que son retenidos por la entidad de seguridad de la llamada sobre un elemento protegible específico. El ejemplo devuelve los permisos de un objeto denominado Orders55. Para obtener más información, consulte sys.fn_my_permissions.

SELECT * FROM fn_my_permissions('Orders55', 'object');
GO

D. Devolver los permisos aplicables a un objeto especificado

El ejemplo siguiente devuelve los permisos aplicables a un objeto denominado Yttrium. Observa que la función integrada OBJECT_ID se utiliza para recuperar el identificador del objeto Yttrium.

SELECT * FROM sys.database_permissions
    WHERE major_id = OBJECT_ID('Yttrium');
GO

Contenido relacionado

• Jerarquía de permisos (motor de base de datos)
• sys.database_permissions (Transact-SQL)