CHAPTER 05 / D2
認証・権限・暗号化
IAM・Cognito・KMS・秘密情報の責任を切り分ける。
01 / 認証と認可を別々に考える
認証は「誰か」を確かめ、認可は「何をしてよいか」を決めます。ログインできた利用者が、他人の注文を閲覧できてよいとは限りません。アプリの利用者IDと、処理を実行するAWSロールも別です。
| 仕組み | 担当すること | 例 |
|---|---|---|
| Cognito user pool | アプリ利用者の認証、JWTの発行 | メールアドレスでログインし、APIへトークンを送る |
| Cognito identity pool | 外部ID等を基に一時AWS認証情報を取得 | ログイン利用者が権限を限定したロールでS3へアクセス |
| IAMロール+STS | AWS APIを呼ぶ権限と一時認証情報 | LambdaがDynamoDBをGetItemする |
| アプリの認可ロジック | 業務データへのアクセス判定 | トークンのsubと注文の所有者IDが一致するか確認 |
JWTは内容を読むだけでは検証したことになりません。署名、発行者、対象クライアントやaudience、期限、トークン用途などを確認します。APIへアクセスする権限にはaccess tokenやscopeを使い、ID tokenは主に利用者属性の表現です。refresh tokenは新しいトークンの取得用です。
公式資料:Cognito user pools
02 / IAMロールは二つの方向を見る
ロールには「誰がこのロールを引き受けられるか」を決める信頼ポリシーと、「引き受けた後に何ができるか」を決めるアクセス許可ポリシーがあります。Lambdaの実行ロールなら、前者がLambdaサービスからのAssumeRoleを許可し、後者がDynamoDB操作などを許可します。
| ポリシー | 何に注目するか |
|---|---|
| アイデンティティベース | ロール等に付与。Action / Resource / Conditionで操作範囲を決める |
| リソースベース | S3バケットやLambda等の側で、Principalを含めてアクセス元を制御 |
| 信頼ポリシー | ロールを引き受けるPrincipalとsts:AssumeRole等 |
| Permissions boundary / SCP | 権限の上限を制限する。これだけで権限を付与するものではない |
{
"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の暗号化などです。保存時に暗号化していても、復号権限を持つ利用者へのアクセス制御は必要です。
| 比較 | 意味 |
|---|---|
| クライアント側暗号化 | 送信前にアプリ側で暗号化。アプリ側で鍵の扱い・復号も考える |
| サーバー側暗号化 | AWSサービスが受信後に暗号化して保存。S3のSSE-S3 / SSE-KMSなど |
| AWS管理のKMSキー | AWSサービスと統合して管理される。利用者が自由にキーポリシーを変更するものではない |
| カスタマー管理KMSキー | ポリシーや有効化・無効化等を制御。クロスアカウント利用などの要件で検討 |
KMSの暗号化・復号には、IAMだけでなくキーポリシーやgrantsも関わります。S3のGetObjectが許可されても、SSE-KMSの復号権限が足りなければ取得できない場合があります。キーの自動ローテーションは、既存の暗号文を全件再暗号化することと同義ではありません。
公式資料:KMS の概念
04 / 秘密情報と設定値を保管する
| サービス | 主な使い方 | 選択のポイント |
|---|---|---|
| Secrets Manager | DBの認証情報、外部APIの秘密値 | ローテーションが重要な秘密を管理。対応DB等と連携 |
| Systems Manager Parameter Store | 環境別の設定、SecureStringによる秘密値 | 階層化された設定とKMS暗号化。自動更新が必要なら別途構成を確認 |
| AppConfig | 機能フラグ、動的なアプリ設定 | バリデーション、段階配信、監視に応じたロールバック |
Lambdaの環境変数にも保存時の暗号化があります。ただし秘密を文字列で配布する方法は、参照権限やログへの露出、更新の反映を考える必要があります。Secrets Managerなどから取得する場合は、取得権限を限定し、必要に応じてキャッシュし、ローテーション後に古い値を使い続けないようにします。
秘密をローテーションしても、アプリが起動時に一度だけ取得して永久に保持すれば追従できません。取得頻度・キャッシュ期限・失敗時の再取得まで含めて考えます。
05 / S3の署名付きURL
署名付きURLは、署名者が持つアクセス権の範囲内で、特定オブジェクトへのGETやPUTなどを期限付きで委譲します。バケットを公開せずに、ブラウザがS3へ直接アップロード・ダウンロードする用途に使えます。
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 / 確認問題
07 / この章の到達点
上のチェックは、このページでの振り返り用です。章単位の進捗は下のボタンで記録できます。
公式資料
内容確認日:2026年11月8日。仕様の詳細や更新情報は、各公式資料で確認できます。
理解を確認できたら、章の進捗を記録できます。