セキュリティ キャッシュの概念

適用対象:SQL ServerAzure SQL DatabaseAzure SQL Managed Instance

この記事では、SQL Server がセキュリティ キャッシュを使用して、プリンシパルがセキュリティ保護可能なリソースにアクセスするために必要なアクセス許可を検証する方法について説明します。

目的

データベース エンジンは、セキュリティ保護可能なエンティティ (セキュリティ保護可能なエンティティと呼ばれます) の階層コレクションを整理します。これは、アクセス許可で保護できます。 最も目立つセキュリティ保護可能なリソースはサーバーとデータベースですが、アクセス許可は細かいレベルで設定することもできます。 SQL Server は、セキュリティ保護可能なリソースに対するプリンシパルのアクションを、適切なアクセス許可を持っていることを確認することによって制御します。

次の図は、ユーザー Alice がサーバー レベルでログインし、3 人の異なるユーザーが各データベースで同じログインにマップされていることを示しています。

認証プロセスを最適化するために、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 の場合、セキュリティ キャッシュのないタスクは次のとおりです。

1. インスタンスに接続します。
2. ログイン検証を実行します。
3. セキュリティ コンテキスト トークンとログイン トークンを作成します。 これらのトークンの詳細については、次のセクションで説明します。
4. データベースに接続します。
5. データベース内にデータベース ユーザー トークンを作成します。
6. データベース ロールのメンバーシップを確認します。 たとえば、db_datareader、db_datawriter、db_ownerなどです。
7. t1.Column1とt2.Column1に対するユーザーのアクセス許可など、すべての列に対するユーザーのアクセス許可を確認します。
8. table1やtable2など、すべてのテーブルに対するユーザーのアクセス許可と、Schema1とSchema2に対するスキーマのアクセス許可を確認します。
9. データベースのアクセス許可を確認します。

SQL Server は、ユーザーが属するすべてのロールに対してプロセスを繰り返します。 すべてのアクセス許可が取得されると、サーバーはチェックを実行して、ユーザーがチェーン内で 1 つの拒否ではなく、必要なすべての許可をチェーンに持っていることを確認します。 アクセス許可チェックが完了すると、クエリの実行が開始されます。

詳細については、 アクセス許可チェック アルゴリズムの概要を確認してください。

検証を簡略化するために、SQL Server はセキュリティ キャッシュを使用します。

セキュリティ キャッシュの定義

セキュリティ キャッシュには、データベースまたはサーバー内のさまざまなセキュリティ保護可能なオブジェクトに対するユーザーまたはログインのアクセス許可が格納されます。 利点の 1 つは、クエリの実行速度が向上することです。 SQL Server は、クエリを実行する前に、スキーマ レベルのアクセス許可、テーブル レベルのアクセス許可、列のアクセス許可など、さまざまなデータベース セキュリティ保護可能なリソースに必要なアクセス許可をユーザーが持っているかどうかを確認します。

セキュリティ キャッシュ オブジェクト

前のセクションで説明したワークフローをより速くするために、SQL Server はセキュリティ キャッシュ内にさまざまなオブジェクトをキャッシュします。 キャッシュされるオブジェクトには、次のようなものがあります。

セキュリティ キャッシュ ストア

トークンは、異なるキャッシュ ストア内に格納されます。

既知の問題

このセクションでは、セキュリティ キャッシュに関する問題について説明します。

セキュリティ キャッシュの無効化

さまざまなシナリオで、データベース レベルまたはサーバー レベルでセキュリティ キャッシュの無効化をトリガーできます。 無効化が発生すると、現在のすべてのキャッシュ エントリが無効になります。 今後のすべてのクエリとアクセス許可チェックは、キャッシュが再作成されるまで、完全な "キャッシュなし" ワークフローに従います。 無効化は、キャッシュされたエントリを再構築する必要があるアクティブな接続がすべて必要な場合に、特に負荷が高い場合に、サーバーのパフォーマンスに大きな影響を与える可能性があります。 キャッシュの無効化を繰り返し実行すると、この影響が悪化する可能性があります。 master データベースの無効化はサーバー全体の無効化として扱われ、インスタンス上のすべてのデータベースのキャッシュに影響します。

