セキュリティ設計（カスタムロール・データアクセス・監査）

カスタムロールは「事前定義ロールのコピー（推奨はトップロールだけのコピー）＋職務ロール単位の付け外し」が基本です。ゼロから作るのは権限が少なく明確なロールだけにします
データアクセスは「BU・元帳（データアクセスセット）で大きく絞り、必要な場合だけセグメント値セキュリティで例外的に絞る」順で設計します
職務分掌（SoD）は、ロール設計で衝突を作らないことが第一です。継続的な検知は Oracle Advanced Controls（Advanced Access Controls）などの専用機能で行います
統合ユーザーは人と分け、最小権限のロールと専用のユーザー・カテゴリ（パスワード方針）で管理します
四半期アップデートで事前定義ロールは変わります。コピーしたロールは Compare Roles で差分を確認する運用を組み込みます

前提となる用語（ジョブロール・職務ロール・データセキュリティ・ポリシーなど）はセキュリティの基本を先に読んでください。

全体像

セキュリティ設計で決めることは、大きく 5 つです。

設計領域	決めること	主な成果物
機能セキュリティ	どの仕事にどの機能を許すか	ロール設計一覧（カスタムロール定義）
データセキュリティ	どの BU・元帳・勘定を扱わせるか	データアクセス設計表
職務分掌（SoD）	1 人に持たせてはいけない組合せ	SoD ルール表
認証	SSO・統合ユーザー・パスワード方針	認証方式設計・統合ユーザー台帳
監査	何の変更履歴を残し、誰が定期点検するか	監査ポリシー・点検手順

Oracle の設計ガイドラインの要点は次のとおりです。

まず事前定義ロールを評価する。合わない部分だけ変える
小さな変更は、ゼロから作るより「コピーして編集」が効率的
組織にない仕事は、カスタムのジョブロールを作る
カスタムの職務ロールは、必要な権限がセキュリティ・リファレンス実装にない場合だけ作る（一般的な導入では使わない）
集約権限は作れない

調達のセキュリティ・ガイドでは、事前定義ロールを直接付与せず、コピーして不要な権限を外したロールを付与することが推奨されています。

設定・実装の手順

カスタムロールの作り方（コピー）

Security Console > Roles タブで元のロールを検索
検索結果のロールの下矢印から Copy Role を選択
Copy Options ダイアログでコピー方式を選んで Copy Role
Copy Role: Basic Information で Role Name・Role Code・Description を確認・変更
必要なら途中のページで権限・階層を編集し、Summary and Impact Report で影響を確認
Submit and Close
Administration タブ > Role Status サブタブで状態が Complete になるのを待ってから編集

コピー方式の違いは次のとおりです。

方式	コピーされる範囲	向いている場面
Copy top role（トップロールのみ）	最上位ロールだけ。継承するロールは元と共有	職務ロールの付け外し、直接付与の権限の追加・削除（推奨）
Copy top role and inherited roles	職務ロールも含めた階層全体	継承先の職務ロール自体を変えたい場合

階層全体をコピーすると、職務ロールのコピーはカスタムロールになり、以後のアップデートで元の職務ロールに加わった変更を受け取らなくなります
集約権限はどちらの方式でもコピーされず、コピー先ロールが集約権限のメンバーに加わります
コピー後の編集は Edit Role で行います。Function Security Policies で権限の追加（Add Function Security Policy）と削除、Role Hierarchy で職務ロールの追加（Add Role → Add Role Membership）と削除ができます。削除できるのは直接継承しているロールだけです
集約権限に含まれる機能権限は、単独では付与できません。集約権限ごと階層に追加します

命名規則

ロールをコピーすると、名前とコードに既定の接尾辞が付きます（名前は「Custom」、コードは _CUSTOM。接頭辞は空）。既定値は Administration タブ > Roles サブタブで変えられます。

Oracle は、地域・機能・ロール種類が分かる名前とコードを推奨しています（例：AR_NA_ACCOUNTS_RECEIVABLE_SPECIALIST_JOB）。コードは ORA_ で始めてはいけません。ロールコードとロールカテゴリ（例：Financials - Job Roles）は後から変更できないので、最初に規則を決めます。

命名規則の例（架空）：

