Compreendendo o contexto de execução
O contexto de execução é determinado pelo usuário ou logon conectado à sessão ou executando (chamando) um módulo. Ele estabelece a identidade na qual são verificadas permissões para executar instruções ou ações. O contexto de execução é representado por um par de tokens de segurança: um token de logon e um token de usuário. Os tokens identificam as entidades primárias e secundários nas quais as permissões são verificadas, e a fonte usada para autenticar o token. Uma logon que se conecta a uma instância do SQL Server tem um token de logon e um ou mais tokens de usuário, dependendo do número de bancos de dados aos quais a conta tem acesso.
Tokens de segurança de usuário e logon
Um token de segurança para um usuário ou logon contém o seguinte:
Uma entidade de servidor ou banco de dados como a identidade primária
Uma ou mais entidades como identidades secundárias
Nenhum ou mais autenticadores
Os privilégios e as permissões das identidades primárias e secundárias
Entidades são os indivíduos, grupos e processos que podem solicitar recursos do SQL Server. Entidades são categorizadas pelos seus escopos de influência: nível do Windows, nível do SQL Server ou nível do banco de dados. Para obter mais informações, consulte Entidades (Mecanismo de Banco de Dados).
Autenticadores são entidades, certificados ou chaves assimétricas que atestam a autenticidade do token. Freqüentemente, o autenticador de um token é a instância do SQL Server. Para obter mais informações sobre autenticadores, consulte Estendendo representação de banco de dados com EXECUTE AS. Para obter mais informações sobre certificados e chaves assimétricas, consulte Hierarquia de criptografia.
Um token de logon é válido na instância do SQL Server. Ele contém as identidades primárias e secundárias nas quais são verificadas as permissões de nível de servidor e de nível de banco de dados associadas com essas identidades. A identidade primária é o próprio logon. A identidade secundária inclui permissões herdadas de funções e grupos.
Um token de usuário só é válido para um banco de dados específico. Ele contém as identidades primárias e secundárias nas quais são verificadas as permissões de nível de banco de dados. A identidade primária é o próprio usuário do banco de dados. A identidade secundária inclui permissões herdadas de funções de banco de dados. Os tokens de usuário não contêm associações de função de servidor e não honram as permissões de nível de servidor concedidas às identidades no token, incluindo aquelas concedidas à função de nível de servidor public.
Se um logon ou conta de usuário do SQL Server forem criados explicitamente, o logon ou a identificação do usuário dessa conta serão usados como identidade primária no token de logon ou usuário. Quando uma entidade tem acesso implícito a uma instância do SQL Server ou acesso a um banco de dados através das permissões CONTROL SERVER, a identidade primária no token de logon é a função pública padrão. A identidade primária no token de usuário é public.
.gif "Observação importante") Importante |
|---|
Os membros da função de servidor fixa sysadmin sempre têm dbo como a identidade primária do token de usuário. |
Exemplo de token de logon
Mary tem um logon do SQL Server que está mapeado para sua conta do Windows MyDomain\Mary. Para exibir informações sobre o token de logon criado para ela, Mary executa esta instrução:
SELECT principal_id, sid, name, type, usage FROM sys.login_token;
GO
O conjunto de resultados pode ser semelhante a:
principal_id sid name type usage
------------ ----------- ------------- -------------- -------------
261 0x583EA MyDomain\Mary WINDOWS LOGIN GRANT OR DENY
2 0x02 public SERVER ROLE GRANT OR DENY
(2 row(s) affected)
O conjunto de resultados mostra que a conta do Windows de Mary é a identidade primária de seu token de logon. A identidade_principal criada quando a conta de logon foi criada é usada como a identidade_principal primária no token de logon. A função public é listada como uma identidade secundária, porque Mary é membro daquela função padrão. Se Mary fosse um membro de outras funções de nível de servidor, elas também seriam listadas como identidades secundárias. No momento que o logon foi criado, a conta do Windows de Mary foi validada pela instância do SQL Server. Então, quando Mary fizer logon na instância do SQL Server, a instância será o autenticador do token de logon dela. Como a instância do SQL Server é o autenticador do token de logon de Mary, um autenticador, como uma entidade, um certificado ou uma chave assimétrica, não é retornado na consulta.
Exemplo de token de usuário
Mary tem um token de usuário para cada banco de dados ao qual ela tem acesso. Neste primeiro exemplo, Mary está conectada ao banco de dados mestre. Para exibir informações sobre o token de usuário criado para ela no banco de dados mestre, Mary executa esta instrução:
SELECT principal_id, sid, name, type, usage FROM sys.user_token;
GO
O conjunto de resultados pode ser semelhante a:
principal_id sid name type usage
------------ ----------- ------------- -------------- -------------
2 NULL guest SQL USER GRANT OR DENY
0 NULL public ROLE GRANT OR DENY
(2 row(s) affected)
O conjunto de resultados mostra que Mary não é uma usuária explícita no banco de dados mestre, mas, pelo contrário, tem acesso através da conta de convidado. A identidade primária de seu token de usuário é o usuário convidado. A função public é listada como uma identidade secundária, porque o convidado é membro daquela função padrão. O token de usuário de Mary no banco de dados mestre contém todos os privilégios de nível de banco de dados e as permissões do usuário convidado e da função public.
No exemplo seguinte, uma conta de usuário explícita para Mary foi criada no banco de dados Vendas. Adicionalmente, ela foi adicionada à função de banco de dados fixa db_ddladmin daquele banco de dados. Com Sales como o banco de dados atual, Mary executa SELECT * FROM sys.user_token novamente.
O conjunto de resultados pode ser semelhante a:
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
Esse conjunto de resultados reflete o token de usuário criado para Mary no banco de dados Sales. Como Mary foi explicitamente adicionada como um usuário no banco de dados Sales, ela é listada como a identidade primária. As duas funções das quais ela é membro são listadas como identidades secundárias. O autenticador do token de usuário de Mary é a instância do SQL Server.
Alternando o contexto de execução
No SQL Server, o contexto de execução de uma sessão pode ser explicitamente alterado especificando-se um nome de usuário ou de logon em uma instrução EXECUTE AS. O contexto de execução de um módulo, como um procedimento armazenado, um gatilho ou uma função definida pelo usuário, pode ser implicitamente alterado especificando um nome de logon ou usuário em uma cláusula EXECUTE AS na definição do módulo. Quando o contexto de execução é alternado para outro usuário ou logon, o SQL Server verifica as permissões nos tokens de logon e usuário daquela conta. Essencialmente, essa conta é representada pela duração da sessão ou execução do módulo. Para obter mais informações, consulte Compreendendo alternância de contexto.
Consulte também