Configuração de visibilidade de metadados
Aplica-se a:SQL ServerBanco de Dados SQL do AzureInstância Gerenciada de SQL do AzureAzure Synapse AnalyticsAnalytics Platform System (PDW)
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 ouNULL
.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
Para permitir que os usuários exibam metadados, você pode conceder a eles a permissão VIEW DEFINITION ou, a partir do SQL Server 2022, as permissões 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. 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
desys.servers
. Um usuário que não tem permissão ALTER ANY LINKED SERVER verá o valorNULL
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 compatibilidadesyscomments
.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 valorNULL
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 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 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)