Koncepty mezipaměti zabezpečení

platí pro: SQL Server Azure SQL DatabaseAzure SQL Managed Instance

Tento článek vysvětluje, jak SQL Server používá mezipaměť zabezpečení k ověření oprávnění, která má vlastník pro přístup k zabezpečitelným objektům.

Účel

Databázový stroj organizuje hierarchickou kolekci entit označovaných jako zabezpečitelné, které je možné zabezpečit pomocí oprávnění. Nejvýznamnějšími zabezpečitelnými objekty jsou servery a databáze, ale oprávnění lze také nastavit na podrobnější úrovni. SQL Server řídí akce principálů na zabezpečitelných objektech tím, že zajišťuje, že mají příslušná oprávnění.

Následující diagram ukazuje, že uživatel, Alice, má přihlášení na úrovni serveru a tři různí uživatelé mapovaní na stejné přihlášení v každé jiné databázi.

K optimalizaci procesu ověřování sql Server používá mezipaměť zabezpečení.

Žádný mezipaměťový proces

Pokud je mezipaměť zabezpečení neplatná, SQL Server se řídí workflowem bez mezipaměti k ověření oprávnění. Tato část popisuje pracovní postup bez mezipaměti.

Abyste si to ukázali, zvažte následující dotaz:

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

Pokud je mezipaměť zabezpečení neplatná, služba před vyřešením dotazu dokončí kroky popsané v následujícím pracovním postupu.

Úlohy SQL Serveru, které neobsahují mezipaměť zabezpečení, zahrnují:

1. Připojte se k instanci.
2. Proveďte ověření přihlášení.
3. Vytvořte token kontextu zabezpečení a přihlašovací token. Podrobnosti o těchto tokenech jsou vysvětleny v další části.
4. Připojte se k databázi.
5. Vytvořte v databázi token uživatele databáze.
6. Zkontrolujte členství v databázových rolích. Například db_datareader, db_datawriter nebo db_owner.
7. Ověřte uživatelská oprávnění pro všechny sloupce, například oprávnění uživatele na t1.Column1 a t2.Column1.
8. Kontroluje uživatelská oprávnění u všech tabulek, jako jsou table1 a table2, a oprávnění schématu na Schema1 a Schema2.
9. Ověřuje oprávnění databáze.

SQL Server tento proces opakuje pro každou roli, do které uživatel patří. Jakmile jsou všechna oprávnění získána, server provede kontrolu, aby bylo zajištěno, že uživatel má v řetězci všechna potřebná udělení, a ani jedno jediné odepření v řetězci. Po dokončení kontroly oprávnění se spustí spuštění dotazu.

Další informace najdete v souhrnu algoritmu kontroly oprávnění.

Pro zjednodušení ověřování sql Server používá mezipaměť zabezpečení.

Definice mezipaměti zabezpečení

Mezipaměť zabezpečení ukládá oprávnění pro uživatele nebo přihlášení pro různé zabezpečitelné objekty v databázi nebo serveru. Jednou z výhod je, že zrychluje provádění dotazů. Než SQL Server spustí dotaz, zkontroluje, jestli má uživatel potřebná oprávnění k různým zabezpečitelným databázím, jako jsou oprávnění na úrovni schématu, oprávnění na úrovni tabulky a oprávnění sloupců.

Objekty mezipaměti zabezpečení

Aby byl pracovní postup vysvětlený v předchozí části rychlejší, SQL Server ukládá do mezipaměti mnoho různých objektů uvnitř mezipamětí zabezpečení. Mezi objekty, které jsou uložené v mezipaměti, patří:

