CEL Conditions & Access Patterns
このページでは、CEL（Common Expression Language）条件を使用して、ユーザーにポリシータグ付きのデータへのアクセスを許可する方法について説明します
Objective
このページでは、CEL（Common Expression Language）条件を使用して、ユーザーにポリシータグ付きのデータへのアクセスを許可する方法について説明します。ポリシータグの概要、ゲートチェーン、およびデータにタグをバインドする方法については、Policy Tags Overviewを参照してください。
Table of Contents
CEL Conditionsを使用してアクセスを許可する
ユーザーにポリシータグ付きのデータへのアクセスを許可するには、2つの手順が必要です。
- Lakehouse ManagerのGrant Access UIを使用して、ユーザーにポリシータグ値を割り当てる
- Identity Access ManagerのユーザーロールバインドのCEL条件を確認または編集する
Grant Access UIの使用
Grant Access UIを使用すると、ユーザーにポリシータグ値を簡単に割り当てることができます。
-
Grant Access メニューを開きます。
-
割り当てたいポリシータグを選択し、アクセス種類を指定します：Read は読み取り専用アクセス、Read and Write は両方のアクセスです。
-
ユーザーまたはグループにポリシータグ値（例：
access_level: level 1）を割り当てます。
-
アクセス設定を確認して保存します。
重要な制限: Grant Access UIは、リソースレベルのスコープを持たないCEL条件を生成します。これは、ゲートチェーンのすべてのレベル（データセット、テーブル、属性）で条件が評価されることを意味します。ポリシータグがテーブルレベルでのみ適用されている場合、データセットレベルのチェックに失敗し、ユーザーはアクセスを拒否されます。IAMでCEL条件を手動で編集して、リソーススコープを追加する必要があります。以下のCEL Conditionsを手動で記述するを参照してください。
注意: Advanced Data Access Control の権限を持っていないユーザーは、デフォルトでどのデータセット、テーブル、属性にも読み取りまたは書き込みできません。これは、ユーザーのIAM設定で確認できます。
CEL Conditionsを手動で記述する
ポリシータグアクセスを正しくスコープするには、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構文、演算子、および視覚的な条件ビルダーについてさらに詳しくは、Roles and Conditions, CEL Conditionsを参照してください。
Best Practices
-
まずデータセットレベルでタグ付けします。ゲートチェーンはデータセットから始まるため、タグ付けされていないデータセットとタグ付けされたテーブルを組み合わせると、混乱を招く設定になります。データセットにベースラインタグを設定します。
-
リソーススコープ付きのCEL条件を使用します。生産環境のアクセス制御には、Grant Access UIによって生成されたデフォルトのCELに依存しないでください。常にCELを編集して
Resourceスコープを含めます。 -
CELチェックの順序をデータセット → テーブル → 属性にします。これはゲートチェーンの評価順序と一致し、条件を読みやすく、デバッグしやすくします。
-
タグ構造をシンプルに保ちます。単一のタグキー（例：
sensitivity）と少数の値（例：public、internal、restricted）を使用します。深くネストされたタグの組み合わせは避けてください。 -
累積タグを許可します。ユーザーはチェーン内のすべてのレベルのタグが必要です。ユーザーが
restrictedテーブルアクセスが必要な場合、親データセットのタグも必要です。 -
専用ユーザーでテストします。アクセスポリシーを展開する前に、テストユーザーを作成し、ゲートチェーンの各レベルを独立して確認します。Testing Access Controlを参照してください。
-
CEL条件を定期的に監査します。ポリシータグが変更されると、ロールバインドのCEL条件が古くなることがあります。タグバインドを修正する際に、それらを確認してください。
-
タグスキーマを文書化します。使用されているタグキーと値、それらの意味、およびバインドされているリソースを記録しておきます。
さらに詳しく
当社のソリューションを実装するためのトレーニングや技術的なアシスタンスが必要な場合は、営業担当者にお問い合わせください、またはこのリンクをクリックして見積もりを受け取り、当社のプロフェッショナルサービスの専門家にプロジェクトのカスタム分析を依頼してください。
専用のDiscordチャネルで、Data Platformを構築するチームと直接質問し、フィードバックを共有し、交流してください。
OVHcloudサービスについてサポートが必要な場合は、ヘルプセンターでリクエストを作成してください。
ユーザーコミュニティに参加してください。