ServiceNow Zurich ロール設計のアンチパターン7選 ありがちな失敗と安全な直し方

Zurichでロール設計が難しくなった理由

ServiceNowの権限設計は、ざっくり言うと「ロールで大枠を決め、ACLで最終的に絞る」という考え方です。ところが実務では、ロールが増えた瞬間に破綻しがちです。しかもZurich以降は、セキュリティやガバナンスの考え方が強まり、昔ながらの“雑にadmin配る”文化が通りにくくなっています。

ここでまず押さえたいのは、ロールが「便利な許可証」ではなく、インスタンスがユーザーを区別し、機能やデータへのアクセスを統制するための土台だという点です。ServiceNowの公式ドキュメントでも、ロールはプラットフォームのセキュリティを成り立たせる基本として説明されています。

さらにZurich周りの流れで見落としやすいのが、次の2つです。

internal external を分ける明示的ロール

ServiceNowには、内部ユーザー向けの snc_internal と、外部ユーザー向けの snc_external という「明示的ロール」があります。どちらも持たないユーザーは、基本的に公開リソースしか触れません。
つまり、最初の一歩から「誰を内側に入れるか」を設計しているイメージです。

特権ロールは昇格して使うという発想

セキュリティ系の重要ロールは「常時ON」ではなく、必要なときに責任を明示して使う、という方向に寄っています。公式ドキュメントでも、特権ロールは手動で昇格して初めて機能にアクセスできる、と整理されています。
また、高セキュリティ設定の説明では security_admin は admin から継承されず明示的に付与が必要である点も明記されています。ここを知らずに「adminなら全部できるはず」と思い込むと、ロール設計だけでなく運用も崩れます。

この前提を踏まえた上で、Zurichで起きやすいロール設計のアンチパターンを整理します。

---

アンチパターン7選：ありがちな失敗と、どこが危ないか

ここでは「あるある」だけど放置すると痛いパターンを7つに絞ります。CSA学習者の目線でも、ロール・グループ・ACL・昇格の関係が混線しやすいところなので、具体例でイメージを固めます。

何でも admin に寄せる

症状：少し詰まるたびに「admin付ければ解決」で前に進む。
なぜ起きる：検証環境で早く動かしたい、期限が近い、担当が少ない。
まずい理由：最小権限の思想が消え、どこで何ができているのか説明できなくなります。さらにZurichの文脈では、管理者権限の扱い方自体がより厳密になっていく流れがあります（adminでも“何でもスクリプトOK”ではなくなった、などの話題が出やすい）。

ありがちな実例

• カタログアイテムの調整が必要 → 申請担当に admin を付与
• フローが動かない → とりあえず admin で実行して「動いたからOK」扱い

安全な直し方の方向性
「その作業に必要な機能の範囲」を言語化し、機能ロールへ分解していきます。adminは最終手段に寄せます。

---

ユーザーにロールを直付けし続ける

症状：ユーザーレコードに role を直接追加していく。
まずい理由：異動・兼務・退職で追跡不能になります。誰が何を根拠に付けたのかが残りません。

公式ドキュメントでは、グループにロールを割り当てる手順が明確に用意されています。つまり、運用の基本は「グループを介した付与」が前提になっています。
コミュニティ側でも、ロール→グループ→ユーザーの順に組むのが一般的な運用として語られています。

安全な直し方の方向性
ユーザー直付けは例外に寄せ、原則は「職務グループ」に寄せます。例外が出るなら、例外ルールと期限を決めます。

---

グループ設計が組織図のコピーになっている

症状：「営業一課」「営業二課」など、組織改編のたびに権限が壊れる。
まずい理由：組織と権限は似ているようでズレます。権限は“やること”に紐づけた方が長持ちします。

安全な直し方の方向性

• 組織グループ：承認経路や通知先など“人のまとまり”
• 職務グループ：権限付与の単位
  この2つを混ぜない。名前も分ける。これだけで整理が進みます。

---

ロール継承がスパゲッティ化している

症状：「Contains」が増えすぎて、ロールの境界が説明できない。
まずい理由：1つ追加したつもりが、意図せず権限が広がります。調査も地獄になります。

