Concepts du cache de sécurité

s’applique à :SQL ServerAzure SQL DatabaseAzure SQL Managed Instance

Cet article explique comment SQL Server utilise un cache de sécurité pour valider les autorisations qu’un principal doit accéder aux éléments sécurisables.

Objectif

Le moteur de base de données organise une collection hiérarchique d’entités, appelées sécurisables, qui peuvent être sécurisées avec des autorisations. Les éléments sécurisables les plus importants sont des serveurs et des bases de données, mais les autorisations peuvent également être définies à un niveau plus fin. SQL Server contrôle les actions des principaux sur des éléments sécurisables en s’assurant qu’ils disposent des autorisations appropriées.

Le diagramme suivant montre qu’un utilisateur, Alice, dispose d’une connexion au niveau du serveur et que trois utilisateurs différents sont mappés à la même connexion à chaque base de données différente.

Pour optimiser le processus d’authentification, SQL Server utilise un cache de sécurité.

Aucun flux de travail de cache

Lorsque le cache de sécurité n’est pas valide, SQL Server suit un flux de travail sans cache pour valider les autorisations. Cette section décrit le flux de travail sans cache.

Pour illustrer ce qui suit, tenez compte de la requête suivante :

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

Lorsque le cache de sécurité n’est pas valide, le service effectue les étapes décrites dans le flux de travail suivant avant de résoudre la requête.

Pour SQL Server, les tâches sans cache de sécurité sont les suivantes :

1. Connectez-vous à l’instance.
2. Effectuez la validation de connexion.
3. Créez le jeton de contexte de sécurité et le jeton de connexion. Les détails de ces jetons sont expliqués dans la section suivante.
4. Connectez-vous à la base de données .
5. Créez un jeton utilisateur de base de données à l’intérieur de la base de données.
6. Vérifiez l’appartenance des rôles de base de données. Par exemple, db_datareader, db_datawriter ou db_owner.
7. Vérifiez les autorisations utilisateur sur toutes les colonnes, par exemple les autorisations de l’utilisateur sur t1.Column1 et t2.Column1.
8. Vérifie les autorisations utilisateur sur toutes les tables, telles que table1 et table2, et les autorisations de schéma sur Schema1 et Schema2.
9. Vérifie les autorisations de base de données.

SQL Server répète le processus pour chaque rôle auquel appartient l’utilisateur. Une fois toutes les autorisations obtenues, le serveur effectue une vérification pour s’assurer que l’utilisateur dispose de toutes les autorisations nécessaires dans la chaîne et qu’il n'existe aucun refus dans la chaîne. Une fois la vérification des autorisations terminée, l’exécution de la requête commence.

Pour plus d’informations, consultez Résumé de l’algorithme de vérification des autorisations.

Pour simplifier la validation, SQL Server utilise un cache de sécurité.

Définition du cache de sécurité

Le cache de sécurité stocke les autorisations d’un utilisateur ou d’une connexion pour différents objets sécurisables dans une base de données ou un serveur. L’un des avantages est qu’il accélère l’exécution des requêtes. Avant d’exécuter une requête, sql Server vérifie si l’utilisateur dispose des autorisations nécessaires pour différents éléments sécurisables de base de données, tels que les autorisations au niveau du schéma, les autorisations au niveau de la table et les autorisations de colonne.

Objets du cache de sécurité

Pour rendre le flux de travail expliqué plus rapidement dans la section précédente, SQL Server met en cache de nombreux objets différents dans les caches de sécurité. Voici quelques-uns des objets mis en cache :

