ServiceNow 2026 Australia版 Granular Admin Rolesのメモ

Posted at 2026-03-30

はじめに
背景: なぜ Granular Admin Roles が必要なのか
新設された5つの ITSM 管理者ロール
ITIL ロール継承の変更（大きな変更あり）
既存の細粒度ロールとの全体像
設定・構成手順
移行ガイド: 9ステップで進める権限最小化
ユースケース・活用シナリオ
セキュリティ・コンプライアンス対応
注意事項・Known Issues
今後の展望
まとめ
用語集
参考リンク

はじめに

この記事の作成方法

この記事は生成AIによって作成されています。ServiceNowのAustraliaバージョンのリリースノートで報告された「Granular Admin Roles」について、複数のDeep Researchを行いその内容を取りまとめたものです。不備があればぜひコメントを頂けると助かります。手抜き作成の手抜きのお願いで大変恐縮です。

この記事の対象読者

本記事は以下の方を対象としています。

ServiceNow の Platform Administrator / System Administrator として日々運用に携わっている方
ServiceNow Architect としてゼロから権限モデルを設計・再設計しようとしている方
コンプライアンス担当者やセキュリティエンジニアとして SOX・HIPAA・ISO 27001・GDPR 準拠を ServiceNow 上で実現する必要がある方
Australia リリース（2026年5月 GA） へのアップグレードを控え、itil_admin 継承変更の影響を事前に把握したい方

Java や Python のコードを書く必要はありません。ただし、ServiceNow のテーブル構造、ACL、ロールの基本知識があることを前提とします。

TL;DR (要約)

ポイント	内容
新ロール数	ITSM 領域で 5 つの専用 admin ロールを新設
対象リリース	Australia（Early Availability: 2026-03-12 / GA: 2026-05-05）
最大の大幅な変更	`itil_admin` が `sn_cmdb_admin` を自動継承するようになる
`itil` にも追加	4 つのロールが継承に追加（`sn_cmdb_editor` 等）
移行方針	最小権限原則に基づき 9 ステップで段階移行
監査有効化	`glide.role_management.v2.audit_roles=true` を最初に設定

背景: なぜ Granular Admin Roles が必要なのか

Admin Sprawl という問題

ServiceNow の admin ロールは全能です。ACL を無視し、すべてのテーブルの読み書き・削除が可能で、システムプロパティの変更、スコープアプリの設定変更、ユーザー管理まですべてを内包します。初期構築時には便利ですが、組織が成熟するにつれて深刻な問題を引き起こします。

これが Admin Sprawl（管理者権限の肥大化・拡散） です。典型的なパターンを見てみましょう。

よくある権限設定の悪例:
- 開発者にも admin を付与（「テストしやすいから」）
- Help Desk 担当者にも itil_admin を付与（「問い合わせが多いから」）
- 退職者のアカウントに admin が残ったまま
- サービスアカウントに admin（「昔から動いているから変えたくない」）

このような状態になると、以下のリスクが顕在化します。

職務分離（SoD）の崩壊: Change Management の承認者が自分で変更を実施できる
監査証跡の不明確化: 誰が何をしたか追跡が困難
CMDB の汚染: 権限を持ちすぎた担当者が誤って CI レコードを書き換える
コンプライアンス違反: SOX 404、HIPAA Security Rule への準拠が困難

「とりあえず admin を付与する」運用は技術的負債です。 Australia リリース以降、この問題に対処するための具体的なロール体系が整備されますが、それを活かすには意図的な設計が必要です。

Australia リリースのセキュリティ戦略における位置づけ

ServiceNow は近年、リリースごとに Granular Admin Roles（細粒度管理者ロール） を段階的に拡充してきました。

Vancouver (2023): security_admin の昇格ワークフロー強化
Washington DC (2024): Time-Limited Roles の導入、Delegated Development の拡充
Xanadu (2024): SIR（Security Incident Response）スコープの分離
Yokohama (2025): GRC・HR モジュールの細粒度ロール整備
Australia (2026): ITSM コアモジュール（Incident, Change, MIM, On-Call, TCM）の管理者ロール分離

Australia リリースは「ITSM の管理者権限分離」という、これまで手付かずだった領域に踏み込んだ点で特筆すべきリリースです。ServiceNow の公式コミュニティで Mega Sage の認定を受ける Gaurav Shirsat 氏は 2026-03-30 付けの投稿で「このリリースは ServiceNow のセキュリティ戦略における重要なマイルストーン」と位置づけています（出典: ServiceNow Community）。

リリースサイクルの変更について: Australia リリースから、ServiceNow のメジャーリリースサイクルが Q1/Q3 の年 2 回から Q2/Q4 の年 2 回 に変更されています。Knowledge 26 カンファレンス（2026年5月）での General Availability（GA）を意識したスケジュール設計です。

リリーススケジュール

マイルストーン	日付
Early Availability (EA)	2026-03-12
General Availability (GA)	2026-05-05 (Knowledge 26 と同時)
推奨アップグレード目安	2026 Q2 中

新設された5つの ITSM 管理者ロール

