#46｜SalmonLog

以下は「問題1」の解説を、ご指定の形式に従って整理したものです。

■ 問題文（文字列を編集せずに出力してください。）

ある企業は、AWS Organizations を使用しています。コンプライアンス要件によると、この企業のアプリケーションは、Amazon EC2 インスタンスでホストされています。Amazon EC2 インスタンスは、インスタンスメタデータサービスバージョン 1 (IMDSv1) の IAM 認証情報を使用してはなりません。

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

■ 選択肢（文字列を編集せずに出力してください。）

A.
AWS Organizations のルート OU に次の SCP をアタッチします。

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Deny",
      "Action": "*",
      "Resource": "*",
      "Condition": {
        "NumericLessThan": {
          "ec2:RoleDelivery": "2.0"
        }
      }
    }
  ]
}

B.
HTTP で 169.254.169.254 へのアクセスを拒否するセキュリティグループを作成します。このセキュリティグループをすべての EC2 インスタンスにアタッチします。

C.
AWS CLI、AWS API、または AWS マネジメントコンソールを使用して EC2 インスタンスを起動するときに、インスタンスメタデータオプションを介して IMDSv1 へのすべてのアクセスを無効にします。

D.
AWS Organizations のルート OU に次の SCP をアタッチします。

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Deny",
      "Action": "ec2:RunInstances",
      "Resource": "arn:aws:ec2:*:*:instance/*",
      "Condition": {
        "StringNotEquals": {
          "ec2:MetadataHttpTokens": "required"
        }
      }
    }
  ]
}

■ 問題文の要件の概要

EC2インスタンスで IMDSv1 の IAM 認証情報使用を完全に禁止する必要がある。
対象は すべてのインスタンス（新規・既存問わず）
組織全体（AWS Organizations）に適用できる方法が望ましい。

■ 正解の選択肢と解説

正解：A

AWS Organizations のルート OU に、ec2:RoleDelivery が 2.0 未満の操作を拒否する SCP を設定する

解説：
この SCP は、ec2:RoleDelivery コンテキストキーを使い、IMDSv2 のみを許可する仕組みです。

ec2:RoleDelivery が 2.0 未満、すなわち IMDSv1 の場合にアクセスを拒否することで、IAM 認証情報の IMDSv1 経由の取得をブロックします。
すべてのアクションに適用されるため、IMDSv1 使用の可能性を完全に排除できます。

■ 不正解の選択肢の理由

B. セキュリティグループで 169.254.169.254 をブロック
→ セキュリティグループは 外部との通信には使えますが、ローカルホスト（169.254.x.x）へのアクセス制限は不可能。IMDS 制御には使えません。

C. 起動時に手動で IMDSv1 を無効化する
→ 手動操作は人的ミスが入りやすく一貫性を保証できないため、コンプライアンス対応としては不十分。SCP のような強制手段が望ましい。

D. ec2:MetadataHttpTokens を required にする SCP を使う
→ この SCP は IMDSv2 を使う新規インスタンス起動を強制できますが、既存のインスタンスには影響しない。完全な制御は不可。

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

IMDSv2 の強制には ec2:RoleDelivery 条件キーを使う SCP が有効
ec2:MetadataHttpTokens はインスタンス起動時の IMDS オプション制御に有効だが、既存インスタンスに影響しない
セキュリティグループではメタデータサービスのアクセス制御はできない
手動設定に頼るのは非推奨。Organizations + SCP による一括制御がベストプラクティス

次の問題があれば、引き続きHTML形式でお送りください。丁寧に対応します。

以下は「問題2」に関するAWS Certified Security – Specialty 試験対策としての詳細な解説です。

■ 問題文（文字列を編集せずに出力してください。）

ある企業が、AWS Abuse チームから電子メールメッセージを受け取りました。メッセージには、その企業の AWS アカウントの IAM ユーザーが、関連するアクセスキーとシークレットアクセスキーのペアをパブリックコードリポジトリに公開したことが記載されています。

