1. DXの道半ば：なぜ最新クラウドは防波堤になれなかったのか？
アサヒGHDは、Google Cloud Platform（GCP）をDX戦略の中核に据え、データの高度利用（BigQuery）や、既存資産のクラウド移管（Google Cloud VMware Engine: GCVE）を積極的に推進していました。しかし、今回のインシデントで壊滅的な被害を受けたのは、国内データセンターに残存していた**「オンプレミス」**のシステムでした。
GCVE（Google Cloud VMware Engine）とは？
クラウドへ移行した部分は安全な設計になっていたとしても、オンプレミス環境とクラウドがネットワークで繋がっている以上、**古い環境（オンプレミス）で発生した「火事」は、容易にシステム全体へと燃え広がります。** 移行過渡期における「守りの不均一さ」が最大の弱点となりました。
「オンプレミス」って結局なに？
IT業界では略して「オンプレ」とも呼ばれます。英語の「on-premises（敷地内で）」という言葉通り、「自社の建物の中に、実物のサーバー（コンピューター）を置いて運用する」というスタイルを指します。
技術的な定義を表示 +
オンプレミス： 企業が自社で情報システムを保有し、自社の設備（データセンターやサーバー室）内に機器を設置して運用すること。ネットワーク、ハードウェア、ソフトウェアのすべてを自社で管理・統制します。
わかりやすい例え：持ち家 vs ホテル
「オンプレミス」と「クラウド」の違いは、住居に例えると非常にわかりやすくなります。
🏠 オンプレミスは「持ち家」
- 自由度： 壁を壊したり、庭を作ったり自由にリフォームできる。
- 管理： 屋根が壊れたら自分で直す。火災保険も自分で入る。
- コスト： 最初に家を建てる大金が必要。
🏨 クラウドは「ホテル・賃貸」
- 自由度： 部屋のルールに従う必要があるが、すぐ住める。
- 管理： 掃除や設備の修理はホテルの人がやってくれる。
- コスト： 使った分だけ（宿泊代）を払えばいい。
なぜアサヒGHDの事件で重要なのか？
アサヒGHDは最新の「クラウド（Google Cloud）」への引っ越しを進めている最中でした。しかし、まだ一部の重要なシステムが古い「持ち家（オンプレミス）」に残っていました。 攻撃者は、この**「古い家の、鍵が古くなっていた場所（VPNの脆弱性）」**を狙って侵入したのです。
「持ち家（オンプレミス）」は自由で安全なイメージがありますが、管理を怠ると**「自分たちで全ての戸締まりを確認しなければならない」**という大きな責任が伴います。
2. レガシーの呪縛：複雑化した管理体制の隙
長年運用されてきた国内データセンターのシステムは、いわゆる「レガシー資産」となっていました。これらのシステムは、最新のクラウドネイティブな環境に比べて、以下のようなセキュリティ上の課題を抱えていた可能性が高いと考えられます。
3. Oracleデータベースの役割：海外クラウドと国内レガシーの対比
アサヒGHDの海外子会社では、Oracle ERP Cloudなどのクラウドサービス導入事例が確認されます。一方で、国内の基幹システムでは依然としてオンプレミスのOracle Databaseが「記憶の金庫」として重用されていました。
今回の攻撃では、このデータベースそのものの脆弱性が突かれたわけではありません。第2回で解説した通り、データベースを格納する**仮想化基盤（VMware ESXi）そのものが乗っ取られた**ことが致命傷となりました。OSやデータベース製品が何であれ、その土台である「仮想化ホスト」を暗号化されるという、インフラ層の無力化が起きたのです。
4. ハイブリッド環境の罠：移行期の「セキュリティ空白地帯」
クラウド移行を進める企業が最も陥りやすい罠は、**「新旧のセキュリティポリシーが混在すること」**です。
アサヒGHDの事例は、DX推進という「攻め」の裏側で、オンプレミスという「守り」のガバナンスをクラウドと同等レベルにまで引き上げることの難しさを浮き彫りにしました。
まとめ：インフラ担当者への教訓
「クラウドに移行しているから安心」という考えは禁物です。
- 移行中のオンプレミス資産こそが、攻撃者にとって最も狙いやすい「脆弱な窓」になる。
- VPNを通した「内側」というだけで信頼するネットワーク設計は限界を迎えている。
- インフラ全体の可視性を確保し、クラウド・オンプレミスを問わない統一されたセキュリティ基準が必要。
次回、第4回では、多くの企業が頭を悩ませる**「セキュリティベンダーへの委託」**の限界と、製品を導入していても防げなかった運用の落とし穴について考察します。
