セキュリティ ログへの SQL Server 監査イベントの書き込み
適用対象: 
SQL Server - Windows のみ
高度なセキュリティ環境では、オブジェクト アクセスを記録するイベントを書き込むのに適切な場所は Windows セキュリティ ログです。 他の監査場所は、サポートされていますが、改ざんされる可能性が高くなります。
SQL Server サーバー監査を Windows セキュリティ ログに書き込むための主要な要件は 3 つあります。
オブジェクト アクセスの監査の設定は、イベントをキャプチャするように構成する必要があります。 監査ポリシー ツール (
auditpol.exe) は、オブジェクト アクセスの監査 カテゴリでさまざまなサブポリシー設定を公開しています。 SQL Server がオブジェクト アクセスを監査できるようにするには、アプリケーションが生成した設定を構成します。SQL Server サービスを実行しているアカウントは、Windows セキュリティ ログに書き込むための セキュリティ監査の生成 権限を持っている必要があります。 既定では、LOCAL SERVICE アカウントおよび NETWORK SERVICE アカウントにこの権限があります。 SQL Server がこれらのアカウントのいずれかで実行されている場合、この手順は必要ありません。
レジストリ ハイブ
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\EventLog\Securityへの SQL Server サービス アカウントに完全なアクセス許可を提供します。重要
レジストリを誤って編集すると、システムに重大な障害が発生する場合があります。 レジストリを変更する前に、コンピューター上のすべての重要なデータをバックアップしてください。
制限事項と制約事項
セキュリティ ログのローカル設定は、ドメイン ポリシーによって上書きできます。 この場合、ドメイン ポリシーによってサブカテゴリ設定 (
auditpol /get /subcategory:"application generated") が上書きされる可能性があります。 SQL Server には、監査しようとしているイベントが記録されていないことを検出する方法はありません。監査ポリシーが正しく構成されていないと、イベントが失われる可能性があります。 Windows セキュリティ ログに書き込むよう構成されている場合、Windows 監査ポリシーは SQL Server 監査に影響を与える可能性があります。 通常、Windows セキュリティ ログは、古いイベントを上書きするよう設定されます。 これにより、最新のイベントが保持されます。 ただし、Windows セキュリティ ログが古いイベントを上書きするよう設定されていない場合、セキュリティ ログがいっぱいになると、システムは Windows イベント 1104 (ログがいっぱいです) を発行します。 この段階で、次の状況になります。
それ以降のセキュリティ イベントは記録されません
SQL Server はシステムがイベントをセキュリティ ログに記録できないことを検出できないため、監査イベントが失われる場合があります。
ボックス管理者によってセキュリティ ログが修復されると、ログ動作は正常に戻ります。
SQL Server 監査レコードには、通常の Windows イベント ログ エントリよりも大幅に多くのデータが含まれています。 さらに、監査仕様の構成によって、SQL Server が短期間 (1 秒あたり数千件) に何千もの監査レコードを生成する場合があります。 負荷が高い期間には、監査レコードがアプリケーション ログまたはセキュリティ ログに書き込まれると、この状態が悪くなる可能性があります。
これらの有害な条件は次のとおりです。
イベント ログの急速な循環 (ログ ファイルがサイズ制限に達すると、イベントは非常に迅速に上書きされます)
Windows イベント ログから読み取られたデータが悪影響を受ける可能性があるその他のアプリケーションおよびサービス
対象のイベント ログは、イベントがすぐに上書きされるため、管理者が使用できない可能性があります
管理者がこれらの悪影響を軽減するために実行できる手順:
ターゲット ログのサイズを大きくします (監査仕様が非常に詳細な場合には、4 GB は不合理ではありません)。
監査されるイベントの数を減らします。
監査レコードをイベント ログではなくファイルに出力します。
アクセス許可
これらの設定を行うには、Windows 管理者である必要があります。
auditpol を使用した Windows のオブジェクト アクセスの監査の設定
管理権限を使用してコマンド プロンプトを開きます。
[スタート] メニューから [コマンド プロンプト] に移動し、[管理者として実行] を選択します。
[ユーザー アカウント制御] ダイアログ ボックスが表示されたら、[続行]を選択します。
次のステートメントを実行して、SQL Server からの監査を有効にします。
auditpol /set /subcategory:"application generated" /success:enable /failure:enableコマンド プロンプト ウィンドウを閉じます。
secpol を使用した "セキュリティ監査の生成" 権限のアカウントへの許可
任意の Windows オペレーティング システムで、[スタート] メニューで、[ファイル名を指定して実行]を選択します。
「
secpol.msc」を入力して、[OK] を選択します。 [ユーザー アクセス制御] ダイアログ ボックスが表示されたら、 [続行]を選択します。ローカル セキュリティ ポリシー ツールで、[セキュリティ設定] > [ローカル ポリシー] > [ユーザー権利の割り当て] に移動します。
結果ペインで [セキュリティ監査の生成] を開きます。
[ローカル セキュリティの設定] タブの [ユーザーまたはグループの追加]を選択します。
[ユーザー、コンピューター、またはグループの選択] ダイアログ ボックスで、ユーザー アカウントの名前 ( domain1\user1 など) を入力して [OK]を選択するか、 [詳細設定] を選択してアカウントを検索します。
[OK] を選択します。
セキュリティ ポリシー ツールを閉じます。
この設定を有効にするために SQL Server を再起動します。
secpol を使用した Windows のオブジェクト アクセスの監査の設定
Windows Vista または Windows Server 2008 より前のオペレーティング システムでは、[スタート] メニューで [実行] を選択します。
「
secpol.msc」を入力して、[OK] を選択します。 [ユーザー アクセス制御] ダイアログ ボックスが表示されたら、 [続行]を選択します。ローカル セキュリティ ポリシー ツールで、[セキュリティ設定] [> ローカル ポリシー]、[> 監査ポリシー] の順に移動します。
結果ペインで、[オブジェクト アクセスの監査]を開きます。
[ローカル セキュリティの設定] タブの [次の場合に監査する] で、 [成功] チェック ボックスと [失敗]チェック ボックスの両方をオンにします。
[OK] を選択します。
セキュリティ ポリシー ツールを閉じます。
関連項目
フィードバック
以下は間もなく提供いたします。2024 年を通じて、コンテンツのフィードバック メカニズムとして GitHub の issue を段階的に廃止し、新しいフィードバック システムに置き換えます。 詳細については、「https://aka.ms/ContentUserFeedback」を参照してください。
フィードバックの送信と表示