はじめに：Zurichで「権限トラブル」が表面化しやすい理由
Zurichに上げたあと、「昨日までできていたのに、急に見えない／編集できない」「管理者なのに触れない設定がある」といった相談が増えがちです。理由は単純に“厳しくなった”というより、アクセス制御の境界がはっきり見えるようになったからです。
ServiceNowの権限はざっくり言うと、次の層が重なって決まります。
- 役割（ロール）やグループで“できる範囲”が決まる
- ACL（Access Control）で、テーブル／レコード／フィールド／スクリプトなどへのアクセスが評価される
- 機能によっては「ユーザー条件（User Criteria）」のように、ACLとは別の仕組みで見せ分ける
- さらに、管理者向けの高権限操作は“昇格（elevated privilege）”が絡むことがある
たとえば、昇格ロールはログイン直後に有効にならず、手動で昇格して初めて権限が効く、という前提を知らないと「ロールがあるのに操作できない」に直結します。昇格ロールはセッション中だけ有効で、ログアウトやタイムアウトで外れます。
この記事は、暗記で乗り切る系ではなく、“どこで落ちているか”を論理的に切り分けるための事例集です。CSA学習の文脈でも、アクセス制御は前提として扱われやすく、理解が浅いと設定問題やシナリオ問題で混乱しやすい分野です。
本番形式で慣れるのが合格への近道。UdemyのServiceNow模擬問題集を人気順で一覧比較できます👇
権限トラブル事例集：まず疑うべき“前提”のズレ（ロール・グループ・セッション）
事例：ロールは付与したのに、画面が変わらない
ありがちな原因
- ロール付与は正しいが、セッションに反映されていない
- 付与したのが「ユーザー」ではなく「グループ」側で、反映タイミングにズレがある
- そもそも“見る権限”ではなく“見せる条件”が別にある（後述のユーザー条件など）
対処
- まずログアウト／ログインで切り分ける
- 機能側の設定（ユーザー条件など）を疑う
ナレッジのユーザー条件では、変更後にログアウト／ログインが必要になる場合がある、と公式ドキュメントでも注意されています。
事例：管理者なのにACL一覧が見えない／編集できない
ありがちな原因
- Zurichでは、高セキュリティ領域の操作に“昇格ロール”が絡むケースがある
- 代表例が security_admin。これはベースシステムで特別扱いの昇格ロールで、ACLやHigh Security Settingsに関わります。
対処
- “管理者＝何でもできる”と思い込まない
- 触れないものがあるときは、まず「昇格が必要な領域か」を確認する
- そして、昇格が必要なら「今のセッションで昇格しているか」を確認する
事例：偽装（Impersonate）したら再現できない／挙動が違う
ありがちな原因
- 偽装は便利ですが、偽装者側の権限や制限が残る場合があります。特に、偽装対象がadminロールの場合など、偽装だけで完全再現できないことがある、と公式に明記されています。
対処
- “偽装で再現できない”＝相手の環境が違う、とは限らない
- 重要な権限トラブルは、偽装＋デバッグ出力（後述）で「どの判定で落ちたか」を見る
権限トラブル事例集：ACLの典型パターン（テーブル・フィールド・評価順・重複）
ここからが本題です。権限トラブルの多くはACLに行き着きます。ただし、ACLは「設定を当てたつもり」でも、評価順・重複・テーブルとフィールドの関係でズレやすい。
事例：カスタムテーブルが見えない（“作ったのに誰もアクセスできない”）
原因の定番
- カスタムテーブルには、明示的なテーブルACLがないと、ワイルドカード（*）側のテーブルACLに依存する
- そのワイルドカードがデフォルトで管理者のみ、のような状態だと、一般ユーザーは全滅します
公式のACLトラブルシューティングでも、カスタムテーブルにアクセスできない場合はテーブルACLを作成し、デバッグで評価されたACLを確認すると案内されています。
対処のコツ
- 「read のテーブルACL」→「レコードACL」→「フィールドACL」の順に、まず入口（テーブル）から疑う
- 何を評価しているかはデバッグで可視化する（後述）
事例：フィールドACLを作ったのに効かない
ありがちな原因
- フィールドACLの前に、テーブルACLで落ちている
- あるいは、同じ対象に重複したACLがあり、上位の評価で意図しない判定になっている
公式でも、フィールドACLが効かないときは「テーブルACLが満たせていない可能性」「重複や競合の可能性」を挙げ、デバッグで評価ACLを追うよう示しています。
対処のコツ
- 「フィールドだけ見て頑張る」のをやめる
- まずテーブルreadが通っているか、次に対象フィールドのread/writeがどのルールで落ちているか、を順番に確認する
事例：リストでは見えるのに、フォームでは見えない
これ、現場でかなりあります。
公式でも「リストで見えるがフォームで見えない」症状として、条件やスクリプトがリストとフォームで異なるタイミング・コンテキストで動いている可能性を挙げています。
対処のコツ
- “UIの違い”ではなく“評価のされ方の違い”として捉える
- デバッグ出力で、リスト表示時／フォーム表示時に、どのACLがtrue/falseになったかを比較する
事例：作ったACLが効かない（別ルールに負けている）
原因の定番
- ACLには処理順があり、別ルールが先に評価されている
- あるいは同種のACLが存在して、結果が上書きされている
公式は「別ルールが優先している可能性」「ユーザーが要件を満たしていない可能性」を示し、デバッグで“評価されているか”を確認せよ、としています。
権限トラブル事例集：アプリ機能側の制御（ナレッジのユーザー条件、偽装、診断）
事例：ナレッジはロールがあるのに見えない
ナレッジは、ACLだけでなく**ユーザー条件（User Criteria）**が強く効きます。公式ドキュメントでも、ナレッジのアクセスはユーザー条件で決まる旨が明記されています。
さらに、ユーザー条件を変更した後は、ログアウト／ログインが必要になる場合がある、と注意もあります。
対処のコツ
- ナレッジが見えないときは、ACLより先に「対象ナレッジベースのユーザー条件」を確認する
- ユーザー条件の診断機能で、誰に見える設定になっているかを検証する（公式が案内）
事例：偽装してACLを調べたいのに、ACL関連テーブルが読めず詰む
ACLデバッグは強力ですが、偽装時はACL関連データの読み取りが絡みます。公式のACLデバッグ説明では、偽装中にACL関連テーブルを読めるようにするシステムプロパティ（glide.security.access_acl_as_impersonator）を説明し、falseの場合は「別セッションでadmin/security_adminが必要になる」可能性にも触れています。
対処のコツ
- 偽装で調査する場合、「偽装者に見せて良い情報が増える」リスクもあるので、運用ポリシーとセットで扱う
- 詰まったら、管理者セッションと調査セッションを分ける、という発想を持つ（公式も示唆）
失敗しない切り分け手順：デバッグで“どこで落ちたか”を特定する
ここまでの事例を最短で解くために、現場で効く「確認順」をテンプレ化します。ポイントは、推測で直さず、評価結果を見て直すことです。
手順：まず“何が評価されたか”を出す
ACLのデバッグは、公式でも「System Security > Debug Security Rules で有効化できる」とされ、出力には次が含まれます。
- どのACL（type/name/operation）が評価されたか
- 役割チェック、条件チェック、スクリプトチェックがどう判定されたか
- true/false（RC）や処理時間など
そして重要なのが、ACL評価の前段に iAccessHandler のような内部チェックが入り、ACL評価そのものがスキップされることがある、という点です（これは設定で変更できない領域）。
「ACLを直してるのに変わらない」とき、実はここで落ちている、というケースがあります。
手順：症状別の“最短ルート”
- カスタムテーブルが見えない
→ まずテーブルread ACL。なければ作る。ワイルドカード依存を疑う。 - フィールドだけ効かない
→ テーブルACLを先に確認。重複／競合も疑う。 - リストとフォームで違う
→ デバッグを両方の画面で見て、条件やスクリプトの差分を探す。 - 管理者なのに触れない
→ 昇格ロールの前提を確認。セッションで昇格しているか。 - ナレッジだけ見えない
→ ユーザー条件（User Criteria）を最優先で確認。必要ならログインし直し。
仕上げ：再発防止の観点（運用で効く）
Zurichの文脈だと、権限ミスは「設定の漏れ」だけでなく、「運用の見落とし」で増えます。たとえば公式のセキュリティベストプラクティスでは、ServiceNow Security Center でハードニング設定やスキャナ結果を監視し、組織要件に沿って優先順位を付けることが推奨されています。
権限トラブルが続く組織ほど、「現場で起きた権限事故」を設定に反映していくループが弱い印象があります。
本番形式で慣れるのが合格への近道。UdemyのServiceNow模擬問題集を人気順で一覧比較できます👇
まとめ：試験対策としての学び方（暗記ではなく仕組みで理解）
Zurichでの権限トラブルは、「ACLを覚える」よりも “評価のされ方”を理解するほうが効きます。ポイントは次の3つです。
- 権限はロールだけで決まらない。昇格やセッションの前提でズレることがある。
- ACLはテーブル→フィールドの関係、評価順、重複でハマる。困ったらデバッグで“評価されたACL”を追う。
- 機能によってはユーザー条件が主役（例：ナレッジ）。ACL一本で考えると迷子になる。
CSAを目指す学習でも、アクセス制御は「前提として理解しているもの」として登場しやすい分野です。暗記ではなく、この記事で紹介したように、症状→疑う層→デバッグで確証の順で整理できると、設定問題やシナリオの読み解きが一気にラクになります。
最後に、学習を加速させる方法としては、公式ドキュメントで概念を押さえた上で、演習で“わざと詰まって、デバッグで解く”経験を積むのが近道です。体系的に演習まで含めて学べる教材の一例として、UdemyのServiceNow CSA向け講座や、ACL／セキュリティ周りを扱うハンズオン講座を1本選び、手元の開発環境で「リストでは見えるのにフォームで見えない」などの事例を再現してみると、理解が定着しやすくなります。
