コンテンツにスキップ
← インシデント一覧に戻る

東京都、看護師等修学資金の事務システムで閲覧権限の設定不備 — 120校が他施設の被貸与者437人分を閲覧可能な状態

項目内容
発生日2026年4月20日9時〜5月1日20時ごろ(閲覧可能だった期間)
対象組織・業界東京都保健医療局(看護師等修学資金貸与事務システム)
攻撃手法攻撃なし。システムの閲覧権限設定の誤り
情報源Security NEXT(2026年6月10日) / 東京都保健医療局 報道発表(2026年5月27日)

東京都は、看護師等養成施設の事務担当者が利用する看護師等修学資金貸与事務システムにおいて、閲覧権限を持たない施設の個人情報が閲覧できる状態になっていたことを公表しました。

システムは2026年4月20日に運用を開始しましたが、特定の操作を行うと、本来は権限のない他施設分の情報にアクセスできる設定になっていました。対象は指定施設120校にわたり、被貸与者437人(氏名、住所、電話番号、貸与金額など)と連帯保証人128人(氏名、住所、電話番号など)の情報が閲覧可能な状態にありました。

閲覧可能だった期間は2026年4月20日9時から5月1日20時ごろまで。施設からの指摘により判明し、東京都はシステムログから実際の閲覧状況を確認したうえで、実際に閲覧したのは3施設の4人と特定しています。外部への情報漏えいはないとしています。

  • 2026年4月20日9時: 看護師等修学資金貸与事務システムの運用を開始。この時点で、特定の操作により権限外の他施設情報が閲覧できる設定になっていた
  • 2026年5月1日: 利用施設からの指摘により、権限設定の不備が判明
  • 2026年5月1日20時ごろ: 閲覧可能な状態を解消
  • システムログを調査し、実際に権限外の情報を閲覧したのは3施設4人であることを確認。外部への漏えいはないと判断
  • 対象施設・被貸与者・連帯保証人に対して説明と謝罪を実施
  • 2026年5月27日: 東京都保健医療局が報道発表
  • 2026年6月10日: 事案が報じられる

システムの閲覧権限設定の誤りです。東京都は「特定の端末操作を行うと、本来は閲覧権限のない他施設分の個人情報が閲覧できる設定になっていた」と説明しています。

注目すべきは、運用開始初日(4月20日)から不備が存在していたという点です。つまりこれは運用中の設定変更による事故ではなく、リリース前のテストで検出されるべき不備が、本番稼働まで通過した事案です。

考えられる原因(推測): 施設ごとにデータを分離するマルチテナント型の業務システムでは、権限制御の実装に典型的な落とし穴があります。(a) 画面の一覧表示には施設IDによる絞り込みが実装されているが、詳細画面や検索機能、帳票出力といった別の経路で絞り込み条件が適用されていない、(b) URLパラメータやリクエストの値を変更すると他施設のデータが取得できる(アクセス制御がサーバ側で検証されていない)、(c) 特定の操作順序を経たときにセッション上の施設情報が引き継がれず、絞り込みが外れる、といったものです。

「特定の操作を行うと」という表現は、通常の画面遷移では再現せず、ある特定の経路でのみ発生することを示唆します。この性質は、正常系のテストシナリオでは検出されにくく、権限マトリクスを網羅した異常系テスト(「他施設のIDを指定したときに拒否されるか」を全機能で確認する)を実施しないと漏れる類型です。

1. 権限のテストは「見えるか」ではなく「見えないか」を確認する作業である

Section titled “1. 権限のテストは「見えるか」ではなく「見えないか」を確認する作業である”

業務システムの受入テストは、通常「必要な情報が正しく表示されるか」を確認します。しかし権限制御のテストは逆で、「見えてはいけないものが見えないこと」を全機能・全経路で確認する必要があります。この確認は、テストケース数が機能数×権限パターン数で増えるため省略されやすく、しかも省略しても正常系のテストはすべて通ります。リリース判定のチェックリストに「他施設のデータを指定した場合の拒否確認を、一覧・詳細・検索・帳票出力の各機能で実施した」という項目があったかどうかが、本件の分岐点です。

2. 「特定の操作」の存在は、設計と実装のずれを示す

Section titled “2. 「特定の操作」の存在は、設計と実装のずれを示す”

権限制御が画面単位で実装され、データアクセス層で一元的に強制されていない構成では、機能追加のたびに絞り込み漏れのリスクが生じます。施設IDによる絞り込みを、個々の画面ロジックではなくデータアクセスの共通層で強制する設計にしておけば、「特定の操作でだけ漏れる」という状態は原理的に発生しにくくなります。これは事故対応ではなくアーキテクチャの選択の問題です。

3. ログがあったから「4人」と言えた

Section titled “3. ログがあったから「4人」と言えた”

