Tip
Microsoft Fabric Data Warehouse は、将来のアーキテクチャ、組み込みの AI、および新機能を備えた、Data Lake 基盤上のエンタープライズ 規模のリレーショナル ウェアハウスです。 データ ウェアハウスを初めて使用する場合は、Fabric Data Warehouseから始めます。 既存の dedicated SQL プール ワークロードは、Fabric にアップグレードして、データ サイエンス、リアルタイム分析、レポートの新機能にアクセスできます。
- Fabric無料試用版を開始します。
- Fabric Data Warehouseの移行アシスタント。
Azure Synapse Analytics監査はデータベースイベントを追跡し、それらをAzure Storage、Azure Monitor Log Analyticsワークスペース、またはAzure Event Hubsに書き込みます。
監査は、次の場合に役立ちます。
- 選択したイベントの監査証跡を保持します。
- データベースアクティビティを理解し、不一致や異常を調査しましょう。
- クエリ、ワークブック、下流監視ツールを使ってアクティビティをレポートします。
- 規制および組織のコンプライアンス要件への準拠を支援します。 監査だけではコンプライアンスが保証されません。
Overview
SQL Database 監査を使用して、以下を行うことができます。
- 選択されたイベントの監査証跡を保持。 監査するデータベース活動のカテゴリを定義できます。
- データベース活動に関するレポート。 事前に構成したレポートとダッシュボードを使用して、活動とイベントのレポートをすぐに使用できます。
- レポートを分析。 疑わしいイベント、異常な活動、および傾向を発見できます。
Important
監査はSQLプールの可用性とパフォーマンスに最適化されています。 アクティビティやネットワーク負荷が非常に高い期間には、すべての選択されたイベントが記録されずにトランザクションが進行することもあります。
大規模な OLTP ワークロードに推奨される監査アプローチ
多くのデータベースで大量の OLTP ワークロードが実行されている環境では、既定の設定でサーバー レベルの監査を使用すると、論理サーバー全体で非常に大きな監査ボリュームが発生する可能性があります。 すべてのデータベースのすべてのイベントが同じ監査フォルダーに書き込まれるため、1 つのデータベースに対して監査ログのクエリを実行すると、時間がかかり、運用コストが高くなります。 パフォーマンスを向上させ、ノイズを低減するには:
- データベース レベルの監査に切り替えます。 各データベースは、独自の監査ログ フォルダーに書き込みを行い、スキャンされるボリュームの合計を減らし、取得を高速化します。
- 監査構成を確認します。 すべてのバッチ完了イベントをキャプチャする必要があるかどうか、またはカスタムフィルター処理された構成がセキュリティとコンプライアンスの要件を満たすことができるかどうかを判断します。
監査ログにおける機密情報を保護する
監査対象のステートメントのテキストには、アプリケーションがそれらの値を動的SQLに連結する際に機密の値が含まれることがあります。 データ値のパラメータを使用し、クエリテキストに秘密情報や個人データを埋め込まないようにし、監査ログへのアクセスを認可ユーザーのみに制限します。
監査先の権限はSQLエンジン外へのアクセスを制御します。 Azure Storage、Log Analytics、Event Hubsには最小権限を適用し、それらのリソースへのアクセスを監視してください。
Limitations
- 一時停止した専用 SQL プールで監査を有効にすることはできません。 ポリシーを有効にする前にプールを再開してください。
- ユーザー割り当てのマネージド ID は、Azure Synapse Analytics の監査ではサポートされていません。
- システム割り当てのマネージドIDは、ストレージアカウントが仮想ネットワークやファイアウォールの背後にある場合、Azure Storage宛先でサポートされます。 管理IDは、ストレージアカウントが仮想ネットワークやファイアウォールの背後にある場合を除き、Azure Synapseではサポートされていません。
- Synapse SQLプールはデフォルトの監査アクショングループのみをサポートします。
-
?文字を含む名前を持つデータベースでは、監査はサポートされていません。 この制限はサーバーレベルおよびデータベースレベルの監査の両方に適用され、名前に?が含まれるデータベースはAzure でのサポートは終了しました。 - 監査記録は
statementおよびdata_sensitivity_informationフィールドで最大4,000文字を保存します。 追加の文字は切り捨てられます。
Remarks
- アクティビティ ログ内の
SQLDBControlPlaneFirstPartyAppによって開始されるイベントは、Azure SQL Database コントロール プレーンの内部Azure関数です。SQLDBControlPlaneFirstPartyAppによって開始されるイベントは、SQL エンジンとAzure Resource Manager間の内部同期操作の一部です。 これらのイベントは、Azure SQL Database管理の通常の部分であり、Azureでの適切なリソース表現と操作に必要です。 - Premium ストレージと BlockBlobStorage がサポートされています。 Standard ストレージがサポートされています。 しかし、仮想ネットワークやファイアウォールの背後にあるストレージアカウントに監査ログを書き込むには、 汎用v2ストレージアカウントを使用する必要があります。 汎用v1やBlob Storageアカウントを使っている場合は、汎用v2ストレージアカウントにアップグレードしてください。 具体的な手順については、「 仮想ネットワークとファイアウォールの背後にあるストレージアカウントに監査ログを書き込む」をご覧ください。 詳細については、「ストレージ アカウントの種類」を参照してください。
- SQL監査を有効にし、アウトバウンドネットワーク制限を設定する際には、監査イベントが目的地に届くようにするために、監査用ストレージアカウントの完全修飾ドメイン名を許可リストに追加する必要があります。 ストレージ エンドポイントを許可リストに追加しなければ、監査トラフィックがブロックされ、監査イベントが失われます。 必要なストレージアカウントFQDNSを許可リストに追加した後、通常の監査イベントフローを再開するために監査設定を再 保存 する必要があります。
- すべての種類の Standard ストレージ アカウントおよび Premium ストレージ アカウントと BlockBlobStorage に対する階層型名前空間がサポートされています。
- 監査ログは、Azure サブスクリプション上の Azure Blob Storage の Append Blobs に書き込まれます。
- 監査ログは .xel 形式であり、SQL Server Management Studio (SSMS) を使用して開くことができます。
- サーバー レベルまたはデータベース レベルの監査イベントに対して不変のログ ストアを構成するには、Azure Storage で提供される手順に従います。 監査用に不変 BLOB ストレージを構成する場合は、[保護された追加書き込みを許可する] が [BLOB の追加] または [BLOB のブロックと追加] に設定されていることを確認します。
None オプションはサポートされていません。 時間ベースの保持ポリシーの場合、ストレージ アカウントの保持間隔は、SQL 監査の保持設定よりも短くする必要があります。 ストレージ ポリシーが設定されているが、SQL 監査リテンション期間が
0されている構成はサポートされていません。 - 仮想ネットワークまたはファイアウォールの背後にあるAzure Storage アカウントに監査ログを書き込むことができます。
- ログ形式、ストレージフォルダの階層構造、命名規則の詳細については、 監査ログ形式を参照してください。
- Microsoft Entra 認証を使用している場合、失敗したログインのレコードは SQL 監査ログに表示されません。 失敗したログイン監査レコードを表示するには、これらのイベントの詳細をログに記録する Microsoft Entra 管理センター にアクセスする必要があります。
- 監査設定を設定した後、新しい脅威検知機能をオンにし、メールでセキュリティアラートを受け取る設定をできます。 脅威の検出を使用すると、セキュリティ上の脅威になる可能性がある異常なデータベース アクティビティに対するプロアクティブ アラートを受信できます。 詳細については、「SQL 高度な脅威保護を参照してください。
- 監査が有効になっているデータベースが別の論理サーバーにコピーされた後、監査が失敗したことを通知するメールを受け取る場合があります。 この状態は既知の問題であり、新たにコピーされたデータベースでは監査が期待通りに機能するはずです。