各ロールの詳細

Australia リリースで新設された 5 つのロールは、それぞれ特定の ITSM モジュールの設定・構成に特化しています。日常的な運用タスク（チケットの作成・更新など）とは分離されている点が重要です。

`sn_incident_admin` — Incident Management 管理者

ロール名: sn_incident_admin
対象モジュール: Incident Management

このロールが許可する操作:

Incident Management のシステムプロパティ変更
インシデント分類・優先度・影響度の定義設定
Incident Management プラグインの機能設定
SLA 定義の管理（sn_sla_definition_query を内包）

付与する対象の例: Service Desk マネージャー、ITSM ツール管理担当者

`sn_change_admin` — Change Management 管理者

ロール名: sn_change_admin
対象モジュール: Change Management

このロールが許可する操作:

Change Management の機能フラグとシステムプロパティの変更
Change Advisory Board（CAB）の設定
変更タイプ（Standard/Normal/Emergency）の定義管理
変更リスク計算ルールの設定

付与する対象の例: Change Manager、ITIL Process Owner

sn_change_admin は Change レコード自体の承認・却下を行う権限ではありません。それは itil + approver_user の組み合わせで制御されます。ロールの責務を混同しないよう注意してください。

`sn_mim_admin` — Major Incident Management 管理者

ロール名: sn_mim_admin
対象モジュール: Major Incident Management

このロールが許可する操作:

Major Incident のトリガールール定義
MIM 関連のシステムプロパティ管理
Major Incident ワークフロー設定
エスカレーションマトリクスの設定

付与する対象の例: MIM Process Owner、Crisis Management 担当

`sn_on_call_admin` — On-Call Scheduling 管理者

ロール名: sn_on_call_admin
対象モジュール: On-Call Scheduling

このロールが許可する操作:

On-Call ローテーションと当番表の管理
On-Call トリガーテーブルの設定
エスカレーションポリシーの定義
通知スケジュールの設定

付与する対象の例: Service Desk Lead、インフラチームマネージャー

`sn_tcm_admin` — Task Communications Management 管理者

ロール名: sn_tcm_admin
対象モジュール: Task Communications Management

このロールが許可する操作:

Task Communication プランと通信タスクの設定
通信テンプレートの管理
通信チャネル設定（メール、Teams 等）の管理

付与する対象の例: Change Communication 担当、Service Desk Communication Manager

従来の権限付与との比較

Australia リリース前後で、同じ業務を行うユーザーに付与すべきロールがどのように変わるかを示します。

役職・担当	従来の付与ロール（問題あり）	Australia 以降の推奨ロール
Incident Management 設定担当	`admin` または `itil_admin`	`sn_incident_admin`
Change Management 設定担当	`admin` または `itil_admin`	`sn_change_admin`
MIM 担当	`admin`	`sn_mim_admin` + `itil`
On-Call スケジュール担当	`admin`	`sn_on_call_admin`
TCM 設定担当	`admin`	`sn_tcm_admin`
CMDB メンテナンス担当	`itil_admin`（≒ `sn_cmdb_admin` も内包される）	`sn_cmdb_editor` のみ

ロール割り当ての判断基準

新しいロールを誰に付与するかを判断するフレームワークとして、以下の問いを使ってください。

この人は「設定・構成」が必要か、それとも「運用・利用」が必要か？
- 設定・構成 → 細粒度 admin ロール
- 運用・利用 → itil または専用の利用者ロール
この人が持つ権限が侵害された場合、最大の被害範囲はどこまでか？
- 被害範囲が特定モジュールに限定できるなら、細粒度ロールで十分
この権限は恒久的に必要か、一時的か？
- 一時的（例：アップグレード期間中のみ）→ Time-Limited Roles を使用

ITIL ロール継承の変更（大きな変更あり）

itil ロールに追加された4つの継承ロール

Australia リリースで itil ロールの継承に以下の 4 つが追加されます。これは itil を持つすべてのユーザーが自動的にこれらの権限を得る ことを意味します。

追加ロール	機能	影響
`sn_cmdb_editor`	CMDB Workspace での CI レコードの作成・編集・維持	ITSM 担当者が CMDB を直接操作可能になる
`sn_comm_management.comm_plan_viewer`	Communication Plan の読み取り専用アクセス	インシデント対応者が通信計画を確認可能
`sn_sla_definition_query`	SLA/OLA レコードの参照	SLA の定義内容を確認できる
`sn_uib_collab_user`	UI Builder のコラボレーティブワークスペースへのアクセス	ローコード/ノーコード作業への参加が可能

sn_cmdb_editor の追加により、従来は CMDB 操作のために不必要に itil_admin を付与していた運用が不要になります。これは最小権限化への追い風です。

sn_cmdb_editor と sn_cmdb_admin の違い

sn_cmdb_editor:
  - CI レコードの作成・編集・メンテナンス
  - CMDB Workspace の利用
  - CI 関連レコードの表示

