Azure SQL DatabaseとAzure Synapse Analyticsの監査

applies to:Azure SQL DatabaseAzure Synapse Analytics

Azure SQL Database および Azure Synapse Analyticsは、データベース イベントを追跡し、Azure ストレージ アカウント、Log Analytics ワークスペース、または Event Hubs の監査ログに書き込みます。

また、監査によって以下を行うことができます。

• 規定コンプライアンスの維持、データベース活動の理解、およびビジネス上の懸念やセキュリティ違犯の疑いを示す差異や異常に対する洞察が容易になります。

• コンプライアンスを保証するものではありませんが、標準へのコンプライアンスを強化します。 詳細については、「Microsoft Azure セキュリティ センター」を参照してください。ここでは>、SQL Database コンプライアンス認定の最新の一覧を確認できます。

概要

SQL Database 監査を使用して、以下を行うことができます。

• 選択されたイベントの監査証跡を保持。 監査するデータベース活動のカテゴリを定義できます。
• データベース活動に関するレポート。 事前に構成したレポートとダッシュボードを使用して、活動とイベントのレポートをすぐに使用できます。
• レポートを分析。 疑わしいイベント、異常な活動、および傾向を発見できます。

Azure SQL Databaseのサーバー監査におけるパフォーマンス、可用性、信頼性の強化 (2025 年 7 月 GA)

• SQL 監査の主要部分を再設計することで、サーバー監査の可用性と信頼性が向上しました。 追加の利点として、SQL ServerとAzure SQL Managed Instanceとのより近い機能のアラインメントがあります。 データベース監査は変更されません。
• 以前の監査の設計では、データベース レベルの監査がトリガーされ、サーバー内のデータベースごとに 1 つの監査セッションが実行されます。 監査の新しいアーキテクチャでは、すべてのデータベースの監査イベントをキャプチャする 1 つの拡張イベント セッションがサーバー レベルで作成されます。
• 新しい監査設計では、メモリと CPU が最適化され、SQL ServerおよびAzure SQL Managed Instanceでの監査のしくみと一致します。

サーバー監査の再アーキテクチャからの変更

• ストレージ アカウントのフォルダー構造の変更:
  • 主な変更の 1 つに、ストレージ アカウント コンテナーに格納されている監査ログのフォルダー構造の変更が含まれます。 以前は、サーバー監査ログは別のフォルダーに書き込まれています。各データベースに対して 1 つ。データベース名はフォルダー名として機能します。 新しい更新プログラムでは、すべてのサーバー監査ログが、 masterというラベルの付いた 1 つのフォルダーに統合されます。 この動作は、Azure SQL Managed InstanceとSQL Serverと同じです。
• 読み取り専用レプリカのフォルダー構造の変更:
  • 読み取り専用データベース レプリカには、以前はログが読み取り専用フォルダーに格納されていました。 これらのログは、 master フォルダーに書き込まれるようになりました。 これらのログは、新しい列 is_secondary_replica_trueでフィルター処理することで取得できます。
• 監査ログを表示するために必要なアクセス許可:
  • VIEW DATABASE SECURITY AUDIT ユーザー データベースのアクセス許可

大規模な OLTP ワークロードに推奨される監査アプローチ

多くのデータベースで大量の OLTP ワークロードが実行されている環境では、既定の設定でサーバー レベルの監査を使用すると、論理サーバー全体で非常に大きな監査ボリュームが発生する可能性があります。 すべてのデータベースのすべてのイベントが同じ監査フォルダーに書き込まれるため、1 つのデータベースに対して監査ログのクエリを実行すると、時間がかかり、運用コストが高くなります。 パフォーマンスを向上させ、ノイズを低減するには:

• データベース レベルの監査に切り替えます。 各データベースは、独自の監査ログ フォルダーに書き込みを行い、スキャンされるボリュームの合計を減らし、取得を高速化します。
• 監査構成を確認します。 すべてのバッチ完了イベントをキャプチャする必要があるかどうか、またはカスタムフィルター処理された構成がセキュリティとコンプライアンスの要件を満たすことができるかどうかを判断します。

監査の制限事項

• 一時停止中の Azure Synapse SQL プールでの監査の有効化はサポートされていません。 監査を有効にするには、Synapse SQL プールを再開します。
• ユーザー割り当てマネージド ID (UAMI) を使用した監査の有効化は、Azure Synapse ではサポートされていません。
• 現時点では、ストレージ アカウントが仮想ネットワークまたはファイアウォールの背後にある場合を除き、マネージド ID はAzure Synapseでサポートされていません。

• パフォーマンスの制約により、 tempdb テーブルと 一時テーブルは監査されません。 バッチ完了アクション グループは、一時テーブルに対してステートメントをキャプチャしますが、オブジェクト名が正しく設定されない可能性があります。 ただし、ソース テーブルは常に監査され、ソース テーブルから一時テーブルへのすべての挿入が確実に記録されます。

• Azure Synapse SQL プールの監査では、既定の監査アクション グループ only がサポートされます。

• Azure の logical サーバーや Azure SQL Database で監査を構成する際に、ログの送信先をストレージ アカウントに指定する場合、認証モードはそのストレージ アカウントの構成と一致する必要があります。 認証の種類としてストレージ アクセス キーを使用する場合は、ストレージ アカウント キーへのアクセスを使用してターゲット ストレージ アカウントを有効にする必要があります。 ストレージ アカウントが Microsoft Entra ID (formerly Azure Active Directory) でのみ認証を使用するように構成されている場合は、認証にマネージド ID を使用するように監査を構成できます。

