ポリシータグを使用してデータアクセスを制御する#

#目的

Policy tagsは、データセット、テーブル、属性にキー値ラベルを割り当てることで、細かいデータアクセス制御を可能にします。Identity Access ManagerのCEL条件と組み合わせることで、どのユーザーが特定のデータを読み書きできるかを決定します。

#目次

1. はじめに
2. アクセス評価の仕組み
3. 新しいポリシーテグの作成
4. ポリシーテグの設定
5. ポリシーテグをデータにバインドする
6. 次のステップ

#はじめに

ポリシータグは、データセット、テーブル、属性にアクセスカテゴリ（例：sensitivity: high、department: finance）を表すキー値ペアでラベルを付けることを可能にします。これらのラベルは、IAMロールバインドに添付されたCEL条件で参照され、どのユーザーがどのデータにアクセスできるかを制御します。

A policy tag consists of two parts:

• Key: 一意の識別子（例: "sensitivity"、 "department"）。
• Value: キーには複数の値を持つことができます（例: "high"、 "medium"、 "low"）。

#アクセス評価の仕組み

ユーザーがデータにアクセスしようとすると、システムは順次ゲートチェーンを通じてその権限を評価します。このチェーンを理解することは、ポリシータグとCEL条件を正しく設定するために不可欠です。

#ゲートチェーン

システムは、3つのリソースレベルで、順番にユーザーのCEL条件を確認します。

1. データセット: ユーザーのCEL条件はこのデータセットに適用されますか？
2. テーブル: ユーザーのCEL条件はこのテーブルに適用されますか？
3. 属性: ユーザーのCEL条件はこの属性に適用されますか？

各レベルは、次のレベルが評価される前に通過する必要があります。どのレベルでも失敗すると、アクセスは即座に拒否されます：システムは次のレベルに進みません。

flowchart LR
    D[Dataset check] -->|PASS| T[Table check]
    D -->|FAIL| X1[DENIED]
    T -->|PASS| A[Attribute check]
    T -->|FAIL| X2[DENIED]
    A -->|PASS| G[ACCESS GRANTED]
    A -->|FAIL| X3[DENIED]

    style G fill:#28a745,color:#fff
    style X1 fill:#dc3545,color:#fff
    style X2 fill:#dc3545,color:#fff
    style X3 fill:#dc3545,color:#fff

#継承

リソースにポリシータグが明示的に割り当てられていない場合、親からタグを継承します。

• テーブル: テーブルにポリシータグが設定されていない場合、親データセットからタグを継承します。
• 属性: 属性にポリシータグが設定されていない場合、親テーブル（データセットから継承している可能性があります）からタグを継承します。
• データセット: データセットは階層の最上位であり、何からも継承しません。

継承は下方向にのみ流れます。テーブルのタグは、その親データセットに上方向に伝播されることは決してありません。

#累積アクセス要件

各ゲートチェーンのレベルは独立して評価されるため、異なるレベルのタグは重複します。以下の例では、access_levelというタグキーを使用し、level 1、level 2、level 3という値をデータセット、テーブル、属性レベルに適用しています。

セットアップ:

• Dataset: access_level: level 1
• Table chicago_calendar_full: access_level: level 2
• Attribute bridge (in chicago_calendar_full): access_level: level 3

このデータセット内の他のテーブルには明示的なタグがなく、データセットからlevel 1を継承します。

• User_A (level 1のみ): タグの付いていないテーブルにアクセスできます（level 1を継承します）。 chicago_calendar_fullにアクセスできません：データセットのゲートは通過しますが、テーブルのゲートで失敗します（level 2が必要です）。 bridgeにアクセスできません。
• User_B (level 1 + level 2): タグの付いていないテーブルとchicago_calendar_fullにアクセスできます。 bridgeを読み取れるかどうかは、CELによって異なります：CELが属性レベルでタグをチェックする場合、bridgeは拒否されます（level 3が必要です）。 CELが属性にパススルーを使用する場合、bridgeはまだアクセス可能な場合があります。 一般的なCELパターンを参照してください。
• User_C (level 1 + level 2 + level 3): この設定で必要なすべてのタグ値を持っています。データセット、chicago_calendar_full、およびCELが各レベルでポリシータグをチェックする場合にbridgeにアクセスできます（属性パススルーについては、以下の重要な注意事項で説明します）。

-- :::info -- SQLを使用してこのシナリオを確認するには、Testing & Troubleshootingに従ってください。 -- :::

#新しいポリシータグの作成

新しいポリシータグを作成するには、次の手順に従ってください：

1. 新しいポリシータグ ボタンをクリックします。
2. ポリシータグの キー （例: "department"）、最初の 値 （例: "finance"）、およびポリシータグの 説明 を入力します。
3. ポリシータグを保存し、利用可能なタグのリストで確認します。

#ポリシーテグの設定

ポリシーテグを作成した後、Tag Informationセクションで値（例：tech、product）を追加したり、説明を更新したりして設定できます。ポリシーテグは、データのセキュリティ要件に合うように慎重に設定する必要があります。

Associated Data Resourcesセクションでは、このポリシーテグが適用されたデータリソース — テーブル、データセット、属性 — が詳細に記載されています。

#データへのポリシーテグのバインド

ポリシーテグは、さまざまなデータコンポーネントにバインドできます。

#データセット

1. データセットセクションに移動します。
2. ポリシーテグを適用するデータセットを選択します。
3. 利用可能なタグから適切なポリシーテグを選択して、データセットにバインドします。

#テーブル

1. テーブルセクションに移動します。
2. ポリシーテグを適用するテーブルを選択します。
3. データセットと同様の手順に従って、ポリシーテグをテーブルにバインドします。

#属性

1. テーブルセクションに移動し、必要なテーブルを選択します。
2. POLICY TAGSセクションをクリックするか、特定の属性の編集アイコンをクリックします。
3. ポリシーテグを適用する特定の属性（列）を探します。または、編集アイコンをクリックして特定の属性を選択した場合は、直接ポリシーテグを追加します。
4. 適切なポリシーテグを属性にバインドします。これは、ドロップダウンから選択するか、タグ付けインターフェースを使用する場合があります。

#次のステップ

ポリシーテグの動作方法とデータへのバインド方法を理解したので、以下に進んでください。

• CEL Conditions & Access Patterns：アクセス権限の付与UI、CEL条件の記述、一般的なパターン
• Testing & Troubleshooting：アクセス制御のテスト手順、一般的なエラー
• Example: Team Access with Groups：グループを使用したオンボーディングの実世界のワークフロー

#さらに学ぶ

ソリューションの実装に関するトレーニングや技術的なアシスタンスが必要な場合は、営業担当者にお問い合わせください、またはProfessional Servicesページをご覧ください。見積もりをリクエストして、専門家がプロジェクトを分析してください。

専用DiscordチャネルでData Platformを構築するチームと直接質問し、フィードバックを共有し、交流してください。

OVHcloudサービスについてサポートが必要な場合は、ヘルプセンターでリクエストを作成してください。

ユーザーコミュニティに参加してください。