クエリアクセスの判定を確認する

クエリアクセス監査では、クエリごとに、チェックされた Catalog、Schema、テーブル、カラムと、アクセスが許可されたか拒否されたかを確認できます。ユーザーから権限エラーの報告があったときや、アクセスを取り消したユーザーがテーブルを読み取れなくなったことを確認するときに使用します。

前提条件

role に次のいずれかの権限が含まれていること。
- query_audit:read_all では、全ユーザーのクエリを表示できます。
- query_audit:read_self では、自分のクエリのみを表示できます。
portal_admin role には query_audit:read_all があります。query_audit:read_self を持つシステム role はありません。この権限を付与するには、Admin がカスタム role に追加します。

左サイドバーで Data Security → Query access audit を選択します。
期間の from と to を設定します。両方とも必須で、期間は最大 31 日です。
必要に応じて結果を絞り込みます。
- Result: Allowed または Denied。
- User。
- リソースタイプ、Catalog、Schema、テーブル。
- フリーテキスト。たとえば SQL の一部です。
グループ表示か raw 表示かを選びます。

新しいクエリが上に表示され、1 ページ 20 件ずつ表示されます。1 ページあたり最大 100 件まで表示できます。

拒否されたクエリで絞り込んだグループ表示のクエリアクセス監査

グループ表示では、クエリごとに 1 行が表示されます。各行には、結果、ユーザー、日時、クエリテキスト、そのクエリで発生したチェックの数、チェックされたリソース、関係した policy が表示されます。

1 つのクエリで、多くのチェックが発生することがよくあります。クエリが触れる Catalog、Schema、テーブル、カラムごとに 1 回ずつチェックされるためです。
クエリは、チェックが 1 つでも拒否されると Denied になります。すべてのチェックが許可された場合にのみ Allowed になります。

行を選択すると、そのクエリのチェックの詳細を確認できます。

raw 表示では、チェックごとに 1 行が表示されます。各行には、アクセスの種類、リソースパス、操作、クライアントの IP アドレス、使用したツールが表示されます。クエリをブロックしたテーブルやカラムを正確に特定するときに使用します。

policy 列には、一致した Data Security policy の名前、種類 (Access、Row filter、Masking、System)、ステータスが表示されます。
Portal policy not available は、チェックが Data Security で確認できるどの policy にも一致しなかったことを示します。行に表示されている判定自体は正しいものです。
policy 列が空でも、アクセスが許可されたとは限りません。必ず結果を確認してください。

一部の行は、ユーザー、SQL、日時に基づいて、ポータルで実行されたクエリにベストエフォートで関連付けられます。クエリ ID が一致する場合を除き、この関連付けは確実なものではなく、可能性が高いものとして扱ってください。

クエリテキストは途中で切り捨てられることがあり、含まれるパスワードやキーは非表示になります。
データは、Lakehouse のアクセス記録から直接取得されます。どこまで遡って検索できるかは、その記録の保管期間によって決まります。
アクセス記録にアクセスできない場合は、空の一覧ではなくエラーが表示されます。しばらくしてからもう一度お試しください。一覧が空の場合は、フィルターに一致するクエリがなかったことを意味します。