Professional 学習教材 ⑤ セキュリティ・コンプライアンス（配点 10%）

Databricks 認定データエンジニア Professional（上位資格）試験のドメイン⑤「セキュリティ・コンプライアンス」向けの自習教材です。行レベル/列レベルのアクセス制御（行フィルター・列マスク）、動的ビュー、ABAC（属性ベースアクセス制御）ポリシー、機密データ保護（マスキング・暗号化・シークレット）とコンプライアンスを、公式ドキュメントに基づいて深く扱います。この md だけで学習が完結するよう、定義・構文・DBR バージョン要件・制限・注意点を網羅しています。
参照した公式ページ:
セキュリティとコンプライアンス（ランディング）: https://learn.microsoft.com/ja-jp/azure/databricks/security/
行フィルターと列マスク（Unity Catalog）: https://learn.microsoft.com/ja-jp/azure/databricks/data-governance/unity-catalog/filters-and-masks/
※ https://learn.microsoft.com/ja-jp/azure/databricks/tables/row-and-column-filters は上記ページへリダイレクト（同一内容）
手動適用（構文例の出典）: https://learn.microsoft.com/ja-jp/azure/databricks/data-governance/unity-catalog/filters-and-masks/manually-apply
動的ビューを作成する: https://learn.microsoft.com/ja-jp/azure/databricks/views/dynamic
ABAC 行フィルター/列マスクポリシーの作成と管理: https://learn.microsoft.com/ja-jp/azure/databricks/data-governance/unity-catalog/abac/policies

1. このドメインの概要

このドメインは、Unity Catalog を中核とした きめ細かいアクセス制御（Fine-Grained Access Control, FGAC） と、Azure Databricks 全体の セキュリティ・コンプライアンス基盤 を問います。Professional 試験では、単に機能名を覚えるだけでなく、以下を「使い分け・仕組み・要件・制限」のレベルで理解していることが求められます。

Azure Databricks のセキュリティは大きく次の 5 領域で構成されます。

認証とアクセス制御（Authentication & Access Control） — SSO/JIT プロビジョニング、個人用アクセストークン（PAT）、ワークスペースオブジェクトへのきめ細かいアクセス制御。
ネットワーク（Network） — プライベート接続、サーバーレスエグレス制御、ストレージファイアウォール、VNet インジェクション。
データセキュリティと暗号化（Data Security & Encryption） — 保存中/転送中の暗号化、カスタマーマネージドキー（CMK）、クラスターノード間トラフィック暗号化、資格情報の編集（redaction）。
シークレット管理（Secret Management） — 資格情報や機密情報を安全に格納・参照する仕組み。
コンプライアンス（Compliance） — コンプライアンスセキュリティプロファイル、拡張セキュリティ監視、HIPAA などの規制対応。

そのうえで、テーブル内のデータそのものへのアクセスをクエリ時に絞り込む 3 つのメカニズムが試験の中心です。

メカニズム	対象	管理方法	最適な用途
テーブルレベルの行フィルター/列マスク	個別のテーブル・列	`ALTER TABLE`（テーブル所有者または `MANAGE` 保有者）	テーブル固有のロジック
ABAC ポリシー	タグ条件に一致するテーブル・列	`CREATE POLICY`（カタログ/スキーマ/テーブルに関連付け、所有者または `MANAGE` 保有者）	多数のテーブルに自動適用される一元化ルール
動的ビュー（dynamic view）	1 つ以上のベーステーブルから構築したビュー	ビュー定義内の SQL ロジック	キュレーション/変換したバージョンのデータ共有

キーとなる判断軸:

1 テーブルだけ、テーブル固有のロジック → テーブルレベルの行フィルター/列マスク。
多数のテーブルに一貫したルール、職務分離、タグ付き新規テーブルの自動カバレッジ → ABAC ポリシー（Databricks 推奨）。
ベーステーブルにアクセスできないユーザーに、加工・結合・編集済みビューを公開 → 動的ビュー。

2. 重要用語集

