[Brazil調査] sn_itam_restrict_asset_read の動き：true のとき snc_internal だけの利用者は担当の資産しか読めない

全社員に ServiceNow のアカウントがあるとき、資産（alm_asset）の一覧はどこまで見えてしまうのでしょうか。この PDI では、snc_internal ロールだけの利用者に、本人が担当者などになっている資産しか見えませんでした。この動きを切り替えているのが、Hardware Asset Management に追加された sn_itam_restrict_asset_read プロパティです。

公式ドキュメントは既定値を false と書いていますが、実機では true でした。テスト利用者でなりすまして、プロパティを切り替えながら見える件数を比べています。

先に押さえておくこと

• 資産テーブルの読み取りは、snc_internal のみ（またはロールなし）の利用者を、本人が関わる資産に絞る

• この PDI の値は true で、公式の「既定は false」と食い違う

• 実機では、true のときロールなしの利用者が0件、snc_internal のみの利用者が本人関連の2件を読めた

• 他のロールを1つでも持つ利用者には影響しない

公式が説明している内容

Brazil への移行向けの HAM リリースノートには、Australia Patch 5 で導入されたプロパティとして次の説明があります。

（訳：新しいシステムプロパティ sn_itam_restrict_asset_read は Australia Patch 5 で導入された。snc_internal ロールだけを持つ利用者が Asset テーブルと子テーブルを読めるかを制御する。true のとき、これらの利用者が読めるのは、本人に割り当てられた資産と、Reserved for・Managed by・Owned by などの項目で本人が参照されている資産だけ。他のロールを持つ利用者は全件を読める。既定値は false。）

引用元：Combined Hardware Asset Management release notes for upgrades from Australia to Brazil

Brazil の欄には、プロパティが読み取りを制御するという説明だけが載っています。詳しい説明は資産と CI の管理のページにあります。

引用元：Asset and CI management

snc_internal ロールとは何か

プロパティの対象は「snc_internal ロールだけを持つ利用者」です。このロールは、Explicit Roles の仕組みで内部利用者に付くベースのロールです。公式ドキュメントは次のように説明しています。

（訳：既存の利用者全員に snc_internal ロールが自動で付与される。このロールは既存のアクセス水準や動作を変えず、内部利用者と外部利用者を区別する分類として働く。）

つまり、ITIL や asset などの業務ロールを持たない一般社員は、ほぼ全員が snc_internal のみの利用者です。今回のプロパティは、この一般社員が資産を読む範囲を絞る設定だと位置づけられます。

引用元：Explicit Roles

ACL がレコードの読み取りをどう判定するかの全般は、次のページにまとまっています。

• Access Control Lists (ACLs)

• Advanced ACL configuration

• ACL types

今回の判定は Advanced ACL（スクリプト付きの ACL）で行われています。条件にロールを書く通常の ACL と違い、レコードごとに本人の項目を照合できる点が特徴です。

実機のプロパティの値

システムプロパティの画面を開くと、型は true | false、値は true でした。

①の説明文は公式のリリースノートと同じ内容です。②の値は true で、公式が書く既定値 false と食い違っています。レコードの作成日と更新日は 2026-07-02、更新者は system でした。誰かが手で変更した形跡はありません。

食い違いの原因までは確かめていません。次に見る ACL のスクリプトは、プロパティが無いときの既定値を true として書いています。実機の既定値は true と見て運用を考えます。

判定を行う ACL

このプロパティを参照している ACL は、alm_asset の読み取り（record・Allow If・Advanced）の1件だけでした。Script Include やビジネスルールからの参照はありません。

判定の流れを図にします。起点は資産レコードを読む操作、緑は読める結果、橙は条件付きで読める結果、赤は読めない結果です。

1. プロパティが true 以外なら、全員が読める

2. true のとき、ロールが snc_internal のみ、またはロールなしでなければ、全件を読める

3. 該当する利用者は、次の8項目のどれかに本人が入っている資産だけ読める

• assigned_to、managed_by、owned_by、reserved_for

• supported_by、attested_by、audited_by、sn_itam_common_audited_by

公式の説明は Reserved for・Managed by・Owned by を例に挙げていますが、ACL のスクリプトでは8項目が対象です。

テスト利用者の比較

テスト利用者を3人作り、なりすまして alm_hardware（alm_asset の子テーブル）を読みました。資産のテストデータは4件で、本人に割当・本人に予約・他人に割当・担当者なしの4種類を用意しました。

利用者のロールは次の3パターンです。

• ロールなし

• snc_internal のみ

