Concepten van beveiligingscache

Van toepassing op:SQL ServerAzure SQL DatabaseAzure SQL Managed Instance

In dit artikel wordt uitgelegd hoe SQL Server gebruikmaakt van een beveiligingscache om te valideren welke machtigingen een principal heeft voor toegang tot beveiligbare items.

Doel

De database-engine organiseert een hiërarchische verzameling entiteiten, ook wel beveiligbare entiteiten genoemd, die kan worden beveiligd met machtigingen. De meest prominente beveiligbare items zijn servers en databases, maar machtigingen kunnen ook op een nauwkeuriger niveau worden ingesteld. SQL Server bepaalt de acties van principals op beveiligbare apparaten door ervoor te zorgen dat ze over de juiste machtigingen beschikken.

In het volgende diagram ziet u dat een gebruiker, Alice, een aanmelding op serverniveau heeft en dat drie verschillende gebruikers zijn toegewezen aan dezelfde aanmelding bij elke verschillende database.

Sql Server maakt gebruik van een beveiligingscache om het verificatieproces te optimaliseren.

Geen cachewerkstroom

Wanneer de beveiligingscache ongeldig is, volgt SQL Server een werkstroom zonder cache om machtigingen te valideren. In deze sectie wordt de werkstroom voor geen cache beschreven.

Bekijk de volgende query om dit te demonstreren:

SELECT t1.Column1,
       t2.Column1
FROM Schema1.Table1 AS t1
     INNER JOIN Schema2.Table2 AS t2
         ON t1.Column1 = t2.Column2;

Wanneer de beveiligingscache ongeldig is, voert de service de stappen uit die worden beschreven in de volgende werkstroom voordat de query wordt omgezet.

Voor SQL Server zijn de taken zonder een beveiligingscache onder andere:

1. Maak verbinding met de instantie.
2. Voer de aanmeldingsvalidatie uit.
3. Maak het token voor de beveiligingscontext en het aanmeldingstoken. Details van deze tokens worden uitgelegd in de volgende sectie.
4. Maak verbinding met de database.
5. Maak een token voor de databasegebruiker binnen de database.
6. Controleer het lidmaatschap van databaserollen. Bijvoorbeeld: db_datareader, db_datawriter of db_owner.
7. Controleer gebruikersmachtigingen voor alle kolommen, bijvoorbeeld de machtigingen van de gebruiker op t1.Column1 en t2.Column1.
8. Controleert gebruikersmachtigingen op alle tabellen, zoals table1 en table2, en schemamachtigingen op Schema1 en Schema2.
9. Controleert databasemachtigingen.

SQL Server herhaalt het proces voor elke rol waartoe de gebruiker behoort. Zodra alle machtigingen zijn verkregen, voert de server een controle uit om ervoor te zorgen dat de gebruiker alle benodigde subsidies in de keten heeft en niet één weigering in de keten. Nadat de machtigingscontrole is voltooid, wordt de uitvoering van de query gestart.

Raadpleeg samenvatting van het machtigingscontrole-algoritme voor meer informatie.

Ter vereenvoudiging van de validatie maakt SQL Server gebruik van een beveiligingscache.

Definitie van beveiligingscache

De beveiligingscache slaat machtigingen op voor een gebruiker of een aanmelding voor verschillende beveiligbare objecten in een database of server. Een van de voordelen is dat het de uitvoering van query's versnelt. Voordat SQL Server een query uitvoert, wordt gecontroleerd of de gebruiker over de benodigde machtigingen beschikt voor verschillende databasebeveiligbare databases, zoals machtigingen op schemaniveau, machtigingen op tabelniveau en kolommachtigingen.

Beveiligingscacheobjecten

Om de werkstroom in de vorige sectie sneller te laten verklaren, slaat SQL Server veel verschillende objecten in beveiligingscaches op. Enkele van de objecten die in de cache zijn opgeslagen, zijn:

Teken	Beschrijving
SecContextToken	De serverbrede beveiligingscontext voor een principal wordt in deze structuur bewaard. Het bevat een hashtabel van gebruikerstokens en fungeert als het beginpunt of de basis voor alle andere caches. Bevat verwijzingen naar het aanmeldingstoken, het gebruikerstoken, de auditcache en de TokenPerm-cache. Daarnaast fungeert het als het basistoken voor een aanmelding op serverniveau.
LoginToken	Vergelijkbaar met het beveiliging contexttoken. Bevat details van principals op serverniveau. Het aanmeldingstoken bevat verschillende elementen zoals SID, aanmeldings-id, aanmeldingstype, aanmeldingsnaam, isDisabled-status en lidmaatschap van vaste serverfuncties. Daarnaast omvat het speciale functies op serverniveau, zoals sysadmin en beveiligingsbeheerder.
UserToken	Deze structuur is gerelateerd aan principals op databaseniveau. Het bevat details zoals gebruikersnaam, databaserollen, SID, standaardtaal, standaardschema, id, rollen en naam. Er is één gebruikerstoken per database voor een aanmelding.
TokenPerm	Registreert alle machtigingen voor een beveiligbaar object voor een UserToken of SecContextToken.
TokenAudit	De sleutel is de klasse en id van een beveiligbaar object. De vermelding is een reeks lijsten met audit-ID's voor elke auditbare bewerking op een object. Servercontrole is gebaseerd op machtigingscontroles, waarbij elke controleerbare bewerking wordt beschreven die een specifieke gebruiker op een bepaald object heeft.
TokenAccessResult	In deze cache worden de resultaten van querymachtigingen voor afzonderlijke query's opgeslagen, met één vermelding per queryplan. Het is de belangrijkste en veelgebruikte cache, omdat dit het eerste is dat is gecontroleerd tijdens het uitvoeren van query's. Om te voorkomen dat ad-hocquery's de cache overspoelen, worden alleen controleresultaten van querymachtigingen opgeslagen als de query drie keer wordt uitgevoerd.
ObjectPerm	Hiermee worden alle machtigingen voor een object in de database vastgelegd voor alle gebruikers in de database. Het verschil tussen TokenPerm en ObjectPerm is dat TokenPerm voor een specifieke gebruiker is, terwijl ObjectPerm voor alle gebruikers in de database kan zijn.

Beveiligingscachearchieven

De tokens worden opgeslagen in verschillende cachearchieven.

Opslaan	Beschrijving
TokenAndPermUserStore	Eén grote winkel die alle volgende objecten bevat: - SecContextToken - LoginToken - UserToken - TokenPerm - TokenAudit
SecCtxtACRUserStore	Access Check Result (ACR)-archief. Elke inlog heeft een eigen, afzonderlijke beveiligingscontext gebruikersopslag.
ACRUserStore	Archief met resultaten van toegangscontrole <unique id> - <db id> - <user id> Elke gebruiker heeft een afzonderlijk ACR-gebruikersarchief. Twee aanmeldingen met vijf gebruikers in twee verschillende databases zijn bijvoorbeeld twee SecCtxtACRUserStore en 10 verschillende ACRUserStore.
ObjectPerm	Eén per database-token ObjPerm. Alle verschillende beveiligbare objecten in de database.

Bekende problemen

In deze sectie worden problemen met de beveiligingscache beschreven.

Ongeldigmaken van beveiligingscache

Verschillende scenario's kunnen ongeldige beveiligingscaches activeren op database- of serverniveau. Wanneer er een invalidering plaatsvindt, worden alle huidige cache-items ongeldig. Alle toekomstige query's en machtigingscontroles volgen de volledige werkstroom 'Geen cache' totdat de caches opnieuw worden ingevuld. Invalidering kan aanzienlijk van invloed zijn op de serverprestaties, met name bij hoge belasting, omdat alle actieve verbindingen de in de cache opgeslagen items opnieuw moeten samenstellen. Herhaalde ongeldige caches kunnen deze impact slechter maken. Ongeldige gegevens in de master database worden beschouwd als ongeldige servergegevens, die van invloed zijn op de caches in alle databases op het exemplaar.

SQL Server 2025 introduceert een functie die caches ongeldig maakt voor alleen een specifieke aanmelding. Dit betekent dat wanneer vermeldingen in de beveiligingscache ongeldig zijn, alleen de vermeldingen die behoren tot de betrokken aanmelding, worden beïnvloed. Als u bijvoorbeeld aanmelding L1 een nieuwe machtiging verleent, blijven de tokens voor aanmelding L2 ongewijzigd.

