ServiceNowのACLとロールの違い｜PDIでDB保存先と評価条件を確認

ServiceNowのRole（ロール）とACL（Access Control List）は、どちらも権限に関係しますが役割は同じではありません。ロールは「利用者が持つ権限ラベル」、ACLは「どのオブジェクトに対する、どの操作を、どの条件で許可するかを判定するルール」です。したがって、ロールを作成しただけではIncidentの書き込み権限は発生しません。そのロールをACLのRequires roleなどへ結び付け、さらに対象・操作・条件・スクリプトを通過して初めてアクセス判定に使われます。

ACLとRoleの違いを先に整理

ServiceNow公式ドキュメントでも、RoleレコードはRole [sys_user_role] に保存されると説明されています。一方ACLは、Decision type、Rule type、Operation、保護対象、Requires role、Condition、Scriptなどから構成されます。同じACLに複数の条件がある場合、アクセスを得るには必要条件をすべて満たす必要があります。

PDI検証1：Roleを作るとDBのどこへ保存されるか

今回は既存の利用者権限へ影響を与えないよう、検証専用Role x_codex_evidence.reader を作りました。説明には「記事検証用。ACLとRoleの保存関係を確認するための権限ラベル。利用者には割り当てない。」と入力しています。Role名はスコープを含む一意で説明的な名前にし、検証用であることを明確にしました。

入力手順

1. AllメニューでUser Administration > Rolesを開きます。
2. Newを選び、NameとDescriptionを入力します。
3. Contains Rolesは、継承させる必然性がある場合だけ追加します。
4. Submitを押す前に、既存Roleと名前が衝突していないか確認します。

Submit後、Roles一覧で同じ名前を検索すると1レコードが表示されました。これはRole定義が sys_user_role に保存された証拠です。この時点ではユーザーにもグループにも割り当てていないため、実利用者の権限は増えていません。

PDI検証2：Incident write ACLの実レコードを読む

ACLは新規作成せず、PDIに存在するIncidentのwrite ACLを読み取りました。権限制御を試すために本番相当の既存ACLを直接変更すると、管理者自身を含む利用者が画面やAPIへアクセスできなくなる危険があります。検証ではまず一覧を絞り込み、対象のOperationとNameを確認するのが安全です。

対象として開いたACLは、Typeがrecord、Nameがincident、Operationがwriteです。Descriptionには sn_incident_write RoleとIncident stateに関する条件が記載され、Requires role関連リストにも同Roleが表示されています。これにより「Role名がある」だけではなく、ACLの一条件としてRoleが参照されていることが分かります。

DBで見るACLとRoleの結び付き

ACL本体とRole本体は別テーブルです。Requires roleの関連は、中間テーブル sys_security_acl_role に保存されます。PDIでは対象ACLで絞った一覧を開き、ACL列にincident、Role列にsn_incident_writeが入っているレコードを確認しました。

この構造を理解すると、「Roleを付与したのに編集できない」「ACLからRoleを外したのに別ACLで許可される」といった調査がしやすくなります。少なくとも次の3点を分けて確認します。

1. ユーザーがRoleを直接または継承で持つか
2. 要求したテーブル・フィールド・操作に一致するACLは何か
3. 一致ACLのRequires role、Condition、Scriptがどう評価されたか

ACL設計のベストプラクティス

1. Roleは個人名ではなく職務で設計する

tanaka_editのような個人依存名ではなく、業務責任が伝わるRoleを設計します。ユーザーへ個別に大量付与するより、原則としてグループへRoleを付け、異動・退職時の管理を簡単にします。Role継承は強力ですが、意図しない権限拡大を防ぐためContains Rolesを定期確認します。

2. ACLは最小権限から始める

テーブル全体のwriteを広く許可してからScriptで例外を増やすより、必要なRole・状態・担当関係を明確にします。フィールド単位の保護が必要なら、テーブルACLだけでなくフィールドACLも確認します。ServiceNowではテーブルへのアクセスとフィールドへのアクセスの両方が関係するため、片方だけ見て判断しません。

3. Conditionで書けるものを先にConditionへ置く