• snc_internal と asset ロールほか複数

プロパティを true から false に切り替えて、見える件数を比べました。

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

• ロールなし：true は0件、false は4件すべて

• snc_internal のみ：true は2件（本人に割当・本人に予約）、false は4件すべて

• asset ロールなど複数ロール：どちらの値でも4件すべて

true のときの結果は、ACL のスクリプトどおりでした。他人に割り当てた資産と担当者のいない資産は、snc_internal のみの利用者には見えません。false に切り替えると、ロールなしの利用者にも全件が見えます。検証後は、プロパティを元の true に戻して確認しています。

担当者項目ごとの確認

5項目すべてで、本人を担当者にした資産が読めました。ACL のスクリプトが照合する8項目のうち、実機で試せる項目を1つずつ確かめました。snc_internal のみのテスト利用者を作り、alm_hardware の資産を5件用意しています。各資産で本人にした項目は1つだけで、対象は次の5項目です。

• assigned_to

• managed_by

• owned_by

• reserved_for

• supported_by

結果は次のとおりです。

親テーブル alm_asset を、なりすました本人として検索しています。

• assigned_to を本人にした資産：読める

• managed_by を本人にした資産：読める

• owned_by を本人にした資産：読める

• reserved_for を本人にした資産：読める

• supported_by を本人にした資産：読める

残る attested_by、audited_by、sn_itam_common_audited_by の3項目は、alm_hardware に項目がありません。ACL のスクリプトは項目の有無を確かめてから照合するため、項目がないテーブルでは何も起きません。この3項目は、ライセンスなど別の子テーブルが持つ可能性があります。alm_license では assigned_to だけを試しました。

子テーブルの確認

プロパティの説明は「Asset テーブルと子テーブル」を対象にしています。alm_license に、本人を assigned_to にした資産と、担当者のいない資産を1件ずつ作って確かめました。

• 本人を assigned_to にしたライセンス：alm_asset 経由でも alm_license 直接でも読める

• 担当者のいないライセンス：どちらでも読めない

alm_hardware と alm_license で結果が同じだったため、子テーブルごとに別の設定を入れなくても、親テーブルの1つの ACL で制御できる構成です。他の子テーブル（alm_consumable など）は試していません。

運用方針の決め方

資産を全社に見せる運用かどうかを先に決めます。アップグレード後の確認は、次の順で進めます。

1. プロパティの値を確認する。この PDI は true で、公式の既定値とは異なる

2. 一般社員に資産を全件見せている運用があるか洗い出す。true のままだと、その利用者には本人関連の資産しか見えなくなる

3. 全社で資産を検索させる運用が必要なら、特定のロールを付与するか、プロパティを false にするかを決める。false にすると、ロールなしの利用者にも全件が見える

4. 資産の担当者項目（assigned_to など）が空の資産は、一般社員には見えない前提で運用を組む

セルフサービスで自分の資産だけ見せたい環境では、true のままが適しています。資産を探す問い合わせを全社員から受ける環境では、ロールを付与するほうが細かく制御できます。プロパティは全体のスイッチなので、false にすると一部の利用者だけに絞ることはできません。

実機を見て気づいたこと

既定値の食い違い

公式ドキュメントは2か所で既定値を false と書いています。実機では、プロパティの値も ACL のスクリプトの既定値も true です。公式のとおり false を前提に確認すると、アップグレード後に一般社員から「資産が見えなくなった」という問い合わせが来るおそれがあります。先に確認するのは公式の記述ではなく、自分の環境の値です。

ロールなしの利用者も対象になる

公式は「snc_internal のみ」と書いていますが、ACL のスクリプトはロールが0件の利用者も同じ扱いにします。実機でもロールなしの利用者は true のとき0件でした。スクリプト上は snc_external のみの利用者も同じ扱いですが、実機では未検証です。snc_internal は暗黙のロールで、getRoles() では列挙されません。ロールなしと snc_internal のみは、実質同じ扱いです。

ACL は項目の有無を確かめてから照合する

8項目のうち3項目は alm_hardware に存在しません。ACL のスクリプトは、項目が有効かを確認してから値を比べています。項目がない子テーブルでもエラーにならず、残りの項目だけで判定が進みます。自社の子テーブルに項目を足す場合の動きは、今回は試していません。

担当者のいない資産

担当者を持たない資産は、true のとき snc_internal のみの利用者に見えません。在庫の機器は assigned_to が空の場合があり、一般社員に在庫を探させる運用では問い合わせの原因になります。在庫を探す担当者には、snc_internal 以外のロールを付けておくと、全件が見えます。