ロール継承を可視化する仕組みとして、公式ドキュメント上で Role Inheritance Map が説明されています。継承カウントの見え方や、可視化の位置づけが明記されています。
つまり、継承は使っていいけれど「見える化して管理する」ことが前提です。

安全な直し方の方向性

• 継承は2段までを目安にし、深掘りしすぎない
• 共通ロールは“土台ロール”として固定し、用途別ロールは積み上げる
• Role Inheritance Mapで、変更前後の差分を必ず確認する

---

1ロールに複数職務の権限を詰め込む

症状：「担当者ロール」1個に、閲覧・登録・承認・設定変更まで全部入っている。
まずい理由：兼務が出た瞬間に詰みます。最小権限に戻せなくなります。

安全な直し方の方向性
ロールを「動詞」で分けます。
例：閲覧 view、起票 create、更新 write、承認 approve、設定 admin など。
機能ロールを組み合わせて職務を作る、という順番にします。

---

ACLの代わりにロールだけで守ろうとする

症状：「このテーブルはこのロール持ちだけ」と大雑把にロールで制御し、フィールド単位の想定がない。
まずい理由：同じテーブルでも、見せたいフィールドと隠したいフィールドが出てきます。ロールだけで完結させると、どこかで無理が出ます。

公式ドキュメントでも、ACLはテーブルやフィールドに対して評価され、条件を満たす必要がある、という基本が整理されています。

安全な直し方の方向性

• ロール：アプリや機能への入場券
• ACL：データの最終ゲート
  この役割分担を守る。ロールで広げすぎたらACLが複雑になり、ACLだけで守ろうとすると運用が破綻します。バランスが重要です。

---

特権ロールの扱いが雑で、昇格運用がない

症状：security_admin相当の強い権限を常時付けっぱなし、または「誰が持ってるか不明」。
まずい理由：設定変更の監査が効きにくくなります。さらに、security_adminはadminから継承されない設計であることが公式に明記されています。ここを理解せずに運用すると、権限の説明責任が崩れます。
昇格の厳格化を制御するプロパティも用意されており、特権の扱いは“運用込み”で考える流れです。

安全な直し方の方向性

• 特権ロールは最小人数
• 付与は期限付き
• 普段は通常ロールで作業し、必要時だけ昇格
• 昇格手順とログ確認をセットにする

---

安全なロール設計の基本形

アンチパターンを避けるための「型」を作ります。ポイントは、設計の順番を固定することです。

最小権限を言葉にしてから、ロールに落とす

最小権限は精神論になりがちですが、設計では手順に落とせます。

• その職務は「どのアプリ」「どの操作」「どのデータ範囲」が必要か
• 操作は閲覧・作成・更新・承認・設定のどれか
• 例外はあるか、あるなら期限はいつまでか

この整理ができると、ロールを「便利セット」にせずに済みます。

ロールはグループに付与し、ユーザーはグループに所属させる

グループへのロール割り当ては、公式手順として定義されています。
運用上も、異動や入退社に強くなります。ユーザー直付けが残ると、監査・棚卸しで必ず詰まります。

おすすめの分け方はこれです。

• 職務グループ：権限付与の単位
• 組織グループ：承認や通知の単位
• 作業グループ：担当割当の単位

全部を1つのグループでやろうとすると、どこかで破綻します。

ロール継承は使うが、見える化と制限をセットにする

ロール継承は強力ですが、増えると事故の原因にもなります。公式ドキュメントでRole Inheritance Mapが説明されているのは、まさに「見えないと危ない」からです。

運用ルールの例

• 継承の目的をロール説明欄に書く
• 継承の深さは原則2段まで
• 変更時はRole Inheritance Mapで影響範囲を確認してから反映

Role Managementの考え方で、重複と属人化を減らす

Zurichのプラットフォームセキュリティ領域では、Role Managementの文脈も整備されています。たとえば、Role Management V2のドキュメントでは、ロール継承の可視化などが前提として扱われています。
「ロールを増やす前に、既存のロールの組み合わせで表現できないか」を確認する癖がつくと、将来の棚卸しが一気に楽になります。

---

運用で崩さないチェックリスト

