Pega のセキュリティを情シスが審査する｜導入前チェックリスト

結論から：審査項目を「責任分界」で仕分けてから証跡を求める

Pega 導入プロジェクトが動き出すと、必ず社内のセキュリティ審査（情シス・セキュリティ部門によるクラウドサービス審査）が入ります。このとき審査が長引く最大の原因は、技術の難しさではなく、「その項目は誰が担保するのか」の仕分けをせずに、すべての質問をベンダーや事業部門に一律にぶつけてしまうことです。

結論を先に言うと、審査の進め方はこうです。

審査項目をまず「プラットフォーム側（Pega Cloud が提供・運用）」「利用者側（導入企業・開発ベンダーが設計）」「境界領域（分担を文書で確認）」の3つに仕分ける。プラットフォーム側は公式の認証・報告書で、利用者側は設計書・設定値で、境界領域は責任分界の文書で確認する。

この仕分けをしてから証跡を求めると、審査の往復（質問→回答→再質問）が最少になります。本記事では、この仕分けの考え方と、審査票にそのまま転記できるチェックリストを提供します。

なぜ「実装レビュー」ではなく「導入前審査」の視点なのか

当ブログではこれまで、SSO 認証の設計や ABAC によるフィールドレベルのアクセス制御、監査証跡の設計といった「作る側」のセキュリティ設計を扱ってきました。本記事は角度を変えて、導入可否を判断する側（情シス・セキュリティ部門）の審査の視点で整理します。

審査で見るべきは「どう作るか」ではありません。何が担保されているか・誰が責任を持つか・証跡は何かの3点です。この3点が曖昧なまま質問票を送ると、「ベンダーに確認します」の往復だけで数週間が溶けます。逆にこの3点で構造化されていれば、Pega の審査は一般的な SaaS 審査のフレームにきれいに収まります。

責任分界の考え方（Pega Cloud の場合）

プラットフォーム側：公式の認証・報告書で確認する

Pega Cloud（Pega が運用する SaaS 型の提供形態）では、物理データセンター、OS・ミドルウェアのパッチ適用、通信経路の TLS 化や保存データの基盤暗号化、プラットフォーム自体の脆弱性対応といった基盤そのものの仕組みは、プラットフォーム側の責任範囲です。この分担自体が Pega 公式ドキュメントに「Pega Cloud Responsibility Model（責任共有モデル）」として整理されているため、審査資料の根拠として提示できます。

この領域を審査する方法は、設計書の査読ではなく第三者認証・報告書の確認です。SOC 2 や ISO 27001 といった認証・報告書の取得状況は更新されていくため、本記事で「取得済み」と断定はせず、審査時点で Pega 公式のコンプライアンス関連ページ・最新ドキュメントを参照して確認する建付けにしてください。確認の起点は Pega 公式の Trust Center（https://www.pega.com/trust）と docs.pega.com の Pega Cloud セキュリティ関連ページです。審査票には「確認日」と「参照した文書名」を残すのがポイントです。

利用者側：設計書・設定値を審査する

一方、次の項目はプラットフォームが機能を提供し、利用者側がそれをどう使うかを設計する領域です。「SaaS だから安全」は、この領域には一切適用されません。

• 認証 — 社内 IdP との SSO 連携（SAML 2.0 / OAuth 2.0・OIDC）をどう構成するか。ローカル認証（ID/パスワード直接ログイン）を残すか、残すなら誰に・いつまで許すか
• 認可 — ロールベース（RBAC）で職務分掌を表現し、属性ベース（ABAC）で「同じ画面でも担当外のデータは見せない」といった行・フィールド単位の制御をどこまで作り込むか
• 監査証跡 — 業務データの「誰が・いつ・何を変更したか」をどの範囲で記録するか。監査対象フィールドの選定はアプリ設計そのもの
• 暗号化（追加分） — 基盤暗号化に加えて、マイナンバー等の機微項目に属性レベルの追加暗号化を掛けるかどうか

境界領域：分担を文書で確認する

データ所在地・特権管理・ログ保全期間のように、プラットフォームと利用者の双方にまたがる項目が境界領域です。ここは「どちらかに聞けば済む」項目ではないため、責任分界を文書で確認します。詳しくは後述の「よくある指摘と回答例」で扱います。

審査チェックリスト（そのまま審査票へ）

領域	確認項目	主な責任	求める証跡
認証	社内 IdP と SSO（SAML 2.0 / OAuth 2.0・OIDC）連携するか。ローカル認証の残存範囲と期限	利用者側	認証方式設計書・IdP 連携設定
認可	RBAC で職務分掌を表現できているか。行・フィールド単位の制御（ABAC）の要否と適用範囲	利用者側	アクセス制御マトリクス（ロール×操作×データ）
監査証跡	業務データの変更履歴（誰が・いつ・何を）の記録範囲。証跡の改ざん耐性と保管先	利用者側＋基盤	監査対象フィールド一覧・保管方式
暗号化（通信）	経路の TLS 化。外部システム連携経路の暗号化	プラットフォーム側	公式ドキュメント・報告書（確認日を記録）
暗号化（保存）	保存データの基盤暗号化の有無。機微項目への追加暗号化の要否	基盤＋利用者側	暗号化方式の記載・追加暗号化の対象項目一覧
脆弱性対応	基盤パッチの適用主体とサイクル。アプリ側カスタムコードの脆弱性診断の計画	双方（分界に沿う）	責任分界文書・診断計画書
ログ取得	取得できるログの種類（認証・操作・システム）。保全期間。SIEM 等への外部転送可否と方式	境界領域	ログ一覧・保全期間・連携方式の確認記録

