Azure SQL Database の監査ログについて、いろいろと情報を整理しておく必要があったので。
監査ログについては、次のドキュメントツリーから情報を確認することができます。
Contents
監査ログの基本的な仕様について
監査ログの取得精度
Azure SQL Database の監査ログは、SQL Server の監査ログ とは異なる仕組みとなっており、「拡張イベント」をベースとした情報の取得となっています。
拡張イベントをベースとしているため、監査ログには次のような制限があります。
Azure SQL Database、Azure Synapse Analytics SQL プール、Azure SQL Managed Instance の監査は、監査対象のデータベースまたはインスタンスの可用性とパフォーマンスに対して最適化されています。 アクティビティが非常に高い、またはネットワーク負荷が高い期間中、監査機能は、監査対象としてマークされたすべてのイベントを記録せずにトランザクションが続行するのを許可する場合があります。
Azure SQL Database の監査ログはすべてのイベントを抜けなく取得するのではなく、パフォーマンスを重視して監査ログが取得されるため、負荷が高い期間については一部のイベントはログの取得がスキップされることで監査による性能の劣化を抑えられます。
現在の仕様としては「厳密な監査ログの取得」は実施することはできず、厳密な監査ログの取得が必要な場合は、SQL Server on Azure VM の利用を検討する必要があります。
ポリシーのレベル
SQL Database では「サーバーレベルの監査ポリシー」と「データベースレベルの監査ポリシー」の二種類のポリシーのレベルがサポートされています。
「サーバーレベルの監査ポリシー」は論理サーバー全体に対して設定が行われるポリシーとなり、既存のデータベース / これから新規に作成するデータベースに対して、同一の設定で監査の設定が反映されます。
「データベースレベルの監査ポリシー」はデータベース単位に異なる設定を行うことができます。
サーバーレベルの監査とデータベースレベルの両方の設定を設定することができますが、各設定は重複して動作することになりますので、サーバーレベルの監査とデータベースレベルの監査の両方で情報が取得されることになります。
サーバーレベルの監査とデータベースレベルの監査では、一般的にストレージアカウントと Log Analytics ワークスペースに対して監査ログの取得を行います。
監査ログの形式については SQL Database 監査ログの形式 に記載されています。
一般的に使用する監査ログの取得先
ストレージアカウント
ストレージアカウントに出力する場合、「sqlauditlogs」というコンテナーにデータベース単位で次のディレクトリが作成されます。
- サーバーレベルの監査: SqlDbAuditing_ServerAudit
- 保有期間無制限 (0) に指定した場合は、SqlDbAuditing_ServerAudit_NoRetention ディレクトリが作成されます。
- データベースレベルの監査: SqlDbAuditing_Audit
- 保有期間無制限 (0) に指定した場合は、SqlDbAuditing_Audit_NoRetention ディレクトリが作成されます。
「サーバーレベルの監査」については、二つの特殊なディレクトリが存在します。
サーバーレベルの監査では、Microsoft サポート操作の監査 という特殊な監査も有効化することができ、この操作に該当するログについては「MSDevOpsAudit_NoRetention」というディレクトリに出力がされます。
もう一つが「master データベース」に対しての操作となります。master データベースに対しての操作は、個別に監査の設定を有効にすることはできず、サーバーレベルの監査の設定が引き継がれるようになっており、master が対象となる操作については、サーバーレベルの監査で監査ログを取得する必要があります。
Log Analytics ワークスペース
Log Analytics ワークスペースに監査ログを取得する場合、個別テーブルは作成されず「AzureDiagnostics テーブル」にサーバーレベル / データベースレベルの両方のログが格納されます。
サーバーレベルの監査ポリシーで取得されたログレコードについては「is_server_level_audit_s」が「true」(where is_server_level_audit_s =~ ‘true’) かどうかで判断することができます。(サーバーレベルの監査は Resource が MASTER となっていそうでもあります)
サーバーレベルとデータベースレベルの両方で同一の設定のアクショングループにより、 Log Analytics ワークスペースに出力をすると同一のテーブルに類似のレコードが 2 回記録されることになります。
Log Analytics ワークスペースのコスト については Analytics ログとしてコスト発生し、従量課金で使用すると月額のコストは小量のデータでもそれなりに高いコストが発生する可能性があります。
30 日間分の Log Analytics の保有コストについては、送信するデータを減らす以外にコストを削減する方法がないため、Log Analytics ワークスペースに送信する監査ログについては必要なものに限定して送信することができないかを検討する必要があります。(サーバーレベルとデータベースレベルで同一のアクショングループを取得しないようにするのも送信されるデータ量を減らすポイントとなります)
基本はストレージアカウントにログを保持し、Azure Monitor のアラートルールと連携したい場合には、関連するアクショングループのイベントのみを Log Analytics ワークスペースに送信するというような設定を行うことができるかも考慮点となります。
Event Hub
ストレージアカウント / Log Analytics ワークスペース以外の監査ログの取得先として、Event Hub を選択することができます。
Event Hub に出力したデータを Stream Analytics でサポートしている出力先 に出力するということができます。
Stream Analytics と組み合わせて使用する場合、Stream Analytics クエリ により、情報のフィルタリングをすることができますので、特定のイベントのみを処理したいという場合には Event Hub の利用も検討できます。
Azure Data Explorer (ADX) では、Stream Analytics を使用しなくても Event Hub のデータを直接取り込む ことができます。Stream Analytics と異なり、クエリにより取り込みの条件を記載することはできませんが、すべてのログを取り込んで問題ないのであれば、Stream Analytics を介さなくてもよいかもしれません。
ADX へのデータ取り込みについては、ADX Free Cluster でも実施することができます。ただし、Free Cluster は 使用できる機能に差 があり、ログ検索アラート を使用する場合には有償版のクラスターを使用する必要があり、Log Analytics ワークスペースのような、特定のログが出力された場合にアラートを通知したいという場合にはコストが発生します。
Stream Analytics では、Log Analytics ワークスペースにログを取り込むことはできませんが、Azure Monitor の機能を使用することで、Event Hub からデータを取り込むことができます。
ただしこの機能は、必須コンポーネント に記載されているように、従量課金の Log Analytics ワークスペースでは使用することができないので、この方法を使用する場合にはコストはそれなりにかかるのではないでしょうか。
デフォルトで取得されるアクショングループ
監査ログで取得される項目は「アクショングループ」という単位で取得項目を制御することができます。
Azure SQL Database で設定可能なアクショングループについては、次のコマンドレットの情報から確認をすることができます。
- PowerShell
- Az CLI
- REST API
Azure SQL Database および Azure Synapse Analytics の監査を設定する に記載されていますが、サーバーレベル / データベースレベルともに、デフォルトでは次のアクショングループが設定されています。
- SUCCESSFUL_DATABASE_AUTHENTICATION_GROUP
- FAILED_DATABASE_AUTHENTICATION_GROUP
- BATCH_COMPLETED_GROUP
アクショングループ以外のログのフィルタリング
アクショングループで取得するイベントを選択することができますが、イベントの取捨選択をするために、次のような方法も提供されています。
取得するイベントの取捨選択は Azure Portal から実施することはできないため、Az CLI か Azure PowerShell を使用する必要があります。
Audit Action を指定した取得情報のフィルタリング
取得するイベントについてはアクショングループ (Audit Action Group) 以外に、Audit Action を指定することができます。
PowerShell で設定する場合、AuditAction というオプションを使用することでアクショングループではなく特定の操作についてのログを取得することができます。
PowerShell を使用する場合は次のようなコマンドとなります。
Set-AzSqlDatabaseAudit -ResourceGroupName "<リソースグループ名>" -ServerName "<サーバー名>" -DatabaseName "<データベース名>" -RetentionInDays 30 `
-WorkspaceResourceId "<Log Analyytics ワークスペース名>" `
-AuditAction @("SELECT on DATABASE::DB0 by public") -PredicateExpression "" -AuditActionGroup @() -Debug -Verbose
このような設定を行った場合は、DB に対して SELECT を行ったクエリについて監査ログの取得が行われます。
Predicate Expression を指定した取得情報のフィルタリング
Audit Action の他に Predicate Expression を指定して取得情報をフィルタリングすることもできます。
Predicate Expression は全ての取得情報に対して適用され、一部のアクショングループだけ特定のフィルタリング設定を行うということはできないようです。
PowerShell を使用する場合は次のようなコマンドとなります。
Set-AzSqlDatabaseAudit -ResourceGroupName "<リソースグループ名>" -ServerName "<サーバー名>" -DatabaseName "<データベース名>" -RetentionInDays 30 `
-WorkspaceResourceId "<Log Analyytics ワークスペース名>" `
-PredicateExpression "statement like '%trace%'" -Debug -Verbose
これらの方法を使用することでアクショングループだけでなく、取得する情報をフィルタリングすることができます。