何が起きたか
この事故で流出した、または流出したおそれがある情報は、2025年1月6日以降のログ100万行超。対話の履歴、APIの秘密鍵、システムの内部情報、運用の記録です。その後の対応と影響は、調査会社の連絡を受け、会社はすぐに外部から接続できない状態にした。会社自身の公表文は確認できないです。
原因になったのは「認証なしでインターネットから開けるデータベース」です。生成AIで作ったもの、または生成AIの使い方が事故に関わっています。
- 中心 直接の原因報道
データベースが通常のWeb用とは別の番号(8123と9000)で外部に開いており、認証なしで操作できた。
- 1つ外側 流出した情報報道
2025年1月6日以降のログ100万行超。対話の履歴、APIの秘密鍵、システムの内部情報、運用の記録。
- いちばん外側 その後の対応と影響報道
調査会社の連絡を受け、会社はすぐに外部から接続できない状態にした。会社自身の公表文は確認できない。
なぜ起きたか
調査会社によると、会社がインターネットに出している約30の接続先を調べたところ、開発用などの接続先でデータベースの管理用の入口が開いていた。誰でもブラウザからデータベースに命令を送れる状態だった。設定がなぜそうなっていたかは公表されていない。
原因の種類は「設定ミス」です。公開範囲やアクセスの設定を誤り、外から見える状態になった事故を指します。このサイトに掲載している事故のうち、同じ種類の原因で起きた事故は13件あります。
事故が起きてから公表されるまで
- 2025年1月、生成AIの新しいモデルが話題になり、調査会社が会社の外部向け設定を調べ始めた
- 調査会社が、認証なしで操作できるデータベースを見つけた
- データベースに対話の履歴やAPIの秘密鍵を含む100万行超のログがあることを確認した
- 調査会社が会社に連絡し、会社はすぐに公開を止めた
- 1月29日、調査会社が経緯を発表した
どうすれば防げたか
上の流れでは、最初から公表まで、途中で異常に気づいて止める仕組みが働いていません。
止められた可能性がある所(当社の見立て)外部から接続できる番号とサービスを定期的に外から調べ、データベースの管理用の入口に認証と接続元の制限をかけておけば、公開状態に早く気づけた可能性がある。
この見立ては、公表された原因から当社が考えたものです。当事者の調査の結果とは異なる場合があります。
自社で確認する3つの手順
上から順に、短い時間で確認できるものを並べています。
- 自社のドメインと接続先の一覧を作り、外部から開いている番号を外から調べる
- データベースや管理画面に、認証と接続元の制限がかかっているかを確認する
- 開発用・検証用の環境が本番と同じようにインターネットに出ていないかを確認する
自社に同じ原因があるか
当てはまるものを選んでください。1つでも当てはまれば、この事故と同じ原因が自社にもある可能性があります。