Begrepp för säkerhetscache

gäller för:SQL ServerAzure SQL DatabaseAzure SQL Managed Instance

Den här artikeln beskriver hur SQL Server använder en säkerhetscache för att verifiera behörigheter som ett huvudnamn har för att få åtkomst till skyddsbara filer.

Avsikt

Databasmotorn organiserar en hierarkisk samling entiteter, så kallade skyddsbara objekt, som kan skyddas med behörigheter. De mest framträdande skyddsbara objekten är servrar och databaser, men behörigheter kan också anges på en finare nivå. SQL Server styr säkerhetsprincipalers åtgärder på skyddade objekt genom att se till att de har lämpliga behörigheter.

Följande diagram visar att en användare, Alice, har en inloggning på servernivå och att tre olika användare har mappats till samma inloggning i varje databas.

För att optimera autentiseringsprocessen använder SQL Server en säkerhetscache.

Inget cachearbetsflöde

När säkerhetscachen är ogiltig följer SQL Server ett arbetsflöde utan cache för att verifiera behörigheter. I det här avsnittet beskrivs arbetsflödet utan cache.

Tänk på följande fråga för att demonstrera:

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

När säkerhetscachen är ogiltig slutför tjänsten stegen som beskrivs i följande arbetsflöde innan den löser frågan.

För SQL Server omfattar uppgifterna utan säkerhetscache:

1. Anslut till instansen.
2. Utför inloggningsverifiering.
3. Skapa säkerhetskontexttoken och inloggningstoken. Information om dessa token beskrivs i nästa avsnitt.
4. Anslut till databasen.
5. Skapa en databasanvändartoken i databasen.
6. Kontrollera medlemskapet för databasroller. Till exempel db_datareader, db_datawriter eller db_owner.
7. Kontrollera användarbehörigheter för alla kolumner, till exempel behörigheter för användaren på t1.Column1 och t2.Column1.
8. Kontrollerar användarbehörigheter för alla tabeller, till exempel table1 och table2, och schemabehörigheter för Schema1 och Schema2.
9. Verifierar databasbehörigheter.

SQL Server upprepar processen för varje enskild roll som användaren tillhör. När alla behörigheter har fåtts utför servern en kontroll för att säkerställa att användaren har alla nödvändiga tillstånd i kedjan och ingen enda nekning i kedjan. När behörighetskontrollen är klar utförs frågan.

Mer information finns i Sammanfattning av algoritmen för behörighetskontroll.

För att förenkla valideringen använder SQL Server en säkerhetscache.

Definition av säkerhetscache

Säkerhetscachen lagrar behörigheter för en användare eller en inloggning för olika skyddsbara objekt i en databas eller server. En av fördelarna är att det påskyndar frågekörningen. Innan SQL Server kör en fråga kontrollerar den om användaren har nödvändiga behörigheter för olika databasskyddbara objekt, till exempel behörigheter på schemanivå, behörigheter på tabellnivå och kolumnbehörigheter.

Objekt för säkerhetscache

För att göra arbetsflödet som beskrivs i föregående avsnitt snabbare cachelagrar SQL Server många olika objekt i säkerhetscacheminnen. Några av objekten som cachelagras är:

Lagringsplatser för säkerhetscache

Token lagras i olika cachelager.

Kända problemområden

I det här avsnittet beskrivs problem med säkerhetscachen.

Ogiltiga säkerhetscache

Olika scenarier kan utlösa ogiltigförklaringar av säkerhetscachen på databas- eller servernivå. När en ogiltighet inträffar ogiltigförklaras alla aktuella cacheposter. Alla framtida frågor och behörighetskontroller följer det fullständiga arbetsflödet "Ingen cache" tills cacheminnena fylls i igen. Ogiltighet kan avsevärt påverka serverns prestanda, särskilt vid hög belastning, eftersom alla aktiva anslutningar måste återskapa de cachelagrade posterna. Upprepade cache-ogiltigförklaringar kan göra den här effekten sämre. Ogiltigförklaringar i master-databasen behandlas som serverövergripande ogiltigförklaringar, vilket påverkar cacheminnena i alla databaser på instansen.

SQL Server 2025 introducerar en funktion som ogiltigförklarar cacheminnen för endast en specifik inloggning. Det innebär att när poster i säkerhetscachen är ogiltiga påverkas endast de poster som hör till den berörda inloggningen. Om du till exempel ger inloggningen L1 en ny behörighet påverkas inte token för inloggning l2.

Som ett första steg gäller den här funktionen för inloggningsscenarierna CREATE, ALTER och DROP samt behörighetsändringar för enskilda inloggningar. Gruppinloggningar fortsätter att uppleva ogiltighet på servernivå.

Tabellen nedan visar alla DDL-åtgärder (Security Data Definition Language) som ogiltigförklarar säkerhetscachen.

Frågeprestanda när storleken på TokenAndPermUserStore växer

Prestandaproblem, till exempel hög CPU-användning och ökad minnesförbrukning, kan orsakas av överdrivna poster i TokenAndPermUserStore-cachen. Som standard rensar SQL Server bara poster i cacheminnet när det identifierar internt minnestryck. Men på servrar med gott om RAM-minne kan det hända att internt minnestryck inte uppstår ofta. När cachen växer ökar den tid som krävs för att söka efter befintliga poster för återanvändning. Den här cachen hanteras av en spinlock, vilket gör att endast en tråd kan utföra sökningen i taget. Det här beteendet kan därför leda till lägre frågeprestanda och högre CPU-användning.

Övergångslösning

SQL Server innehåller två spårningsflaggor (TF) som kan användas för att ange en kvot för TokenAndPermUserStore-cachen. Som standard finns det ingen kvot, vilket innebär att cacheminnet kan innehålla ett obegränsat antal poster.

• TF 4618: Begränsar antalet poster i TokenAndPermUserStore till 1024.
• TF 4618 och TF 4610: Begränsar antalet poster i TokenAndPermUserStore till 8192. Om den låga inmatningsgränsen för TF 4618 orsakar andra prestandaproblem rekommenderar vi att du använder spårningsflaggorna 4610 och 4618 tillsammans. Mer information finns i Ange spårningsflaggor med DBCC TRACEON.

Mer information finns i artikeln Prestandaproblem kan orsakas av överdrivna poster i TokenAndPermUserStore-cachen – SQL Server

Metodtips

Det här avsnittet innehåller metodtips för att optimera säkerhetsarbetsflödet.

Användarhantering under oanvända timmar

Med tanke på att säkerhetscacheminnen på hög nivå är ogiltiga (databas-/servernivå) utför du säkerhets-DDL:er under icke-kontorstid när serverbelastningen är låg. Om en ogiltig säkerhetscache inträffar under tunga arbetsbelastningar kan det uppstå en märkbar prestandapåverkan på hela servern när säkerhetscacheminnena fylls i igen.

Använda enkla transaktioner för behörighetsändringar

Om du utför flera DDL-åtgärder (Data Definition Language) för säkerhet inom samma transaktion kan du avsevärt öka risken för att det uppstår dödlägen med andra aktiva anslutningar För att minska den här risken rekommenderar vi att du undviker att köra flera säkerhets-DDL:er i en enda transaktion. Utför i stället säkerhetsrelaterade DDL-operationer i separata transaktioner för att minimera låskonkurrensen.

Relaterat innehåll

• Kom igång med behörigheter för databasmotorn