sn_cmdb_admin:
  - 上記すべて + CMDB の設定変更
  - CMDB ヘルスダッシュボードの設定
  - CI クラスの定義変更
  - Discovery スケジュールの管理

日常的な CMDB メンテナンス担当者には sn_cmdb_admin ではなく sn_cmdb_editor で十分です。

⚠️ itil_admin への大きな変更: sn_cmdb_admin の自動継承

これは Australia リリースにおける最重要の変更です。

itil_admin ロールが sn_cmdb_admin を自動的に継承するようになります。アップグレード後、現在 itil_admin を持つユーザーは 全員が sn_cmdb_admin の権限を自動取得 します。

影響評価を実施せずにアップグレードすることは危険です。

この変更が問題となる具体的なシナリオ:

シナリオA: IT サポートチームの権限過剰

Before: itil_admin ユーザー
  → Change 承認、SLA 管理、ナレッジ管理

After (Australia): itil_admin ユーザー
  → Change 承認、SLA 管理、ナレッジ管理
  → + CMDB 設定変更（意図していない！）
  → + Discovery スケジュール管理（意図していない！）

シナリオB: SOX/ISO 27001 監査への影響

SOX コントロール: 「CMDB 変更は承認プロセスを経た担当者のみ」
現状: itil_admin 保有者 50名 全員が CMDB 設定変更可能になる
監査指摘: "SoD 違反の可能性"

アップグレード前に必須の対応

以下の手順を Australia アップグレード前 に必ず実行してください。

Step 1: itil_admin 保有者の全数確認

// Background Script で実行
var gr = new GlideRecord('sys_user_has_role');
gr.addQuery('role.name', 'itil_admin');
gr.addQuery('state', 'active');
gr.query();
while (gr.next()) {
    gs.info('User: ' + gr.user.user_name +
            ' | Name: ' + gr.user.name +
            ' | Assigned: ' + gr.sys_created_on);
}

Step 2: 各ユーザーの業務と必要権限の照合

照合マトリクス例:

ユーザー	現在のロール	必要な権限	アップグレード後の推奨ロール
alice@example.com	`itil_admin`	Change 設定のみ	`sn_change_admin` + `itil`
bob@example.com	`itil_admin`	CMDB 設定が本当に必要	`itil_admin`（維持）
charlie@example.com	`itil_admin`	Incident 設定のみ	`sn_incident_admin` + `itil`

Step 3: 不要な itil_admin を剥奪してから、適切な細粒度ロールを付与

既存の細粒度ロールとの全体像

プラットフォームレベルの細粒度ロール一覧

Australia 以前から存在するプラットフォームレベルの重要な細粒度ロールをまとめます。

ロール名	機能	推奨付与先
`security_admin`	高権限操作（ACL 作成・ユーザーロール管理）の昇格	Platform Admin（常時でなく昇格時のみ）
`user_admin`	ユーザー・グループの管理	IT Help Desk、HR
`personalize_dictionary`	テーブル・フィールドのカスタマイズ	Configuration Admin
`catalog_admin`	Service Catalog の設定	ITSM Catalog Manager
`report_admin`	レポート全体の管理	Reporting Lead
`pa_admin`	Performance Analytics の設定	Analytics Manager

モジュール別管理者ロール

モジュール	管理者ロール	利用者ロール
CMDB	`sn_cmdb_admin`	`sn_cmdb_editor`（新規・itil 継承）
Security Incident Response	`sn_si.admin`	`sn_si.analyst`
HR Service Delivery	`sn_hr_core.admin`	`sn_hr_core.case_writer`
GRC / Risk	`sn_grc.admin`	`sn_grc.user`
ITSM - Incident	`sn_incident_admin`（新規）	`itil`
ITSM - Change	`sn_change_admin`（新規）	`itil`
ITSM - MIM	`sn_mim_admin`（新規）	`itil`
ITSM - On-Call	`sn_on_call_admin`（新規）	`itil`
ITSM - TCM	`sn_tcm_admin`（新規）	`itil`

管理者ロールの階層構造と設計原則

admin（全権限 ← 使用を最小限に）
  ├── security_admin（昇格が必要な操作）
  ├── itil_admin（ITSM 全体設定 + sn_cmdb_admin）← Australia 以降
  │     ├── sn_incident_admin
  │     ├── sn_change_admin
  │     ├── sn_mim_admin
  │     ├── sn_on_call_admin
  │     └── sn_tcm_admin
  ├── sn_si.admin（SIR スコープ）
  ├── sn_hr_core.admin（HR スコープ）
  └── sn_grc.admin（GRC スコープ）

itil（ITSM 利用者）
  ├── sn_cmdb_editor（新規継承）
  ├── sn_comm_management.comm_plan_viewer（新規継承）
  ├── sn_sla_definition_query（新規継承）
  └── sn_uib_collab_user（新規継承）

設計原則: admin ロールは「プラットフォームの初期設定」と「重大インシデント時の緊急操作」のみに使用し、日常業務では使わないことがゴールです。Australia の 5 つの新ロールはこの原則を ITSM 領域でも実現するための基盤です。

設定・構成手順

基本的な設定手順

