Configuração de visibilidade de metadados

Aplica-se a:SQL ServerBanco de Dados SQL do AzureInstância Gerenciada de SQL do AzureAzure Synapse AnalyticsPDW (Analytics Platform System)

A visibilidade de metadados é limitada aos protegíveis que pertencem a um usuário ou sobre os quais recebeu alguma permissão.

Por exemplo, a consulta a seguir retornará uma linha se o usuário recebeu uma permissão SELECT ou INSERT na tabela myTable.

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

Entretanto, se o usuário não possuir 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 apenas se aplica aos seguintes protegíveis.

Exibições do catálogo

Metadados com exposição de funções internas

Exibições de compatibilidade

Mecanismo de banco de dados sp_help procedimentos armazenados

Exibições do esquema de informações

Propriedades estendidas

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

Tabelas do sistema de envio de logs

Tabelas do sistema de plano de manutenção do banco de dados

Tabelas do sistema de replicação

Tabelas do sistema do SQL Server Agent

Tabelas do sistema de backup

Replicação e procedimento armazenados do SQL Server Agent sp_help

Acessibilidade de metadados limitada significa o seguinte:

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

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

• Os procedimentos armazenados sp_help podem retornar apenas um subconjunto de linhas ou NULL.

• Como resultado, aplicativos que assumem o acesso de metadados públicos serão interrompidos.

Os módulos SQL, como os procedimentos armazenados e os gatilhos, são executados no contexto de segurança do chamador e, em consequência, têm acessibilidade limitada aos metadados. Por exemplo, no código a seguir, quando o procedimento armazenado tentar acessar os metadados para a tabela myTable na qual o visitante não tem nenhum direito, há retorno de um conjunto de resultados vazio. Em versões anteriores do SQL Server, é retornada uma linha.

CREATE PROCEDURE assumes_caller_can_access_metadata  
BEGIN  
SELECT name, object_id   
FROM sys.objects   
WHERE name = N'myTable';  
END;  
GO  

Você pode conceder aos visitantes uma permissão VIEW DEFINITION ou a partir do SQL Server 2022 VIEW SECUIRITY DEFINITION ou VIEW PERFORMANCE DEFINITION que permita aos visitantes exibir os metadados no escopo apropriado: nível de objeto, nível de banco de dados ou nível de servidor. Assim, no exemplo prévio, se o visitante tiver uma permissão VIEW DEFINITION em myTable, o procedimento armazenado retornará uma linha. Para obter mais informações, veja GRANT (Transact-SQL) e Permissões de banco de dados GRANT (Transact-SQL).

Você também pode modificar o procedimento armazenado de forma a executar com as credenciais do proprietário. Quando o proprietário do procedimento e o da tabela forem o mesmo proprietário, o encadeamento de propriedade é aplicável e o contexto de segurança do proprietário do procedimento ativa o acesso aos metadados para myTable. Nesse cenário, o seguinte código retorna uma linha de metadados ao chamador.

Observação

O exemplo a seguir utiliza a exibição do catálogo sys.objects , em vez da exibição de compatibilidade sys.sysobjects .

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  

Observação

Você pode usar EXECUTE AS para alternar temporariamente para o contexto de segurança do chamador. Para obter mais informações, confira EXECUTE AS (Transact-SQL).

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

A configuração de visibilidade de metadados pode ter uma função importante em seu plano de segurança global. Entretanto, há casos nos quais um usuário habilidoso e determinado pode forçar a divulgação de alguns metadados. Recomendamos que você implante permissões para metadados como um dos muitos detalhes de defesa.

É teoricamente possível forçar a emissão de metadados em mensagens de erro manipulando a ordem de avaliação do predicado nas consultas. A possibilidade de tais ataques por tentativa e erro não é específica do SQL Server. Está implícita nas transformações associativas e comutativas permitidas pela álgebra relacional. Você pode reduzir esse risco limitando as informações retornadas nas mensagens de erro. Para restringir ainda mais a visibilidade de metadados desse modo, você pode iniciar o servidor com o sinalizador de rastreamento 3625. Este sinalizador de rastreamento limita a quantidade de informações mostradas nas mensagens de erro. Por sua vez, isso ajuda a impedir divulgações forçadas. Em compensação as mensagens de erro serão concisas e será difícil usar para propósitos 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 metadados a seguir não estão sujeitos a divulgação forçada:

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

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

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

  • Não foi negada a permissão VIEW DEFINITION ao usuário no objeto e ele tem as permissões CONTROL, ALTER ou TAKE OWNERSHIP sobre o objeto. Todos os outros usuários verão NULL.

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

  • 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 no modo de exibição de compatibilidade syscomments.

