IT & Information security Journal
タイムズモビリティ株式会社は9月25日、同社が運営するカーシェアリングサービス「タイムズカー」のWebシステムが第三者による不正アクセスを受けたことを公表しました 1。漏えいしたアカウント数は約660万件であり、対象には現会員のほか、退会済みの会員や、入会を申し込んだものの完了していない人も含まれるとしています 2。
また9月29日には、運転免許証や公共料金の請求書などの本人確認書類の画像が漏えいしたアカウントが約160万件にのぼることも明らかにしました 3。
会員向けサービスでは、入会時にさまざまなデータをユーザーから預かることが一般的です。こうしたデータを性質に応じてどう分け、どう守り、不要になったデータをどう消去すべきなのか。データ管理の考え方と具体策を、Webセキュリティの第一人者である徳丸 浩氏に聞きました。
この記事のポイント
収集した個人情報は、業務上の保管期限を決めて確実に廃棄することが重要。また、保管しておくだけのデータはWebサイトから安全な環境に移し、Webサイトにはサービス提供に必要最低限の情報だけを置くようにすべき
eKYC事業者をはじめとした外部に本人確認とそのデータ管理を委託する「リスク移転」という選択や、自社でデータを持たない「リスク回避」という選択も考えられる
データを消す判断には勇気が必要であり、現場任せでは「怖いから取っておく」という判断になりがち。そのため、事業部門の責任者がどんなデータを消すのかを決めたうえで、その仕組み・決まりを第三者が点検することが必要
昨今相次いでいる漏えい事案は特殊な手口によるものではなく、AIにより攻撃が「早く」「安く」なったことで狙われる範囲が広がったものと考えられる。防御のために行うべきことは変わらず、基本的な対策の徹底が重要
本件では、退会済みの方や入会手続が完了していない方の情報に加え、本人確認書類の画像も漏えいしました。サービス提供事業者がユーザーから預かったデータは、そもそもどのように扱うべきでしょうか。
前提として、現在の企業活動では、さまざまな理由から個人情報を収集するというのは普通にあることです。タイムズカーの場合は、事業やサービス提供に必要な情報を集めていたのだと思いますが、それ以外にも、たとえばキャンペーンを実施するなどして、広く個人情報を集める場合も多いと思います。そうした際に起こりがちなのが、収集した個人情報がWebサイトの環境上に残ったままになっており、現在は使わないような古い情報まで漏れてしまうというケースです。
本件で特に注目されている、運転免許証の画像などであれば、まず業務上の保管期限を決めることが重要です。タイムズカーでは、なりすまし対策や問い合わせ対応などのために、運転免許証の情報・画像を退会後も7年間保管していたといいます 4。本件については、詳細な事情が明かされていない部分もあるため、保管期間が必要以上に長かったのか、妥当だったのかは一概にはいえませんが、あるべき論としては保管期限を決め、保管期限が来たら確実に廃棄することです。
また、ユーザーから預かったデータをWebサイトの環境内に置いておくのは相当リスクが高い状態ですので、移動可能なデータは安全な場所で保管することが大切です。最近のランサムウェアの事案なども考えると絶対に安全な場所というのは難しいところですが、本当に取っておくだけでよいのであれば、オフラインで、通常はアクセスできないような環境に置くことも考えられます。それが難しい場合でも、社内ネットワークのしかるべき安全なところに保管することが推奨されます。
昨今では、クラウド環境上にWebサイトを立てることが一般的です。本件がクラウド環境において発生したのかどうかは公表されていませんが、仮にクラウド環境を使う場合、たとえばアマゾン ウェブ サービス（AWS）であればAmazon S3という有名なクラウド型のストレージサービスがあり、そこにデータを保存したくなるでしょう。しかし、これは現実には危険を伴います。できればクラウドストレージではなく、やはり社内の安全な区画でデータを保管するのがよいと思います。
クラウド型のストレージサービスの多くは暗号化の機能を提供しているため、その機能を用いてデータを暗号化しておけば大丈夫だろうと考えるかもしれません。しかし、そうした暗号化機能は、読み取り権限がある人がアクセスすると自動的に復号され、元の形で読める仕様になっています。これを透過型暗号といいます。クラウドストレージはデータを使うためのサービスなので、権限のある人がいちいち復号の操作をしなくても済むようにできているわけです。
過去に起こった事件を見てみると、暗号化はしていたけれども、攻撃者に読み取り権限を奪われて、結局元の形でデータを読まれてしまったというケースも少なくありません。そう考えると、インターネットからアクセスしやすい場所にユーザーから預かったデータを置くのは、やはり危険だといえます。
データの内容・種類によって保管場所を変えることも考えるべきでしょうか。
これはわりと単純な話で、Webサイトやサービスを運営・維持するために必要なデータは、どんなに機微な情報であっても、そこからアクセス可能な範囲に置くしかありません。金庫にしまっておくわけにはいかないのです。
そのため、あくまでサービス提供に必要なデータかどうかを基準として、Webサイト環境には必要最低限のデータを置き、単に保管しておけばよいものであれば、速やかに安全な場所に移すのがよいと判断すべきでしょう。
本人確認書類については、書類そのもののデータではなく、確認結果だけを残すといった方法も考えられるでしょうか。
そうした方法も考えられるでしょう。ただし、仮に法的な要求などで元の書類データを保管するのであれば、それは生のデータとして取っておくしかありませんので、あくまで目的次第です。
一例として、ログについて考えるとわかりやすいと思います。Webサービスでは、操作履歴などのさまざまなログを保管します。そのログに本来は記録すべきでない機微な情報が紛れ込むというのはわりとあることです。極端な話をすると、ログにクレジットカード情報が含まれていて、そこから漏えいしたという事例も実際にあります。
とはいえ、ログは誰がいつ何をしたかという履歴ですから、プライバシーの観点で機微な情報が含まれることはあり得ます。そうした場合は、ハッシュ化といって、元の形には戻せない値に変換してログに記録しておくことが考えられます。同じ情報からは同じ値が得られるので、特定のユーザーの記録かどうかを照合することはできますが、ログから元の情報そのものを読み取ることはできません。
ただし、ビジネス上のログは、誰が何をしたかまで最終的に追えないと目的を果たせません。ですから、その目的に応じて加工したり、一部をマスクしたりという形で処理を行います。こうした、用途にあわせた加工・保管の考え方は、本件の本人確認用のデータをはじめ、ログ以外の履歴を取っておく場合にも、一般論としてあてはまるものだと思います。
クレジットカード情報であれば、ECサイト事業者などはカード番号を自社で保持しないこと（非保持化）が、法令などで事実上義務付けられています。同様に、本人確認をeKYC（※）事業者などに任せ、サービス提供事業者側ではなるべくデータを持たないという選択もあり得るでしょうか。
あり得ます。情報セキュリティの基本的な考え方に「リスク移転」があります。自社では機微な情報などを持たずに外部に管理を委託することで、完全ではないにしてもリスクの何割かを外部に移し、また自社から直接は情報が漏えいしないようにするという考え方です。
また、本件の場合は難しいと思われますが、「リスク回避」の考え方のもと、そもそも機微な情報を持たずに済む方法をとるという判断もあり得ます。
いずれにしても、必要ない情報は持たない、あるいは管理を外部委託することは有用です。昨今は、多段になったサプライチェーンがサイバー攻撃で狙われることもあり、外部が安全ともなかなかいえないですが、自社で管理するのではなく専門の事業者に頼むという方法も考えるとよいでしょう。
（※）eKYC（electronic Know Your Customer）：各種サービスや取引において必要となる本人確認手続をオンラインで行う仕組み
ユーザーから機微なデータを預かって保管する場合、冒頭で伺った保管場所の観点に加えて、セキュリティ上どのような措置をとるべきでしょうか。
まずあげられるのが、暗号化です。ただし、暗号化を行ううえでは検討すべき点もあります。あるデータを取っておくのは、それを使う機会があるからです。そのため、暗号化はするけれども検索もできる必要がある、というのが要件になります。
そのため、検索等に用いる情報は維持しつつ、機微な画像データなどは暗号化する。そのうえで、鍵管理を適切に行う必要があるでしょう。
そのほか、ユーザーのデータを守るうえで押さえるべき基本的な対策はありますか。
どこに、どんなデータがあるかを台帳管理し、きちんとチェックできる状態にしなければいけません。Webシステムで用いるデータは、データベースで集中管理されており、重要な情報がどこにあるかがわかりやすいのですが、そこに思いもよらない機微な情報が含まれてしまっているケースもあり得ます。
2026年10月7日に株式会社エイチ・アイ・エスが明らかにした、海外拠点が不正アクセスを受けた事例では、侵害の事実は2025年12月11日にわかっていたものの、公表までに約10か月を要しました 5。同社は公表に時間がかかった理由として、ファイルサーバーにさまざまな内容・形式のデータが置かれていたことで、手作業を含めた調査が必要となったためとしています。
これは他の企業でも起こり得る話です。特に海外拠点で管理が行き届いていなかったりすると、重要な情報も普段の日常業務の情報もごちゃ混ぜになっているかもしれません。
そうならないよう、重要な情報の管理場所を定期的に棚卸しなどして、常に把握すること。そのうえで、データが自社の環境に入ってから、バックアップを取り、利用を終え、それを確実に廃棄するまでの、いわゆるデータライフサイクルにあわせた管理ルールを定め、定期的に点検することが大切です。
データのライフサイクルに関するルールを定めたあと、それを形骸化させずに運用し続けるためには、どんな点に注意すべきでしょうか。
これはなかなか難しいところで、私も「自分はできるのか」と言われると、結構つらいなと感じます。特に、データを消すというのはかなり勇気がいることです。「間違って余計なものを消してしまったらどうしよう」とか「一旦取っておきたい」という気持ちが湧くもので、現場担当者に任せきりにすると、「ちょっと怖いから取っておこう」という判断になりがちです。
そのため、現場担当者とは別に、運用状況を点検する担当者を定めて、第三者が定期的に監査をする必要があるでしょう。それは情報システムやセキュリティの担当者かもしれませんし、監査部門などの担当者かもしれません。企業の規模や状況によって変わると思いますが、しかるべき責任者、責任部門を決めて、半年〜1年に1回ほどのスパンで点検し、記録に残すことが重要です。
どのデータを消すべきかの判断についても、監査部門・担当者が関与すべきでしょうか。
監査部門・担当者はどのデータを消してよいかの判断はできません。ビジネスの中身を知らない人が勝手にデータを消すわけにはいきませんので、事業部門の責任者が決めるべきです。
事業部長などが、どの情報や項目を削除するかまで逐一精査するわけではないと思いますが、どんな情報を扱っているのか報告を受けて、法律をはじめとした根拠にもとづき、保管期限をたとえば「1年」「5年」などと最終的に決める役割を担うべきでしょう。本件で漏えいしたデータも、やはり事業部長レベルの人が取扱いや削除の方針を決めるべき、重要な情報だと思います。
2026年9月から10月にかけて、情報漏えいの公表が相次いでおり、JPCERT/CCやIPA、および経済産業省、金融庁、内閣官房国家サイバー統括室（NCO）などの行政機関も立て続けに注意喚起を行っています 6。こうした状況についてどう捉えていますか。
いま起こっている事案に関していえば、おそらくそれほど特別なテクニックを使った攻撃ではないと推察しています。いろいろな専門家の意見やJPCERT/CCの注意喚起の内容などを見ても、それは変わりません。ですから、被害が生じた企業においては、どこか基礎的な対策ができていなかった可能性が高いのではないかと思います。
攻撃にAIが使われていること自体はほぼ間違いないと思いますが、特殊な攻撃方法が編み出されたわけではなく、いわゆる「早く」「安く」攻撃できるようになったということではないかと思います。それによって、いままでは狙われなかったようなターゲットも標的になる可能性が高くなります。従来であれば、狙えるけれどもリターンが手間に見合わないと攻撃者が考えたようなところも、AIエージェントが自動で攻撃をするのだからやっておけ、と考えることは十分あり得るわけです。
従来から脆弱性はあったけれども表面化していなかった部分にまで攻撃者の手が回るようになり、被害につながっているということですね。
他方、防御側がとれる対策は実はあまり変わっていません。手前味噌になりますが、たとえば私の著書『体系的に学ぶ 安全なWebアプリケーションの作り方』に載っているような対策が、現実にはあまりきちんとできていなかった。それをこの機会にきちんとやるようにしましょう、というのが基本線です。そうした基本的な対策を各企業でどう具体的に進めるかが、次のステップだと思います。
タイムズカーの事案を受けてお話ししたデータ管理の方法や体制についても、インシデントが多発している最近の状況にあわせたものではなく、情報をきちんと管理するためのいろはです。ただ、被害がこれだけ立て続けに公表されているなかでは、改めて見直すべきだと思います。
（写真：岩田伸久）
UNITISは、IT・セキュリティ担当者へ、実務家・専門家による解説や他社事例等を伝えるメディアです。セキュリティ・法律の専門家による実務解説や分析、第一線の実務家による事例・ノウハウをお届けします。
Monthly Incident Report
この記事をシェアする
最新情報をフォローする