数千人規模でServiceNowをITSM（ITサービスマネジメント、社内のIT問い合わせや変更管理を一元的に運用する仕組み）・CMDB（構成管理データベース、保有するITシステムの構成情報を一元管理する台帳）基盤として全社導入し、年次の内部統制監査を受けている企業のシステム運用担当者は、認証設定とACL（アクセス制御リスト、誰がどのデータを操作できるかを定義する仕組み）設定が別々のスイッチであるという前提を、日々の運用でどこまで意識しているだろうか。2026年6月、ServiceNowのカスタムAPI機能であるScripted REST Resource（サーバー側スクリプトで独自のAPIエンドポイントを定義する機能）の一つで、requires_authenticationという認証必須フラグが誤ってfalseに設定され、無認証のまま顧客テナントのデータを照会できる状態が発生した[1][2]。認証さえ通していればACLがデータを守ってくれるはずだと考えていた運用担当者にとって、この事故は前提そのものを覆す。本稿は事故の技術的な仕組みと開示の経緯を整理し、自社のScripted REST Resource棚卸しの要否を判断する材料を示す。
予備知識
- ACL（アクセス制御リスト）: 誰がどのレコード・フィールドを読み書きできるかをルールで定義する仕組み。
- Scripted REST Resource（Scripted REST API）: ServiceNow上でサーバー側スクリプトを使い、独自のAPIエンドポイントを作成する機能。
- ITSM（ITサービスマネジメント）: 社内のIT問い合わせ、変更管理、インシデント対応などを一元的に運用する体制。
- CMDB（構成管理データベース）: サーバーやアプリケーションなど、ITシステムの構成情報を一元管理する台帳。
SaaS設定不備のような事故を内部統制の枠組みでどう捉え直すかを、監査担当者の視点で整理できる
ServiceNowの無認証データ露出事故で何が起きたのか
この事故は、ServiceNowのScripted REST Resourceに設定する認証必須フラグrequires_authenticationがfalseのまま公開され、外部の第三者が無認証でテナント内のデータを照会できた事案である[1][2]。対象はPOSTメソッドを持つ/api/now/related_list_editというエンドポイントで、本来は認証済みセッションを前提に動く機能だった[3][4]。この不備自体は2026年4月22日、ServiceNowのバグバウンティ制度を通じて既に報告されていた[3]。しかし実際の悪用は6月2日から始まり、特定のIPアドレス（51.159.98.241）からの機械的な照会が6月3日・4日にかけて複数の顧客テナントで観測された[1][3][4]。ServiceNowは6月5日にrequires_authenticationをtrueへ戻す修正を全ホスト環境へ適用し、影響が疑われる顧客にサポートケース経由で個別連絡した[1][3][4]。ただし技術情報を含む正式なアドバイザリKB3067321が一般公開されたのは6月9日で、パッチ適用から4日間、サポート契約のない外部組織には事故を知る手段がなかった[5]。
認証チェックとアクセス制御が別レイヤーである構造を、API設計の原則から体系的に学べる
なぜ認証を無効化しただけでデータが漏れたのか
原因は単一の設定ミスだが、被害が生じた理由は、ServiceNowの認証チェックとACLチェックが独立した別レイヤーとして動く設計にある[2]。requires_authenticationをfalseにすると、リクエストは認証を経ずにguest（未ログイン扱い）のコンテキストで処理へ進む[2]。その先で本来ACLがguestの権限を評価してデータを絞り込むはずだが、該当テーブルに対するguestの読み取り権限が結果的に十分だったため、ACL側の判定を素通りしてレコードが返された[2]。つまり認証を無効化したこと自体よりも、認証なしの状態で通過したリクエストをACLが独立して止められなかった点が本質である[2]。
| チェック層 | 目的 | 今回の状態 |
|---|---|---|
| 認証チェック（requires_authentication） | リクエスト送信者が誰かを確認する | false設定により無効化 |
| ACLチェック | 確認済みの主体が該当データを操作してよいか判定する | guestロールへの読み取り制限が不十分で通過 |
AIエージェント構築ツール「Langflow」は、LLM（大規模言語モデル）やRAG（検索拡張生成）の処理をノードとしてつなぎ、コードを書かずにAIエージェントを組み立てられるオープンソースのアプリケーション層プラットフォームである[…]
漏えいしたデータの範囲はどこまで広がったのか
確認された範囲は、ITチケットや資産情報など、ITSM運用の中核データに及んだ[1][4]。具体的には、内部URLやシステム名を含むITサポートチケット、氏名など従業員の個人情報、調査内容や対応手順を含むセキュリティインシデントの記録、ワークフローデータや資産インベントリ、スクリーンショットやログを含む添付ファイルが対象だった[1][4]。ServiceNowはIT問い合わせから資産台帳、インシデント対応記録まで一元管理する基盤であり、露出したデータの性質上、認証情報の悪用や社内ネットワークへの横展開につながりかねない[5]。影響を受けた顧客テナントの合計数についてServiceNowは公式な数値を公表しておらず、サポートケースを通じた個別通知にとどまっている[3][4]。
AWS CloudFrontに、プライベートなVPC内バックエンドを公開せずCDN配信できる「VPC Origins」という機能がある。2024年11月に登場した比較的新しい仕組みで、オリジンをインターネットに晒さずに済む点が評価されてき[…]
企業がScripted REST Resourceで今すぐ点検すべきことは何か
対応の起点は、自社インスタンス内のScripted REST Resourceを一覧化し、requires_authenticationとACLの両方を確認することである[2][3]。まず全エンドポイントのrequires_authentication設定を洗い出し、falseになっている項目があれば意図した公開かどうかを個別に判断する[3][4]。次に、認証を無効化しているエンドポイントについては、guestロールに紐づくACLが該当テーブルへの読み取りを許可していないかを点検する[2]。あわせて、設定変更を検知する仕組みがなければ、今回のような単一パラメータの変更が長期間気づかれずに残る[3][4]。ServiceNow標準の変更履歴ログや、SaaS環境の設定不備を継続的に検知する外部ツールの活用も選択肢になる[4]。
MBAファシリテーション＆ネゴシエーション講義ノート Day6/全6回（最終回） この記事でわかること 交渉の障害を3つに分類する視点（論理的構造・認知感情・環境） あるプロスポーツリーグのロックアウト――交渉が決裂に至るメカニズム […]
国内ServiceNow運用でACL設定変更の検知が手薄になりやすい理由
この種の設定ミスは、ServiceNowを使う世界中のテナントに共通して起こり得る。日本企業固有の違いは、設定変更を発見する体制の方にある。多くの国内企業はScripted REST Resourceのようなカスタム開発部分の保守をSIer（システムインテグレーター）へ委託しており、変更内容の把握が月次報告や年1回の内部統制監査のタイミングに限られやすい。継続的な設定監視の仕組みが定着していない場合、requires_authenticationのような1つのフラグの変更が次の監査まで見過ごされる。
| 観点 | 想定される差 |
|---|---|
| 発見経路 | 海外はバグバウンティやSaaSセキュリティ監視ツールが主流。国内はSIer報告と年次監査への依存が大きい |
| 変更管理 | カスタムAPIの設定変更が、保守契約の稟議フローの外で行われる余地がある |
IT部門の判断は、保守委託先にScripted REST Resourceの変更検知を契約要件として組み込むかどうかである。決裁側の判断は、年次監査の間隙を埋める継続監視への追加投資を、リスクの大きさに見合う費用として承認するかどうかである。
まとめ
ServiceNowの今回の事故は、認証設定とACL設定が独立したレイヤーであるがゆえに、片方の不備だけでデータが漏れうることを示した。IT部門の担当者がまず着手すべきは、自社インスタンス内のScripted REST Resourceを棚卸しし、requires_authenticationとACLの両方を確認する作業である。決裁側が判断すべきは、年次監査だけでは埋まらない継続監視への投資を、今回のような設定変更が数週間気づかれないリスクと比べてどう評価するかである。パッチはベンダー側で完結しても、自社が何を外部に公開しているかを把握する責任は運用側に残る。
よくある質問（FAQ）
Q1. ServiceNowの今回の事故は何が原因ですか。
A. Scripted REST Resourceのrequires_authentication設定が誤ってfalseになり、無認証のリクエストがguest権限で該当データテーブルへ到達できたことが原因である[1][2][3]。
Q2. この事故は日本企業にも関係ありますか。
A. 設定ミス自体はServiceNowを使う全テナントに起こり得るため無関係ではない。ただし国内企業はSIer保守委託や年次監査に依存しがちで、変更の発見が遅れやすい構造がある。
Q3. 自社が同じリスクを抱えていないか、どう確認すればよいですか。
A. 自社インスタンスのScripted REST Resource一覧を洗い出し、requires_authenticationがfalseの項目とそれに紐づくACLの読み取り範囲を点検するのが第一歩である[3][4]。
