MENU
会員登録（無料）
  1. ホーム
  2. 【DVA-C02】WEB問題集：セキュリティ編

【DVA-C02】WEB問題集：セキュリティ編

WEB問題集

DVA-C02#1(security)

開発者は Lambda 関数からデータベースパスワードを取得しています。パスワードは 30 日ごとに自動ローテーションが必要で、コード側はキャッシュ込みでベストプラクティスに沿った取得方式にしたいです。最適な実装はどれですか。

ディスカッション 0

正解：D

正解の根拠

Secrets Manager は組み込みの自動ローテーション機能を持ち、Lambda 拡張機能 (Parameters and Secrets Lambda Extension) を併用することで秘匿情報をローカルキャッシュ経由で取得でき、API 呼出回数とコールドスタート遅延を削減できます。

秘匿情報管理の比較

サービス自動ローテーション料金
Secrets Managerあり (Lambda)シークレット毎課金
SSM Parameter Storeなし (手動)Standard 無料
S3 + KMSなし独自実装が必要

コード例

resp = http.get(
  "http://localhost:2773/secretsmanager/get?secretId=db"
)
secret = resp.json()["SecretString"]

不正解の理由

  • B: Parameter Store はローテーション機構を持ちません。
  • C: S3 保存はカスタムローテーション実装が必要で複雑です。
  • A: 環境変数の更新は危険で、変更時に古いバージョンが残ります。

参考：Secrets Lambda Extension

DVA-C02#2(security)

API Gateway REST API のエンドポイントへ社内ネットワーク (VPC) からのみアクセス許可し、それ以外を遮断する実装を求められています。プライベートかつ最小特権の構成として最適な方法はどれですか。

ディスカッション 0

正解：C

正解の根拠

Private API は VPC エンドポイント経由のみ到達可能で、リソースポリシーで aws:SourceVpce を指定して特定 VPCE 以外をブロックすることで、ネットワーク層と認可層の二重防御が成立します。これが最小特権かつプライベート要件を満たす標準構成です。

API Gateway 公開モード

タイプ到達範囲制御
Edge-OptimizedインターネットWAF/IAM
RegionalインターネットWAF/IAM
PrivateVPC のみVPCE Policy

コード例

{
  "Effect": "Allow",
  "Principal": "*",
  "Action": "execute-api:Invoke",
  "Condition": {"StringEquals": {"aws:SourceVpce": "vpce-abc"}}
}

不正解の理由

  • D: パブリック API はネットワーク層で開放されており、ポリシー誤りで露出します。
  • A: CloudFront 経由は外部到達可能で、社内限定要件に過剰です。
  • B: Source IP 検証は IP スプーフィング/プロキシで信頼性が低いです。

参考：Private APIs

DVA-C02#3(security)

開発者は S3 にアップロードされたオブジェクトを KMS で暗号化したいです。複数アカウントの IAM プリンシパルから書き込みを受け、鍵の運用負担を最小化する暗号化キーの選択として最適なのはどれですか。

ディスカッション 0

正解：B

正解の根拠

クロスアカウントでの暗号化キー共有には CMK (カスタマー管理キー) が必須です。aws/s3 等の AWS マネージドキーは他アカウントへのキー共有ができないためです。CMK のキーポリシーで明示的に許可することで監査性も確保できます。

S3 暗号化方式

方式鍵管理クロスアカウント
SSE-S3AWSシンプル
SSE-KMS (CMK)顧客キーポリシーで可
SSE-KMS (aws/s3)AWS不可
SSE-Cクライアント運用負荷大

不正解の理由

  • D: SSE-S3 は監査やキーローテーションの粒度が CMK より弱いです。
  • A: SSE-C はクライアント側で鍵管理が必要で運用負担が大きいです。
  • C: aws/s3 キーは他アカウントへ共有できません。

参考：SSE-KMS

DVA-C02#4(security)

あるチームは Lambda 関数 A から別の AWS アカウントの S3 バケットを読み込みたいです。最小特権と監査性を備えたクロスアカウントアクセスの実装はどれですか。

ディスカッション 0

正解：C

正解の根拠

クロスアカウントアクセスでは、対象アカウントにロールを作り Lambda 実行ロールから AssumeRole する設計が標準です。CloudTrail で誰がいつ何を取得したか追跡でき、最小特権を達成できます。

クロスアカウント方式

方式監査性推奨度
AssumeRole高推奨
バケットポリシー直接中場合により可
アクセスキー共有低非推奨

コード例

sts = boto3.client("sts")
cred = sts.assume_role(
  RoleArn="arn:aws:iam::222:role/R",
  RoleSessionName="xacct"
)["Credentials"]
s3 = boto3.client("s3", **cred)

不正解の理由

  • A: Public 解除と固定アクセスキーは重大なセキュリティリスクです。
  • D: Public 読み取り許可は要件に反し、監査性も劣ります。
  • B: SCP は ID ベース許可ではなくガードレール用途で、付与目的では使えません。

参考：Cross-Account Roles

DVA-C02#5(security)

API Gateway HTTP API で Cognito User Pool 発行の JWT を検証したいです。最小コストとレイテンシで実装できる方法はどれですか。

ディスカッション 0

正解：B

正解の根拠

HTTP API はネイティブ JWT Authorizer を備え、Cognito を含む OIDC 互換 IdP の検証を追加コードなしで実行できます。Lambda Authorizer に比べてレイテンシと料金が低く抑えられます。

API Gateway 認可方式

方式コスト柔軟性
HTTP API JWT追加なしOIDC 標準
REST API Cognito追加なしUser Pool 専用
Lambda AuthorizerLambda 課金カスタム可

コード例

Authorizer:
  Type: JWT
  IdentitySource: $request.header.Authorization
  JwtConfiguration:
    issuer: https://cognito-idp.ap-northeast-1.amazonaws.com/POOL
    audience: [CLIENT_ID]

不正解の理由

  • D: REST 切替は不要な変更で、コスト効率も悪化します。
  • C: Lambda Authorizer は呼出毎課金とコールドスタート影響があります。
  • A: Lambda@Edge は CloudFront 必須で、過剰な構成です。

参考：JWT Authorizer

前のページ
次のページ