[Brazil調査] Restricted Caller Access：呼び出し元の書き換えで許可が Invalidated になる

他のスコープの Script Include を呼ぶ処理を、更新セットで本番へ移したとします。以前に許可した呼び出しは、移したあとも有効なままなのでしょうか。

この許可（Restricted Caller Access、以下 RCA）は、呼び出し元が変わると無効になる仕組みがもともとあります。Brazil では、更新セットのコミット時に無効にするかどうかを選ぶシステムプロパティが加わりました。アップグレードした PDI で、呼び出し元を書き換えると RCA がどう変わるかを動かして確かめました。無効化モードの切り替え自体は試していません。

画面で確かめた要点

以前からある動き（今回の検証で確認）

• 呼び出し元の Script Include を書き換えると、紐づく RCA が Invalidated に変わった（公式の説明どおり）

• 対象が Caller Restriction のとき、Invalidated 後の呼び出しは拒否された。Caller Tracking のときは次の呼び出しで Allowed に戻った

• 無効化の記録は、対象スコープの Default 更新セットにも入った

Brazil で加わったもの（公式の説明のみ。動きは未検証）

• 新しいプロパティ glide.sys.fencing.restricted_caller_access.invalidation_mode。値は DB_LISTENER（既定）と SCRIPT_ENGINE。更新セットのコミット時の扱いを選ぶ

• このアップグレード版 PDI にはプロパティのレコードが存在しない。既定の DB_LISTENER で動く前提になる

呼び出しから無効化までの流れは次のとおりです。

図の内容を文字でも書き出します。

• 対象が Caller Tracking：自動で Allowed。呼び出し元を変更すると Invalidated。次の呼び出しで Allowed に戻る

• 対象が Caller Restriction：拒否して Requested。管理者が Allowed にすると成功。呼び出し元を変更すると Invalidated。管理者が改めて Allowed にするまで拒否が続く

RCA の仕組み

RCA は、別のスコープのスクリプトが、あるアプリのリソース（Script Include やテーブルなど）を呼ぶときの許可を管理します。許可の1件が sys_restricted_caller_access の1レコードです。

公式は、このテーブルの役割を次のように説明しています。

（訳：Restricted caller access のレコードは、アプリ、アプリのリソース、イベントへのアクセスを要求する、別スコープのアプリやスクリプトを記録します）

引用元：Restricted caller access privilege settings

対象リソース側の Caller Access には、次の2つの設定があります。

• Caller Tracking：呼び出しを自動で許可し、Allowed として記録する

• Caller Restriction：呼び出しを拒否し、Requested として記録する。管理者が Allowed か Denied にする

公式の手順には、呼び出し元が変わったときの扱いも書かれています。

（訳：呼び出し元のリソースが変わった場合（ビジネスルールのスクリプトが変わったときなど）、RCA レコードのステータスは Invalidated に変わります。管理者かアプリ管理者が、ステータスを Allowed か Denied に更新する必要があります）

引用元：Define cross-scope access to an application resource

Brazil で加わったプロパティ

Australia から Brazil への差分ノートに、次の項目があります。

（訳：別スコープからのアクセス対象テーブルにあるソースコードのレコード（Script Include など）が更新セットでコミットされたとき、RCA レコードをどう無効にするかを、このシステムプロパティで制御します。既定ではデータベースのリスナーが更新セットのコミットを監視し、コミットの時点で RCA を無効にするため、別スコープのアクセスは最新のソースコードに基づきます）

引用元：Combined ServiceNow AI Platform core feature release notes (Australia to Brazil)

システムプロパティの一覧には、値が2つ載っています。

（訳：DB_LISTENER は更新セットのコミットを監視して、その時点で RCA を無効にします。SCRIPT_ENGINE は、更新セットに変更のあるスクリプトが含まれていても、スクリプトエンジンが関連する RCA を無効にしません）

引用元：Available system properties

型は string、既定値は DB_LISTENER です。公式は、sys_properties にプロパティを追加して使うと説明しています。

つまり、更新セットでソースを移したときに RCA を無効にするかどうかを切り替える設定です。公式の記述どおりなら、SCRIPT_ENGINE ではコミットの時点で RCA が無効化されません。実行時の扱いは確かめていません。

