[10.2.8~] WAC RBAC Guide

QueryPie WACはRBAC（Role-Based Access Control）を提供しています。

このドキュメントでは、10.2.8 以上のバージョンに適用されるWACロールとポリシーについて説明します。

WACロールとポリシー

ポリシー（Policy）はWACに登録されたリソースに対してどのようにアクセスを制御するかを記述した仕様で、YAML形式で記述します。
- Webアプリリソースに対する許可またはブロックが含まれます。
ロール（Role）はユーザーが何をできるかできないかを定義するオブジェクトです。
- ロール1つの中には複数のポリシーを割り当てることができ、この場合ポリシーはOR条件で結合されます。
- 同一のWeb Appおよびサブパスに対する複数のポリシーが存在する場合、ブロック（Deny）ポリシーが許可（Allow）ポリシーより優先されます。
ユーザーは複数のロールを割り当てられますが、一度に1つだけを選択して使用します。

注意ロールに含まれるポリシーをすべて統合した時、最低1つの許可ポリシーが残っていなければなりません。
ブロックポリシーのみで構成されたロールは何のアプリケーション権限も付与しないため、正常な使用が不可能です。

WAC YAMLポリシーの基本構造

WACのポリシーはYAML形式で記述され、その基本構造は以下の通りです。

YAMLドキュメント例


apiVersion: webApp.rbac.querypie.com/v1
kind: WacPolicy

spec:
  allow:
    resources:
      - webApp: "Querypie Web Admin"
        urlPathTags:
          access: "admin"
      - webApp: "QueryPie Customer Portal"
        urlPaths: ["*"]
    conditions:
      userAttributes:
        department: "White"
      ipAddresses:
        - "10.10.0.0/24"
        - "10.10.1.79"
  deny:
    resources:
      - webApp: "Querypie Web Admin"
        urlPaths:
          - "/general-settings/user-management/roles"

YAML仕様

Category	Property	Required	Description	Valid Values
`apiVersion`	-	required	記述されたYAML Codeのバージョンシステムで管理する値で、修正不要	`webApp.rbac.querypie.com/v1`
`kind`	-	required	記述されたYAML Codeの種類システムで管理する値で、修正不要	`WacPolicy`
`spec:` `<effect>`	-	required	ポリシー内の詳細ルール（許可または拒否）	`allow`, `deny`
	`resources`	required	アクセスを許可/拒否するリソース指定	`webApp`, `urlPaths`, `urlPathTags` (urlPathTagsは `spec: allow` でのみ使用可能)
	`conditions`	OPTIONAL	ルール適用対象に対する詳細条件 (現在 `spec: allow` でのみ使用可能)	`userAttributes`, `ipAddresses`

以下でポリシー記述に必要なQueryPie WAC Policy YAML文法を案内します。

spec: <effect> required

ポリシーの具体的なルールの許可または拒否の有無を指定します。spec: allow または spec: deny をサポートします。

1つのポリシーには最大1回の allow、1回の deny のみが存在できます。
ポリシー内で同一の要素に対して deny と allow が同時に宣言された場合、deny が優先されます。

Resources required

許可またはブロックポリシーを設定したいWebアプリリソースを指定します。配下に webApp を必須で持ち、urlPaths または urlPathTags を持ちます。

resources は spec: allow、spec: deny で両方とも許可されます。ただし、urlPathTags による明示は spec: allow でのみサポートされます。

webApp required

QueryPieに定義したWebアプリリソース名を入力します。

明示的にWebアプリを特定する必要があり、ワイルドカードや正規表現は許可されません。
- - webApp: "QueryPie" (O)
- - webApp: "*Query*" (X)
- - webApp: "QueryPie$" (X)
1つの spec 内で複数のWebアプリを列挙できます。


spec:
allow:
  resources:
    - webApp: "Querypie Web Admin"
      urlPaths:
        - "/general-settings/user-management"
        - "/database-settings/policies"
    - webApp: "QueryPie Customer Portal"
      urlPathTags:
        access: "admin"

Webアプリ名は以下の条件を満たす必要があります。
- 文字数最大120文字
- アルファベット大文字小文字（case-sensitive）、数字および一部特殊記号（_、-、(、)、[、]）のみ許可
- スペース許可
- 開始と終了はアルファベット大文字小文字または数字に制限
- 重複不可

Webアプリのサブパスレベルでアクセス制御ポリシーを運用するためには、webApp 配下に urlPaths または urlPathTagsを入力できます。 1つのポリシー内で、1つのWebアプリに対して urlPaths と urlPathTagsを同時に指定することは 不可能 です。

urlPaths OPTIONAL

ポリシーを適用したい特定のWebアプリリソースのサブパスを特定します。

Admin > Web App に登録されたサブパスのみ登録可能です。
Base URLを含めて、Webアプリに存在する すべて のサブパスに対して許可または拒否するには urlPaths: ["*"] で記述します。
- 例：QueryPie Web Admin の全体パスに対してアクセスブロック

spec: deny: resources:

webApp: “Querypie Web Admin” urlPaths: [”*”]


3. サブパス入力時、入力したパスに対してポリシーが適用されます。
* サブパスはリストで列挙し、複数入力できます。
* パスの最後の部分にワイルドカードを入力して、特定パス配下のすべてのパスを指示できます。（上位パスは含みません）