影響を受けるのは読み取りの ACL

プロパティが参照するのは alm_asset の読み取りの ACL だけです。書き込みや作成の ACL は今回調べていません。

効く範囲

ここまでの結果を、判断に使える形でまとめます。

• 効く対象：ロールがない、または snc_internal のみの利用者（スクリプト上は snc_external のみの利用者も対象。実機では未検証）

• 効かない対象：他のロールを1つでも持つ利用者（実機では asset ロールほか複数ロールで全件を確認）

• 効く場所：alm_asset の読み取り ACL（alm_hardware と alm_license で確認）

• 絞り込みの条件：assigned_to、managed_by、owned_by、reserved_for、supported_by に本人が入っていること（実機で5項目を確認）

• 切り替え：プロパティの値だけ。値を変えても ACL 自体の編集は要らない

• 変更できるロール：プロパティの読み書きは asset_system_admin ロール

ロールを付けるか、プロパティを切り替えるかで迷うときは、見せたい相手の範囲で選びます。全社員に全件を見せたいなら false、特定の担当者にだけ全件を見せたいなら true のままでロールを付与します。

最後に、判定を行う ACL の画面を確認します。

①の説明には、プロパティ名と、既定値が true であることが書かれています。公式ドキュメントより、ACL の説明のほうが実機の動きに合っています。

アップグレード後の確認

Brazil 欄の HAM リリースノートには、プロパティの説明に加えて、ACL に関する次の注意が載っています。

（訳：Brazil へのアップグレード後は、カスタマイズまたは削除した ACL のロールを見直し、想定したアクセス設定になっているか確認する。）

引用元：Combined Hardware Asset Management release notes for upgrades from Australia to Brazil

この注意は、今回の alm_asset の読み取り ACL にも当てはまります。この ACL は Application が Global で、保護ポリシーは None です。自社で ACL のロール行を足したり削ったりしている環境では、アップグレードで ACL がどう更新されたかを確認します。

確認のポイントは次の3点です。

• alm_asset の読み取り ACL に、自社で追加した条件がないか

• 一般社員向けに付けたカスタムロールが、資産の閲覧を前提にしていないか

• 資産を参照するレポートやダッシュボードが、一般社員の画面で空になっていないか

3点目は今回の検証で確かめていません。ACL は一覧や検索で効いているため、一般社員の画面に出る件数が管理者と食い違う可能性があります。

自分の環境で切り分けるときの手順

一般社員から「資産が見えない」と言われたときは、次の順で確認します。操作はすべて読み取りだけで済みます。

1. プロパティの値を開く（/sys_properties_list.do?sysparm_query=name=sn_itam_restrict_asset_read）

2. 該当の利用者のロールを開き、snc_internal 以外のロールがあるかを確認する

3. 見えない資産を開き、assigned_to など8項目に利用者が入っているかを確認する

4. それでも原因が分からないときは、ACL のデバッグ機能で判定の経過を追う

ACL のデバッグ機能は、次のページに説明があります。

• ACL debugging tools

プロパティを false に切り替えれば原因の切り分けにはなりますが、全利用者に全件が見えるようになります。本番では切り替えず、検証用のインスタンスか、テスト利用者のなりすましで確認します。

用語

• snc_internal：ServiceNow の内部利用者全員に暗黙で付くベースのロール

• ACL：テーブルや項目へのアクセスを制御する規則

• alm_asset：資産の親テーブル。ハードウェア（alm_hardware）やライセンス（alm_license）などの子テーブルを持つ

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

• プロパティ：/sys_properties_list.do?sysparm_query=name=sn_itam_restrict_asset_read

• ACL：/sys_security_acl_list.do?sysparm_query=name=alm_asset^operation=read

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

• Combined Hardware Asset Management release notes for upgrades from Australia to Brazil

• Asset and CI management

• Explicit Roles

• Allow ACL

検証範囲とおことわり

• アップグレード前の Australia の状態は、この PDI で比べていない

• 子テーブルは alm_hardware と alm_license で確認した。alm_consumable など他の子テーブルは確認していない

• 件数の検証は、テストデータ4件を含む alm_hardware で行った。attested_by、audited_by、sn_itam_common_audited_by の3項目は alm_hardware に無いため、実機で照合を試していない

• snc_external のみの利用者は試していない（ACL のスクリプト上は対象になっているが、実機での動きは未確認）

• Service Portal や REST API 経由の確認は含まない

• 検証用のユーザーと資産はすべて削除し、残りが0件であることを確認した。プロパティは元の true に戻している