プロパティのレコード

アップグレードした PDI で sys_properties を検索すると、このプロパティのレコードは0件でした。公式が追加して使うと書いているとおりの状態です。

①の条件で検索し、②のとおり0件でした。値を変えたい場合は、プロパティを自分で追加します。この記事では追加も変更もしていません。

実機で動かした条件

グローバルスコープに検証用の Script Include を1つ作り、別スコープの Script Include を生成する処理を書きました。呼び出し先には、設定の違う次の Script Include を使いました。

• Caller Tracking の対象：Process Mining の ProminLicenseCheckUtils

• Caller Restriction の対象：Templated Snippets の TaskTableList

どちらもインスタンスを生成するだけで、メソッドは呼んでいません。検証用の Script Include と RCA レコードは検証後に削除しました。

呼び出し元の書き換えと Invalidated

Caller Tracking の対象を呼ぶと、RCA が Allowed で自動作成されました。続けて呼び出し元の Script Include のスクリプトを書き換えると、同じレコードが Invalidated に変わりました。

Caller Restriction の対象には、最初の呼び出しが拒否され、Requested のレコードが作られました。このレコードを Allowed にすると、呼び出しは通りました。その後に呼び出し元を書き換えたところ、このレコードも Invalidated になっています。

①の Status が2件とも Invalidated です。②の対象は、Process Mining と Templated Snippets の Script Include です。

Caller Restriction の拒否

Caller Restriction の対象を呼んだ最初の実行では、スクリプトの出力に拒否のメッセージが出ました。

②のメッセージは、対象アプリが RCA を宣言する必要があると伝え、アプリ管理者に連絡するよう案内しています。実際の例外は TypeError: undefined is not a function. で、画面上は呼び出し先が見つからないように見えます。③のとおり Requested のレコードが作られているため、原因の調査は RCA 一覧から始めるのが近道です。

許可した後に呼び出し元を書き換えた場合も、同じ拒否が出ました。

①で Invalidated に変わり、②で拒否されています。ステータスは Requested に戻らず、Invalidated のままでした。Invalidated のレコードを Allowed にし直す作業は、管理者が行います。

更新セットへの記録

前の画像の①に「Update was added to the Default [Templated Snippets] update set」とあるとおり、無効化は対象スコープの Default 更新セットにも入りました。検証中に、Process Mining と Templated Snippets の Default 更新セットが自動で作られています。

①の更新セットに、②の RCA レコードの更新が積まれています。RCA の更新は更新セットの中身なので、そのセットを移送すれば別環境へ渡る対象です（移送自体は試していません）。移送の前に、Invalidated や検証用の Allowed が混ざっていないか見ておくと安全です。今回の検証で作った更新セットとレコードは、検証後にすべて削除済みです。

許可の4つの単位

RCA の許可は、呼び出し元と対象を、スコープ全体にするか個別のリソースにするかで4通りに分かれます。

• Scope-to-scope：呼び出し元のアプリ全体から、対象のアプリ全体へ

• Scope-to-target：呼び出し元のアプリ全体から、対象の特定のリソースへ

• Source-to-scope：呼び出し元の特定のリソースから、対象のアプリ全体へ

• Source-to-target：呼び出し元の特定のリソースから、対象の特定のリソースへ

引用元：Restricted caller access privilege settings

作り方は Set the application scope, application resource, and event access にあります。

今回の検証で作られたレコードは、呼び出し元が Script Include、対象も Script Include の組み合わせでした。ソースの特定のリソースが書き換わったとき、その許可が無効になる点が、この記事の主題です。

ストアアプリの Requested RCA

アプリを導入すると、同梱された RCA の依頼が、対象アプリ側に Requested として作られます。公式は、次のように説明しています。

（訳：Requested RCA を使うと、次のファミリーリリースを待たずに、ストアアプリに保護されたリソースへのアクセスを与えられます）

引用元：Requested restricted caller access (RCA)

作成は、アップグレードサマリーの実行後に動くスケジュールジョブが非同期に行います。導入の直後は Requested が見えず、遅れて現れることがあります。確認は導入の直後と、少し置いた後の2回に分けるとよいでしょう。