用語（日本語）	English	説明
きめ細かいアクセス制御	Fine-Grained Access Control (FGAC)	行・列・値のレベルでデータ可視性を制御する仕組み。専用アクセスモードから利用する場合はサーバーレスコンピューティング上で適用される。
行フィルター	Row filter	クエリ時に各行を評価する SQL UDF。`FALSE` を返す行はクエリ結果から除外される。行レベルセキュリティの実現手段。
列マスク	Column mask	列の値を入力に取り、元の値かマスク済みの値を返す SQL UDF。戻り値型は列型と一致またはキャスト可能である必要がある。列ごとに 1 つだけ設定可能。
行レベルセキュリティ	Row-Level Security (RLS)	ユーザーやグループごとに表示できる「行」を制限する概念。行フィルターや動的ビューの `WHERE` 句で実現。
列レベルセキュリティ	Column-Level Security	列単位で表示可否・マスクを制御する概念。列マスクや動的ビューの `CASE` 式で実現。
動的ビュー	Dynamic view	実行ユーザーやグループメンバーシップに応じて表示内容を変える Unity Catalog ビュー。`session_user()` / `is_account_group_member()` などを利用。
ユーザー定義関数	User-Defined Function (UDF)	行フィルター/列マスクのロジックを実装する関数。SQL UDF が基本。Python/Scala は SQL UDF でラップして使う。
`current_user()` / `session_user()`	current_user() / session_user()	現在（セッションの）ユーザーのメールアドレスを返す関数。呼び出し元ユーザーの ID 判定に使う。
`is_account_group_member()`	is_account_group_member()	現在のユーザーがアカウントレベルグループのメンバーなら `TRUE`。Unity Catalog データの動的ビューで推奨。
`is_member()`	is_member()	Hive メタストア互換用のグループ判定関数。アカウントレベルのグループメンバーシップを評価しないため、Unity Catalog データのビューでは使用しない。
ABAC	Attribute-Based Access Control	属性（＝タグ）ベースのアクセス制御。管理タグに基づき、カタログ/スキーマにアタッチしたポリシーが自動適用される。
ポリシー	Policy	ABAC における行フィルター/列マスクの適用ルール。`CREATE POLICY` で作成し、カタログ/スキーマ/テーブルにアタッチする。
タグ / 管理タグ（統制タグ）	Tag / Governed tag	メタデータのキー（＋値）。ABAC はタグ条件（`has_tag` / `has_tag_value`）でポリシー適用対象を決める。管理タグは統制された（ガバナンスされた）タグ。
セキュリティ保護可能なオブジェクト	Securable object	カタログ・スキーマ・テーブルなど、権限やポリシーを付与できる対象。
プリンシパル	Principal	ユーザー・グループ・サービスプリンシパル。ポリシーの `TO` / `EXCEPT` で指定する。
`MANAGE` 権限	MANAGE privilege	ポリシー操作（作成/編集/削除/表示/説明）に必須の権限。オブジェクト所有権でも代替可。
`EXECUTE` 権限	EXECUTE privilege	行フィルター/列マスクに使う UDF を割り当てるために必要な関数実行権限。
機密データ	Sensitive data	SSN・電話番号・メールアドレスなど、保護が必要な個人情報（PII）等。列マスクやマスキングで保護する。
マスキング	Masking / Data masking	機密値を `REDACTED` 等に置換したり一部だけ表示すること。列マスクや動的ビューの `CASE` 式で実装。
暗号化	Encryption	保存中（at rest）・転送中（in transit）のデータを保護する仕組み。CMK やノード間トラフィック暗号化を含む。
カスタマーマネージドキー	Customer-Managed Keys (CMK)	顧客自身の暗号化キーでデータを保護し、暗号化の制御を保持する仕組み。
シークレット	Secret	資格情報や機密情報を安全に格納するオブジェクト。Spark conf や環境変数で参照する。
資格情報の編集	Credential redaction	ログや出力から機密資格情報を自動的に編集（マスク）する機能。
セキュリティベースライン / セキュリティプロファイル	Security baseline / Compliance security profile	各種コンプライアンスフレームワーク・標準に対応した強化セキュリティ設定のプロファイル。
拡張セキュリティ監視	Enhanced Security Monitoring	セキュリティの異常や脅威を検出する高度な監視機能。
コンプライアンス	Compliance	HIPAA など規制要件を満たすための構成・機能群。
JIT プロビジョニング	Just-In-Time (JIT) provisioning	SSO ログイン中にユーザーアカウントを自動作成する仕組み。
個人用アクセストークン	Personal Access Token (PAT)	API アクセス用トークン。追跡・管理の対象。
定義者権限 / 呼び出し元コンテキスト	Definer's rights / Invoker context	フィルターは基本「定義者の権限」で実行されるが、`session_user()` や `is_account_group_member()` 等は呼び出し元ユーザーのコンテキストで評価される。
マッピングテーブル（ACL）	Mapping table / Access Control List	どのユーザー/グループがどの行にアクセスできるかをエンコードしたテーブル。行フィルターと結合して RLS を実現。

3. 詳細解説

3-1. セキュリティ全体像（データ/ユーザー/ワークスペース保護）

Azure Databricks は「データ・ユーザー・ワークスペース」を保護する包括的なセキュリティ/コンプライアンス機能を提供します。全体は次の 5 本柱で理解します。

(1) 認証とアクセス制御

強力な認証を構成し、環境・リソースへのユーザーアクセスを管理。
ユーザーの自動プロビジョニング（JIT）: SSO ログイン中にアカウントを自動作成。
個人用アクセストークン（PAT） の監視・管理: API アクセスセキュリティのために追跡・管理。
アクセス制御: ワークスペースオブジェクトとリソースにきめ細かいアクセス制御を実装。

(2) ネットワーク

プライベート接続: ワークスペースにアクセスするユーザーのプライベート接続を設定。
サーバーレスエグレス制御（ネットワークポリシー）: サーバーレスコンピューティングの外向き通信を制御。
Azure Storage ファイアウォール: サーバーレスコンピューティングアクセス用のファイアウォール規則を設定。
VNet インジェクション: 独自の仮想ネットワークに Azure Databricks をデプロイしてセキュリティを強化。

(3) データセキュリティと暗号化

保存中（at rest）・転送中（in transit）のデータを暗号化とセキュリティ制御で保護。
カスタマーマネージドキー（CMK）: 独自の暗号化キーでデータを保護し、暗号化の制御を維持。
クラスターワーカーノード間トラフィックの暗号化: クラスターノード間の転送中データを暗号化。
資格情報の編集（redaction）: ログ・出力から機密資格情報を自動的に編集。

(4) シークレット管理

資格情報・機密情報を安全に格納・管理。
Spark conf / 環境変数のシークレット: Spark 構成や環境変数で使うシークレットを構成（値を平文でノートブックに書かない）。
シークレットワークフロー: シークレットの作成・使用を通じた安全な資格情報の取り扱い。

(5) コンプライアンス

規制要件を満たし、セキュリティのベストプラクティスを実装。
コンプライアンスセキュリティプロファイル: 各種コンプライアンスフレームワーク・標準に対応したセキュリティプロファイル（＝セキュリティベースライン）。
拡張セキュリティ監視: セキュリティ異常・脅威を検出する高度な監視。
HIPAA など個別規制の構成ガイダンス。