In eerste instantie is deze functie van toepassing op de aanmeldingsscenario's CREATE, ALTER en DROP, en op wijzigingen in machtigingen voor afzonderlijke aanmeldingen. Groepsaanmelding blijft ongeldig op serverniveau.

De onderstaande tabel bevat alle DDL-acties (Security Data Definition Language) die de beveiligingscache ongeldig maken.

Handeling	Onderwerp	Omvang
CREATE/ALTER/DROP	APPLICATION ROLE SYMMETRIC KEY ASYMMETRIC KEY AUTHORIZATION CERTIFICATE ROLE SCHEMA USER	Opgegeven database
DROP	Elk object dat wordt weergegeven in sys.all_objects of een beveiligbare lijst die wordt vermeld in de database of een lijst met beveiligbare schema's.	Opgegeven database
GRANT/DENY/REVOKE	Elketoestemming voor een beveiligbaar object in een database of schema.	Opgegeven database
CREATE/ALTER/DROP	LOGIN (SERVICE) MASTER KEY	SQL Server exemplaar
ALTER	DATABASE	Opgegeven database

Queryprestaties wanneer de grootte van TokenAndPermUserStore groeit

Prestatieproblemen, zoals een hoog CPU-gebruik en een verhoogd geheugenverbruik, kunnen worden veroorzaakt door overmatige vermeldingen in de Cache TokenAndPermUserStore. Sql Server schoont standaard alleen vermeldingen in deze cache op wanneer interne geheugenbelasting wordt gedetecteerd. Op servers met veel RAM-geheugen kan interne geheugenbelasting echter niet vaak optreden. Naarmate de cache toeneemt, neemt de tijd die nodig is om te zoeken naar bestaande vermeldingen om opnieuw te gebruiken toe. Deze cache wordt beheerd door een spinlock, waardoor slechts één thread tegelijk de zoekopdracht kan uitvoeren. Daarom kan dit gedrag leiden tot verminderde queryprestaties en een hoger CPU-gebruik.

Tijdelijke maatregel

SQL Server biedt twee traceringsvlagken (TF) die kunnen worden gebruikt om een quotum in te stellen voor de TokenAndPermUserStore-cache. Er is standaard geen quotum, wat betekent dat de cache een onbeperkt aantal vermeldingen kan bevatten.

• TF 4618: Beperkt het aantal vermeldingen in de TokenAndPermUserStore tot 1024.
• TF 4618 en TF 4610: Beperkt het aantal vermeldingen in de TokenAndPermUserStore tot 8192. Als de limiet voor laag invoeraantal van TF 4618 andere prestatieproblemen veroorzaakt, is het raadzaam om traceringsvlaggen 4610 en 4618 gelijktijdig te gebruiken. Zie Traceringsvlagmen instellen met DBCC TRACEON voor meer informatie.

Voor meer informatie raadpleegt u het artikel Prestatieproblemen kunnen worden veroorzaakt door overmatige vermeldingen in de Cache TokenAndPermUserStore - SQL Server

Beste praktijken

In deze sectie vindt u aanbevolen procedures voor het optimaliseren van de beveiligingswerkstroom.

Gebruikersbeheer tijdens niet-peakuren

Gezien de ongeldige aard van beveiligingscaches op hoog niveau (database-/serverniveau), voert u beveiligings-DDLs uit tijdens niet-bedrijfsuren wanneer de serverbelasting laag is. Als een ongeldige beveiligingscache optreedt tijdens zware werkbelastingen, kan dit een merkbare invloed hebben op de prestaties op de hele server, omdat de beveiligingscaches opnieuw worden ingevuld.

Enkele transacties gebruiken voor machtigingswijzigingen

Het uitvoeren van meerdere DDL-bewerkingen (Security Data Definition Language) binnen dezelfde transactie kan de kans op impasses met andere actieve verbindingen aanzienlijk verhogen Om dit risico te beperken, is het raadzaam om te voorkomen dat meerdere beveiligings-DDLs in één transactie worden uitgevoerd. Voer in plaats daarvan DDL-bewerkingen met betrekking tot beveiliging uit in afzonderlijke transacties om vergrendelingsconflicten te minimaliseren.

Verwante inhoud

• Aan de slag met database-enginemachtigingen