Uncategorized

#40

 

以下の通り、指定フォーマットで問題を整理・解説します。

■問題文（文字列を編集せずに出力）

ある企業は、企業のウェブサイトへの異常なトラフィックが頻繁に発生することが確認されています。リクエストを膨らませる IP アドレスの範囲は常に変化しており、トラフィックの量は増加しています。

セキュリティエンジニアは、潜在的な DDoS 攻撃から ウェブサイトを保護するためのソリューションを実装する必要があります。このソリューションは、IP アドレスからのリクエストの割合を追跡する必要があります。特定の IP アドレスからのリクエストが特定のレートを超える場合、ソリューションはその IP アドレスからウェブサイトに到達できるトラフィックの量を制限する必要があります。

これらの要件を満たすソリューションを選択してください。

■選択肢（文字列を編集せずに出力）

A. 問題のあるクライアントの IP アドレス範囲を特定します。AWS WAF で通常のルールを作成し、問題のある IP アドレスの範囲をブロックします。
B. バックエンドサーバーに Amazon Inspector を設定します。レートベースの構成で評価ターゲットを作成し、問題のある IP アドレスをブロックします。
C. AWS WAF でレートベースのルールを作成し、IP アドレスが設定されたしきい値レートを超えたときに IP アドレスをブロックします。
D. Amazon GuardDuty でレートベースのルールを作成し、IP アドレスが設定されたしきい値レートを超えたときに IP アドレスをブロックします。

■問題文の要件の概要

  • DDoS 攻撃からの保護が必要
  • 攻撃元の IP アドレスは頻繁に変化
  • 特定 IP のリクエストレート監視が必要
  • 一定のレートを超えた IP を自動的に制限

■正解の選択肢と解説

正解：C. AWS WAF でレートベースのルールを作成し、IP アドレスが設定されたしきい値レートを超えたときに IP アドレスをブロックします。

解説：
AWS WAF（Web Application Firewall）は、レートベースのルールを設定することで、特定の IP アドレスからの過剰なリクエストを検出し、しきい値を超えた場合にその IP アドレスを自動的にブロックできます。これは変動する攻撃元に対しても有効なDDoS対策であり、問題文の要件を最も的確に満たします。

■不正解の選択肢の理由

  • A. 静的に IP アドレスを指定してブロックする方式では、攻撃元 IP が頻繁に変わる本ケースでは有効性が低い。
  • B. Amazon Inspector は脆弱性スキャンツールであり、トラフィックの監視やIP制御には使用できない。
  • D. Amazon GuardDuty は脅威検出のためのサービスで、IPを自動的にブロックする機能やレートベースルールは存在しない。

■SCS試験で押さえておくべきポイント

  • AWS WAF のレートベースルールは、一定期間内のリクエスト数に基づきIP単位で制御可能。動的なIP変化に対応可能。
  • Amazon Inspector は脆弱性診断用途、GuardDuty は検出用途であり、どちらもブロッキング機能は持たない。
  • **手動IPブロックルール（A）**は、変化する攻撃には非効率。
  • SCS試験では「サービスの機能範囲・用途の違い」に注目することが得点の鍵。

次の問題も続けてお送りいただければ、同じ形式で対応いたします。

以下に、問題2の内容を指定フォーマットで整理・解説します。

■問題文（文字列を編集せずに出力）

A 社は、アカウント A という名前の AWS アカウントを持っています。A 社は最近 B 社を買収し、B 社はアカウント B という名前の AWS アカウントを持っています。B 社は、そのファイルを Amazon S3 バケットに保存します。管理者は、アカウント A のユーザーに、アカウント B の S3 バケットへのフルアクセスを付与する必要があります。

管理者がアカウント A のユーザーの IAM 権限を調整した後、ユーザーはまだ S3 バケット内の任意のファイルにアクセスすることはできません。

この問題を解決するソリューションを選択してください。

■選択肢（文字列を編集せずに出力）

A. アカウント B で、アカウント A からのユーザーがアカウント B の S3 バケットにアクセスすることを許可するために、ユーザーポリシーを作成します。
B. アカウント B で、アカウント A からのユーザーがアカウント B の S3 バケットにアクセスすることを許可するために、バケット ACL を作成します。
C. アカウント B で、アカウント A からのユーザーがアカウント B の S3 バケット内のすべてのオブジェクトにアクセスすることを許可するために、オブジェクト ACL を作成します。
D. アカウント B で、バケットポリシーを作成して、アカウント A からのユーザーがアカウント B の S3 バケットにアクセスすることを許可します。