今回のアップグレード済み PDI には、プロパティ glide.restricted_caller_access.requested_rca_feature.enable が true で入っていました（2026-10-09 に sys_properties で確認）。このプロパティの役割は、公式ページで確かめていません。

RCA を有効にする方法

RCA は、プラグイン com.glide.scope.access.restricted_caller で有効になります。このアップグレード済み PDI では、プラグインは有効でした。手順は Activate application restricted caller access にあります。

公式は、HR Service Delivery と Security Incident Response では、RCA が標準で有効だと説明しています。自分のインスタンスで RCA がどれだけ使われているかは、まず RCA 一覧の件数と、対象 Script Include の Caller Access の設定件数で把握します。

Workflow Studio のフロー

RCA の呼び出し元は、スクリプトだけではありません。公式は、Workflow Studio のフローとアクションにも、専用の呼び出し元の種類があると説明しています。

（訳：Restricted Caller Access Privileges テーブルには、Workflow Studio の呼び出し元を識別する専用のソースタイプがあります）

引用元：Restricted caller access to Workflow Studio flows

フローを呼び出し元として追跡するプロパティ com.glide.hub.flow.restricted_caller_access.track_flows_as_source は、この PDI で true でした（2026-10-09 に sys_properties で確認）。今回は Script Include だけを動かしたので、フローを書き換えたときの無効化は確かめていません。

RCA の一覧

アップグレードした PDI の RCA は、検証用のレコードを作る前の時点で234件でした。すべて Allowed です。Script Include の Caller Access は、74件が設定済みでした。内訳は、Caller Tracking が5件、Caller Restriction が69件です。

メニューは、System Applications の下の Application Restricted Caller Access です。同じ場所に Application Cross-Scope Access（sys_scope_privilege）もあります。RCA の確認では前者を開きます。

確認用のフィルタを2つ挙げます。

• status=3：Invalidated。再承認が必要な RCA

• status=0：Requested。新しい呼び出しの承認待ち

実務での確認手順

更新セットで別スコープの呼び出しを含む変更を移すときは、移送後に RCA を確認します。確認する場所は、対象スコープの RCA 一覧です。

1. 移送前に、呼び出し元と対象のスコープを一覧にする

2. 移送後に Invalidated と Requested のレコードを検索する

3. 呼び出し元の内容が想定どおりなら Allowed にする

4. 呼び出し元が想定外なら Denied にして、呼び出し元を調べる

SCRIPT_ENGINE を選ぶ場合、公式の記述では、更新セットで移したスクリプトに変更があっても、コミットの時点で RCA は無効化されません。実行時にどう扱われるかは確かめていないため、採用する場合は移送後の動きを先に検証します。その必要がなければ、既定の DB_LISTENER のままにします。

実機で気づいたこと

Invalidated のまま残る

Caller Restriction の対象では、Invalidated のレコードを残したまま拒否されます。新しい Requested が増えないので、Requested だけを監視すると見逃してしまいます。確認の一覧には Invalidated も加えてください。

拒否のエラーの読み方

例外は「undefined is not a function」で、アクセス拒否とは読めません。スクリプトログに出る「Security restricted」のメッセージが手がかりです。呼び出しが突然失敗したときは、ログと RCA の Status を先に見ます。

直接の書き換えの扱い

公式の手順ページには、呼び出し元が変わると RCA が Invalidated になると以前から書かれています。今回は更新セットを使わず Script Include を直接更新し、説明どおり Invalidated になりました。Brazil のプロパティが関わるのは更新セットのコミット時で、その動きは確かめていません。

検証範囲とおことわり

• 検証日：2026-10-09。Australia から Brazil へアップグレードした PDI 1台での確認

• 更新セットのコミットによる無効化は試していない。DB_LISTENER と SCRIPT_ENGINE の動きの違いは未確認

• プロパティは追加も変更もしていない

• 動かしたのは Script Include の呼び出しのみ。テーブルやイベント、Flow Designer 経由の呼び出しは未確認

• Australia 時点の動きとの比較は行っていない

• 検証用の Script Include、RCA、更新セットは削除した

関連記事は次の2本です。

• アプリとスコープ：Globalとx_の違い（sys_app）

• 共通ロジックをまとめて呼ぶ（Script Include）