状態、担当グループ、Activeなど条件ビルダーで表現できる判定は、まずData Conditionで表します。Scriptは複雑な関係判定など、本当に必要な場合に限定します。条件が多いACLはDescriptionへ目的と前提を残し、後任が画面だけで意図を追えるようにします。

4. adminだけでテストしない

管理者はAdmin overridesなどにより一般利用者と異なる結果になることがあります。security_adminを必要な時間だけElevateし、設定後は一般RoleのテストユーザーやImpersonate、Access Analyzer、Debug Security Rulesを使って確認します。許可ケースだけでなく、Roleなし・条件不一致・フィールドACL不一致の拒否ケースも試します。

5. 既存ACLを直接変更する前に影響範囲を調べる

IncidentはTaskを継承しているため、親テーブルやワイルドカードACLも評価対象になり得ます。Nameがincidentだけの一覧では不十分です。継承元、*、*.*、対象フィールドのACLまで追い、Update Setとレビュー手順を通します。

よくある誤解と切り分け

Roleを持っているのに編集できない

Requires roleを通ってもConditionまたはScriptがfalse、テーブルACLは通ってもフィールドACLがfalse、別のDeny-Unlessに一致、などを確認します。

Roleを持っていないのに編集できる

同じ評価位置に別のAllow-If ACLがないか、Role継承、グループ付与、admin overrideを確認します。

フォームで非表示だから安全

UI PolicyやClient Scriptは表示制御であり、APIやリストからのアクセス保護にはなりません。機密フィールドはACLで保護します。

権限変更を安全に検証するチェックリスト

ACLは「保存できた」だけでは品質を判断できません。許可すべき利用者と拒否すべき利用者をあらかじめ表にし、操作ごとに期待結果を固定します。たとえばIncidentのwriteなら、Roleあり・条件一致、Roleあり・条件不一致、Roleなし・条件一致、管理者、継承Roleの5ケースを用意します。さらに同じレコードをフォーム、リスト編集、REST APIから扱い、UIだけの制御へ依存していないかを確認します。

1. 変更前に対象ACL、親テーブルACL、フィールドACLを一覧化する
2. 許可ケースと拒否ケースのテストユーザーを分ける
3. ImpersonateまたはAccess Analyzerで継承Roleを確認する
4. Debug Security Rulesで実際に一致したACLと通過・失敗条件を記録する
5. フォーム表示、リスト、APIの少なくとも3経路を試す
6. Update Setへ入った構成レコードとレビュー担当者を確認する
7. 問題が起きた場合に元へ戻せるよう、変更前値と復旧手順を残す

とくに、adminで成功した結果だけを証拠にしないことが重要です。管理者はRoleチェックやAdmin overridesによって一般利用者と異なるため、「管理者で見えた」は一般利用者の許可証明になりません。拒否結果も含めたテスト記録が、最小権限を維持する実務上の証拠になります。

CSA理解確認問題

問題：Incidentのwrite ACLにRequires role、Condition、Scriptが設定されています。利用者がRequires roleだけを持つ場合、正しい説明はどれですか。

1. Roleを持てば、ConditionとScriptの結果に関係なく書き込める
2. RoleはACLを削除し、テーブルへ直接権限を保存する
3. 一致するACLで必要なRole・Condition・Scriptなどを満たしたときにアクセスが許可される
4. Roleはフォーム項目を非表示にするだけで、ACL評価には使われない

まとめ

Roleは権限を束ねるラベル、ACLはアクセス要求を判定するルールです。PDIではRoleがsys_user_role、ACLがsys_security_acl、その関連がsys_security_acl_roleへ保存されることを確認できました。権限トラブルでは画面名だけで判断せず、ユーザーの継承Role、ACL本体、中間テーブル、条件、スクリプトまで分けて追うことが重要です。

CSA学習ガイドへ戻る ／ Client ScriptとBusiness Ruleの違いを確認する ／ CSA練習問題へ進む

公式資料

• ServiceNow Docs: Explore Access Control Lists
• ServiceNow Docs: Configure an ACL
• ServiceNow Docs: Exploring user administration