■問題文の要件の概要

  • 買収によって別アカウント間でのファイル共有が必要
  • アカウント A のユーザーがアカウント B の S3 バケットへアクセスできない問題がある
  • 解決策はクロスアカウントアクセスの構成に関するもの

■正解の選択肢と解説

正解：D. アカウント B で、バケットポリシーを作成して、アカウント A からのユーザーがアカウント B の S3 バケットにアクセスすることを許可します。

解説：
クロスアカウントで S3 にアクセスするには、アクセス元アカウント（アカウント A）で IAM ポリシーの許可を与えるだけでなく、リソース側（アカウント B）の S3 バケットにも、バケットポリシーで明示的にアクセス許可を付与する必要があります。
S3 はリソースベースのポリシー（バケットポリシー）によって外部アカウントからのアクセスを制御するため、バケットポリシーでアクセス許可を定義することが必須です。

■不正解の選択肢の理由

  • A. ユーザーポリシーを作成：IAM ポリシーは自アカウント内のリソースへのアクセス許可に使います。他アカウントのバケットにはバケット側のリソースポリシー（バケットポリシー）が必要です。
  • B. バケット ACL を作成：ACL は古い形式のアクセス制御で、アカウント単位の詳細制御に向いておらず、非推奨です。
  • C. オブジェクト ACL を作成：ACL はオブジェクト単位のアクセス権を定義しますが、S3 バケット全体へのアクセスを提供するには不適切です。

■SCS試験で押さえておくべきポイント

  • S3 のクロスアカウントアクセスには、アクセス元 IAM ユーザーに対する許可（IAM ポリシー）と、リソース側の許可（バケットポリシー）の 両方が必要。
  • S3 バケットポリシーはリソースベースのアクセス制御を行うため、クロスアカウントアクセス時に不可欠。
  • ACL（Access Control List）による制御は旧方式であり、SCS 試験では極力避けるべき解答肢。
  • アカウント間連携では リクエスト元の許可＋リソース側の受け入れ設定 の両方を常に意識。

次の問題があれば、引き続き対応いたします。

以下に、問題3を指定フォーマットで整理・解説します。

■問題文（文字列を編集せずに出力）

ある企業は、Amazon RDS DB インスタンスと Amazon Elastic Block Store (Amazon EBS) ボリュームのバックアップコピーを保持する必要があります。同社は、数百マイル離れたデータセンターにバックアップコピーを保持する必要があります。

最も少ない運用オーバーヘッドでこれらの要件を満たすソリューションを選択してください。

■選択肢（文字列を編集せずに出力）

A.
AWS Backup を設定し、必要なスケジュールに従ってバックアップを作成します。異なる AWS リージョンにバックアップボールトを作成します。AWS Backup を設定し、バックアップを異なる AWS リージョンのバックアップボールトにコピーします。

B.
AWS Backup を設定して、必要なスケジュールに従ってバックアップを作成します。バックアッププランで複数のアベイラビリティーゾーン (AZ) をバックアップの保存先として指定します。

C.
Amazon Data Lifecycle Manager を設定してバックアップを作成します。Amazon Data Lifecycle Manager ポリシーを設定して、バックアップを Amazon S3 バケットにコピーします。S3 バケットでレプリケーションを有効にします。

D.
Amazon Data Lifecycle Manager を設定してバックアップを作成します。AWS Lambda 関数を作成し、バックアップを異なる AWS リージョンにコピーします。Amazon EventBridge を使用してスケジュールに従って Lambda 関数を実行します。

■問題文の要件の概要

  • Amazon RDS および Amazon EBS のバックアップを保持する必要がある
  • バックアップは 地理的に離れたデータセンター（リージョン） に保管する必要がある
  • 運用負荷（オーバーヘッド）はできる限り 最小限 に抑える

■正解の選択肢と解説

正解：A. AWS Backup を設定し、必要なスケジュールに従ってバックアップを作成します。異なる AWS リージョンにバックアップボールトを作成します。AWS Backup を設定し、バックアップを異なる AWS リージョンのバックアップボールトにコピーします。

解説：
AWS Backup は、Amazon RDS・EBS・EFSなどを含む多くのサービスのバックアップを一元的に管理できるフルマネージドサービスです。クロスリージョンバックアップ機能により、指定したスケジュールに従って別リージョンのバックアップボールトへ自動コピーできます。これにより、「地理的分散」かつ「低運用負荷」という両方の要件を満たします。

