Основные понятия кэша безопасности

2025-05-20

Область применения:SQL Server База данных SQL Azure Управляемый экземпляр SQL Azure

В этой статье объясняется, как SQL Server использует кэш безопасности для проверки разрешений, которые субъект имеет на доступ к защищаемым ресурсам.

Цель

Ядро СУБД упорядочивает иерархическую коллекцию сущностей, известных как защищаемые объекты, которые можно защитить с помощью разрешений. Наиболее известные защищаемые объекты — это серверы и базы данных, но разрешения также можно задать на более точном уровне. SQL Server управляет действиями субъектов в защищаемых объектах, обеспечивая наличие соответствующих разрешений.

На следующей схеме показано, что пользователь, Алиса, имеет имя входа на уровне сервера и три разных пользователя, сопоставленных с одинаковым именем входа в каждой базе данных.

Для оптимизации процесса проверки подлинности SQL Server использует кэш безопасности.

Без кэширования рабочего процесса.

Если кэш безопасности недопустим, SQL Server следует рабочему процессу без кэша для проверки разрешений. В этом разделе описывается рабочий процесс без кэша.

Чтобы продемонстрировать, рассмотрим следующий запрос:

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

Если кэш безопасности недопустим, служба выполняет действия, описанные в следующем рабочем процессе, прежде чем разрешить запрос.

Схема представляет рабочий процесс без кэша.

Для SQL Server задачи без кэша безопасности включают:

Подключитесь к инстансу.
Выполните проверку входа.
Создайте маркер контекста безопасности и маркер входа. Подробные сведения об этих маркерах описаны в следующем разделе.
Выполните подключение к базе данных.
Создайте маркер пользователя базы данных внутри базы данных.
Проверьте членство в ролях базы данных. Например, db_datareader, db_datawriter или db_owner.
Проверьте разрешения пользователя на всех столбцах, например разрешения пользователя t1.Column1 и t2.Column1.
Проверяет разрешения пользователей во всех таблицах, таких как table1 и table2, и разрешения на схемы для Schema1 и Schema2.
Проверяет разрешения базы данных.

SQL Server повторяет процесс для каждой роли, к которой принадлежит пользователь. После получения всех разрешений сервер выполняет проверку, чтобы убедиться, что у пользователя есть все необходимые права в цепочке и нет ни одного запрета в цепочке. После завершения проверки разрешений начнется выполнение запроса.

Дополнительные сведения см. в сводке по алгоритму проверки разрешений.

Для упрощения проверки SQL Server использует кэш безопасности.

Определение кэша безопасности

Кэш безопасности сохраняет разрешения для пользователя или входа для различных защищаемых объектов в базе данных или сервере. Одним из преимуществ является ускорение выполнения запроса. Прежде чем SQL Server выполнит запрос, он проверяет, имеет ли пользователь необходимые разрешения для различных защищаемых баз данных, таких как разрешения уровня схемы, разрешения на уровне таблицы и разрешения столбцов.

Объекты кэша безопасности

Чтобы сделать рабочий процесс более быстрым в предыдущем разделе, SQL Server кэширует множество различных объектов в кэшах безопасности. К некоторым объектам, кэшируемым относятся:

Токен	Описание
`SecContextToken`	Контекст безопасности на уровне сервера для субъекта хранится в этой структуре. Он содержит хэш-файл маркеров пользователей и служит отправной точкой или базой для всех остальных кэшей. Содержит ссылки на маркер входа, маркер пользователя, кэш аудита и кэш TokenPerm. Кроме того, он служит базовым токеном для авторизации на уровне сервера.
`LoginToken`	Аналогично маркеру контекста безопасности. Содержит сведения о главных компонентах уровня сервера. Маркер входа включает различные элементы, такие как SID, идентификатор входа, тип входа, имя входа, состояние isDisabled и членство в предопределенных роях сервера. Кроме того, она включает специальные роли на уровне сервера, такие как системный администратор и администратор безопасности.
`UserToken`	Эта структура связана с субъектами уровня базы данных. Она содержит такие сведения, как имя пользователя, роли базы данных, SID, язык по умолчанию, схема по умолчанию, ID, роли и имя. Для входа существует один маркер пользователя для каждой базы данных.
`TokenPerm`	Регистрирует все разрешения для защищаемого объекта для UserToken или SecContextToken.
`TokenAudit`	Ключ — это класс и идентификатор защищаемого объекта. Запись представляет собой ряд списков, содержащих идентификаторы аудита для каждой проверяемой операции на объекте. Аудит сервера основан на проверках разрешений, подробных сведений о каждой операции аудита, которая имеет конкретный пользователь в определенном объекте.
`TokenAccessResult`	В этом кэше хранятся результаты проверки разрешений для отдельных запросов с одной записью для каждого плана запроса. Это наиболее важный и часто используемый кэш, так как это первое, что проверяется во время выполнения запроса. Чтобы предотвратить переполнение кэша нерегламентированными запросами, он сохраняет только результаты проверки разрешений, если запрос выполняется три раза.
`ObjectPerm`	При этом записываются все разрешения для объекта в базе данных для всех пользователей в базе данных. Разница между TokenPerm и ObjectPerm заключается в том, что TokenPerm предназначен для конкретного пользователя, а ObjectPerm может быть для всех пользователей в базе данных.

Хранилища кэша безопасности

Маркеры хранятся в разных хранилищах кэша.