新しい細粒度ロールをユーザーに付与する際は、個人への直接付与ではなくグループ経由 が推奨されます。

グループベースのロール付与手順:

sys_user_group テーブルで新しいグループを作成
- 例: ITSM - Incident Admins、ITSM - Change Admins

グループにロールを付与

グループ: ITSM - Incident Admins
ロール: sn_incident_admin

メンバーをグループに追加（個人へのロール直接付与は禁止）

ロール監査の有効化

Australia 移行の前後を問わず、最初に行うべき設定は ロール監査の有効化 です。

System Properties > Security
プロパティ名: glide.role_management.v2.audit_roles
値: true

この設定を有効化すると sys_audit_role テーブルへの記録が開始され、以下の操作が監査ログに残ります。

ユーザーへのロール付与・剥奪
グループへのロール付与・剥奪
ロール継承の変更

glide.role_management.v2.audit_roles=true を設定しても、設定より前の操作は遡及的に記録されません。できる限り早いタイミングで有効化することを強く推奨します。

security_admin 昇格の正しい使い方

security_admin は「常時保有するロール」ではなく「必要な操作時のみ昇格するロール」として設計されています。

正しい使い方:
1. 通常操作: admin ロールのみ
2. ACL 変更が必要な場合:
   → System Security > Elevate Roles から security_admin を一時昇格
3. 操作完了後: security_admin の昇格を解除

昇格操作は KB0788167 に記載の通り監査ログに記録されます。

// 昇格の監査ログを確認するクエリ
var gr = new GlideRecord('sys_audit_role');
gr.addQuery('role', 'security_admin');
gr.addQuery('sys_created_on', '>=', 'javascript:gs.beginningOfLastMonth()');
gr.orderByDesc('sys_created_on');
gr.query();
while (gr.next()) {
    gs.info('User: ' + gr.user.user_name +
            ' | Action: ' + gr.action +
            ' | Time: ' + gr.sys_created_on);
}

Scoped Administration の設定

スコープアプリの管理者を分離するには、各スコープアプリの Admin ロールを使用します。

SIR（Security Incident Response）の分離例:

目標: SecOps チームが SIR を管理できるが、
      他の ITSM 設定は変更できない

設定:
1. グループ作成: SecOps - SIR Admins
2. ロール付与: sn_si.admin
3. itil_admin は付与しない
4. sn_si.admin は一方向操作（ロックダウン後は解除不可）
   → 事前に十分テストすること

sn_si.admin の SIR ロックダウンは一方向操作です。 ロックダウン後に admin から SIR を切り離すと、元に戻すには ServiceNow サポートへの連絡が必要になります。必ず Sandbox インスタンスで十分なテストを行ってから本番適用してください。

移行ガイド: 9ステップで進める権限最小化

ステップ別解説

Step 1: ロール監査の有効化

System Properties で設定:
glide.role_management.v2.audit_roles = true

これがすべての起点です。監査なしに権限移行を行うことは、変更の証跡が残らないため推奨しません。

Step 2: 現状の admin/itil/itil_admin 保有者のエクスポートと監査

// admin 保有者一覧
var roles = ['admin', 'itil', 'itil_admin'];
roles.forEach(function(roleName) {
    var gr = new GlideRecord('sys_user_has_role');
    gr.addQuery('role.name', roleName);
    gr.addQuery('state', 'active');
    gr.query();
    var count = 0;
    while (gr.next()) { count++; }
    gs.info(roleName + ': ' + count + ' users');
});

エクスポート結果は Excel 等で管理し、各ユーザーの業務内容と照合します。

Step 3: アップグレード前のロールレビュー（Australia 特有）

Australia アップグレード専用チェックリスト:

itil_admin 保有者全員を特定
各保有者が本当に sn_cmdb_admin 相当の権限を必要としているか確認
不要な itil_admin 保有者に代替ロールを割り当て
アップグレード後の権限マトリクスを関係者に共有・承認取得

Step 4: 業務目的別グループの作成と細粒度ロールの付与

グループ設計例:
ITSM-Incident-Admins    → sn_incident_admin
ITSM-Change-Admins      → sn_change_admin
ITSM-MIM-Admins         → sn_mim_admin
ITSM-OnCall-Admins      → sn_on_call_admin
ITSM-TCM-Admins         → sn_tcm_admin
ITSM-CMDB-Editors       → sn_cmdb_editor（itil 継承でも可）
ITSM-CMDB-Admins        → sn_cmdb_admin
Platform-Security-Admins → security_admin

Step 5: ACL 修正による CMDB アクセス制限

// CMDB テーブルへの直接書き込みを制限する ACL 例
// cmdb_ci テーブルの write ACL
Table: cmdb_ci
Operation: write
Role: sn_cmdb_editor OR sn_cmdb_admin
Script:
  // さらに細かい制御が必要な場合
  return gs.hasRole('sn_cmdb_editor') || gs.hasRole('sn_cmdb_admin');

Step 6: スコープアプリの admin ロールを分離

対象スコープアプリ:

