台東区の障害者支援アプリに不正な管理者アカウント 委託先に求める権限の確認

外部に作らせた会員アプリでは、一般の会員が管理者の権限を持てない作りかどうかを、委託先に示してもらう必要があります。台東区は10月26日、障害者支援アプリ「ささえ～る」の運営を委託するミラボから報告があったと発表しました。だれかが管理者アカウントを不正に作り、会員の情報をダウンロードしたという内容です。

区の説明では、原因は設計の段階で想定から抜けていた不備です。発表の言葉は「アカウント登録及び権限管理の仕組みに設計段階で想定していなかった不備」。区が新規の会員登録を一時停止したことから、一般の会員登録の入り口が使われたとみられます。

本来つかないはずの管理者権限が、つながった

ミラボは10月23日、台東区に報告しました。区は不備によって不正なアカウントが作られ、「本来付与されるはずのない管理者権限を紐づけられた」結果、会員の情報がダウンロードされたと説明しています。

流出した情報はメールアドレス197件と、障害児者との関係、障害のカテゴリー。氏名や住所、電話番号は入っていません。区の発表によると、不正なアカウントは無効にして削除し、システムも修正済みです。新規の会員登録は一時停止しました。

IPAの「安全なウェブサイトの作り方」は、だれにどの操作を許すかを決める処理を認可制御と呼び、その欠落を脆弱性として扱っています。IPAが挙げる例は、ログインした利用者が他人のデータを見られてしまう型です。ただ、一般の会員に管理者の権限が付いた今回も、認可の側の不備と読めます。

197件でも、軽く見られない理由

メールアドレスが197件と聞くと、小さな事故に見えるかもしれません。しかし、一緒に流出したのは障害のカテゴリーでした。個人情報保護委員会のガイドラインでは、身体障害や知的障害、精神障害などの障害があることを特定させる情報が、要配慮個人情報にあたります。¹会社が同じ種類のデータを持っていれば、漏れたおそれがあるだけで、件数にかかわらず個人情報保護委員会に報告しなければなりません。²

どの区分の人が、区のアプリに登録しているのか。メールアドレスとその区分が結びついたまま渡ったなら、手当や福祉サービスの手続きを口実に、相手に合わせて区を装うメールを作れます。区が利用者に、区やサービスの運用会社を装うメールへの注意を呼びかけた理由も、ここにあるのでしょう。

一方で、不正なアカウントがいつ作られ、何回ダウンロードされたのか、ミラボがどう気づいたのかは、発表に書かれていません。ミラボのお知らせ欄にも、11月8日の時点で本件の掲載はありません。

同じ製品を使うほかの自治体にも関係する

ささえ～るはミラボの「障害者支援アプリ」をもとに、台東区向けに作ったアプリです。ミラボが2025年4月に台東区での提供開始を知らせた発表には、港区や茅ヶ崎市、江戸川区など8つの自治体が導入事例として並んでいました。2026年2月には丹波市と宮古市でも提供が始まり、台東区を入れると少なくとも11の自治体になります。

ブラウザー版の入り口からも、分かることがありました。ミラボの発表に載っている入り口は、11の自治体とも「lg-pwd.jp」のドメインで、末尾の自治体コードだけが違います。

アカウントを登録して権限を付ける仕組みが製品で共通なら、ほかの自治体の会員も、同じ不備の上にいたことになります。しかし、台東区の発表もミラボの製品の案内も、この点にはふれていません。同じ製品を導入している自治体にとって、自分の会員が対象外だったかは、委託先から文書で答えをもらうまで分かりません。

自治体の外にも、似た立場の会社は多いはずです。会員登録と管理画面を持つアプリを委託先のパッケージで作っている会社は、同じ問いを抱えます。10月のバイトルの件で、ディップも原因を「システムの一部機能における仕様の不備」としていました。どの機能のどんな不備かは、どちらの発表からも読み取れません。

委託先に示してもらう、権限の確認の手順

1. 同じ製品やパッケージを使っているなら、委託先に、今回の不備が自分の環境にもあったか、自分の会員データが取られていないかを文書で問い合わせます。
2. 管理者アカウントを一覧にして委託先から出してもらい、作った覚えのないアカウントがないかを見ます。定例の会議で毎月の議題にしておけば、忘れません。
3. 管理画面からの書き出しについて、だれが、いつ、何件出したかの記録が残るかを確認します。残らない作りなら、次の改修の候補です。
4. 委託先の了承を得たうえで、検証環境で一般の会員として登録し、管理者だけの画面や機能を呼び出せないか、登録や変更のリクエストに権限の項目を足して送っても管理者にならないかを試します。共通の製品で試せないときは、第三者による脆弱性診断の結果を出してもらい、権限昇格の項目が入っているかを見ます。
5. 次の仕様書には、利用者の種類ごとに許す操作の表を出してもらうことと、その表どおりに動くかを受け入れの試験で示してもらうことを盛り込みます。

「想定していなかった」を、仕様書の中に入れる

設計段階で想定していなかったという言い方は正直な説明だと思います。区が新規の会員登録を止めたことから見て、想定の外にあったのは、一般の登録者が管理者の権限に届く場面だったのでしょう。攻撃する側なら、真っ先に試す場面です。

発注する側なら、その場面を仕様書と受け入れの試験に書き込めます。権限の表は、たとえば次のような1枚です。中身は一例で、だれに何を許すかは自治体や会社ごとに決めます。

受け入れの試験では、「できない」の欄を一つずつ試した結果を、委託先に出してもらいます。一般の会員の画面から管理者を追加できないことも、その結果を見れば分かるはずです。地味な作業ですが、委託先の設計を外から確かめられる、数少ない手段です。