Descripción del contexto de ejecución
El contexto de ejecución está determinado por el usuario o el inicio de sesión que está conectado a la sesión o que está ejecutando (llamando) un módulo. Establece la identidad para la que se comprueban los permisos para ejecutar instrucciones o realizar acciones. El contexto de ejecución está representado por un par de tokens de seguridad: un token de inicio de sesión y un token de usuario. Los tokens identifican las entidades de seguridad primaria y secundaria para las que se comprueban los permisos y el origen utilizado para autenticar el token. Un inicio de sesión que se conecta a una instancia de SQL Server tiene un token de inicio de sesión y uno o más tokens de usuario en función del número de bases de datos a la que tiene acceso la cuenta.
Tokens de seguridad de usuario e inicio de sesión
Un token de seguridad para un usuario o un inicio de sesión está formado por:
Una entidad de seguridad de servidor o base de datos como identidad primaria
Una o varias entidades de seguridad como identidades secundarias
Cero o más autenticadores
Los privilegios y permisos de las identidades primaria y secundaria
Las entidades de seguridad son los individuos, grupos y procesos que pueden solicitar los recursos de SQL Server. Las entidades de seguridad se clasifican por su ámbito de influencia: nivel de Windows, nivel de SQL Server o nivel de base de datos. Para obtener más información, vea Entidades de seguridad (motor de base de datos).
Los autenticadores son entidades de seguridad, certificados o claves asimétricas que avalan la autenticidad del token. A menudo, el autenticador de un token es la instancia de SQL Server. Para obtener más información acerca de los autenticadores, vea Extender la suplantación de la base de datos mediante EXECUTE AS. Para obtener más información acerca de los certificados y las claves asimétricas, vea Jerarquía de cifrado.
Un token de inicio de sesión tiene validez en toda la instancia de SQL Server. Contiene las identidades primaria y secundaria para las que se comprueban los permisos de nivel de servidor y cualquier permiso de nivel de base de datos asociado a estas identidades. La identidad primaria es el propio inicio de sesión. La identidad secundaria incluye permisos heredados de funciones y grupos.
Un token de usuario sólo es válido para una base de datos específica. Contiene las identidades primaria y secundaria para las que se comprueban los permisos de nivel de base de datos. La identidad primaria es el propio usuario de base de datos. La identidad secundaria incluye permisos heredados de funciones de bases de datos. Los tokens de usuario no contienen miembros de función de servidor y no respetan los permisos de nivel de servidor para las identidades del token incluidas las que se conceden a la función public de nivel de servidor.
Si se crea explícitamente una cuenta de inicio de sesión o usuario de SQL Server, el Id. de inicio de sesión o usuario creado para esa cuenta se utiliza como la identidad primaria en el token de inicio de sesión o usuario. Cuando una entidad de seguridad tiene acceso implícito a una instancia de SQL Server o acceso a una base de datos mediante los permisos CONTROL SERVER, la identidad primaria del token de inicio de sesión es la función pública predeterminada. La identidad primaria del token de usuario es public.
.gif "Nota importante") Importante |
|---|
Los miembros de la función fija de servidor sysadmin siempre utilizan dbo como identidad primaria de su token de usuario. |
Ejemplo de token de inicio de sesión
Mary tiene un inicio de sesión de SQL Server que está asignado a su cuenta de usuario MyDomain\Mary de Windows. Para ver la información sobre el token de inicio de sesión creado para ella, Mary ejecuta esta instrucción:
SELECT principal_id, sid, name, type, usage FROM sys.login_token;
GO
El conjunto de resultados es similar al siguiente:
principal_id sid name type usage
------------ ----------- ------------- -------------- -------------
261 0x583EA MyDomain\Mary WINDOWS LOGIN GRANT OR DENY
2 0x02 public SERVER ROLE GRANT OR DENY
(2 filas afectadas)
El conjunto de resultados muestra que la cuenta de Windows de Mary es la identidad primaria de su token de inicio de sesión. El principal_id generado al crear su cuenta de inicio de sesión se utiliza como el principal_id primario en el token de inicio de sesión. La función public se incluye como identidad secundaria porque Mary es miembro de dicha función predeterminada. Si Mary fuese miembro de otras funciones de servidor, también aparecerían como identidades secundarias. Al crear el inicio de sesión, su cuenta de Windows fue validada por la instancia de SQL Server. Por lo tanto, cuando Mary inicia sesión en la instancia de SQL Server, la instancia es el autenticador de su token de inicio de sesión. Puesto que la instancia de SQL Server es el autenticador del token de inicio de sesión de Mary, en la consulta no se devuelve un autenticador, como pueda ser una entidad de seguridad, un certificado o una clave asimétrica.
Ejemplo de token de usuario
Mary tiene un token de usuario para cada base de datos a la que tiene acceso. En este primer ejemplo, Mary está conectada a la base de datos maestra. Para ver la información sobre el token de usuario creado para ella en la base de datos maestra, Mary ejecuta esta instrucción:
SELECT principal_id, sid, name, type, usage FROM sys.user_token;
GO
El conjunto de resultados es similar al siguiente:
principal_id sid name type usage
------------ ----------- ------------- -------------- -------------
2 NULL guest SQL USER GRANT OR DENY
0 NULL public ROLE GRANT OR DENY
(2 filas afectadas)
El conjunto de resultados muestra que Mary no es un usuario explícito en la base de datos maestra, pero en cambio tiene acceso a través de la cuenta guest. La identidad primaria de su token de usuario es el usuario guest. La función public se incluye como identidad secundaria porque guest es miembro de dicha función predeterminada. El token de usuario para Mary en la base de datos maestra contiene todos los permisos y privilegios del nivel de base de datos para el usuario guest y la función public.
En el siguiente ejemplo se ha creado una cuenta de usuario explícita para Mary en la base de datos Sales. Además, ha sido agregada a la función fija de base de datos db_ddladmin para dicha base de datos. Con Sales como la base de datos actual, Mary vuelve a ejecutar SELECT * FROM sys.user_token.
El conjunto de resultados es similar al siguiente:
principal_id sid name type usage
------------ ----------- ------------- -------------- -------------
5 0x36CC4BBD1 Mary SQL USER GRANT OR DENY
0 NULL public ROLE GRANT OR DENY
16387 NULL db_ddladmin ROLE GRANT OR DENY
Este conjunto de resultados refleja el token de usuario creado para Mary en la base de datos Sales. Puesto que Mary fue agregada explícitamente como usuario a la base de datos Sales, aparece como identidad primaria. Las dos funciones de las que es miembro aparecen como identidades secundarias. El autenticador del token de usuario de Mary es la instancia de SQL Server.
Cambio del contexto de ejecución
En SQL Server, el contexto de ejecución de una sesión puede cambiarse explícitamente mediante la especificación de un nombre de usuario o inicio de sesión en una instrucción EXECUTE AS. El contexto de ejecución de un módulo como, por ejemplo, un procedimiento almacenado, un desencadenador o una función definida por el usuario, puede cambiarse implícitamente mediante la especificación de un nombre de usuario o inicio de sesión en una cláusula EXECUTE AS en la definición del módulo. Cuando el contexto de ejecución cambia a otro usuario o inicio de sesión, SQL Server comprueba los permisos para los tokens de inicio de sesión y usuario de la cuenta. Básicamente, esa cuenta se suplanta durante el transcurso de la sesión o ejecución del módulo. Para obtener más información, vea Descripción del cambio de contexto.