sn_si.admin（Security Incident Response）
sn_hr_core.admin（HR Service Delivery）
sn_grc.admin（GRC / Risk Management）

各スコープの admin ロールを適切なチームのグループに付与し、itil_admin や admin からこれらのスコープを切り離します。

Step 7: Time-Limited Roles による一時的アクセス制御

Washington DC リリース以降で利用可能な Time-Limited Roles を活用します。

ユースケース:
- アップグレード作業のために一時的に admin が必要
- 外部コンサルタントに 2 週間だけ特定権限を付与

設定場所:
User Administration > Users > [ユーザー選択] > Roles タブ
→ Expiration Date を設定

Time-Limited Roles のセキュリティギャップ: 期限付き admin を持つユーザーが、期限切れ前に自分自身に恒久的なロールを付与できる問題があります（後述の Known Issues を参照）。一時的な admin 付与時は必ず監視を強化してください。

Step 8: 余剰 admin ロールの安全な剥奪

// 特定ユーザーから admin を剥奪する前の確認スクリプト
var userId = 'YOUR_USER_SYS_ID';
var gr = new GlideRecord('sys_user_has_role');
gr.addQuery('user', userId);
gr.addQuery('state', 'active');
gr.query();
while (gr.next()) {
    gs.info('Role: ' + gr.role.name +
            ' | Source: ' + gr.granted_by +
            ' | Since: ' + gr.sys_created_on);
}

security_admin をすべてのユーザーから削除することは絶対に避けてください。 最後の security_admin 保有者を削除すると、復旧には ServiceNow サポートへの連絡が必要になります。

Step 9: 検証とモニタリング

移行後の検証項目:

各ユーザーが必要な操作を実施できるか確認（UAT）
不要な操作が拒否されることを確認
sys_audit_role テーブルで予期しない権限変更がないか確認
Security Center のコンプライアンスダッシュボードを確認
移行完了を関係者に通知

移行時の主要な落とし穴

落とし穴	防止策
admin を剥奪したら業務が止まった	UAT を Sandbox で十分実施してから本番適用
itil_admin の数を把握していなかった	Step 2 の監査を必ず先行実施
グループ経由でなく個人にロール付与	グループポリシーを明文化し、直接付与を ACL で制限
security_admin を全員から削除	少なくとも 2 名の専任保有者を維持
Sandbox でテストせず本番で SIR ロックダウン	本番前に Sandbox で動作確認必須

ユースケース・活用シナリオ

ユースケース1: 職務分離 (SoD) の強制

背景: 金融機関 A 社では、Change Management の承認者と実施者が同一人物になるケースがあり、SOX 監査で指摘を受けていた。

解決策:

Change 承認者グループ:
  ロール: approver_user + itil
  ※ sn_change_admin は付与しない

Change 実施者グループ:
  ロール: itil
  ※ 承認権限はなし

Change 設定管理者グループ:
  ロール: sn_change_admin
  ※ Change レコードの承認・実施はできない

この設計により、1 人のユーザーが Change の「設定変更」「承認」「実施」を同時に行うことが構造的に不可能になります。

ユースケース2: 開発者アクセス（admin なしで開発）

背景: アプリ開発チームが「開発しやすいから」という理由で全員 admin を持っていた。

解決策（Delegated Development）:

ServiceNow の Delegated Development では、admin を付与せずに 10 種類の権限タイプを個別付与できます。

開発者に必要な権限（admin なしで構成）:
1. Can create applications
2. Can edit application files
3. Can publish to update sets
4. Can manage data (特定のテーブルのみ)
5. Can manage ACLs (開発スコープ内のみ)

Sasol 社の事例: 南アフリカの化学・エネルギー企業 Sasol は、Delegated Development と Granular Admin Roles を組み合わせた「virtual guardrails（仮想ガードレール）」モデルにより、コンプライアンスを維持しながら開発速度を向上させました。

ユースケース3: Granular Delegation（粒度の細かい委任）

特定のグループ管理やカタログ管理を、admin を付与せずに特定のユーザーに委任できます。

委任設定例:
対象ユーザー: 各部門の IT 担当者
委任権限:
  - 自部門のグループメンバー管理のみ
  - 自部門向けカタログアイテムの管理のみ

設定場所:
User Administration > Delegated Administration

金融機関での Granular Delegation 活用事例: Peoplesoft Financials カテゴリの承認タスクに限定した委任を設定。User Criteria で代理候補者を制限し、承認は可能だが承認レコードの編集はできない ACL を実装。最小限の開発工数でコンプライアンスを維持しながら業務継続を実現した。

ユースケース4: Time-Limited Roles（一時的な権限付与）

シナリオ: 外部コンサルタントが 2 週間かけてアップグレード支援

設定:
ユーザー: consultant@external.com
ロール: sn_change_admin, sn_incident_admin
有効期限: 2026-05-20

設定後に自動で監視:
- 権限付与時に sys_audit_role に記録
- 期限後は自動的に無効化

ユースケース5: HR・機密データの隔離