Jeton	Descriptif
SecContextToken	Le contexte de sécurité à l’échelle du serveur pour un principal est conservé dans cette structure. Il contient une table de hachage de jetons utilisateur et sert de point de départ et de base pour tous les autres caches. Inclut des références au jeton de connexion, au jeton utilisateur, au cache d’audit et au cache TokenPerm. En outre, il agit comme jeton de base pour une connexion au niveau du serveur.
LoginToken	Similaire au jeton de contexte de sécurité. Contient les détails des comptes principaux au niveau du serveur. Le jeton de connexion inclut différents éléments tels que SID, ID de connexion, type de connexion, nom de connexion, état isDisabled et appartenance au rôle fixe du serveur. En outre, il englobe des rôles spéciaux au niveau du serveur, tels que l’administrateur système et l’administrateur de sécurité.
UserToken	Cette structure est liée aux entités principales au niveau de la base de données. Il inclut des détails tels que le nom d’utilisateur, les rôles de base de données, le SID, le langage par défaut, le schéma par défaut, l’ID, les rôles et le nom. Il existe un jeton utilisateur par base de données pour une connexion.
TokenPerm	Enregistre toutes les autorisations pour un objet sécurisable pour un UserToken ou SecContextToken.
TokenAudit	La clé est la classe et l’ID d’un objet sécurisable. L’entrée est une série de listes contenant des ID d’audit pour chaque opération auditable sur un objet. L’audit du serveur est basé sur des vérifications d’autorisation, détaillant chaque opération auditable qu’un utilisateur spécifique a sur un objet particulier.
TokenAccessResult	Ce cache stocke les résultats de la vérification des autorisations de requête pour les requêtes individuelles, avec une entrée par plan de requête. Il s’agit du cache le plus important et couramment utilisé, car il s’agit de la première chose vérifiée lors de l’exécution de la requête. Pour empêcher les requêtes ad hoc d’inonder le cache, il stocke uniquement les résultats de la vérification des autorisations de requête si la requête est exécutée trois fois.
ObjectPerm	Cela enregistre toutes les autorisations d’un objet dans la base de données pour tous les utilisateurs de la base de données. La différence entre TokenPerm et ObjectPerm est que TokenPerm concerne un utilisateur spécifique, tandis que ObjectPerm peut être pour tous les utilisateurs de la base de données.

Stockage de cache de sécurité

Les jetons sont stockés dans différents magasins de cache.

Magasin	Descriptif
TokenAndPermUserStore	Un grand magasin qui contient tous les objets suivants : - SecContextToken - LoginToken - UserToken - TokenPerm - TokenAudit
SecCtxtACRUserStore	Stockage de résultats de vérification d’accès (ACR). Chaque connexion possède son propre contexte de sécurité utilisateur distinct.
ACRUserStore	Magasin de résultats de vérification d’accès <unique id> - <db id> - <user id> Chaque utilisateur dispose d’un stockage utilisateur ACR individuel. Par exemple, deux connexions avec cinq utilisateurs dans deux bases de données différentes s’élèvent à deux SecCtxtACRUserStore et 10 différentes ACRUserStore.
ObjectPerm	Un par jeton de base de données ObjPerm . Tous les éléments sécurisables dans la base de données.

Problèmes connus

Cette section décrit les problèmes liés au cache de sécurité.

Invalidations du cache de sécurité

Différents scénarios peuvent déclencher des invalidations du cache de sécurité au niveau de la base de données ou du serveur. Lorsqu’une invalidation se produit, toutes les entrées de cache actuelles sont invalidées. Toutes les futures requêtes et vérifications d’autorisation suivent le flux de travail « Aucun cache » complet jusqu’à ce que les caches soient remplis à nouveau. L’invalidation peut avoir un impact significatif sur les performances du serveur, en particulier en cas de charge élevée, car toutes les connexions actives doivent reconstruire les entrées mises en cache. Les invalidations répétées du cache peuvent aggraver cet impact. Les invalidations dans la master base de données sont traitées comme des invalidations à l’échelle du serveur, affectant les caches dans toutes les bases de données de l’instance.

SQL Server 2025 introduit une fonctionnalité qui invalide les caches pour une connexion spécifique uniquement. Cela signifie que lorsque les entrées du cache de sécurité sont invalidées, seules les entrées appartenant à la connexion affectée sont affectées. Par exemple, si vous accordez une nouvelle autorisation à la connexion L1, les jetons de connexion L2 ne sont pas affectés.

