Configuração de visibilidade de metadados

Aplica-se a:Banco de Dados SQL dodo AzureInstância Gerenciada SQL do Azuredo Azure Synapse Analyticsdo Analytics Platform System (PDW)Banco de Dados SQL no Microsoft Fabric

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 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 no myTable, a consulta retornará um conjunto de resultados vazio.

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

A configuração da visibilidade dos metadados aplica-se apenas aos seguintes elementos securizáveis:

• Visualizações do catálogo
• Metadados expondo funções internas
• Vistas de compatibilidade
• Procedimentos armazenados do Mecanismo sp_help de Banco de Dados
• Vistas do esquema de informações
• Propriedades estendidas

A configuração de visibilidade de metadados não se aplica aos seguintes itens de segurança:

• Tabelas do sistema de envio de logs
• Tabelas do sistema do plano de manutenção do banco de dados
• Tabelas do sistema de replicação
• Tabelas de sistema do SQL Server Agent
• Tabelas do sistema de backup
• Replicação e procedimentos armazenados do SQL Server Agent sp_help

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, os aplicativos que assumem o acesso a metadados públicos são interrompidos.

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 permissão aos chamadores VIEW DEFINITION ou no SQL Server 2022 (16.x) e versões posteriores, ou VIEW SECURITY DEFINITIONVIEW 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 VIEW DEFINITION permissão em myTable, o procedimento armazenado retornará uma linha. Para obter mais informações, consulte Permissões de banco de dadosGRANT e GRANT.

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.

Observação

O exemplo a seguir usa a vista de catálogo sys.objects em vez da vista 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, consulte EXECUTE AS.

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 sã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 e sinalizadores de rastreamento do Serviço Mecanismo de Banco de Dados.

Os seguintes metadados 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 ALTER ANY LINKED SERVER permissão vê um NULL valor 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 condições for verdadeira:

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

  • Não foi negada VIEW DEFINITION permissão ao usuário no objeto e tem CONTROL, ALTERou TAKE OWNERSHIP permissão no objeto. Todos os outros usuários veem 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

• 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 internos do sistema são publicamente visíveis por meio da sys.system_sql_modules exibição de catálogo, do sp_helptext procedimento armazenado e da OBJECT_DEFINITION() função.

Observação

O procedimento sp_helptext armazenado do sistema não é suportado no Azure Synapse Analytics. Em vez disso, use a vista de catálogo de objetos sys.sql_modules.

Princípios gerais de visibilidade dos 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, SELECT a permissão em um esquema implica que o beneficiário tem SELECT permissão sobre todos os protegíveis contidos por esse 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, consulte Permissions Hierarchy (Database Engine).

Observação

A UNMASK permissão não influencia a visibilidade dos metadados: a concessão UNMASK por si só não divulga nenhum metadados. UNMASK sempre precisa ser acompanhado de uma SELECT permissão para ter qualquer efeito. Exemplo: conceder UNMASK no escopo do banco de dados e conceder SELECT em uma tabela individual tem o resultado de que o usuário só pode ver os metadados da tabela individual a partir da qual ele pode selecionar, não quaisquer outros.

Precedência de DENY

DENY normalmente tem precedência sobre outras permissões. Por exemplo, se um usuário de banco de dados tiver permissão EXECUTE concedida 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 dos metadados do 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 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 é a concessão SELECT em apenas uma coluna individual de uma determinada tabela: isso permite que o beneficiário visualize 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, 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 usuário que possa criar uma tabela deve ser capaz de acessar metadados de grupo de arquivos para usar as ON <filegroup> cláusulas ou TEXTIMAGE_ON <filegroup> da CREATE TABLE instrução.

Os metadados retornados pelas DB_ID() funções 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.

• 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)
• Vistas do catálogo do sistema (Transact-SQL)
• Vistas de compatibilidade do sistema (Transact-SQL)