項目	規則	例
ロールコード	`<会社>_<地域>_<業務>_<種類>`	`SMP_JP_AP_INVOICE_ENTRY_JOB`
ロール名	業務名＋区分	SMP JP AP 請求書入力担当
ロールカテゴリ	製品＋種類	Financials - Job Roles
説明	元ロールと主な変更点	Accounts Payable Specialist をコピーし分析系の職務を削除

職務ロールの組合せ方

ジョブロールに機能権限を 1 つずつ足すより、職務ロール単位で付け外しするほうが保守しやすくなります。公式の例では、General Accountant をコピーし、職務ロール General Ledger Reporting を外して「レポート権限のない一般会計担当」を作ります。

組合せの考え方：

近い事前定義ジョブロールを選ぶ（例：Accounts Payable Specialist）
その職務ロールの一覧を「必要／不要」に仕分ける（例：Payables Invoice Creation は必要、分析系は不要）
不足は、別の事前定義ジョブロールが持つ職務ロールを追加して補う
それでも足りない機能だけ、機能権限を直接追加する

データアクセスの設計

データアクセスは、粗い単位から順に決めます。

層	仕組み	対象モジュール
1. BU	Manage Data Access for Users で BU を付与	AP・AR・調達など
2. 元帳・会社	データアクセスセット（元帳全体か第一貸借一致セグメント値）	GL
3. 勘定・部門など	セグメント値セキュリティ	GL・AP・AR・資産・会社間

BU セキュリティ：AP の請求書と支払は BU 単位で保護され、ユーザーごとに BU の明示的な付与が必要です。調達はさらに調達エージェント（Manage Procurement Agents）で調達 BU ごとの操作を管理します。

データアクセスセット：元帳全体（Full Ledger）か、第一貸借一致セグメント値（Primary Balancing Segment Value）単位で、読取専用か読取・書込を与えます。親の値を指定すると子孫の値も対象になります。

セグメント値セキュリティ（26D 時点）：COA の値セットのうち、指定したセグメントの値へのアクセスを制御します。現行の方式は「既定では全員が全値にアクセスでき、制限したいユーザーだけに規則を割り当てる」例外管理型です。

設定および保守 > Financials > Financial Reporting Structures > Manage Chart of Accounts Configurations で、Manage Segment Value Security by Business Function を開き、適用する業務機能（General Ledger、Payables、Receivables、Intercompany、Assets）を選ぶ。選ぶと補助元帳会計にも自動で適用される
同じ画面で COA の該当セグメントを選び、Value Set タブで Enable security を選んで保存
Deploy All Charts of Accounts を実行し、Publish Account Hierarchies で残高キューブへ反映
Manage Data Security から Manage Segment Value Security Rules スプレッドシートを開き、Rules シート（ポリシーと値の条件）→ Rule Assignments シート（ユーザー・業務機能・セキュリティ・コンテキスト・アクセスレベル）の順にアップロード

業務機能	組み合わせるセキュリティ・コンテキスト
General Ledger	Data access set
Payables、Receivables	Business unit
Assets	Asset books
会社間（Provider／Receiver intercompany）	Intercompany organization

セキュリティを有効にすると、全値へのアクセスを与える既定ポリシーが Authenticated User ロールに付与されます。制限は規則の割当で行います
規則を渡すためのロールは、そのためだけの空のロール（Role Category は Default）にします。ジョブロールにポリシーを付けない、ロールで階層を作らない、Security Console でコピーしない、が公式のベストプラクティスです
規則で使う階層（ツリー）はフラット化が必要です。フラット化しないと残高キューブ系のレポートで制限が効きません
業務機能による方式を使えるのは、まだどの値セットも保護していない環境です。既存の環境の扱いは公式ドキュメント（My Oracle Support の Doc ID 3054824.1）を確認してください

職務分掌（SoD）

SoD は「1 人が不正を完結できる権限の組合せ」を持たせないための統制です。

衝突の例	理由
仕入先マスタの登録・変更＋請求書の入力	架空の仕入先への支払が可能
請求書の入力＋支払の実行	入力から出金まで 1 人で完結
仕訳の入力＋同じ仕訳の承認	承認統制の形骸化
ロール・ユーザー管理＋業務ロール	自分に権限を付与できる

対策は 2 段階です。

