Configuração de visibilidade de metadados

A visibilidade dos metadados é limitada a objetos seguráveis que um usuário possui ou nos quais o usuário recebeu alguma permissão. Por exemplo, a consulta a seguir retornará uma linha se o usuário tiver recebido uma permissão, como SELECT ou INSERT na tabela myTable.

SELECT name, object_id  
FROM sys.tables  
WHERE name = 'myTable';  
GO  

No entanto, se o usuário não tiver nenhuma permissão em myTable, a consulta retornará um conjunto de resultados vazio.

Escopo e impacto da configuração de visibilidade de metadados

A configuração de visibilidade de metadados só se aplica aos recursos de segurança a seguir.

A configuração de visibilidade de metadados não se aplica aos elementos protegíveis a seguir.

A acessibilidade de metadados limitada significa o seguinte:

• Aplicativos que pressupõem acesso a metadados públicos irão falhar.

• Consultas em exibições do sistema podem retornar apenas um subconjunto de linhas ou, às vezes, um conjunto de resultados vazio.

• Funções internas que emitem metadados, como OBJECTPROPERTYEX, podem retornar NULL.

• Os procedimentos armazenados do Mecanismo de Banco de Dados sp_help podem retornar apenas um subconjunto de linhas ou NULL.

Os módulos SQL, como procedimentos armazenados e gatilhos, são executados no contexto de segurança do chamador e, portanto, têm acessibilidade limitada de metadados. Por exemplo, no código a seguir, quando o procedimento armazenado tenta acessar metadados para a tabela myTable na qual o chamador não tem direitos, um conjunto de resultados vazio é retornado. Em versões anteriores do SQL Server, uma linha é retornada.

CREATE PROCEDURE assumes_caller_can_access_metadata  
BEGIN  
SELECT name, id   
FROM sysobjects   
WHERE name = 'myTable';  
END;  
GO  

Para permitir que os chamadores exibam metadados, você pode conceder aos chamadores a permissão VIEW DEFINITION em um escopo apropriado: nível de objeto, nível de banco de dados ou servidor. Portanto, no exemplo anterior, se o chamador tiver a permissão VIEW DEFINITION ativada myTable, o procedimento armazenado retornará uma linha. Para obter mais informações, consulte GRANT (Transact-SQL) e GRANT Database Permissions (Transact-SQL).

Você também pode modificar o procedimento armazenado para que ele seja executado sob as credenciais do proprietário. Quando o proprietário do procedimento e o proprietário da tabela são o mesmo proprietário, o encadeamento de propriedade se aplica e o contexto de segurança do proprietário do procedimento permite o acesso aos metadados para myTable. Nesse cenário, o código a seguir retorna uma linha de metadados para o chamador.

CREATE PROCEDURE does_not_assume_caller_can_access_metadata  
WITH EXECUTE AS OWNER  
AS  
BEGIN  
SELECT name, id  
FROM sys.objects   
WHERE name = 'myTable'   
END;  
GO  

Benefícios e limites da configuração de visibilidade de metadados

A configuração de visibilidade de metadados pode desempenhar um papel importante em seu plano de segurança geral. No entanto, há casos em que um usuário qualificado e determinado pode forçar a divulgação de alguns metadados. Recomendamos que você implante permissões de metadados como uma das muitas defesas detalhadas.

Teoricamente, é possível forçar a emissão de metadados em mensagens de erro manipulando a ordem da avaliação do predicado em consultas. A possibilidade de ataques de tentativa e erro não é específica para o SQL Server. Ela é implícita pelas transformações associativas e commutativas permitidas na álgebra relacional. Você pode atenuar esse risco limitando as informações retornadas em mensagens de erro. Para restringir ainda mais a visibilidade dos metadados dessa maneira, você pode iniciar o servidor com o sinalizador de rastreamento 3625. Esse sinalizador de rastreamento limita a quantidade de informações mostradas em mensagens de erro. Por sua vez, isso ajuda a evitar divulgações forçadas. A desvantagem é que as mensagens de erro serão concisas e podem ser difíceis de usar para fins de depuração. Para obter mais informações, consulte Opções de Inicialização do Mecanismo de Banco de Dados e Sinalizadores de Rastreamento (Transact-SQL).

Os seguintes metadados não estão sujeitos à divulgação forçada:

• O valor armazenado na coluna provider_string de sys.servers. Um usuário que não tem a permissão ALTER ANY LINKED SERVER verá um valor NULL nesta coluna.

• Definição de origem de um objeto definido pelo usuário, como um procedimento armazenado ou gatilho. O código-fonte só fica visível quando um dos seguintes é verdadeiro:

  • O usuário tem a permissão VIEW DEFINITION no objeto.

  • A permissão VIEW DEFINITION não foi negada ao usuário no objeto, e ele tem permissão CONTROL, ALTER ou TAKE OWNERSHIP no objeto. Todos os outros usuários verão NULL.

