Configurazione della visibilità dei metadati

Si applica a: sìSQL Server (tutte le versioni supportate) Sìdatabase SQL di Azure SìIstanza gestita di SQL di Azure sìAzure Synapse Analytics sìParallel Data Warehouse

La visibilità dei metadati è limitata alle entità a protezione diretta di cui l'utente è proprietario o per le quali dispone di autorizzazioni. Ad esempio, la query seguente restituisce una riga se all'utente è stata concessa un'autorizzazione SELECT o INSERT per la tabella myTable.

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

Se invece l'utente non dispone di alcuna autorizzazione per myTable, la query restituisce un set di risultati vuoto.

Ambito e impatto della configurazione della visibilità dei metadati

È possibile configurare la visibilità dei metadati unicamente per le entità a protezione diretta seguenti:

Viste del catalogo

Metadati che espongono funzioni predefinite

Viste di compatibilità

Stored procedure sp_help del Motore di database

Viste degli schemi delle informazioni

Proprietà estese

Non è possibile configurare la visibilità dei metadati per le entità a protezione diretta seguenti:

Tabelle di sistema per il log shipping

Tabelle di sistema del piano di manutenzione database

Tabelle di sistema di replica

SQL Server Tabelle di sistema dell'agente

Tabelle di sistema di backup

Replica e stored procedure SQL Server sp_help dell'agente

Un'accessibilità limitata ai metadati comporta quanto segue:

  • Le applicazioni per cui è impostato l'accesso pubblico ai metadati verranno interrotte.

  • È possibile che le query eseguite su viste di sistema restituiscano solo un subset di righe o a volte un set di risultati vuoto.

  • Le funzioni incorporate di emissione dei metadati, ad esempio OBJECTPROPERTYEX, possono restituire NULL .

  • Le Motore di database sp_help stored procedure possono restituire solo un subset di righe, o NULL .

I moduli SQL, ad esempio le stored procedure e i trigger, vengono eseguiti nel contesto di sicurezza del chiamante e pertanto la relativa accessibilità ai metadati è limitata. Nel codice di esempio seguente, quando la stored procedure tenta di accedere ai metadati relativi alla tabella myTable per la quale il chiamante non dispone di alcun diritto, viene restituito un set di risultati vuoto. Nelle versioni precedenti di SQL Server, viene invece restituita una riga.

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

Per consentire ai chiamanti di visualizzare i metadati, è possibile concedere ai chiamanti l'autorizzazione VIEW DEFINITION in un ambito appropriato: a livello di oggetto, di database o di server. Nell'esempio precedente, se il chiamante dispone dell'autorizzazione VIEW DEFINITION per myTable, la stored procedure restituisce pertanto una riga. Per altre informazioni, vedere GRANT (Transact-SQL) e Autorizzazioni di database GRANT (Transact-SQL).

È inoltre possibile modificare la stored procedure in modo che venga eseguita con le credenziali del proprietario. Se il proprietario della stored procedure è anche proprietario della tabella, verrà applicata la concatenazione della proprietà e il contesto di sicurezza del proprietario della procedura consentirà di accedere ai metadati relativi a myTable. In questo scenario, il codice seguente restituisce una riga di metadati al chiamante.

Nota

Nell'esempio seguente viene usata la vista del catalogo sys.objects anziché la vista di compatibilità 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  

Nota

Per passare temporaneamente al contesto di sicurezza del chiamante, è possibile utilizzare EXECUTE AS. Per altre informazioni, vedere EXECUTE AS (Transact-SQL).

Vantaggi e limiti della configurazione della visibilità dei metadati

La configurazione della visibilità dei metadati svolge un ruolo importante per il piano di sicurezza globale. In alcuni casi, tuttavia, un utente esperto potrebbe essere in grado di forzare la diffusione di alcuni metadati. È pertanto consigliabile prevedere un ulteriore livello di protezione tramite l'implementazione di autorizzazioni per i metadati.

In teoria, è possibile forzare la creazione di metadati nei messaggi di errore modificando l'ordine di valutazione del predicato nelle query. La possibilità di attacchi trial-and-error di questo tipo non è specifica di SQL Server, ma è implicita nelle trasformazioni associative e commutative consentite nell'algebra relazionale. È possibile ridurre questo rischio limitando le informazioni restituite nei messaggi di errore. Per limitare ulteriormente la visibilità dei metadati in questo modo, è possibile avviare il server con il flag di traccia 3625, che limita la quantità di informazioni visualizzate nei messaggi di errore. Questa soluzione contribuisce a limitare la diffusione forzata di informazioni, ma è controbilanciata dal fatto che i messaggi di errore saranno concisi e potrebbero essere difficili da utilizzare a scopi di debug. Per altre informazioni, vedere Opzioni di avvio del servizio del motore di database e Flag di traccia (Transact-SQL).

I metadati seguenti non sono soggetti alla diffusione forzata:

  • Valore archiviato nella provider_string colonna di sys.servers . Un utente che non dispone dell'autorizzazione ALTER ANY LINKED SERVER visualizza un valore in questa NULL colonna.

  • La definizione dell'origine di un oggetto definito dall'utente, ad esempio una stored procedure o un trigger. Il codice sorgente è visibile solo se è vera una delle condizioni seguenti:

    • L'utente dispone dell'autorizzazione VIEW DEFINITION per l'oggetto.

    • All'utente non è stata negata l'autorizzazione VIEW DEFINITION per l'oggetto e l'autorizzazione CONTROL, ALTER o TAKE OWNERSHIP per l'oggetto. Tutti gli altri utenti visualizzano NULL .

  • Le colonne di definizione delle viste del catalogo seguenti:

    • sys.all_sql_modules
    • sys.server_sql_modules
    • sys.default_constraints
    • sys.numbered_procedures
    • sys.sql_modules
    • sys.check_constraints
    • sys.computed_columns
  • Colonna ctext nella visualizzazione di syscomments compatibilità.

  • Output della sp_helptext procedura.

  • Le colonne seguenti nelle viste degli schemi delle informazioni:

    • 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
  • La funzione OBJECT_DEFINITION()

  • Valore archiviato nella colonna password_hash di sys.sql_logins . Un utente che non dispone dell'autorizzazione CONTROL SERVER visualizza NULL un valore in questa colonna.