■不正解の選択肢の理由

  • B. AZをまたぐ保存では不十分
    → アベイラビリティゾーンは同一リージョン内での冗長性にすぎず、「数百マイル離れた場所」の要件を満たさない。
  • C. DLM + S3 レプリケーションはRDSに非対応・複雑
    → Data Lifecycle Manager（DLM）は EBS スナップショット専用。RDS バックアップ管理には使えない上、S3 バケットへのコピーには手動ロジックが必要で、運用が煩雑。
  • D. DLM + Lambda + EventBridge は手作業が多く運用負荷大
    → DLM に加え、自作 Lambda と EventBridge のスケジュール管理が必要で、「最小限の運用オーバーヘッド」という要件に反する。

■SCS試験で押さえておくべきポイント

  • AWS Backup はクロスリージョンバックアップに対応し、RDS・EBS 両方を自動かつ一元的にバックアップ可能
  • **バックアップの地理的冗長性（災害対策）**には、「異なるリージョン」が必須。AZ 複数配置では不十分
  • **DLM（Data Lifecycle Manager）**は EBS 専用であり、RDS などには対応していない
  • 最小運用コスト = マネージドサービスを優先すべきシナリオが多い（Lambda などの自作処理は原則避ける）

続けて他の問題もあれば、お送りください。SCS視点で丁寧に解説します。

以下に、問題4の内容を指定フォーマットで整理・解説します。

■問題文（文字列を編集せずに出力）

ある会社には 2 つのソフトウェア開発チームがあり、機密データを Amazon S3 に保存するアプリケーションを作成しています。
各チームのデータは常に分離されている必要があります。会社のセキュリティチームは、両チームのデータ暗号化戦略を設計し、キーの使用状況を監査できるようにする必要があります。また、運用上のオーバーヘッドを最小限に抑える必要があります。

要件を満たす最適な方法を選択してください。

■選択肢（文字列を編集せずに出力）

A.
アプリケーションチームに、単一の AWS Key Management Service (AWS KMS) AWS マネージドキーで 2 つの異なる S3 バケットを使用するように指示します。キーポリシーを制限して、KMS キーのみの暗号化と復号化を許可します。チームが暗号化コンテキストを使用して暗号化と復号化を行うことを許可しないようにします。

B.
アプリケーションチームに、単一の AWS Key Management Service (AWS KMS) カスタマーマネージドキーで 2 つの異なる S3 バケットを使用するように指示します。キーポリシーを制限して、KMS キーのみの暗号化と復号化を許可します。チームが暗号化コンテキストを使用して暗号化と復号化を行うことを許可しないようにします。

C.
アプリケーションチームに、別々の AWS Key Management Service (AWS KMS) のカスタマーマネージドキーで 2 つの異なる S3 バケットを使用するように指示します。キーポリシーを制限して、KMS キーの暗号化と復号化をそれぞれのチームのみに許可します。チームに暗号化コンテキストを使用して暗号化と復号化を強制します。

D.
アプリケーションチームに、別々の AWS Key Management Service (AWS KMS) の AWS マネージドキーで 2 つの異なる S3 バケットを使用するように伝えます。キーポリシーを制限して、KMS キーの暗号化と復号化をそれぞれのチームのみに許可します。チームに暗号化コンテキストを使用して暗号化と復号化を強制します。

■問題文の要件の概要

  • 2チームのデータを分離
  • セキュリティチームがKMSキーの使用状況を監査可能
  • 運用負荷を最小限に
  • 暗号化戦略の明確化（キーとポリシーの管理が必要）

■正解の選択肢と解説

正解：C. アプリケーションチームに、別々の AWS Key Management Service (AWS KMS) のカスタマーマネージドキーで 2 つの異なる S3 バケットを使用するように指示します。キーポリシーを制限して、KMS キーの暗号化と復号化をそれぞれのチームのみに許可します。チームに暗号化コンテキストを使用して暗号化と復号化を強制します。

解説：
カスタマーマネージドキー（CMK）をチームごとに分けることでデータの論理分離が可能になります。さらに、暗号化コンテキストの強制とキーポリシーの制御により、アクセス制限と監査性を確保できます。
CMK なら CloudTrail での使用状況監査も可能で、かつ必要に応じてポリシーやローテーション設定も管理できるため、セキュリティ要件を満たしつつ運用負荷を抑えたベストプラクティスとなります。

