Configuração de visibilidade de metadados

Em versões anteriores do SQL Server, os metadados de todos os objetos em um banco de dados são visíveis para os membros da função pública. Isso significa que qualquer usuário registrado em uma instância do SQL Server pode visualizar os metadados de cada objeto no servidor, até mesmo dos objetos sobre os quais o usuário não possui direitos.

No SQL Server 2005 e posteriormente, 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 = '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.

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

Acessibilidade de metadados limitada significa o seguinte:

• Aplicativos que assumem que o acesso de metadados público será interrompido.

• 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 em OBJECTPROPERTYEX podem retornar NULO.

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

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, id 
FROM sysobjects 
WHERE name = 'myTable';
END;
GO

Você pode conceder aos visitantes uma permissão VIEW 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, consulte 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, id
FROM sys.objects 
WHERE name = '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 (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á um 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 permissão ao usuário em VIEW DEFINITION no objeto e possui permissões em CONTROL, ALTER ou em TAKE OWNERSHIP no 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.sql_modules
  sys.server_sql_modules	sys.check_constraints
  sys.default_constraints	sys.computed_columns
  sys. numbered_procedures

• A coluna ctext na 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.COLUMNS.COLUMN_DEFAULT
  INFORMATION_SCHEMA.DOMAINS.DOMAIN_DEFAULT	INFORMATION_SCHEMA.ROUTINE_COLUMNS.COLUMN_DEFAULT
  INFORMATION_SCHEMA.ROUTINES.ROUTINE_DEFINITION	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 a permissão CONTROL SERVER verá um valor NULL nessa 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 de sp_helptext e na função OBJECT_DEFINITION().

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 o beneficiado tem permissão SELECT em todos os protegíveis contidos nesse esquema. A concessão de permissão SELECT em um esquema permite que usuário veja então 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 inclusos. Para obter mais informações sobre escopos, consulte 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 recebeu permissão EXECUTE em um esquema, mas teve a permissão EXECUTE negada em um procedimento armazenado nesse esquema, o usuário não pode exibir os metadados para esse procedimento armazenado.

Além disso, se um usuário teve a permissão EXECUTE negada em um esquema, mas recebeu a permissão EXECUTE em um procedimento armazenado nesse esquema, o usuário não pode exibir os metadados para esse procedimento armazenado.

Outro exemplo, se um usuário teve permissão EXECUTE concedida e negada em um procedimento armazenado, o que é possível através de suas diversas associações à funções, 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 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.

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.

A tabela a seguir lista aos exibições do catálogo que são visíveis na função pública.

Consulte também

Referência

GRANT (Transact-SQL)

DENY (Transact-SQL)

REVOKE (Transact-SQL)

Cláusula EXECUTE AS (Transact-SQL)

Exibições de catálogo (Transact-SQL)

exibições de compatibilidade (Transact-SQL)