Pega の ABAC でフィールド単位のアクセス制御を実現する

結論から：フィールド単位の見せ分けは ABAC で実現する

「この案件は担当者にしか見せたくない」「顧客のマイナンバーや口座番号は一部の役割にだけ表示したい」——こうした 1 件ごと・1 項目ごとのアクセス制御 は、Pega では ABAC（属性ベースアクセス制御 / Attribute-Based Access Control） で実現します。具体的には Access Control Policy と Access Control Policy Condition を組み合わせ、フィールドの見せ分け（マスキング）には PropertyRead 系のアクションを使います。

重要なのは、ABAC は既存の RBAC（役割ベースアクセス制御 / Role-Based Access Control）を置き換えるものではなく、補完するもの だという点です。そして最大の落とし穴は「後付けで ABAC を入れようとして、判定に使える属性がデータモデルに存在せず改修になる」ことです。本記事では、この設計判断を実装観点で整理します。

RBAC と ABAC — 役割分担を正しく理解する

まず、この 2 つは「どちらを使うか」ではなく「どう組み合わせるか」という関係にあります。

• RBAC は「その役割（Role）が、そのクラスやアクションに対して操作できるか」を判定します。判定の入力は ユーザーが持つ役割 です。粒度はクラス単位・ルール単位で、静的です。
• ABAC は「いま扱っているその 1 件のインスタンスの属性値」を見て、アクセスの可否を動的に判定します。判定の入力は 対象データの属性 と 要求者側の属性 の突き合わせです。Pega 公式でも ABAC は「クラスの特定インスタンスへのアクセスを制限する」インスタンス（行）レベルのセキュリティ と位置付けられ、さらに プロパティ単位（項目＝列に相当）のマスキング まで踏み込めるものとされています。

言い換えると、RBAC は「与信審査担当者はケース種別 X を開ける」という クラス単位の許可、ABAC は「開けるケースの中でも、自分の支店が担当している案件だけ」「顧客区分が VIP の口座番号は非表示」という インスタンス単位・項目単位の絞り込み を担当します。

観点	RBAC（役割ベース）	ABAC（属性ベース）
判定の入力	ユーザーの役割（Role）	対象データの属性 + 要求者の属性
粒度	クラス / ルール単位	インスタンス単位・フィールド単位（行・列レベル）
判定タイミング	静的（役割が決まれば固定）	動的（そのレコードの値で毎回評価）
代表的な用途	「営業はこのケース種別を扱える」	「自分の担当案件だけ」「機微項目はマスク」
Pega の実装	Access Group / Role / RBAC ルール	Access Control Policy + Policy Condition

Pega の ABAC はどう構成されるか

Pega の ABAC は、大きく 2 つのルールで構成されます。

1. Access Control Policy — 「どのクラスの、どのアクションに対して」ポリシーを適用するかを定義します。適用先のクラスと、対象となるアクション種別を指定します。
2. Access Control Policy Condition — 実際の可否を決める条件式です。ここで 対象インスタンスのプロパティ と 要求者側の属性（アクセスグループやクリップボードから取得する属性など）を比較し、true / false を返します。

つまり ABAC の判定ロジックの本体は Policy Condition にあり、Access Control Policy は「その条件をどのクラス・どのアクションに紐づけるか」を宣言する枠だと捉えると設計しやすくなります。

アクション種別と適用範囲は必ず公式ドキュメントで確認する

Access Control Policy が扱えるアクション種別には、一般に Read（読み取り）／Update（更新）／Delete（削除）／Discover／PropertyRead（プロパティ単位の読み取り） などがあります（Discover は、Read 条件を満たさないケースについて限定的な情報だけを見せるためのアクションです）。どのアクション種別が使えるか、そしてポリシーを適用できるクラスの範囲（ケース種別のクラスか、データクラスか等）は、Pega のバージョンによって差があります。「このアクションはこのクラスに効くはず」と記憶で断定せず、採用するプラットフォームバージョンの公式ドキュメントで、対応するアクション種別と適用可能なクラス範囲を必ず確認してください。設計初期にここを取り違えると、条件は正しいのに意図した箇所に効かない、という手戻りが起きます。

フィールド単位の見せ分け（マスキング）を PropertyRead で実現する

