Existem várias instâncias em que queremos verificar a permissão em um protegível para um principal. Antes de prosseguir, vamos ver o que são principais, protegíveis e permissões.
De acordo com a documentação da Microsoft,
- Protegíveis no contexto do SQL Server são recursos específicos aos quais o sistema de autorização do Mecanismo de Banco de Dados do SQL Server controla o acesso. Eles são divididos em três categorias:Servidor, Banco de Dados e Esquema. Em geral, qualquer SQL Server ou objetos de banco de dados podem ser protegíveis.
- Permissões são controles com os quais atribuímos ou negamos determinado nível de acesso a um protegível.
- Diretor é uma entidade que recebe permissão para um protegível. Os principais mais comuns são logins e usuários de banco de dados.
O SQL Server tem uma função de segurança interna HAS_Permis_BY_Name que nos ajudará a saber se um principal identificado tem permissão específica em um determinado protegível ou não. Essa função do sistema retornará 1 se a permissão efetiva for atribuída a esse principal em um determinado protegível e retornará 0 se a permissão efetiva não for atribuída. Você obterá o valor NULL se a permissão efetiva ou a classe protegível não for válida.
A função de sistema HAS_Permis_BY_Name também é muito útil na verificação de permissão para seu login. Mostrarei um processo passo a passo para verificar a permissão específica em um protegível para meu principal e outros principais neste artigo.
A sintaxe T-SQL desta função do sistema é a seguinte:
--T-SQL syntax
HAS_PERMS_BY_NAME (securable, securable_class, permission)
Três parâmetros obrigatórios serão necessários para executar esta função de segurança do SQL Server do sistema.
- Digite o nome do protegível sobre o qual você deseja verificar a permissão. Se um protegível for um servidor em si, você deve usar NULL.
- O segundo parâmetro é securable_class que é o nome da classe. Se não tiver certeza, você pode usar outra função do sistema sys.fn_builtin_permissions para obter a lista completa de classes protegíveis e suas permissões disponíveis.
- O terceiro parâmetro é a permissão onde você precisa inserir a permissão efetiva sobre a qual deseja verificar o protegível especificado.
Agora, deixe-me mostrar todas as classes protegíveis disponíveis executando a função do sistema sys.fn_builtin_permissions. Eu usei DISTINCT para exibir linhas por classe protegível.
--Display all securable_class
SELECT distinct class_desc FROM sys.fn_builtin_permissions(default)Aqui, você pode obter uma lista da classe protegível.
Se você deseja verificar todas as permissões possíveis para qualquer classe protegível, você também pode usar esta função do sistema. Execute a instrução T-SQL abaixo:
--Display each permission for all securable class
SELECT class_desc,permission_name FROM sys.fn_builtin_permissions(default);Podemos ver a lista na imagem abaixo. O class_desc é uma classe protegível e permission_name é um tipo de permissão. Se você não tiver certeza sobre a classe protegível e as permissões a serem verificadas para qualquer protegível, você pode usar esta função do sistema.
HAS_Permis_BY_Name Casos de USO
Mostrarei 5 casos de uso de verificação de várias permissões para meu próprio login na instância do SQL Server e para um login adicional chamado manvendra .
- Verificar permissões de nível de servidor ou instância
- Verificar permissões no nível do banco de dados
- Verificar permissões de nível de objeto
- Verificar permissões de login
- Verifique outras permissões, como catálogo de texto completo, esquema etc.
Vamos começar com o primeiro caso de uso para verificar as permissões no nível da instância.
CASO DE USO 1:verificar o SQL Server ou a permissão no nível da instância
Este caso de uso mostrará como verificar várias permissões para um servidor principal\login. Você pode executar a instrução T-SQL acima usando a função do sistema sys.fn_builtin_permissions. Você pode usar a cláusula WHERE nesta função para listar apenas as permissões de nível de servidor. Aqui, mostrarei as permissões para meu próprio login conectado.
- Ver estado do servidor
- Criar função de servidor
- Conecte qualquer banco de dados
Se você estiver procurando por alguma permissão no nível do servidor, você deve sempre passar NULL como um argumento seguro. Neste exemplo, NULL será protegível como seu nível de servidor e os nomes de permissão acima terão argumento de permissão. Execute a instrução T-SQL abaixo para verificar as permissões no nível do servidor.
--Display server level permission for your own login using which you have established the database connection
SELECT HAS_PERMS_BY_NAME(null, null, 'VIEW SERVER STATE') AS [VIEW SERVER STATE],
HAS_PERMS_BY_NAME(null, null, 'CREATE SERVER ROLE') AS [CREATE SERVER ROLE],
HAS_PERMS_BY_NAME(null, null, 'CONNECT ANY DATABASE') AS [CONNECT ANY DATABASE]A saída é mostrada na imagem abaixo. T-SQL retornou 1 para todas as permissões para meu login. Significa que tenho permissões para todas as três operações. Posso ver o estado do servidor, posso criar uma função de servidor e também posso me conectar a qualquer banco de dados neste servidor ou instância.
Deixe-me mostrar se um login chamado 'manvendra' tem permissões para as 3 operações acima. Usaremos a instrução T-SQL EXECUTE AS LOGIN para verificar o nível de acesso. Certifique-se de ter a permissão IMPERSONATE nesse login para o qual você está verificando as permissões. Execute a mesma instrução T-SQL acima após a instrução EXECUTE AS LOGIN.
--Display server level permission for another login ‘manvendra’
EXECUTE AS LOGIN = ‘manvendra’
GO
SELECT HAS_PERMS_BY_NAME(null, null, 'VIEW SERVER STATE') AS [VIEW SERVER STATE],
HAS_PERMS_BY_NAME(null, null, 'CREATE SERVER ROLE') AS [CREATE SERVER ROLE],
HAS_PERMS_BY_NAME(null, null, 'CONNECT ANY DATABASE') AS [CONNECT ANY DATABASE]Aqui, podemos ver que o login ‘manvendra’ não tem acesso a nenhuma dessas 3 atividades no nível do servidor, pois sua saída retornou 0.
CASO DE USO 2:Verificar permissões no nível do banco de dados
Expliquei como verificar várias permissões para qualquer principal no nível do servidor ou da instância na seção acima. Agora, mostrarei como verificar várias permissões para qualquer principal no nível do banco de dados. Veja a declaração abaixo:
--Display each permission for securable class ‘DATABASE’
SELECT class_desc,permission_name FROM sys.fn_builtin_permissions(default)
WHERE class_desc = ‘DATABASE’Você pode ver que existem 82 permissões disponíveis no nível do banco de dados na captura de tela abaixo.
Eu escolhi as permissões abaixo para verificar se meu login ou um login adicional ‘manvendra’ tem permissão para realizar essas atividades.
- QUALQUER
- CRIAR Tabela
- CRIAR PROCEDIMENTO
- INSERIR
- SELECIONAR
Aqui, protegível será o nome do banco de dados no qual você deseja verificar as permissões, a classe protegível será ‘Banco de dados’ e permissão serão os nomes de permissão acima. Execute a instrução T-SQL abaixo para verificar várias permissões.
--Display few specific permissions for your own connected login on a DATABASE
SELECT HAS_PERMS_BY_NAME(db_name(), 'DATABASE', 'ANY') AS [DB Access],
HAS_PERMS_BY_NAME(db_name(), 'DATABASE', 'CREATE TABLE') AS [CREATE TABLE],
HAS_PERMS_BY_NAME(db_name(), 'DATABASE', 'CREATE PROCEDURE') AS [CREATE PROCEDURE],
HAS_PERMS_BY_NAME(db_name(), 'DATABASE', 'INSERT') AS [INSERT Access],
HAS_PERMS_BY_NAME(db_name(), 'DATABASE', 'SELECT') AS [SELECT Access]A saída retornou 1 para cada permissão. Significa que tenho permissão para realizar todas as atividades acima no contexto atual do banco de dados.
Execute a instrução T-SQL abaixo para verificar as mesmas permissões para login 'manvendra' no contexto do banco de dados atualmente selecionado.
--Display few specific permissions for login ‘manvendra’ on current database
EXECUTE AS LOGIN ='manvendra'
GO
SELECT HAS_PERMS_BY_NAME(db_name(), 'DATABASE', 'ANY') AS [DB Access],
HAS_PERMS_BY_NAME(db_name(), 'DATABASE', 'CREATE TABLE') AS [CREATE TABLE],
HAS_PERMS_BY_NAME(db_name(), 'DATABASE', 'CREATE PROCEDURE') AS [CREATE PROCEDURE],
HAS_PERMS_BY_NAME(db_name(), 'DATABASE', 'INSERT') AS [INSERT Access],
HAS_PERMS_BY_NAME(db_name(), 'DATABASE', 'SELECT') AS [SELECT Access]A saída mostra que o login ‘manvendra’ tem permissões muito limitadas neste banco de dados. Este login só pode se conectar ao banco de dados e o restante das permissões não são permitidas.
Aqui, alterei o contexto do banco de dados e escolhi o banco de dados 'AdventureWorksDW2019-TSQL' como um argumento seguro e executei a instrução abaixo para login 'manvendra'.
--Display few specific permissions for login ‘manvendra’ on database ‘AdventureWorksDW2019-TSQL’
EXECUTE AS LOGIN ='manvendra'
GO
SELECT HAS_PERMS_BY_NAME('AdventureWorksDW2019-TSQL', 'DATABASE', 'ANY') AS [DB Access],
HAS_PERMS_BY_NAME('AdventureWorksDW2019-TSQL', 'DATABASE', 'CREATE TABLE') AS [CREATE TABLE],
HAS_PERMS_BY_NAME('AdventureWorksDW2019-TSQL', 'DATABASE', 'CREATE PROCEDURE') AS [CREATE PROCEDURE],
HAS_PERMS_BY_NAME('AdventureWorksDW2019-TSQL', 'DATABASE', 'INSERT') AS [INSERT Access],
HAS_PERMS_BY_NAME('AdventureWorksDW2019-TSQL', 'DATABASE', 'SELECT') AS [SELECT Access]O mesmo login ‘manvendra’ tem permissão para operações INSERT e SELECT neste banco de dados ‘AdventureWorks2019-TSQL’
Da mesma forma, podemos executar a instrução T-SQL acima para verificar a permissão de bancos de dados distintos para nosso login. A saída mostra que tenho acesso a todas as permissões.
Você pode ir em frente e verificar outras permissões de nível de banco de dados para qualquer principal usando a função de segurança do SQL Server do sistema acima.
CASO DE USO 3:Verifique as permissões do OBJECT-LEVEL
Este caso de uso ilustra o uso de permissões de nível de objeto em um banco de dados. Novamente, você pode executar a instrução T-SQL abaixo para listar todas as permissões disponíveis para a classe protegível ‘OBJECT’. Usei a cláusula WHERE na função do sistema sys.fn_builtin_permissions para exibir a lista de permissões de nível de objeto.
--Check all object level permissions
SELECT class_desc,permission_name FROM sys.fn_builtin_permissions(default)
WHERE class_desc ='OBJECT'Aqui está a lista de permissões para a classe protegível Object.
Agora, vou verificar as permissões abaixo em um objeto específico para qualquer conta de login e ver se essa conta tem acesso para realizar as operações abaixo.
- INSERIR
- SELECIONAR
- EXCLUIR
- VER DEFINIÇÃO
Eu usei um objeto de banco de dados 'dbo.dimAccount' como protegível, OBJECT como uma classe protegível e as permissões acima como argumento de permissão. Execute as instruções abaixo para exibir os detalhes da permissão.
--Check some specific object level permissions for your own login
SELECT HAS_PERMS_BY_NAME('[dbo].[DimAccount]', 'OBJECT', 'INSERT') AS [Insert Permission],
HAS_PERMS_BY_NAME('[dbo].[DimAccount]', 'OBJECT', 'SELECT') AS [Select Permission],
HAS_PERMS_BY_NAME('[dbo].[DimAccount]', 'OBJECT', 'DELETE') AS [DELETE Permission],
HAS_PERMS_BY_NAME('[dbo].[DimAccount]', 'OBJECT', 'VIEW DEFINITION') AS [VIEW DEFINITION Access]
Como sou um administrador de sistema nesta instância, minha conta está retornando 1 para qualquer permissão que estou verificando em qualquer nível. Isso significa que tenho permissões totais, e isso pode ser verificado executando as instruções abaixo também.
Execute a instrução abaixo para verificar as permissões para o login ‘manvendra’.
--Check some specific object level permissions for another login ‘manvendra’
EXECUTE AS USER ='manvendra'
GO
USE [AdventureWorksDW2019-TSQL]
GO
SELECT HAS_PERMS_BY_NAME('[dbo].[DimAccount]', 'OBJECT', 'INSERT') AS [Insert Permission],
HAS_PERMS_BY_NAME('[dbo].[DimAccount]', 'OBJECT', 'SELECT') AS [Select Permission],
HAS_PERMS_BY_NAME('[dbo].[DimAccount]', 'OBJECT', 'DELETE') AS [DELETE Permission],
HAS_PERMS_BY_NAME('[dbo].[DimAccount]', 'OBJECT', 'VIEW DEFINITION') AS [VIEW DEFINITION Access]
Podemos ver que o login ‘manvendra’ tem acesso às permissões INSERT, SELECT e DELETE mas esta conta não tem permissão para VIEW DEFINITION deste objeto no banco de dados ‘AdventureWorksDW2019-TSQL’.
Deixe-me aplicar a operação DENY access to DELETE para esta conta 'manvendra' no objeto 'DimAccount' no banco de dados AdventureWorksDW2019-TSQL. Você pode ver isso na imagem abaixo.
Podemos ver que a saída indica que o login ‘manvendra’ tem acesso apenas às instruções INSERT e SELECT e não tem permissão à instrução DELETE.
Verifique vários níveis de acesso para qualquer login em qualquer objeto de banco de dados usando a função do sistema acima.
CASO DE USO 4:Verificar permissão de login
Este caso de uso ajudará você a entender como verificar várias permissões para logins. Você pode obter todos esses tipos de detalhes usando esta função de segurança do sistema SQL Server HAS_PERMS_BY_NAME.
Podemos listar todas as permissões disponíveis para um login específico executando a instrução T-SQL abaixo.
--List all available permission for securable class ‘LOGIN’
SELECT class_desc, permission_name FROM sys.fn_builtin_permissions(default)
WHERE class_desc ='LOGIN'Abaixo está a lista de nomes de permissão para a classe protegível ‘LOGIN’.
Vou verificar se tenho permissão ALTER ou VIEW DEFINITION no login sa executando as instruções T-SQL abaixo. Eu usei login sa como um argumento protegível, LOGIN como um argumento de classe protegível e ALTER &VIEW DEFINITION como um argumento de permissão nesta função do sistema.
--Check ALTER & VIEW DEFINITION permission on securable sa
SELECT HAS_PERMS_BY_NAME('sa', 'LOGIN', 'ALTER'),
HAS_PERMS_BY_NAME('sa', 'LOGIN', 'VIEW DEFINITION')Como administrador de sistema, terei esses níveis de acesso e a saída também é validada retornando seu valor como 1.
Vamos verificar se o login ‘manvendra’ tem permissão para ALTER ou VIEW definição do login sa.
--Check ALTER & VIEW DEFINITION permission on securable sa for principal ‘manvendra’
EXECUTE AS USER ='manvendra'
GO
SELECT HAS_PERMS_BY_NAME('sa', 'LOGIN', 'ALTER'),
HAS_PERMS_BY_NAME('sa', 'LOGIN', 'VIEW DEFINITION')A saída retornou como zero (0), o que significa que o login ‘manvendra’ não tem permissão para ALTER ou VIEW DEFINITION login sa.
Use esta função do sistema para verificar e entender os níveis de acesso para vários logins.
CASO DE USO 5:verificar outras permissões
Aqui, abordarei algumas outras classes protegíveis como SCHEMA e FULLTEXT CATALOG, ENDPOINT, AVAILABILITY GROUP, etc.
Vamos primeiro listar todas as permissões disponíveis para a classe protegível SCHEMA e FULLTEXT CATALOG executando a instrução abaixo:
--List all available permission for securable class ‘SCHEMA’ & ‘FTCatalog’. FTCatalog is full text catalog.
SELECT class_desc, permission_name FROM sys.fn_builtin_permissions(default)
WHERE class_desc='SCHEMA' OR
class_desc= 'FULLTEXT CATALOG'O próximo passo é identificar qual permissão estamos procurando para verificar nosso principal. Vou verificar as permissões DELETE e ALTER para a classe protegível SCHEMA e a permissão ALTER e VIEW DEFINITION na classe protegível FULLTEXT CATALOG.
Precisamos passar seus respectivos protegíveis como eu passei dbo para a classe protegível SCHEMA e FTCatalog para classe protegível FULLTEXT CATALOG na instrução abaixo.
Execute a instrução T-SQL abaixo para obter permissão para seu logon.
--List below permissions for securable class ‘SCHEMA’ & ‘FTCatalog’.
SELECT HAS_PERMS_BY_NAME('dbo', 'SCHEMA', 'DELETE') AS [Schema Deletion Access],
HAS_PERMS_BY_NAME('dbo', 'SCHEMA', 'ALTER') AS [Schema Alter Access],
HAS_PERMS_BY_NAME('[FTCatalog]', 'FULLTEXT CATALOG', 'ALTER') AS [FTC Alter Access],
HAS_PERMS_BY_NAME('[FTCatalog]', 'FULLTEXT CATALOG', 'VIEW DEFINITION') AS [VIEW DEFINITION]A saída abaixo mostra que o login ‘manvendra’ tem acesso apenas à exclusão do SCHEMA e o restante dos acessos foi negado ou revogado.
Conclusão
Expliquei o processo passo a passo para verificar várias permissões para várias classes protegíveis para qualquer principal neste artigo. Você também pode usar esta função de segurança do SQL Server do sistema para atender aos seus requisitos de verificação de permissão. Por favor, compartilhe este artigo e dê seus comentários na seção de comentários para que possamos melhorar.
