バックアップ、クロスアカウントコピー、保持期間、復元テストの基本設計は既習です。

既存環境のセキュリティを改善するときは、

バックアップジョブが成功している
=
セキュリティ上も安全

とは考えません。

例えば、本番アカウントの管理者権限が侵害されたときに、

本番データ
↓
削除

バックアップ
↓
同じ権限で削除

できるのであれば、バックアップは存在していても攻撃から復旧できない可能性があります。

また、

30日保持

↓

攻撃者が侵入

↓

45日後に侵害を発見

↓

正常な復旧ポイントが
既に期限切れ

であれば、バックアップ作成自体は成功していてもセキュリティ上の復旧要件を満たしません。

ここでは、

バックアップを作る

ことではなく、

侵害されても
復旧ポイントを残す

↓

攻撃者から
管理境界を分離する

↓

削除・保持期間短縮を防ぐ

↓

復旧に必要な権限を制御する

↓

信頼できる復旧ポイントを確認する

という、バックアップをセキュリティ対策として強化する設計を扱います。

ゴール

既存環境について、

• AWS Backupをセキュリティ上の復旧能力として評価する
• 保持期間を攻撃の検出遅延まで含めて設計する
• クロスアカウントバックアップの管理境界が実際に分離されているか確認する
• AWS Backup Vault Lockで復旧ポイントの不変性を高める
• Logically air-gapped vaultを侵害時の復旧経路として判断する
• バックアップへのアクセス権限と削除権限を分離する
• 不変な復旧ポイントの内容まで信頼できるか検証する
• 本番アカウントを利用できない状況でも復旧できる経路を検討する

ことを目指します。

1. バックアップをセキュリティ対策として見る

バックアップの一般的な目的には、

障害

誤操作

データ破損

災害

からの復旧があります。

セキュリティ改善では、さらに、

認証情報侵害

悪意ある管理操作

ランサムウェア

バックアップ削除

保持期間の変更

を脅威として加えます。

例えば、

本番管理者の認証情報を侵害
↓
本番リソース削除
↓
バックアップ削除
↓
復旧不能

となる設計では、バックアップが本番環境と同じ攻撃範囲にあります。

したがって、

本番環境
↓
侵害される

×

復旧ポイント
↓
同じ侵害で失われない

という関係を作る必要があります。

2. 最初にバックアップの攻撃経路を確認する

既存環境をレビューするときは、

バックアップはある？

だけではなく、

誰が削除できる？

誰が保持期間を変更できる？

本番管理者は
バックアップアカウントへ入れる？

バックアップボールトの設定を
誰が変更できる？

復元できる人は誰？

本番アカウントを失った場合
どこから復旧する？

を確認します。

重要なのは、

バックアップデータとバックアップ管理権限の両方を保護すること

です。

3. 保持期間は「保存コスト」だけで決めない

保持期間は、保存コストや規制対応だけではなく、

侵害から
どこまで過去へ戻れるか

を決めます。

例えば、

バックアップ保持
30日

↓

攻撃者が侵入
0日目

↓

徐々にデータを改ざん

↓

侵害発見
45日目

であれば、

侵害前の正常な復旧ポイント

がすでに期限切れになっている可能性があります。

したがって保持期間では、

規制上必要な期間

+

侵害を検出するまでの時間

+

復旧ポイントを選定するための余裕

も考えます。

ただし、

長ければ長いほど安全

とも限りません。

長期保持にはコストがあり、保持するデータ自体に保存期限や削除要件が存在する場合もあります。

判断するのは、

必要な復旧履歴
と
保持要件
と
コスト

です。

4. クロスアカウント化した後の管理経路を確認する

バックアップを別アカウントへ分離する基本設計は既習です。

ここで確認するのは、

別アカウントへ置いた後も、本番環境の侵害から本当に切り離されているか

です。

例えば、

本番管理者
↓
バックアップアカウントの
強い管理ロールを自由に引き受け可能

であれば、

本番管理者の認証情報侵害
↓
バックアップアカウントへ移動
↓
復旧ポイントへ影響

という経路が残ります。

したがって、

別アカウント
=
自動的に安全

ではありません。

確認するのは、

本番側から
どのロールを引き受けられる？

復旧ポイントを
誰が削除できる？

保持設定を
誰が変更できる？

復元と削除を
同じ権限へ与えていない？

です。

管理境界を作ったら、

その境界をIAM設計でも維持する

必要があります。

5. 不変バックアップで削除・変更に耐える

アカウントを分離しても、

バックアップアカウントの
管理権限そのもの

が侵害される可能性はあります。

そこで検討するのが不変バックアップです。

AWS Backupでは、

AWS Backup Vault Lock

を利用できます。

Vault Lockには、

Governance mode

Compliance mode

があります。

Compliance modeではGrace time経過後、

通常管理者

ルートユーザー

AWS

を含め、ロックを変更・削除できません。

また、ロックされたボールト内の復旧ポイントは、設定された保持期間を満了するまで削除できません。

