[Brazil調査] 購読経由のアクセスと catalog ロール除去：カタログと申請が見えなくなる条件

Brazil に上げたあと、カタログのアイテムや申請を見られなくなる人は出るのでしょうか。この PDI では購読まわりの新プロパティは既定値の allow_bypass のままで、catalog ロールだけのテスト利用者は他人宛の申請を読めませんでした。Service Catalog に入った見え方の変更は、購読（サブスクリプション）経由のアクセスで「Available for」の条件を回避できるかを決める新プロパティと、申請系の ACL から catalog ロールと catalog_admin ロールが外れた変更です。

どちらも実機の PDI で動かして、誰が見えて誰が見えないかを確かめました。

先に押さえておくこと

• 購読経由のアクセスの扱いは glide.sc.catalog_item.subscription_enforcement で決まり、この PDI の値は既定の allow_bypass。上げただけでは従来の動きのまま

• require_criteria に切り替えると、購読があっても Available for の条件に合わない利用者にはアイテムが見えなくなる（実機で確認）

• 申請（sc_request・sc_req_item）の読み取りは、catalog ロールだけの利用者には本人宛のものに限られる。他人宛は読めない

• 公式の説明と実機には食い違いがある。catalog ロールが残っている ACL が11行ある

公式が説明している2つの変更

Brazil のリリースノート（Service Catalog、Australia から Brazil）には、この2件が別々の項目として載っています。

1つ目は購読経由のアクセスです。

（訳：サービスの購読が、カタログアイテムの「Available for」ユーザー条件を回避できるかを制御します。制御には glide.sc.catalog_item.subscription_enforcement プロパティを使います。）

プロパティの値は2つです。

• require_criteria：親のサービス提供を購読していても、条件に合わない利用者のアクセスを止める

• allow_bypass：従来の動きを保つ。既定値

2つ目は申請の ACL です。

（訳：申請管理のテーブルとフィールドの ACL は、catalog ロールと catalog_admin ロールにもとづくアクセスを付与しなくなりました。）

続けて、次の3点が書かれています。

• Request [sc_request] や Requested Item [sc_req_item] の ACL には、申請管理のロールが最低1つ残る

• catalog 系ロールしか持たない利用者は、これらの ACL でアクセスできなくなる

• 影響を受けるのは、カタログチームが管理する ACL だけ

引用元：Combined Service Catalog release notes for upgrades from Australia to Brazil

プロパティの一覧：Service Catalog properties

見え方を決める2つの経路

カタログアイテムの見え方を決めるのは、ユーザー条件（User Criteria）です。管理者は「USA Sales」のような条件のレコードを作り、アイテムやカテゴリに「Available for（使える人）」または「Not Available for（使えない人）」として割り当てます。条件の材料は所属、場所、ロールなどで、1つの条件を複数のアイテムに使い回せます。

もう1つの経路が購読です。サービス提供（service_offering）を会社・部門・場所・利用者の単位で購読すると、そのサービス提供に紐づくアイテムが見える仕組みです。この PDI には、購読を保持するテーブルが4つありました。

• service_subscribe_company（会社）

• service_subscribe_department（部門）

• service_subscribe_location（場所）

• service_subscribe_sys_user（利用者）

つまり、アイテムが見える理由は「条件に合う」と「購読している」の2通りあります。従来は、どちらか片方を満たせば見える動きでした。新プロパティは、この「どちらか片方」を、条件を必須にする方向へ変えるスイッチです。

条件を厳しくしたいアイテムほど、この違いが効きます。たとえば、特定の部門だけに配りたいアイテムに Available for を設定しても、別のサービス提供の購読を通じて他部門の人に見えていた可能性があります。require_criteria は、その抜け道をふさぐ設定です。

どちらを選ぶかは、購読をアイテムを配る手段として使うか、アクセス制御から切り離して使うかで決まります。配布が目的なら allow_bypass のまま、制御が目的なら require_criteria を検討します。

引用元：Set security for items and categories

Request Management のリリースノート（Australia から Brazil）にも目を通しましたが、ACL からのロール除去に関する記述は見当たりませんでした。変更の説明は Service Catalog 側のリリースノートにだけ載っています。申請の権限を調べるときは、Request Management のページだけを見ていると気づきにくくなります。