予防（ロール設計）：衝突する職務ロールを同じジョブロールに入れない。ロール・マッピングで衝突するロールの組合せを付与しない
検知（継続監視）：Oracle Risk Management の Oracle Advanced Controls（Advanced Access Controls）では、アクセスの割当を監視するモデルとコントロールを作り、SoD 違反を検出します。モデルの条件には BU や元帳などのセキュリティ・コンテキストも使え、Manage Data Access for Users の付与と照合されます。ロール割当の定期的な棚卸しには Access Certifications が使えます

統合ユーザー

OIC などから REST・SOAP・FBDI を呼ぶ統合ユーザーは、次の方針で作ります。

人のユーザーと分ける。連携の用途ごとに分けると、権限の範囲と影響範囲が明確になります
必要な機能権限とデータアクセスだけを持つカスタムロールを付ける。Application Implementation Consultant などの強いロールを流用しない
専用のユーザー・カテゴリを作り、パスワード方針を分ける。パスワード方針はカテゴリごとに設定でき、Days Before Password Expiration の既定は 90 日です。期限切れで連携が止まらないよう、期限の設定値と更新手順を運用設計に入れます（無期限にできるかなど設定範囲は公式ドキュメントで確認）
Basic 認証よりトークン系の認証を検討する。詳細は認証・認可を参照してください

Inactive Users Report では、Web サービス要求やバッチもアクティビティに数えられます。統合ユーザーは「動いているから有効」に見えるので、台帳で管理します。

SSO（シングル・サインオン）

Fusion は SAML 2.0 のサービス・プロバイダ（SP）で、社内の IdP（SAML 2.0 対応のフェデレーション・サーバー）と連携します。Fusion 自体は IdP になれません。

Fusion のアイデンティティ基盤は OCI IAM アイデンティティ・ドメインへの移行が進んでいます（26D 時点）。移行済みの環境では、Fusion 用のアイデンティティ・ドメインで外部 IdP とのフェデレーション（SAML IdP の追加・有効化・IdP ポリシーへの割当、必要なら JIT プロビジョニング）を設定します
移行前の環境では Security Console の Single Sign-On タブで設定します。Sign Out URL・Enable Chooser Login Page、IdP メタデータのインポート、Name ID Format（Email か Unspecified）、Diagnostics and Activation タブの Test と Enable Identity Provider の順です
どちらの方式でも、IdP 側のユーザー識別子（メールアドレスかユーザー名）と Fusion のユーザー名の対応を最初に決めます
管理者が締め出されたときに復旧できるよう、IT Security Manager ロールと有効なメールアドレスを持つ管理者を確保し、メール通知を有効にしておきます

監査

種類	仕組み	確認方法
業務オブジェクトの変更履歴	Manage Audit Policies で対象オブジェクトと属性を選び、Audit Level を Auditing にする	ナビゲータ > Tools > Audit Reports
ユーザーとロールの点検	セキュリティ系のスケジュール済プロセス	出力ファイル（CSV など）

業務オブジェクトの監査設定：

設定および保守 > Manage Audit Policies
Oracle Fusion Applications セクションの Configure Business Object Attributes で Product を選び、監査するオブジェクトと属性を選んで Save and Close
Audit Level で Auditing を選んで Save and Close

監査は既定で無効です。オブジェクトを構成してから有効にしないと記録されません。サンドボックスでは設定できません
設定には Manage Audit Policies（FND_MANAGE_AUDIT_POLICIES_PRIV）、参照には View Audit History（FND_VIEW_AUDIT_HISTORY_PRIV）の権限が必要です
有効にする前の期間の履歴は残りません。本番稼働前に有効化します
Audit Reports からのエクスポートはエンティティあたり 10,000 件までです。全件が必要なら Generate Audit Report を使います

ユーザーとロールの点検に使う主なレポート：

レポート（スケジュール済プロセス）	用途
User and Role Access Audit Report	ユーザーまたはロールが持つ機能権限（オプションでデータセキュリティ・ポリシーも）
User Role Membership Report	ユーザーごとのロール付与一覧（CSV）
User Password Changes Audit Report	期間内のパスワード変更
Inactive Users Report	指定日数以上サインインしていないユーザー（Import User Login History の毎日実行が前提）

