アスクルは、なぜバックアップがあってもすぐに復旧できなかったのか

侵入に使われたのは、業務委託先に付与していた管理者アカウントでした。このアカウントには、例外的に多要素認証が適用されていませんでした。会社はID・パスワードの不正利用を確認していますが、最初にどう漏れたかは解明できていません。

侵入した攻撃者は、複数のサーバーへアクセスするための認証情報を集め、ランサムウェアを展開しました。物流システムが暗号化され、自動倉庫やピッキングシステムなどを動かせなくなったことで、出荷業務を全面停止する事態になりました。

復旧に使うはずのバックアップも、攻撃を受けました。 同じデータセンター内のバックアップが暗号化され、バックアップファイルの削除も確認されています。アスクルは、ランサムウェア攻撃を想定したバックアップ環境を構築していなかったことを、復旧が長引いた要因に挙げています。[1]

攻撃後の復旧では、残っているデータを戻すだけで業務を再開できるとは限りません。攻撃者に使われたアカウントや、侵害された可能性のある機器を、そのまま使い続けてよいか確認する必要があります。

アスクルは主要アカウントの認証情報を更新し、端末やサーバーに脅威が残っていないかを調査しました。汚染が疑われる機器は廃棄やOSの再インストールを行い、安全を確認した新しい環境を構築しています。会社は、対策を適用する機器の多さや、一部のOS更新にも時間を要したと説明しています。[1]

業務は、扱う商品や出荷拠点を限ったトライアルから戻していきました。

これらは段階的な再開で、各時点で全サービスが通常に戻ったという意味ではありません。[1][2]

バックアップの被害に加えて、機器の安全確認と環境の再構築が必要になり、注文を受けて商品を出荷するまでの業務を順に戻していった経緯が分かります。

バックアップの取得状況を確認する際は、攻撃を受けた後、そのデータを使って仕事を再開できるかまで確かめたいところです。

• バックアップを守れるか
  本番システムの管理者権限を奪われても、バックアップを削除・暗号化されないようにしているか。
• 復元する環境を用意できるか
  サーバーを作り直し、アカウントを更新する場合に、必要な設定や手順がそろっているか。
• 実際の業務を動かせるか
  データの復元後、受注・在庫確認・出荷など、一連の処理が動くところまで試しているか。全面復旧までの間、限定的に再開できる業務はあるか。

復旧訓練でファイルを取り出せた後に、誰が、どの環境で、どの仕事から再開するのか。アスクルの事案を踏まえて、自社の手順でも確認しておきたい点です。