購読経由のアクセスのプロパティ

プロパティ1つで、購読経由のアクセスを従来どおりにも絞り込みにもできます。プロパティの実体は、システムプロパティの1レコードです。値は allow_bypass で、公式の既定値と一致しています。選択肢の表示名は、allow_bypass が「Allow multiple access paths」、require_criteria が「Require criteria match」です。

①の説明文には、リリースノートにない記述が含まれていました。

（訳：「Not available for」は常にアクセスを止めます。条件が空なら全員がアクセスできます。）

条件を設定していないアイテムは、このプロパティの影響を受けません。また「Not available for」の指定は、値がどちらでも常にアクセスを止める設計です。変化が出るのは、Available for の条件を持つアイテムに、購読経由で到達していた利用者だけです。

引用元：/sys_properties_list.do?sysparm_query=name=glide.sc.catalog_item.subscription_enforcement

アイテムが見えるかどうかの判定は、次の順に進みます。

起点は利用者がアイテムを開く操作、緑は見える結果、橙は従来どおり購読で見える結果、赤は見えない結果です。

1. Not available for の条件に該当すれば、見えない（プロパティの値に関係なく常に拒否）

2. 拒否条件に該当せず、Available for が空なら、全員に見える

3. 利用者が条件に合えば、見える

4. 条件に合わず購読もなければ、見えない

5. 条件に合わず購読があるときだけ、プロパティの値で分かれる（allow_bypass は見える、require_criteria は見えない）

購読と条件の組み合わせ

検証用のデータ

PDI には、サービス提供（service_offering）もその購読も最初からありませんでした。検証用に次の4点を作りました。

• サービスとサービス提供

• テスト利用者 kiji_test_cat による購読

• Available for を「admin のみ」にしたアイテム

• アイテムとサービス提供の紐づけ

判定の結果

kiji_test_cat でアイテムの可視判定（GlideappCatalogItem.get(id).canView()）を確かめました。

require_criteria に切り替えると、購読があっても条件に合わない利用者は見えなくなりました。結果は次のとおりです。

• 購読なし：どちらの値でも見えない

• 購読あり：①allow_bypass なら見える、②require_criteria なら見えない

• 条件に追加した場合：どちらの値でも見える

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

• 条件に合わない・購読なし：allow_bypass も require_criteria も見えない

• 条件に合わない・購読あり：allow_bypass は見える、require_criteria は見えない。設定値だけが結果を分ける

• 条件に合う・購読あり：どちらも見える。条件に合えば値は無関係

購読でアイテムを配っている環境で require_criteria に変えると、条件に合わない人が一斉に見えなくなります。購読で配るつもりのアイテムに Available for が設定されているなら、アイテム側の条件を見直す作業が先に必要です。

申請の ACL の変更

Australia では、catalog ロールや catalog_admin ロールを持つだけで申請系のテーブルに触れられる ACL がありました。

Brazil への移行ログ（アップグレード履歴ログ）を調べると、ACL のロール行（Access Roles）の削除が12件ありました。内訳は次のとおりです。

• sc_request の catalog ロールが3件

• sc_task の catalog ロールが2件

• sc_req_item.quantity の catalog と catalog_admin

• sysapproval_approver の catalog

• 名前が空のロール行が4件

公式の説明どおりの変更が、実際に適用されています。

一方で、catalog ロールが残っている ACL もありました。申請系の ACL に紐づくロール行を、catalog と catalog_admin で絞り込んだ結果が次の画面です。

• ①sc_request の catalog_admin が2行（作成と削除の ACL）

• ②sc_request.* の catalog（フィールド全体の読み取り ACL）

• ③sc_req_item.* の catalog（フィールド全体の書き込み ACL）

• そのほか sc_task の作成、sc_req_item の作成、stage・quantity・request_state の書き込みなどに残っている

残っている ACL の大半は Global パッケージに属し、この調査では該当ACLの移行ログを確認できませんでした。作成日は2026-01-05です。

