Permisos: GRANT, DENY, REVOKE

Se aplica a:Azure Synapse AnalyticsAnalytics Platform System (PDW)Punto de conexión de análisis SQL en Microsoft FabricAlmacenamiento de Microsoft Fabric

Use las instrucciones GRANT y DENY para conceder o denegar un permiso (como UPDATE) en un elemento protegible (por ejemplo, una base de datos, una tabla, una vista, etc.) a una entidad de seguridad (un inicio de sesión, un usuario de base de datos o un rol de base de datos). Use REVOKE para quitar la concesión o la denegación de un permiso.

Los permisos de nivel de servidor se aplican a los inicios de sesión. Los permisos de nivel de base de datos se aplican a los usuarios de base de datos y roles de base de datos.

Para ver qué permisos se han concedido y denegado, consulte las vistas sys.server_permissions y sys.database_permissions. Los permisos que no se conceden o deniegan explícitamente a una entidad de seguridad se pueden heredar si se dispone de una pertenencia en un rol que tiene permisos. Los permisos de los roles fijos de base de datos no se pueden cambiar y no aparecen en las vistas sys.server_permissions y sys.database_permissions.

• GRANT concede explícitamente uno o varios permisos.

• DENY deniega explícitamente uno o varios permisos a la entidad de seguridad.

• REVOCAR quita los permisos GRANT o DENY existentes.

Convenciones de sintaxis de Transact-SQL

Sintaxis

-- Azure Synapse Analytics and Parallel Data Warehouse and Microsoft Fabric
GRANT   
    <permission> [ ,...n ]  
    [ ON [ <class_type> :: ] securable ]   
    TO principal [ ,...n ]  
    [ WITH GRANT OPTION ]  
[;]  
  
DENY   
    <permission> [ ,...n ]  
    [ ON [ <class_type> :: ] securable ]   
    TO principal [ ,...n ]  
    [ CASCADE ]  
[;]  
  
REVOKE   
    <permission> [ ,...n ]  
    [ ON [ <class_type> :: ] securable ]   
    [ FROM | TO ] principal [ ,...n ]  
    [ CASCADE ]  
[;]  
  
<permission> ::=  
{ see the tables below }  
  
<class_type> ::=  
{  
      LOGIN  
    | DATABASE  
    | OBJECT  
    | ROLE  
    | SCHEMA  
    | USER  
}  

Argumentos

<permission>[ ,...n ]
Uno o varios permisos que se van a conceder, denegar o revocar.

ON [ <class_type> :: ] securable La cláusula ON describe el parámetro protegible en el que se van a conceder, denegar o revocar permisos.

<class_type> Tipo de clase del elemento protegible. Puede ser LOGIN, DATABASE, OBJECT, SCHEMA, ROLE o USER. También se pueden conceder permisos a SERVERclass_type, pero SERVER no se especifica para esos permisos. DATABASE no se especifica si el permiso incluye la palabra DATABASE (por ejemplo, ALTER ANY DATABASE). Si no se especifica class_type y el tipo de permiso no está restringido a la clase de base de datos o servidor, se supone que la clase es OBJECT.

securable
Nombre del inicio de sesión, base de datos, tabla, vista, esquema, procedimiento, rol o usuario en el que se van a conceder, denegar o revocar permisos. El nombre del objeto se puede especificar con las reglas de nomenclatura de tres partes que se describen en Convenciones de sintaxis de Transact-SQL.

TO principal [ , ...n ]
Una o varias entidades de seguridad a las que se van a conceder, denegar o revocar permisos. "Principal" es el nombre de un inicio de sesión, un usuario de base de datos o un rol de base de datos.

FROM principal [ , ...n ]
Una o varias entidades de seguridad cuyos permisos se van a revocar. "Principal" es el nombre de un inicio de sesión, un usuario de base de datos o un rol de base de datos. FROM solo se puede usar con una instrucción REVOKE. TO se puede usar con GRANT, DENY o REVOKE.

WITH GRANT OPTION
Indica que el receptor también podrá conceder el permiso especificado a otras entidades de seguridad.

CASCADE
Indica que el permiso se deniega o revoca para la entidad de seguridad especificada y para el resto de entidades de seguridad a las que esta ha concedido el permiso. Es obligatorio cuando la entidad de seguridad tiene el permiso con GRANT OPTION.

GRANT OPTION FOR
Indica que se revocará la capacidad de conceder el permiso especificado. Se requiere cuando se usa el argumento CASCADE.

Permisos

