ServiceNow CSAのセキュリティ対策｜ACL・ロール・責任範囲の判断ガイド

ServiceNow CSAのセキュリティ分野では、ACL・ロール・Security Center・Shared Responsibility（責任分界）といった言葉が次々に出てきます。用語の意味は分かっても、「結局どれをいつ使い、試験でどう判断すればいいのか」が掴みにくい——そう感じている方は多いはずです。

この記事は、CSAで問われるセキュリティを、①そもそも何を守る仕組みか → ②これがないと現場で何が起きるか → ③やりたいことから使う機能を選ぶ早見表の順で理解するための記事です。用語の暗記ではなく、模試で迷わない判断軸を持ち帰ることをゴールにします。

▶ この分野の模擬試験を無料・登録不要で解く
CMDB・データ移行など分野別に分けた、AI生成のCSA模試です

そもそもCSAのセキュリティは何を問うのか

ServiceNowのセキュリティは、ざっくり4つの柱で考えると整理できます。

• Role / Group（権限を配る）：誰に何の操作を許すかを、ロールとグループで管理する
• ACL（データを守る）：テーブル・フィールド単位で read/write/create/delete を制御する
• Security Center（リスクを見る）：インスタンスのリスクや推奨対応を可視化する
• Shared Responsibility（責任を分ける）：ServiceNow側と顧客側、どちらの責任かを線引きする

CSAで何度も問われる本質は、「画面で隠すこと」と「データを守ること」は別物という点です。次の事故を見ると、その意味がはっきりします。

これがないとどうなる ——「フォームで隠したのに、APIから給与額が漏れた話」

ある管理者が、給与テーブルの「金額」フィールドを一般ユーザーに見せたくないと考えました。UI Policy でフィールドを非表示にし、フォーム上から金額が消えたのを確認して「これで安心」と判断しました。

ところが後日、一般ユーザーがリストビューと REST API、さらにレポートから金額の値を普通に取得できていたことが分かります。原因は単純です。UI Policy はフォーム画面の見た目を変えるだけで、データそのものへのアクセスは1つも制限していなかった。フィールドACLを設定していなかったのです。

これがセキュリティ設計が抜けていると起きることの典型です。「見えない」と「アクセスできない」は別。画面で隠しても、リスト・API・レポートなど別経路から値は取れてしまいます。本当に守るには、データ操作そのものを制御するACLが要ります。

だからCSAは権限と責任を問う ——鍵は「隠す」でなく「守る・分ける」

こうした事故を防ぐ力があるかを確認するため、CSAの試験範囲にはアクセス制御（ACL）、ロール設計、Security Center、Shared Responsibility が含まれています。問われるのは用語の暗記ではなく、「誰が・何を・どこまでできるか」を正しい仕組みで制御できるかです。

この先は、(1)迷ったとき立ち返る判断早見表、(2)4つの柱を「事故 → 放置するとどうなる → どう使って防ぐ → 改善後」で、の順に、模試で迷わない判断軸を作っていきます。

セキュリティ判断早見表（迷ったらここに戻る）

セキュリティの問題は、やりたいこと（問題文）と使う機能を結べれば解けます。次の早見表が、この記事全体の地図です。各行は後の章で事故付きで深掘りします。

ここからは、4つの柱を「実際に起きがちな事故」から見ていきます。事故の形を知っていると、選択肢の言い換えに惑わされなくなります。

Role / Group：退職者の権限が、いつまでも残る

現場で起きる事故：異動・退職のたびに、管理者が個々のユーザーへロールを直接付けたり外したりしていた。半年後、棚卸しすると「誰がなぜこの権限を持っているか」が誰にも分からず、退職者アカウントに強い権限が残っていた。

放置するとどうなる：ユーザーへロールを直接乱発すると、権限が属人化し、棚卸し・剥奪が追いつきません。不要な権限が静かに積み上がり、攻撃や情報漏洩の入口になります。

CMDBではなくここで使うのは：同じ職務の権限はGroup にロールを付与し、ユーザーを Group に所属させて管理します。職務が変わったら所属を変えるだけで権限が切り替わり、棚卸しもグループ単位でできます。

改善後：「このグループ＝この権限」が明確になり、入退社・異動に強い権限運用になります。個別付与の抜け漏れが減ります。

早見表の該当行：「同じ権限を多人数に付けたい」→ Role / Group。誤答は「Userに直接Roleを乱発」。

ACL：隠すのではなく、データ操作そのものを守る

現場で起きる事故：冒頭で紹介した「フォームで隠したのにAPIから給与額が漏れた」事故が、まさにこのACLの問題です。UI Policy で隠しただけで、データアクセスは制御されていませんでした。

放置するとどうなる：画面表示の制御（UI Policy / フォームレイアウト）だけでは、リスト・API・レポートなど別経路からデータが見えます。「見えない＝守られている」ではないため、機密データが想定外に取得されます。

