適用対象:✅ Microsoft Fabric の SQL 分析エンドポイントおよびウェアハウス
Fabric Data Warehouse の監査では、データベース イベントを追跡および記録することで、セキュリティとコンプライアンスの能力を強化できます。
SQL監査ログを使用することで、データベースの活動を監視し、潜在的なセキュリティ脅威を検出し、主要なアクションの監査記録を維持することでコンプライアンス要件を満たすことができます。例えば:
- 認証の試行とアクセス制御の変更
- データ アクセスと変更の操作
- スキーマの変更と管理アクティビティ
- アクセス許可の変更とセキュリティ構成
重要
既定では、SQL 監査ログは [オフ] です。 監査クエリのアクセス許可を持つユーザーは、これを有効にしてログをキャプチャする必要があります。
開始するには、「 Fabric Data Warehouse で SQL 監査ログを構成する方法」の手順を確認します。
Storage
SQL 監査ログは保存時に暗号化され、OneLake に格納されます。
Fabric Data Warehouse の場合、監査ログは OneLake のウェアハウス.XELに格納されているファイルに書き込まれます。
次の ロール を持つユーザーは、監査フォルダーにアクセスできます。
- ワークスペース 管理者
- Workspace メンバー
- ワークスペース の共同作成者
- すべてを読む権限があるワークスペースビューアー
これらのユーザーは次のことができます。
- 監査フォルダーを参照する
- SQL 監査によって生成された
.XEL監査ファイルを表示する - オフライン分析用のファイルをコピーする
- SQL Server Management Studio (SSMS) などのツールを使用してファイルを開く
sys.fn_get_audit_file_v2を使用して T-SQL を使用して監査ログにクエリを実行することもできます。
手順については、Fabric Data Warehouse で SQL 監査ログを構成する方法を参照してください。
ヒント
Microsoft Fabric Data Warehouse で監査ログを構成すると、記録されたアクション グループとイベントに応じてストレージ コストが増加する可能性があります。 不要なストレージ コストを回避するには、必要なイベントのみを有効にします。
Performance
SQL監査ログ機能は、監査対象データベースの可用性とパフォーマンスに最適化されています。 アクティビティが非常に高い、またはネットワーク負荷が高い期間中、監査機能は、監査対象としてマークされたすべてのイベントを記録せずにトランザクションが続行するのを許可する場合があります。
権限
監査ログを構成してクエリを実行するには、 監査クエリ (監査) アクセス許可が必要です。
- 既定では、ワークスペース管理者には、ワークスペース内のすべての項目に対する監査クエリのアクセス許可があります。
- 管理者は共有ダイアログボックスを通じて、他のユーザーにアイテムに対する 監査クエリ の権限を付与できます。
ワークスペース管理者は、Fabricポータルの共有メニューオプションを使って、監査クエリの権限を項目に付与できます。 ユーザーが監査クエリのアクセス許可を持っているかどうかを確認するには、[アクセス許可の管理] 設定を確認します。
倉庫アイテムで、[ 共有 ] ボタンを選択します。
または、Fabric ポータルのワークスペースで実行します。 倉庫アイテムの
...コンテキスト メニューを選択し、[ アクセス許可の管理] を選択します。「 Grant People access pane 」で、ユーザーに権限を付与します。
アイテムの [共有] メニューで監査クエリ (監査) 権限を選択する場所を示すスクリーンショット。
T-SQL権限を用いて監査ログを照会します
ユーザーには、たとえワークスペース管理ロールを持っていなくても、T-SQL権限を使って監査ログを照会できるように、 VIEW DATABASE SECURITY AUDIT 権限を付与しましょう。
以下の権限を付与すると、ユーザーは sys.fn_get_audit_file_v2 関数を使って監査ログをクエリできます。
GRANT VIEW DATABASE SECURITY AUDIT TO [user];
ヒント
VIEW DATABASE SECURITY AUDIT権限は監査ログのクエリのみを許可します。
ファイルへのアクセスや監査設定の変更権限は与えられません。
データベース レベルの監査アクション グループとアクション
監査ログ構成のアクセシビリティを高めるために、Fabric ポータルではフレンドリ名を使用して、SQL 管理者以外や他のユーザーがキャプチャされた Fabric Data Warehouse イベントを簡単に理解できるようにします。
ファブリックは、これらのフレンドリ名を基になる SQL 監査アクション グループにマップします。 参照として次の表を使用します。
| 親しみやすい名前 | アクション グループ名 | 説明 |
|---|---|---|
| オブジェクトにアクセスされました | DATABASE_OBJECT_ACCESS_GROUP |
メッセージの種類、アセンブリ、コントラクトなどのデータベース オブジェクトへのアクセスをログに記録します。 |
| オブジェクトが変更されました | DATABASE_OBJECT_CHANGE_GROUP |
データベース オブジェクトに対する CREATE、ALTER、または DROP 操作をログに記録します。 |
| オブジェクト所有者の変更 | DATABASE_OBJECT_OWNERSHIP_CHANGE_GROUP |
データベース オブジェクトの所有権の変更をログに記録します。 |
| オブジェクト権限が変更されました | DATABASE_OBJECT_PERMISSION_CHANGE_GROUP |
データベース オブジェクトに対する GRANT、REVOKE、または DENY アクションをログに記録します。 |
| ユーザーが変更されました | DATABASE_PRINCIPAL_CHANGE_GROUP |
データベース プリンシパル (ユーザー、ロール) の作成、変更、または削除をログに記録します。 |
| ユーザーが偽装されました | DATABASE_PRINCIPAL_IMPERSONATION_GROUP |
偽装操作 (EXECUTE AS など) をログに記録します。 |
| ロール メンバーが変更されました | DATABASE_ROLE_MEMBER_CHANGE_GROUP |
データベース ロールからのログインの追加または削除をログに記録します。 |
| ユーザーがログインに失敗しました | FAILED_DATABASE_AUTHENTICATION_GROUP |
データベース内で失敗した認証試行をログに記録します。 |
| スキーマ権限が使用されました | SCHEMA_OBJECT_ACCESS_GROUP |
スキーマ オブジェクトへのアクセスをログに記録します。 |
| スキーマが変更されました | SCHEMA_OBJECT_CHANGE_GROUP |
スキーマに対する CREATE、ALTER、または DROP 操作をログに記録します。 |
| スキーマ オブジェクトのアクセス許可がチェックされました | SCHEMA_OBJECT_OWNERSHIP_CHANGE_GROUP |
スキーマ オブジェクトの所有権に対する変更をログに記録します。 |
| スキーマ オブジェクトのアクセス許可が変更されました | SCHEMA_OBJECT_PERMISSION_CHANGE_GROUP |
スキーマ オブジェクトに対する GRANT、REVOKE、または DENY アクションをログに記録します。 |
| Batch が完了しました | BATCH_COMPLETED_GROUP |
このイベントは、バッチ テキスト、ストアド プロシージャ、またはトランザクション管理操作の実行が完了するたびに発生します。 |
| バッチが開始されました | BATCH_STARTED_GROUP |
このイベントは、バッチ テキスト、ストアド プロシージャ、またはトランザクション管理操作の実行が開始されるたびに発生します。 |
| 監査が変更されました | AUDIT_CHANGE_GROUP |
このイベントは、任意の監査が作成、変更、または削除されるたびに発生します。 |
| ユーザーのログアウト | DATABASE_LOGOUT_GROUP |
このイベントは、データベース ユーザーがデータベースからサインアウトしたときに発生します。 |
| ログインしているユーザー | SUCCESSFUL_DATABASE_AUTHENTICATION_GROUP |
プリンシパルがデータベースに正常にログインしたことを示します。 |
データベース レベルの監査アクション
アクション グループに加えて、個々の監査アクションを構成して、特定のデータベース イベントをログに記録できます。
| 監査措置 | 説明 |
|---|---|
SELECT |
指定したオブジェクトに対する SELECT ステートメントをログに記録します。 |
INSERT |
指定したオブジェクトに対する INSERT 操作をログに記録します。 |
UPDATE |
指定したオブジェクトに対する UPDATE 操作をログに記録します。 |
DELETE |
指定したオブジェクトに対する DELETE 操作をログに記録します。 |
EXECUTE |
ストアド プロシージャまたは関数の実行をログに記録します。 |
RECEIVE |
Service Broker キューに対する RECEIVE 操作をログに記録します。 |
REFERENCES |
外部キー制約に関連するアクセス許可チェックをログに記録します。 |
述語フィルタリングによる監査ノイズの削減
どのイベントを捕捉するかをフィルタリングするには、オプションの 述語式 フィルターを使用します。
述語フィルタリングを活用し、自動化のアイデンティティ、サービスプリンシパル、スケジュールされたジョブなどの予想される反復的な活動からのノイズを減らし、組織のコンプライアンスや調査目的で必要なアクショングループを無効化する必要はありません。
- イベントが設定された述語と一致した場合にのみ、そのアクションのSQL監査ログイベントが生成されます。
- フィルタリングはイベントが書かれる前に行われるため、除外されたイベントは後で遡って調査できません。 述語除外を意図的な監査方針の決定として扱い、所有権、権限、リスクプロファイルの変化に応じて設定された述語を定期的に見直してください。
- 述語フィルタリングは、すでに有効になっている 監査アクショングループやアクションによってキャプチャされるように設定されたイベントのみを評価します。
- 基盤となるアクショングループが有効化されていなければ、述語が評価するためのイベントは生成されず、フィルターも効果を持ちません。 例えば、
statementフィールド上の述語を使ってSELECT文をフィルタリングするには、まず「バッチ完了(BATCH_COMPLETED_GROUP)」アクショングループを有効にする必要があります。
- 基盤となるアクショングループが有効化されていなければ、述語が評価するためのイベントは生成されず、フィルターも効果を持ちません。 例えば、
述語式はFabricポータルやREST APIを使って設定できます。 手順については「 述語式の設定」を参照してください。
述語表現構文
述語式はCREATE SERVER AUDIT (Transact-SQL)の <predicate_expression> 節と同じ構文を使用しますが、WHEREキーワードは含みません。
<predicate_expression> ::=
{ [ NOT ] <predicate_factor>
[ { AND | OR } [ NOT ] { <predicate_factor> } ] [ ,... n ] }
<predicate_factor> ::=
event_field_name { = | <> | != | > | >= | < | <= | LIKE }
{ number | 'string' }
-
event_field_namesys.fn_get_audit_file(Transact-SQL)で返される列に対応します。file_name、audit_file_offset、event_timeを除くすべての文書化された列を使用できます。 -
action_idclass_typeは文字列ですが、述語内の数値としか比較できません。 - 文字列比較は暗黙の型変換を行いません。
- 式の長さは最大3,000文字です。
- 文字列が空なら述語が適用されていないことを意味します。
例えば、既知のサービスプリンシパルや自動化の識別子によって生成された活動を除外するには、 server_principal_nameでフィルタリングします。 繰り返しの SELECT 文を除外するには、 statement フィールドでフィルターを使います: NOT statement LIKE 'SELECT %'。
制限事項
- 既定のワークスペースでは、SQL 監査ログはサポートされていません。
- SQL 監査ログは、 ウェアハウス スナップショットではサポートされていません。
重要
監査ログは、OneLake の Warehouse アイテム内に格納されます。 ウェアハウスを削除すると、関連付けられている監査ログ ファイルも削除され、アクセスできなくなります。
コンプライアンスまたは調査の目的で監査ログを保持するには、ウェアハウスを削除する前に、 .XEL ファイルを別のストレージの場所にコピーします。
SQL 分析エンドポイントの制限事項
SQL 分析エンドポイントを監査する場合は、次の制限が適用されます。
- DML 操作はキャプチャされません。 監査では、sql 分析エンドポイントではなく Lakehouse ランタイムを介して Lakehouse テーブルのデータ操作が行われるため、
INSERT、UPDATE、DELETE、MERGEなどの操作は記録されません。 - 監査フォルダーへの直接アクセスは現在サポートされていません。 ユーザーは、基になる
.XEL監査ファイルを Lakehouse 監査フォルダーから参照またはダウンロードできません。
T-SQL関数 sys.fn_get_audit_file_v2を使ってSQL分析エンドポイントの監査イベントにクエリすることも可能です。