発生時期2022年9月
種別API(システム連携の窓口)の設定不備による情報漏洩
対象組織Optus(オプタス/オーストラリア第2位の通信大手)
被害規模現・元利用者最大約1,000万人分(豪州人口の約3分の1)の個人情報が流出。氏名・生年月日・住所・電話番号・メールに加え、パスポート番号・運転免許証番号まで含まれた
主な手口外部システムとデータをやり取りするための「API」が、認証なしで誰でもアクセスできる状態で公開されていた。高度なハッキングではなく、この設定の穴を突いてデータが抜き取られた
API不備による情報漏洩
1外部API連携の不備弱点2大量データを取得窃取3最大1,000万人分被害4API設計の重要性教訓
  1. 1外部API連携の不備:認証なしのAPI
  2. 2大量データを取得:本人確認番号まで流出
  3. 3最大1,000万人分:人口の1/3規模
  4. 4API設計の重要性:認証・アクセス制御を

1. 事件の概要

2022年9月、オーストラリアの通信大手Optusで、現・元利用者最大約1,000万人分という、同国人口の約3分の1に相当する規模の個人情報が流出しました。しかも、流出した情報には氏名や連絡先だけでなく、パスポート番号や運転免許証番号といった、本人確認に使われる重要な番号まで含まれていました。

この事件で衝撃的だったのは、原因が「高度なサイバー攻撃」ではなかったことです。Optusの内部関係者や豪州政府によれば、外部システムとデータをやり取りするための「API(エーピーアイ/システム連携の窓口)」が、認証(本人確認)なしで、誰でもアクセスできる状態で公開されてしまっていました。攻撃者はその「開けっ放しの窓口」からデータを抜き取っただけ。人為的な設定ミスが、国家的な規模の漏洩を招いたのです。

APIとは、システム同士がデータをやり取りするための「窓口」です。現代のWebサービスやアプリは、この窓口を無数に使って動いています。便利な反面、「窓口に鍵をかけ忘れる(認証を設定し忘れる)」と、そこから大量のデータが漏れます。この事件は、開発・運用の“うっかり”が招くリスクの典型です。

2. 被害の内容と規模

図1:被害の規模
最大約1,000万人分
流出した現・元利用者の情報
約3分の1
豪州の人口に対する被害者の割合
パスポート・免許証
含まれていた身分証明書の番号

身分証明書の番号まで流出したため、多くの利用者が免許証やパスポートの再発行を迫られる事態になりました。

流出した情報

社会的な影響

パスポートや免許証の番号は、なりすましや不正な本人確認に悪用される恐れがあるため、豪州では身分証明書の再発行が大規模に必要になりました。Optusは対応費用として多額の引当金を計上し、社会的な信用も大きく損ないました。この事件は豪州で、個人情報保護のルール強化を後押しする契機にもなりました。

氏名や連絡先の漏洩も問題ですが、パスポート・免許証・マイナンバーのような「本人確認に使う番号」の漏洩は、より深刻です。これらは変更が難しく、なりすましに直結するため、被害が長期化します。こうした番号は特に厳重に守る必要があります。

3. 原因と手口

図2:認証のないAPIから情報が抜かれた流れ
1 🚪

認証なしで公開

外部とデータをやり取りするAPIが、本人確認なしで誰でもアクセスできる状態だった

2 🔢

番号を順に指定できた

利用者を番号で順番に指定して情報を取り出せる作りになっていた

3 🤖

機械的に大量取得

番号を次々に変えるだけで、高度な技術なしに大量の情報を抜き取れた

4 🪪

身分証番号まで流出

氏名・住所に加え、パスポート番号・運転免許証番号まで含まれていた

数年前の開発ミスが「直したつもりで直っていない」まま放置されていました。サービスは正常に動いて見えるため、設定ミスは気づきにくいのです。

「認証のない窓口」が公開されていた

報道によれば、問題のAPIは、本来なら認証(アクセスできる人を確認する仕組み)が必要なのに、それがないまま、外部からアクセスできる状態で公開されていました。さらに、そのAPIは個人を順番に指定して情報を取り出せる作りになっており、攻撃者は番号を次々に変えるだけで、大量の利用者情報を機械的に抜き取れてしまいました。

背景:過去の“やり残し”

報道では、この問題のある設定は数年前の開発時のミスに端を発し、一部は修正されたものの、APIの側だけ修正が漏れて放置されていたとされます。「直したつもりで直っていなかった」——設定ミスが長期間気づかれないまま残っていた点は、トヨタのクラウド設定ミスとも共通します。

APIやクラウドの設定ミスは、「攻撃されなくても、こちらのミスで情報が漏れる」タイプのリスクです。しかも、サービスは正常に動いて見えるため気づきにくい。開発・運用では、「この窓口に、本当に認証がかかっているか」を必ず確認することが欠かせません。

4. 対策と教訓

自社でWebサービスやアプリを開発・運用している、あるいは外部に開発を委託している中小企業に関わる教訓です。

企業がとるべき対策

この事件の教訓は、「攻撃を防ぐ以前に、自分で“窓口の鍵”を閉め忘れない」ことです。自社サイトやアプリを持つなら、「外から見える入口に認証がかかっているか」を一度点検してください。外注している場合も、丸投げにせず、セキュリティ設定を確認することが大切です。

5. まとめ

Optusの事件は、高度な攻撃ではなく、認証のないAPI(窓口)という設定の穴から、約1000万人分・パスポート番号まで流出した出来事でした。教訓は——連携の窓口に必ず認証、公開入口の棚卸し、大量取得の制限、開発の“やり残し”点検。攻撃対策の前に、まず「自分で開けっ放しにしていないか」を確認することが、確実な守りになります。

※本記事は報道・公表資料など一般に公開された情報をもとに、教育・啓発を目的として再構成したものです。原因や被害規模は公表・報道時点のもので、見解が分かれる部分もあります。正確な情報は公式発表をご確認ください。