AWS DVA / 第5章

CHAPTER 05 / D2

認証・権限・暗号化

IAM・Cognito・KMS・秘密情報の責任を切り分ける。

一読の目安 35分図・具体例・確認問題

01 / 認証と認可を別々に考える

認証は「誰か」を確かめ、認可は「何をしてよいか」を決めます。ログインできた利用者が、他人の注文を閲覧できてよいとは限りません。アプリの利用者IDと、処理を実行するAWSロールも別です。

仕組み担当すること例
Cognito user poolアプリ利用者の認証、JWTの発行メールアドレスでログインし、APIへトークンを送る
Cognito identity pool外部ID等を基に一時AWS認証情報を取得ログイン利用者が権限を限定したロールでS3へアクセス
IAMロール+STSAWS APIを呼ぶ権限と一時認証情報LambdaがDynamoDBをGetItemする
アプリの認可ロジック業務データへのアクセス判定トークンのsubと注文の所有者IDが一致するか確認
認証トークンとAWS認証情報を分けるユーザープールのJWTはアプリのログインを表します。API経由でLambdaがDBへアクセスする場合、DB操作にはLambda自身の実行ロールを使います。ブラウザ利用者としてログインCognitouser poolAPI GatewayJWTなどを検証Lambda実行ロールでDB操作ログインJWT認証済みの情報
認証トークンとAWS認証情報を分ける — ユーザープールのJWTはアプリのログインを表します。API経由でLambdaがDBへアクセスする場合、DB操作にはLambda自身の実行ロールを使います。

JWTは内容を読むだけでは検証したことになりません。署名、発行者、対象クライアントやaudience、期限、トークン用途などを確認します。APIへアクセスする権限にはaccess tokenやscopeを使い、ID tokenは主に利用者属性の表現です。refresh tokenは新しいトークンの取得用です。

公式資料:Cognito user pools

公式資料:Cognito identity pools

02 / IAMロールは二つの方向を見る

ロールには「誰がこのロールを引き受けられるか」を決める信頼ポリシーと、「引き受けた後に何ができるか」を決めるアクセス許可ポリシーがあります。Lambdaの実行ロールなら、前者がLambdaサービスからのAssumeRoleを許可し、後者がDynamoDB操作などを許可します。

ポリシー何に注目するか
アイデンティティベースロール等に付与。Action / Resource / Conditionで操作範囲を決める
リソースベースS3バケットやLambda等の側で、Principalを含めてアクセス元を制御
信頼ポリシーロールを引き受けるPrincipalとsts:AssumeRole等
Permissions boundary / SCP権限の上限を制限する。これだけで権限を付与するものではない
最小権限の許可ポリシー:Orders テーブルを読む(例)
{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Action": "dynamodb:GetItem",
    "Resource": "arn:aws:dynamodb:ap-northeast-1:123456789012:table/Orders"
  }]
}

アカウントID・リージョン・テーブル名は例です。QueryをGSIへ行うなら、必要なアクションとインデックスのARNも検討します。s3:ListBucketはバケットARN、s3:GetObjectは通常オブジェクトARNという違いも押さえます。

クロスアカウントでロールを引き受けるときは、呼び出し側のAssumeRole権限、引き受け先の信頼関係、そのロールの実効権限を順に確認します。

公式資料:IAM のポリシー評価

03 / KMSと暗号化の役割

転送中の暗号化はTLSなど、保存時の暗号化はS3やDBの暗号化などです。保存時に暗号化していても、復号権限を持つ利用者へのアクセス制御は必要です。

エンベロープ暗号化データ本体はデータキーで暗号化し、そのデータキーをKMSキーで保護します。保存するのは暗号化データと暗号化済みデータキーです。データ本体大きなデータデータキー本体を暗号化暗号化データ保存先へKMSキーデータキーを保護暗号化済みキー本体と一緒に保存
エンベロープ暗号化 — データ本体はデータキーで暗号化し、そのデータキーをKMSキーで保護します。保存するのは暗号化データと暗号化済みデータキーです。
比較意味
クライアント側暗号化送信前にアプリ側で暗号化。アプリ側で鍵の扱い・復号も考える
サーバー側暗号化AWSサービスが受信後に暗号化して保存。S3のSSE-S3 / SSE-KMSなど
AWS管理のKMSキーAWSサービスと統合して管理される。利用者が自由にキーポリシーを変更するものではない
カスタマー管理KMSキーポリシーや有効化・無効化等を制御。クロスアカウント利用などの要件で検討

