Configurazione della visibilità dei metadati

Si applica a:SQL ServerAzure SQL DatabaseAzure SQL Managed InstanceAzure Synapse AnalyticsSistema di Piattaforma Analitica (PDW)Database SQL in Microsoft Fabric

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 l'utente concede un'autorizzazione, SELECT ad esempio o INSERT nella tabella myTable.

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

Tuttavia, se l'utente non dispone dell'autorizzazione per myTable, la query restituisce un set di risultati vuoto.

Ambito e impatto della configurazione della visibilità dei metadati

La configurazione della visibilità dei metadati si applica solo alle entità a protezione diretta seguenti:

• Viste del catalogo
• Metadati che espongono funzioni predefinite
• Viste di compatibilità
• Stored procedure del motore sp_help di database
• Viste degli schemi delle informazioni
• Proprietà estese

La configurazione della visibilità dei metadati non si applica alle 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
• Tabelle di sistema di SQL Server Agent
• Tabelle di sistema di backup
• Stored procedure di replica e SQL Server Agent sp_help

Un'accessibilità limitata ai metadati comporta quanto segue:

• È 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 predefinite di creazione di metadati, ad esempio OBJECTPROPERTYEX, possono restituire NULL.
• È possibile che le stored procedure sp_help del motore di database restituiscano solo un sottoinsieme di righe o NULL.
• Di conseguenza, le applicazioni che presuppongono l'accesso ai metadati pubblici risultano interrotte.

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, invece, viene 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 VIEW DEFINITION l'autorizzazione, oppure, a partire da SQL Server 2022 (16.x) e versioni successive, concedere VIEW SECURITY DEFINITION o VIEW PERFORMANCE DEFINITION al livello appropriato: livello di oggetto, livello di database o livello di server. Pertanto, nell'esempio precedente, se il chiamante dispone dell'autorizzazione su VIEW DEFINITION, la stored procedure restituirà una riga. Per altre informazioni, vedere GRANT e GRANT - Autorizzazioni di database.

È 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

È possibile usare EXECUTE AS per passare temporaneamente al contesto di sicurezza del chiamante. Per altre informazioni, vedere EXECUTE AS.

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.

È teoricamente possibile forzare l'emissione di metadati nei messaggi di errore modificando l'ordine di valutazione del predicato nelle query. La possibilità di attacchi di valutazione ed errori non è specifica di SQL Server. È implicita dalle 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, Il compromesso è che i messaggi di errore sono terse e potrebbero essere difficili da usare a scopo di debug. Per altre informazioni, vedere Opzioni di avvio del servizio motore di database e flag di traccia.

I metadati seguenti non sono soggetti alla divulgazione forzata:

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

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

  • L'utente possiede VIEW DEFINITION l'autorizzazione sull'oggetto.

  • L'utente non è stato negato il permesso VIEW DEFINITION sull'oggetto e ha il permesso CONTROL, ALTER o TAKE OWNERSHIP sull'oggetto. Tutti gli altri utenti vedono 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

• La colonna ctext nella visualizzazione compatibilità syscomments.

• L'output della procedura sp_helptext.

• 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

• OBJECT_DEFINITION() funzione

• Il valore archiviato nella colonna password_hash di sys.sql_logins. Un utente che non ha CONTROL SERVER, o che nelle versioni SQL Server 2022 (16.x) e successive non ha l'autorizzazione VIEW ANY CRYPTOGRAPHICALLY SECURED DEFINITION, visualizza un valore NULL in questa colonna.

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

Nota

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

Principi generali di 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

Ruoli predefiniti e autorizzazioni implicite

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, SELECT l'autorizzazione per uno schema implica che l'utente dispone SELECT dell'autorizzazione per tutti gli oggetti protetti contenuti in tale schema. La concessione dell'autorizzazione SELECT per uno schema consente pertanto a un utente di visualizzare i metadati dello schema e anche di tutte le tabelle, viste, funzioni, procedure, code, sinonimi, tipi e raccolte di XML Schema al suo interno. Per ulteriori informazioni sugli ambiti, vedere Gerarchia delle autorizzazioni (Motore di database).

Nota

L'autorizzazione UNMASK non influisce sulla visibilità dei metadati: concedendo UNMASK da solo non vengono divulgati metadati. UNMASK deve essere sempre accompagnato da un'autorizzazione SELECT per avere qualsiasi effetto. Esempio: la concessione UNMASK all'ambito del database e la concessione SELECT in una singola tabella ha il risultato che l'utente può visualizzare solo i metadati della singola tabella da cui è possibile selezionare, non altri.

Precedenza di DENY

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

Inoltre, se a un utente viene negata EXECUTE l'autorizzazione per uno schema ma è stata concessa EXECUTE l'autorizzazione per una 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 EXECUTE l'autorizzazione per una stored procedure, che è possibile tramite le varie appartenenze ai ruoli, DENY ha la precedenza e l'utente non può visualizzare i metadati della stored procedure.

Visibilità dei metadati dei sottocomponenti

La visibilità dei sottocomponenti, ad esempio indici, vincoli check e trigger, è determinata dalle autorizzazioni per l'elemento padre. Questi sottocomponenti non dispongono di autorizzazioni concesse. 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 consiste nel concedere SELECT solo una singola colonna di una determinata tabella: ciò consente all'utente autorizzato di visualizzare i metadati dell'intera tabella, incluse tutte le colonne. Un modo per considerarlo è che l'autorizzazione VIEW DEFINITION funziona solo a livello di entità (la tabella in questo caso) e non è disponibile per gli elenchi di sottoentità (ad esempio le espressioni di colonna o di sicurezza).

Il codice di seguito dimostra 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 the 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, i filegroup non dispongono di autorizzazioni conferibili; pertanto, non è possibile concedere a un utente l'autorizzazione per visualizzare i metadati di un filegroup. Tuttavia, qualsiasi utente che può creare una tabella deve essere in grado di accedere ai metadati del filegroup per usare le clausole ON <filegroup> o TEXTIMAGE_ON <filegroup> dell'istruzione CREATE TABLE.

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

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

• 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

Contenuti correlati

• SOVVENZIONE (Transact-SQL)
• NEGA (Transact-SQL)
• REVOCA (Transact-SQL)
• Clausola EXECUTE AS (Transact-SQL)
• Viste del catalogo di sistema (Transact-SQL)
• Viste di compatibilità del sistema (Transact-SQL)