設計が正しくても、運用が崩れると一瞬でアンチパターンに戻ります。ここでは、最小限の運用ルールをチェックリスト化します。

付与フローを固定する

• 申請理由：何の作業で必要か
• 期限：いつまで必要か
• 承認者：データオーナーか運用責任者
• 付与単位：ユーザー直付けではなく職務グループ

「急ぎだから直付け」は、緊急対応のテンプレを別に作って例外扱いにします。例外が常態化すると、必ず事故に繋がります。

変更前に見るべき観点

• そのロールが含むロールは何か
• そのロールを持つユーザーは誰か
• ACLの想定と矛盾しないか
• 特権ロールに寄っていないか

特権の扱いは特に重要です。昇格や高セキュリティ設定の考え方は公式にも整理があり、運用を曖昧にしない方が安全です。

Security Centerを「点検の場所」として使う

ZurichではSecurity Centerが強化され、セキュリティ課題をタスクとして扱うなど、運用に寄せた改善が紹介されています。
ここを“たまに見る画面”ではなく、棚卸しや監査の入口として使うと、属人化が減ります。

棚卸しは小さく頻繁に

• 四半期に一度：特権ロールの保有者一覧と妥当性確認
• 月に一度：期限付きロールの期限切れ回収
• 変更のたび：Role Inheritance Mapで影響範囲確認

大掃除型の棚卸しは、忙しい現場ほど失敗します。小さく回すのが現実的です。

---

CSA学習に落とし込む理解ポイントと学び方

CSAの学習では、暗記よりも「仕組みのつながり」を理解しているかどうかで迷いが減ります。ロール設計の話は、そのまま基礎理解の土台になります。

ロール グループ ACL 昇格を一枚で整理する

自分の中で、次の対応関係がスッと出てくる状態を目指すと学習が楽になります。

• ロール：機能やアプリへのアクセス単位
• グループ：付与を管理する単位
• ACL：データの最終ゲート
• 昇格：特権を必要なときだけ有効化する考え方

問題文で「このユーザーができないのはなぜ？」となったときに、ロール不足なのか、グループ付与の設計なのか、ACLなのか、特権昇格なのかを切り分けやすくなります。

ひっかかりやすい読み違いを減らす

• 「adminなら何でもできるはず」という思い込みを捨てる
• security_adminの扱いは別物として理解する
• ロールで守る話とACLで守る話を混ぜない

このあたりは、理解が浅いと混乱しやすい前提として扱われがちです。丸暗記より、図にして整理した方が強いです。

体系的に学べる教材の一例としてUdemy講座を活用する

ロール設計は、断片知識だけだと「現場の例外」で崩れます。
そこで、CSA学習の段階では ユーザー管理・ロール・グループ・ACL・昇格をひとつの流れで説明してくれる講座を1本持っておくと、理解が安定します。

Udemyには、ServiceNowの基礎から権限周りまでを体系立てて扱う講座が複数あります。テキストだけで繋がりが作りにくい人は、動画で「なぜそう設計するのか」を掴んでから公式ドキュメントに戻る学び方が相性いいはずです。
あくまで教材の一例ですが、学習の寄り道を減らす道具として検討してみてください。

---

まとめ

Zurichのロール設計で事故が増えやすいのは、セキュリティ強化の流れの中で「雑な権限付与」が以前より通りにくくなっているからです。明示的ロールで内部外部を分け、特権は昇格して使うという前提を押さえるだけでも、設計のブレが減ります。

ロール設計のアンチパターンは、だいたい「付与の仕方」「ロールの作り方」「運用」のどれかで起きます。admin寄せ、ユーザー直付け、組織図コピー、継承のスパゲッティ化、詰め込みロール、ACL不在の防御、特権運用の雑さ。この7つを避けるだけで、権限トラブルの多くは手前で止められます。

そしてCSA学習者にとっては、ロール・グループ・ACL・昇格の関係を一本の線で理解しておくことが、問題文の切り分けを速くします。暗記で押し切るより、仕組みの整理に時間を使った方が後々効きます。公式ドキュメントと、体系的に学べる教材の一例としてUdemy講座をうまく併用しながら、崩れない権限設計の型を作っていきましょう。