Para conceder un permiso, el otorgante debe tener el permiso en cuestión con WITH GRANT OPTION, o un permiso superior que implique el permiso que se va a conceder. Los propietarios de objetos pueden conceder permisos para los objetos que poseen. Las entidades de seguridad con permiso CONTROL en un elemento protegible pueden conceder permisos para ese elemento. Los miembros de los roles fijos de base de datos db_owner y db_securityadmin pueden conceder cualquier permiso en la base de datos.

Notas generales

El hecho de denegar o revocar permisos para una entidad de seguridad no afectará a las solicitudes que hayan superado la autorización y se estén ejecutando. Para restringir el acceso de inmediato, debe cancelar las solicitudes activas o terminar las sesiones actuales.

Algunas instrucciones requieren varios permisos. Por ejemplo, la creación de una tabla requiere permisos CREATE TABLE en la base de datos y el permiso ALTER SCHEMA para la tabla que contendrá la tabla.

En ocasiones, Analytics Platform System (PDW) ejecuta procedimientos almacenados para distribuir las acciones del usuario a los nodos de ejecución. Por lo tanto, no se puede denegar el permiso EXECUTE para toda una base de datos. (Por ejemplo, se producirá un error en DENY EXECUTE ON DATABASE::<name> TO <user>;). Como solución alternativa, deniegue el permiso EXECUTE para esquemas de usuario u objetos específicos (procedimientos).

En Microsoft Fabric, actualmente no se puede ejecutar explícitamente CREATE USER. Cuando se ejecuta GRANT o DENY, el usuario se creará automáticamente.

En Microsoft Fabric, los permisos de nivel de servidor no se pueden administrar.

Permisos implícitos y explícitos

Un permiso explícito es un permiso GRANT o DENY concedido a una entidad de seguridad mediante una instrucción GRANT o DENY.

Un permiso implícito es un permiso GRANT o DENY que una entidad de seguridad (inicio de sesión, usuario o rol de base de datos) ha heredado de otro rol de base de datos.

También se puede heredar un permiso implícito de un permiso principal o inclusivo. Por ejemplo, el permiso UPDATE en una tabla puede heredarse si se tiene el permiso UPDATE en el esquema que contiene la tabla o si se tiene el permiso CONTROL en la tabla.

Encadenamiento de propiedad

Cuando varios objetos de base de datos obtienen acceso unos a otros de forma secuencial, la secuencia se denomina cadena. Aunque estas cadenas no existen de manera independiente, cuando SQL Server recorre los eslabones de una cadena, SQL Server evalúa los permisos de los objetos que la componen de manera distinta a si se estuviese obteniendo acceso a los objetos por separado. El encadenamiento de propiedad tiene implicaciones importantes en lo que respecta a la administración de la seguridad. Para más información sobre las cadenas de propiedad, vea Cadenas de propiedad y Tutorial: Cadenas de propiedad y cambio de contexto.

Lista de permisos

Permisos de nivel de servidor

Se pueden conceder, denegar o revocar permisos de nivel de servidor de inicios de sesión.

Permisos que se aplican a los servidores

• CONTROL SERVER

• ADMINISTER BULK OPERATIONS

• ALTER ANY CONNECTION

• ALTER ANY DATABASE

• CREATE ANY DATABASE

• ALTER ANY EXTERNAL DATA SOURCE

• ALTER ANY EXTERNAL FILE FORMAT

• ALTER ANY LOGIN

• ALTER SERVER STATE

• CONNECT SQL

• VIEW ANY DEFINITION

• VIEW ANY DATABASE

• VIEW SERVER STATE

Permisos que se aplican a los inicios de sesión

• CONTROL ON LOGIN

• ALTER ON LOGIN

• IMPERSONATE ON LOGIN

• VIEW DEFINITION

Permisos de nivel de base de datos

Los permisos de nivel de base de datos se pueden conceder, denegar y revocar de usuarios de base de datos y roles de base de datos definidos por el usuario.

Permisos que se aplican a todas las clases de base de datos

• CONTROL

• ALTER

• VIEW DEFINITION

Permisos que se aplican a todas las clases de base de datos, excepto usuarios

• TAKE OWNERSHIP

Permisos que se aplican únicamente a las bases de datos

• ALTER ANY DATABASE

• ALTER ON DATABASE

• ALTER ANY DATASPACE

• ALTER ANY ROLE

• ALTER ANY SCHEMA

• ALTER ANY USER

• BACKUP DATABASE

• CONNECT ON DATABASE

• CREATE PROCEDURE

• CREATE ROLE

• CREATE SCHEMA

• CREATE TABLE

