AWS Certified Developer - Associate (DVA-C02) #7 Domain 2-1 セキュリティ — 認証と認可

2026年5月26日火曜日

読了 5分

#6 SDK 開発パターンで「本番の認証情報は IAM Role」と述べました。セキュリティドメインはそのテーマを正面から扱います。DVA のセキュリティは SAA のような巨大なネットワーク設計ではなく、アプリケーションが認証情報をどう得て、ユーザーをどう認証し、一時的な権限をどう発行するか というコードに近い問いです。

まず認証 (authentication) と認可 (authorization) を区別します。認証は「あなたは誰か」、認可は「あなたは何ができるか」 です。Cognito は主に認証を、IAM は認可を担当します。

IAM Role を開発者視点で #

#6 で見たとおり、コードが AWS サービスにアクセスするときは 長期アクセスキーを保存せず IAM Role を使用 します。実行環境ごとに Role を供給する方式が異なります。

実行環境	Role の供給方式
EC2	インスタンスプロファイル (Instance Profile)
ECS	タスクロール (Task Role)
Lambda	実行ロール (Execution Role)
EKS ポッド	IRSA (サービスアカウント用 IAM Role)

これらの Role はすべて STS が発行した一時的な認証情報 をコードに自動供給します。SDK の認証情報供給チェーンがこれを最後の段階で拾ってきます。「Lambda が DynamoDB に書き込むには?」の答えは「実行ロールに dynamodb:PutItem 権限を与える」です。

STS — 一時的な認証情報 #

Security Token Service (STS) は有効期限のある一時的な認証情報 (アクセスキー ID・シークレットキー・セッショントークン) を発行します。漏洩しても被害が限定されます。

AssumeRole — 別の Role を引き受けてその権限を一時的に得ます。クロスアカウントアクセスの定石です。
AssumeRoleWithWebIdentity — Google・Facebook・Cognito のような OIDC/Web アイデンティティで認証したユーザーに一時的な認証情報を与えます。
GetSessionToken — MFA が適用された一時的な認証情報の発行など。

核心となる原則: アプリやモバイル端末に長期 IAM キーを配布しません。 代わりにフェデレーションで一時的な認証情報を発行します。

Cognito — 2 つのプール #

Cognito は DVA のセキュリティで最も頻繁に出るサービスであり、User Pool と Identity Pool を混同するとほぼ必ず間違えます。

区分	User Pool	Identity Pool (Federated Identities)
役割	認証 (ログイン・サインアップ)	認可 (一時的な AWS 認証情報の発行)
成果物	JWT トークン (ID/Access/Refresh)	STS の一時的な AWS 認証情報
問い	「このユーザーは誰か」	「このユーザーが AWS リソースにどうアクセスするか」
代表的な用途	アプリのユーザーディレクトリ、API Gateway オーソライザー	ログインしたユーザーが S3/DynamoDB に直接アクセス

User Pool #

ユーザーディレクトリであり認証プロバイダーです。サインアップ・ログイン・MFA・パスワードポリシー・ソーシャルログイン連携 (Google など)・ホスト型 UI を提供し、ログインに成功すると JWT を発行します。この JWT を API Gateway の Cognito オーソライザーが検証して API アクセスを許可します。

Identity Pool #

認証済み (またはゲスト) ユーザーに STS の一時的な AWS 認証情報 を発行します。ユーザーはこの認証情報で S3 バケットや DynamoDB テーブルに直接アクセスできます。認証ソースとして User Pool、ソーシャル IdP、SAML などを受け付けます。

決定的な区別: 「ログイン/トークン」なら User Pool、「ユーザーに AWS リソースへの直接アクセス (一時的な認証情報)」なら Identity Pool です。2 つを一緒に使うパターンも一般的です。User Pool でログイン → そのトークンを Identity Pool に渡して AWS 認証情報を取得。

よく出る認証シナリオ #

Web/モバイルアプリのログイン → User Pool (認証) + API Gateway Cognito オーソライザー。
ログインしたユーザーが自分のフォルダにだけ S3 アップロード → Identity Pool で一時的な認証情報 + IAM ポリシー変数 (${cognito-identity.amazonaws.com:sub}) でユーザーごとの隔離。
サードパーティ OAuth でログイン → User Pool のソーシャル連携または Lambda オーソライザー。
サービス間 (サーバー to AWS) → IAM Role、Cognito 不要。

試験の出題パターン #

「モバイルアプリのユーザーがログイン後に S3 に直接アップロードする一時的な AWS 認証情報が必要だ。」 → Identity Pool。
「アプリにログイン・サインアップ・JWT が必要だ。」 → User Pool。
「API Gateway でログインしたユーザーだけ許可。」 → User Pool + Cognito オーソライザー。
「Lambda が DynamoDB にアクセスする必要がある。」 → 実行ロールに権限付与 (キー保存ではない)。
「別のアカウントのリソースをコードで制御。」 → STS AssumeRole。
「ユーザーごとに自分の S3 prefix にだけアクセス。」 → Identity Pool + IAM ポリシーのポリシー変数。

よく出会う落とし穴 #

1) User Pool と Identity Pool を混同する #

User Pool は認証 (トークン)、Identity Pool は認可 (AWS の一時的な認証情報) です。「AWS リソースへの直接アクセス」なら Identity Pool です。

2) アプリに IAM ユーザーのキーを配布する #

モバイル・Web に長期キーを入れる答案は常に不正解です。フェデレーションで一時的な認証情報を発行します。

3) Lambda にアクセスキーを環境変数で #

Lambda は実行ロールが認証情報を自動供給します。キーを入れる理由がありません。

まとめ #

この記事の要点:

認証 (「誰か」) vs 認可 (「何をするか」)。Cognito は認証、IAM は認可
コードの AWS アクセスは IAM Role (EC2 プロファイル・ECS タスク・Lambda 実行ロール)。すべて STS の一時的な認証情報
STS — AssumeRole (クロスアカウント)、AssumeRoleWithWebIdentity (フェデレーション)
Cognito User Pool (ログイン・JWT) vs Identity Pool (一時的な AWS 認証情報) の区別が核心
アプリ・モバイルに 長期キーの配布は禁止

次へ — Domain 2-2 暗号化とシークレット #

アイデンティティと権限を整理したので、次は データと秘密値そのものの保護 です。#8 暗号化とシークレットでは、KMS とエンベロープ暗号化、S3・Lambda 環境変数の暗号化、そして Secrets Manager と Parameter Store の違い (自動ローテーションを含む) を見ていきます。