「レコード自体は見せてよいが、特定の項目だけ隠したい」というフィールド単位のマスキングは、PropertyRead 系のアクションを対象にした Access Control Policy で実現します。

• Read（インスタンス全体の読み取り） を制御すると、条件に合致しないユーザーには そのレコード自体が見えなくなります（一覧・レポート・検索結果にも出ません）。
• PropertyRead（プロパティ単位の読み取り） を制御すると、レコードは開けるが 特定のプロパティ値だけがマスクされる、という見せ分けができます。

この使い分けが実装上の肝です。たとえば「コールセンターのオペレーターは顧客ケースを開けるが、クレジットカード番号のフルは見えず下 4 桁のみ」というのは、レコード全体は Read 許可のまま、カード番号プロパティに PropertyRead のポリシーをかけて実現します。「そもそもこのレコードを一覧にも出したくない」なら Read 側で絞ります。

PropertyRead には「マスク方法」と「最適化プロパティ」という前提がある

PropertyRead ポリシーでは、値をどうマスクするかを選べます。テキスト型なら 全体マスク（Full Mask）／末尾 N 文字以外をマスク（Mask all but last ‘N’）／先頭 N 文字以外をマスク（Mask all but first ‘N’） といった方式が用意されており、先ほどの「カード番号は下 4 桁のみ表示」はこの「末尾 N 文字以外をマスク」で実現します（日付型・整数型には、年だけ／日と月だけを伏せる、といった別のマスク方式があります）。

ただし、ここには実装上の重要な前提が 2 つあります。

• プロパティ単位のポリシーは、最適化（公開列化）されたプロパティにしか適用できません。 マスクしたい項目が最適化されていなければ、まずデータモデル側でその項目を最適化する必要があります。これは後述の「後付けで失敗する」パターンに直結します。
• プロパティ単位のポリシーが強制されない領域があります。 取得時点で利用者の資格情報が確定しない形でデータを取り回す機能——ノードスコープ／クラスタスコープのデータページや、スケジュール実行されるレポートなど——ではマスクが効きません。機微項目をこうした経路に載せる設計は避けてください。

マスク方式や適用可否の細部はバージョンにより異なるため、採用するプラットフォームバージョンの公式ドキュメントで確認してください。

★最重要：ABAC は RBAC を「補完」する（置き換えない）

ここが設計を誤りやすい最大のポイントです。Pega の公式ドキュメントでも「ABAC は RBAC のセキュリティ機能を補完・拡張する（supplements and extends）」と明記されており、RBAC と ABAC の両方を通過して初めてアクセスが許可されます。両者は AND 条件です。公式の表現でも「ABAC ポリシーがアクセスを許可した場合でも、RBAC も適用され、RBAC も許可しなければならない」とされています。

• RBAC で 拒否 されたものを、ABAC で 許可 に戻すことは できません。
• ABAC は「RBAC で許可された範囲を、さらに属性で絞り込む」方向にしか働きません。

したがって設計の順序は必ず「まず RBAC で役割ごとの大枠の許可を設計し、その内側を ABAC で属性により絞る」となります。「RBAC が厳しすぎるから ABAC でこじ開ける」という発想は原理的に成立しません。もし ABAC で許可したいのに見えないなら、疑うべきは先に RBAC（Access Group / Role）の設定です。

やりたいこと	使うべき仕組み
役割単位でケース種別・機能の可否を決める	RBAC（Role / Access Group）
許可された中で「自分の担当案件だけ」に絞る	ABAC（Access Control Policy + Condition）
レコードは見せるが特定項目だけ隠す	ABAC の PropertyRead
RBAC で拒否した操作を一部ユーザーに開放する	RBAC 側を見直す（ABAC ではできない）

具体例：与信情報を含むケースでの見せ分け

一般的な融資審査アプリを例にします。ケースには「申込者の年収」「信用スコア」といった機微なプロパティが含まれるとします。

