Azure SQL Database で監査ログを有効にした場合、既定では Azure SQL Database および Azure Synapse Analytics の監査を設定する に記載されている、次のアクショングループの情報が取得されます。
- BATCH_COMPLETED_GROUP
- SUCCESSFUL_DATABASE_AUTHENTICATION_GROUP
- FAILED_DATABASE_AUTHENTICATION_GROUP
監査ログの保存先として使用する代表的なデータストアとしては、ストレージアカウント / Log Analytics ワークスペースがありますが、ワークロードによっては標準の設定で監査ログを取得すると、Log Analytics ワークスペースのデータインジェストのコストがかなり高くなる可能性があります。
Log Analytics ワークスペースに監査ログを保存する場合、PredicateExpression が使用できる可能性があれば、コストを大きく抑えることができる可能性がありますので、本投稿でまとめておきたいと思います。
Contents
Log Analytics ワークスペースにログを取得する利点
Log Analytics ワークスペースは、ストレージアカウントと比較するとコストは高いですが、Log Analytics ワークスペースにログを取得することで次のような利点があります。
- ログ検索時の検索性能
- Azure モニターを使用した監視との連携
ストレージアカウントに保存した監査ログは、拡張イベントの形式で保存されており、ある程度検索の容易性はあるのですが、大量のログが格納されているケースでは、ログの検索性能は高くないかと思います。ログの検索性能については、Log Analytics ワークスペースのほうが高速となるケースのほうが多いかと。
Log Analytics ワークスペースにログを検索した際のメリットとしては「2.」のほうが大きいかもしれません。
ストレージアカウントに格納されたログは、前述のとおり拡張イベントの形式となっており、T-SQL 等で検索はできるのですが、標準機能では Azure モニターと連携することができません。
Log Analytics ワークスペースに格納したログについては、Azure モニターのアラートで使用することができますので、「特定のイベントが発生した場合」にアラートとして通知することができます。
Log Analytics ワークスペースにログを格納するモチベーションとしては、アラートでの利用が大きな理由になるのではないでしょうか。
PredicateExpression を使用しない取得ログの調整
本投稿のメインは、PredicateExpression を使用したログのフィルタリングとなりますが、SQL Database の監査ログのフィルタリング方法としては、「アクショングループ」「サーバーレベル / データベースレベルの監査設定」を使用した調整のほうがメジャーではないでしょうか。
最初にこれらの方法について触れておきたいと思います。
アクショングループを使用した調整
SQL Database の監査では取得するアクショングループ (イベント) を指定することができ、Azure Portal からは変更できませんが、API を使用した Azure SQL Database 監査の管理 に記載されている、PowerShell 等を使用することで、取得項目についてはカスタマイズすることができます。
既定の情報では不足している場合 / 取得情報が過多でコストが増える場合などは、取得するアクショングループを変更することで取得情報を調整することができます。
サーバーレベル / データベースレベルの監査設定を使用した調整
SQL Database の監査はサーバーレベル (論理サーバー) / データベースレベルの二つの粒度で設定することができます。
サーバーレベルとデータベースレベルの設定は個別に動作し、それぞれで異なる設定を行うことができます。
ストレージアカウントと Log Analytics ワークスペースの両方に監査ログを格納しておきたいが、Log Analytics ワークスペースに格納しておくログを少なくしたい場合は、次のような設定を行うことができます。(サーバーレベルとデータベースレベルの設定は逆でも問題ありません)
- サーバーレベル
- ストレージアカウントと Log Analytics ワークスペースに監査ログを保存
- アクショングループを調整して取得するログを調整
- データベースレベル
- ストレージアカウントに監査ログを保存
- アクショングループは既定の設定で取得
サーバーレベルとデータベースレベルの監査設定は独立して動作しますので、どちらかのレベルで取得するログを調整することで、Log Analytics ワークスペースに取得されるログを削減できる可能性があります。
PredicateExpression を使用しない場合は、これらの方法で監査ログの取得内容を調整することができ、これにより、Log Analytics ワークスペースに保存されるデータを抑え、データインジェストのコストを抑えられる可能性があります。
PredicateExpression を使用した取得ログの調整
前述のアクショングループ、サーバーレベル / データベースレベルの監査設定を使用することで Log Analytics ワークスペースのコストが抑えられれば良いのですが、これらの方法で取得されるログを調整してもコストが想定したより抑えられていない場合は、追加でフィルターの方法を検討する必要があります。
この際に使用できるフィルターとして、AuditAction / PredicateExpression があり、PredicateExpression についてはサーバーレベル / データベースレベルの両方の粒度で使用することができるため、本投稿ではこの設定を利用しています。
設定には、次のコマンドレットを使用することができます。
PredicateExpression は、SQL Server の監査ログ / 拡張イベントのログのフィルター条件のような述語を指定することができ、指定されているアクショングループの情報をさらにフィルターすることができます。
例としては次のようなコマンドレットになります。
Set-AzSqlServerAudit -ResourceGroupName $resourceGroupName -ServerName $serverName `
-LogAnalyticsTargetState Enabled -WorkspaceResourceId $resourceId `
-PredicateExpression "(server_principal_name = 'appliation_db_user') AND (application_name = 'Application1')"
上記の例であれば、特定のユーザー/アプリケーションの情報のみを Log Analytics ワークスペースに取得する設定となるため、Log Analytics に取得されるログを大きくフィルターすることができ、データインジェストのコストを大きく削減することができる可能性があります。
構文としては通常の SQL に近いですが、IN が使用できなかったはずですので、同一列で複数の条件を指定した場合は OR でつないでいく必要があるかと思いますが、SQL Database 監査ログの形式 に記載されているフィールドを指定してログのフィルタリングを行うことができます。
Log Analytics ワークスペースに格納されている監査ログを確認し、明らかに取得が不要な情報がある場合は、アクショングループによるフィルターだけでなく、PredicateExpression を使用したフィルターも組み合わせることで、データインジェストのコストの削減につながる可能性があるかと。