SQL Server 2025 では、特定のログインに対してのみキャッシュを無効にする機能が導入されています。 つまり、セキュリティ キャッシュ エントリが無効になると、影響を受けるログインに属するエントリのみが影響を受けます。 たとえば、ログイン L1 に新しいアクセス許可を付与した場合、ログイン L2 のトークンは影響を受けません。

最初の手順として、この機能は、CREATE、ALTER、DROP ログインのシナリオ、および個々のログインのアクセス許可の変更に適用されます。 グループ ログインでは、サーバー レベルの無効化が引き続き発生します。

次の表に、セキュリティ キャッシュを無効にするすべてのセキュリティ データ定義言語 (DDL) アクションを示します。

TokenAndPermUserStore のサイズが大きくなるときのクエリ パフォーマンス

高い CPU 使用率やメモリ消費量の増加などのパフォーマンスの問題は、TokenAndPermUserStore キャッシュ内のエントリが過剰に発生する可能性があります。 既定では、SQL Server は、内部メモリ不足を検出した場合にのみ、このキャッシュ内のエントリをクリーンアップします。 ただし、RAM が十分なサーバーでは、内部メモリの負荷が頻繁に発生しない可能性があります。 キャッシュが大きくなると、再利用するために既存のエントリを検索するのに必要な時間が長くなります。 このキャッシュはスピンロックによって管理され、一度に検索を実行できるスレッドは 1 つだけです。 その結果、この動作によって、クエリのパフォーマンスが低下し、CPU 使用率が高くなる可能性があります。

対処法

SQL Server には、TokenAndPermUserStore キャッシュのクォータを設定するために使用できる 2 つのトレース フラグ (TF) が用意されています。 既定では、クォータはありません。つまり、キャッシュは無制限の数のエントリを保持できます。

• TF 4618: TokenAndPermUserStore のエントリ数を 1024 に制限します。
• TF 4618 および TF 4610: TokenAndPermUserStore のエントリ数を 8192 に制限します。 TF 4618 のエントリ数の制限が低い場合は、他のパフォーマンスの問題が発生する場合は、トレース フラグ 4610 と 4618 を一緒に使用することをお勧めします。 詳細については、「 DBCC TRACEON - トレース フラグ (Transact-SQL)」を参照してください。

詳細については、TokenAndPermUserStore キャッシュ内の過剰なエントリが原因で発生する可能性があるパフォーマンスの問題に関する記事を参照してください。

ベスト プラクティス

このセクションでは、セキュリティ ワークフローを最適化するためのベスト プラクティスを示します。

ピーク時以外のユーザー管理

セキュリティ キャッシュの高レベルの無効化の性質 (データベース/サーバー レベル) を考えると、サーバーの負荷が低い非ビジネス時間帯にセキュリティ DFL を実行します。 負荷の高いワークロード中にセキュリティ キャッシュの無効化が発生した場合、セキュリティ キャッシュが再入力されるため、サーバー全体のパフォーマンスに大きな影響を与える可能性があります。

アクセス許可の変更に 1 つのトランザクションを使用する

同じトランザクション内で複数のセキュリティ データ定義言語 (DDL) 操作を実行すると、他のアクティブな接続でデッドロックが発生する可能性が大幅に高まる可能性があります。このリスクを軽減するには、1 つのトランザクションで複数のセキュリティ DDL を実行しないようにすることをお勧めします。 代わりに、セキュリティ関連の DDL 操作を個別のトランザクションで実行して、ロックの競合を最小限に抑えます。

関連コンテンツ

• データベース エンジンのアクセス許可を開始する