無防備なのがバレやすくなっただけ。当たり前をやらない実態が露呈した結果という件。｜エスキューヴ・パブリッシング

議題

昨今、システム障害や情報漏洩のニュースが頻発しています。

そして、よく聞くようになったのが、

「AIによってサイバー攻撃がさらに脅威になっている」

という話です。

もちろん、AIによって攻撃の速度や精度が上がり、これまで以上に警戒しなければならないことは間違いありません。

しかし、最近の情報漏洩事故を一つひとつ見ていくと、別の側面も見えてきます。

AIが登場したから突然危険になったのではなく、これまで「当たり前にやるべきだったこと」をやっていなかった事実が、攻撃によって露呈しているだけではないか。

私は、ここをきちんと見なければならないと思っています。

根本原因が何なのかを確認せず、

「サイバー攻撃が怖い」
「AIが危険だ」

と騒ぐだけでは、本当の改善にはつながりません。

家に例えてみると、とても単純な話です

「当たり前のセキュリティ対策をしていなかった」という話を、家に置き換えてみます。

「鍵をかけずに出かけた」
「電気・ガス・水道・ネットの故障を放置した」
「壁や窓に穴が空いているのに、そのまま放置した」

そうです。

泥棒に入られてもおかしくない状態だった。

ということです。

これは自然界でも同じです。

ライオンなどの肉食獣がいるサファリパークを、無防備な状態で見学する人はいません。

危険が存在することを前提に、車両、防御、経路、ルールなどを準備したうえで安全に回ります。

植物の世界でも同じです。

乾燥と高温が続く環境で、水や湿度管理をせず植物を弱らせれば、ハダニなどの害虫被害を受けやすくなります。

つまり、

脅威が存在すること自体が問題なのではありません。
脅威が存在することを知りながら、防御をしないことが問題なのです。

デジタルの世界には以前からハッカーが存在しています。

そこに、より高速に考え、探し、試すことのできる「AIという新しい肉食獣」が加わった。

私は、現在の状況をそのように捉えています。

では、最近の情報漏洩では何が起きているのか？

最近公表された国内の情報漏洩・不正アクセス事例について、

何が起きたのか
公表されている原因
技術的に考えられる原因仮説
何をしていなかった可能性があるのか
どこに根本原因があった可能性があるのか

という観点で整理してみます。

※「原因仮説」は各社が公表した確定情報ではありません。公表内容から技術的に考えられる可能性を整理したものです。

分類	企業・サービス	公表事実	公表されている原因	原因仮説（非公式）	何をしていなかった？	根本原因仮説	リンク
アップデート／開発実装	タイムズカー	約662万件の会員情報等を外部送信。本人確認書類画像にもアクセス・送信	Webシステムに存在した脆弱性を悪用され侵入。DB・ファイル領域までアクセス	脆弱性が事前診断・更新・レビューで発見または防止できた種類だった可能性	脆弱性診断、継続的な脆弱性管理、同一構成システム点検	開発・保守会社が脆弱性管理を継続的に実施・提案していなかった可能性。ただし発注側が対応を見送った可能性も残る	公式情報
開発実装／権限管理	skyticket	約1,464万件。うち約413万件にハッシュ化PWを含む	一部管理機能を不正操作され、他サーバー・クラウドへ横展開。別経路では業務管理システムの脆弱性も悪用	管理画面の認可・権限分離・ネットワーク分離が弱く、一つの突破から広範囲へ到達できた可能性	管理機能保護、最小権限、横展開防止、脆弱性管理	開発・インフラ設計側で「侵入されても広げない」設計が不足していた可能性	公式情報
開発実装	ソースネクスト	最大22,519,960件の会員情報が流出した可能性	会員情報取得APIを第三者が不正利用	APIが大量の会員情報を取得できる設計で、認証・認可・レート制御・異常検知のいずれかが不足していた可能性	API認証・認可、レート制限、大量取得検知、アクセス制限	開発会社側のAPI安全設計・レビュー不足の可能性が高い	公式情報
アップデート／開発実装	ユミルリンク Cuenote FC	49システム、延べ約5,163万件の情報流出	ライブラリの脆弱性。認証情報取得、不正プログラム設置、DB出力、セッション情報取得、他システムへの横展開も確認	依存ライブラリの脆弱性管理に加え、認証情報・セッション・システム間分離にも複合的な弱点があった可能性	ライブラリ監視、パッチ適用、認証情報分離、セッション保護、ネットワーク分離	開発・保守側の依存関係管理と多層防御の不足可能性が高い	公式情報
安全性／監視	佐川急便	お荷物問い合わせサービスから送り主・届け先等の個人情報が流出した可能性	第三者による不正アクセス。具体的侵入原因は現在も調査中	再発防止としてシステム構成、アクセス制御、脆弱性管理、権限管理、監視を見直しているため、このいずれかまたは複合要因の可能性	アクセス制御、脆弱性管理、権限管理、監視・検知	原因確定前のため開発側／発注側を断定不可。保守・運用設計全体の管理不足の可能性	公式情報
開発実装／監視	焼肉きんぐ公式アプリ	アプリ会員管理システムへの不正アクセス・個人情報漏えい	外部第三者による断続的な攻撃。具体的侵入口は未公表	アプリのAPI、バックエンド、認証・認可、Web脆弱性などが候補。ただし特定できる根拠はまだない	アプリ／API診断、WAF、認可、異常アクセス監視	原因未確定。開発実装または監視運用のどちらか、もしくは複合	公式情報
開発実装／監視	バーガーキング公式アプリ	公式アプリ会員情報の漏えいを公表	不正アクセス。具体的な侵入経路・脆弱性は現時点で詳細非公表	大規模会員DBへ到達していることから、Web／API／認可／アクセス制御等が候補。ただし技術原因はまだ断定不可	API・Web診断、権限分離、大量アクセス検知	原因未確定。開発設計または運用監視上の弱点が存在した可能性	公式情報
安全性／データアクセス	ヤマト運輸・クロネコ代金後払い	利用者の氏名、住所、電話、メール、商品明細等が漏えいした可能性	外部からの不正アクセス。具体的侵入経路は調査中	外部公開サービスの脆弱性、認証・認可、アクセス制御等が候補。ただし未確定	Web診断、アクセス制御、DB権限制御、監視	原因未確定。開発・保守側の技術要因か、運用管理要因かは現時点では分けられない	公式情報
安全性／認証	CAPCOM ID	約1,177万件のメールアドレス等が漏えい。196件ではPWが不正変更	CAPCOM IDへの不正アクセス。具体的な攻撃手段は調査中	PW変更機能またはアカウント操作系の認証・セッション・認可周辺まで攻撃者が到達した可能性	認証・PW変更保護、セッション管理、異常操作検知	開発実装または認証運用のいずれかに突破可能な経路が存在した可能性	公式情報
外部サービス／委託先管理	第一興商	約872万件の顧客情報が漏えいした可能性	委託先社員PCがマルウェア感染。当該PCに第一興商の個人データを一時保存	大量の個人データを従業員端末へ一時保存できた点、端末保護・DLP・データ取扱ルールに改善余地があった可能性	個人情報の端末保存禁止・制限、EDR、DLP、委託先監査	委託先側の端末・データ管理＋発注元側の委託先統制双方の問題である可能性	公式情報
外部サービス管理	ソースネクスト等／Cuenote FC利用企業	Cuenote FC事件により複数企業の顧客メールアドレス等にも影響	SaaS提供元ユミルリンクの脆弱性を起点とする事故	発注企業自身が直接防ぐことは難しい。一方、「委託先が侵害された場合にどこまで自社情報が漏れるか」の設計は可能	委託先評価、預託データ最小化、データ分類、契約・監査	直接原因はサービス提供会社。発注企業側には第三者リスク管理の責任が残る	公式情報