特定された IAM ユーザーは、サービスアカウントとして指定されています。この IAM ユーザーは、お客様向けの重要な本番アプリケーションでハードコードされた認証情報を使用しています。同社の AWS アカウント内に侵害の兆候はありません。アプリケーションのダウンタイムを最小限に抑えるソリューションを実装することで、この状況に対処する必要があります。

これらの要件を満たす最適な手順を選択してください。

■ 選択肢（文字列を編集せずに出力してください。）

A.
IAM ユーザーに関連付けられた一時的な AWS Security Token Service (AWS STS) の認証情報をすべて取り消します。公開されている IAM アクセスキーを無効にします。IAM ユーザー用の新しいアクセスキーとシークレットアクセスキーのペアを作成します。新しい認証情報を使用するようにアプリケーションを更新します。IAM ユーザーに関連付けられた AWS マネジメントコンソールの認証情報をすべて削除します。

B.
IAM ユーザーに関連付けられているすべての AWS マネジメントコンソールの認証情報を削除します。IAM ユーザーのための新しいアクセスキーとシークレットアクセスキーのペアを作成します。新しい認証情報を使用するためにアプリケーションを更新します。公開されている IAM アクセスキーを無効にします。IAM ユーザーに関連付けられた一時的な AWS Security Token Service (AWS STS) の認証情報をすべて取り消します。

C.
公開されている IAM アクセスキーを無効にします。IAM ユーザー用の新しいアクセスキーとシークレットアクセスキーのペアを作成します。新しい認証情報を使用するようにアプリケーションを更新します。IAM ユーザーに関連付けられた一時的な AWS Security Token Service (AWS STS) の認証情報をすべて取り消します。IAM ユーザーに関連付けられた AWS マネジメントコンソールの認証情報をすべて削除します。

D.
IAM ユーザーに関連付けられた AWS マネジメントコンソールの認証情報をすべて削除します。IAM ユーザーのために新しいアクセスキーとシークレットアクセスキーのペアを作成します。公開されている IAM アクセスキーを無効にします。IAM ユーザーに関連付けられた一時的な AWS Security Token Service (AWS STS) の認証情報をすべて取り消します。新しい認証情報を使用するようにアプリケーションを更新します。

■ 問題文の要件の概要

アクセスキーが外部に漏洩している（コードリポジトリに公開された）
影響を受けた IAM ユーザーは サービスアカウントとして本番アプリで使用中
インシデントの痕跡はまだないが、即時対応が必要
アプリケーションのダウンタイムを最小限に抑えることが重要

■ 正解の選択肢と解説

正解：C

公開されている IAM アクセスキーを無効にします。IAM ユーザー用の新しいアクセスキーとシークレットアクセスキーのペアを作成します。新しい認証情報を使用するようにアプリケーションを更新します。IAM ユーザーに関連付けられた一時的な AWS Security Token Service (AWS STS) の認証情報をすべて取り消します。IAM ユーザーに関連付けられた AWS マネジメントコンソールの認証情報をすべて削除します。

解説：
漏洩したアクセスキーは即座に無効化し、その後新しい認証情報でアプリケーションを更新することでダウンタイムを防ぎます。
次に、既存のSTSセッション（一時的なトークン）をすべて無効にすることで、不正アクセスの可能性を排除。
最後に、コンソールログイン情報も削除することで、すべてのアクセス経路を遮断し、万が一の再発や未検知の脅威に備えます。

■ 不正解の選択肢の理由

A・B・D 共通の問題：

STS認証情報の取り消しやマネジメントコンソール認証情報の削除を先に実施している点が問題です。
その前にまず新しい認証情報でアプリケーションを更新する必要がある。順番を誤ると、アプリケーションの停止（ダウンタイム）につながるリスクがあります。

A の問題点：

STS認証情報の取り消しが アプリ更新よりも先 → ダウンタイムの原因となる。