背景: 医療機関 B では、ITSM 担当者が Patient Health Information（PHI）を含む HR ケースを閲覧できてしまう状態だった。

解決策:

HR データの保護:
1. sn_hr_core.secure_info_reader ロールを付与したユーザーのみ
   PHI フィールドが見える
2. ITSM 担当者 (itil ロール) には見えない

Field-Level ACL の設定:
Table: sn_hr_case
Field: [PHI フィールド]
ACL Script:
  return gs.hasRole('sn_hr_core.secure_info_reader');

AES-256 暗号化と Field-Level ACL を組み合わせることで HIPAA Security Rule への準拠を実現します。

チームロール整合マトリクス

チーム/役割	admin	security_admin	itil_admin	itil	細粒度ロール
Platform Admin	○	昇格のみ	-	-	-
ITSM Process Owner	-	-	必要最小限	○	業務に応じて選択
Service Desk Operator	-	-	-	○	-
CMDB Engineer	-	-	-	○	`sn_cmdb_editor`
CMDB Admin	-	-	-	○	`sn_cmdb_admin`
Change Manager	-	-	-	○	`sn_change_admin`
SecOps Engineer	-	-	-	-	`sn_si.admin` または `sn_si.analyst`
HR Case Worker	-	-	-	-	`sn_hr_core.case_writer`
App Developer	-	-	-	-	Delegated Development
External Consultant	-	-	-	-	Time-Limited + 最小細粒度ロール

セキュリティ・コンプライアンス対応

SOX 対応

Sarbanes-Oxley Act（SOX）Section 404 では、財務報告に関わるシステムの内部統制が求められます。

ServiceNow での SOX 対応:

GRC SOX Content Pack: SOX 準拠に必要なコントロール・リスクテンプレートが含まれます
SoD 強制: sn_change_admin と approver_user の分離により Change SoD を実現
監査証跡: glide.role_management.v2.audit_roles=true による全ロール変更の記録

SOX コントロール例:
CTRL-IT-001: 本番変更は実施者と異なるユーザーが承認する
実装: sn_change_admin ≠ approver_user（ロールの分離で強制）

CTRL-IT-002: 特権アクセスは記録・承認される
実装: security_admin 昇格ログ（KB0788167）

HIPAA 対応

Health Insurance Portability and Accountability Act（HIPAA）の Security Rule では PHI の保護が義務付けられます。

PHI 保護の実装:
1. Field-Level ACL: PHI フィールドへのアクセスを sn_hr_core.secure_info_reader に限定
2. AES-256 暗号化: sys_encrypted_text フィールドタイプを使用
3. 監査ログ: PHI アクセスをすべて sys_audit に記録
4. アクセス最小化: HR データへの itil アクセスを ACL でブロック

ISO/IEC 27001 対応

ServiceNow は 2012 年から ISO/IEC 27001 認証を取得しており、ISO/IEC 27017（クラウドセキュリティ）および ISO/IEC 27018（クラウドにおける個人情報保護）も取得しています。

Granular Admin Roles は ISO 27001 の A.9（アクセス制御） 要件に直接対応します。

ISO 27001 管理策	ServiceNow での実装
A.9.1.2 情報及びアプリケーションへのアクセス	ACL + 細粒度ロールで最小権限を実装
A.9.2.3 特権的アクセス権の管理	`security_admin` の昇格制御
A.9.4.1 情報アクセスの制限	Field-Level ACL、Security Data Filters

GDPR 対応

EU 一般データ保護規則（GDPR）への対応:

PII（個人情報）保護:
1. Field-Level ACL で PII フィールドへのアクセス制限
2. EU データレジデンシー: ServiceNow Privacy Packs（SPP EU）を使用
3. データ削除権: Data Anonymization ツールの活用
4. アクセスログ: sys_audit での全アクセス記録

監査証跡の仕組み

Australia リリース以降の監査テーブル構成:

sys_audit:
  → テーブルレベルの変更記録（既存）

sys_audit_role:
  → ロール付与・剥奪の記録（glide.role_management.v2.audit_roles=true で有効）
  → 記録内容: user, role, action (add/remove), granted_by, timestamp

sys_security_event:
  → security_admin 昇格の記録（KB0788167）

セキュリティベストプラクティス 7箇条

ロールはグループ経由で付与する: 個人への直接付与は例外的運用に限定し、理由を記録する
admin を日常業務に使わない: Incident チケットの更新や Change の承認に admin は不要。適切な細粒度ロールを使う
security_admin は昇格制で使う: 常時保有ではなく、必要な操作時のみ意識的に昇格する
itil_admin を毎回のメジャーアップグレード前に監査する: 今後も itil_admin の継承内容は変更される可能性がある
ロール監査を常時有効化する: glide.role_management.v2.audit_roles=true を本番・開発・テスト全環境で有効化
一時的な権限は Time-Limited Roles を使う: 「期間限定の admin」を設定し、終了後に自動無効化されるようにする
RBAC のテストは専用 Sandbox インスタンスで行う: 本番インスタンスで直接 ACL テストを行うことは権限剥奪リスクがある

注意事項・Known Issues