1. RBAC：審査担当グループにはケース種別「与信審査」の Read/Update を許可、事務担当グループには Read のみ許可。この時点では両グループとも全項目が見えます。
2. ABAC（Read）：ケースに 担当支店 プロパティを持たせ、Policy Condition で「要求者の所属支店 = ケースの担当支店」を評価。これで、担当外支店の審査担当者には そのケース自体が見えなく なります。
3. ABAC（PropertyRead）：信用スコア プロパティに対して「役割が審査担当のときのみ表示」の PropertyRead ポリシーを設定。事務担当はケースは開けるが 信用スコアだけマスク される、という状態を作れます（このとき 信用スコア は、プロパティ単位ポリシーの対象にできるよう 最適化済みプロパティ である必要があります）。

この 3 段構えで初めて「支店・役割・項目」の三軸で機微データを制御できます。RBAC だけでは 2 と 3 は表現できず、ABAC だけでは 1 の大枠が抜けます。

よくある失敗 — 後付けの ABAC

最も多い失敗は、アクセス制御を後回しにして、リリース間際に ABAC を差し込もうとする パターンです。ここで初めて「ABAC の判定に使える属性が、そのケースやデータオブジェクトに存在しない」ことに気づきます。

先の例で言えば、「担当支店で絞りたい」のにケースに 担当支店 プロパティが無い、あるいは値が確実に埋まっていない——という状況です。こうなると、

• データモデルにプロパティを追加し、
• 既存データにバックフィル（過去分の値埋め）を行い、
• ケース作成フローで値がセットされるよう改修し、
• （項目マスクをかけたい場合は）そのプロパティを最適化（公開列化）し、
• そのうえで Access Control Policy を組む、

という広範囲の改修が発生します。ABAC の条件式そのものは短くても、判定に必要な属性をデータに載せる工事 が本体になってしまうのです。

もう一つの典型は「ABAC で全部やろうとする」失敗です。役割で切れる大枠まで Policy Condition に詰め込むと、条件が複雑化・重複し、保守も評価コストも悪化します。役割で切れるものは RBAC、属性でしか切れないものだけ ABAC という切り分けを守ることが、結果的に一番シンプルになります。

設計の順序：データモデルとアクセス制御は同時に

後付け ABAC を避ける唯一の方法は、アクセス制御をデータモデル設計と同時に決める ことです。実務では、データオブジェクトやケース種別を設計する段階で次を必ず洗い出します。

• この情報は「誰に・どの粒度で」見せるのか（役割 / インスタンス / 項目）。
• インスタンス単位・項目単位で絞るなら、判定に使う属性は何か。それはこのオブジェクトに載っているか。項目マスクをかけるなら、その属性は 最適化 されているか。
• その属性は いつ・誰が・確実に埋めるのか（作成時・承認時・連携時）。

この 3 点をデータモデル設計のレビュー項目に組み込んでおけば、「見せ分けたいのに属性が無い」という後戻りはほぼ防げます。アクセス制御は「あとで振りかける調味料」ではなく、データモデルの一部 として最初から設計するもの、と捉えてください。

まとめ

• Pega でフィールド単位・レコード単位の見せ分けを実現するのは ABAC（Access Control Policy + Policy Condition）。項目マスキングは PropertyRead を使い、対象は 最適化済みプロパティ に限られる。
• ABAC は RBAC を補完 する。両方通過して初めてアクセスでき、RBAC で拒否したものを ABAC で許可はできない。役割で切れるものは RBAC、属性でしか切れないものだけ ABAC。
• アクション種別（Read / Update / Delete / Discover / PropertyRead 等）と適用クラスの範囲、マスク方式は バージョンごとに差がある ため、公式ドキュメントで確認する。
• 最大の失敗は 後付け ABAC。判定に使う属性が無く大改修になる。アクセス制御は データモデル設計と同時 に決める。

機微情報の取り扱いは、設計の初期判断がそのままセキュリティ品質と改修コストに直結します。要件段階で「誰に・どの粒度で・どの属性で絞るか」を固めておくことが、堅牢で保守しやすい Pega アプリケーションへの近道です。

関連リンク

• Pega Platform 開発支援
• Pega DevOps 導入支援
• Pega Constellation UI と Cosmos の違いを徹底比較
• Pega Constellation UI で「できないこと」と現実的な回避策
• Pega の Picklist と Data Reference の使い分け
• Pega設計の分岐点：ケースにすべきか、データインスタンスか
• 無料相談に申し込む