我々が最も頻繁に目にするのは、攻撃者がペイロードを実行する前に、数日から数週間にわたりネットワーク内に検知されずに潜伏しているケースです。彼らはその時間を利用してバックアップの保存場所を特定し、その後、バックアップを削除、破損、またはアクセス不能にします。この潜伏期間は、復旧作業の妨げにもなります。もし復旧したバージョンがすでに感染していた場合、システムは数日間は復旧しますが、その後、攻撃者がすべてを再暗号化してしまうことになります。
攻撃者がバックアップに侵入する仕組み
バックアップの侵害のほとんどは、一人の人物と一組の認証情報から始まります。
フィッシング詐欺の見分けがつきにくくなった。
AIが作成したメールには、フィルタや従業員がかつて見抜いていたような文法ミスや不自然な表現が一切見られなくなりました。
熟練者でさえ「なぜまだこの請求書を支払っていないのか」と疑問に思うほど説得力のある支払い要求が絶えず届きます。そして、巧妙に作られたメッセージがたった1通あれば、攻撃者がバックアップストレージにアクセスするために必要な認証情報を渡してしまうのに十分です。
共有された認証情報や、権限範囲が広すぎる認証情報が、あとはすべてを成し遂げてしまいます。
ローマへの道は一つではないように、残念ながら、攻撃者がバックアップにアクセスする手段も数多く存在します：
- ・バックアップエージェントが、ドメイン管理者として、あるいは本番環境の共有フォルダへの書き込み権限を持つドメインユーザーとして実行されている。
- ・1つのローカル管理者パスワードが、ローテーションなしで複数のサーバーで再利用されている。
- ・NASやクラウドバケットの認証情報が、共有パスワードマネージャー、スクリプト、またはマップされたドライブに保存されている。
- ・同じRMMアカウントや管理者アカウントが、本番環境、ドメインコントローラー、バックアップコンソールにアクセスできてしまうのです。
バックアップにもミスはつきものです。
善意の従業員が誤ってフォルダを削除したり上書きしたりしたり、あるいはパスワードのローテーションによってバックアップジョブのアクセス権が失われても、誰も気づかないことがあります。企業はセキュリティツールに多額の投資を行う一方で、トレーニングやアクセス制御には比較的少ない予算しか割り当てていません。しかし、こうした失敗のほとんどは、まさにそこに起因しているのです。
現実には、いかなるセキュリティ体制であっても、すべての攻撃を完全に防ぐことはできません。だからこそ、企業はバックアップの安全性を確保しておく必要があるのです。そうすれば、万が一攻撃がすり抜けてしまった場合でも、バックアップが残っており、復元が可能になります。
バックアップのセキュリティチェック5項目
バックアップは、単なる「チェックリストの項目」から、ビジネスが危機にさらされた際にその有効性を確認し、復旧できる手段へと進化させなければなりません。
3-2-1バックアップルールについてはここでは詳しく触れません。今や誰もがこれを遵守しているはずだからです。その代わりに、当社がMSPパートナーの顧客のバックアップ環境を検証する際にも確認している、以下の5つの質問について見ていきましょう。
1. 復元テストは、チームが実行できるほど簡単ですか？
テストは、スケジュール通りに実行できるほどシンプルでなければなりません。例えば、ファイルやアプリケーションの復元は毎月または四半期ごとに、システム全体の復元は少なくとも年に1回実施します。テストを行うたびにバックアップが機能していることが確認でき、技術担当者は実践的な経験を積むことができるため、インシデント発生時に初めて手順を覚えるような事態を防げます。
2. バックアップストレージは隔離されていますか？
ローカルおよびクラウドのバックアップストレージは、いずれも本番環境とは分離されている必要があります。つまり：
- ・バックアップ専用であり、バックアップソフトウェアからのみアクセス可能な専用のNASまたはクラウドストレージ先を使用すること。一般的なファイル共有やマップされたドライブは絶対に使用しないでください。
- ・そのストレージ用の認証情報は1セットのみとし、チーム全員が閲覧できるスクリプトや保管庫のエントリではなく、バックアップソフトウェア内に暗号化して保存すること。
3. クラウドストレージは不変型であり、それでもアクセスは可能ですか？
不変ストレージは、所定の保存期間中、変更や削除を防止するため、有効な認証情報を持つ攻撃者がオフサイトのコピーを消去することを防ぎます。しかし、ストレージへのアクセスに必要な認証情報や暗号化キーが漏洩する可能性は依然としてあります。これらが、攻撃の際に暗号化されたり盗まれたりする場所に保存されている場合、不変のコピーはそのまま残っていても、完全にアクセス不能となり、使用できなくなってしまいます。これを回避するには、アクセス認証情報と暗号化キーを本番環境とは別の場所に文書化して保管してください。
4. 十分に遡って復元できますか？
ランサムウェアが実行されるまで3週間もネットワーク内に残っていた場合、昨日や先週のバックアップにはすでにそのランサムウェアが含まれている可能性が高く、それらのバックアップを復元すると問題が再発することになります。感染していない状態を復元するには、保持設定において、攻撃者が侵入する前の時点まで遡って十分な数のバージョンを保持できるようにする必要があります。
一つの対策として、バックアップジョブや保存場所ごとに保存期間ポリシーを設定することが挙げられます。ローカルストレージについては、迅速な運用上の復元を可能にするために保存期間を短く設定し、オフサイトストレージについては、妥当な潜伏期間を超えるように保存期間を長く設定します。
5. バックアップは自身の処理結果を確認しているか？
優れたバックアップジョブは、実行の開始時に、選択されたすべての対象がバックアップセットに含まれていることを確認します。何かが欠落していたり破損していたりする場合、その対象を再度バックアップします。
これにより、バックアップファイルの完全性が確認されます。ただし、バックアップの復元可能性が確認されるわけではありません。たとえば、ボリュームシャドウコピーサービスのライターがタイムアウトした場合や、ドライバが欠落しているために異なるハードウェアへのベアメタル復元を行う場合など、完全なバックアップであっても、アプリケーション一貫性のある復元やベアメタル復元に失敗する可能性があります。こうした問題は復元テストを行って初めて発見できるため、結局は最初のチェック項目に戻ることになります。
現実的な復旧時間はどれくらいか？
「バックアップはありますか？」という質問には、ほとんどの事業主が答えられるでしょう。しかし、「もし今この瞬間にシステムがすべてダウンしてしまった場合、稼働を再開するまでに何時間かかり、どれだけのデータが失われるでしょうか？」という質問にはどうでしょうか。
RTO（復旧時間目標）とRPO（復旧時点目標）がどの程度になるかを把握できるのは、この2つ目の質問に答えることだけです。
帯域幅が最初の制約要因となります。
企業がSaaSアプリケーション、データベース、ファイルストレージをより多く利用するにつれ、インターネット接続はその成長に追いつけなくなっています。以下の表は、プロトコルのオーバーヘッド、スロットリング、および接続を消費するその他の要因を考慮する前の、フルラインレートでのクラウドのみによる復旧における最良のシナリオを示しています。
| 復元データ | 100 Mbps | 500 Mbps | 1 Gbps |
| 500 GB | 11 時間 | 2.2 時間 | 1.1 時間 |
| 1 TB | 22 時間 | 4.4 時間 | 2.2 時間 |
| 2TB | 44 時間 | 8.9 時間 | 4.4 時間 |
実際には、復元にはそれ以上の時間がかかります。そのため、ハイブリッドバックアップが注目されています。これにより、ローカルバックアップからLAN速度で復元を行い、ローカルコピーでは提供できないデータのみをクラウドストレージから取得することが可能になります。
2つ目の制約は、チームの準備態勢です。
復元テストを省略することで節約できる時間は、チームが復元プロセスの開始方法、暗号化キーの所在、復元順序の決定などをその場になって考えなければならない場合、かえって大きなコストとなります。その間も、顧客は損失を被り続けます。唯一の解決策は、各システムに対して定期的かつ綿密な復元テストを実施することです。そうして初めて、顧客のRTOを把握できるのです。
RSSフィードを取得する
