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 コンプライアンス認定の最新の一覧を確認できます。

注記

Azure SQL Managed Instance監査の詳細については、「get started with Azure SQL Managed Instance auditing」を参照してください。

概要

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

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

重要

Azure SQL Database、Azure Synapse Analytics SQL プール、およびAzure SQL Managed Instanceの監査は、監査対象のデータベースまたはインスタンスの可用性とパフォーマンスのために最適化されています。 アクティビティが非常に高い、またはネットワーク負荷が高い期間中、監査機能は、監査対象としてマークされたすべてのイベントを記録せずにトランザクションが続行するのを許可する場合があります。

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

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

監査ログにおける機密情報を保護する

動的SQLが入力値を直接SQL文に連結して構築されると、それらの値は文のテキストの一部となります。 もし明細が監査対象の場合、明細文に含まれる機密情報が監査ログに記録されることがあります。

機密情報の漏洩リスクを減らすために、以下のベストプラクティスを遵守してください:

  • 敏感な数値を含む操作には動的SQLは避けてください

    セキュリティに敏感な管理操作では、機密値を動的SQLに連結して文を作成するのは避けましょう。 可能な限り、ネイティブSQL文や、文文に機密値を直接埋め込むのを防ぐ他の方法を用いましょう。

    ユーザーアクセス可能な文字列から構成された動的SQL文も、 SQLインジェクション攻撃に対してアプリケーションを脆弱にします。 SQLインジェクションは、悪意のあるコードを文字列に挿入し、その後データベースに渡して解析・実行する攻撃です。 SQLインジェクションの脆弱性に対してT-SQLを構築する手続きは必ずテストしなければなりません。なぜなら、データベースエンジンは受け取ったすべての文法的に有効なクエリを実行するからです。 データ値にはパラメータを使用し、クエリテキストにパラメータ値を連結してはいけません。 適切にパラメータ化された値は実行可能なSQL構文ではなくデータとして扱われます。

  • 監査ログへのアクセスを制限する

    監査ログへのアクセスは認可されたユーザーと管理者に限定してください。 SQL データベース エンジン内では、SQL権限がデータベース エンジン内の監査アクセスを制御しており、プラットフォームや監査範囲によって異なる場合があります。 最小権限の原則に従い、監査情報を管理またはレビューするために必要な権限のみを付与してください。 Microsoftはサーバーレベルとデータベースレベルの監査権限モデルを別々に文書化しており、Azure SQL Databaseはサーバーレベルの権限の利用可能性においてSQL Serverとは異なります。

    SQL データベース エンジン外での監査ログへのアクセスは、設定された宛先(Azure Storage、Log Analytics、Event Hubsなど)の権限に依存します。 最小権限の原則に従い、監査情報を管理またはレビューするために必要な権限のみを付与してください。

    監査データへのアクセスを制限することで、機密情報が記録された監査イベントに存在する場合の不正開示のリスクを減らすことができます。

監査の制限事項

  • 一時停止中の Azure Synapse SQL プールでの監査の有効化はサポートされていません。 監査を有効にするには、Synapse SQL プールを再開します。

  • ユーザー割り当てマネージド ID (UAMI) を使用した監査の有効化は、Azure Synapse ではサポートされていません。

  • 現時点では、ストレージ アカウントが仮想ネットワークまたはファイアウォールの背後にある場合を除き、マネージド ID はAzure Synapseでサポートされていません。

  • Azure Synapse Analyticsの場合、仮想ネットワーク(VNet)背後のストレージアカウントへの監査には、サーバーのシステム割り当てマネージドIDとStorage Blob Data Contributorの役割が必要です。 ユーザー割り当てマネージド ID (UAMI) は、Synapse 監査ではサポートされていません。 Microsoft Entra専用認証を使用するストレージ アカウントを監査する必要がある場合は、サーバーでシステム割り当てマネージド ID を構成し、ターゲット ストレージ アカウントに対するストレージ BLOB データ共同作成者ロールを付与します。 詳細については、「 VNet とファイアウォールの背後にあるストレージ アカウントに監査を書き込む」を参照してください。

  • パフォーマンスの制約により、 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 高度な脅威保護を参照してください。
  • 監査が有効になっているデータベースが別の論理サーバーにコピーされた後、監査が失敗したことを通知するメールを受け取る場合があります。 これは既知の問題であり、監査は新しくコピーされたデータベースで想定どおりに機能するはずです。

関連するコンテンツ

  • Last updated on