試験のポイント: 「どの機能がどの柱に属するか」を対応づけられること。例）ノード間の転送中データ暗号化＝データセキュリティ、JIT＝認証、エグレス制御＝ネットワーク、資格情報の平文回避＝シークレット管理。

3-2. 行フィルターと列マスク（仕組み・関数として定義・適用・DBR要件・制限）

行フィルターと列マスクは、Unity Catalog のアクセス制御であり、ユーザーがクエリ時に見られる「行」と「列の値」を制限します。

行フィルター（Row filter）とは

クエリ時に各行を評価する SQL UDF。関数が FALSE を返した行はクエリ結果から除外される。
用途例: 特定のリージョン・部署・アカウントのレコードだけにユーザーを制限（行レベルセキュリティ）。
各テーブルに設定できる行フィルターは 1 つだけ。0 個以上の入力パラメーターを取り、各パラメーターはテーブルの 1 列にバインドされる。
ALTER TABLE ... SET ROW FILTER で 1 テーブルにバインドし、テーブル所有者が管理。

列マスク（Column mask）とは

特定の列でユーザーに見せる値を制御する SQL UDF。列の値を入力に取り、元の値かマスク済みの値を返す。
戻り値の型は列のデータ型と一致またはキャスト可能である必要がある。
各列は 1 つのマスクだけを持てる。他の列を入力に取り、複数の属性に基づいて動作を変えられる（USING COLUMNS）。
ALTER TABLE ... ALTER COLUMN ... SET MASK で列にバインドし、テーブル所有者が管理。

適用の2つの方法

ABAC ポリシー（推奨）: 管理タグと再利用可能なポリシーで一元的に適用。カタログ/スキーマをまたいでスケールし、上位管理者が定義できるため、テーブル所有者はオーバーライド/削除できない。ポリシーロジックはテーブル固有 UDF より効率的に評価される。
テーブルごとの手動割り当て: UDF を個々のテーブル・列に直接割り当てる。きめ細かいがスケール・保守が困難。

必要な権限（手動適用時）

関数を割り当てるには、関数への EXECUTE、スキーマへの USE SCHEMA、親カタログへの USE CATALOG。
新規テーブル作成時にフィルター/マスクを付ける場合は、スキーマへの CREATE TABLE。
既存テーブルでフィルター/マスクを追加・削除する場合は、テーブル所有者、または MANAGE と SELECT の両方。
同じステートメントでスキーマも変更する場合（マスク付き列の追加など）は MODIFY も必要。

コンピューティング要件（DBR バージョン）

SQL ウェアハウス で利用可能。
標準アクセスモード（旧・共有アクセスモード）: Databricks Runtime 12.2 LTS 以降。
専用アクセスモード（旧・シングルユーザーアクセスモード）: Databricks Runtime 15.4 LTS 以降（かつワークスペースでサーバーレスコンピューティングが有効であること。FGAC はサーバーレス上で実行されるため課金が発生し得る）。
DBR 15.3 以下の専用コンピューティングからは、行フィルター/列マスク付きテーブルを読み取れない。
専用アクセスモードでは、DBR 15.4〜16.2 は読み取り操作のみサポート。書き込み（INSERT/UPDATE/DELETE）は DBR 16.3 以降が必要で、MERGE INTO などサポートされたパターンを使う。
DBR 12.2 LTS より前 では行フィルター/列マスクは非サポート。これらのランタイムは「安全に失敗（fail safe）」＝テーブルにアクセスしてもデータが返らない。

データ型の不一致の動作（重要な落とし穴）

UDF のパラメーター型は、渡されるテーブル列のデータ型と一致させる必要がある。
型が違う（例: STRING 列を INT パラメーターに渡す）と、Databricks は暗黙的にキャストする。
ANSI モード無効（spark.sql.ansi.enabled = false） だと、キャスト不能値はサイレントに NULL に変換され、エラーが出ない。結果として「全行を返す行フィルター」「誤った値をマスクする列マスク」など誤った結果を生む。
Databricks は ANSI モード有効（= true）を推奨。キャスト失敗時にエラーになり、問題がすぐに顕在化する。

テーブル置換時の保持（REPLACE TABLE）

REPLACE TABLE を実行しても、スキーマ変更に関係なく既存の行フィルターは保持される。
新テーブルにマスク付き列と同名の列があれば、列マスクも保持される（明示的に再定義しなくてもポリシーが残る＝誤消去防止）。
ただし保持されたポリシーが削除/変更された列を参照すると後続クエリが失敗し得る。その場合は ALTER TABLE で更新/削除する。

制限事項（試験頻出）

DBR 12.2 LTS 未満は非サポート（fail safe）。
行/列マスクをビューに適用することはできない。
Iceberg REST カタログまたは Unity REST API 経由では、行フィルター/列マスク付きテーブルにアクセスできない。
Delta Lake API はサポートされない。
OpenSharing（Delta Sharing のオープン共有）プロバイダーは、テーブルレベルの行フィルター/列マスク付きテーブルを共有できない（ABAC ベースは共有所有者がポリシーから除外されていれば共有可能）。OpenSharing 受信者は共有/外部テーブルにのみ適用でき、ストリーミングテーブルや具体化ビューには不可。
ポリシーを含むテーブル内ファイルへのパスベースアクセスは非サポート。
MERGE は、入れ子・集計・ウィンドウ・LIMIT・非決定的関数を含むフィルター/マスクポリシーを持つテーブルでは非サポート。
DBR 17.2 より前では、パーティション列にフィルター/マスクポリシーが定義されたパーティションテーブルの DELETE/UPDATE/MERGE は非サポート。
元のポリシーへ戻る循環依存のフィルター/マスクは非サポート。
行フィルター/列マスクは、アクティブなフィルター/マスクを含む別テーブルを参照できない（ABAC では参照先テーブルのポリシーからポリシー関数所有者を除外して回避可能）。
タイムトラベルは行/列マスクでは機能しない（ABAC ではポリシーから明示除外されたユーザーはタイムトラベル可）。
行/列マスク付きテーブルでは深いクローン・浅いクローンが非サポート（ABAC では除外ユーザーはクローン可）。
行フィルター/列マスク付きテーブルから AI Search インデックスを作成できない。
列マスクは、生成された列（generated column）が参照する列には適用できない。

