![【Security Hub修復手順】[EFS.7] EFS ファイルシステムでは、自動バックアップが有効になっている必要があります](https://images.ctfassets.net/ct0aopd36mqt/5HhaOnXgcaK80eorXpnxyD/57c471f47b2f7e9c65e7bc2f185a9184/aws-security-agent.png?w=3840&fm=webp)
【Security Hub修復手順】[EFS.7] EFS ファイルシステムでは、自動バックアップが有効になっている必要があります
かつまたです。
本記事では、AWS Security HubによるAWS環境のセキュリティ状況スコアリングに該当する項目についての修復手順をご紹介します。
本記事の対象コントロール
[EFS.7] EFS ファイルシステムでは、自動バックアップが有効になっている必要があります
[EFS.7] EFS file systems should have automatic backups enabled
前提条件
本記事はAWS Security Hubで「AWS基礎セキュリティのベストプラクティススタンダード」を利用されている方向けの内容となります。
AWS Security Hubの詳細についてはこちらのブログをご覧ください。
対象コントロールの説明
このコントロールは、Amazon EFSファイルシステムで自動バックアップが有効になっているかチェックします。
対象のファイルシステムでバックアップポリシーを有効にすると、このコントロールは成功します。
自動バックアップの実体
EFSの自動バックアップは、AWS Backupのデフォルトバックアッププランによって実行されます。設定内容は次のとおりです。
| 項目 | 内容 |
|---|---|
| バックアップ頻度 | 日次 |
| スケジュール時刻 | UTC 5:00(日本時間 14:00) |
| 開始ウィンドウ | スケジュール時刻から8時間 |
| 完了ウィンドウ | スケジュール時刻から7日 |
| 保持期間 | 35日 |
| 保存先 | aws/efs/automatic-backup-vault |
| バックアップ方式 | 増分バックアップ |
上記は検証時点のデフォルト設定です。スケジュールやウィンドウの値はバックアップルールとして編集できます。
初回はファイルシステム全体がコピーされ、2回目以降は変更・追加・削除されたファイルとディレクトリのみがコピーされます。
デフォルトのバックアッププランとバックアップボールトは、自動バックアップの有効化時にAmazon EFSがユーザーに代わって作成します。プラン名は aws/efs/automatic-backup-plan、ボールト名は aws/efs/automatic-backup-vault です。なお、これらを削除することはできません。
検出される原因は作成方法にあります
自動バックアップのデフォルト値は、ファイルシステムの作成方法によって異なります。
| 作成方法 | 自動バックアップのデフォルト |
|---|---|
| EFSコンソール | 有効 |
| AWS CLI / API(リージョンファイルシステム) | 無効 |
| AWS CLI / API(1ゾーンファイルシステム) | 有効 |
コンソールから作成したファイルシステムは自動バックアップが有効になるため、通常このコントロールで検出されません。
検出されるのは、AWS CLIやAPI、CloudFormationなどのIaCツールでリージョンファイルシステムを作成したケースがほとんどです。
CloudFormationの AWS::EFS::FileSystem では、BackupPolicy プロパティで自動バックアップの有効・無効を指定します。IaCで管理しているファイルシステムを修復する場合は、コンソールでの変更だけでなく、テンプレート側にも BackupPolicy の有効化を明示することを推奨します。
Resources:
FileSystem:
Type: AWS::EFS::FileSystem
Properties:
BackupPolicy:
Status: ENABLED
対応が必要な理由
EFSのリージョンファイルシステムは、複数のアベイラビリティーゾーンにデータを冗長化して保存します。一方、1ゾーンファイルシステムは単一のアベイラビリティーゾーン内にデータを保存します。
いずれの場合も、この冗長化はインフラ障害に対する耐久性を提供するものであり、データ操作に対する保護ではありません。
具体的には、次のような事象からは復旧できません。
- 運用担当者の誤操作によるファイルやディレクトリの削除
- アプリケーションの不具合によるデータの上書き・破損
- ランサムウェアによるファイルの暗号化
これらの操作結果は冗長化されたデータにもそのまま反映されます。EFSのストレージ冗長化だけでは復旧できないため、バックアップのように世代管理された復旧手段が必要です。
なお、AWSアカウント自体が侵害されるケースまで想定する場合、自動バックアップだけでは不十分です。デフォルトのバックアップボールトは復旧ポイントの削除を拒否するアクセスポリシーを持ちますが、十分な権限を持つ主体であればそのポリシーを編集できます。AWS Backup Vault Lock、クロスアカウントコピー、論理エアギャップボールトなどの併用もあわせてご検討ください。
EFS.2との違い
Amazon EFSのバックアップに関するコントロールには、EFS.2「Amazon EFS ボリュームは、バックアッププランに含める必要があります」もあります。両者は評価する対象が異なります。
| コントロール | AWS Configルール | 評価対象 | 評価タイミング |
|---|---|---|---|
| EFS.7 | efs-automatic-backups-enabled |
ファイルシステムのバックアップポリシーが有効か | 変更トリガー |
| EFS.2 | efs-in-backup-plan |
いずれかのバックアッププランに含まれているか | 定期評価 |
独自に作成したバックアッププランでEFSをバックアップしている場合、EFS.2はPASSEDになりますが、EFS.7は自動バックアップが無効のままFAILEDになります。
独自のバックアッププランで要件を満たすバックアップを取得できているのであれば、Security Hub側で検出結果を抑制する判断も可能です。その場合は、バックアップの頻度と保持期間が自社の復旧要件を満たしているかを確認してください。
ただし、ワークフローステータスを SUPPRESSED にしても、将来同じ問題について新しい検出結果が生成されることを防げるわけではありません。SUPPRESSED は個々の検出結果に対するステータスです。継続的に除外したい場合は、オートメーションルールによる自動抑制や、コントロール自体の無効化もあわせてご検討ください。
環境別の考え方
本番環境では、RPO・RTOなどのデータ保護要件に基づき、自動バックアップを有効化してください。
本番以外の環境では、対応は必須ではありません。自動バックアップを有効にするとバックアップストレージの料金が発生するため、復旧要件のない検証環境などでは、コストを優先して無効のままとする判断も考えられます。
修復手順
自動バックアップは作成済みのファイルシステムに対して後から有効化できます。ファイルシステムの再作成やアンマウントは発生せず、マウント中のクライアントから引き続きアクセスできます。
事前確認: 現在のバックアップポリシーを確認する
Security Hubの検出結果でFAILEDになっているリソースのIDから、対象のファイルシステムIDを確認しておきます。
そのうえで、本当に自動バックアップが無効になっていることを確認します。EFSコンソールで確認する場合は、以下の手順です。
- EFSコンソールを開く
- 左メニューから「ファイルシステム」を選択する
- 対象のファイルシステムを選択して詳細画面を開く
- 「全般」セクションの「自動バックアップ」が「無効」になっていることを確認する

CLIで確認する場合は、以下のコマンドを使用します。
aws efs describe-backup-policy \
--file-system-id <ファイルシステムID> \
--region ap-northeast-1
Status が DISABLED であれば自動バックアップは無効です。
ただし、AWS CLIやAPIで作成したファイルシステムでは、次のように PolicyNotFound エラーが返ることがあります。
An error occurred (PolicyNotFound) when calling the DescribeBackupPolicy operation: None
PolicyNotFound は、対象のファイルシステムにバックアップポリシーが設定されていない場合に返ります。エラーですが異常ではなく、自動バックアップが有効化されていない状態です。なお今回の検証では、一度有効化してから無効化したファイルシステムでは Status: DISABLED が返りました。
修復手順: 自動バックアップを有効化する
EFSコンソールから自動バックアップを有効化します。
- EFSコンソールで対象のファイルシステムの詳細画面を開く
- 「全般」設定パネルの「編集」を選択する
- 「自動バックアップの有効化」にチェックを入れる
- 「変更を保存」を選択する


CLIで実行する場合は、以下のコマンドを使用します。
aws efs put-backup-policy \
--file-system-id <ファイルシステムID> \
--backup-policy Status="ENABLED" \
--region ap-northeast-1
コマンドの応答では Status が ENABLING になります。
{
"BackupPolicy": {
"Status": "ENABLING"
}
}
今回の検証では、数秒後に ENABLED へ変わりました。反映時間は環境によって異なる可能性があるため、以下のコマンドで状態を確認してください。
aws efs describe-backup-policy \
--file-system-id <ファイルシステムID> \
--region ap-northeast-1 \
--query 'BackupPolicy.Status' \
--output text
自動バックアップが有効になると、ファイルシステムに aws:elasticfilesystem:default-backup というシステムタグが値 enabled で付与されます。このタグはAmazon EFSが管理します。今回の検証では、自動バックアップを無効化するとこのタグは削除されました。

なお、バックアップの実行中にファイルの書き込み・名前変更・移動・削除が行われると、取得されたバックアップ内でデータの不整合が発生する可能性があります。アプリケーション整合性が必要な場合は、更新処理を一時停止するか、更新の少ない時間帯にバックアップを実行してください。
有効化後のバックアップ設定を確認する
自動バックアップを有効にすると、AWS Backupのデフォルトプランでバックアップが実行されます。設定内容はAWS Backupコンソールで確認できます。
- AWS Backupコンソールを開く
- 左メニューから「バックアッププラン」を選択する
- デフォルトのEFSバックアッププランを選択する

デフォルトのバックアッププランとバックアップボールトは、あらかじめ手動で用意しておく必要はありません。今回の検証では、有効化の操作から1分以内に自動作成されました。反映に時間がかかる場合は、しばらく待ってからAWS Backupコンソールを再確認してください。
なお、デフォルトのバックアッププランとバックアップボールトそのものは削除できません。
最後に
今回は、EFS.7の修復手順をご紹介しました。
EFSのストレージ冗長化はインフラ障害に対する耐久性であり、誤削除やデータ破損からは守ってくれません。本番環境では復旧手段としてのバックアップを必ず確保しましょう。
ご覧いただきありがとうございました。