東京都は、対象となりうる範囲(120校・被貸与者437人・連帯保証人128人)と、実際に閲覧された範囲(3施設4人)を区別して公表しています。この区別ができたのは、システムログから閲覧状況を確認できたためです。もしアクセスログが十分な粒度で残っていなければ、東京都は「120校が437人分を閲覧できる状態でした」という最大範囲の説明しかできず、437人全員に対して「あなたの情報が第三者に見られた可能性があります」と通知することになりました。ログの粒度が、通知の広さと、対象者が受ける不安の量を決めています。

4. 発覚が「利用者からの指摘」だったこと

Section titled “4. 発覚が「利用者からの指摘」だったこと”

不備の判明は施設からの指摘によるものでした。運用開始から11日間、都の側では検知されていません。権限外のデータにアクセスされた記録はログに残っていたにもかかわらず、それを能動的に見る仕組みがなかったことになります。「施設Aの利用者が施設Bのデータを参照した」という論理的にありえないアクセスは、機械的に検出できる異常です。ここが自動で拾えていれば、11日ではなく初日〜数日で気づけた可能性があります。

5. 対象が「被貸与者」と「連帯保証人」であることの意味

Section titled “5. 対象が「被貸与者」と「連帯保証人」であることの意味”

修学資金の貸与情報は、氏名・住所・電話番号に加えて貸与金額を含みます。これは経済状況に関わる情報です。さらに連帯保証人128人は、当人が制度の当事者ではなく、被貸与者との関係を通じて情報が登録されている立場です。本人が漏えいリスクを認識する機会がないまま情報が扱われている層であり、通知・説明の設計では特に配慮が求められます。東京都が連帯保証人にも説明と謝罪を実施した点は妥当な判断です。

ヤグラの視点 — 攻撃者のいないインシデント:権限設定の誤りは、防御製品のどのアラートにも乗らない

Section titled “ヤグラの視点 — 攻撃者のいないインシデント:権限設定の誤りは、防御製品のどのアラートにも乗らない”

この事案には攻撃者がいません。不正アクセスも、マルウェアも、フィッシングも発生していません。起きたのは、正規の利用者が、正規の認証を通って、正規のシステムを操作した結果、見えてはいけないデータが見えたということだけです。

だからこそ、この類型は既存のセキュリティ製品のどのアラートにも乗りません。ファイアウォールは通常の業務通信を通します。EDRは正規のブラウザ操作を止めません。WAFは正規のリクエストを攻撃と判定しません。「認証を通った人が、権限外のデータを見ている」という状態を異常だと判断できるのは、業務ロジックを知っている側だけです。

しかし、まったく検知の手がかりがないわけではありません。本件で東京都が事後に4人を特定できたのは、ログに記録が残っていたからです。つまり異常の痕跡は、発生した瞬間からログの中にありました。11日間気づかれなかったのは、痕跡がなかったからではなく、痕跡を見る仕組みがなかったからです。

「施設Aに所属するアカウントが、施設Bの被貸与者レコードを参照した」というイベントは、業務ルール上ありえない組み合わせです。この種の論理的にありえないアクセスの組み合わせは、ルールとして記述できるものもありますが、システムが増えるほど記述しきれなくなります。認証ログとアプリケーションのアクセスログを横断で集約し、平常時のアクセスパターンを学習したうえで「この組み合わせは今までなかった」と気づける状態を作ることが、現実的な検知の形になります。

自治体・公共部門では、地方公共団体情報セキュリティポリシーにおいてログの取得と定期的なレビューが求められています。しかしログを「取得すること」と、「異常を見つけられること」は別の話です。11日分・120校分のアクセスログを人間が目視でレビューして異常な組み合わせを見つけるのは、現実的な作業量ではありません。ヤグラの AI SOC は、各種システムのログを集約・変換して横断で異常検知を行い、AIエージェントが自然言語での監査・脅威ハンティングを実行できる基盤を提供します。「権限外アクセスがなかったことを毎月確認できている」状態は、事故を防ぐだけでなく、事故が起きたときに範囲を即答できる状態でもあります。

なお強調しておくべきは、本件の根本原因はリリース前の権限テストの不足であり、検知の仕組みはあくまで二段目の防御だという点です。設計と受入テストで権限制御を担保することが第一で、監視はそれをすり抜けたものを早期に拾うための備えです。順序を逆にすべきではありません。

権限設定の是正、対象者への説明・謝罪は完了しており、外部への漏えいはないと確認されています。事案としては収束段階です。監視ポイントは、①同システムの他機能における同種の権限不備の残存有無、②都の他の業務システムに対する横展開点検の実施状況、③新規システムのリリース前テストにおける権限確認手順の整備状況です。運用開始初日から不備が存在していた事案であることから、調達・受入検査のプロセス見直しが本質的な論点として残ります。

日時内容
2026-08-04アーカイブとして初稿作成(2026年6月10日報道時点)。DBの company: 個人情報が閲覧可能に(見出し断片)を主体である「東京都(保健医療局)」に修正