sc_request.* の読み取り ACL だけは、サービスカタログ基盤のパッケージに属します。移行ログでは「Unchanged（変更なし）」でした。この ACL の必須ロールは catalog、itil、sn_request_read の3つです。

公式の「申請管理のロールが残る」という説明は成り立っています。一方で、catalog ロールが含まれなくなるという説明と、この PDI の ACL の状態は一致していません。

新規インスタンスでは状態が異なる可能性があります。

catalog ロールだけの利用者の読み取り

catalog ロールだけの利用者は、他人宛の申請を読めませんでした。ACL の行が残っているかどうかより、実際に読めるかどうかが重要です。テスト利用者を3人作り、他人宛と本人宛の申請を用意して、なりすまして確かめました。テスト利用者はメールアドレスなしで、ロールは次のとおりです。

• kiji_test_cat：catalog のみ

• kiji_test_adm：catalog_admin のみ

• kiji_test_rd：sn_request_read

• ①catalog のみの利用者は、他人宛の REQ も RITM も読めない

• ②本人宛の REQ と RITM は読める。申請者が本人であるという条件（スクリプト付きの ACL）で読めている

• ③catalog_admin のみの利用者は、読み取りは NG のまま、REQ の作成と削除、RITM とタスクの作成が OK。残っている ACL の行がそのまま効いている

• sn_request_read の利用者は、他人宛でも読める

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

• catalog のみ：他人宛の REQ・RITM は読めない。本人宛は読める。作成・削除は不可

• catalog_admin のみ：他人宛は読めない。本人宛は未確認。REQ の作成・削除と、RITM・タスクの作成は可

• sn_request_read：他人宛も本人宛も読める。作成・削除は不可

アップグレード後に管理者が確認すること

ここまでの結果から、確認する範囲は購読と申請ロールの2点に絞れます。

実機の結果から、確認の優先順位は次のとおりです。

1. 購読でアイテムを配っているかを確認する。サービス提供の購読（service_subscribe_* の各テーブル）を使っていなければ、プロパティを触る理由はない

2. 購読で配っていて、かつアイテムに Available for がある場合は、require_criteria に切り替える前に、見えなくなる人を洗い出す。テスト用の利用者でなりすまし、切り替えたあとに元へ戻して確認する

3. catalog ロールだけを持つ利用者を探す。申請の画面が必要な人には sn_request_read を付与する

4. 申請の作成や削除を catalog_admin に頼る運用がないかを確認する。この PDI では、これらの ACL の行が残っていた

ユーザー条件のデバッグ

アイテムが見えない利用者の調査には、ユーザー条件のデバッグ機能が使えます。アイテムと利用者を指定すると、どの条件に合ったか、合わなかったかが分かります。必要なロールは catalog_manager、catalog_admin、admin のいずれかです。

ただし、このデバッグが調べるのはユーザー条件だけで、ACL の判定は含まれません。申請が見えない原因の切り分けには、別途ACLのデバッグを使います。

引用元：Debug user criteria of a catalog item

確認の手順

購読と申請ロールは別の経路なので、確認も別々に進めます。着手の順序は自由で、どちらも読み取りと元へ戻せる操作だけで済みます。

• 購読を使っているかを service_subscribe_* の件数で確かめる

• Available for のあるアイテムのうち、購読にも紐づくものを洗い出す

• 洗い出したアイテムを、テスト利用者で require_criteria と allow_bypass の両方で確認する

• catalog ロールのみの利用者の一覧を作り、申請の閲覧が必要な人を sn_request_read に移す

• 作業の最後に、プロパティの値を元に戻して確認する

起点はアップグレード後、青は確認する項目、橙はテストで確認する項目、緑は対処、灰色は対応不要の場合です。購読の流れと、申請ロールの流れは独立しているため、どちらから着手してもかまいません。

この PDI で、catalog ロールを持つ有効な利用者（継承を含む）は25人、そのうち itil・sn_request_*・admin のいずれも持たない利用者は4人でした。自分の環境では、catalog ロールの保有者から、itil・sn_request_read・sn_request_write・itil_admin・admin のいずれかを持つ利用者を除いて確認します。

実機を見て気づいたこと

購読経由の挙動と Available for

