Configuração de visibilidade de metadados

Aplica-se a:SQL ServerAzure SQL DatabaseAzure SQL Managed InstanceAzure Synapse AnalyticsSistema de Plataforma de Análise (PDW)Banco de dados SQL no Microsoft Fabric

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 conceder 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 permissão 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 protegíveis:

• Exibições do catálogo
• Metadados com exposição de funções internas
• Exibições de compatibilidade
• Procedimentos armazenados do Mecanismo sp_help de Banco de Dados
• 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 procedimentos 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 OBJECTPROPERTYEX, podem retornar NULL.
• Os procedimentos armazenados sp_help podem retornar apenas um subconjunto de linhas ou NULL.
• Como resultado, aplicativos que assumem quebras de acesso de metadados públicos .

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

Para permitir que os chamadores exibam metadados, você pode conceder permissão aos chamadores VIEW DEFINITION, ou, no SQL Server 2022 (16.x) e versões posteriores, 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 e GRANT Database Permissions.

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.

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 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 da avaliação do predicado em consultas. A possibilidade de ataques de tentativa e erro não é específica para o SQL Server. Está implícito pelas transformações associativas e commutativas permitidas na á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. A desvantagem é que as mensagens de erro são terse e podem ser difíceis de usar para fins de depuração. Para obter mais informações, consulte as opções de inicialização do Serviço do Mecanismo de Banco de Dados e os sinalizadores de rastreamento.

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 ALTER ANY LINKED SERVER permissão vê um NULL valor nesta coluna.

• Definição de fonte de um objeto definido pelo usuário como um procedimento armazenado ou gatilho. O código-fonte só fica visível quando uma das seguintes condições é verdadeira:

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

  • O usuário não teve a permissão negada VIEW DEFINITION no objeto e tem permissão CONTROL, ALTER ou TAKE OWNERSHIP no objeto. Todos os outros usuários veem 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

• OBJECT_DEFINITION() função

• O valor armazenado na coluna password_hash de sys.sql_logins. Um usuário que não tem CONTROL SERVER, ou no SQL Server 2022 (16.x) e versões posteriores, a VIEW ANY CRYPTOGRAPHICALLY SECURED DEFINITION permissão vê um NULL valor nesta coluna.

As definições sql de procedimentos e funções internas do sistema são publicamente visíveis por meio da exibição do sys.system_sql_modules catálogo, do sp_helptext procedimento armazenado e da OBJECT_DEFINITION() função.

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 de 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, SELECT a permissão em um esquema implica que o usuário autorizado tem SELECT permissão em todos os protegíveis contidos nesse esquema. A concessão de SELECT permissão 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, veja Hierarquia de permissões (Mecanismo de Banco de Dados).

Precedência em DENY

DENY normalmente tem precedência sobre outras permissões. Por exemplo, se um usuário de banco de dados receber EXECUTE permissão em um esquema, mas tiver sido negada EXECUTE permissão 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 permissão negada EXECUTE em um esquema, mas tiver recebido EXECUTE permissão 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 EXECUTE permissão 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 de metadados de subcomponente

A visibilidade de subcomponentes, como índices, restrições de verificação e gatilhos, é determinada por permissões no pai. Esses subcomponentes não têm permissões que podem 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 apenas uma coluna individual de uma determinada tabela: isso permite que o usuário autorizado exiba os metadados de toda a tabela, incluindo todas as colunas. Uma maneira de pensar nisso é que a VIEW DEFINITION permissão 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 coluna ou segurança).

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 the 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 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 do grupo de arquivos para usar as cláusulas ON <filegroup> ou TEXTIMAGE_ON <filegroup> da instrução CREATE TABLE.

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

Esta é uma lista das exibições do catálogo visíveis na função pública.

• sys.allocation_units
• sys.column_type_usages
• sys.configurations
• sys.data_spaces
• sys.database_files
• sys.destination_data_spaces
• sys.filegroups
• sys.messages
• sys.parameter_type_usages
• sys.partition_functions
• sys.partition_range_values
• sys.partition_schemes
• sys.partitions
• sys.schemas
• sys.sql_dependencies
• sys.type_assembly_usages

Conteúdo relacionado

• SUBVENÇÃO (Transact-SQL)
• NEGAR (Transact-SQL)
• REVOGAR (Transact-SQL)
• Cláusula EXECUTE AS (Transact-SQL)
• Exibições de catálogo do sistema (Transact-SQL)
• Exibições de compatibilidade do sistema (Transact-SQL)