適用対象:
Azure SQL DatabaseAzure Synapse Analytics
Azure SQL Database と Azure Synapse Analytics の監査は、データベース イベントを追跡し、Azure ストレージ アカウント、Log Analytics ワークスペース、または Event Hubs の監査ログに書き込みます。
また、監査によって以下を行うことができます。
規定コンプライアンスの維持、データベース活動の理解、およびビジネス上の懸念やセキュリティ違犯の疑いを示す差異や異常に対する洞察が容易になります。
コンプライアンスを保証するものではありませんが、標準へのコンプライアンスを強化します。 詳細については、Microsoft Azure Trust Centerに関するページを参照してください。ここから最新の SQL Database コンプライアンス証明書の一覧を入手できます。
注記
Azure SQL Managed Instance の監査の詳細については、「Azure SQL Managed Instance の監査の概要」を参照してください。
概要
SQL Database 監査を使用して、以下を行うことができます。
- 選択されたイベントの監査証跡を保持。 監査するデータベース活動のカテゴリを定義できます。
- データベース活動に関するレポート。 事前に構成したレポートとダッシュボードを使用して、活動とイベントのレポートをすぐに使用できます。
- レポートを分析。 疑わしいイベント、異常な活動、および傾向を発見できます。
重要
Azure SQL Database、Azure Synapse Analytics SQL プール、Azure SQL Managed Instance の監査は、監査対象のデータベースまたはインスタンスの可用性とパフォーマンスに対して最適化されています。 アクティビティが非常に高い、またはネットワーク負荷が高い期間中、監査機能は、監査対象としてマークされたすべてのイベントを記録せずにトランザクションが続行するのを許可する場合があります。
Azure SQL Database のサーバー監査におけるパフォーマンス、可用性、信頼性の強化 (2025 年 3 月)
- 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 と同じです。
- 主な変更の 1 つに、ストレージ アカウント コンテナーに格納されている監査ログのフォルダー構造の変更が含まれます。 以前は、サーバー監査ログは別のフォルダーに書き込まれています。各データベースに対して 1 つ。データベース名はフォルダー名として機能します。 新しい更新プログラムでは、すべてのサーバー監査ログが、
- 読み取り専用レプリカのフォルダー構造の変更:
- 読み取り専用データベース レプリカには、以前はログが読み取り専用フォルダーに格納されていました。 これらのログは、
masterフォルダーに書き込まれます。 これらのログは、新しい列is_secondary_replica_trueでフィルター処理することで取得できます。
- 読み取り専用データベース レプリカには、以前はログが読み取り専用フォルダーに格納されていました。 これらのログは、
- 監査ログを表示するために必要なアクセス許可:
- フォルダーに格納されている監査ログを表示できるのは、
masterプリンシパルだけです。
- フォルダーに格納されている監査ログを表示できるのは、
監査の制限事項
- 一時停止中の Azure Synapse SQL プールで監査を有効にすることは、サポートされていません。 監査を有効にするには、Synapse SQL プールを再開します。
- ユーザー割り当てマネージド ID (UAMI) を使って監査を有効にすることは、Azure Synapse ではサポートされていません。
- 現在、マネージド ID は、ストレージ アカウントが Virtual Network またはファイアウォールの内側にある場合を除き、Azure Synapse ではサポートされていません。
- パフォーマンスの制約のため、tempdb を監査したり、一時テーブル したりすることはありません。 バッチ完了アクション グループは、一時テーブルに対してステートメントをキャプチャしますが、オブジェクト名が正しく設定されない可能性があります。 ただし、ソース テーブルは常に監査され、ソース テーブルから一時テーブルへのすべての挿入が確実に記録されます。
- Azure Synapse SQL プールの監査では、既定の監査アクション グループのみがサポートされます。
- ログの送信先を ストレージ アカウントとして使用して Azure の論理サーバーまたは Azure SQL Database の監査を構成する場合、認証モードはそのストレージ アカウントの構成と一致する必要があります。 認証の種類としてストレージ アクセス キーを使用する場合は、ストレージ アカウント キーへのアクセスを使用してターゲット ストレージ アカウントを有効にする必要があります。 ストレージ アカウントが Microsoft Entra ID (旧称 Azure Active Directory) による認証のみを使用するように構成されている場合は、認証にマネージド ID を使用するように監査を構成できます。
解説
Premium ストレージと BlockBlobStorage がサポートされています。 Standard ストレージがサポートされています。 ただし、Virtual Network またはファイアウォールの内側にあるストレージ アカウントに書き込む監査の場合は、汎用 v2 ストレージ アカウントが必要です。 汎用 v1 または Blob Storage アカウントを使用している場合は、汎用 v2 ストレージ アカウントにアップグレードします。 具体的な手順については、VNet とファイアウォールの背後にあるストレージ アカウントに監査を書き込む方法に関する記事を参照してください。 詳細については、「ストレージ アカウントの種類」を参照してください。
すべての種類の Standard ストレージ アカウントおよび Premium ストレージ アカウントと BlockBlobStorage に対する階層型名前空間がサポートされています。
監査ログは、Azure サブスクリプションの Azure Blob Storage 内にあるAppend Blobsに書き込まれます。
監査ログは .xel 形式であり、SQL Server Management Studio (SSMS) を使用して開くことができます。
サーバー レベルまたはデータベース レベルの監査イベントに対して不変のログ ストアを構成するには、Azure Storage で提供される手順に従います。 監査用に不変 BLOB ストレージを構成する場合は、[保護された追加書き込みを許可する] が [BLOB の追加] または [BLOB のブロックと追加] に設定されていることを確認します。 None オプションはサポートされていません。 時間ベースの保持ポリシーの場合、ストレージ アカウントの保持間隔は、SQL 監査の保持設定よりも短くする必要があります。 ストレージ ポリシーが設定されているが、SQL 監査リテンション期間が
0されている構成はサポートされていません。Virtual Network またはファイアウォールの内側にある Azure ストレージ アカウントに監査ログを書き込むことができます。
ログ形式、ストレージ フォルダーの階層、および名前付け規則の詳細については、「SQL Database 監査ログの形式」に関する記事を参照してください。
読み取り専用レプリカを使用して読み取り専用クエリ ワークロードをオフロードするの監査が自動で有効化されます。 ストレージ フォルダーの階層、命名規則、ログ形式の詳細については、「SQL Database 監査ログの形式」に関する記事を参照してください。
Microsoft Entra 認証を使用している場合、失敗したログインのレコードは SQL 監査ログに表示されません。 失敗したログインの監査レコードを表示するには、これらのイベントの詳細をログに記録している Microsoft Entra 管理センターにアクセスする必要があります。
ログインはゲートウェイによって、データベースが置かれている特定のインスタンスにルーティングされます。 Microsoft Entra ログインを使用すると、要求されたデータベースへのサインインにそのユーザーを使用しようとする前に、資格情報が検証されます。 不合格になった場合、要求されたデータベースがアクセスされることはなく、監査は行われません。 SQL ログインを使用すると、要求されたデータで資格情報が検証されます。そのため、この場合は監査が可能です。 ログイン成功 (明らかにデータベースにアクセスできる) は、いずれの場合も監査されます。
監査設定を構成した後に、新しい脅威の検出機能をオンにし、電子メールを構成してセキュリティの警告を受信します。 脅威の検出を使用すると、セキュリティ上の脅威になる可能性がある異常なデータベース アクティビティに対するプロアクティブ アラートを受信できます。 詳細については、「SQL Advanced Threat Protection」に関する記事をご覧ください。
監査が有効になっているデータベースが別の論理サーバーにコピーされた後、監査が失敗したことを通知するメールを受け取る場合があります。 これは既知の問題であり、監査は新しくコピーされたデータベースで想定どおりに機能するはずです。