パフォーマンス推奨（情報漏えい防止のため常に「安全な選択」がなされる＝最適化が抑制され得る）

単純な UDF を使う。マッピングテーブル・サブクエリより単純な CASE 式。
大きなテーブルでの個別の列マスク数を制限（各マスクはクエリ中に評価される）。真に機密な列だけに適用し、関数を再利用。
UDF 引数の数を減らす（引数由来の列参照は、クエリで未使用でも最適化できない）。
AND 結合が多すぎる行フィルターを避ける（実行時に解決できる行フィルターはユーザー×テーブルで 1 つだけ、という前提でロジックを AND で結合しがちだが、結合が増えるほど最適化を妨げるパターンを含みやすい）。
エラーを送出しない決定的な式を使う（ANSI 除算のように「0 除算」等でエラーになると、フィルター/マスク前の値情報が漏れるため、SQL コンパイラは操作をプッシュダウンできない。try_divide などを使う）。
Python UDF より SQL を優先（Python UDF は低速で最適化機会が少ない。使う場合は必要に応じて DETERMINISTIC マーク）。

3-3. 動的ビュー（current_user/グループ判定でのアクセス制御・15.4 LTS 要件・制限）

動的ビュー（dynamic view） は、Unity Catalog で列/行レベルのセキュリティやデータマスキングをきめ細かく構成するための SQL ビューです。実行ユーザーやそのグループメンバーシップに応じて、表示する行・列・値を動的に変えます。

使用する組み込み関数

session_user(): 現在のユーザーのメールアドレスを返す（current_user() と同様に呼び出し元判定に使う）。
is_account_group_member('group'): 現在のユーザーがそのアカウントレベルグループのメンバーなら TRUE。Unity Catalog データの動的ビューで推奨。
is_member('group'): 既存の Hive メタストア互換用。アカウントレベルのグループメンバーシップを評価しないため、Unity Catalog データのビューでは使用しないこと。

ベストプラクティス: 動的ビューを使う際は、ビューで参照される元テーブル・元ビューをユーザーが直接読み取れないようにする（そうしないと迂回されてしまう）。

コンピューティング要件（DBR バージョン）

動的ビューの作成・読み取り要件は、コンピューティング要件を除き標準ビューと同じ。以下のいずれかを使う。

SQL ウェアハウス
標準アクセスモード（旧・共有アクセスモード） のコンピューティング
Databricks Runtime 15.4 LTS 以降の専用アクセスモード（旧・シングルユーザーアクセスモード）
DBR 15.3 以下の専用コンピューティングでは動的ビューを読み取れない。
DBR 15.4 LTS 以降のデータフィルター処理はサーバーレスコンピューティング上で実行されるため、ワークスペースでサーバーレスコンピューティングが有効である必要がある。専用コンピューティングから読み取るとサーバーレス課金が発生し得る。

3 つの実装パターン

列レベルのアクセス（列マスキング）: CASE 式で、特定グループのメンバーのみ実値を、それ以外は REDACTED を返す。Spark はクエリ解析中に CASE をリテラル文字列か実列内容に置換するため、クエリパフォーマンスへの悪影響はない。
行レベルのアクセス（行フィルタリング）: WHERE 句内の CASE で、特定グループには TRUE、それ以外には条件（例: total <= 1000000）を適用して行を絞る。
データマスキング（高度）: Spark SQL の複雑な式や正規表現（例: regexp_extract）で、ドメインだけ見せる等の高度なマスクを実装。

動的ビュー vs ABAC/テーブルレベルの使い分け

動的ビューは、元テーブルにアクセスできないユーザーに、キュレーション・変換・結合したバージョンのデータを公開する場合に使う（例: ファクトテーブルの編集済みスライスをアナリストグループと共有、複数テーブルの列を 1 つのセキュアレイヤーに結合）。
多数テーブルへの一貫適用や職務分離、タグ付き新規テーブルの自動カバレッジが必要なら ABAC が向く。

3-4. ABAC（属性ベースアクセス制御ポリシー、タグ連携）

ABAC（Attribute-Based Access Control） は、管理タグ（governed tags） という「属性」に基づいて、行フィルター/列マスクを ポリシー としてカタログ/スキーマ/テーブルに一元適用する仕組みです。Databricks は「多数のテーブルで一貫した行フィルター/列マスクが必要な場合」に ABAC を推奨します。

ABAC の強み

カタログ/スキーマレベルにアタッチし、管理タグに基づいてテーブル・列に自動適用（テーブルごとの構成が不要）。
上位レベルの管理者が定義するため、テーブル所有者はオーバーライド/削除できない。
ポリシー作成者とデータスチュワードの職務分離が可能。
タグ付けされた新規テーブルの自動カバレッジ。
ポリシーロジックはテーブル固有 UDF より効率的に評価される。

必要条件