Магазин	Описание
`TokenAndPermUserStore`	Одно большое хранилище, содержащее все следующие объекты: - `SecContextToken` - `LoginToken` - `UserToken` - `TokenPerm` - `TokenAudit`
`SecCtxtACRUserStore`	Хранилище результатов проверки доступа (ACR). У каждой учетной записи для входа есть собственное отдельное хранилище пользовательского контекста безопасности.
`ACRUserStore`	Хранилище результатов проверки доступа `<unique id>` - `<db id>` - `<user id>` У каждого пользователя есть отдельное хранилище пользователей ACR. Например, два сеанса входа с пятью пользователями в двух разных базах данных эквивалентны двум `SecCtxtACRUserStore` и 10 различным `ACRUserStore`.
`ObjectPerm`	Один токен на базу данных `ObjPerm`. Все различные защищаемые объекты в базе данных.

Известные проблемы

В этом разделе описываются проблемы с кэшем безопасности.

Инвалидации кэша безопасности

Различные сценарии могут активировать недопустимые операции кэша безопасности на уровне базы данных или сервера. При возникновении недопустимости все текущие записи кэша являются недействительными. Все будущие запросы и проверки разрешений следуют полному процессу "Без кэша", пока кэши не будут вновь заполнены. Аннулирование может значительно повлиять на производительность сервера, особенно при высокой нагрузке, так как всем активным подключениям нужно заново кэшировать записи. Повторяющиеся аннулирования кеша могут усилить это воздействие. Аннулирования в master базе данных рассматриваются как аннулирования на уровне сервера, влияющие на кэши во всех базах данных экземпляра.

В SQL Server 2025 представлена функция, которая делает кэши недействительными только для определенного имени входа. Это означает, что при недопустимых записях кэша безопасности затрагиваются только те записи, принадлежащие к затронутому имени входа. Например, если вы предоставляете имя входа L1 новое разрешение, токены для входа L2 остаются без изменений.

В качестве начального шага эта функция применяется к сценариям создания, изменения и удаления логинов и изменениям прав доступа для отдельных логинов. Имена входа групп продолжают работать с недопустимыми на уровне сервера.

В приведенной ниже таблице перечислены все действия языка определения данных безопасности (DDL), которые недействительна для кэша безопасности.

Действие	Тема	Область действия
`CREATE/ALTER/DROP`	`APPLICATION ROLE` `SYMMETRIC KEY` `ASYMMETRIC KEY` `AUTHORIZATION` `CERTIFICATE` `ROLE` `SCHEMA` `USER`	Указанная база данных
`DROP`	Любой объект, который отображается в sys.all_objects или любой защищаемый объект, указанный в списке защищаемых баз данных или области схемы.	Указанная база данных
`GRANT/DENY/REVOKE`	Любоеразрешение на защищаемую базу данных или схему.	Указанная база данных
`CREATE/ALTER/DROP`	`LOGIN` (`SERVICE`) `MASTER KEY`	экземпляр SQL Server
`ALTER`	`DATABASE`	Указанная база данных

Производительность запроса при росте размера TokenAndPermUserStore

Проблемы с производительностью, такие как высокая загрузка ЦП и увеличение потребления памяти, могут быть вызваны чрезмерными записями в кэше TokenAndPermUserStore. По умолчанию SQL Server очищает записи в этом кэше только при обнаружении внутреннего давления памяти. Однако на серверах с большим объемом ОЗУ внутренняя нагрузка на память может возникать не часто. По мере роста кэша увеличивается время, необходимое для поиска существующих записей для повторного использования. Этот кэш управляется спинблоком, что позволяет одновременно выполнять поиск только одним потоком. Следовательно, это поведение может привести к снижению производительности запросов и более высокому использованию ЦП.

Обходной путь

SQL Server предоставляет два флага трассировки (TF), которые можно использовать для задания квоты для кэша TokenAndPermUserStore. По умолчанию квота отсутствует, то есть кэш может содержать неограниченное количество записей.

TF 4618: ограничивает количество записей в TokenAndPermUserStore до 1024.
TF 4618 и TF 4610: ограничивает количество записей в TokenAndPermUserStore до 8192. Если низкий предел количества записей TF 4618 вызывает другие проблемы с производительностью, рекомендуется использовать флаги трассировки 4610 и 4618 вместе. Дополнительные сведения см. в разделе DBCC TRACEON — флаги трассировки (Transact-SQL).

Дополнительные сведения см. в статье о проблемах с производительностью, которые могут быть вызваны чрезмерными записями в кэше TokenAndPermUserStore — SQL Server

Лучшие практики

В этом разделе перечислены рекомендации по оптимизации рабочего процесса безопасности.

Управление пользователями в непиковые часы

Учитывая высокий уровень недопустимости кэшей безопасности (уровень базы данных или сервера), выполняйте DDL безопасности в нерабочие часы, когда нагрузка сервера низка. Если недопустимый кэш безопасности возникает во время тяжелых рабочих нагрузок, это может оказать заметное влияние на производительность всего сервера, так как кэши безопасности повторяются.

Использование отдельных транзакций для изменений разрешений

Выполнение нескольких операций языка определения данных безопасности (DDL) в одной транзакции может значительно увеличить вероятность возникновения взаимоблокировок с другими активными подключениями. Чтобы уменьшить этот риск, рекомендуется избегать выполнения нескольких DDL безопасности в одной транзакции. Вместо этого выполните операции DDL, связанные с безопасностью, в отдельных транзакциях, чтобы свести к минимуму конфликт блокировки.

Начните работу с разрешениями диспетчера базы данных