B の問題点：

公開キーを最初に無効化していない → 外部からのアクセスリスクが残る。

D の問題点：

コンソール認証削除やキー作成が先 → 不正利用防止より前に操作しており、公開キーがすぐに無効化されていない。

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

アクセスキーの漏洩時は 即時にキーを無効化 するのが第一優先。
アプリケーション側に新しいキーを適用してから、STSセッションの取り消しを行うと、サービス影響を抑えられる。
IAMユーザーの代わりに、IAMロールやフェデレーションの利用を検討すると、将来的なキー漏洩のリスクが減る。
一時的なSTS資格情報の取り消しは revoke-session などの対応で実施。
AWS Security Blog にある「アクセスキー漏洩時の対応フロー」は必読。

続きの問題もあれば、HTML形式で送ってください。順に解析していきます。

以下は「問題3」の解説を、AWS Certified Security – Specialty 試験向けにご指定の形式でまとめたものです。

■ 問題文（文字列を編集せずに出力してください。）

企業は、チームごとに AWS アカウントを提供します。各チームのメンバーは、自分のチームアカウントのユーザーアカウントを使用して AWS で認証します。

会社は、3 つ以上のチームによる共同作業のために、プロジェクト固有の AWS アカウントを作成しました。同社は、この新しいアカウント内に新しい Amazon S3 バケットも作成しました。S3 バケットポリシーや S3 ACL はありません。セキュリティエンジニアは、すべてのチームが S3 バケットに保存されているオブジェクトを読み書きできるように、安全なソリューションを実装する必要があります。

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

■ 選択肢（文字列を編集せずに出力してください。）

A.
S3 バケットが存在する同じ AWS アカウントで、バケットに対する適切なアクセス許可を持つ IAM ロールを作成します。チームの AWS アカウントをプリンシパルとして指定する信頼ポリシーを含めます。チームは、オブジェクトを読み取り、バケット内のオブジェクトに書き込むときに、ロールを引き受けます。

B.
S3 バケットが存在する同じ AWS アカウントで、バケットポリシーを追加して、すべてのチームがオブジェクトを読み取り、バケット内のオブジェクトに書き込むことを許可します。チームは、オブジェクトを読み取り、バケット内のオブジェクトに書き込むときに、バケットが配置されている AWS アカウントのアカウント番号を指定します。

C.
S3 バケットが存在する同じ AWS アカウントで、バケットの ACL を更新して、チームの AWS アカウントの正規ユーザー ID を含めます。チームは、オブジェクトを読み取り、バケット内のオブジェクトに書き込むときに、バケットが配置されている AWS アカウントのアカウント番号を指定します。

D.
S3 バケットが存在する同じ AWS アカウントで、IAM ユーザー、IAM グループ、および各チームのアクセスキーを作成します。各チームは、バケット内のオブジェクトの読み取りと書き込みを行うときに、アクセスキーを共有します。

■ 問題文の要件の概要

プロジェクト用の 共通 AWS アカウントに作成した S3 バケット に対し、
複数チーム（複数AWSアカウント） から セキュアかつ双方向（読み書き）アクセス させたい
バケットポリシーやACLは使用していない状態

■ 正解の選択肢と解説

正解：A

IAMロールを使ったクロスアカウントアクセスの構成がベストプラクティス。

解説：

プロジェクト用アカウントにIAMロールを作成し、必要なS3アクセス権限（GetObject、PutObjectなど）を付与
信頼ポリシーで、各チームのアカウントからのAssumeRoleを許可
各チームは、自身のアカウントでAssumeRoleを実行し、一時的な認証情報で安全にS3へアクセス

この方法の利点：

キー共有不要、きめ細かい権限制御が可能
管理・監査が容易（CloudTrail でロールの利用状況を追跡可能）
AWS推奨のクロスアカウントアクセス方式

■ 不正解の選択肢の理由