À titre d’étape initiale, cette fonctionnalité s’applique aux scénarios de connexion CREATE, ALTER et DROP, ainsi qu’aux modifications d’autorisation pour les connexions individuelles. Les connexions de groupe continuent à rencontrer une invalidation au niveau du serveur.

Le tableau ci-dessous répertorie toutes les actions DDL (Security Data Definition Language) qui invalident le cache de sécurité.

Action	Sujet	Étendue
CREATE/ALTER/DROP	APPLICATION ROLE SYMMETRIC KEY ASYMMETRIC KEY AUTHORIZATION CERTIFICATE ROLE SCHEMA USER	Base de données spécifiée
DROP	Tout objet qui apparaît dans sys.all_objects ou tout sécurisable listé dans la base de données ou dans la liste des sécurisables à l'échelle du schéma.	Base de données spécifiée
GRANT/DENY/REVOKE	Touteautorisation de sécurisable contenue par la base de données ou le schéma.	Base de données spécifiée
CREATE/ALTER/DROP	LOGIN (SERVICE) MASTER KEY	Instance de SQL Server
ALTER	DATABASE	Base de données spécifiée

Performances des requêtes lorsque la taille de TokenAndPermUserStore augmente

Les problèmes de performances, tels que l’utilisation élevée du processeur et la consommation accrue de mémoire, peuvent être causés par des entrées excessives dans le cache TokenAndPermUserStore. Par défaut, SQL Server nettoie uniquement les entrées de ce cache lorsqu’il détecte la sollicitation de la mémoire interne. Toutefois, sur les serveurs avec beaucoup de RAM, la sollicitation de la mémoire interne peut ne pas se produire fréquemment. À mesure que le cache augmente, le temps nécessaire à la recherche d’entrées existantes à réutiliser augmente. Ce cache est géré par un spinlock, ce qui permet à un seul thread d’effectuer la recherche à la fois. Par conséquent, ce comportement peut entraîner une diminution des performances des requêtes et une utilisation plus élevée du processeur.

Contournement

SQL Server fournit deux indicateurs de trace (TF) qui peuvent être utilisés pour définir un quota pour le cache TokenAndPermUserStore. Par défaut, il n’existe aucun quota, ce qui signifie que le cache peut contenir un nombre illimité d’entrées.

• TF 4618 : Limite le nombre d’entrées dans TokenAndPermUserStore à 1024.
• TF 4618 et TF 4610 : limite le nombre d’entrées dans TokenAndPermUserStore à 8192. Si la limite de nombre d’entrées faible de TF 4618 provoque d’autres problèmes de performances, il est recommandé d’utiliser ensemble les indicateurs de trace 4610 et 4618. Pour plus d’informations, consultez Définir des indicateurs de trace avec DBCC TRACEON.

Pour plus d’informations, vous pouvez consulter l’article Problèmes de performances pouvant être provoqués par des entrées excessives dans le cache TokenAndPermUserStore - SQL Server

Meilleures pratiques

Cette section répertorie les meilleures pratiques pour optimiser le flux de travail de sécurité.

Gestion des utilisateurs pendant les heures creuses

Compte tenu de la nature générale de l’invalidation des caches de sécurité (niveau base de données/serveur), effectuez des DLL de sécurité pendant les heures non commerciales lorsque la charge du serveur est faible. Si une invalidation du cache de sécurité se produit pendant les charges de travail lourdes, il peut y avoir un impact notable sur les performances sur l’ensemble du serveur, car les caches de sécurité sont remplis à nouveau.

Utiliser des transactions uniques pour les modifications d’autorisation

L’exécution de plusieurs opérations DDL (Security Data Definition Language) au sein de la même transaction peut augmenter considérablement la probabilité de rencontrer des interblocages avec d’autres connexions actives pour atténuer ce risque, il est recommandé d’éviter d’exécuter plusieurs DLL de sécurité dans une seule transaction. Au lieu de cela, exécutez des opérations DDL en lien avec la sécurité dans des transactions distinctes pour réduire la contention des verrous.

Contenu connexe

• Pour commencer avec les autorisations du moteur de base de données