■ 1. 事案の概要と時系列
- テレビ朝日メディアプレックスの公表:
- 2026年7月3日、同社が自社サーバへの不正アクセスに関するお知らせとお詫びを公表
- 時系列:
- 4月17日、ISMS（ISO/IEC 27001）認証取得を自社サイトで公表
- 4月28日、第三者による不正アクセスを確認し、関係サーバの停止と外部ネットワーク遮断を実施
- 6月19日、個人情報を含む情報の一部が漏えいした恐れが判明
- 7月3日、公表
- 時間差の意味:
- 認証取得の公表から侵害まではわずか11日
- 発見から公表までは66日
- この時間差に今回いちばん学べるものがある
■ 2. 外部から観測できた構成
- 公開情報からの観測:
- 同社サイトはWordPressで構築されている
- 一般公開されているHTTPヘッダとHTMLの中に構成がそのまま出ていた
- curlでトップページのver=指定とwp-login.phpのServerヘッダを確認できる
- 読み取れる構成:
- WordPress 4.9.7（2018年7月リリース）
- PHP 7.1.33（2019年にサポート終了）
- Contact Form 7 5.0.3（2018年）
- OpenSSL 1.0.2k（2017年、サポート終了）
- テーマは独自製のカスタムテーマ
- 2018年で止まった時間:
- 構成のほぼ全体が2018年で時間が止まっている
- Apacheだけ比較的新しいが、クラウド側のイメージ更新でついでに上がっただけと見るのが自然
■ 3. 受託サービスとの対照
- モダンな受託サービス群:
- 動画配信サービスはCloudFrontとエッジ処理の構成で、WordPressの痕跡はまったくない
- 同社の公開事例でも疎結合CMS、コンテナ、Blue/Greenデプロイと説明されている
- 止まっていたのは自社サイトだけ:
- 客に納めるものはしっかり作られ、モダンに保たれている
- 凍結していたのは自社のコーポレートサイトのみ
- 紺屋の白袴:
- 技術力がないのではなく、優先順位の問題
- 他人の袴は仕立てるが自分は白袴のまま、という古い言葉そのもの
■ 4. 塩漬けの構造とERPの失敗
- 8年アップグレードできなかった原因:
- 原因はおそらく凝ったカスタムテーマそのもの
- デザインを作り込むほど、WordPressのコアやプラグインの標準的な挙動から離れる
- 独自PHPコードがコア関数に深く依存すると、コア更新の瞬間にサイトが壊れる
- 結果としてアップグレードできず、放置するしかなくなる
- 「動いているものに触るな」として2018年で凍結した
- ERPで繰り返されてきた失敗:
- SAPをはじめとするERPで何十年も繰り返されてきた失敗とまったく同じ構造
- 導入時、標準機能（バニラ）では業務に合わない部分を埋めるためアドオンを大量に作り込む
- 数年後のベンダーのバージョンアップ時に、そのアドオンが足枷になる
- 標準に手を入れすぎたシステムは、上げようとすると壊れる
- アップグレードの改修費が新規導入並みに膨らみ、塩漬けになる
- アドオンを抱えたまま古いバージョンで動かし続けるのが日本中のERPが陥ってきた道
- Clean Core:
- SAPがこの反省から掲げるようになった、アップグレード可能な状態を維持する設計思想
- コアには手を入れず、標準はバニラのまま保つ
- 拡張はBTPなどの外側の拡張基盤に出す
- そうすればコアはいつでも安全にアップグレードできる
- パッケージはバニラで使い、カスタマイズは外出しするという昔からの主張とも一致する
- WordPressでの相似形:
- カスタムテーマという「アドオン」がコアに絡みつき、アップグレードを止めた
- ERPほど規模が大きくないため、誰も深刻に受け止めなかっただけ
- フロントWebで代償が露呈する怖さ:
- ERPは業務システムのため、塩漬けの代償はまず社内の不便や非効率として現れる
- フロントのWebはインターネットに直接晒されている
- 同じ病でも、代償がセキュリティ侵害として外から公然と暴かれる
- Webは規模が小さいから軽く見られ、コアとの結合を安易に考えられる
- 小さいからこそ放置され、真っ先に狙われる
■ 5. ISMS認証と適用範囲
- 単純な揶揄は不正確:
- ISMSを取ったのに会社サイトが古いままと笑うのは正確ではない
- 認証の適用範囲は会社全体ではなく、テクノロジーソリューション事業本部
- 認証範囲の文言は顧客要求事項に基づくソフトウェアの設計、開発などで、対象は顧客向け業務
- 本質は運用上の隙間:
- 認証された範囲と、実際にインターネットに晒されている資産のあいだに隙間が生まれうる
- 凍結していた自社コーポレートサイトは、おそらく最初からスコープの外にいた
- 枠の外は守られない:
- 認証は枠組みであり、枠の外まで自動的に守ってくれるわけではない
- 攻撃者から見れば、認証の外側に取り残された資産こそ一番柔らかい入口
■ 6. 利益率に入っていないリスク
- コスト構造:
- 売上を生む客向けサービスには金をかけ、動画配信基盤はモダンに保たれCDNで守られている
- 直接売上を生まない自社サイトの保守は、コストとして真っ先に削られる
- 利益率を追えば自然とそうなる
- 計上されないセキュリティリスク:
- 保守を止めれば短期的には支出が減る
- 一方で「侵害される確率 × 侵害されたときの損害」という見えないコストが積み上がる
- 66日間の対応、外部専門機関の費用、公表による信用毀損は、削った保守費をおそらく大きく上回る
- 多くの組織に共通する盲点:
- リスクを利益率の計算に入れていないのは一社の問題ではない
- 目に見える支出は削れるが、目に見えないリスクは削れず後ろに溜まっていく
■ 7. 漏えいした情報の推定
- 公告の記載:
- 公告は「当社が持つ個人情報を含む情報の一部」としか書いていない
- コーポレートサイトは会員機能もECもない、問い合わせ、採用、資料請求中心のB2Bサイト
- 大量の個人情報が集まる構造ではない
- 受託サービスへの波及:
- 動画配信サービス等の運用受託先は別ドメイン、別インフラで物理的に離れている
- そちらへの波及を示す発表は現時点でない
- 漏えいした情報の見立て:
- 抜けたのは自社サイトDBにあった問い合わせ、応募、登録情報と見るのが素直
- 件数は多くなくても、個人情報保護法上は報告対象になる
- 見えているサイトに大した情報がないのに漏れたという違和感が、入口の性質を物語る
- 侵入経路の仮説:
- Contact Form 7 5.0.3は、2026年時点では既知の脆弱性を抱えた古い系統に属する
- 断定はできないが、フォーム周辺を起点にファイルを置かれ内部へ、という筋書きは観測構成と矛盾しない
■ 8. 古さが調査も遅らせる
- 範囲特定まで52日:
- 発見から漏えい範囲の特定まで52日かかった
- 古い構成の調査上の弱さ:
- 2018年の構成には、いまの環境が持つ監査ログや検知の仕組みが乏しい
- 侵入は分かっても、何が持ち出されたかを追いきれない状態になりやすい
- そのため外部専門機関に頼り、それでも結論は「漏えいの恐れ」に留まった
- 二重の代償:
- 古さが侵入を許し、古さが調査も遅らせた
- 新しい構成なら数日で範囲を切れたかもしれない
■ 9. ひと手間で防げる初手
- 初手はどれもひと手間:
- 防御の初手はどれもひと手間で済む
- 実際にこの記事を書きながら自分のサイトも見直した
- オリジンをCDNの裏に隠す:
- サイトのIPが直接見えていると、WAFを迂回してサーバを直接叩かれる
- AWSはCloudFrontとAWS WAF
- AzureはFront Doorと統合WAF
- GCPはCloud CDNとCloud Armor
- apexドメイン（wwwなし）をCDNに向けるDNS対応も含め、半日あれば終わる
- メールのなりすまし対策:
- DMARCをp=none（検知のみ）からp=reject（拒否）へ変更する
- SPFを~allから-allへ変更する
- 作業は数分で済む
- 放置すると自社ドメインを騙るフィッシングメールが素通りする
- 依存関係を「見る」こと:
- これが本題
■ 10. 依存関係の可視化とSCA
- 見えなくなる依存関係:
- 凝ったカスタムテーマはWordPress.orgの自動更新から外れる
- プラグインも「動いているから」と放置されやすい
- こうして依存関係は少しずつ見えなくなり、8年が過ぎる
- Clean Coreを守れなかったERPが、自分が何を抱え込んでいるか分からなくなるのと同じ
- SCA（Software Composition Analysis）:
- 見えなくなった依存を機械的に洗い出す仕組み
- CVE公表の瞬間に、自環境のどの部品にどの脆弱性があるかを教えてくれる
- 見えなくなっていたリスクを、再びコストの計算に載せられるようにする道具
- 可視化の必要性:
- 脆弱性は毎日公表され、公表から数時間で攻撃コードが出回る
- 自動スキャナが世界中のサイトを舐めていく
- 可視化すれば、自分のサイトが今どう狙われうるかが手に取るように分かる
- 可視化していなければ、8年間まったく気づかないことが現実に起きる
- 完璧でなくても持てる姿勢:
- 人手も時間も足りず、完璧な運用は難しい
- それでもCVEを持ち、追いかける姿勢は持てる
- 依存を可視化し、警告が来たら動くだけで「気づかないまま8年」は避けられる
■ 11. 結論: 凝ることと守ること
- 作る力と守る力は別物:
- 凝るほどコードは増え、コアに絡みつき、標準の更新から外れる
- やがて作った人にしか触れないブラックボックスになる
- ERPで何十年も繰り返した失敗を、フロントエンドでより小さく無防備な形で繰り返している
- 守るための原則:
- コアはバニラに保つ
- 拡張は外に出す
- 自分が何に依存しているかを常に見える状態にしておく
- 認証に実を伴わせるもの:
- 認証という枠組みに実を伴わせるのは、結局そうした地道な運用
- 凝ることと守ることに同じ熱量を注ぐべき