この事例から何を学ぶべきなのか

企業から、侵入経路や技術的な根本原因のすべてが詳細に公開されることは多くありません。

そのため、原因が確定していない企業について、外部から「これが原因だった」と断定することはできません。

しかし、公表されている事実だけを見ても、非常に重要なことが分かります。

問題になっている項目の多くが、「やった方がよい対策」ではなく、本来MUSTで実施すべき基本的なセキュリティ対策である。

例えば、

脆弱性を定期的に確認する
OS・ライブラリ・フレームワークを更新する
APIの認証・認可を適切に設計する
管理者権限を必要最低限にする
一つのサーバーが突破されても横展開できないようにする
異常なアクセスを監視する
個人情報を必要以上に保持・共有しない
委託先のセキュリティも確認する

こうした内容は、決して最新の特殊なセキュリティ技術ではありません。

昔から言われ続けている、基本的な安全対策です。

発注側がやるべきこと

まず、発注する企業側が理解しなければならないことがあります。

「お金をケチるために、大切なセキュリティ対策の工数を削らない。」

「納期を縮めることばかりに集中して、大切なセキュリティ対策の工数を削らない。」

セキュリティ対策は、売上を直接生む機能ではありません。

そのため、見積りを見ると、

「ここは削れないの？」
「もっと早くリリースできないの？」

となりやすい部分です。

しかし、その数十万円、数百万円、数週間を削った結果として、数百万人、数千万人の情報が漏洩する可能性があります。

サービスを世の中へ提供する以上、安全性は追加オプションではありません。

開発側がやるべきこと

一方で、開発会社側にも重要な責任があります。

「リスクと脅威に鈍感にならないこと。」

発注元から言われなかったから実装しなかった。

予算に入っていなかったから提案しなかった。

今動いているからアップデートしなかった。

これでは、安全なサービスを作っているとは言えません。

専門家である開発会社だからこそ、発注元が気付いていないリスクを見つけ、

「これは実装した方がよい」ではなく、「これは実装しなければならない」

と伝える必要があります。

サービスは「完成」したら終わりではない

システム開発では、サービスを公開すると一つの大きな区切りになります。

しかし、本当の意味では、そこがスタートです。

OSは更新されます。

PHPやNode.jsも更新されます。

ライブラリも更新されます。

新しい脆弱性も発見されます。

攻撃方法も変わります。

そして今後は、AIによってその速度がさらに上がっていくでしょう。

サービスを作り終えることが目的なのではありません。

サービスが永続的に、安心・安全に使い続けられる状態を維持することまで含めて「開発」なのです。

結論

AIという新しい脅威が登場したからこそ、今まで以上にセキュリティは重要になります。

しかし、その前に確認すべきことがあります。

当たり前のことを、当たり前にやっているか。

鍵をかける。

壊れた場所を直す。

穴が開いたら塞ぐ。

侵入されたらすぐに気付けるようにする。

そして、新しい危険が現れたら、それに合わせて防御方法を更新する。

デジタルの世界でも、本質は同じです。

発注側は、セキュリティを予算・納期調整の犠牲にしない。

開発側は、専門家としてリスクを見つけ、必要な対策を強く提案する。

この当たり前を徹底すること。

高度なサイバー攻撃への対策を考えるのは、まずそこからではないでしょうか。

議題