CEL 条件 & アクセスパターン
このページでは、CEL（Common Expression Language）条件を使用してユーザーにポリシータグ付きのデータへのアクセスを付与する方法について説明します
目的
このページでは、CEL（Common Expression Language）条件を使用してユーザーにポリシータグ付きのデータへのアクセスを付与する方法について説明します。ポリシータグの概要、ゲートチェーン、およびデータへのタグのバインド方法については、ポリシータグの概要を参照してください。
目次
CEL 条件によるアクセス付与
ユーザーにポリシータグ付きのデータへのアクセスを付与するには、2つの手順が必要です。
- ユーザーにポリシータグ値を割り当てる Lakehouse Manager の Grant Access UI を使用して
- ユーザーロールバインドの CEL 条件を確認または編集する Identity Access Manager で
Grant Access UI の使用
Grant Access UI を使用すると、ユーザーにポリシータグ値を簡単に割り当てることができます。
-
Grant Access メニューを開きます。
-
割り当てたいポリシータグを選択し、アクセスタイプを指定します：Read は読み取り専用アクセス、Read and Write は両方のアクセスです。
-
ポリシータグ値（例：
access_level: level 1）をユーザーまたはグループに割り当てます。
-
アクセス設定を確認して保存します。
重要な制限: Grant Access UI は、リソースレベルのスコープを持たない CEL 条件を生成します。これは、条件がゲートチェーンのすべてのレベル（データセット、テーブル、属性）で評価されることを意味します。ポリシータグがテーブルレベルでのみ適用されている場合、データセットレベルのチェックに失敗し、ユーザーはアクセスを拒否されます。IAM で CEL 条件を手動で編集してリソーススコープを追加する必要があります。以下のCEL 条件を手動で記述するを参照してください。
注意: Advanced Data Access Control の権限を持っていないユーザーは、デフォルトでどのデータセット、テーブル、属性にも読み取りまたは書き込みを行うことはできません。これは、ユーザーのIAM 設定で確認できます。
CEL 条件を手動で記述する
ポリシータグアクセスを正しくスコープするには、Identity Access Managerでユーザーロールバインドの CEL 条件を編集する必要があります。
Grant Access UI は、次のような CEL 条件を生成します。
この条件は、すべてのリソースレベルでPolicyTags.sensitivity == "high"をチェックします。データセットにsensitivity: highが設定されていない場合（テーブルのみに設定されている場合）、データセットチェックに失敗し、ユーザーはアクセスを拒否されます。
これを修正するには、Resourceを使用してポリシータグチェックを特定のリソースレベルにスコープするように CEL 条件を編集します。
この条件は、次のことを意味します。
- データセット レベル: 常に通過（タグチェックは必要ありません）
- テーブル レベル:
sensitivity: highが必要 - 属性 レベル: 常に通過（タグチェックは必要ありません）
CEL 条件を編集するには、次の手順に従います。
- Identity Access Managerを開き、ユーザーまたはグループに移動します。
- ADAC ロールバインド（サービス
adacのもの）を見つけます。 - 条件の編集をクリックします。
- CEL エディタに切り替え、生成された条件をリソーススコープ版で置き換えます。
- 保存します。
1行目のコメント// Permissions are managed in Lakehouse Manager. Do not update here!に注意してください。これは、Grant Access UI によって自動生成されます。CEL コンテンツの下部を、リソーススコープ条件で安全に置き換えることができます。
一般的な CEL パターン
以下は、一般的なシナリオ用の使用可能な CEL パターンです。各パターンでは、タグキーと値を独自のものに置き換えてください。
重要: 単純なパススルー（例：|| Resource == "dataset"）があるリソースレベルでは、そのレベルでタグの強制は行われません。タグチェックを意図的にスキップしたいレベルのみにパススルーを使用してください。以下のすべてのパターンでは、条件をゲートチェーンの順序でリストしています: データセット → テーブル → 属性。
1. すべてのレベル（データセット、テーブル、属性）でタグを強制する（完全なアクセス制御に推奨）
これは、すべてのレベルでタグをチェックします。level 1 + level 2を持つユーザーは、データセット、level 2までタグ付けされたテーブル、level 2までタグ付けされた属性にアクセスできます。level 3でタグ付けされた属性は拒否されます。
2. テーブルレベルのみでタグを強制する（データセットと属性はパススルー）
これは、テーブルのみにタグを付け、データセットレベルまたは属性レベルの制限が不要な場合に使用します。注意: このパターンでは、属性レベルのタグは強制されません。
3. 特定のタグが付いていないテーブルへのアクセスを付与する
4. データセットレベルのみで強制する（すべてのテーブルと属性はパススルー）
これは、データセットレベルのみでアクセスを制限する必要がある場合に使用します。データセットのゲートが通過すれば、データセット内のすべてのテーブルと属性にアクセスできます。
5. データセットとテーブルレベルで強制する（属性はパススルー）
このパターンでは、属性レベルのタグは強制されません。
6. 属性レベルのみで強制する
7. 複数のタグ値を組み合わせる（ユーザーはリストされた値のいずれかが必要）
CEL 構文、演算子、および視覚的な条件ビルダーについての詳細については、ロールと条件、CEL 条件を参照してください。
ベストプラクティス
-
まずデータセットレベルでタグ付けします。ゲートチェーンはデータセットから始まるため、タグ付けされたテーブルを持つ未タグ付けのデータセットは混乱を招く設定になります。データセットにベースラインタグを設定します。
-
リソーススコープ CEL 条件を使用します。生産環境のアクセス制御には、Grant Access UI によって生成されるデフォルトの CEL に依存しないでください。常に CEL を編集して
Resourceスコープを含めます。 -
CEL チェックをデータセット → テーブル → 属性の順序で行います。これはゲートチェーンの評価順序に一致し、条件を読みやすく、デバッグしやすくします。
-
タグ構造をシンプルに保ちます。単一のタグキー（例：
sensitivity）と少数の値（例：public、internal、restricted）を使用します。深く入れ子になったタグの組み合わせは避けてください。 -
累積タグを付与します。ユーザーはチェーン内のすべてのレベルのタグが必要です。ユーザーが
restrictedテーブルアクセスが必要な場合、親データセットのタグも必要です。 -
専用ユーザーでテストします。アクセスポリシーを展開する前に、テストユーザーを作成し、ゲートチェーンの各レベルを独立して確認します。アクセス制御のテストを参照してください。
-
CEL 条件を定期的に監査します。ポリシータグが変更されるにつれて、ロールバインドの CEL 条件が古くなることがあります。タグバインドを変更する際に、それらを確認してください。
-
タグスキーマを文書化します。使用中のタグキーと値、それらの意味、およびバインドされているリソースを記録してください。
さらに詳しく
当社のソリューションのトレーニングや技術的なサポートが必要な場合は、営業担当者にお問い合わせください。または、Professional Services ページをご覧になり、見積もりをリクエストして、当社の専門家がプロジェクトを分析していただくこともできます。
質問をする、フィードバックを送る、または Data Platform を構築しているチームと直接交流するには、専用の Discord チャネル をご利用ください。
OVHcloud サービスについてサポートが必要な場合は、Help Centre でリクエストを作成してください。
ユーザーコミュニティ に参加してください。