spec: allow: resources:

webApp: “Querypie Web Admin” urlPaths:
- “/general-settings/user-management” # 特定のサブパス
- “/general-settings/user-management/*” # 特定パスのすべてのサブパス


* 入力したパス中に相互に重複するパスを同時に入力できません。
  * 例：QueryPie Web Admin の `/general-settings/*` と `/general-settings/user-management` を **同時に入力不可**

spec: allow: resources:

webApp: “Querypie Web Admin” urlPaths:
- “/general-settings/*”
- “/general-settings/user-management”

パスの中間またはパス名の一部にワイルドカードを入力したり、正規表現を入力することは できません 。
- "/*-settings" (X)
- "/*/edit" (X)
- "^/database-settings/policies/data-.*$" (X)
同一のリソース（およびサブパス）に対してブロックポリシーと許可ポリシーが重複する場合、ブロックポリシーが優先適用されます。

urlPathTags OPTIONAL

Webアプリに登録されたサブパス別URL Pathタグを基準に、アクセスを許可するサブパスを指定します。

タグは大文字小文字を区別し、複数入力できます。
- Keyが同一のタグを複数入力時、OR 条件で動作します。
  - 例：access: admin または access: user が付与されたパスに対してアクセス許可

urlPathTags: “access”: “admin” “access”: “user”


* Keyが異なるタグを複数入力時、**AND** 条件で動作します。
* 例：`access: admin` と `type: general` が一緒に付与されたパスに対してアクセス許可

urlPathTags: “access”: “admin” “type”: “general”



### Conditions <Badge color="green">OPTIONAL</Badge>

`conditions` はルール適用対象リソースの範囲を狭めるための条件を定義します。`userAttributes`、`ipAddresses` 2種類の条件指定が可能です。

<Callout type="info">
`conditions` はspec:allowでのみ文法的に許可されます。
</Callout>

#### userAttributes <Badge color="green">OPTIONAL</Badge>

QueryPieユーザーの属性（attribute）を基準にルールによってリソースアクセスが許可されるユーザーの範囲を限定します。

<Callout type="info">
ユーザー属性はAdministrator &gt; General &gt; Usersメニューのユーザー別詳細ページで照会できます。
QueryPieで追加されたユーザーの属性は詳細ページで追加/変更/削除などが可能で、IdP同期によって追加されたユーザーの属性はユーザー元帳（Okta、LDAPなど）で変更できます。
</Callout>

属性情報は大文字小文字を区別し、複数入力できます。

* Keyが同一の属性を複数入力時、OR条件で動作します。
* 例：部署（department）がPMまたはQAのユーザーに対してアクセス許可

userAttributes: “department”: “PM” “department”: “QA”


* Keyが異なる属性を複数入力時、AND条件で動作します。
* 例：部署（department）がPMで、職位（title）が管理者のユーザーに対してアクセス許可

userAttributes: “department”: “PM” “title”: “Manager”



#### ipAddresses <Badge color="green">OPTIONAL</Badge>

リソースに対するIPアクセス制御条件リストを単一IP、CIDR形式で定義します。

ipAddresses: [“10.10.0.0/24”, “10.11.10.1”]



別途定義しない場合、デフォルト値はすべて許可（`0.0.0.0/0`）です。

## 推奨する運用方式

権限別にアクセスを許可するWebアプリおよびサブパスを指定する方式を推奨しています。

1. Webアプリ別に存在する権限リストを確認します。
    1. 例：採用プラットフォームに対して、
        1. HR - すべての権限を持つ
        2. 面接官 - 面接結果を管理するページにのみアクセス可能
2. Webアプリの権限別にそれぞれRoleを作成します。
    1. HR, Interviewer
3. 権限別アクセスポリシーをそれぞれ作成し、RoleにAssignします。
    1. HR - 採用プラットフォーム内のすべてのパスに対してアクセス許可
    2. Interviewer - 採用プラットフォーム内の面接結果ページにのみアクセス許可

<Callout type="important">
**注意**

一部許可パターンを使用する場合、正常なウェブサイト使用のために **必ず入場が必要なランディングページ** を別途ポリシーで構成し、ロールに入れてあげなければなりません。

* 例：ログインページ、リダイレクトページなど
</Callout>


アクセスを許可するサブパスを指定するための方法は以下の2つの中から選択してください。

#### タグベースアクセス制御

WebアプリにPathを登録し、各Pathに適切なタグを付与した後、ポリシーでタグベースにアクセスを制御することを推奨します。
この方式を使用すると以下のような利点があります。

*  **ロールベースポリシー管理の容易性** : 特定ロールに必要なパスに同一のタグを付与して管理可能
*  **ポリシー保守の簡素化** : Webアプリに新しいパスが追加されても適切なタグのみ付与すれば既存ポリシー修正なしでアクセス制御可能
*  **複雑なアクセス制御の実装** : 多様な条件（ユーザー属性、IPアドレスなど）とタグを組み合わせて細かいアクセス制御実装可能

#### ワイルドカード活用

新しくサポートされるワイルドカード機能を活用して、特定パス配下のすべてのページに対するアクセスを効率的に制御できます。

* 管理ページの全体アクセス制御：`/admin/*`
* 特定機能モジュール全体アクセス制御：`/module/orders/*`