既知の問題一覧

KB / PRB 番号	問題内容	回避策
KB0793530	`admin` + `security_admin` を持つユーザーが、`admin` ロールを含むグループのメンバーを管理できない	ServiceNow サポートに連絡
KB0693286 / PRB1275223	`user_admin` または `sn_si_manager` が `sn_si` スコープのグループを編集できない（Jakarta 以降の仕様）	`sn_si.admin` を付与、または設計変更
KB0696830	プラグインを新規アクティベーション後、新しいロールが有効になるにはログアウト→ログインが必要	ユーザーに再ログインを案内
—	`sn_si.admin` の SIR ロックダウンは一方向操作（undo 不可）	Sandbox で十分テスト後に本番適用
—	ロール継承のオーファンレコードがトランザクションタイムアウト後に発生することがある	ServiceNow サポートエンジニアへの連絡が必要
—	Role Management V2 プラグインが 3 つのレガシーフィールドをクリアする	移行前にレガシーフィールドを参照しているカスタマイズを確認

Time-Limited Roles のセキュリティギャップ

重要なセキュリティギャップ: 期限付き admin ロールを付与された一時ユーザーが、権限期限切れ前に自分自身に恒久的なロールを付与できるという問題があります。

影響: 悪意あるユーザーまたは内部脅威によって、一時権限が恒久権限に昇格される可能性がある

対処法:

一時的な admin 付与中は sys_audit_role をリアルタイム監視する
一時ユーザーへの user_admin または security_admin の同時付与を避ける
付与から 24 時間以内に権限変更の監査ログを確認する
ServiceNow が修正を提供するまでの暫定措置として、Manager 承認フローを必須化する

トレーニングリソース

Now Learning: "ServiceNow Administration Fundamentals" コースに関連内容が含まれる
CSA 認定試験: Certified System Administrator の試験範囲に含まれる
ServiceNow Community: Gaurav Shirsat 氏のブログシリーズ（上述）

今後の展望

以下は筆者の個人的な見解です。ServiceNow 社の公式ロードマップではありません。

Australia リリースで ITSM コアモジュールの管理者ロールが細粒度化されたことで、ServiceNow の権限モデルはようやく「設計として最小権限が実現できる」状態に近づいてきたと感じます。

今後の展望として、以下の方向性が期待されます。

AI を活用した権限推奨エンジン: Now Assist による「このユーザーには本当はこのロールで十分」という自動推奨
ゼロトラストアーキテクチャとの統合: MFA・Identity Provider との連携強化による動的権限付与
Cross-scope Admin Roles の統一管理: 各スコープが独自に持つ admin ロールを一元的に管理・可視化するダッシュボード
Compliance as Code: SOX・HIPAA・GDPR 要件を ServiceNow 設定として宣言的に定義するフレームワーク

まとめ

ServiceNow Australia リリース（2026-05-05 GA）における Granular Admin Roles の主要ポイントを振り返ります。

新設ロール（5 つの ITSM Admin Roles）:

sn_incident_admin、sn_change_admin、sn_mim_admin、sn_on_call_admin、sn_tcm_admin が新設
「ITSM の設定担当者に admin は不要」という原則が ITSM 領域でも実現可能に

ITIL ロール継承の変更:

itil に 4 つのロールが追加（sn_cmdb_editor 等）→ ITSM 利用者の利便性向上
itil_admin が sn_cmdb_admin を自動継承 → アップグレード前の監査必須

移行の方針:

glide.role_management.v2.audit_roles=true を最初に有効化
itil_admin 保有者を全数確認・照合
グループベースで細粒度ロールを付与
余剰 admin・itil_admin を段階的に剥奪
Security Center とロール監査で継続モニタリング

Admin Sprawl は「なんとなく続いてきた悪習」ですが、それを終わらせるためのツールが整ってきました。Australia リリースを権限モデル再設計の契機として活用してください。

用語集

用語	説明
Admin Sprawl	`admin` ロールが必要以上のユーザーに付与され、管理が困難になる状態
Granular Admin Roles	特定のモジュールや機能に限定した管理者ロール群の総称
SoD (Segregation of Duties)	職務分離。1人のユーザーが対立する権限を同時に持てないよう設計すること
Delegated Development	admin を付与せずに開発権限を委任する機能（10 種類の権限タイプ）
Time-Limited Roles	有効期限付きのロール付与（Washington DC リリース以降）
security_admin	ACL 管理などの高権限操作を許可するロール。昇格制で利用
itil_admin	ITSM 全体の設定を管理するロール。Australia 以降は `sn_cmdb_admin` を自動継承
Early Availability (EA)	一部のお客様向けに先行提供されるリリース（GA より前）
General Availability (GA)	全お客様向けに正式提供されるリリース
Scoped Application	ServiceNow のアプリケーション分離の仕組み。各スコープが独自の admin ロールを持つ
ACL (Access Control List)	テーブル・フィールドレベルでのアクセス制御ルール
sys_audit_role	ロール付与・剥奪の監査ログテーブル
Security Data Filter	テーブルに対してレコードレベルでの行単位アクセス制御を行う仕組み
PHI (Protected Health Information)	HIPAA で保護される医療個人情報
PII (Personally Identifiable Information)	個人を特定できる情報（GDPR の対象）

