ServiceNowのセキュリティは、CSA試験でも実務でも「用語は知っているのに、いざ設定や設問になると手が止まる」領域です。ACLは知っている。Roleも知っている。Security Centerという画面があることも、Shared Responsibilityという言葉も聞いたことがある。それでも「目の前の要件に対して、どの仕組みで守るのが正しいのか」と問われると迷う。
迷う理由はシンプルで、これらの仕組みがそれぞれ別の「層」で動いているからです。画面で隠す層、データ操作を止める層、リスクを可視化する層、責任を分ける層。どの層の話をしているのかが曖昧なまま用語だけを覚えると、試験では「もっともらしい誤答」に引っかかり、実務では「守ったつもりで守れていない」状態を作ってしまいます。
この記事では、2つの実際に起こりがちな事故を入口に、ServiceNowのセキュリティを4つの層として並べ直します。そのうえで、試験で出される設問がどの層を問うているのかを見抜く視点と、自分のPDI（Personal Developer Instance）で確かめる手順までをつなげます。
ある会社で起きた、権限放置とAPI経由の情報漏えい
ある組織で、監査の直前に複数の問題が同時に発覚しました。
ひとつめは権限の放置です。入社時に管理者が個々のユーザーへ直接ロールを割り当てる運用をしていて、退職や異動のたびの後始末が人によってバラバラでした。半年後、セキュリティ監査で「退職した社員の管理者相当アカウントが残ったまま」「なぜそのユーザーがその権限を持っているのか誰も説明できない」状態が見つかります。権限が役割ではなく「人」に紐づいていたため、説明責任そのものが失われていました。高権限アカウントは、乗っ取られたときの被害が大きい入口です。使われていないアカウントも、攻撃対象を無駄に広げているだけでした。
ふたつめはデータ保護の誤解です。給与テーブルのフォームで、担当者がUI Policyを使って「金額」フィールドを非表示にしていました。画面から消えたので問題は片付いたと思い込んでいたのです。ところが数日後、一般ユーザーがリスト表示・REST API・レポートの3経路から給与額を取得できることが分かります。UI Policyはフォームの見た目だけを制御していて、データへのアクセスそのものは一切止めていませんでした。フィールドのACLが設定されていなかったのが原因です。
そして全体として、これらのリスクを俯瞰している人が誰もいませんでした。未対応のセキュリティ推奨が溜まり、分類済みデータが想定外に持ち出され、それでも「どこに何のリスクがあるか」が一覧化されていなかった。問題が起きてから初めて、断片的に気づくしかなかったのです。
この事故は、たまたま運が悪かったわけではありません。「画面で見えない」ことと「アクセスできない」ことを混同し、権限を人に紐づけ、リスクを誰も追跡していなかった——3つのほころびが重なった結果です。そして、その3つはServiceNowではそれぞれ別の層で対処すべきものでした。
ServiceNowのセキュリティを「4つの層」で捉える
セキュリティの仕組みを、目的ごとに4つの層に分けて並べます。混乱したときは、いま自分がどの層の話をしているのかをここで確かめてください。
| 層 | 仕組み | 役割 |
|---|---|---|
| 配る | Role / Group | 誰に何を許すかを配る。権限を役割と所属で管理する |
| 守る | ACL（Table / Field） | データ操作そのものを制御する。read/write/create/deleteを全経路で守る |
| 見える化する | Security Center | インスタンスのリスクと対応すべき項目を可視化・追跡する |
| 分ける | Shared Responsibility | ServiceNowと顧客、どちらの責任かを切り分ける |
この4層を貫く前提がひとつあります。「画面で隠す」ことは「データを守る」ことではない、という原則です。第1層と第2層の違いが分からないままだと、最初の事故の給与フィールドのような取り違えが必ず起こります。
第1層：Role と Group ——「誰に何を許すか」を配る
権限を配る層から見ていきます。ここでつまずく典型は、冒頭の事故そのもの——個々のユーザーに直接ロールを割り当てる運用です。
直接割り当ては、最初は手っ取り早く感じます。けれど時間が経つと、誰がどの権限を、なぜ持っているのかが追えなくなります。退職者にアクセスが残り、緩い権限が見えないところで積み上がり、それがそのまま攻撃の入口になり、監査のたびに調査コストが膨らみます。権限が「人」に貼り付いているからです。
CSAで正解とされる設計は、権限を「役割」に紐づけることです。手順としてはこうなります。
- 職務や役割を表す Group を作る
- Role は個人ではなく、その Group に付与する
- ユーザーは Group のメンバーとして出し入れする
こうすると権限が役割中心になります。異動はグループの付け替えで済み、監査はグループ単位の確認で済む。「このグループ＝この権限」という対応関係が常に明確で、個別割り当ての取りこぼしが消えます。
試験での判断軸として覚えておきたいのは、User・Group・Role の関係です。User は個人アカウント、Group は複数Userのまとまり、Role は機能・操作権限——この3つの役割を正しく対応づけられるかが問われます。「権限の対応を入れ替える」「役割を取り違える」形の誤答に乗らないことが大切です。
第2層：ACL ——データ操作そのものを守る
次は、データそのものを守る層です。最初の事故の「金額フィールドをUI Policyで隠した」失敗が、まさにこの層の取り違えでした。
UI Policyでフィールドを隠すと、フォーム上からは消えます。最もよく使う1画面では確かに見えなくなるので、対処できたように見えてしまう。けれど守られていないルートが残ります。
- リスト表示：金額が見える
- REST API：金額が取得できる
- レポート：金額が集計できる
- モバイル：金額が露出する
UI Policyはフォームのレイアウトを制御するだけで、データの権限には一切関与しないからです。見えなくなった分だけ、かえって「漏れていることに気づけない」状態になります。
正しく守るには Table ACL / Field ACL を設定します。ACLでは read / write / create / delete の操作権限を定義し、ロール条件・スクリプトによる条件・直接割り当てといった方法で制御します。重要なのは、ACLがアクセス方法に関係なく一律に適用される点です。フォームからでも、リストからでも、APIからでも、レポートからでも、同じルールが効きます。
ここから導ける原則が「見えない ≠ アクセスできない」です。画面表示の制御（UI Policy）と、データ保護（ACL）は、設計上はっきり別物として扱う。試験で「機密フィールドを保護したい」と問われてUI Policyを選ぶのは誤りで、Field ACLが正解になります。
第3層：Security Center ——放置・高権限・未対応を可視化する
権限を配り、データを守る設定をしても、それが時間とともに崩れていないかを誰かが見ていなければ、最初の事故のように「気づいたら手遅れ」になります。それを防ぐのが、リスクを一画面で可視化する Security Center です。
Security Centerは、インスタンスのセキュリティ状態をまとめて表示します。主に次のものが見えます。
- コンプライアンススコア / At a glance：全体の状態を一望する
- Findings：セキュリティチェック違反や設定上の検出結果
- Customer Actions：顧客が実施すべきセキュリティ対応（期限つき）
- 特権・未使用アカウント：Active privileged accounts と Never logged-in users
- データ保護 / ログイン保護：分類済みデータの持ち出しや、ログイン失敗の傾向
ここでCSAとして外せない考え方が、検出を見るだけでは、リスクは下がらないという点です。Findingsを眺めて満足してはいけません。Findingsは「何を直すべきか」を教えてくれるだけで、直す作業は別に必要です。
正しい運用は、Findingsを Security Task に変換し、担当者と期限を付けて実際の対応を追跡することです。ここで使ってはいけないのが Mute の誤用です。Muteは一時的な抑制であって、解決ではありません。使うなら理由と再確認日を残し、根本対応をSecurity Taskで進めます。
Customer Actionsについても同じ落とし穴があります。「ServiceNow側がやってくれる項目」だと勘違いして放置すると、期限が過ぎても何も進みません。Customer Actionsは、後述するShared Responsibilityにおける顧客側の責任として、期限で優先順位を付けて処理します。
そして高権限・未使用アカウント。最初の事故の核心でした。Active privileged accounts と Never logged-in users を定期的に棚卸しし、権限が必要最小限か確認し、退職者や不要なアカウントを削除する。これで攻撃対象が縮みます。
ここで多くの人がはまるのが「スコアを上げること自体が目的になる」罠です。スコアは上がったのに、Customer Actionsは未対応のまま、高権限アカウントも残ったまま——という状態は、見かけだけが整って中身は危ないままです。
| 進んでいる気がする操作 | 実際に起きていること | 正しい対応 |
|---|---|---|
| FindingsをMuteして件数を減らす | スコアは上がるが原因は未修正 | Security Taskで根本対応する |
| 評価範囲を狭めてスコアを上げる | 監視外の領域にリスクが残る | 運用の信頼性に基づいて評価する |
| Customer Actionsを後回しにする | 顧客側のリスクが残り続ける | 期限で処理し責任範囲を明確にする |
| 可視化で止まる | 検出だけではリスクは下がらない | 検出をSecurity Taskの対応につなぐ |
試験で「最も適切な対応は？」と問われたら、スコアや見かけの数字ではなく、実際にリスクが下がり、説明責任が果たせる選択肢を選びます。
第4層：Shared Responsibility ——「クラウドだから安全」という誤解
最後は、責任を分ける層です。ここを誤解していると、第1〜3層をいくら整えても土台が崩れます。
ありがちな思い込みが「ServiceNowはクラウドで提供されているから、セキュリティはベンダーの仕事だ」というものです。ある組織では、この前提のまま運用していたところ、公開ポータルから外部に見せるつもりのなかったテーブルデータが見えてしまいました。原因は、弱いACL、公開ページの設定ミス、データ分類の不在。ポータルのリンクを知っていれば誰でも見られる状態だったのです。
クラウド提供は「ベンダーが面倒を見てくれている」という錯覚を生みやすく、その分だけ顧客はインスタンス側の対策に投資しなくなります。実際の責任分担は次のように分かれています。
| 責任範囲 | ServiceNow | 顧客 |
|---|---|---|
| インフラ / 物理 | ○ | |
| サービス可用性 | ○ | |
| インスタンスのACL / 権限 | ○ | |
| ユーザー認証・認可 | ○ | |
| データ分類 | ○ | |
| ロールの割り当て | ○ | |
| 公開ページの設定 | ○ | |
| Customer Actionsへの対応 | ○ |
この表が示すのは、ServiceNowが守るのは基盤と可用性まで、ということです。設定・構成・認証・データの扱いは顧客の領域に入ります。だからこそ、Security CenterのCustomer Actionsは「顧客が完了させるべきタスク」として現れるのです。ここでも「有効化した ≠ 守られた」が効きます。機能を有効にしただけで完了とみなさず、Shared Responsibility Modelを物差しにして、どの対策が顧客側に属するかを洗い出し、それが実際に設定されているかを確認する——この検証ステップまでがセットです。
試験で問われる判断パターン
ここまでの4層を、設問でどう問われるかという視点で一枚にまとめます。CSAのセキュリティ設問は「やりたいこと」を提示して、それを実現する仕組みを選ばせる形が中心です。誤答はたいてい、層を取り違えた「もっともらしい選択肢」になっています。
| やりたいこと | 使う仕組み | 理由 | 引っかかりやすい誤答 |
|---|---|---|---|
| 多数のユーザーに同じ権限を配りたい | Role / Group | 権限を集約し、異動・退職に強くなる | 個人へロールを直接割り当てる |
| すべてのアクセス経路でデータ操作を制御したい | ACL（Table / Field） | フォーム・リスト・API・レポートに一律で効く | UI Policyで非表示にするだけ |
| インスタンス全体のリスク状態を把握したい | Security Center（Findings + Customer Actions） | 可視化し、Security Taskで追跡する | スコアを上げて完了とみなす |
| 自社とベンダーの責任を切り分けたい | Shared Responsibility Model | 顧客側の対策範囲を定義する | クラウドだから全部安全と考える |
判断の軸はひとつです。「制御しているように見える」選択肢ではなく、「実際にデータ・操作・責任を制御している」選択肢を選ぶ。隠す・スコアを上げる・有効化する、はいずれも見かけの安心であって、守れている証拠にはなりません。
PDIで確認するセキュリティ設定の手順
理解を定着させるには、自分のPDIで実際に触るのが近道です。次の順番で確かめてください。画像で残しておくと、後から見返したときに記憶が戻りやすくなります。
- Access Control（ACL）テーブルを開く：ナビゲーションから
sys_security_aclを開き、テーブルとフィールドのread/writeルールを観察する。どのオペレーション（read / write / create / delete）にどんな条件が付いているかを見る。 - User / Group / Role の流れを作る：Groupを1つ作り、そこにRoleを付与し、ユーザーをそのGroupのメンバーに追加する。個人に直接付けず、所属で権限が継承されることを確認する。
- Impersonate Userで検証する：一般ユーザーになりすまし（Impersonate）、フォーム・リスト・APIで先ほどのデータにアクセスを試みる。UI Policyではなく、ACLが効いて操作が止まることを確かめる。
- Security Centerを開く：コンプライアンススコア、Findings、Customer Actions、特権アカウント一覧を確認する。Findingから対応タスク（Security Task）への流れをたどる。
- データ分類と公開ページを確認する：データ分類のルールと、公開ポータル側のACL設定を見て、外部に出る経路が想定どおりに絞られているかを確認する。
手を動かすと、「見えないだけ」と「アクセスできない」の違いが体感で分かります。Impersonateでフォームから消えたフィールドがリストやAPIで取れてしまう状態を一度自分で再現しておくと、試験でUI PolicyとField ACLを取り違えなくなります。
まとめと、次に学ぶ範囲
ServiceNowのセキュリティは、4つの層で捉えると一気に整理できます。
- 配る（Role / Group）：権限は人ではなく役割に紐づける。Groupに Role を付け、ユーザーは所属で出し入れする
- 守る（ACL）：データはACLで守る。UI Policyの非表示は「見えない」だけで「アクセスできない」ではない
- 見える化する（Security Center）：Findingsは見るだけでなく Security Task にして追跡する。スコアではなく「リスクが下がったか」で評価する
- 分ける（Shared Responsibility）：設定・認証・データ分類・公開ページは顧客の責任。Customer Actions は顧客側のタスクとして期限で処理する
事故が起きたのは、知識がなかったからではありません。層を取り違え、見かけの安心で止まってしまったからです。設問でも実務でも、「制御しているように見える」ではなく「実際に制御している」を選ぶ——この軸を持てば、セキュリティ領域の判断はぶれなくなります。
次は、ここで整理した判断軸を設問形式で試すのが効果的です。CSAのセキュリティ領域に絞った演習で弱点を洗い出し、曖昧だった層をPDIで再確認する、という流れで進めてください。
よくある質問
Q. UI PolicyとACLは、結局どちらでフィールドを守ればいいですか？ A. データを守るのはACL（Field ACL）です。UI Policyはフォームの表示・必須・読み取り専用を制御するもので、リスト・API・レポートには効きません。「機密データを保護する」要件ならField ACLを設定します。UI Policyは、あくまで画面の使い勝手を整える目的に限定して使ってください。
Q. Security Centerのスコアを上げれば、セキュリティは良くなったと考えていいですか？ A. スコアは状態を測る目安であって、ゴールではありません。FindingsをMuteしたり評価範囲を狭めたりすればスコアは上がりますが、原因は残ったままです。Findingsを Security Task に変換して根本対応し、Customer Actions を期限で処理し、高権限・未使用アカウントを棚卸しする——「リスクが実際に下がったか」で判断してください。
Q. クラウドサービスなのに、なぜ顧客側にセキュリティ責任があるのですか？ A. Shared Responsibility Modelでは、ServiceNowがインフラ・物理・サービス可用性を担い、顧客がインスタンスのACL・認証・データ分類・ロール割り当て・公開ページ設定・Customer Actionsへの対応を担います。基盤は守られていても、設定や権限の不備による漏えいは顧客側の領域です。「有効化した＝守られた」ではない、と捉えてください。