すべてのポリシー操作（作成/編集/削除/表示/説明）に、対象セキュリティ保護可能オブジェクトへの MANAGE、またはオブジェクトの所有権が必要。
ポリシー作成には:
- Databricks Runtime 16.4 以降、またはサーバーレスコンピューティング。
- フィルター/マスクロジック用の、EXECUTE 可能な Unity Catalog 内 UDF（またはポリシー作成時にインライン定義する SQL 関数）。
- ターゲットオブジェクトに適用される 管理タグ。
ポリシーをアタッチするセキュリティ保護可能オブジェクト（カタログ/スキーマ/テーブル）への MANAGE、または所有＋UDF への EXECUTE。

ポリシーの主要概念（SQL 句）

ON { CATALOG | SCHEMA | TABLE }: ポリシーをアタッチするスコープ。子孫の全テーブルに対して評価される。
ROW FILTER function_name / COLUMN MASK function_name: ポリシー種別とロジック UDF。
TO principal [, ...]: ポリシー適用対象のユーザー/グループ/サービスプリンシパル（All account users で全員）。
EXCEPT principal [, ...]: ポリシーから除外するプリンシパル。除外者はフィルター/マスクされず、変更されていない完全なデータを見られる。
FOR TABLES: 対象はテーブル（ストリーミングテーブル・具体化ビューを含む。現状サポートされる唯一のセキュリティ保護可能種別）。
WHEN condition: タグに基づき適用テーブルを決めるブール式。has_tag('tag_name') と has_tag_value('tag_name','tag_value') を使う。省略時の既定は TRUE（スコープ内全テーブル）。
MATCH COLUMNS condition [AS alias] [, ...]: 対象列を識別する列条件（has_tag / has_tag_value を AND/OR/NOT で組合せ）。エイリアスを付けて ON COLUMN / USING COLUMNS から参照。最大 3 つの MATCH COLUMNS 式を持て、すべて一致で適用。
ON COLUMN alias: 列マスクでマスク対象の一致列を指定（エイリアス参照）。
USING COLUMNS (function_arg [, ...]): UDF に渡す引数。MATCH COLUMNS のエイリアスまたは定数リテラル。

タグ条件（UI の「テーブルの条件」）

条件なし: スコープ内の全テーブルに適用。
これらのタグのいずれかに一致するテーブル: 指定タグキー（またはキー＋値）のリストに適用。
カスタム式に一致するテーブル: has_tag / has_tag_value を AND/OR/NOT で組合せ、式が TRUE のテーブルに適用。

ポリシーの表示・説明・監査

SHOW POLICIES ON ...: オブジェクトに定義されたポリシー一覧。SHOW EFFECTIVE POLICIES は親スコープ（カタログ等）のポリシーも含む。テーブルの有効ポリシー表示に親への権限は不要（テーブル管理者が適用ルールを確認できる）。
DESCRIBE POLICY ...: 特定ポリシーの詳細（名前・種別・プリンシパル・条件・関数名・タイムスタンプ等）。ターゲットへの MANAGE（または所有権）が必要。
監査ログ: 管理タグと ABAC ポリシー操作は system.access.audit システムテーブルに記録される（createEntityTagAssignment / deleteEntityTagAssignment / createPolicy / deletePolicy / getPolicy / listPolicies など）。
ポリシー編集: SQL は CREATE OR REPLACE POLICY（全句を再指定＝定義全体を置換、名前とアタッチ先は変更不可）。Python SDK の update_policy は update_mask による部分更新が可能。
GRANT モデルのポリシー（ベータ）は別ドキュメント（grant-policies）。

3-5. 機密データ保護・コンプライアンス（マスキング/暗号化/シークレット）

マスキング（Masking）

機密データ（SSN・電話番号・メールアドレス等の PII）を、ユーザー属性に応じて REDACTED や部分表示に置換。
実装手段: 列マスク（ALTER TABLE ... SET MASK）、ABAC 列マスクポリシー、動的ビューの CASE 式、正規表現（regexp_extract）。
ネストした STRUCT フィールドの選択的マスク（named_struct() で再構築）、他列を条件に使う USING COLUMNS など、高度なパターンにも対応。

暗号化（Encryption）

保存中（at rest）・転送中（in transit）のデータを保護。
カスタマーマネージドキー（CMK）: 顧客自身のキーで暗号化を制御。
クラスターワーカーノード間トラフィックの暗号化: ノード間の転送中データを暗号化。
資格情報の編集（redaction）: ログ・出力から機密資格情報を自動編集。

シークレット（Secrets）

資格情報・機密情報を平文で扱わず、シークレットとして安全に格納・参照。
Spark conf / 環境変数のシークレット: 構成値としてシークレットを注入（ノートブックに平文を書かない）。
シークレットワークフローで作成・使用を管理。

コンプライアンス / セキュリティベースライン

コンプライアンスセキュリティプロファイル: 各種フレームワーク・標準に沿った強化セキュリティ設定（セキュリティベースライン）。
拡張セキュリティ監視: 異常・脅威検知。
HIPAA 等の規制別構成ガイダンス。

4. 構文・コード例

4-1. 行フィルター（テーブルレベル・手動適用）

sql

-- 1. 行フィルター関数を作成（出力はブール値）
CREATE FUNCTION us_filter(region STRING)
RETURN IF(IS_ACCOUNT_GROUP_MEMBER('admin'), true, region='US');

-- 2. 既存テーブルに適用（ON で対応列をバインド）
CREATE TABLE sales (region STRING, id INT);
ALTER TABLE sales SET ROW FILTER us_filter ON (region);

-- CREATE TABLE 時に同時適用
CREATE TABLE sales (region STRING, id INT)
WITH ROW FILTER us_filter ON (region);