Nota

Le SQL delle funzioni e delle procedure di sistema incorporate sono visibili pubblicamente tramite la vista del catalogo, il stored procedure e sys.system_sql_modules sp_helptext la funzione OBJECT_DEFINITION().

Nota

L'stored procedure di sp_helptext sistema non è supportata in Azure Synapse Analytics. Usare invece la vista sys.sql_modules del catalogo di oggetti.

Principi generali della visibilità dei metadati

Di seguito sono illustrati alcuni principi generali da tenere in considerazione per la visibilità dei metadati:

  • Autorizzazioni implicite dei ruoli predefiniti

  • Ambito delle autorizzazioni

  • Precedenza di DENY

  • Visibilità dei metadati dei sottocomponenti

Autorizzazioni implicite dei ruoli predefiniti

I metadati accessibili ai ruoli predefiniti variano in base alle autorizzazioni implicite corrispondenti.

Ambito delle autorizzazioni

Le autorizzazioni valide in un ambito implicano la possibilità di visualizzare i metadati dell'ambito specifico e di tutti gli ambiti dipendenti. Ad esempio, l'autorizzazione SELECT per uno schema implica che l'utente autorizzato dispone dell'autorizzazione SELECT per tutte le entità a protezione diretta contenute in tale schema. La concessione dell'autorizzazione SELECT per uno schema consente pertanto a un utente di visualizzare i metadati dello schema e di tutte le tabelle, le viste, le funzioni, le procedure, le code, i sinonimi, i tipi e le raccolte di XML Schema al suo interno. Per altre informazioni, vedere Gerarchia delle autorizzazioni (Motore di database).

Nota

L'autorizzazione UNMASK non influisce sulla visibilità dei metadati: la sola concessione di UNMASK non divulgherà alcun oggetto Metadata. UnMASK dovrà sempre essere accompagnata da un'autorizzazione SELECT per avere qualsiasi effetto. Esempio: la concessione di UNMASK nell'ambito del database e la concessione di SELECT per una singola tabella avranno come risultato che l'utente può visualizzare solo i metadati della singola tabella da cui può selezionare, non altri.

Precedenza di DENY

DENY ha in genere la precedenza su altre autorizzazioni. Ad esempio, se a un utente del database viene concessa l'autorizzazione EXECUTE per uno schema ma a un'autorizzazione EXECUTE per un stored procedure in tale schema, l'utente non può visualizzare i metadati per tale stored procedure.

Inoltre, se a un utente viene negata l'autorizzazione EXECUTE per uno schema ma è stata concessa l'autorizzazione EXECUTE per un stored procedure in tale schema, l'utente non può visualizzare i metadati per tale stored procedure.

Per un altro esempio, se a un utente è stata concessa e negata l'autorizzazione EXECUTE per un stored procedure, possibile tramite le varie appartenenze ai ruoli, DENY ha la precedenza e l'utente non può visualizzare i metadati del stored procedure.

Visibilità dei metadati dei sottocomponenti

La visibilità dei sottocomponenti, quali gli indici, i vincoli CHECK e i trigger, è determinata dalle autorizzazioni per il componente padre. A questi sottocomponenti non è possibile concedere autorizzazioni. Ad esempio, se a un utente sono state concesse autorizzazioni per una tabella, l'utente potrà visualizzare i metadati relativi a tabelle, colonne, indici, vincoli CHECK, trigger e altri sottocomponenti. Un altro esempio è la concessione di SELECT solo a una singola colonna di una determinata tabella: ciò consentirà all'utente a cui viene concessa di visualizzare i metadati dell'intera tabella, incluse tutte le colonne. Un modo per pensare è che l'autorizzazione VIEW DEFINITION funziona solo a livello di entità (la tabella in questo caso) e non è disponibile per gli elenchi di sotto-entità ,ad esempio le espressioni di colonna o di sicurezza.

Il codice seguente illustra questo 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

Metadati accessibili a tutti gli utenti del database

Alcuni metadati devono essere accessibili a tutti gli utenti di un database specifico. Ad esempio, non è possibile concedere autorizzazioni per i filegroup e pertanto non è possibile concedere a un utente l'autorizzazione per la visualizzazione dei metadati di un filegroup. Tutti gli utenti che possono creare una tabella devono tuttavia essere in grado di accedere ai metadati dei filegroup per poter usare le clausole filegroup ON o filegroup TEXTIMAGE_ON dell'istruzione CREATE TABLE.

I metadati restituiti dalle funzioni DB_ID() e DB_NAME() sono visibili a tutti gli utenti.

Si tratta di un elenco delle viste del catalogo visibili per il ruolo pubblico.

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

Vedere anche

GRANT (Transact-SQL)
DENY (Transact-SQL)
REVOKE (Transact-SQL)
Clausola EXECUTE AS (Transact-SQL)
Viste del catalogo (Transact-SQL)
Viste della compatibilità (Transact-SQL)