Konfiguration av metadatasynlighet

gäller för:SQL ServerAzure SQL DatabaseAzure SQL Managed InstanceAzure Synapse AnalyticsAnalytics Platform System (PDW)

Synligheten för metadata är begränsad till skyddsbara data som en användare antingen äger eller som användaren har beviljats viss behörighet för.

Följande fråga returnerar till exempel en rad om användaren har beviljats en behörighet, till exempel SELECT eller INSERT i tabellen myTable.

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

Men om användaren inte har någon behörighet på myTablereturnerar frågan en tom resultatuppsättning.

Omfång och påverkan av konfiguration av metadatasynlighet

Konfiguration av metadatasynlighet gäller endast för följande skyddsbara objekt.

Konfigurationen av metadatasynlighet gäller inte för följande skyddsbara funktioner.

Begränsad metadatatillgänglighet innebär följande:

• Frågor om systemvyer kanske bara returnerar en delmängd rader, eller ibland en tom resultatuppsättning.

• Inbyggda funktioner som avger metadata, såsom OBJECTPROPERTYEX, kan returnera NULL.

• Databasmotorn sp_help lagrade procedurer kan möjligen bara returnera en delmängd rader eller NULL.

• Därför bryts program som förutsätter åtkomst till offentliga metadata.

SQL-moduler, till exempel lagrade procedurer och utlösare, körs under anroparens säkerhetskontext och har därför begränsad metadatatillgänglighet. I följande kod returneras till exempel en tom resultatuppsättning när den lagrade proceduren försöker komma åt metadata för tabellen myTable där anroparen inte har några rättigheter. I tidigare versioner av SQL Server returneras en rad.

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

Om du vill tillåta användare att visa metadata kan du ge dem behörighet att visa definitioner: antingen behörigheten VISA DEFINITION eller, från och med SQL Server 2022, antingen VISA SÄKERHETSDEFINITION eller VISA PRESTANDADEFINITION på lämplig nivå: objektnivå, databasnivå eller servernivå. I föregående exempel returnerar därför den lagrade proceduren en rad om anroparen har behörigheten VIEW DEFINITION på myTable. Mer information finns i GRANT (Transact-SQL) och GRANT Database Permissions (Transact-SQL).

Du kan också ändra den lagrade proceduren så att den körs under ägarens autentiseringsuppgifter. När procedurägaren och tabellägaren är samma ägare gäller ägarskapslänkning och säkerhetskontexten för procedurens ägare ger åtkomst till metadata för myTable. I det här scenariot returnerar följande kod en rad metadata till anroparen.

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  

Fördelar och gränser för konfiguration av metadatasynlighet

Konfiguration av metadatasynlighet kan spela en viktig roll i din övergripande säkerhetsplan. Det finns dock fall där en kompetent och bestämd användare kan tvinga fram avslöjande av vissa metadata. Vi rekommenderar att du distribuerar metadatabehörigheter som ett av många djupgående skydd.

Det är teoretiskt möjligt att framtvinga utsläpp av metadata i felmeddelanden genom att ändra ordningen på predikatutvärdering i frågor. Risken för sådana försök-och-misstag-attacker är inte specifik för SQL Server. Det är underförstått av de associativa och kommutativa transformeringar som tillåts i relationsalgebra. Du kan minska den här risken genom att begränsa den information som returneras i felmeddelanden. Om du vill begränsa synligheten för metadata ytterligare på det här sättet kan du starta servern med spårningsflagga 3625. Den här spårningsflaggan begränsar mängden information som visas i felmeddelanden. Detta bidrar i sin tur till att förhindra framtvingade avslöjanden. Kompromissen är att felmeddelanden blir terse och kan vara svåra att använda i felsökningssyfte. Mer information finns i startalternativen för Database Engine Service och Trace Flags (Transact-SQL).

Följande metadata är inte föremål för tvångsupplysning:

• Värdet som lagras i kolumnen provider_string i sys.servers. En användare som inte har ÄNDRA NÅGON LÄNKAD SERVER behörighet ser ett NULL värde i den här kolumnen.

• Källdefinition för ett användardefinierat objekt, till exempel en lagrad procedur eller utlösare. Källkoden visas bara när något av följande är sant:

  • Användaren har behörigheten VIEW DEFINITION på objektet.

  • Användaren har inte nekats VIEW DEFINITION behörighet för objektet och har CONTROL, ALTEReller TA ÄGARSKAP behörighet för objektet. Alla andra användare ser NULL.