-- 定数リテラルを引数に使う
ALTER TABLE <table_name> SET ROW FILTER <function_name> ON (<constant_literal>, ...);

-- 行フィルターを無効化（削除）
ALTER TABLE sales DROP ROW FILTER;

-- 行フィルターを変更
CREATE OR REPLACE FUNCTION us_filter(region STRING)
RETURN IF(IS_ACCOUNT_GROUP_MEMBER('admin'), true, region='US');

-- 関数を完全に削除する場合は、必ず先に DROP ROW FILTER してから DROP FUNCTION
ALTER TABLE <table_name> DROP ROW FILTER;
DROP FUNCTION <function_name>;

注意: 関数を先に DROP FUNCTION するとテーブルにアクセスできなくなる。その場合は ALTER TABLE <table_name> DROP ROW FILTER; で孤立参照を削除する。

4-2. 列マスク（テーブルレベル・手動適用）

sql

-- ssn 列のマスク関数。HumanResourceDept グループのメンバーだけ実値を見られる
CREATE FUNCTION ssn_mask(ssn STRING)
  RETURN CASE WHEN is_account_group_member('HumanResourceDept') THEN ssn
              ELSE '***-**-****' END;

-- CREATE TABLE 時に列に適用
CREATE TABLE users (
  name STRING,
  ssn STRING MASK ssn_mask);

-- 既存テーブルの列に適用
CREATE TABLE users (name STRING, ssn STRING);
ALTER TABLE users ALTER COLUMN ssn SET MASK ssn_mask;

-- 追加列を渡す（USING COLUMNS）。第1引数は常にマスク対象列。
ALTER TABLE <table_name> ALTER COLUMN <col_name>
  SET MASK <mask_func_name> USING COLUMNS <additional_columns>;

-- 列マスクを削除
ALTER TABLE users ALTER COLUMN ssn DROP MASK;

-- 関数を完全に削除する場合は、必ず先に DROP MASK
ALTER TABLE <table_name> ALTER COLUMN <col> DROP MASK;
DROP FUNCTION <function_name>;

他列を条件に使う列マスク（USING COLUMNS）

sql

-- address(マスク対象), country(条件用), group_suffix(グループ指定)
CREATE FUNCTION mask_address_by_country(
  address STRING, country STRING, group_suffix STRING DEFAULT '_address_viewers')
RETURN IF(
  is_account_group_member(country || group_suffix),
  address,
  'REDACTED'
);

CREATE TABLE customers (
  name STRING,
  address STRING MASK mask_address_by_country USING COLUMNS (country, '_address_viewers'),
  country STRING
);

Python UDF を列マスクに使う（SQL でラップ必須）

sql

-- 1. Python UDF
CREATE OR REPLACE FUNCTION email_mask_python(email STRING)
RETURNS STRING
LANGUAGE PYTHON
AS $$
import re
return re.sub(r'^[^@]+', lambda m: '*' * len(m.group()), email)
$$;

-- 2. SQL ラッパー（これを列マスクとして適用する。Python UDF を直接使うと [ROUTINE_NOT_FOUND] エラー）
CREATE OR REPLACE FUNCTION email_mask_sql(email STRING)
RETURN email_mask_python(email);

CREATE TABLE contacts (name STRING, email STRING MASK email_mask_sql);

ネストした STRUCT フィールドのマスク

sql

CREATE FUNCTION mask_nested_field(data STRUCT<value: STRING, secret: STRING>)
RETURN IF(
  is_account_group_member('privileged_users'),
  data,
  named_struct('value', data.value, 'secret', 'REDACTED')  -- 型は元の STRUCT と一致させる
);

マッピングテーブル（ACL）で RLS を実現

sql

-- 呼び出し元ユーザーが許可リストに含まれるか判定
CREATE FUNCTION row_filter()
  RETURN EXISTS(
    SELECT 1 FROM valid_users v
    WHERE v.username = SESSION_USER()
);
-- 列指定せず全体に適用する場合は ON ()
CREATE TABLE data_table (x INT, y INT, z INT)
  WITH ROW FILTER row_filter ON ();

補足: フィルターは基本「定義者の権限（definer's rights）」で実行されるが、SESSION_USER() / IS_ACCOUNT_GROUP_MEMBER() など呼び出し元コンテキストをチェックする関数は例外的に呼び出し元として評価される。

4-3. 動的ビュー

sql

-- 列レベル: auditors グループだけ email を見られる（他は REDACTED）
CREATE VIEW sales_redacted AS
SELECT
  user_id,
  CASE WHEN is_account_group_member('auditors') THEN email
       ELSE 'REDACTED' END AS email,
  country, product, total
FROM sales_raw;

-- 行レベル: managers は全件、他は 100万ドル以下のみ
CREATE VIEW sales_redacted AS
SELECT user_id, country, product, total
FROM sales_raw
WHERE CASE
  WHEN is_account_group_member('managers') THEN TRUE
  ELSE total <= 1000000
END;

-- データマスキング: 全員ドメインは見えるが、完全なアドレスは auditors のみ
CREATE VIEW sales_redacted AS
SELECT
  user_id, region,
  CASE WHEN is_account_group_member('auditors') THEN email
       ELSE regexp_extract(email, '^.*@(.*)$', 1) END
FROM sales_raw;

4-4. ABAC ポリシー

sql

-- ポリシーの一般構文
CREATE [OR REPLACE] POLICY policy_name
ON { CATALOG catalog_name | SCHEMA schema_name | TABLE table_name }
[COMMENT description]
{ row_filter_body | column_mask_body }

列マスクポリシー例（pii:ssn タグの列を、admins 以外の us_analysts に対して末尾4文字だけ表示）

sql

