近年の重大インシデント、その裏側では何が起こっていたのか
まずは、近年発生した重大インシデント事例をいくつか振り返ってみよう。
メタップスペイメント
決済代行事業を展開するメタップスペイメントでは2021年末前後に、不正アクセスによる情報流出が発生した。同社の決済システムは標準的なシステム構成ではあったものの、決済システムのデータベースが特定顧客（A社）向けアプリケーションのデータベースと共有される構成になっていた。外部の攻撃者が、A社のアプリケーションに対しSQLインジェクションによる攻撃を行ったことで、同じデータベースにメタップスペイメントが保有していた、暗号化やマスクされた情報までもが流出してしまった。
Capital One
米国の大手金融サービスとして知られるCapital One（キャピタル・ワン）では、2019年にWAFの設定ミスに起因するSSRF（Server Side Request Forgery）攻撃を受け、大規模な情報流出が発生した。同社は、AWS EC2でWAF（Apache Mod Security）を構成し、情報をS3に保管していた。攻撃者はこのWAFの脆弱性を突いてS3にアクセスするためのクレデンシャルを窃取したため、S3内の情報が流出した。
KADOKAWA
出版大手のKADOKAWAは、2024年6月にハッカー集団「BlackSuit」によるランサムウェア攻撃を受け、システム障害や情報流出へと発展した。攻撃者はKADOKAWAのプライベートクラウド内にあるサーバーを遠隔起動させようとしたため、データセンターでは電源ケーブルやネットワークケーブルを物理的に抜線するなどの攻防が行われた。現時点では詳細不明ではあるものの、フィッシングなどにより従業員アカウントの情報が盗まれ、社内ネットワークに侵入されたと推測されている。
Shionogi America
塩野義製薬の米国法人では、解雇されたエンジニアが社外からプライベートクラウドにログインし、仮想環境に置かれていた業務用サーバーを削除した。のちに犯人は逮捕されたが、元社員が内部環境にアクセスできてしまったために発生したインシデントといえる。
GitLab
ソースコード管理などのサービスを提供するGitLabでは、2017年1月にエンジニアの操作ミスで全データを喪失するインシデントが発生した。DDoS攻撃への対応中にデータベースの複製を削除したはずが、本番のデータベースを削除してしまったという。5種類の定期バックアップではリストアできず、手動スナップショットがあったため復旧に成功した。
UniSuper
オーストラリアの年金基金であるUniSuperでは、クラウドベンダー内のオペレーターによるミスで、システムが削除されてしまう事件が起こった。同社はGoogle Cloud VMware Engineでプライベートクラウド環境を構築していたが、最初のデプロイでGoogleのオペレーターが「あるパラメーターを空白にする」というミスをしたため、デフォルトの期間（1年後）が設定され、1年後に環境が自動削除されてしまったのである。Google Cloud Storageに残っていたデータのバックアップからかろうじて復旧した。
ここまで紹介されたのは、いずれも社会的に重要なサービスを提供する組織におけるインシデントである。原因は様々であり、対策も一様ではない。徳丸浩氏は、「同じようなインシデントは、どの企業、どのサービスでも起こり得ます。こういうことが起こった時のために備えておかなければなりません」と警鐘を鳴らす。