Žeton	Popis
SecContextToken	Kontext zabezpečení celé serverové infrastruktury pro danou entitu je uchováván v rámci této struktury. Obsahuje hashovací tabulku uživatelských tokenů a slouží jako výchozí bod nebo základ pro všechny ostatní mezipaměti. Obsahuje odkazy na přihlašovací token, token uživatele, mezipaměť auditu a mezipaměť TokenPerm. Navíc funguje jako základní token pro přihlášení na úrovni serveru.
LoginToken	Podobá se tokenu kontextu zabezpečení. Obsahuje podrobnosti o principálech na úrovni serveru. Přihlašovací token zahrnuje různé prvky, jako je SID, přihlašovací ID, typ přihlášení, přihlašovací jméno, stav isDisabled a pevné členství role serveru. Kromě toho zahrnuje zvláštní role na úrovni serveru, jako je správce systému a správce zabezpečení.
UserToken	Tato struktura souvisí s hlavními subjekty na úrovni databáze. Obsahuje podrobnosti, jako jsou uživatelské jméno, databázové role, SID, výchozí jazyk, výchozí schéma, ID, role a název. Pro přihlášení existuje jeden token uživatele pro každou databázi.
TokenPerm	Zaznamenává všechna oprávnění pro zabezpečitelný objekt pro UserToken nebo SecContextToken.
TokenAudit	Klíč je třída a ID zabezpečitelného objektu. Položka je sada seznamů obsahující ID auditu pro každou auditovatelnou operaci s objektem. Audit serveru je založený na kontrolách oprávnění, které detailně popisují jednotlivé auditovatelné operace, které má konkrétní uživatel na určitém objektu.
TokenAccessResult	Tato mezipaměť ukládá výsledky kontroly oprávnění dotazu pro jednotlivé dotazy, přičemž každému plánu dotazu odpovídá jedna položka. Je to nejdůležitější a běžně používaná mezipaměť, protože je to první věc, která se kontroluje během provádění dotazu. Aby se zabránilo zahltí mezipaměti ad hoc dotazů, ukládá výsledky kontroly oprávnění dotazu pouze v případě, že se dotaz spustí třikrát.
ObjectPerm	Tato akce zaznamenává všechna oprávnění pro objekt v databázi pro všechny uživatele v databázi. Rozdíl mezi TokenPerm a ObjectPerm spočívá v tom, že TokenPerm je určený pro konkrétního uživatele, zatímco ObjectPerm může být pro všechny uživatele v databázi.

Úložiště cache zabezpečení

Tokeny se ukládají v různých úložištích mezipaměti.

Store	Popis
TokenAndPermUserStore	Jeden velký obchod, který obsahuje všechny následující objekty: - SecContextToken - LoginToken - UserToken - TokenPerm - TokenAudit
SecCtxtACRUserStore	Úložiště výsledků kontroly přístupu (ACR) Každý přihlašovací účet má vlastní samostatné úložiště kontextu zabezpečení uživatele.
ACRUserStore	Úložiště výsledků kontroly přístupu <unique id> - <db id> - <user id> Každý uživatel má samostatné úložiště uživatelů ACR. Například dvě přihlášení s pěti uživateli ve dvou různých databázích odpovídají dvěma SecCtxtACRUserStore a deseti různým ACRUserStore.
ObjectPerm	Jeden na tokeny databáze ObjPerm . Všechny různé prvky zabezpečení v databázi.

Známé problémy

Tato část popisuje problémy s mezipamětí zabezpečení.

Zneplatnění mezipaměti zabezpečení

Různé scénáře můžou aktivovat zneplatnění mezipaměti zabezpečení na úrovni databáze nebo serveru. Pokud dojde k zneplatnění, všechny aktuální položky mezipaměti jsou zneplatněny. Všechny budoucí dotazy a kontroly oprávnění se řídí úplným pracovním postupem Bez mezipaměti, dokud nebudou znovu vyplněny mezipaměti. Zneplatnění může výrazně ovlivnit výkon serveru, zejména při vysokém zatížení, protože všechna aktivní připojení potřebují znovu sestavit položky uložené v mezipaměti. Opakované zneplatnění mezipaměti může tento dopad zhoršit. Zneplatnění databáze master se považuje za zneplatnění pro celou serverovou databázi, což ovlivňuje mezipaměti ve všech databázích v instanci.

SQL Server 2025 zavádí funkci, která zneplatňuje mezipaměti pouze pro konkrétní přihlášení. To znamená, že pokud jsou položky mezipaměti zabezpečení neplatné, ovlivní to jenom ty položky patřící do ovlivněného přihlášení. Pokud například udělíte přihlášení L1 novému oprávnění, zůstanou tokeny pro přihlášení L2 nedotčené.