■不正解の選択肢の理由

  • A. AWSマネージドキーを使用
    → AWSが管理するキーはポリシー制御ができず、キーごとのアクセス制御や詳細な監査に不向き。
  • B. 単一のカスタマーマネージドキーを使用
    → キーが共有されるため、チームごとの分離ができず、誤使用や誤アクセスのリスクが高まる。
  • D. AWSマネージドキーをチームごとに分ける
    → AWSマネージドキーはユーザーによるキー管理（削除、ポリシー変更等）ができないため、セキュリティチームの監査ニーズや制御要件に対応できない。

■SCS試験で押さえておくべきポイント

  • **KMSのカスタマーマネージドキー（CMK）**は、キーの完全な制御（ポリシー、ローテーション、監査）が可能
  • チームやアプリケーション単位でキーを分けることが、データ分離と権限分離のベストプラクティス
  • 暗号化コンテキストは追加的なセキュリティ制御（条件付きアクセス）として有効
  • AWSマネージドキーは簡易用途向けであり、セキュリティ要件が高いケースでは不適切

次の問題もあれば引き続きお送りください。丁寧に解説いたします。

以下に、問題5を指定フォーマットで整理・解説します。

■問題文（文字列を編集せずに出力）

AWS アカウント管理者は IAM グループを作成し、次の管理ポリシーを適用して、個々のユーザーが多要素認証を使用して認証することを要求しました。

{ 
 "Version": "2012-10-17", 
 "Statement": [
  { 
   "Effect": "Allow", 
   "Action": "ec2:*", 
   "Resource": "*" 
  }, 
  { 
   "Sid": "BlockAnyAccessUnlessSignedInWithMFA", 
   "Effect": "Deny", 
   "Action": "ec2:*", 
   "Resource": "*", 
   "Condition": { 
    "BoolIfExists": { 
     "aws:MultiFactorAuthPresent": false 
     } 
    } 
   } 
 ] 
}

ポリシーを実装した後、管理者は、ユーザーが AWS CLI を使用して Amazon EC2 コマンドを実行できないという報告を受け取ります。多要素認証を実施しながら、この問題を解決する最適な方法を選択してください。

■選択肢（文字列を編集せずに出力）

A.
ロールを作成し、ロールの信頼ポリシーで多要素認証を実施します。sts assume-role CLI コマンドを実行し、-serial-number と –token-code パラメータを渡すようにユーザに指示します。結果の値を環境変数に格納します。ポリシーの NotAction に sts:AssumeRole を追加します。

B.
SAML 2.0 を使用して API/CLI アクセスのフェデレーションを実装し、多要素認証を実施するように ID プロバイダーを構成します。

C.
aws sts get-session-token CLI コマンドを実行し、多要素認証の -serial-number と –token-code パラメーターを渡すようにユーザーに指示します。これらの結果の値を使用して、API/CLI 呼び出しを行います。

D.
aws:MultiFactorAuthPresent の値を true に変更します。

■問題文の要件の概要

  • IAM ポリシーで MFA を強制している
  • CLI からの EC2 操作が拒否されている
  • ユーザーはMFAで認証しているつもり
  • 解決策は「MFA の適切な CLI 認証方法」を提供すること

■正解の選択肢と解説

正解：C. aws sts get-session-token CLI コマンドを実行し、多要素認証の -serial-number と –token-code パラメーターを渡すようにユーザーに指示します。これらの結果の値を使用して、API/CLI 呼び出しを行います。

解説：
aws sts get-session-token は、ユーザーが MFA デバイスを用いて CLI/SDK で認証する際に使用する正しい方法です。このコマンドで MFA トークンを渡すことで、MFA 情報付きの**一時的な認証情報（セッショントークン）**を取得できます。その後、CLI の環境変数に下記のように設定することでアクセス可能になります：

export AWS_ACCESS_KEY_ID=...
export AWS_SECRET_ACCESS_KEY=...
export AWS_SESSION_TOKEN=...

この手順により aws:MultiFactorAuthPresent の条件が true になり、Deny ポリシーを回避してアクセスできるようになります。