B. バケットポリシーで全チームを許可
→ バケットポリシーを使うと、細かい権限管理が難しくなり、バケット全体への広範なアクセスを許可してしまいがち。
また、アカウント数が増えると、ポリシーの肥大化・メンテナンスが困難。

C. バケットACLの更新でアクセス許可
→ ACLは推奨されない古いアクセス管理手法。正規ユーザーIDの管理も複雑で、柔軟性・セキュリティに欠ける。

D. IAMユーザーを作成しアクセスキーを共有
→ アクセスキー共有はセキュリティリスクが非常に高い。
キーの漏洩リスク・権限の乱用・追跡の困難さなど、AWSのベストプラクティスに完全に反する方法。

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

クロスアカウントアクセスにはIAMロール + 信頼ポリシー + AssumeRoleが基本
S3バケットのアクセス制御においては：
- ACLは非推奨
- バケットポリシーはスケーラビリティに難あり
- IAMロールでの引き受けが推奨される
アクセスキーの共有はNG。セキュリティ上の重大なリスク

次の問題もHTML形式でお送りいただければ、引き続き解説いたします。

以下は「問題4」の解説を、AWS Certified Security – Specialty 試験対策としての形式でまとめたものです。

■ 問題文（文字列を編集せずに出力してください。）

会社には、Amazon S3 バケットへのアクセスを必要とする AWS Lambda 関数があります。同社のセキュリティポリシーでは、Amazon S3 への接続はプライベートネットワーク経由であり、安全である必要があります。

同社は、Amazon S3 へのアクセスを許可するために、VPC にゲートウェイ VPC エンドポイントを設定しました。同社は、VPC 内で実行するように Lambda 関数を設定しました。さらに、NAT ゲートウェイを介してインターネットへのルートを持つプライベートサブネットを使用するように Lambda 関数を構成しました。

VPC 内の他のリソースは、このプライベートサブネットを使用してインターネットに正常にアクセスします。Lambda 関数が実行されると、ゲートウェイ VPC エンドポイントの代わりに NAT ゲートウェイを使用して Amazon S3 にアクセスします。

Lambda 関数が Amazon S3 のゲートウェイ VPC エンドポイントを確実に使用する最適な方法を選択してください。

■ 選択肢（文字列を編集せずに出力してください。）

A.
ゲートウェイ VPC エンドポイントを、Lambda 関数が使用するプライベートサブネットのルートテーブルに関連付けます。

B.
ゲートウェイ VPC エンドポイントポリシーを調整して、Lambda 関数のネットワークインターフェースアドレスからのアクセスを許可します。

C.
Lambda 関数が使用するプライベートサブネットのルートテーブル内の NAT ゲートウェイへのルートを削除します。

D.
Lambda 関数のセキュリティグループを設定し、S3 ネットワークアドレス空間への接続を許可します。

■ 問題文の要件の概要

Lambda 関数が Amazon S3 へプライベートネットワーク経由で接続する必要がある。
すでに VPC エンドポイント（Gateway型） は作成済み。
Lambda は プライベートサブネット + NAT ゲートウェイ経由で通信してしまっている。
Lambda 関数が S3 に直接アクセスするルート（Gateway Endpoint）を使うようにさせたい。

■ 正解の選択肢と解説

正解：A

「ゲートウェイ VPC エンドポイントを、Lambda 関数が使用するプライベートサブネットのルートテーブルに関連付ける」

解説：

ゲートウェイ VPC エンドポイント（Gateway Endpoint）は ルートテーブルベースでルーティングを制御します。
そのため、Lambda 関数が配置されているプライベートサブネットのルートテーブルに 送信先: prefix_list_id (例: com.amazonaws.ap-northeast-1.s3) ターゲット: VPC Endpoint ID を追加することで、S3 へのアクセスが NAT 経由ではなく ゲートウェイエンドポイント経由になります。

この設定により、通信がインターネットを通らず AWS の内部ネットワークのみで完結し、セキュリティポリシー要件も満たせます。