CREATE FUNCTION ssn_to_last_nr (ssn STRING, nr INT) RETURNS STRING
  RETURN right(ssn, nr);

CREATE POLICY mask_ssn
ON SCHEMA prod.customers
COLUMN MASK ssn_to_last_nr
TO us_analysts EXCEPT admins
FOR TABLES
MATCH COLUMNS has_tag_value('pii', 'ssn') AS ssn
ON COLUMN ssn
USING COLUMNS (4);

行フィルターポリシー例（sensitivity:high タグのテーブルから、us_analysts に対して EU 顧客の行を除外）

sql

CREATE FUNCTION non_eu_region (geo_region STRING) RETURNS BOOLEAN
  RETURN geo_region <> 'eu';

CREATE POLICY hide_eu_customers
ON SCHEMA prod.customers
COMMENT 'Exclude rows with European customers from sensitive tables'
ROW FILTER non_eu_region
TO us_analysts
FOR TABLES
WHEN has_tag_value('sensitivity', 'high')
MATCH COLUMNS has_tag('geo_region') AS region
USING COLUMNS (region);

表示・説明・削除

sql

-- 親スコープを含めた有効ポリシー一覧
SHOW EFFECTIVE POLICIES ON SCHEMA prod.customers;

-- ポリシー詳細
DESCRIBE POLICY hide_eu_customers ON SCHEMA prod.customers;

-- 削除
DROP POLICY mask_ssn ON SCHEMA prod.customers;

5. 試験で問われるポイント

3 メカニズムの使い分け（テーブルレベル行フィルター/列マスク ↔ ABAC ポリシー ↔ 動的ビュー）。「多数テーブルへ一貫適用・職務分離・タグ自動カバレッジ」なら ABAC、「1 テーブル固有」ならテーブルレベル、「加工/結合したビューを公開」なら動的ビュー。
DBR バージョン要件の暗記:
- 行フィルター/列マスク: 標準アクセスモードは 12.2 LTS 以降、専用アクセスモードは 15.4 LTS 以降（サーバーレス有効が前提）。12.2 LTS 未満は fail safe（データ返らず）。専用は 15.4〜16.2 が読み取りのみ、書き込みは 16.3 以降。
- 動的ビュー: 専用アクセスモードは 15.4 LTS 以降、15.3 以下は読み取り不可。
- ABAC ポリシー作成: DBR 16.4 以降またはサーバーレス。パーティション列ポリシーの DELETE/UPDATE/MERGE は 17.2 以降。
行フィルターは UDF が FALSE の行を除外、各テーブル 1 つだけ。列マスクは列型と一致/キャスト可能な戻り値、各列 1 つだけ。
関数の適用/解除の構文: ALTER TABLE ... SET ROW FILTER ... ON (...) / ALTER TABLE ... ALTER COLUMN ... SET MASK ... USING COLUMNS ...、削除は DROP ROW FILTER / DROP MASK。関数削除は必ず先に DROP してから DROP FUNCTION（順序を逆にするとテーブルアクセス不能）。
is_account_group_member()（Unity Catalog 推奨）と is_member()（Hive 互換・UC では非推奨）の違い。動的ビューでは元テーブルへの直接読み取りを禁止するのがベストプラクティス。
session_user() / current_user() による呼び出し元判定。フィルターは定義者権限で動くが、これらの関数は呼び出し元コンテキストで評価される。
ABAC のタグ連携: WHEN has_tag(...) / has_tag_value(...) でテーブル選択、MATCH COLUMNS（最大 3 つ）で列選択、TO/EXCEPT でプリンシパル、USING COLUMNS で UDF 引数。管理タグと MANAGE 権限、UDF への EXECUTE が前提。
ビューに行フィルター/列マスクは適用できない（ビューは動的ビューで対応）。
ANSI モードと型不一致: 型が合わないとキャストされ、ANSI 無効だとサイレント NULL 化で誤結果 → ANSI 有効推奨。UDF パラメーター型は列型と一致させる。
主要な制限: タイムトラベル不可、クローン不可、Delta Lake API 不可、パスベースアクセス不可、AI Search インデックス作成不可、生成列が参照する列にマスク不可、循環依存不可、相互参照テーブル不可、OpenSharing 制約。
Python UDF は SQL ラッパー経由でのみ列マスクに使える（直接だと [ROUTINE_NOT_FOUND]）。
REPLACE TABLE でフィルター/マスクは保持される（誤消去防止）。
セキュリティ 5 本柱（認証/ネットワーク/データ暗号化/シークレット/コンプライアンス）と各機能の対応（CMK・ノード間暗号化・redaction・JIT・エグレス制御・HIPAA・拡張セキュリティ監視など）。
監査: 管理タグと ABAC ポリシー操作は system.access.audit に記録される。

6. 理解度チェックリスト