• ?文字を含む名前を持つデータベースでは、監査はサポートされていません。 これは、server-level と database-level 監査の両方に適用されます。名前に ? を持つデータベースは Azure でサポートされなくなっています。

• Azure SQL DatabaseおよびAzure Synapse監査ログは、 フィールドと statement フィールドに最大data_sensitivity_informationをキャプチャします。 監査可能なアクションからの出力がこの制限を超えると、最初の 4,000 文字を超えるコンテンツは 切り捨てられ 、 監査レコードから除外されます。

解説

• アクティビティ ログ内の SQLDBControlPlaneFirstPartyApp によって開始されるイベントは、Azure SQL Database コントロール プレーンの内部Azure関数です。 SQLDBControlPlaneFirstPartyApp によって開始されるイベントは、SQL エンジンとAzure Resource Manager間の内部同期操作の一部です。 これらのイベントは、Azure SQL Database管理の通常の部分であり、Azureでの適切なリソース表現と操作に必要です。
• Premium ストレージと BlockBlobStorage がサポートされています。 Standard ストレージがサポートされています。 ただし、Virtual Network またはファイアウォールの内側にあるストレージ アカウントに書き込む監査の場合は、汎用 v2 ストレージ アカウントが必要です。 汎用 v1 または Blob Storage アカウントをお持ちの場合は、汎用 v2 ストレージ アカウント>にアップグレードします。 具体的な手順については、VNet とファイアウォールの背後にあるストレージ アカウントに監査を書き込む方法に関する記事を参照してください。 詳細については、「ストレージ アカウントの種類」を参照してください。
• お客様が SQL 監査を有効にし、 送信ネットワーク 制限も構成する場合は、監査イベントが宛先に正常に到達できるように、監査ストレージ アカウントの完全修飾ドメイン名の一覧を許可する必要があります。 ストレージ エンドポイントが許可リストに登録されていない場合、監査トラフィックはブロックされ、監査イベントが失われます。 必要なストレージ アカウントの FQDN を許可リストに追加した後、通常の監査イベント フローを再開するには、監査構成を 再保存 する必要があります。
• すべての種類の Standard ストレージ アカウントおよび Premium ストレージ アカウントと BlockBlobStorage に対する階層型名前空間がサポートされています。
• 監査ログは、Azure サブスクリプションのAzure Blob Storageの Append Blobs に書き込まれます
• 監査ログは .xel 形式であり、SQL Server Management Studio (SSMS) で開くことができます。
• サーバーレベルまたはデータベース レベルの監査イベントの不変ログ ストアを構成するには、Azure Storage によって提供される instructions に従います。 監査用に不変 BLOB ストレージを構成する場合は、[保護された追加書き込みを許可する] が [BLOB の追加] または [BLOB のブロックと追加] に設定されていることを確認します。 None オプションはサポートされていません。 時間ベースの保持ポリシーの場合、ストレージ アカウントの保持間隔は、SQL 監査の保持設定よりも短くする必要があります。 ストレージ ポリシーが設定されているが、SQL 監査リテンション期間が 0されている構成はサポートされていません。
• 仮想ネットワークまたはファイアウォールの背後にあるAzure Storage アカウントに監査ログを書き込むことができます。
• ログ形式、ストレージ フォルダーの階層、および名前付け規則の詳細については、「SQL Database 監査ログの形式」に関する記事を参照してください。
• 読み取り専用レプリカを使用して読み取り専用クエリ ワークロードをオフロードするの監査が自動で有効化されます。 ストレージ フォルダーの階層、命名規則、ログ形式の詳細については、「SQL Database 監査ログの形式」に関する記事を参照してください。
• Microsoft Entra認証を使用すると、失敗したログイン レコードが SQL 監査ログに表示されません。 失敗したログイン監査レコードを表示するには、これらのイベントの詳細をログに記録する Microsoft Entra 管理センター にアクセスする必要があります。
• ログインはゲートウェイによって、データベースが置かれている特定のインスタンスにルーティングされます。 Microsoft Entraログインでは、そのユーザーを使用して要求されたデータベースにサインインする前に資格情報が検証されます。 不合格になった場合、要求されたデータベースがアクセスされることはなく、監査は行われません。 SQL ログインを使用すると、要求されたデータで資格情報が検証されます。そのため、この場合は監査が可能です。 ログイン成功 (明らかにデータベースにアクセスできる) は、いずれの場合も監査されます。
• 監査設定を構成した後に、新しい脅威の検出機能をオンにし、電子メールを構成してセキュリティの警告を受信します。 脅威の検出を使用すると、セキュリティ上の脅威になる可能性がある異常なデータベース アクティビティに対するプロアクティブ アラートを受信できます。 詳細については、「SQL 高度な脅威保護を参照してください。
• 監査が有効になっているデータベースが別の論理サーバーにコピーされた後、監査が失敗したことを通知するメールを受け取る場合があります。 これは既知の問題であり、監査は新しくコピーされたデータベースで想定どおりに機能するはずです。

関連するコンテンツ

• Azure SQL 監査の新機能
• Azure SQL Managed Instance監査を開始します
• SQL Server の監査
• Azure SQL Database と Azure Synapse Analytics