■ 不正解の選択肢の理由

B. エンドポイントポリシーの調整
→ VPCエンドポイントポリシーは アクセスの許可/拒否の制御であり、ルーティングには影響を与えません。Lambda が NAT ゲートウェイ経由で通信してしまう問題は解決できません。

C. NAT へのルートを削除
→ Lambda が他の外部サービス（例えば Amazon SNS, API等）にアクセスする可能性がある場合、NAT 経由の通信が必要になることがあるため削除は不適切。S3アクセス問題の本質的な解決にもなりません。

D. セキュリティグループを設定
→ セキュリティグループはインバウンド/アウトバウンドトラフィックのフィルタリングであり、VPC Endpoint 経由通信のルート制御には無関係。また Lambda に ENI が自動で割り当てられる場合でも、それ自体で S3 エンドポイント利用は保証されません。

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

**Gateway VPC Endpoint（S3/DynamoDB専用）**は ルートテーブルベースのルーティング制御で動作する。
Lambda 関数を VPC 内で実行させる場合、アクセス先（S3など）への通信ルートの明示が必要。
NAT ゲートウェイ経由のアクセスはセキュリティ上の制約があるケースが多く、可能な限り VPC エンドポイント経由とする。
VPC エンドポイントのルート設定を確認する手順は現場対応や試験でも頻出。必ず押さえるべきポイント。

次の問題もHTMLでお送りいただければ、引き続き対応いたします。

以下は「問題5」の解説を、AWS Certified Security – Specialty 試験向けにご指定の形式で整理したものです。

■ 問題文（文字列を編集せずに出力してください。）

ある企業は、ID フェデレーションを使用して、ID アカウント (987654321879) にユーザーを認証し、ユーザーは IdentityRole という名前の IAM ロールを引き受けます。次に、ユーザーはターゲット AWS アカウント (123456789012) で JobFunctionRole という名前の IAM ロールを引き受けて、ジョブ機能を実行します。

ユーザーは、ターゲットアカウントで IAM ロールを引き受けることができません。ID アカウントのロールに関連付けられているポリシーは次のとおりです。
{
 "Version": "2012-10-17",
 "Statement": [{
  "Effect": "Allow",
  "Action": "sts:AssumeRole",
  "Resource": "arn:aws:iam::*:role/JobFunctionRole"
 }]
}
ユーザーがターゲットアカウントで適切なロールを引き受けることができるようにする最適な方法を選択してください。

■ 選択肢（文字列を編集せずに出力してください。）

A.
ID アカウントのロールの信頼ポリシーを次のように更新します。

{
 "Version": "2012-10-17",
 "Statement": [{
  "Effect": "Allow",
  "Action": "sts:AssumeRole",
  "Principal": { "AWS": "arn:aws:iam::987654321879:root" }
 }]
}

B.
ターゲットアカウントのロールの信頼ポリシーを次のように更新します。

{
 "Version": "2012-10-17",
 "Statement": [{
  "Effect": "Allow",
  "Action": "sts:AssumeRole",
  "Principal": { "AWS": "arn:aws:iam::987654321879:role/IdentityRole" }
 }]
}

C.
ターゲットアカウントのロールに関連付けられている IAM ポリシーを次のように更新します。

{
 "Version": "2012-10-17",
 "Statement": [{
  "Sid": "Stmt1502946463000",
  "Effect": "Allow",
  "Action": "sts:AssumeRole",
  "Resource": "arn:aws:iam::123456789012:role/JobFunctionRole"
 }]
}

D.
ID アカウントのロールに関連付けられている IAM ポリシーを次のように更新します。

{
 "Version": "2012-10-17",
 "Statement": [{
  "Effect": "Allow",
  "Action": "sts:AssumeRole",
  "Resource": "arn:aws:iam::123456789012:role/JobFunctionRole"
 }]
}

■ 問題文の要件の概要