• Definitionskolumnerna som finns i följande katalogvyer:

  • sys.all_sql_modules
  • sys.server_sql_modules
  • sys.default_constraints
  • sys.numbered_procedures
  • sys.sql_modules
  • sys.check_constraints
  • sys.computed_columns

• Kolumnen ctext i kompatibilitetsvyn syscomments.

• Utdata från sp_helptext-proceduren.

• Följande kolumner i informationsschemavyerna:

  • 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

• Funktionen OBJECT_DEFINITION()

• Värdet som lagras i kolumnen password_hash i sys.sql_logins. En användare som inte har behörigheten CONTROL SERVER eller, från och med SQL Server 2022, behörigheten VISA ALL KRYPTOSÄKER DEFINITION kommer att se ett NULL-värde i denna kolumn.

Allmänna principer för synlighet för metadata

Följande är några allmänna principer att tänka på när det gäller metadatasynlighet:

• Implicita behörigheter för fasta roller

• Behörigheternas omfattning

• Prioritet för DENY

• Synlighet för underkomponentmetadata

Fasta roller och implicita behörigheter

Metadata som kan nås av fasta roller beror på deras motsvarande implicita behörigheter.

Behörighetsomfång

Behörigheter i ett omfång innebär möjligheten att se metadata i det omfånget och alla inneslutna omfång. Till exempel innebär SELECT- behörighet för ett schema att mottagaren har SELECT- behörighet för alla skyddsbara objekt som ingår i detta schema. Beviljandet av SELECT- behörighet för ett schema gör det därför möjligt för en användare att se metadata för schemat och även alla tabeller, vyer, funktioner, procedurer, köer, synonymer, typer och XML-schemasamlingar i det. Mer information om omfång finns i Behörighetshierarki (databasmotor).

Prioritet för DENY

NEKA har vanligtvis företräde framför andra behörigheter. Om en databasanvändare till exempel beviljas KÖR behörighet för ett schema men har nekats KÖR behörighet för en lagrad procedur i schemat, kan användaren inte visa metadata för den lagrade proceduren.

Om en användare nekas KÖR behörighet för ett schema men har beviljats behörigheten EXECUTE för en lagrad procedur i schemat kan användaren inte visa metadata för den lagrade proceduren.

Om en användare till exempel har beviljats och nekats EXECUTE- behörighet för en lagrad procedur, vilket är möjligt genom dina olika rollmedlemskap, har NEKA företräde och användaren kan inte visa metadata för den lagrade proceduren.

Synlighet för underkomponentmetadata

Synligheten för underkomponenter, till exempel index, kontrollvillkor och utlösare, bestäms av de behörigheter som gäller för den överordnade enheten. Dessa underkomponenter har inte behörigheter som kan beviljas. Om en användare till exempel har beviljats viss behörighet i en tabell kan användaren visa metadata för tabeller, kolumner, index, kontrollbegränsningar, utlösare och andra sådana underkomponenter. Ett annat exempel är att bevilja SELECT- på endast en enskild kolumn i en viss tabell: detta gör att beviljare kan visa metadata för hela tabellen, inklusive alla kolumner. Ett sätt att tänka på det är att VIEW DEFINITION behörighet endast fungerar på entitetsnivå (tabellen i det här fallet) och inte är tillgänglig för underentitetslistor (till exempel kolumn- eller säkerhetsuttryck).

Följande kod visar det här beteendet:

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

Metadata som är tillgängliga för alla databasanvändare

Vissa metadata måste vara tillgängliga för alla användare i en specifik databas. Filgrupper har till exempel inte delegeringsbara behörigheter. Därför kan inte en användare beviljas behörighet att visa metadata för en filgrupp. Dock måste alla användare som kan skapa en tabell kunna komma åt filgruppsmetadata för att använda filgruppen ON eller filgruppen TEXTIMAGE_ON -satsen i CREATE TABLE-instruktionen.

Metadata som returneras av funktionerna DB_ID() och DB_NAME() är synliga för alla användare.

Det här är en lista över de katalogvyer som är synliga för den offentliga rollen.

Se även

GRANT (Transact-SQL)
NEKA (Transact-SQL)
ÅTERKALLA (Transact-SQL)
EXECUTE AS-klausulen (Transact-SQL)
katalogvyer (Transact-SQL)
Kompatibilitetsvyer (Transact-SQL)