AIを破壊するランサムウェア 「単なるファイル復元」では復旧できない理由：AIデータ保護におけるSaaSの落とし穴
企業がAI活用を進める中、攻撃者はAIインフラの「脳」を標的にし始めた。SaaSのデータ保護を過信すると、有事の際に全データを失う致命的な事態を招く。再起不能の危機からAIシステムを救う復旧戦略とは。
ランサムウェア（身代金要求型マルウェア）が企業のデータやその管理体制を襲う際、攻撃者はデータ分析やAI（人工知能）ツールを支えるインフラを無効化するために、コントロールプレーン（制御層）、カタログ、パイプラインといった「頭脳」を標的にするようになっている。
「データレイクハウス」は、大量の未加工データを蓄積する「データレイク」と、特定の目的のために整理、加工されたデータを格納する「データウェアハウス」（DWH）を融合させた技術だ。データ分析ツールやAIツールを運用する上で、SaaS（Software as a Service）型のデータレイクハウスは便利な一方、回復力の盲点を生みがちだ。「クラウドベンダーがデータ保護まで担う」という認識は誤解であり、SaaSの責任共有モデルでは、ベンダーの責務は稼働時間やインフラの安全確保にとどまる。データの保護、バックアップ、復旧は、あくまでユーザー企業の責任だ。この役割分担を軽視すれば、ランサムウェア被害がAIシステム全体の致命的な停止を招く恐れがある。
こうした事態を防ぐために、企業はどのような復旧計画を立て、手順を整理すべきなのか。通常のデータ復旧との差、保護すべき対象や復旧手順を解説する。
AIシステムの復旧は従来のデータ復旧とは違う
データ分析ツールやAIツールのためのシステムの復元は、ファイルサーバの復元とは異なる。システムを機能させるパイプライン、学習モデル、特徴量ストア（AIモデル学習用の加工済みデータ）、カタログは、互いに複雑に依存し合っているからだ。
侵害され構成要素をそのまま本番環境に戻しても、マルウェアが潜伏しているリスクは排除できない。そのため、完全な復旧とは見なせないのが実情だ。
データレイクハウスのランサムウェア復旧計画において最も確実な方法は、侵害されたシステムから切り離した場所で復元を試みることだ。これが、「隔離復旧環境」（IRE：Isolated Recovery Environment）の役割だ。IREは、ユーザー認証やアクセス権限を管理する「Active Directory」、ネットワーク上の住所録の役割を果たす「DNS」（Domain Name System）、各機器に通信用の設定を自動で割り当てる「DHCP」（Dynamic Host Configuration Protocol）といった、インフラの稼働に欠かせない基本機能を備えた専用の空間だ。復旧チームはこの空間でシステムを復元し、本番環境に再接続する前に正常に機能するかどうかを確認する。
IREを構築する手法には、主に2つの選択肢がある。
- エアギャップ方式
- 外部ネットワークから物理的に遮断する。優れた安全性を誇るが、専用機器や運用を担う人材の確保が不可欠だ。復旧（RTO）までに数日を要する場合もある。
- 論理隔離方式
- ネットワークの分割と厳格なアクセス制御を用いる。迅速かつ低予算で運用できるが、設定の徹底度合いが安全性を左右する。
隔離されたシステムは、そこに保存されたデータの正当性が保証されて初めて価値を持つ。そのため、バックアップは不変（イミュータブル）でなければならない。WORM（Write Once Read Many：書き込み1回、読み込み複数回）などの制御技術を用い、攻撃者による削除や改ざんを封じ込める必要がある。
それでも、定期的な復旧テストは欠かせない。復旧チームは全システムを復元し、パイプラインが正確に動くかどうか、AIモデルが期待通りの結果を出すかどうかを確かめる。復旧の各工程にかかる時間を記録し、確信を得た上で本番システムへと切り替えるべきだ。
データレイクハウスの「知性」を再建する
従来のランサムウェア対策は、ファイルを保存するストレージの保護に偏りがちだった。しかしAIシステムには、データを読み解くための「メタデータ層」の保護が欠かせない。
データレイクハウスは通常、「Amazon Simple Storage Service」（Amazon S3）や「Azure Data Lake Storage」といった安価なオブジェクトストレージに、「Apache Parquet」などの形式でデータを保存する。だが、ファイルの構造や履歴を記録したメタデータがなければ、AIエンジンはデータを正しく抽出できない。
「Delta Lake」「Apache Iceberg」「Apache Hudi」といった主要なテーブル形式フォーマットは、更新履歴であるトランザクションログを信頼の根拠としている。これが破壊されれば、AIシステムはデータへの「地図」を失い、機能不全に陥る。
単にデータファイルをコピーするだけでは復旧としては不十分だ。一般的なバックアップ手法はファイルを個別に扱うため、テーブルの復元に必要な情報の整合性を保てない。これでは、手作業で複雑な構造を組み直すという膨大な手間を強いられることになる。
有事の手順書には、以下の項目を盛り込むべきだ。
- 侵害されたコントロールプレーンを隔離する
- 別リージョン（拠点）に複製しておいたカタログやログに切り替える
- 不変バックアップから整合性の取れたカタログを復元する
- 過去の状態を再現する「タイムトラベル」機能を利用して、攻撃前の正常なメタデータを呼び出し、それが実際のデータファイルの状態と一致するかどうかを照合する。異常がないことが確認できてから業務を再開する
AIパイプライン全体の信頼を確保する
AIガバナンスを担うアナリストにとって、ランサムウェアに対する回復力はバックアップの問題であると同時に、データの出どころ（リネージ）や正当性の問題でもある。
構成要素の改ざんを検出し、確実に正常な状態に戻せる仕組みが不可欠だ。そのためには、学習データや特徴量ストアの状態だけではなく、モデルの重み、パイプラインの定義、履歴情報を含むモデル管理記録や検索用の数値データ（ベクトルインデックス）まで、あらゆる階層で履歴管理を徹底しなければならない。
出どころを証明するには、データソースから学習、モデルの出力に至るまでの詳細なリネージが必要になる。改ざんの検出には暗号学的ハッシュ値を用いる。これらの対策を組み合わせることで初めて、復元したAIモデルの品質を客観的に証明できる。
復旧の速度は、採用するデプロイ（展開）手法によって大きく変わる（表）。
| 展開戦略 | 仕組み | 最適な用途 |
|---|---|---|
| ブルー／グリーン | 2つの完全なシステムを並行稼働させ、瞬時に切り替える | 復旧速度を最優先する有事の切り替え |
| カナリア | 復旧したバージョンに少しずつ通信を流し、影響を監視する | 慎重な検証を要する定期更新 |
体系的な防御を実現するためには、以下の3つのフレームワークが役立つ。
- NIST AI RMF（AIリスクマネジメントフレームワーク）
- ビジネス全体のリスクを、統治、分析、測定、管理の4軸で評価する。
- AI TRiSM（信頼、リスク、セキュリティ管理）
- 調査会社Gartnerが提唱。信頼、リスク、セキュリティの観点から、AI管理に必要な技術を特定する。
- MITRE ATLAS
- 学習データを改ざんする「データポイズニング」、学習データや重みに攻撃のトリガーを仕込む「バックドア攻撃」など、AIシステムを標的とする手口のナレッジベースを活用する。
AIやセキュリティを率いるリーダーにとって、回復力の確保は有事の前に下しておくべきアーキテクチャに関する重大な決断だ。標準的な災害復旧（DR）計画では、AI技術特有の複雑なリスクに対処し切れない。体系的なアプローチを欠けば、混乱の中で最も重要な「信頼の証明」が後回しにされ、システム再開への道は遠のいてしまう。
Copyright © ITmedia, Inc. All Rights Reserved.