6. Governance modeとCompliance modeを脅威で選ぶ

Governance modeは、

通常運用では
指定管理者以外に変更させたくない

というガバナンスに利用できます。

一方で、

強い管理権限自体が
攻撃者に奪われる

ことを想定すると、十分な権限でロックを解除できるGovernance modeでは要件を満たさない場合があります。

例えば、

管理者認証情報まで侵害される可能性

↓

一定期間は
誰にも復旧ポイントを
消させたくない

という要件なら、

Compliance mode

を候補にします。

決定打は、

誰からバックアップを
守る必要があるか

です。

7. Vault Lockでは保持期間設定も防御になる

Vault Lockでは、

MinRetentionDays
MaxRetentionDays

を設定できます。

例えば、

MinRetentionDays
35日

と設定したボールトに対して、

保持期間
7日

のバックアップやコピーを作成しようとすると、最小保持期間を満たさないため処理は失敗します。

これにより、

攻撃者が
新しいバックアップだけ
極端に短い保持期間へ変更

↓

短期間で復旧ポイントを消失

という弱体化を防ぐ材料になります。

ただし、

Vault Lockを設定した
=
既存のすべての復旧ポイントの
保持期間が自動変更される

わけではありません。

Vault Lock設定前から存在する復旧ポイントは、それまでのライフサイクル設定に従います。

8. Compliance modeは事前設計を間違えると戻せない

Compliance modeには、

Grace time

があります。

この期間中はロックを削除したり設定を修正したりできます。

しかしGrace time経過後は、

ロック変更
不可

ロック削除
不可

保持期間満了前の
復旧ポイント削除
不可

となります。

これはセキュリティ上強力ですが、

保持期間を誤って
極端に長く設定

すると、

大量のバックアップを
長期間削除できない

という状態にもなります。

したがって、

Compliance modeだから
とりあえず最大保持

ではなく、

必要な保持期間を先に決めてから不変化する

ことが重要です。

9. Logically air-gapped vaultを利用する

AWS Backupには、

Logically air-gapped vault

があります。

これは通常のバックアップボールトより追加の保護機能を持つ特殊なボールトです。

Logically air-gapped vaultには、

AWS Backup Vault Lock
Compliance mode

が組み込まれています。

設計イメージは、

本番環境
↓
バックアップ

↓

Logically air-gapped vault
│
├─ Compliance mode
├─ 保持期間
└─ 分離された復旧ポイント

です。

特に、

悪意ある操作

ランサムウェア

管理権限侵害

などを想定し、

通常運用の管理経路から
復旧ポイントを
より強く保護したい

場合の候補になります。

10. 通常運用経路と侵害時の復旧経路を分ける

クロスアカウントバックアップそのものの仕組みは既習です。

ここでは、

通常時に
バックアップを作る経路

と、

重大な侵害後に
バックアップへ到達する経路

を同じものとして考えないことが重要です。

例えば、

通常運用

本番環境
↓
バックアップ作成・コピー
↓
保護された復旧ポイント

に対して、

侵害時

本番アカウント
↓
信頼できない

別の復旧アカウント
↓
保護された復旧ポイントへアクセス
↓
復旧

という別経路を持たせます。

Logically air-gapped vaultではAWS Resource Access Managerを使用して別アカウントへアクセスを共有できます。

目的は、

本番アカウントが利用不能でも復旧能力を残すこと

です。

11. アクセス制御は「バックアップできる人」だけではない

バックアップの権限設計では、

バックアップ作成

バックアップコピー

復旧ポイント削除

ボールト設定変更

復元

を、必ずしも同じ主体へ与える必要はありません。

例えば、

バックアップ運用者
↓
作成・監視

復旧担当者
↓
必要時に復元

セキュリティ管理者
↓
ボールト / 保持期間管理

のように役割を分けることを検討します。

特に、

作成できる人
=
削除できる人
=
保持期間を変更できる人
=
復元できる人

という大きな権限集合を無条件に作らないようにします。

12. Vault Access Policyだけで十分とは限らない

AWS Backupのバックアップボールトでは、リソースベースのVault Access Policyを利用できます。

ただし、Vault Access Policyが制御するのは、

AWS Backup API

を使用するアクセスです。

一部のバックアップでは、

Amazon EBS API

Amazon RDS API

など、元サービス側のAPIからバックアップへアクセスできる場合があります。

したがって、

Vault Access Policyで
削除を拒否

↓

すべての管理経路から
削除不能

と即断してはいけません。

バックアップ種類によっては、

AWS Backup側の権限

+

元サービス側のIAM権限

を合わせて確認します。

重要なのは、

バックアップに到達できるすべての管理経路を確認すること

です。

13. 不変バックアップでも「正常なデータ」とは限らない

復元テストの必要性そのものは既習です。

ここで重要なのは、不変性とデータの正常性を混同しないことです。

例えば、

1日目
攻撃者侵入

↓