このまま行を審査票に転記し、「証跡」列に受領した文書名と確認日を埋めていけば、審査の抜け漏れと往復を同時に防げます。

審査でよくある3つの指摘と回答の準備

指摘1：「データは国内に保管されるのか」

データ所在地は境界領域の代表です。Pega Cloud は複数リージョンでの提供があり、提供リージョンは公式ドキュメント（Deployment regions for Pega Cloud）で公開されています。回答の型は「契約で指定するリージョンを確認し、契約書・公式文書ベースで回答する」です。「たぶん国内です」という口頭回答は審査で最も嫌われます。事業部門とベンダー任せにせず、契約前の段階でリージョンを確定させ、文書の該当箇所を証跡として添付できるようにしておきます。

指摘2：「特権 ID は誰が持ち、どう管理されるのか」

特権管理は2層に分けて回答するのが型です。（1）プラットフォーム運用者側のアクセス統制はプラットフォーム側の責任範囲であり、認証・報告書の確認事項。（2）アプリケーション管理者権限（全件検索・設定変更ができる社内ロール）は利用者側の設計事項であり、付与の最小化・定期棚卸し・操作ログの取得をアクセス制御設計に含めて回答します。この2層を混ぜて回答すると、審査側が「結局誰の責任か」を判断できず差し戻しになります。

指摘3：「ログの保全期間は社内基準（例：1年）を満たすか」

ログ保全期間も境界領域です。一般に、プラットフォーム側が保持する基盤ログと、アプリ側の監査証跡（業務データの変更履歴）では保持の考え方が別であることをまず説明します。そのうえで、社内基準に対して「どのログを・どちらの仕組みで・何年」満たすかを対応表で回答します。基盤側の保持期間だけで社内基準を満たせない場合は、ログを外部のログ基盤（SIEM 等）へ転送して自社側で保全する設計を回答に含めるのが定石です。Pega Cloud では外部ストレージ・監視基盤へのログストリーミング機能が公式に提供されています（接続先サービスや方式は契約・バージョンにより異なるため、公式ドキュメントで確認を）。転送方式の詳細は契約前に確認しておきます。

よくある失敗

失敗1：「SaaS だから安全」で利用者側の審査を素通しする

認可設計（RBAC/ABAC）や監査証跡の範囲は、プラットフォームがどれだけ堅牢でも利用者側が設計しなければ存在しません。ここを審査せずに通すと、リリース後に「退職者アカウントが残っている」「担当外の顧客データが検索できる」という、プラットフォームとは無関係のインシデントが起きます。

失敗2：オンプレ前提のチェックリストをそのまま適用する

逆方向の失敗です。「OS のパッチ適用手順書を提出せよ」「サーバー室の入退室記録を見せよ」といったプラットフォーム側の項目を利用者・ベンダーに要求すると、回答不能な質問が審査を空転させます。SaaS 型の審査では、この種の項目は第三者認証・報告書の確認に置き換えるのが正しい運用です。

失敗3：監査証跡を「後で設定すればいい」と先送りする

監査対象フィールドの選定は、データモデルと一体のアプリ設計そのものです。リリース後に「この項目も監査対象にしたい」と言っても、過去に遡って履歴は生成できません。審査の段階で監査範囲の設計書を証跡として求めることが、後付けコストの最小化に直結します。

まとめ

• Pega のセキュリティ審査は、項目をプラットフォーム側／利用者側／境界領域の3つに仕分けてから証跡を求めると最短で終わる
• プラットフォーム側は公式の認証・報告書（SOC 2 等の取得状況は審査時点の公式情報で確認し、確認日を記録）、利用者側は設計書・設定値、境界領域は責任分界の文書で確認する
• 認証（SSO）・認可（RBAC/ABAC）・監査証跡は利用者側の設計事項。「SaaS だから安全」は通用しない
• 頻出指摘のデータ所在地・特権管理・ログ保全期間は境界領域として回答の型を準備しておく
• チェックリストの「証跡」列に文書名と確認日を残す運用が、審査の往復を最少にする

---

Pega 導入のセキュリティ審査対応・設計でお困りの際は、Pega Platform 開発支援 や 無料相談 をご利用ください。Pega 認定資格の最高位 LSA（Lead System Architect）を保有するコンサルタントが、審査回答の準備からアクセス制御・監査証跡の設計までご支援します。

関連リンク

• Pega Platform 開発支援
• Pega DevOps・運用支援
• Pega の SSO 認証設計（SAML/OAuth）
• Pega の ABAC によるフィールドレベルアクセス制御
• Pega の監査証跡設計
• 無料相談に申し込む