Configuração de visibilidade de metadados

Aplica-se a:SQL ServerBanco de Dados SQL do AzureInstância Gerenciada SQL do Azure do Azure Synapse AnalyticsAnalytics Platform System (PDW)

A visibilidade dos metadados é limitada aos elementos protegidos que um utilizador possui ou aos quais lhe foi concedida alguma permissão.

Por exemplo, a consulta a seguir retorna 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 = N'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 seguintes elementos de segurança.

A configuração de visibilidade de metadados não se aplica aos seguintes elementos de segurança.

Por acessibilidade limitada dos metadados entende-se o seguinte:

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

• Funções internas emissoras de metadados, como OBJECTPROPERTYEX, podem retornar NULL.

• Mecanismo de Banco de Dados sp_help pode fazer com que procedimentos armazenados retornem apenas um subconjunto de linhas ou NULL.

• Como resultado, as aplicações que assumem acesso público a metadados deixarão de funcionar.

Os módulos SQL, como procedimentos armazenados e gatilhos, são executados sob o 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, object_id   
FROM sys.objects   
WHERE name = N'myTable';  
END;  
GO  

Para permitir que os chamadores visualizem metadados, você pode conceder aos chamadores a permissão VIEW DEFINITION ou, a partir do SQL Server 2022, VIEW SECURITY DEFINITION ou VIEW PERFORMANCE DEFINITION em um escopo apropriado: nível de objeto, nível de banco de dados ou nível de servidor. Portanto, no exemplo anterior, se o chamador tiver a permissão VIEW DEFINITION em 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, object_id  
FROM sys.objects   
WHERE name = N'myTable'   
END;  
GO  

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

A configuração da visibilidade dos metadados pode desempenhar um papel importante no 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 de predicados em consultas. A possibilidade de tais ataques de tentativa e erro não é específica do SQL Server. Está implícito nas transformações associativas e comutativas permitidas na álgebra relacional. Você pode reduzir esse risco limitando as informações retornadas em mensagens de erro. Para restringir ainda mais a visibilidade dos metadados dessa forma, 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 contrapartida é 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 serviço Mecanismo de Banco de Dados e Sinalizadores de Rastreamento (Transact-SQL).

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

• O valor armazenado na coluna provider_string de sys.servers. Um utilizador que não tenha permissão de ALTERAR QUALQUER SERVIDOR VINCULADO 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 é visível somente quando uma das seguintes opções é verdadeira:

  • O utilizador tem a permissão VIEW DEFINITION no objeto.

  • O utilizador não teve negada a permissão VIEW DEFINITION no objeto e tem permissão CONTROL, ALTERou 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.server_sql_modules
  • sys.default_constraints
  • sys.numbered_procedures
  • sys.sql_modules
  • sys.check_constraints
  • sys.computed_columns

• A coluna ctext na vista de compatibilidade syscomments.

• A saída do procedimento de sp_helptext.

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

  • INFORMATION_SCHEMA.CHECK_CONSTRAINTS.CHECK_CLAUSE
  • INFORMATION_SCHEMA.DOMAINS.DOMAIN_DEFAULT
  • INFORMATION_SCHEMA.ROUTINES.ROUTINE_DEFINITION
  • INFORMATION_SCHEMA.COLUMNS.COLUMN_DEFAULT
  • INFORMATION_SCHEMA.ROUTINE_COLUMNS.COLUMN_DEFAULT
  • INFORMATION_SCHEMA.VIEWS.VIEW_DEFINITION

• Função OBJECT_DEFINITION()

• O valor armazenado na coluna "password_hash" de sys.sql_logins. Um utilizador que não tenha CONTROL SERVER ou, a partir do SQL Server 2022, a permissão VER QUALQUER DEFINIÇÃO CRIPTOGRAFICAMENTE PROTEGIDA verá um valor NULL nesta coluna.

Princípios gerais de visibilidade de metadados

A seguir estão alguns princípios gerais a serem considerados em relação à visibilidade de metadados:

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

• Âmbito das permissões

• Precedência de DENY

• Visibilidade dos metadados do 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.

Âmbito das permissões

As permissões em um escopo implicam a capacidade de ver metadados nesse escopo e em todos os escopos incluídos. Por exemplo, permissão SELECT num esquema implica que o beneficiário tem permissão SELECT em todos os seguráveis contidos nesse esquema. A concessão da permissão SELECT num esquema, portanto, permite que um utilizador ver os metadados do esquema e também todas as tabelas, visões, funções, procedimentos, filas, sinónimos, tipos e coleções de esquemas XML nele contidas. Para obter mais informações sobre escopos, consulte Permissions Hierarchy (Database Engine).

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 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 for negada a um usuário permissão EXECUTE 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 utilizador tiver recebido e negado permissão EXECUTE num procedimento guardado, o que é possível através das suas várias associações de função, DENY terá precedência e o utilizador não poderá visualizar os metadados do procedimento guardado.

Visibilidade dos metadados do subcomponente

A visibilidade de subcomponentes, como índices, restrições de validação e gatilhos, é determinada por permissões no objeto pai. Esses subcomponentes não têm permissões concedidas. Por exemplo, se um usuário recebeu alguma permissão em uma tabela, ele pode exibir os metadados das tabelas, colunas, índices, restrições de verificação, gatilhos e outros subcomponentes semelhantes. Outro exemplo é conceder SELECT em apenas uma coluna individual de uma determinada tabela: isso permitirá que o beneficiário visualize os metadados de toda a tabela, incluindo todas as colunas. Uma maneira de pensar nisso é que a permissão VIEW DEFINITION só funciona no nível da entidade (a tabela, neste caso) e não está disponível para listas de subentidades (como colunas ou expressões de segurança).

O código a seguir demonstra esse comportamento:

CREATE TABLE t1
(
    c1 int,
    c2 varchar
 );
GO
CREATE USER testUser WITHOUT LOGIN;
GO

EXECUTE AS USER='testUser';
SELECT OBJECT_SCHEMA_NAME(object_id), OBJECT_NAME(object_id), name FROM sys.columns;
SELECT * FROM sys.tables
-- this returns no data, as the user has no permissions
REVERT;
GO

-- granting SELECT on only 1 column of the table:
GRANT SELECT ON t1(c1) TO testUser;
GO
EXECUTE AS USER='testUser';
SELECT OBJECT_SCHEMA_NAME(object_id), OBJECT_NAME(object_id), name FROM sys.columns;
SELECT * FROM sys.tables
-- this returns metadata for all columns of the table and the table itself
REVERT;
GO

DROP TABLE t1
DROP USER testUser

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

Alguns metadados devem estar acessíveis a todos os utilizadores numa base de dados específica. Por exemplo, os grupos de arquivos não têm permissões conferíveis; Portanto, um usuário não pode receber permissão para exibir os metadados de um grupo de arquivos. No entanto, qualquer utilizador que possa criar uma tabela deve ser capaz de aceder aos metadados dos grupos de ficheiros para usar as cláusulas ON grupo de ficheiros ou TEXTIMAGE_ON grupo de ficheiros da instrução CREATE TABLE.

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

Esta é uma lista das vistas de catálogo que são visíveis para a função pública.

Ver também

SUBVENÇÃO (Transact-SQL)
DENY (Transact-SQL)
REVOGAR (Transact-SQL)
Cláusula EXECUTE AS (Transact-SQL)
Catalog Views (Transact-SQL)
Vistas de compatibilidade (Transact-SQL)