• CREATE VIEW

• SHOWPLAN

Permisos que se aplican únicamente a los usuarios

• IMPERSONATE

Permisos que se aplican a las bases de datos, esquemas y objetos

• ALTER

• Delete

• Ejecute

• INSERT

• SELECT

• UPDATE

• REFERENCES

Para una definición de cada tipo de permiso, vea Permisos (motor de base de datos).

Gráfico de permisos

En este póster se representan gráficamente todos los permisos. Es la manera más fácil de ver la jerarquía anidada de permisos. Por ejemplo, el permiso ALTER LOGIN ON se puede conceder por sí mismo, pero también se incluye si se concede a un inicio de sesión el permiso CONTROL en ese inicio de sesión, o si se concede el permiso ALTER ANY LOGIN a un inicio de sesión.

Permisos predeterminados

En la lista siguiente se describen los permisos predeterminados:

• Cuando se crea un inicio de sesión mediante la instrucción CREATE LOGIN, el nuevo inicio de sesión recibe el permiso CONNECT SQL.

• Todos los inicios de sesión son miembros del rol de servidor público y no se pueden quitar de público.

• Cuando se crea un usuario de base de datos mediante el permiso CREATE USER, el usuario de base de datos recibe el permiso CONNECT en la base de datos.

• Ninguna entidad de seguridad, incluido el rol público, tiene permisos explícitos o implícitos de forma predeterminada.

• Cuando un inicio de sesión o usuario se convierte en el propietario de una base de datos o un objeto, el inicio de sesión o el usuario siempre tiene todos los permisos en la base de datos o el objeto. Los permisos de propiedad no se pueden cambiar y no están visibles como permisos explícitos. Las instrucciones GRANT, DENY y REVOKE no tienen ningún efecto en los propietarios.

• El inicio de sesión sa tiene todos los permisos en el dispositivo. Al igual que sucede con los permisos de propiedad, los permisos sa no se pueden cambiar y no están visibles como permisos explícitos. Las instrucciones GRANT, DENY y REVOKE no tienen ningún efecto en el inicio de sesión sa. No se puede cambiar el nombre del inicio de sesión sa.

• La instrucción USE no requiere permisos. Todas las entidades de seguridad pueden ejecutar la instrucción USE en cualquier base de datos.

Ejemplos: Azure Synapse Analytics y Sistema de la plataforma de análisis (PDW)

A. Conceder un permiso de nivel de servidor a un inicio de sesión

Las dos instrucciones siguientes conceden un permiso de nivel de servidor a un inicio de sesión.

GRANT CONTROL SERVER TO [Ted];  

GRANT ALTER ANY DATABASE TO Mary;  

B. Conceder un permiso de nivel de servidor a un inicio de sesión

En el ejemplo siguiente se concede un permiso de nivel de servidor en un inicio de sesión a una entidad de seguridad de servidor (otro inicio de sesión).

GRANT  VIEW DEFINITION ON LOGIN::Ted TO Mary;  

C. Conceder un permiso de nivel de base de datos a un usuario

En el ejemplo siguiente se concede un permiso de nivel de base de datos en un usuario a una entidad de seguridad de base de datos (otro usuario).

GRANT VIEW DEFINITION ON USER::[Ted] TO Mary;  

D. Conceder, denegar y revocar un permiso de esquema

La siguiente instrucción GRANT concede a Yuen la capacidad de seleccionar datos de cualquier tabla o vista del esquema dbo.

GRANT SELECT ON SCHEMA::dbo TO [Yuen];  

La siguiente instrucción DENY impide que Yuen pueda seleccionar datos de cualquier tabla o vista del esquema dbo. Yuen no puede leer los datos, ni siquiera aunque tenga el permiso de otra manera, por ejemplo, mediante una pertenencia a un rol.

DENY SELECT ON SCHEMA::dbo TO [Yuen];  

La siguiente instrucción REVOKE quita el permiso DENY. Ahora, los permisos explícitos de Yuen son neutros. Yuen puede seleccionar los datos de cualquier tabla mediante otro permiso implícito, como una pertenencia a un rol.

REVOKE SELECT ON SCHEMA::dbo TO [Yuen];  

E. Demostración de la cláusula opcional OBJECT::

Dado que OBJECT es la clase predeterminada para una instrucción de permiso, las dos instrucciones siguientes son iguales. La cláusula OBJECT:: es opcional.

GRANT UPDATE ON OBJECT::dbo.StatusTable TO [Ted];  

GRANT UPDATE ON dbo.StatusTable TO [Ted];