■不正解の選択肢の理由

  • A. ロールと assume-role の構成を使う方法
    → 信頼ポリシー側で MFA 要求する構成も可能だが、IAM グループの既存の MFA 条件と競合しやすく、冗長かつ複雑。sts:AssumeRole を NotAction に追加するのも本質的な解決にならない。
  • B. SAML フェデレーションによる MFA
    → SAML + IdP による認証は可能だが、この課題に対しては過剰。既存の IAM ユーザーと CLI 利用の前提では非現実的。
  • D. aws:MultiFactorAuthPresent の値を true に変更
    → ポリシーの値は動的評価される条件キーであり、手動で true に変更することは意味がない。MFA セッションで自動的に true になるもの。

■SCS試験で押さえておくべきポイント

  • aws:MultiFactorAuthPresent 条件は MFA を通じた一時セッションでのみ true になる
  • CLI/SDK で MFA を使うには aws sts get-session-token が正解
  • IAM ポリシーで Deny + BoolIfExists: false の MFA強制条件はよく出題される
  • get-session-token で得られる一時認証情報は、CLI の環境変数に設定して使用
  • ロール/信頼ポリシーを使う MFAは別用途（例：クロスアカウント）

次の問題があれば、引き続きご提供ください。構文チェック・IAM条件キーの使い方なども詳しく解説いたします。

以下に、問題6を指定フォーマットで整理・解説します。

■問題文（文字列を編集せずに出力）

組織には IAM グループがあります。グループ内の各 IAM ユーザーには MFA デバイスが発行されており、Amazon S3 へのフルアクセス権を持っています。
組織は、グループのメンバーが、MFA 認証が完了した後にのみ、S3 操作を行うことができることを保証する必要があります。セキュリティエンジニアは、最小限の維持でこの目的を達成するシステムを構築する必要があります。

これらの条件を満たす方法の組み合わせを選択してください。(2 つ選択)

■選択肢（文字列を編集せずに出力）

A.
s3:* actions のためにグループ内のユーザーにお客様管理の拒否ポリシーを追加します。

B.
s3:* actions のためにグループにお客様管理の拒否ポリシーを追加します。

C.
s3:* actions のためにグループにお客様管理の許可ポリシーを追加します。

D.
ポリシーに条件を追加します :

"Condition" : { "BoolIfExists" : { "aws:MultiFactorAuthPresent" : false } }

E.
ポリシーに条件を追加します :

"Condition" : { "Bool" : { "aws:MultiFactorAuthPresent" : false } }

■問題文の要件の概要

  • IAMグループに属するユーザーがS3にアクセスする
  • MFAを使った後でのみ操作可能にしたい
  • メンテナンスコストを最小限にしたい
  • ポリシーレベルで MFA未使用時に明示的に拒否させる構成が必要

■正解の選択肢と解説

正解：B, D

✅ B. グループに拒否ポリシーを追加

解説：
IAMグループに対して適用することで、すべてのメンバーに一括で制限を適用でき、メンテナンスも最小限になります。個々のユーザーに設定するよりも管理が楽です。

✅ D. BoolIfExists を使った MFA 条件

解説：
以下のような拒否ポリシーを適用すると、MFA を使っていないリクエストを明示的に拒否できます：

{
  "Effect": "Deny",
  "Action": "s3:*",
  "Resource": "*",
  "Condition": {
    "BoolIfExists": {
      "aws:MultiFactorAuthPresent": "false"
    }
  }
}
  • BoolIfExists によって、MFA 情報が存在しない場合（たとえば、アクセスキーを使った CLI 呼び出し）もブロック対象になります。
  • よって、MFA を使わないリクエスト全般をカバー可能。

■不正解の選択肢の理由

  • A. 各ユーザーに拒否ポリシーを追加
    → 管理対象が多くなり、維持コストが高くなるため不適切。
  • C. グループに許可ポリシーを追加
    → 許可ポリシーだけでは MFA を条件に制限できず、明示的な拒否が必要。
  • E. Bool を使用
    → BoolIfExists を使わないと、キーが存在しない場合の処理が漏れる。これにより一部の MFA 未使用リクエストを拒否できなくなる可能性があります。

■SCS試験で押さえておくべきポイント

  • MFA を強制するには Deny + aws:MultiFactorAuthPresent: false の条件付きポリシーがベスト
  • BoolIfExists は、キーが存在しない状況にも対応できるためより安全
  • 拒否ポリシーは 許可よりも優先される（明示的 Deny）
  • ユーザー単位よりグループ単位でのポリシー付与の方が 管理性が高い

次の問題があればお知らせください。IAM 条件キーやポリシー設計は出題頻度が高いため、丁寧に解説します。

以下に、問題7を指定フォーマットで整理・解説します。

■問題文（文字列を編集せずに出力）

