以下に、問題1 を指定の形式で整理・解説します。
■ 問題文
ある企業は、Amazon RDS スナップショットのデータライフサイクル管理を実装する必要があります。企業は AWS Backup を使用してスナップショットを管理します。
企業は RDS の自動スナップショットを 5 年間保持し、長期アーカイブストレージとして Amazon S3 を使用します。
これらの要件を満たすソリューションを選択してください。
■ 選択肢
A.
AWS Backup が RDS スナップショット用に使用する S3 バケットでバージョニングを有効にし、5 年間の保持期間を設定します。
B.
AWS Backup を使用して、RDS スナップショットに 5 年間の保持タグを適用します。
C.
S3 ライフサイクルポリシーを作成します。AWS Backup が RDS スナップショット用に使用する S3 バケットに 5 年間の保持期間を含めます。
D.
AWS Backup でバックアッププランを作成し、5 年間の保持期間を設定します。
■ 問題文の要件の概要
- Amazon RDS スナップショットのライフサイクル管理を行いたい
- 管理手段は AWS Backup を使用する
- 5年間の保持期間
- 長期保管は S3 アーカイブストレージ(Glacierなど)を想定
■ 正解の選択肢と解説
✅ D. AWS Backup でバックアッププランを作成し、5 年間の保持期間を設定します。
- 理由:
AWS Backup では、RDSを含むサービスのバックアップを一元管理でき、バックアッププラン内の「保持期間(Retention period)」に最大5年間などを設定可能です。
また、AWS Backup は内部的にバックアップデータを専用ストレージに保管し、保持期間終了後は自動で削除されます。さらに、長期保存が必要な場合には、Glacier / Glacier Deep Archive への移行設定も可能です。
■ 不正解の選択肢の理由
選択肢 | 誤りの理由 |
---|---|
A. S3バージョニング+保持期間 | AWS Backup が使用する S3 バケットは ユーザーが直接操作・設定できない。バージョニングやライフサイクルの設定はできない。 |
B. タグを適用 | タグには保持期間の制御機能はない。AWS Backup の保持管理は バックアッププランのルールで実施すべき。 |
C. S3ライフサイクルポリシーの使用 | RDS スナップショットは直接 S3 に格納されないし、S3 ライフサイクルポリシーでは AWS Backup の保持管理はできない。 |
■ SCS試験で押さえておくべきポイント
- AWS Backup の保持期間管理は「バックアッププラン内のルール」で定義する
→ タグや手動S3設定では管理しない - RDS、EC2、EFS などのリソースのスナップショットやバックアップを一元的に管理できる
- 長期保持・アーカイブニーズには、Glacier / Glacier Deep Archive との連携が有効
- S3 ライフサイクルは S3 オブジェクト用のものであり、RDS スナップショットには関係しない
続けて他の問題もご希望であれば、送ってください。全てこの形式で丁寧に解説します。
以下に 問題2 を指定フォーマットで整理して解説します。
■ 問題文
あるセキュリティエンジニアが、会社の AWS 環境に対してログ記録ソリューションを実装しています。セキュリティエンジニアは会社の AWS アカウントで AWS CloudTrail の証跡を設定しました。ログは Amazon S3 バケットに保存され、サードパーティーのサービスプロバイダーが監視します。サービスプロバイダーには、その S3 バケットへアクセスするための専用 IAM ロールがあります。
会社は、すべてのログをカスタマーマネージドキーで保存時に暗号化する必要があります。セキュリティエンジニアは AWS Key Management Service (AWS KMS) を使用してカスタマーマネージドキーとキーポリシーを作成しました。また、セキュリティエンジニアは、そのキーを使用して証跡を暗号化するように CloudTrail を設定します。
セキュリティエンジニアがこの設定を実装すると、サービスプロバイダーはログを読み取れなくなります。
サービスプロバイダーがログを読み取れるようにする最適な方法を選択してください。
■ 選択肢
A.
S3 バケットポリシーで、サービスプロバイダーのロールがオブジェクトを復号化できるようにアクセスを許可します。
B.
キーポリシーにステートメントを追加して、サービスプロバイダーのロールにキーの kms:Decrypt
アクションを許可します。
C.
キーを AWS Certificate Manager (ACM) に移行して、キーにアクセスするための共有エンドポイントを作成します。
D.
サービスプロバイダーのロールに AWSKeyManagementServicePowerUser
の AWS マネージドポリシーを追加します。
■ 問題文の要件の概要
- CloudTrail ログを KMS カスタマーマネージドキーで暗号化
- ログは S3 に保存
- ログを 外部サービス(サービスプロバイダー)が IAM ロール経由で読み取り
- しかし、暗号化設定後は ログの復号ができない状態
- → 解決策は「KMS キーに対する復号権限の追加」
■ 正解の選択肢と解説
✅ B. キーポリシーにステートメントを追加して、サービスプロバイダーのロールにキーの kms:Decrypt
アクションを許可します。
- 理由:
CloudTrail ログは KMS キーによって暗号化されており、S3 にアクセスできても KMS キーの復号権限がなければ読み取れません。そのため、KMS キーポリシーにサービスプロバイダーの IAM ロールに対してkms:Decrypt
権限を追加することで復号が可能になります。
■ 不正解の選択肢の理由
選択肢 | 理由 |
---|---|
A. S3 バケットポリシーで復号許可 | バケットポリシーは S3 オブジェクトへのアクセス制御のみで、KMS の復号権限は別途キーポリシーで設定が必要。 |
C. ACM にキーを移行 | KMS のキーは ACM に移行できない。そもそも ACM は証明書の管理サービスであり、KMS 暗号鍵の代替にならない。 |
D. PowerUser ポリシーを追加 | AWSKeyManagementServicePowerUser は多くの KMS 操作を許可するが、対象キーのキーポリシーに明示的に許可されていなければ復号は不可。 |
■ SCS試験で押さえておくべきポイント
- KMS 暗号化されたデータへのアクセスには、KMS キーポリシーに明示的な
kms:Decrypt
の許可が必要 - IAM ポリシーだけでなく、KMS キーポリシーとの組み合わせで評価される
- S3 バケットが KMS 暗号化を使用している場合、S3 ポリシーだけでは不十分
- AWS Certificate Manager(ACM)と KMS の違いを理解しておくこと
次の問題も必要であれば送ってください。引き続きこの形式で解説いたします。
以下に 問題3 を指定フォーマットで整理・解説します。
■ 問題文
ある企業が IAM ロールによって実行されたアクションを調査しています。ロールが最後に AWS Security Hub にアクセスした日時と、ロールが最後に Security Hub で DeleteInsight アクションを使用した日時を特定する必要があります。
この情報を提供するソリューションを選択してください。
■ 選択肢
A.
AWS Identity and Access Management (IAM) を使用して認証情報レポートを生成します。レポートで Security Hub のアクティビティを検索します。
B.
AWS Identity and Access Management (IAM) の [アクセスアドバイザー] タブを使用します。Security Hub と実行されたアクションを検索します。
C.
AWS Identity and Access Management Access Analyzer でアナライザーを作成します。Security Hub でのロールのアクションに関する調査結果を調べます。
D.
AWS Trusted Advisor のセキュリティカテゴリのチェックを使用します。ロールを検索し、実行されたアクションを調べます。
■ 問題文の要件の概要
- IAMロールによるSecurity Hubへのアクセス履歴を知りたい
- アクセス日時と、DeleteInsightアクションの実行日時を特定したい
- 目的:監査や不正使用の検出・調査
■ 正解の選択肢と解説
✅ B. IAM の [アクセスアドバイザー] タブを使用します。
- 理由:
IAM のアクセスアドバイザーは、そのロールまたはユーザーが最後にアクセスした AWS サービス(例:Security Hub)とそのアクセス日時を表示する機能です。これにより「Security Hub にいつアクセスしたか」がわかります。 - 補足:
ただし、具体的なアクション(例:DeleteInsight)を特定するには CloudTrail での調査が本来必要ですが、本問では IAM の機能にフォーカスしており、選択肢の中では最も要件に近いのが B です。
■ 不正解の選択肢の理由
選択肢 | 理由 |
---|---|
A. IAM の認証情報レポート | 認証情報レポートはアクセスキーの有効性やMFA有無などセキュリティ状態を示すものであり、サービスの利用履歴は含まれません。 |
C. IAM Access Analyzer | リソースへの意図しないアクセス(外部アクセス)を検出するツールであり、実行された操作履歴やタイムスタンプの記録は提供しません。 |
D. AWS Trusted Advisor | セキュリティベストプラクティスのチェックツールで、アクション実行履歴や日時の確認には使えません。 |
■ SCS試験で押さえておくべきポイント
- IAM アクセスアドバイザーは「どの IAM エンティティが、どの AWS サービスに最後にアクセスしたか」を把握するための重要機能
- 具体的な API アクション(例:DeleteInsight)の記録は AWS CloudTrail を使う
- IAM Access Analyzerは「ポリシーの検証や外部アクセスの検出」、アクセスアドバイザーは「実際の使用実績を確認」する目的で使われる
- 認証情報レポートはユーザーのセキュリティ状態(パスワード有効/無効、アクセスキー状態など)を知るためのもの
他の問題もあれば、引き続きこの形式で解説可能です。お気軽にお送りください。
以下に 問題4 を指定フォーマットで整理・解説します。
■ 問題文
ある企業は、AWS Organizations を使用して数百の AWS アカウントを管理しています。企業は、プロダクトチーム、セキュリティチーム、プラットフォームチームのために、さまざまな IAM ロール および IAM ポリシー を作成する予定です。一部の IAM ポリシーは、チーム間で共有されます。
セキュリティエンジニアは、各チームの IAM ロールを論理的にグループ化するソリューションを実装する必要があります。また、このソリューションは、プラットフォームチームのみが AWS サービスへの IAM 権限を委任できる ようにする必要があります。
これらの要件を満たすソリューションを選択してください。
■ 選択肢
A.
各チームの異なるタグを IAM ロールに適用します。プラットフォームチームのロールを除くすべてのエンティティに対して sts:AssumeRole
権限を拒否する SCP をデプロイします。
B.
各チームの異なるタグを IAM ポリシーに適用します。プラットフォームチームのポリシーを除くすべてのエンティティに対して iam:PassRole
権限を拒否する SCP をデプロイします。
C.
各チームの IAM ロールを使用して IAM パスを設定します。プラットフォームチームの IAM パスを除くすべてのエンティティに対して iam:PassRole
権限を拒否する SCP をデプロイします。
D.
各チームの IAM ロールを使用して IAM パスを設定します。IAM 権限の境界を使用して、製品チームとセキュリティチームの IAM ロールに sts:AssumeRole
権限を拒否します。
■ 問題文の要件の概要
- AWS Organizations を使用
- IAM ロールをチーム単位で論理的にグループ化する必要あり
- プラットフォームチームだけが IAM 権限(
iam:PassRole
)を委任できる必要あり
■ 正解の選択肢と解説
✅ C. 各チームの IAM ロールを使用して IAM パスを設定します。プラットフォームチームの IAM パスを除くすべてのエンティティに対して iam:PassRole
権限を拒否する SCP をデプロイします。
- 理由:
IAM パスは、ロールやポリシーを論理的に階層化・分類できるメカニズムです(例:/platform/
、/security/
)。
これを活用すると、SCP(Service Control Policy)で IAM パス単位に権限制御が可能になります。 iam:PassRole
の制限:iam:PassRole
権限がないと、EC2 や Lambda などに IAM ロールを渡せません。これを プラットフォームチーム専用に制限することで、委任操作を一元管理できます。
■ 不正解の選択肢の理由
選択肢 | 誤りの理由 |
---|---|
A. sts:AssumeRole を拒否 | ロールの利用そのものを妨げることになり、各チームの通常業務にも支障が出る。目的は「委任(PassRole)」の制限であり、AssumeRole の制限ではない。 |
B. ポリシーにタグ付け | IAM ポリシーへのタグは SCP の制御対象には使えない。制御するべきは IAM ロール(パスまたはタグ)であって、ポリシーではない。 |
D. 権限の境界で sts:AssumeRole を拒否 | 権限の境界(Permissions boundary)は、許可の上限を制限するものであり、拒否を明示的に定義できない。また、iam:PassRole には使えない。 |
■ SCS試験で押さえておくべきポイント
- IAM パスを使うと、ロールやポリシーを階層的に整理・制御できる(例:
/product/
,/security/
,/platform/
)。 - **SCP(Service Control Policy)**は IAM パスと組み合わせることで、特定グループに対する サービスアクセスや権限委任を精密に制御できる。
iam:PassRole
は AWS サービスへのロール委任に必要な権限 → これを誰ができるかは厳密に制御すべきセキュリティポイント- IAM のタグやポリシータグは SCP では直接制御に使えない。
引き続き、問題を送っていただければこの形式で解説いたします。
以下に 問題5 を指定フォーマットで整理・解説します。
■ 問題文
ある企業が AWS Organizations を使用して、複数の AWS アカウントを持つ環境を構築しました。この企業の組織には現在 2 つの AWS アカウントがあり、今後 12 ヶ月の間に 50 以上の AWS アカウントが追加される予定です。同社は、既存および将来のすべての AWS アカウントで Amazon GuardDuty を使用することを義務付けます。既存の各 AWS アカウントは、GuardDuty が有効になっています。同社は、各 AWS アカウントに個別にログインして、GuardDuty の検出結果を確認しています。
同社は、既存の AWS アカウントと将来の AWS アカウントについて、GuardDuty の検出結果を一元的に表示することを望んでいます。また、新しい AWS アカウントで GuardDuty が自動的にオンになるようにする必要があります。
これらの要件を満たすソリューションを選択してください。
■ 選択肢
A.
組織に新しい AWS アカウントを作成します。新しいアカウントで GuardDuty を有効にします。新しいアカウントを、GuardDuty の委任された管理者アカウントとして指定します。既存のアカウントをメンバーアカウントとして追加するように GuardDuty を設定します。新しい AWS アカウントを組織に自動的に追加するオプションを選択します。
B.
組織に新しい AWS アカウントを作成します。新しいアカウントで GuardDuty を有効にします。各アカウントで AWS Security Hub を有効にします。新しい AWS アカウントを組織に自動的に追加するオプションを選択します。
C.
組織の管理アカウントで AWS Security Hub を有効にします。管理アカウントを Security Hub の委任された管理者アカウントとして指定します。既存のアカウントをメンバーアカウントとして追加します。新しい AWS アカウントを組織に自動的に追加するオプションを選択します。すべての Security Hub の検出結果を組織の GuardDuty アカウントに送信します。
D.
組織の管理アカウントで AWS Security Hub を有効にします。すべての GuardDuty の検出結果を Security Hub に送信するように、管理アカウント内で GuardDuty を構成します。
■ 問題文の要件の概要
- GuardDuty を 既存と将来の全アカウントで有効にしたい
- GuardDuty の 検出結果を一元的に確認したい(=中央管理)
- 新しいアカウントで GuardDuty を自動有効化したい
■ 正解の選択肢と解説
✅ A. 新しいアカウントで GuardDuty を有効にし、それを委任管理者とする
- 理由:
GuardDuty では、AWS Organizations の仕組みを利用して、特定のアカウントを“委任された管理者”に指定することが可能です。この委任管理者アカウントを通じて、組織全体の GuardDuty の結果を一元管理できます。 - また、**“自動的に組織内の新規アカウントを GuardDuty に追加”**するオプションもあり、将来的に増えるアカウントにも自動で対応可能です。
■ 不正解の選択肢の理由
選択肢 | 理由 |
---|---|
B | GuardDuty の委任管理者設定がなく、一元管理ができない。Security Hub は補完的な統合ビューのみを提供。 |
C | GuardDuty の自動有効化や一元管理には Security Hub の委任管理者では不十分。Security Hub は GuardDuty 結果を参照できるが、GuardDuty 自体の設定を管理できない。 |
D | Security Hub だけでは GuardDuty の中央管理は不可能。また、GuardDuty の自動有効化機能を提供しない。 |
■ SCS試験で押さえておくべきポイント
- GuardDuty 委任管理者アカウントは、AWS Organizations 内で中央管理する際に必須。
- 自動的にメンバーアカウントを GuardDuty に追加する設定は、ガバナンスの効率化に重要。
- Security Hub は GuardDuty の統合ビューを提供するが、GuardDuty の検出と設定自体は別物。
- SCS 試験では、**組織全体のセキュリティサービスの集中管理(Security Hub, GuardDuty, Macieなど)**が頻出テーマ。
この問題は GuardDuty の設計・運用ポリシーに関する理解を問う良問です。引き続き問題があれば送ってください。
以下に 問題6 を指定フォーマットで整理・解説します。
■ 問題文
ある企業がデフォルトの SCP で AWS Organizations を使用しています。同社は、特定の OU 内のすべての AWS アカウントに対して AWS の使用を制限する必要があります。
指定された一部のグローバルサービスを除き、この OU 内のすべてのアカウントの AWS 利用は eu-west-1 リージョンのみに制限されなければなりません。セキュリティエンジニアは、この制限を既存のアカウントと OU 内の新しいアカウントに適用する SCP を作成する必要があります。
■ 選択肢
A.
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "DenyNonDefaultRegions",
"Effect": "Allow",
"NotAction": [ <desired global services> ],
"Resource": "*",
"Condition": {
"StringNotEquals": {
"aws:RequestedRegion": ["eu-west-1"]
}
}
}
]
}
B.
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "DenyNonDefaultRegions",
"Effect": "Deny",
"NotAction": [ <desired global services> ],
"Resource": "*",
"Condition": {
"StringEquals": {
"aws:RequestedRegion": ["eu-west-1"]
}
}
}
]
}
C.
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "DenyNonDefaultRegions",
"Effect": "Allow",
"Action": [ <desired global services> ],
"Resource": "*",
"Condition": {
"StringEquals": {
"aws:RequestedRegion": ["eu-west-1"]
}
}
}
]
}
D.
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "DenyNonDefaultRegions",
"Effect": "Deny",
"NotAction": [ <desired global services> ],
"Resource": "*",
"Condition": {
"StringNotEquals": {
"aws:RequestedRegion": ["eu-west-1"]
}
}
}
]
}
■ 正解の選択肢と解説
✅ D. Effect: Deny
と StringNotEquals: eu-west-1
により、eu-west-1 以外を拒否
Effect: "Deny"
により、強制的にアクセス拒否を実施。Condition: "StringNotEquals": "eu-west-1"
により、eu-west-1 以外のリージョンでの操作を拒否。NotAction
にグローバルサービスを指定することで、それらは拒否対象外。
✅ これは、eu-west-1 での操作と指定グローバルサービスの利用のみを許容する構文であり、要件に完全に一致します。
■ 不正解の選択肢と理由
選択肢 | 理由 |
---|---|
A | Effect: Allow では制限にならず、許可しか行えないため、他の SCP と競合して不要にアクセスが許可されるリスクあり。 |
B | "StringEquals": "eu-west-1" は 逆の意味になり、本来許可したい eu-west-1 へのアクセスを拒否してしまうため不適切。 |
C | Effect: Allow だけでは他リージョンを明示的に拒否できず、リージョン制限の SCP には使えない。 |
■ SCS試験で押さえておくべきポイント
- SCP(Service Control Policy)では “Deny” の使用が強力かつ優先される。
aws:RequestedRegion
を活用することで リージョン制限が可能。StringNotEquals
+"Effect": "Deny"
= 特定の値以外すべて拒否という構文になる。- グローバルサービスは
NotAction
に指定することで例外的に許可可能。 - SCP は許可の追加ではなく アクセスの制限(Deny)に主眼を置くべき。
追加で疑問や SCP ポリシー構文の練習をしたい場合も、引き続き対応します。
以下に 問題7 を指定の形式で整理・解説します。
■ 問題文
ある企業は、Amazon S3 バケットからオブジェクトを読み取る必要があるアプリケーションを運用しています。企業は IAM ポリシーを作成し、そのポリシーをアプリケーションが使用する IAM ロールにアタッチしました。アプリケーションが S3 バケットからオブジェクトを読み取ろうとすると、AccessDenied
エラーを受け取ります。
セキュリティエンジニアは、S3 バケットまたはアプリケーションのセキュリティを低下させることなく、この問題を解決する必要があります。
■ 選択肢
A.
S3 バケットにリソースポリシーをアタッチし、ロールに読み取りアクセスを許可します。
B.
AWS Identity and Access Management Access Analyzer を使用して IAM ポリシーを確認し、ポリシーが正しい権限を付与していることを確認します。さらに、アプリケーションがロールを正しく引き受けていることを検証します。
C.
S3 バケットで S3 パブリックアクセスブロック機能が無効になっていることを確認します。AWS CloudTrail ログを確認して、アプリケーションがロールを正しく引き受けていることを検証します。
D.
別の AWS リージョンでアプリケーションの新しいデプロイメントを起動し、そのアプリケーションにロールをアタッチします。
■ 正解の選択肢と解説
✅ B. IAM Access Analyzer でポリシーとロール引き受けを検証する
- AccessDenied の原因を調査するには、まず IAM ポリシーが適切に設定されているかを確認することが重要。
- また、アプリケーションが正しく IAM ロールを引き受けていない可能性もある。
- IAM Access Analyzer は、ポリシー検証や未使用のアクセス許可検出に使える強力なツールで、セキュリティを低下させずに問題の特定と解決が可能。
■ 不正解の選択肢とその理由
選択肢 | 理由 |
---|---|
A | リソースポリシーを使うと、IAM ロールの設定ミスを隠したり、不要な許可が追加されてしまう可能性がある。最小権限の原則に反し、不要な複雑性やセキュリティリスクを増やす。 |
C | S3 パブリックアクセスブロックは、外部からの匿名・パブリックアクセスを制御する機能であり、IAM ロール経由のアクセスには関係しない。根本原因に関係のない設定。 |
D | リージョンを変更しても IAM ポリシーや S3 のアクセス権限に変化はない。構成ミスはどのリージョンでも再現するため、無意味な対処法。 |
■ SCS試験で押さえておくべきポイント
- AccessDenied の根本原因調査には、IAM ロールの引き受け状況とポリシーの内容確認が必須。
- IAM Access Analyzer は以下の目的で使える:
- IAM ポリシーの構文とベストプラクティスチェック
- 想定どおりのアクセス許可が付与されているかを検証
- リソースが外部に共有されていないか確認
- リソースポリシーや設定変更で解決を試みる前に、既存のIAM構成が正しいかを診断するのが先。
疑問点や Access Analyzer の具体的な使い方についても、いつでも質問してください。