プロパティ名からは、購読が絡むアイテムすべてに効くように見えます。実際に値が結果を変えるのは、Available for の条件を持つアイテムで、条件に合わない人が購読を持つときだけです。条件なしのアイテムでは、どちらの値でも全員に見えます。

影響の大きさは、対象になるアイテムの数で測れます。Available for を持ち、かつ購読にも紐づくアイテムを数えてください。この PDI では購読の登録がなかったため、数は出せていません。

ACL の行ごとの効き方

公式は catalog ロールが外れると説明していますが、PDI では移行ログ上12行が削除され、11行が残りました。残った読み取りの ACL は、テーブルではなくフィールド全体（sc_request.*）が対象です。テーブル自体の読み取りは別の ACL で決まるため、catalog のみの利用者は他人宛を読めませんでした。ACL を確認するときは、テーブルの行とフィールドの行を分けて見ます。

読み取りの判定

本人宛の申請は catalog のみでも読めました。申請者が本人かどうかを見るスクリプト付きの ACL が別にあるためです。今回のテスト利用者（catalog のみ）は他人宛を読めませんでした。承認者や代理として他人宛の申請を見ている利用者への影響は、アップグレード前後の比較をしていないため未確認です。

承認者の運用では、承認画面から申請を開く経路が別の ACL を通る可能性があります。この点は今回確かめていないため、承認を catalog ロールで受けている環境は、実際の承認画面で開けるかを個別に確認してください。

ロール別の影響の早見

実機で確かめた範囲を、ロール別に整理します。

• catalog のみ：他人宛の申請は読めない。本人宛は読める。カタログでの注文は、この確認の範囲外

• catalog_admin のみ：他人宛の申請は読めない。REQ の作成・削除と、RITM・タスクの作成は ACL の行が残っているため可能

• sn_request_read：他人宛を含めて読める。変更の影響を受けない

• itil：sc_request の読み取りと書き込みの ACL に含まれている。今回の変更の影響は確認していない

承認者や、代理で申請を確認していた担当者は、catalog ロールだけで運用していた場合に影響を受けやすい層です。

用語

• ユーザー条件（User Criteria）：所属・場所・ロールなどで利用者を絞る条件のレコード。アイテムとカテゴリに割り当てる

• Available for：アイテムを使える人を指定する割り当て。空なら全員が使える

• 購読（サブスクリプション）：サービス提供を会社・部門・場所・利用者の単位で購読する仕組み

• REQ・RITM：申請（sc_request）と申請アイテム（sc_req_item）

付録：調査で使った URL と、引用した公式説明を実機で確認する方法

本文で引用した説明文は、次の画面で同じものを開けます。

• プロパティの説明：/sys_properties_list.do?sysparm_query=name=glide.sc.catalog_item.subscription_enforcement

• 申請の ACL のロール行：/sys_security_acl_role_list.do?sysparm_query=sys_user_role.nameINcatalog,catalog_admin^sys_security_acl.nameINsc_request,sc_req_item,sc_task

• アップグレードの履歴：/sys_upgrade_history_list.do

公式ドキュメントの参照先は次のとおりです。

• Service Catalog のリリースノート（Australia から Brazil）

• Request Management のリリースノート（Australia から Brazil）

• Service Catalog properties

検証範囲とおことわり

• アップグレード前の Australia の状態は、この PDI で直接比べていない。比較は公式ドキュメントと、Brazil への適用結果を記録した移行ログにもとづく

• プロパティの切り替えは、1つのテスト用アイテムと、利用者単位の購読1件で確認した。会社・部門・場所単位の購読は試していない

• 「Not available for」の動きは、プロパティの説明文の記述だけで、実機では試していない

• 申請の権限確認は、テーブルとレコードを対象とした canRead・canWrite・canDelete・canCreate で行った。Service Portal や REST API 経由の確認は含まない

• catalog_admin のみの利用者が本人宛の申請を読めるかは確認していない

• 検証用のユーザー、サービス、サービス提供、アイテム、申請はすべて削除した。プロパティは allow_bypass に戻し、値を確認している

関連記事は次のとおりです。

• サービスカタログのロール

• サービスカタログのプロパティ

• サービスカタログのトラブル事例と解決