フェデレーションユーザーはまず IDアカウント(987654321879) の IdentityRole を引き受ける
その後、ターゲットアカウント(123456789012) の JobFunctionRole を引き受けたい
IdentityRole から JobFunctionRole への ロールの連鎖 (role chaining) を許可したい
現在、IdentityRole に AssumeRole の許可はあるが、ターゲットアカウント側に信頼関係が未設定

■ 正解の選択肢と解説

正解：B

ターゲットアカウントの JobFunctionRole の信頼ポリシーを更新し、IdentityRole からの AssumeRole を許可する

{
 "Version": "2012-10-17",
 "Statement": [{
  "Effect": "Allow",
  "Action": "sts:AssumeRole",
  "Principal": {
    "AWS": "arn:aws:iam::987654321879:role/IdentityRole"
  }
 }]
}

解説：
ロールの連鎖（Role Chaining）を成立させるには、**引き受け元ロールを「信頼ポリシーで許可」**する必要があります。
このケースでは IdentityRole から JobFunctionRole を AssumeRole しようとしているため、JobFunctionRole 側の信頼ポリシーに IdentityRole を 明示的にプリンシパル指定しなければなりません。

■ 不正解の選択肢の理由

A. IDアカウントのロールの信頼ポリシーを更新
→ 認証元の IdentityRole に対して信頼ポリシーを変更しても、引き受け先のロール（JobFunctionRole）に対する信頼は得られない。この設定は不要。

C. ターゲットアカウント側で IAM ポリシーを更新
→ IAMポリシーは“誰が何をするか”を定義するが、信頼ポリシーがなければ AssumeRole は拒否される。この設定だけでは動作しない。

D. IDアカウント側の IAM ポリシーを更新
→ すでにポリシーで sts:AssumeRole は許可されている。これを更新しても、ターゲット側が受け入れない限り AssumeRole できない。

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

ロール連鎖（Role Chaining）：IAMロール → IAMロールの連続的引き受けには「信頼ポリシー」と「IAMポリシー」の両方が必要
IAMポリシー：実行者が何を許可されているか（例：sts:AssumeRole）
信頼ポリシー：ロールを引き受けることができるプリンシパル（ユーザー・ロール・アカウントなど）を定義
複数アカウント間でロールを連鎖させる場合、ターゲット側の信頼ポリシーの設定ミスが最も多い障害要因
正しい形式で ARN（IAM Role）をプリンシパルとして明記することが重要

次の問題があれば、同じ形式で続けて対応いたします。

以下は「問題6」の解説を、AWS Certified Security – Specialty 試験対策の形式で整理したものです。

■ 問題文（文字列を編集せずに出力してください）

ある会社は、今後の製品発売に向けてコンテンツ配信ネットワークを実装したいと考えています。配布元は AWS の外部のオブジェクトストアであり、リクエストからの Authorization ヘッダーを渡す必要があります。

この要件を最短時間で満たす最適な方法を選択してください。

■ 選択肢（文字列を編集せずに出力してください）

A.
新しい Amazon CloudFront ディストリビューションを作成します。Authorization ヘッダーのヘッダーホワイトリストを使用して、新しい CloudFront キャッシュポリシーを作成します。ポリシーをディストリビューションにアタッチします。

B.
オブジェクトを Amazon S3 に移行します。新しい Amazon CloudFront ディストリビューションを作成します。Authorization ヘッダーのヘッダーホワイトリストを使用して、新しい CloudFront キャッシュポリシーを作成します。ポリシーをディストリビューションにアタッチします。

C.
オブジェクトを Amazon S3 に移行します。ポート 443 上のリスナーと、オリジンディストリビューションを指すエンドポイントグループを持つ新しい AWS Global Accelerator アクセラレータを作成します。

D.
新しい Amazon CloudFront ディストリビューションを作成します。X-Amz-Authorization 用の新しい CloudFront カスタムヘッダーを作成します。ヘッダーをディストリビューションにアタッチします。