KMSの暗号化・復号には、IAMだけでなくキーポリシーやgrantsも関わります。S3のGetObjectが許可されても、SSE-KMSの復号権限が足りなければ取得できない場合があります。キーの自動ローテーションは、既存の暗号文を全件再暗号化することと同義ではありません。

公式資料:KMS の概念

04 / 秘密情報と設定値を保管する

サービス主な使い方選択のポイント
Secrets ManagerDBの認証情報、外部APIの秘密値ローテーションが重要な秘密を管理。対応DB等と連携
Systems Manager Parameter Store環境別の設定、SecureStringによる秘密値階層化された設定とKMS暗号化。自動更新が必要なら別途構成を確認
AppConfig機能フラグ、動的なアプリ設定バリデーション、段階配信、監視に応じたロールバック

Lambdaの環境変数にも保存時の暗号化があります。ただし秘密を文字列で配布する方法は、参照権限やログへの露出、更新の反映を考える必要があります。Secrets Managerなどから取得する場合は、取得権限を限定し、必要に応じてキャッシュし、ローテーション後に古い値を使い続けないようにします。

秘密をローテーションしても、アプリが起動時に一度だけ取得して永久に保持すれば追従できません。取得頻度・キャッシュ期限・失敗時の再取得まで含めて考えます。

公式資料:Secrets Manager のローテーション

05 / S3の署名付きURL

署名付きURLは、署名者が持つアクセス権の範囲内で、特定オブジェクトへのGETやPUTなどを期限付きで委譲します。バケットを公開せずに、ブラウザがS3へ直接アップロード・ダウンロードする用途に使えます。

boto3:限定したダウンロードURLを発行(抜粋)
import boto3

s3 = boto3.client("s3")
url = s3.generate_presigned_url(
    "get_object",
    Params={"Bucket": "example-private-bucket", "Key": "reports/result.pdf"},
    ExpiresIn=300
)

URLを持つ人がアクセスできるため、共有範囲を限定します。指定した期限だけでなく、署名に使った一時認証情報の期限や失効も有効性に関係します。署名者に元々ない権限を増やす仕組みではありません。ブラウザのPUTには、別途CORS設定が必要な場合があります。

公式資料:S3 の署名付きURL

切り分け練習:S3がAccessDenied

同じロールで一部のオブジェクトだけ取得できない。暗号化方式がSSE-KMSに変わっていた。何を見る?

考え方・解答例

S3のオブジェクト権限に加えて、対象KMSキーのキーポリシー、IAMのkms:Decrypt権限、明示的Denyやキーの状態を確認します。S3のAllowだけ増やしても復号できるとは限りません。

06 / 確認問題

QUESTION 5-1 · 単一選択ログイン済みユーザーが、権限を限定してブラウザから直接AWS APIを呼ぶための一時認証情報を得たい。適切なのは?
解答・解説を読む

正解:A
Identity poolは認証済みのID等をAWS一時認証情報へ交換できます。User poolのJWTとは用途が異なります。

QUESTION 5-2 · 単一選択IAMでAllowされているGetObjectが、適用されるバケットポリシーで明示的Denyされている。結果は?
解答・解説を読む

正解:C
適用される明示的DenyがAllowに優先します。ポリシーの新旧や追加順では決まりません。

07 / この章の到達点

上のチェックは、このページでの振り返り用です。章単位の進捗は下のボタンで記録できます。

公式資料

内容確認日:2026年11月8日。仕様の詳細や更新情報は、各公式資料で確認できます。

おつかれさまでした。

理解を確認できたら、章の進捗を記録できます。