• As colunas de definição encontradas nas seguintes exibições de catálogo:

  sys.all_sql_modules	sys.sql_modules
  sys.server_sql_modules	sys.check_constraints
  sys.default_constraints	sys.computed_columns
  sys.numbered_procedures

• A coluna ctexto na visão de compatibilidade syscomments.

• A saída do procedimento sp_helptext .

• As seguintes colunas nas exibições de esquema de informações:

  INFORMATION_SCHEMA.RESTRIÇÕES_DE_VERIFICAÇÃO.CLÁUSULA_DE_VERIFICAÇÃO	INFORMATION_SCHEMA.COLUMNS.COLUMN_DEFAULT
  INFORMATION_SCHEMA. DOMÍNIOS. DOMAIN_DEFAULT	INFORMATION_SCHEMA.ROUTINE_COLUMNS.COLUMN_DEFAULT
  INFORMATION_SCHEMA.ROUTINAS.DEFINICAO_ROTINA	INFORMATION_SCHEMA. MODOS DE EXIBIÇÃO. VIEW_DEFINITION

• função OBJECT_DEFINITION()

• O valor armazenado na coluna password_hash de sys.sql_logins. Um usuário que não tem a permissão CONTROL SERVER verá um valor NULL nesta coluna.

Princípios gerais de visibilidade de metadados

Veja a seguir alguns princípios gerais a serem considerados em relação à visibilidade dos metadados:

• Permissões implícitas de funções fixas

• Escopo de permissões

• Precedência de Negação

• Visibilidade dos metadados de subcomponente

Funções fixas e permissões implícitas

Os metadados que podem ser acessados por funções fixas dependem de suas permissões implícitas correspondentes.

Escopo de permissões

As permissões em um escopo implicam a capacidade de ver metadados nesse escopo e em todos os escopos fechados. Por exemplo, a permissão SELECT em um esquema implica que o concessionário tem permissão SELECT em todos os objetos de segurança contidos nesse esquema. A concessão da permissão SELECT em um esquema, portanto, permite que um usuário veja os metadados do esquema e também todas as tabelas, exibições, funções, procedimentos, filas, sinônimos, tipos e coleções de esquema XML dentro dele. Para obter mais informações sobre escopos, consulte Hierarquia de Permissões (Mecanismo de Banco de Dados).

Precedência de DENY

DENY normalmente tem precedência sobre outras permissões. Por exemplo, se um usuário de banco de dados receber permissão EXECUTE em um esquema, mas tiver sido negada a permissão EXECUTE em um procedimento armazenado nesse esquema, o usuário não poderá exibir os metadados desse procedimento armazenado.

Além disso, se um usuário tiver a permissão EXECUTE negada em um esquema, mas tiver recebido permissão EXECUTE em um procedimento armazenado nesse esquema, o usuário não poderá exibir os metadados desse procedimento armazenado.

Por outro exemplo, se um usuário tiver recebido e negado a permissão EXECUTE em um procedimento armazenado, o que é possível por meio de suas várias associações de função, DENY terá precedência e o usuário não poderá exibir os metadados do procedimento armazenado.

Visibilidade dos metadados de subcomponente

A visibilidade de subcomponentes, como índices, restrições de verificação e gatilhos, é determinada por permissões no objeto pai. Esses subcomponentes não têm permissões que podem ser concedidas. Por exemplo, se um usuário tiver recebido alguma permissão em uma tabela, o usuário poderá exibir os metadados das tabelas, colunas, índices, restrições de verificação, gatilhos e outros subcomponentes.

Metadados acessíveis a todos os usuários do banco de dados

Alguns metadados devem estar acessíveis a todos os usuários em um banco de dados específico. Por exemplo, grupos de arquivos não têm permissões de conferência; portanto, um usuário não pode receber permissão para exibir os metadados de um grupo de arquivos. No entanto, qualquer usuário que possa criar uma tabela deve ser capaz de acessar metadados de grupos de arquivos para usar as cláusulas ON grupo de arquivos ou TEXTIMAGE_ON grupo de arquivos na instrução CREATE TABLE.

Os metadados retornados pelas funções DB_ID() e DB_NAME() são visíveis para todos os usuários.

A tabela a seguir lista as exibições de catálogo visíveis para a função pública .

Consulte Também

GRANT (Transact-SQL)
DENY (Transact-SQL)
REVOKE (Transact-SQL)
Cláusula EXECUTE AS (Transact-SQL)
Exibições do Catálogo (Transact-SQL)
Exibições de compatibilidade (Transact-SQL)