1. はじめに
Microsoft SQL サーバーは全くの初心者ながら、MSSQL 監査ログを監視する相談が有りましたので、設定手順を以下残しておきたいと思います。ドキュメントは以下になるのですが、初心者には分かり難いところがあったので、その部分を補足しておきたいと思います。
なお、本設定の反映のために Microsoft SQL サーバーの OS 再起動が必要になります。
基幹系データベースの場合はメンテナンスタイミングなども考慮しておきましょう。
2. MSSQL サーバーの監査ログの書き出し先
データベースの監査要件として、Microsoft SQL サーバーには監査ログ機能が備わっています。
設定では以下の三つの方法が提供されていますが、セキュリティや外部へのログ書き出しの要件を考慮すると Windows セキュリティイベントログへの書き出し用途が一番多いのではないかと思います。
| 出力先 | 内容 |
|---|---|
| ファイル | 指定したディレクトリに監査ファイルとして書き込む方法。監査ログを確認するためには、ファイルそのものを読み込む必要があり、可読性が低い。とりあえず貯めておく程度であれば、ファイルサーバなどに置いておくなどが良い。 |
| アプリケーションログ | Windows イベントのアプリケーションログとして監査ログが書き込まれる。但し、誰でも見れてしまうため、セキュリティレベルが低い |
| セキュリティログ | Windows イベントのセキュリティイベントとして書き込まれる。Windows 権限で保護されており、セキュリティを意識するのであればこちらがお勧め |
3. 設定手順
基本的には公式 Docs の手順通りです。
今回、Amazon EC2 に作成した Windows 2022 Server / SQL 2016 Server 環境で試したものを貼っています。
3.1 auditpol コマンドを打ち込む
コマンドプロンプト（管理権限）にて、以下コマンドを打ち込みます。
auditpol /set /subcategory:"application generated" /success:enable /failure:enable
3.2 Windows セキュリティイベントに書き込むために権限を付与する
Windows セキュリティイベントにログを書き込むために、Microsoft SQL サーバーの起動ユーザーに対して権限を付与する必要があります。こちらはローカルセキュリティポリシー (secpol.msc) を用いて、「セキュリティ監査の生成」ポリシーに対してユーザーを付与してあげます。
この設定を反映するために Microsoft Windows Server の再起動が必要になります。
SQL サーバーの起動ユーザーは、SQL Server 構成マネージャーのサーバーのプロパティから調べることが出来ます。
SQL 2016 Serverの場合、デフォルト値はMSSQLSERVERになっていました。
3.3 SQLサーバーの監査ログを設定する
SSMS (SQL Server Management Studio)を用いて、監査ログ + 監査ポリシーの設定を行います。
詳しい設定手順は以下の公式 Docs を参照して下さい。
今回は Windows セキュリティイベントログ宛の保管設定を行ってみます。
「セキュリティ」->「監査」より新規に Windows セキュリティイベントログ書き出し用のプロファイルを作成します。
3.2 に記載した権限の付与とサーバー再起動による反映が行わていると、以下のように監査書き出しが成功します。
次に「サーバー監査の仕様」から監査ログに書き出しポリシーの設定を行います。
個々の監査アクションの設定は細かなパラメータとして任意にユーザー側で設定が出来るようになっています。
全てを有効化するとログ量の増大に繋がったり、パフォーマンスの懸念があるので、必要な監査要件に合わせて有効化することをお勧めします。
要件によって何を有効化するかはお客様次第になりますが、セキュリティ監査用途であれば以下の監査アクションが良いのではと思います。
| パラメータ | 内容 |
|---|---|
| FAILED_LOGIN_GROUP | プリンシパルが SQL Server へのログインを試みて失敗したことを示します。 このクラスのイベントは、新しい接続によって生じることも、接続プールから再利用された接続によって生じることもあります。 |
| FAILED_DATABASE_AUTHENTICATION_GROUP | プリンシパルが包含データベースにログオンしようとして失敗したことを示します。 このクラスのイベントは、新しい接続によって生じることも、接続プールから再利用された接続によって生じることもあります。 このイベントが発生します。 |
| DATABASE_CHANGE_GROUP | このイベントは、データベースが作成、変更、または削除されるときに発生します。 |
| DATABASE_OBJECT_CHANGE_GROUP | このイベントは、スキーマなどのデータベース オブジェクトで、CREATE、ALTER、または DROP ステートメントが実行されたときに発生します。 |
| DATABASE_PERMISSION_CHANGE_GROUP | このイベントは、 SQL Server の任意のユーザーによって、ステートメント権限に対して GRANT、REVOKE、または DENY が実行されるたびに、データベースに対する権限の許可などのデータベース限定のイベントに対して発生します。 |
| USER_CHANGE_PASSWORD_GROUP | このイベントは、包含データベースのユーザーのパスワードが USER ALTER ステートメントを使用して変更されるたびに発生します。 |
| SERVER_OPERATION_GROUP | このイベントは、設定、リソース、外部アクセス、承認の変更などのセキュリティ監査操作が使用されるときに発生します。 |
最後にポリシーの方で有効化を行います。
4. Windows イベントビューアーにて、監査ログを確認する
無事設定が反映され、監査ログとして出力されているかどうか、イベントビューアーで確認します。
Windows セキュリティイベントとして出力されていれば、ソース名**「MSSQLSERVER$AUDIT」**として出力されていることが分かります。
以下はログイン失敗の出力例です。
ここまで確認が出来ていれば、あとは Windows セキュリティイベントログを SIEM などに連携して、監査/検知などに役立てることができます。
5. まとめ
Microsoft SQL サーバーの監査ログの設定は意外と分かり難いのですが、細かな設定を施すことが出来て、また Windows セキュリティイベントログに出力することで監査要件に使えることが分かります。本記事がどなたかの参考になれば幸いです。
＊本稿は、個人の見解に基づいた内容であり、所属する会社の公式見解ではありません。また、いかなる保証を与えるものでもありません。正式な情報は、各製品の販売元にご確認ください。