10日目
データ改ざん開始

↓

20日目
改ざん済みデータをバックアップ

↓

30日目
侵害発見

という場合、

削除・変更できない
復旧ポイント

であっても、

中身は既に改ざん済み

という可能性があります。

したがって、

不変
=
正常な復旧ポイント

ではありません。

必要なのは、

複数世代を保持

↓

侵害開始時点を推定

↓

侵害前の候補を選択

↓

復元テスト

↓

復元データや
アプリケーション状態を検証

という流れです。

不変性は、

復旧ポイントを変更・削除から守る対策

であり、

その内容が安全であることを証明する対策

ではありません。

14. 本番アカウントを使えない場合の復旧を考える

重大な侵害では、本番アカウントそのものを安全に利用できない可能性があります。

例えば、

管理者認証情報侵害
↓
IAM設定改ざん
↓
本番アカウントを
信頼できない

という状況です。

このとき、

復旧には
本番アカウントへのログインが必須

という設計では、復旧能力が侵害済み環境へ依存しています。

Logically air-gapped vaultとMulti-party approvalを組み合わせると、別の復旧アカウントから保護されたバックアップへのアクセスを要求する設計を構成できます。

復旧アカウント
↓
アクセス要求

↓

複数の承認者

↓

必要なしきい値を満たす

↓

復旧アクセス

これにより、

本番アカウントが侵害

↓

別の信頼できるアカウントから
保護されたバックアップへ到達

↓

復旧

という経路を持たせられます。

15. Multi-party approvalで単一認証情報への依存を減らす

Multi-party approvalを使用すると、

1人の管理者が
強い権限を持つ

だけでは、保護された復旧経路へのアクセスを完了できない設計にできます。

例えば、

復旧アカウント
↓
アクセス要求

↓

承認者A
承認

承認者B
承認

↓

必要数へ到達
↓
復旧アクセス

です。

特に、

本番アカウント侵害

認証情報窃取

マルウェア

を想定した復旧経路で、

単一の認証情報

への依存を減らせます。

ただし、通常のバックアップ運用すべてに必要なわけではありません。

判断するのは、

どの程度まで管理プレーン侵害を想定するか

です。

16. セキュリティ対策として一続きに設計する

バックアップをセキュリティ対策として改善するときは、

AWS Backupを導入

↓

終了

ではありません。

例えば、

本番ワークロード
↓
バックアップ
↓
別の管理境界
↓
不変なバックアップボールト
↓
適切な保持期間
↓
最小権限のアクセス制御
↓
複数世代から正常な候補を選定
↓
復元テスト
↓
復元後の正常性確認
↓
別の復旧アカウントからの復旧経路

という形で、

作成
↓
保護
↓
分離
↓
検証
↓
復旧

をつなげます。

17. 混同しやすいポイント

18. SAP-C02での判断手順

既存環境で、

AWS Backup
導入済み

バックアップ成功率
100%

とあっても、それだけで十分とは判断しません。

まず、

攻撃者が
本番管理者権限を取得したら
何ができる？

を確認します。

もし、

本番データ削除
+
バックアップ管理境界へ移動

まで可能なら、

本番側から残る
不要な管理経路を削減

します。

さらに、

バックアップ側の
強い管理権限まで侵害されたら？

を考え、

AWS Backup Vault Lock
↓
Compliance mode

などの不変性を検討します。

次に、

侵害発見まで
何日かかる可能性がある？

から保持期間を確認します。

さらに、

不変な復旧ポイントの中身は
侵害前の正常な状態か？

を確認し、

複数世代
↓
候補選定
↓
復元テスト
↓
正常性確認

へ進みます。

最後に、

本番アカウント自体を
利用できなくても復旧できる？

まで必要なら、

Logically air-gapped vault

復旧アカウント

Multi-party approval

などを候補にします。

まとめ

バックアップをセキュリティ対策として改善するときは、

作る

だけではなく、

残す
↓
保持期間

分離を維持する
↓
クロスアカウントの権限境界

消させない
↓
不変バックアップ

触れる人を制御する
↓
アクセス制御

正常な復旧ポイントを確認する
↓
復元テスト

侵害時にも使える経路を残す
↓
復旧

まで考えます。

AWS Backupでは、

AWS Backup Vault Lock

Logically air-gapped vault

Multi-party approval

などを既存のバックアップ設計へ組み合わせ、管理権限侵害に対する復旧能力を強化できます。

重要なのは、

バックアップが存在することではなく、攻撃を受けた後にも信頼できる復旧ポイントへ到達し、実際にサービスを復旧できること

です。

主要AWS公式資料

• AWS Certified Solutions Architect - Professional (SAP-C02) — Domain 3 / Task 3.2
• AWS Backup Vault Lock
• AWS Backup — Logically air-gapped vault
• AWS Backup — Cross-account backup
• AWS Backup — Vault access policies
• AWS Backup — Restore testing
• AWS Backup — Multi-party approval for logically air-gapped vaults