個人情報保護委員会の指導事例に出てくる、推測されやすいパスワードと委託先のアカウント
令和 6 年度第 1 四半期の指導 110 件の概要には、事業名を使った簡単なパスワード、4 桁の管理者パスワード、初期設定のままの ID が原因とされた事案が並びます。委託先の監督の不備も 8 件ありました。
個人情報保護委員会は、四半期ごとに「監視・監督権限の行使状況の概要」を公表し、指導した事案を社名を伏せて載せます。令和 6 年 8 月 28 日公表の令和 6 年度第 1 四半期分には、パスワードと委託先のアカウントに関わる事案が繰り返し出てきます。同じ型が何度も指導されている資料です。
何が起きたか
この四半期の指導・助言は 142 件で、うち民間事業者が 110 件、行政機関等が 32 件です。民間事業者への指導は、不正アクセスを原因とする漏えいが中心でした。委員会は原因の傾向を 3 つにまとめています。直し方が出ていた欠陥の放置、推測されやすい ID・パスワード、設定ミスでデータベースが外から見える状態になっていたことです。
指導の内容のうち関係の深いものは次のとおりです(1 事案が複数に当たることがあります)。
| 指導の内容 | 件数 |
|---|---|
| 外部からの不正アクセス等の防止の不備 | 44 |
| 委託先に対する監督の不備 | 8 |
| アクセス制御の不備 | 5 |
| アクセス者の識別と認証の不備 | 3 |
パスワードが原因とされた事案
概要に載った事案のうち、パスワードの状態が原因と考えられるとされたものを並べます。番号は概要の事案番号です。
- 事案 14: サーバーの管理者権限のアカウントが複数あり、一部のパスワードが 4 桁だった。
- 事案 18: 写真アプリの利用者アカウントにリスト型攻撃(他のサービスから流出した ID・パスワードで試す攻撃)。利用者のパスワードの使い回し。
- 事案 26〜28: 委託先が管理するアカウントのパスワードが、その事業の名称を使った簡単な文字列だった。
- 事案 31・32: 委託先の仮想専用サーバー(1 台のサーバーを分けて借りるサーバー)で、ファイアウォール(外からの通信を選んで止める仕組み)と ID・パスワードが初期設定のまま。総当たり攻撃(文字の組み合わせを片端から試す攻撃)で突破された。
- 事案 38: VPN 機器(外から社内につなぐための機器)とサーバー管理者アカウントのパスワードが推測しやすく、設定後に変更されていなかった。
- 事案 47: 自治体の委託先のメールアカウントのパスワードが、容易に推測できるものだった。
- 事案 55・56: 管理者アカウントの ID とパスワードが同じ 5 文字・6 文字で、容易に推測できた。
- 事案 61: メール管理システムの管理者アカウントの ID・パスワードを長期間変えておらず、強度にも問題があった。
事案 41 は経路が複雑です。業務委託先 2 社のメールサービスが不正アクセスを受け、そこから委託元の委託先用 VPN のパスワードが盗まれました。さらに、委託元が委託先に配っていた社内システム用のアカウントが悪用されました。原因は、VPN と社内システムで多要素認証(2 つ以上の方法でログインを確かめる仕組み)と接続元の制限が不十分だったこととされています。
委託元に対する指導
委託先のアカウントが原因の事案では、委託元も指導を受けています。事案 26〜28 では、適切な委託先の選定、委託契約の締結、委託先での個人データの取扱状況の把握が不十分で、委託先に対する監督に不備があったとされました。事案 31 でも、契約の締結と取扱状況の把握の不十分さが指摘されています。委託先のパスワードが弱かったこと自体は委託先の問題ですが、確かめていなかったことが委託元の問題として扱われています。
同じ型の事故で一般に問われる管理
個人情報保護委員会のガイドライン(通則編)は、個人情報保護法 25 条の委託先の監督について、委託元が行う措置を 3 つ挙げています。適切な委託先の選定、委託契約の締結、委託先における個人データの取扱状況の把握です。選定では、別添の安全管理措置(個人データを守るための対策)が業務に沿って行われることを「あらかじめ確認しなければならない」(委託先が本当にやっているかを、任せる前に確かめる)としています。上の事案で「不十分」とされたのは、この 3 点です。
IPA の「中小企業の情報セキュリティ対策ガイドライン」第 4.0 版の対策例のうち、この事案に関わる 3 つを挙げます。初期設定のパスワードを変更すること。パスワードは 10 文字以上でできるだけ長くし、名前・電話番号・誕生日・簡単な英単語を使わず、推測できないようにすること。従業員の異動や退職時には、速やかに設定を変更・削除することです。
米国 NIST の SP 800-63B(ログインの本人確認についての基準)第 4 版は、サービス側にパスワードを一覧と照合するよう求めています。その一覧に、サービスの名前や利用者名とその変形を入れることも、基準は例として挙げています。事業名を使ったパスワードは、この例に当てはまります。詳細はパスワードの使い回しで法人向けサービスの管理画面に不正ログインされた事案にあります。
自分の現場を点検する問い
- 委託先に渡したアカウントのパスワードを誰が決め、初期設定のまま使われていないかを確かめたか。
- 会社名や事業名、サービス名を含むパスワードが、管理者用のアカウントに残っていないか。
- 委託契約に、アカウントの扱いと取扱状況の報告を入れているか。契約後に確かめる機会があるか。
- 委託先が使う VPN や社内システムのアカウントに、2 つ目の確認や接続元の制限があるか。
- 管理者用のアカウントのパスワードを、設定してから一度も変えていないものはないか。
よくある質問
委託先のパスワードが弱くて漏えいしたら委託元の責任ですか
概要では、委託先のアカウントが原因の事案で、委託元も選定・契約・取扱状況の把握の不十分さから、委託先の監督の不備を指導されています。責任の範囲は契約と法令によります。
個人情報保護委員会の指導事例はどこで読めますか
委員会のサイトに、四半期ごとの「監視・監督権限の行使状況の概要」が PDF で載っています。社名は伏せられ、事案の概要と指導事項が表になっています。
どんなパスワードが推測されやすいとされていますか
概要にあるのは、4 桁、ID と同じ 5〜6 文字、事業名を使った文字列、初期設定のままのものです。NIST は、サービス名や利用者名を含むものを、照合する一覧に入れる例として挙げています。
Junify の場合
- 人手で続けると
- 同じ型の事故を避けるなら、退職や契約終了のたびにその人が使えた ID をすべて止め、共有のパスワードを配り直し、記録を点検する人を決めて回し続けることになります。
- Junify なら
- 委託先が決めた簡単なパスワードや、初期設定のままのパスワードが自社のアカウントに残ることは、Junify では起きません。決めるのは委託元の管理者で、委託先の担当者には渡らず、見ないまま使います。誰がいつ使ったかは担当者ごとに残り、契約が終われば割り当てを外すだけです。サーバーの公開設定は Junify の外です。
参考資料
- 個人情報保護委員会「令和6年度第1四半期における監視・監督権限の行使状況の概要」(令和 6 年 8 月 28 日)
- 個人情報保護委員会「個人情報の保護に関する法律についてのガイドライン(通則編)」(令和 8 年 6 月一部改正)
- IPA「中小企業の情報セキュリティ対策ガイドライン」第 4.0 版(2026 年 3 月)
- NIST Special Publication 800-63B Revision 4「Digital Identity Guidelines: Authentication and Authenticator Management」
同じテーマの記事
-
退職を申し出てから退職日までに技術情報を持ち出された事案から分かる、退職予定者の権限の扱い
秘密保持契約を結んでいた元社員が、退職を申し出てから退職するまでの間に営業秘密に当たる技術情報を持ち出したとして逮捕されました。会社は再発防止策に、退職予定者のアクセス権限の停止・制限の強化を挙げています。
-
代行会社の Google アカウントへの不正アクセスで公式 X と YouTube が乗っ取られた事案
代行会社が使用・管理する Google アカウントへの不正アクセスをきっかけに、公式 X で無関係な投稿が、YouTube でチャンネル名の変更や動画の削除が行われました。
-
委託先のパソコンの感染が社内システムへの侵入につながった事案から分かる、ログインの仕組みの共有
委託先の従業者のパソコンが悪意のあるプログラムに感染し、関係会社と共通のログインの仕組みでつながっていた社内システムに侵入されました。ユーザー・取引先・従業者の情報 44 万件が漏えいしました。委託先と何を共有しているかが問われました。