Cognito & STS — 「あなたは誰？」を正しく聞く

皆さん、国際空港に行ったことありますか。搭乗する時、何が起きるか。まずセキュリティゲートで、「あなたは誰？」と聞かれます。パスポート、チケットを見せる。顔認証。これは認証（Authentication）です。「あなたが本当にあなたであることを確認する」ステップ。OK、あなたは本物。では次、「あなたはどこに行っていいの？」という話。日本の市民ですか？ビザはありますか？飛行機に乗る予約は？これは認可（Authorization）です。「あなたが何をしていいかを決める」ステップ。

ウェブアプリケーション。「ユーザーがログイン」した後、「このユーザーが何をアクセスできるか」を制御する。その仕組みが Cognito と STS。分業体制。Cognito は認証（ユーザーを確認）。STS は認可（権限を付与）。

Cognito の 2大コンポーネント

User Pools。認証。ユーザー名、パスワード管理。トークン発行（ID Token、Access Token、Refresh Token）。

Identity Pools。認可。AWS リソースへのアクセス権。一時認証情報（AccessKeyId、SecretAccessKey、SessionToken）を発行。

両方必須。User Pools だけでは、AWS リソースアクセスできない。Identity Pools だけでは、ユーザー確認できない。

初心者が引っかかるポイント。「Cognito で S3 にアクセスできるのか」。User Pools では不可。Identity Pools と組み合わせて初めて可能。

User Pools の詳細

MFA。三択。SMS（ショートメッセージ）、TOTP（Google Authenticator）、Email（SES）。設定で選択。

Advanced Security。侵害された認証情報検出。AWS の脅威インテリジェンスとマッチング。パスワード漏洩 DB に引っかかれば、パスワード変更強制。適応型認証。異常なログイン試行の検出。リスク評価に基づいて MFA 要求。

Lambda トリガー。認証フロー内の 8 つのポイント。Pre Sign-up（サインアップ前）。Pre Authentication（ログイン直前）。Post Authentication（ログイン後）。Pre Token Generation（トークン発行直前）。Custom Message。User Migration。Post Confirmation。Custom Authflow Challenge。

重要。Lambda トリガーのタイムアウト。5 秒。外部 API 呼び出しとか DB クエリとか。5 秒以内に完了必須。遅いと認証フロー全体が失敗。これ、VPC 内 Lambda だと危ない。起動時間だけで 1～2 秒かかることも。

Identity Pools の流れ

ステップ 1。User Pools からトークン取得。ステップ 2。そのトークン使って Identity Pools から Identity ID を取得。ステップ 3。Identity ID で一時認証情報を取得。ステップ 4。その一時認証情報で S3、DynamoDB にアクセス。

Python コード例。boto3 で cognito-idp、cognito-identity、sts クライアント作成。順番に呼ぶ。この流れ。

ロールマッピング

Identity Pools、複数 IAM ロール管理可能。どのロール割り当てるか。トークンベース。ID Token のカスタムクレームで選択。ルールベース。Priority ベースのマッピング。複数条件組み合わせ。

トークンベース。シンプル。ID Token に「department=engineering」クレーム入ってれば、engineer-role 割り当て。

ルールベース。複雑。複数ロール管理時に便利。「department=engineering AND project=project-a なら role-a」みたいな。

外部 IdP 連携

Google、Facebook、Apple、Amazon。SAML プロバイダー（Okta、Salesforce、AD）。OpenID Connect（OIDC）。

Cognito User Pools と外部 IdP の連携。「Google でログイン」ボタンクリック。Google に遷移。ログイン。トークン返却。Cognito が仲介。

Identity Pools も直接連携可能。「Google の ID Token を Cognito Identity Pools に」。Identity Pools が検証。ロール割り当て。AWS リソースアクセス可能。

STS の役割

STS。一時認証情報発行。長期的なアクセスキーの代わりに、期限付き認証情報。セキュリティ向上。

AssumeRole

クロスアカウント認証の基本。Account A のユーザーが、Account B のロール引き受ける。STS AssumeRole API。期限付き認証情報返却。

重要な脆弱性。Confused Deputy 問題。悪意のある Account C が、Account A のサービスを利用。知らないうちに Account B のロール権限で C の指示実行。対策。External ID。Account B のロール作成時に External ID 指定。Account A が AssumeRole 時に External ID 送信。マッチしないと失敗。必須。

Session Tags

AssumeRole 時にセッションタグ設定。そのセッション内で属性ベースアクセス制御。「Project=ProjectA」タグ付けば、IAM ポリシーで「s3:ProjectA/*」へのアクセスのみ許可。部門別、プロジェクト別の自動分離。

セッション期間の制約

AssumeRole。最小 15 分、最大 12 時間。

GetSessionToken（MFA 付き）。最小 15 分、最大 36 時間。

重要。ロールチェーン。Account A → Account B → Account C のように複数ロール AssumeRole チェーンする場合。合計期間 1 時間以内。「A で発行した一時認証情報の有効期限が 30 分」なら、B からの一時認証情報も 30 分以下。時間が短くなります。これ、仕組みを理解しないと、トラブル原因に。

Cognito + API Gateway

Lambda Authorizer。API Gateway の手前。ID Token 検証。JWT 署名確認。有効期限確認。OK なら API Gateway へ。NG なら拒否。

Cognito の公開鍵を取得。JWKS エンドポイント。署名検証。装備品。

試験ポイント

「User Pools vs Identity Pools」。何度も出題。認証（User Pools）。認可（Identity Pools）。完全に分別。

「Lambda トリガー 5 秒制限」。外部 API 呼び出し設計で要注意。非同期処理化とか、事前準備が必須。

「Confused Deputy」。External ID の使用は必須。ロール作成時に External ID 指定。AssumeRole 時に送信。

「ロールチェーン 1 時間制限」。複数アカウント跨ぐときに要確認。セッション期間が短くなります。

「IdP 連携」。Google、SAML、OIDC。複数対応。各々の実装パターン異なります。

できないこと

Cognito User Pools。AWS リソースに直接アクセス不可。Identity Pools と組み合わせが必須。

Lambda トリガー。5 秒以上の長時間処理不可。タイムアウト。

STS AssumeRole。12 時間以上のセッション不可。長期間が必要なら、GetSessionToken で 36 時間まで。

Cognito + STS の連携

フルフロー。User Pools でログイン。ID Token 取得。Identity Pools に送信。ロール割り当て。一時認証情報発行。AWS リソースアクセス。さらに、STS AssumeRole で別アカウントのロール引き受け。複雑だけど、これが現代のマルチアカウント環境。

まとめ

SCS-C03 全 13 講を通じて。IAM、KMS、CloudTrail、GuardDuty、Security Hub、VPC、S3、WAF・Shield、Config、Secrets・Parameter・ACM・CloudHSM、Inspector・Macie、Organizations・Control Tower・Identity Center、Cognito・STS。

セキュリティのいろいろな側面。ネットワーク、データ、認証、監視、検出、修復。それぞれが独立してなく、相互に連携。全体像の理解が試験合格のカギ。各サービスの「制約」「できないこと」を正確に把握。これが差別化。頑張ってください。では、健闘をお祈りします。