• A saída do procedimento sp_helptext.

• As seguintes colunas nas exibiçõ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 em sys.sql_logins. Um usuário que não tenha CONTROL SERVER ou a partir do SQL Server 2022 a permissão VIEW ANY CRYPTOGRAPHICALLY SECURED DEFINITION verá um valor NULL nesta coluna.

Observação

As definições de SQL de procedimentos e funções de sistema internos são publicamente visíveis na exibição do catálogo sys.system_sql_modules, no procedimento armazenado sp_helptext e na função OBJECT_DEFINITION().

Observação

O procedimento armazenado do sistema sp_helptext não tem suporte no Azure Synapse Analytics. Em vez disso, use a exibição do catálogo de objetos sys.sql_modules.

Princípios gerais de visibilidade de metadados

A seguir, alguns princípios gerais para serem considerados relativos à visibilidade de metadados:

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

• Escopo das permissões

• Precedência em DENY

• Visibilidade de metadados de subcomponente

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

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

Escopo das permissões

Permissões em um escopo implicam na capacidade de ver os metadados nesse escopo e em todos os escopos inclusos. Por exemplo, a permissão SELECT dentro de um esquema implica que a entidade autorizada tem permissão SELECT em todos os protegíveis contidos nesse esquema. A concessão da permissão SELECT em um esquema permite que o 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 esquemas XML inclusos. Para obter mais informações sobre escopos, veja Hierarquia de permissões (Mecanismo de Banco de Dados).

Observação

A permissão UNMASK não influencia a visibilidade dos metadados: conceder UNMASK por si só não divulgará nenhum metadado. A UNMASK sempre precisará ser acompanhada pela permissão SELECT para sortir algum efeito. Exemplo: conceder UNMASK no escopo do banco de dados e conceder SELECT em uma tabela individual resultará que o usuário só poderá ver os metadados da tabela individual da qual ele pode selecionar, e não das demais.

Precedência em DENY

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

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

Outro exemplo, se um usuário tiver a permissão EXECUTE concedida e negada em um procedimento armazenado, o que é possível por meio de diversas associações a funções, DENY terá precedência e o usuário não poderá ver os metadados do procedimento armazenado.

Visibilidade de metadados de subcomponente

A visibilidade de subcomponentes, como índices, restrições de verificação e gatilhos são determinados através de permissões no pai. Esses subcomponentes não têm permissões que possam ser concedidas. Por exemplo, se um usuário recebeu alguma permissão em uma tabela, o usuário poderá exibir os metadados para as tabelas, colunas, índices, restrições de verificações, gatilhos e outros subcomponentes similares. Outro exemplo é conceder SELECT somente em uma coluna individual de uma determinada tabela: isso permitirá que a entidade autorizada veja os metadados da tabela inteira, incluindo todas as colunas. Uma forma de entender isso é pensando que a permissão VIEW DEFINITION só funciona no nível da entidade (a tabela, nesse caso) e não está disponível para listas de subentidades (como expressões de segurança ou de coluna).

O seguinte código 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 thge table itself
REVERT;
GO

DROP TABLE t1
DROP USER testUser

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

Algum metadados devem ser 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 que possam ser conferidas; consequentemente, um usuário não pode receber permissão para exibir os metadados de um grupo de arquivos. Entretanto, qualquer usuário que possa criar uma tabela deve poder acessar os metadados de grupo de arquivos para usar filegroup ON ou as cláusulas TEXTIMAGE_ON filegroup 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 exibições do catálogo visíveis na função pública.

sys.partition_functions

sys.partition_schemes

sys.filegroups

sys.database_files

sys.partitions

sys.schemas

sys.sql_dependencies

sys.parameter_type_usages

sys.partition_range_values

sys.data_spaces

sys.destination_data_spaces

sys.allocation_units

sys.messages

sys.configurations

sys.type_assembly_usages

sys.column_type_usages

Confira 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)