めもおきば 技術同人誌と記事のアーカイブ
About

Digital Appendix

『AIエージェントが見つけたサーバーレス』のデジタル付録

A-IDENTITY-01 版 0.11.0

身元、秘密、鍵、限定委任

身元、秘密、鍵、限定委任

対象本文

第6章のworkload identity、secret store、key management、短命資格、token exchange、MicroVM上の役割分離を補います。主権の外部鍵はA-SOVEREIGN-01、Lambda MicroVMsの統合例はA-RUNTIME-01も参照します。

収集方法

2026年7月10日に、AWS、Google Cloud、Microsoft Azure、Cloudflareのworkload identityとsecret管理の公式文書、IETF RFC 8693を確認しました。製品名の横並びより、身元、資格、秘密、暗号鍵、委任を別の資産として扱えるかを比較しています。

2026年8月6日に、短期資格の有効時間の現在値と長期キーのローテーション基準を追加しました。この回は作業環境から各公式文書ページの本体へ未到達(HTTP 403)だったため、検索結果スニペットの逐語照合によります。同日、著者がSecurity Hub IAM.3、AWSロールの最大セッション設定(既定1時間・1〜12時間・AWSサービスのセッションは対象外)、Google Cloudのaccess token(既定3,600秒・組織ポリシーで43,200秒)、Entra IDのaccess token既定有効期間(60〜90分のランダム・平均75分)を原文で確認しました。同日中に、managed identityの約24時間cache(managed-identities-faq)とAWS role chainingの1時間上限(AssumeRole API Reference)も著者が原文で確認し、この節の全数値の一次確認が完了しました(VD-CH06-CRED-TTLはresolved)。

現在の答え

提供者workloadの身元秘密の保管・参照暗号鍵設計上の境界
AWSIAM roleとservice-issued temporary credentialsSecrets Manager、Parameter StoreKMS、CloudHSM、external key storeroleとsecret resource policy、KMS key policyを別に評価
Google Cloudservice account、metadata server、Workload Identity FederationSecret ManagerCloud KMS、Cloud HSM、Cloud EKMidentity federationで外部workloadも長命keyなしにtoken交換
Microsoft AzureMicrosoft Entra managed identity、workload identity federationKey Vault secretsKey Vault keys、Managed HSM、external key managementsystem-assigned/user-assigned identityとvault RBACを分離
CloudflareWorker/Service Binding、Access service token等を用途別に使用Workers secrets、Secrets Storeproductごとのencryption/key機能account secretとscript binding、edge access、downstream credentialを分離

短期資格の有効時間の現在値です(2026-08-06時点。既定・上限とも提供者が変更し得ます)。書籍6.2の「尺の相場は時間単位」の内訳にあたります。

提供者経路既定上限・備考
AWSSTS AssumeRole(実行ロールの引き受け)1時間ロールの最大セッション設定は1〜12時間で、未指定なら既定1時間。この設定はAWSサービスが引き受けるセッションには適用されない。一時資格から別ロールを引き受けるrole chainingでは上限1時間で、超える指定は失敗する
Google Cloudservice accountのaccess token1時間(3,600秒)組織ポリシーconstraints/iam.allowServiceAccountCredentialLifetimeExtensionで許可したservice accountに限り12時間(43,200秒)
Microsoft AzureEntra IDのaccess token(一般)60〜90分のランダム(平均75分)既定有効期間は発行時にランダムに割り当てられ、要求の集中を分散する
Microsoft Azuremanaged identityのtoken(IMDS経由)未確定(既知の未知を参照)基盤側がresource URIごとにtokenを約24時間cacheし、期限前の強制リフレッシュは不可、権限変更の反映に数時間かかることがある。漏えい時に使える時間の見積もりはcache周期の上限側(約24時間)を使い、一般既定の60〜90分をこの経路へ適用しない

長期キー側の運用基準としては、CIS AWS Foundations Benchmark由来のAWS Security Hub検査IAM.3が、IAM userのaccess keyを90日以内にローテーションすることを求めます(実装はAWS Config規則access-keys-rotatedで、日数の基準値は既定の90日)。この基準は2026-08-06に原文表記「[IAM.3] IAM users’ access keys should be rotated every 90 days or less」を確認済みです。

共通方向は、codeへ固定資格を埋めず、基盤がworkloadの身元を証明し、その身元へ短命tokenと必要最小限のresource accessを与えることです。差は、identityをrole、service account、Entra principal、bindingのどこへ置き、secret storeとkey serviceをどのpolicy planeで結ぶかにあります。

次の四つは同義ではありません。

  1. 身元: どのworkload、user、agent、serviceが要求したか。
  2. 資格: 身元を短時間証明するtokenや署名可能なcredential。
  3. 秘密: 外部API keyやpasswordのように、対象serviceがまだ長命値を要求するときの値。
  4. 暗号鍵: dataを暗号化・復号・署名するkeyと、その使用policy。

RFC 8693のtoken exchangeは、subject_token、任意のactor_token、resource、audience、scopeを使って、入口のtokenを奥まで転送せず、対象を狭めたtokenへ交換する共通語彙を与えます。tenant_id、run_id、承認IDは標準項目ではなく、application固有の委任文脈として署名対象またはserver-side stateへ結びます。

Lambda MicroVMsをClaude Managed Agentsのself-hosted sandboxにする参照構成では、launcherがwebhook署名を検証して環境を起動し、MicroVMのroleがSecrets Managerの参照を実行時に読む一方、Anthropic organization API keyはAWS computeへ渡しません。これは、起動権限、webhook検証、secret参照、tool実行を分ける具体例です。

一次資料

記入用の雛形——権限・委任マトリクス(空欄版)

書籍第6章6.5の権限・委任マトリクスを自分のワークフローで書き出すための空欄版です。段階ごとに複製して使います。

ワークフロー:

段階:
利用者・主体:
接続するワークロードID:
対象資源と操作:
委任scope / audience / resource:
tenant・run・対象への拘束:
人間承認の要否と拘束するダイジェスト:
有効期限と再取得条件:
拒否時の動作:
監査証拠:

既知の未知

変更履歴

付録索引へ戻る / 書籍サポートへ戻る