V počátečním kroku se tato funkce vztahuje na scénáře vytvoření, ALTER a DROP přihlášení a změny oprávnění pro jednotlivá přihlášení. Skupinová přihlášení stále čelí neplatnosti na úrovni serveru.

Následující tabulka uvádí všechny akce DDL (Security Data Definition Language), které zneplatní mezipaměť zabezpečení.

Činnost	Předmět	Scope
CREATE/ALTER/DROP	APPLICATION ROLE SYMMETRIC KEY ASYMMETRIC KEY AUTHORIZATION CERTIFICATE ROLE SCHEMA USER	Zadaná databáze
DROP	Jakýkoli objekt, který se zobrazí v sys.all_objects nebo jakýkoli zabezpečitelný uvedený v seznamu zabezpečitelných databází nebo schématu.	Zadaná databáze
GRANT/DENY/REVOKE	Jakékolioprávnění k zabezpečitelnému objektu obsaženému v databázi nebo schématu.	Zadaná databáze
CREATE/ALTER/DROP	LOGIN (SERVICE) MASTER KEY	instance systému SQL Server
ALTER	DATABASE	Zadaná databáze

Výkon dotazů při růstu velikosti TokenAndPermUserStore

Problémy s výkonem, jako je vysoké využití procesoru a zvýšená spotřeba paměti, mohou být způsobeny nadměrnými položkami v mezipaměti TokenAndPermUserStore. SQL Server ve výchozím nastavení pouze vyčistí položky v této mezipaměti, když zjistí interní zatížení paměti. Na serverech s velkým množstvím paměti RAM však nemusí dojít často k internímu zatížení paměti. S rostoucím nárůstem mezipaměti se zvyšuje doba potřebná k vyhledání existujících položek, které se mají znovu použít. Tuto mezipaměť spravuje zámek, který umožňuje, aby vyhledávání provádělo současně pouze jedno vlákno. V důsledku toho může toto chování vést ke snížení výkonu dotazů a vyššímu využití procesoru.

Řešení problému

SQL Server poskytuje dva trasovací příznaky (TF), které lze použít k nastavení kvóty pro cache TokenAndPermUserStore. Ve výchozím nastavení neexistuje žádná kvóta, což znamená, že mezipaměť může obsahovat neomezený počet položek.

• TF 4618: Omezuje počet položek v TokenAndPermUserStore na 1024.
• TF 4618 a TF 4610: Omezuje počet položek v TokenAndPermUserStore na 8192. Pokud nízký limit počtu záznamů TF 4618 způsobuje jiné problémy s výkonem, doporučuje se používat společně trasovací příznaky 4610 a 4618. Další informace naleznete v tématu Nastavení příznaků trasování pomocí DBCC TRACEON.

Další informace najdete v článku Problémy s výkonem způsobené nadměrnými položkami v mezipaměti TokenAndPermUserStore – SQL Server.

Osvědčené postupy

Tato část obsahuje seznam osvědčených postupů pro optimalizaci pracovního postupu zabezpečení.

Správa uživatelů během nepeakových hodin

Vzhledem k povaze zneplatnění mezipamětí zabezpečení na vysoké úrovni (databáze nebo serveru) proveďte bezpečnostní DDL příkazy mimo pracovní dobu, kdy je zatížení serveru nízké. Pokud během náročných úloh dojde k zneplatnění mezipaměti zabezpečení, může to mít výrazný dopad na výkon celého serveru, protože se mezipaměti zabezpečení znovu naplní.

Použití jednotlivých transakcí pro úpravy oprávnění

Provádění několika operací bezpečnostního DDL (Data Definition Language) v rámci jedné transakce může výrazně zvýšit pravděpodobnost zablokování s jinými aktivními připojeními. Aby se toto riziko zmírnilo, doporučuje se vyhnout provádění více bezpečnostních DDL v jedné transakci. Místo toho spusťte operace DDL související se zabezpečením v samostatných transakcích, abyste minimalizovali kolize zámků.

Související obsah

• Začínáme s oprávněními databázového stroje