ある企業は、Amazon EC2 インスタンスを使用して、Application Load Balancer の背後でフロントエンドサービスをホストしています。Amazon Elastic Block Store (Amazon EBS) ボリュームは、EC2 インスタンスにアタッチされています。また、大容量の画像や音楽ファイルを保存するために Amazon S3 バケットを使用しています。

同社は、潜在的なランサムウェア攻撃を防止、識別、隔離するために、AWS にセキュリティアーキテクチャを実装しました。現在、さらなるリスク低減を目指しています。

セキュリティエンジニアは、攻撃者が予防的および検出コントロールを回避した場合でも、正常な運用に復旧できるディザスタリカバリソリューションを開発する必要があります。このソリューションは、1 時間の RPO を満たす必要があります。

これらの要件を満たすソリューションを選択してください。

■選択肢（文字列を編集せずに出力）

A.
AWS Backup を使用して、EC2 インスタンスと S3 バケットのバックアップを 1 時間ごとに作成します。既存のアーキテクチャコンポーネントを複製する AWS CloudFormation テンプレートを作成します。AWS CodeCommit を使用して、CloudFormation テンプレートをアプリケーション設定コードと一緒に保存します。

B.
4 時間ごとに EBS スナップショットを作成します。Amazon GuardDuty Malware Protection (マルウェア保護) を有効にします。GuardDuty で Execution:EC2/MaliciousFile の検出結果が生成された場合、直近のスナップショットを即時復元する自動化を構築します。

C.
Amazon Security Lake を使用して、AWS CloudTrail ログと VPC フローログ用の一元化されたデータレイクを作成します。これらのログを自動応答のために活用します。AWS Security Hub を有効にして、リカバリ手順の一元管理を確立します。既存のアーキテクチャコンポーネントを複製する AWS CloudFormation テンプレートを作成します。AWS CodeCommit を使用して、CloudFormation テンプレートをアプリケーション設定コードと一緒に保存します。

D.
AWS Backup を使用して、EBS ボリュームと S3 オブジェクトのバックアップを毎日作成します。Amazon Security Lake を使用して、AWS CloudTrail ログと VPC フローログ用の一元化されたデータレイクを作成します。これらのログを自動応答のために活用します。

■問題文の要件の概要

  • 企業は ALB 配下の EC2 + EBS 構成、S3 に大容量ファイル
  • すでに防御・検出は実装済（＝予防と検知策は前提）
  • 復旧（ディザスタリカバリ）に焦点がある
  • RPO（目標復旧時点）1時間以内を満たす必要あり

■正解の選択肢と解説

正解：A
**「AWS Backup を 1時間ごとに実行」＋「CloudFormation + CodeCommit による環境の即時再構築」**の組み合わせが最も適切。

解説：

  • AWS Backup で EC2・EBS・S3 を 1時間ごとにバックアップ
    → RPO（Recovery Point Objective）= 1時間 を満たすために必要。
  • CloudFormation テンプレートでインフラ復旧を自動化
    → 予測不能な障害発生時に迅速に復元可。
  • CodeCommit にテンプレートを保存し、継続的に構成管理
    → バージョン管理とインフラのコード化（IaC）により安定性確保。

■不正解の選択肢の理由

  • B. EBSスナップショットを4時間ごと
    • ❌ RPO要件（1時間）を満たせない
    • GuardDuty は検出ツールであり、復旧主体ではない。
  • C. Security Lake + CloudFormation による復旧
    • ❌ バックアップ戦略が存在しない
    • ログ分析や自動応答はできても、消失データの復元は不可能
  • D. 毎日バックアップ
    • ❌ バックアップ頻度が低すぎてRPO不達成
    • 1日単位では、最大23時間のデータ損失が発生しうる。

■SCS試験で押さえておくべきポイント

  • RPO（Recovery Point Objective）とバックアップ頻度は一致させること
    • RPO1時間 → バックアップも1時間ごとが必須
  • AWS Backup は EBS, S3, RDS 等のスナップショットを一元管理可能
  • CloudFormation + CodeCommit で IaC による構成復旧を自動化
  • GuardDuty, Security Hub, Security Lake などは「防御・検出」側のサービスであり、「復旧」には不十分
  • ランサムウェア対策は多層的アプローチ：検出 + バックアップ + 自動復元が重要

引き続き、次の問題があればお送りください。RPO/RTO や災害復旧の設計もよく出題されるテーマです。

RELATED POST