ロールの全体像は、BI カタログの Shared Folders > Security > Transaction Analysis Samples > Security Dashboard でも確認できます。

四半期アップデートで事前定義ロールが変わる影響

事前定義ロールは四半期アップデートで権限が追加・変更されます。影響はコピー方式で変わります。

トップロールのみのコピー：継承している事前定義の職務ロールの変更は、コピー先にも反映されます。継承先の変更で権限が増えることもあるので、リリース前に確認します。一方、元のジョブロール自体に直接追加された権限は反映されないため、比較して取り込みます
階層全体のコピー：コピーした職務ロールには変更が反映されません。新機能を使うには手で追加が必要です

アップデートごとの運用例：

リリース更新後に Retrieve Latest LDAP Changes と Import User and Role Application Security Data を実行
主要なカスタムロールを、新リリースの元ロールと Compare Roles で比較（Show で片方にしかない項目を表示し、Export to Excel で記録）
必要な権限を Add to Second Role でカスタムロールへ追加
テスト環境で Simulate Navigator と業務シナリオで確認し、本番へ反映

環境間でのロールの移送（カスタムロールのエクスポート／インポート）の手順は、Securing ERP の「Export and Import of Security Setup Data」を参照してください。テスト・移送の全体は環境管理・四半期アップデート・テストで扱います。

コード例

セキュリティ設計書のテンプレート例です。設計書は表で作り、移行・テスト・監査で同じ表を使い回します。

1. ロール設計一覧

ロールコード	元ロール	コピー方式	主な変更
SMP_JP_AP_INVOICE_ENTRY_JOB	Accounts Payable Specialist	トップロールのみ	分析系の職務ロールを削除
SMP_JP_AP_MANAGER_JOB	Accounts Payable Manager	トップロールのみ	変更なし（命名統一のみ）
SMP_JP_GL_ACCOUNTANT_JOB	General Accountant	トップロールのみ	General Ledger Reporting を削除
SMP_JP_INT_AP_IMPORT_JOB	新規作成	—	請求書インポートに必要な権限のみ

2. データアクセス設計表

ロールコード	セキュリティ・コンテキスト	値	付与方法
SMP_JP_AP_INVOICE_ENTRY_JOB	Business Unit	JP01 営業単位	Manage Data Access for Users
SMP_JP_GL_ACCOUNTANT_JOB	Data Access Set	サンプル商事 JP 元帳	Manage Data Access Set Data Access for Users
SVS_JP_COST_CENTER_RO（規則用ロール）	Data access set	サンプル商事 JP 元帳	Manage Segment Value Security Rules

3. SoD ルール表

ルール ID	職務 A	職務 B	対応
SOD-01	仕入先の登録・変更	請求書の入力	同一ジョブロールに入れない
SOD-02	請求書の入力	支払の実行	別担当者に付与。例外は承認と定期点検
SOD-03	ロール・ユーザー管理	業務ロール	IT Security Manager は業務ロールを持たない

4. 統合ユーザー台帳

ユーザー	用途	ロール	認証・期限管理
INT_AP_IMPORT	AP 請求書の FBDI 取込	SMP_JP_INT_AP_IMPORT_JOB	統合用カテゴリ、更新担当を決める
INT_GL_EXTRACT	残高の抽出	抽出に必要な照会ロール	同上

落とし穴とベストプラクティス

「必要な権限だけ」を徹底します。不要な権限はサブスクリプションの利用にも影響します。公式の「Predefined Roles and Subscription Impact」も確認してください
データアクセスは、まず BU・データアクセスセットで設計し、セグメント値セキュリティは例外に限定します
ロール設計一覧・データアクセス設計表・SoD ルール表を、テストケース（Simulate Navigator と業務シナリオ）と監査点検の基準として使います

試験対策ポイント

GL 模擬テスト：データアクセスセットとセグメント値セキュリティの違い（元帳・会社単位と勘定単位）、規則用ロールの考え方
AP 模擬テスト：BU 単位のセキュリティ、請求書の照会・編集に必要な権限
調達模擬テスト：事前定義ロールをコピーして使う推奨、調達エージェントのアクセスレベル
覚える用語：Copy top role と Copy top role and inherited roles の違い、_CUSTOM、Compare Roles、Manage Audit Policies、User and Role Access Audit Report