参考リンク

公式ドキュメント:

ServiceNow Docs - Granular Admin Roles (Platform Security): docs.servicenow.com/.../granular-admin-roles.html
ServiceNow Docs - Australia Release Notes: servicenow.com/docs/r/release-notes/family-release-notes.html
ServiceNow Docs - Elevated Privilege: docs/.../c_ElevatedPrivilege.html

ナレッジベース:

KB0788167 — Auditing security_admin elevation events
KB0793530 — admin + security_admin group management issue
KB0696830 — Plugin role activation requires re-login
KB0693286 / PRB1275223 — user_admin group editing limitation in sn_si scope

ServiceNow Community:

Gaurav Shirsat (Mega Sage) — "Expanded Role Inheritance for itil and itil_admin: Australia Release" (2026-03-30)
"Use Case for Granular Delegation" (ServiceNow AI Platform Blog)
"Enabling Auditing of Roles"
"Understanding Time-Limited Roles in ServiceNow"
"Configuring ACLs the Right Way"
"Seven Best Practices for User and Group Management"

技術ブログ・パートナー資料:

AqibNow: "Australia Release 2026 Complete Guide"
AelumConsulting: "ServiceNow Australia Release Updates"
Kanini: "ServiceNow Australia Release 2026"
xtype: "Taming Privilege Sprawl in ServiceNow"
Milestone Technologies: "Optimizing SOX Compliance with ServiceNow"

ホワイトペーパー:

ServiceNow Security Best Practices White Paper
ServiceNow ISO 27001/27017/27018 Certification Documentation

本記事の内容は 2026-03-30 時点の情報に基づいています。Australia リリース（GA: 2026-05-05）までの間に詳細が変更される可能性があります。本番環境への適用前には必ず最新の公式ドキュメントをご確認ください。

記事中「筆者の見解」として明示した箇所は個人的な意見であり、ServiceNow 社の公式見解ではありません。

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up

ServiceNow 2026 Australia版 Granular Admin Rolesのメモ

はじめに

この記事の作成方法

この記事の対象読者

TL;DR (要約)

背景: なぜ Granular Admin Roles が必要なのか

Admin Sprawl という問題

Australia リリースのセキュリティ戦略における位置づけ

リリーススケジュール

新設された5つの ITSM 管理者ロール

各ロールの詳細

sn_incident_admin — Incident Management 管理者

sn_change_admin — Change Management 管理者

sn_mim_admin — Major Incident Management 管理者

sn_on_call_admin — On-Call Scheduling 管理者

sn_tcm_admin — Task Communications Management 管理者

従来の権限付与との比較

ロール割り当ての判断基準

ITIL ロール継承の変更（大きな変更あり）

itil ロールに追加された4つの継承ロール

⚠️ itil_admin への大きな変更: sn_cmdb_admin の自動継承

アップグレード前に必須の対応

既存の細粒度ロールとの全体像

プラットフォームレベルの細粒度ロール一覧

モジュール別管理者ロール

管理者ロールの階層構造と設計原則

設定・構成手順

基本的な設定手順

ロール監査の有効化

security_admin 昇格の正しい使い方

Scoped Administration の設定

移行ガイド: 9ステップで進める権限最小化

ステップ別解説

Step 1: ロール監査の有効化

Step 2: 現状の admin/itil/itil_admin 保有者のエクスポートと監査

Step 3: アップグレード前のロールレビュー（Australia 特有）

Step 4: 業務目的別グループの作成と細粒度ロールの付与

Step 5: ACL 修正による CMDB アクセス制限

Step 6: スコープアプリの admin ロールを分離

Step 7: Time-Limited Roles による一時的アクセス制御

Step 8: 余剰 admin ロールの安全な剥奪

Step 9: 検証とモニタリング

移行時の主要な落とし穴

ユースケース・活用シナリオ

ユースケース1: 職務分離 (SoD) の強制

ユースケース2: 開発者アクセス（admin なしで開発）

ユースケース3: Granular Delegation（粒度の細かい委任）

ユースケース4: Time-Limited Roles（一時的な権限付与）

ユースケース5: HR・機密データの隔離

チームロール整合マトリクス

セキュリティ・コンプライアンス対応

SOX 対応

HIPAA 対応

ISO/IEC 27001 対応

GDPR 対応

監査証跡の仕組み

セキュリティベストプラクティス 7箇条

注意事項・Known Issues

既知の問題一覧

Time-Limited Roles のセキュリティギャップ

トレーニングリソース

今後の展望

まとめ

用語集

参考リンク

`sn_incident_admin` — Incident Management 管理者

`sn_change_admin` — Change Management 管理者

`sn_mim_admin` — Major Incident Management 管理者

`sn_on_call_admin` — On-Call Scheduling 管理者

`sn_tcm_admin` — Task Communications Management 管理者