CSAでこう使う：テーブル／フィールドACLで read / write / create / delete を、ロールや条件・スクリプトで制御します。これは経路に依存せず、フォームでもリストでもAPIでも同じく効きます。

改善後：「誰がどのデータをどう操作できるか」が経路に関係なく一貫して守られます。画面の見た目とデータ保護を切り分けて設計できます。

早見表の該当行：「隠したのに別経路で値が見える」→ ACL。誤答は「UI Policyで隠せば安全」。

Security Center：高権限・未対応の放置を見える化する

現場で起きる事故：高権限（admin相当）アカウントが想定より多く、未対応のセキュリティ推奨（Customer Actions）も溜まっていた。誰も全体像を把握しておらず、対応漏れがインシデントにつながった。

放置するとどうなる：リスクが可視化されないと、高権限アカウントの増殖・未対応の推奨事項・古い設定が静かに積み上がります。気づいたときには対応すべき項目が膨大になっています。

CSAでこう使う：Security Centerで、コンプライアンススコア・Findings・Customer Actions・特権アカウントなどを定期的に確認します。検出（Finding）は見て終わりにせず、Security Task として作業化して対応を追跡します。

改善後：リスクの全体像と優先度が見え、対応が作業として回り始めます。ただし「点数を上げること」自体が目的ではない点に注意します（次章）。

早見表の該当行：「インスタンスのリスクを把握したい」→ Security Center（Finding／Customer Actions）。誤答は「点数を上げれば完了」。

Shared Responsibility：「クラウドだから安全」という誤解

現場で起きる事故：「ServiceNowはクラウドだから、セキュリティはベンダー任せで大丈夫」と考え、顧客側のACL・公開ページ・データ分類の設定が甘いまま運用。外部公開ポータルから、想定外のテーブルデータが見えていた。

放置するとどうなる：ServiceNowが基盤（インフラ・物理）を守っていても、顧客側の設定・権限・データ管理が甘ければデータは漏れます。責任境界を誤解すると、自社が守るべき部分が丸ごと抜け落ちます。

CSAでこう使う：Shared Responsibility Modelで、ServiceNow側（基盤・サービス提供）と顧客側（インスタンス設定・認証認可・ロール付与・データ分類）の責任を線引きして理解します。Security Center の Customer Actions は「顧客側が実施すべき対応」として扱います。

改善後：「どこから先が自社の責任か」が明確になり、設定・運用で守るべき部分を継続的に確認できます。

早見表の該当行：「どこまで自社責任か曖昧」→ Shared Responsibility。誤答は「有効化で顧客責任ゼロ」。

「隠せた・有効化した・点数が上がった」で安心する罠

セキュリティの判断問題は、「やった気になる対処」と「本当に守る対処」を見分けられるかが問われます。どれも一見もっともらしいので、具体シナリオに翻訳して違いを見ます。

「最も適切な対応は？」と問われたら、「見た目・件数・有効化」ではなく「データ操作と責任を実際に制御しているか」を選びます。これが迷わないための判断軸です。

セキュリティ運用のベストプラクティス

事故を防ぐ「守れているインスタンス」を保つために、現場で押さえておきたい運用のベストプラクティスは次の5つです。

1. 権限はGroup経由で配る。ユーザーへ直接ロールを付けず、職務グループにロールを付与して所属で管理します。
2. 機密データはACLで守る。画面で隠すだけにせず、テーブル／フィールドACLで操作そのものを制御します。
3. 最小権限を徹底する。高権限アカウントは必要最小限にし、定期的に棚卸しして不要な権限を剥奪します。
4. Security Centerを定期確認し、対応を作業化する。FindingやCustomer Actionsを見て終わりにせず、Security Taskで追跡します。
5. 責任範囲を線引きする。Shared Responsibilityで、自社が設定・運用で守るべき部分を明確にして点検します。

PDIで手を動かして確認する場所

Personal Developer Instance（PDI）で実際の画面を触ると、早見表が記憶に定着します。

• Access Control (ACL)（sys_security_acl）：テーブル／フィールドの read/write 制御を確認する
• User / Group / Role：GroupにRoleを付け、Userを所属させる流れを確認する
• Impersonate User：一般ユーザーとして表示・操作可否を確認する（隠すだけでないかの検証）
• Security Center：コンプライアンススコア・Findings・Customer Actions・特権アカウントを見る
• Data Classification / 外部公開ページ：顧客側の責任範囲にあたる設定を確認する

まとめ：事故の形で覚えると、判断問題に強くなる

• 「見えない」と「アクセスできない」は別。守るのはACL、隠すのはUI Policy
• 権限はGroup経由で配り、最小権限と棚卸しを徹底する
• Security Centerは見るだけでなく、Security Taskで対応を回す
• Shared Responsibilityで、顧客側が守るべき部分を線引きする
• 「隠せた・有効化した・点数が上がった」は、守れている証拠にはならない

セキュリティは、CSAでも判断問題が集中するテーマです。事故の形と早見表が頭に入ったら、実際の問題で手を動かして判断軸を固めましょう。