■ 問題文の要件の概要

コンテンツ配信ネットワーク（CDN）を構築したい。
配信元は AWS 外部のオブジェクトストア（＝S3ではない）。
Authorization ヘッダーをそのままオリジンに転送する必要がある。
最短時間で構築したい。

■ 正解の選択肢と解説

正解：A

「新しい Amazon CloudFront ディストリビューションを作成します。Authorization ヘッダーのヘッダーホワイトリストを使用して、新しい CloudFront キャッシュポリシーを作成します。ポリシーをディストリビューションにアタッチします。」

解説：

CloudFront はデフォルトで Authorization ヘッダーをキャッシュキーに含めません。また、オリジンに転送もしません。
Authorization ヘッダーをオリジンに渡すには、キャッシュポリシーで明示的に「ホワイトリスト登録」する必要があります。
CloudFront のオリジンリクエストポリシーでは Authorization ヘッダーは使用できず、キャッシュポリシーのキーに含める必要があります。
この設定を行うことで、オリジン（外部のオブジェクトストア）に Authorization ヘッダーが届くようになり、CDN経由での認証付き配信が実現できます。

■ 不正解の選択肢の理由

B. S3 に移行して CloudFront を構築する
→「AWS外部のオブジェクトストア」を使うという前提を無視しており、最短時間での対応にならないため不正解。

C. S3 + Global Accelerator
→そもそもオブジェクトは AWS 外部にあるため移行が必要になり、手間が大きく不適。また Global Accelerator はグローバルルーティングに使うもので、Authorization ヘッダー転送とは無関係。

D. X-Amz-Authorization 用のカスタムヘッダーを設定
→CloudFront は Authorization ヘッダーをカスタムヘッダーとして上書き送信する設計には対応していない。また、カスタムヘッダーの指定はオリジンリクエストポリシーを使う方式であり、Authorization ヘッダーはオリジンリクエストポリシーで転送できないためエラーになります（HTTP 400）。

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

CloudFront 経由で Authorization ヘッダーをオリジンに送信するには：
- キャッシュポリシーで Authorization をホワイトリスト登録する。
- オリジンリクエストポリシーでは転送不可 →使うと HTTP 400 エラーになる。
CloudFront のキャッシュ動作に影響を与えるヘッダー・クエリ文字列は、明示的にキーに含める必要がある。
**「最短時間」**が求められる場合、外部サービスへの接続要件があるなら既存リソースを活かした設定変更がベスト。

次の問題もお送りいただければ、同様の形式で解説いたします。

以下は「問題7」の解説を、AWS Certified Security – Specialty 試験対策の形式で整理した内容です。

■ 問題文（文字列を編集せずに出力してください）

企業は、リモートの従業員のために、クラウドベースの管理されたデスクトップソリューションを必要としています。この企業は、従業員が会社から支給されたデバイスを使用してのみデスクトップにアクセスできるようにしたいと考えています。セキュリティエンジニアは、コストと管理オーバーヘッドを最小限に抑えるソリューションを設計する必要があります。

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

■ 選択肢（文字列を編集せずに出力してください）

A.
Amazon EC2 インスタンスのフリートをデプロイします。Windows Active Directory を使用する証明書ベースのデバイス認証を使用して、各従業員にインスタンスを割り当てます。

B.
Amazon WorkSpaces をデプロイします。クライアント証明書を作成し、信頼できるデバイスにデプロイします。ディレクトリレベルで制限付きアクセスを有効にします。

C.
企業のデバイスからのアクセスのみを許可する制限ポリシーを使用して、カスタムの仮想デスクトップインフラストラクチャ (VDI) ソリューションをデプロイします。

D.
Amazon WorkSpaces をデプロイします。AWS Identity and Access Management (IAM) を使用して、認証ゲートウェイで IP をブロックする信頼できるデバイスポリシーを設定します。

■ 問題文の要件の概要