[ ] 行フィルターと列マスクの定義（UDF が何を返し、どの行/値が除外・マスクされるか）を説明できる
[ ] 「各テーブルに行フィルターは 1 つ」「各列に列マスクは 1 つ」という制約を覚えている
[ ] 列マスクの戻り値型は列型と一致/キャスト可能でなければならないことを理解している
[ ] ALTER TABLE ... SET ROW FILTER ... ON (col) と ALTER TABLE ... ALTER COLUMN ... SET MASK ... USING COLUMNS ... を書ける
[ ] CREATE TABLE ... WITH ROW FILTER ... / ... STRING MASK func の作成時適用構文を書ける
[ ] フィルター/マスク関数を安全に削除する順序（先に DROP ROW FILTER/DROP MASK、その後 DROP FUNCTION）を説明できる
[ ] 行フィルター/列マスクの DBR 要件（標準 12.2 LTS+/専用 15.4 LTS+、書き込み 16.3+、12.2 未満は fail safe）を言える
[ ] 動的ビューの DBR 要件（専用 15.4 LTS 以降、サーバーレス有効が前提）を言える
[ ] ABAC ポリシー作成の要件（DBR 16.4+ またはサーバーレス、MANAGE、UDF への EXECUTE、管理タグ）を言える
[ ] is_account_group_member() と is_member() の違い、UC でどちらを使うかを説明できる
[ ] session_user() / current_user() を使った動的ビューの列/行制御を書ける
[ ] 動的ビューで元テーブルへの直接読み取りを禁止すべき理由を説明できる
[ ] ABAC の WHEN has_tag_value(...)、MATCH COLUMNS（最大 3 つ）、TO/EXCEPT、USING COLUMNS、ON COLUMN の役割を説明できる
[ ] タグ（管理タグ）と ABAC ポリシーの連携で「新規テーブルの自動カバレッジ」が実現できることを理解している
[ ] テーブルレベル・ABAC・動的ビューの 3 つを、用途に応じて正しく使い分けられる
[ ] 「ビューに行フィルター/列マスクは適用できない」ことを覚えている
[ ] ANSI モードと型不一致がもたらす誤結果のリスクと対策（ANSI 有効・型一致）を説明できる
[ ] 主要制限（タイムトラベル/クローン/Delta Lake API/パスアクセス/AI Search/生成列/循環依存/OpenSharing）を列挙できる
[ ] Python UDF を列マスクに使うには SQL ラッパーが必要なことを理解している
[ ] REPLACE TABLE でフィルター/マスクが保持される挙動を説明できる
[ ] パフォーマンス推奨（単純な CASE、引数削減、AND 結合を減らす、エラーを出さない決定的な式、SQL 優先）を挙げられる
[ ] セキュリティ 5 本柱と代表機能（CMK・ノード間暗号化・redaction・シークレット・JIT・エグレス制御・コンプライアンスプロファイル・拡張セキュリティ監視・HIPAA）を対応づけられる
[ ] 管理タグと ABAC ポリシー操作が system.access.audit に監査記録されることを知っている

Professional 学習教材 ⑤ セキュリティ・コンプライアンス（配点 10%） ​

1. このドメインの概要 ​

2. 重要用語集 ​

3. 詳細解説 ​

3-1. セキュリティ全体像（データ/ユーザー/ワークスペース保護） ​

3-2. 行フィルターと列マスク（仕組み・関数として定義・適用・DBR要件・制限） ​

行フィルター（Row filter）とは ​

列マスク（Column mask）とは ​

適用の2つの方法 ​

必要な権限（手動適用時） ​

コンピューティング要件（DBR バージョン） ​

データ型の不一致の動作（重要な落とし穴） ​

テーブル置換時の保持（REPLACE TABLE） ​

制限事項（試験頻出） ​

パフォーマンス推奨（情報漏えい防止のため常に「安全な選択」がなされる＝最適化が抑制され得る） ​

3-3. 動的ビュー（current_user/グループ判定でのアクセス制御・15.4 LTS 要件・制限） ​

使用する組み込み関数 ​

コンピューティング要件（DBR バージョン） ​

3 つの実装パターン ​

動的ビュー vs ABAC/テーブルレベルの使い分け ​

3-4. ABAC（属性ベースアクセス制御ポリシー、タグ連携） ​

ABAC の強み ​

必要条件 ​

ポリシーの主要概念（SQL 句） ​

タグ条件（UI の「テーブルの条件」） ​

ポリシーの表示・説明・監査 ​

3-5. 機密データ保護・コンプライアンス（マスキング/暗号化/シークレット） ​

4. 構文・コード例 ​

4-1. 行フィルター（テーブルレベル・手動適用） ​

4-2. 列マスク（テーブルレベル・手動適用） ​

4-3. 動的ビュー ​

4-4. ABAC ポリシー ​

5. 試験で問われるポイント ​

6. 理解度チェックリスト ​

Professional 学習教材 ⑤ セキュリティ・コンプライアンス（配点 10%）

1. このドメインの概要

2. 重要用語集

3. 詳細解説

3-1. セキュリティ全体像（データ/ユーザー/ワークスペース保護）

3-2. 行フィルターと列マスク（仕組み・関数として定義・適用・DBR要件・制限）

行フィルター（Row filter）とは

列マスク（Column mask）とは

適用の2つの方法

必要な権限（手動適用時）

コンピューティング要件（DBR バージョン）

データ型の不一致の動作（重要な落とし穴）

テーブル置換時の保持（REPLACE TABLE）

制限事項（試験頻出）

パフォーマンス推奨（情報漏えい防止のため常に「安全な選択」がなされる＝最適化が抑制され得る）

3-3. 動的ビュー（current_user/グループ判定でのアクセス制御・15.4 LTS 要件・制限）

使用する組み込み関数

コンピューティング要件（DBR バージョン）

3 つの実装パターン

動的ビュー vs ABAC/テーブルレベルの使い分け

3-4. ABAC（属性ベースアクセス制御ポリシー、タグ連携）

ABAC の強み

必要条件

ポリシーの主要概念（SQL 句）

タグ条件（UI の「テーブルの条件」）

ポリシーの表示・説明・監査

3-5. 機密データ保護・コンプライアンス（マスキング/暗号化/シークレット）

4. 構文・コード例

4-1. 行フィルター（テーブルレベル・手動適用）

4-2. 列マスク（テーブルレベル・手動適用）

4-3. 動的ビュー

4-4. ABAC ポリシー

5. 試験で問われるポイント

6. 理解度チェックリスト