Permisos: GRANT, DENY, REVOKE
Se aplica a: Azure Synapse Analytics Analytics Platform System (PDW) Punto de conexión de análisis SQL en Microsoft Fabric Almacenamiento 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.
Importante
Si la entidad de seguridad dispone del permiso especificado sin la opción GRANT, se revocará el permiso.
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.
Nota:
La mayoría de los roles fijos de servidor no están disponibles en esta versión. Use en su lugar roles de base de datos definidos por el usuario. Los inicios de sesión no se pueden agregar al rol fijo de servidor sysadmin. La concesión del permiso CONTROL SERVER es similar a la pertenencia al rol fijo de servidor sysadmin.
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];