リモート従業員向けのクラウドベースデスクトップソリューション
会社から支給されたデバイス以外からのアクセスは不可
セキュリティとコスト管理の最適化が必要

■ 正解の選択肢と解説

正解：B

「Amazon WorkSpaces をデプロイします。クライアント証明書を作成し、信頼できるデバイスにデプロイします。ディレクトリレベルで制限付きアクセスを有効にします。」

解説：

Amazon WorkSpaces は、マネージド型の仮想デスクトップサービスで、セキュリティ・スケーラビリティ・コスト効率に優れています。
クライアント証明書を使って信頼できるデバイス（会社支給端末）のみにアクセスを許可する機能があります。
ディレクトリレベルで制限付きアクセスを有効にすることで、WorkSpaces 側で証明書認証の適用が可能になります。
IAMではなく、証明書ベースでのアクセス制限がよりセキュアかつ低コストです。

■ 不正解の選択肢の理由

A. Amazon EC2 + AD + 証明書ベースの認証
→ EC2 フリートを個別に管理するのは コストと運用負荷が大きく、スケーラブルでないため不適切。

C. カスタム VDI ソリューション + 制限ポリシー
→ 自前で VDI を構築・運用するのは 最もコストと管理オーバーヘッドが高い。AWSマネージドサービスがあるならそちらを使うのが前提。

D. IAM + IP ベースの制限
→ モバイルワーカーや出張先での利用があると IP 制限は非現実的で管理負担が大きい。証明書の方が確実でセキュア。

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

Amazon WorkSpaces は、セキュリティ管理されたマネージドVDIサービス。
証明書ベースのデバイス認証により、信頼できる端末のみにアクセスを制限できる。
WorkSpaces の アクセス制御オプション（Trusted Devices） を利用すれば、macOS/Windows PC に証明書をインストールして認証できる。
IP制限よりも証明書認証の方がセキュリティと運用面で優れている。
セキュリティ＋コスト最適化が要求されたら、AWSのマネージドサービス（WorkSpacesやAppStream 2.0）が第一候補になる。

次の問題もあれば、引き続き同じ形式で対応可能です。お気軽に送ってください。

■ 問題文（文字列を編集せずに出力してください。）

■ 選択肢（文字列を編集せずに出力してください。）

■ 問題文の要件の概要

■ 正解の選択肢と解説

■ 不正解の選択肢の理由

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

■ 問題文（文字列を編集せずに出力してください。）

■ 選択肢（文字列を編集せずに出力してください。）

■ 問題文の要件の概要

■ 正解の選択肢と解説

■ 不正解の選択肢の理由

A の問題点：

B の問題点：

D の問題点：

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

■ 問題文（文字列を編集せずに出力してください。）

■ 選択肢（文字列を編集せずに出力してください。）

■ 問題文の要件の概要

■ 正解の選択肢と解説

■ 不正解の選択肢の理由

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

■ 問題文（文字列を編集せずに出力してください。）

■ 選択肢（文字列を編集せずに出力してください。）

■ 問題文の要件の概要

■ 正解の選択肢と解説

■ 不正解の選択肢の理由

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

■ 問題文（文字列を編集せずに出力してください。）

■ 選択肢（文字列を編集せずに出力してください。）

■ 問題文の要件の概要

■ 正解の選択肢と解説

■ 不正解の選択肢の理由

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

■ 問題文（文字列を編集せずに出力してください）

■ 選択肢（文字列を編集せずに出力してください）

■ 問題文の要件の概要

■ 正解の選択肢と解説

■ 不正解の選択肢の理由

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

■ 問題文（文字列を編集せずに出力してください）

■ 選択肢（文字列を編集せずに出力してください）

■ 問題文の要件の概要

■ 正解の選択肢と解説

■ 不正解の選択肢の理由

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

#39

AWS 認定試験対策ガイド（追加編）

#37

Recent Posts

Recent Comments

Archives

Categories