Claude Platform on AWSのアクセスが3つの環境を統合、ただしセキュリティの成否はIAMの精度に左右される

AWSは、認証情報とセキュリティの要件が大きく異なるにもかかわらず、単一のサブスクリプションで利用できるClaude Platform on AWSの3つのアクセス経路を文書化した。

10月1日に公開された実装では、AWSワークロード、開発者のノートPC、外部サービスを、専用のAI Servicesアカウントが保持するワークスペースへ接続する。本番アプリケーションはクロスアカウントのSignature Version 4を使用し、開発者にはスコープを限定したAPIキーを付与、外部ワークロードはOpenID Connectフェデレーションで認証する。

このアーキテクチャは、すべての環境に単一の認証モデルを強いることなく、請求と管理の一元化を実現するとしている。一方で、その緊張関係も明白だ。一元化は所有権の管理を簡素化するが、広すぎるIAMポリシーや不適切に扱われた開発者キーは、この設計を有用にするワークスペース境界を弱めかねない。

これは単なるClaude統合ガイドではない。AWSの実装は、認証を環境別のコントロールプレーンへと変える。また、「単一のサブスクリプション」という表現の背後に隠れた運用作業も浮き彫りにする。

Amazon Bedrockは引き続き重要な参照点となる。これはAWSが管理する基盤モデルサービスを通じてClaudeモデルを提供する。対してClaude Platform on AWSは、API、コンソール、プラットフォーム機能を含むAnthropicのネイティブなプラットフォーム体験をAWSアカウント経由で提供する。

新たなアクセスパターンは、この違いをなくすものではない。IAMベースの本番トラフィック制御を維持しながら、企業がAWS組織全体にAnthropicのネイティブプラットフォームを拡張する方法を示している。

1つのサブスクリプションが3つの信頼境界に対応

重要な変更は、接続性の拡大だけではない。AWSは、ワークスペースの所有権を一元化したまま、3つの環境を3つの異なる認証方法に対応付けた。

提案されたトポロジーは、3つのアカウントロールから始まる。管理アカウントが組織レベルの請求とガバナンスを担い、専用のAI ServicesアカウントがClaude Platformのサブスクリプション、ワークスペース、APIキー、アクセスロールを所有する。

その後、1つ以上のワークロードアカウントがサブスクリプションを所有せずにClaude推論を利用する。アプリケーションはAI Servicesアカウント内のロールを引き受け、そのロールで認可されたワークスペースリソースを呼び出す。

この分離により、AI Servicesアカウントには明確な目的が与えられる。無関係なリソースで埋め尽くされた一般的なアプリケーションアカウントではなく、Claudeアクセスを囲む管理上の境界となる。

AWSは、このアカウント内に本番用と開発用のワークスペースを分けて作成することを推奨している。ワークスペースは、管理を一元化したままチーム、プロジェクト、環境を分離するためのリソース境界だ。

各ワークスペースには、IAMポリシーから参照できるAmazon Resource Name、すなわちARNがある。そのため、あるワークスペースに対する推論を認可しても、別のワークスペースまで自動的に認可する必要はない。

最初のアクセス経路は、すでにAWS内で実行されているアプリケーションを対象とする。AWSはAmazon EKSのPodを例に挙げているが、このパターンは他のAWSワークロードにも適用できる。

そのPodはまず、AI Servicesアカウント内のクロスアカウントロールを引き受ける。次に、一時的な認証情報を使って、一般にSigV4と呼ばれるAWS Signature Version 4でClaudeリクエストに署名する。

SigV4はAWS認証情報を用いてAWS APIリクエストに暗号学的署名を行う。これにより、受信側サービスは別個の静的APIシークレットなしに、呼び出し元、リクエストの完全性、認可コンテキストを検証できる。

クロスアカウントロールは、本番ワークスペースARNに対する選択済みのaws-external-anthropicアクションを許可する。この例には、推論、トークン数の計算、モデル取得、モデル一覧取得が含まれる。

このロールに開発ワークスペースへのアクセス権は不要だ。これにより、ワークロードID、許可されたAPIアクション、利用可能なClaudeワークスペースの間に直接的な関係が生まれる。

2つ目の経路は開発者のノートPCを対象とする。開発者はしばしば、デプロイ済みのワークロード外でプロンプト、SDKの挙動、アプリケーションロジックをテストするための、より摩擦の少ない手段を必要とする。

AWSは、これらのユーザーに開発ワークスペースと紐付いた長期利用のAPIキーを割り当てる。標準のAnthropic SDKは、そのキーをClaude Platform on AWSのリージョナルエンドポイントに対して使用できる。

この経路は使い慣れた開発者体験を維持する一方で、永続的なベアラー認証情報を生み出す。キーを保持する者は誰でも、有効期限が切れるか管理者が無効化するまで、その権限を利用できる。

3つ目の経路は外部サービスを対象とする。例には、Google Cloud上のワークロード、AWS以外のKubernetesクラスター、GitHub ActionsやGitLab CIなどのCI/CDシステムが含まれる。

これらのサービスはOIDCフェデレーションを使用し、IDプロバイダーが署名したトークンを一時的なAWS認証情報と交換する。一時的な認証情報から、短命のClaudeベアラートークンが生成される。

AWSの例では、有効期間1時間のトークンを作成する。実装では最大12時間まで有効期間を設定でき、その後、外部サービスは新たなトークンを取得する必要がある。

これら3つの経路が、Claudeのマルチ環境アクセスの中核を構成する。サブスクリプションは1つのアカウントに置かれ、認証は呼び出し元の実行場所に応じて変化する。

これがアーキテクチャ上の進展だ。EKSのPod、開発者のノートPC、外部パイプラインが、単一の汎用認証情報パターンを共有すべきではないことを認識している。

Claude Platform on AWSのアクセスは制御をIAMへ移す

Claude Platform on AWSへのアクセスは、コードの実行場所よりも、IAMが意図されたIDとワークスペースを正確に記述しているかどうかに左右されるようになった。

AWSは、既存のAWSアカウントを通じてAnthropicのネイティブプラットフォームを利用する手段としてこのサービスを導入した。同社によれば、AWSは自社のアカウント構造を通じてネイティブ体験を提供する最初のクラウドプロバイダーだった。

当初の発表では、認証、請求、監査機能をAWSに接続した。顧客は別途の商取引関係を確立せずに、AnthropicのAPIとツールを利用できた。

マルチ環境設計は、この提案を基本的なAPI接続の先へと拡張する。個々のアプリケーションではなくAWS組織を、Claudeアクセスを編成するレイヤーに位置付ける。

これは重要だ。企業におけるAI利用は、1つの環境内にとどまることはほとんどない。チームはアプリケーションをローカルでテストし、EKSへデプロイし、別のクラウドから評価を実行することがある。

共有の静的キーは3つの場所すべてを接続できるが、それらのIDも一体化してしまう。ログに表示されるのはキーであり、必ずしもそれを使用したワークロード、アカウント、パイプラインではない。

クロスアカウントロールはより多くのコンテキストを保持する。ワークロードは名前付きロールを引き受け、一時的な認証情報を取得し、AWSがプリンシパルに帰属させられる署名付きリクエストを送る。

このロールは、2つの認可チェックポイントも作る。ワークロードアカウントは、そのローカルIDによる対象ロールの引き受けを許可しなければならない。AI Servicesアカウントは、そのIDと組織を信頼する必要がある。

AWSの例では、信頼ポリシーにaws:PrincipalOrgID条件を追加している。この条件により、指定されたAWS組織に関連するプリンシパルにロールの引き受けを制限する。

次に、アクセス許可ポリシーが推論を本番ワークスペースARNに限定する。信頼は誰がロールに入れるかを決め、アクセス許可はそのロールがその後に何を行えるかを定義する。

この分離は、以前はモデルアクセスをシークレット配布として扱っていたチームに新たな負荷をかける。Claude AWS認証を、IDアーキテクチャとして管理する必要が生じるからだ。

セキュリティ、プラットフォーム、アプリケーションの各チームは、アカウントの所有権について合意しなければならない。ロール、ワークスペース、ポリシー、環境マッピングの命名標準も必要になる。

専用アカウントは、こうした責任を可視化できる。ただし、それだけで設定が正しくなるわけではない。

このアーキテクチャはインシデント対応にも影響する。本番ロールは、開発者アクセスを直ちに削除することなく無効化できる。侵害された開発キーも、EKSワークロードロールを変更せずに無効化できる。

ワークスペースの分離は、コスト配分も支援できる。AWSによると、組織はワークスペースにタグを付け、コスト配分用にそのタグを有効化できる。

AWSによると、有効化には24〜48時間かかる場合があり、その後、チームはAWS Cost Explorerのデータをワークスペース別にフィルタリングできる。これにより、技術的な分離からプロジェクトレベルの支出分析へ至る道筋が生まれる。

監査可能性には、別の明示的な選択が必要だ。ワークスペース管理はデフォルトでCloudTrail管理イベントに記録されるようだが、推論はデータイベントのカテゴリーに属する。

監視に関するドキュメントによると、推論やその他のワークスペース操作を記録するには、チームがデータイベントのログ記録を有効にする必要がある。これらのイベントはCloudTrailの追加料金を発生させる可能性もある。

この違いは見落としやすい。サブスクリプションを一元化すれば監査証跡の可能性は高まるが、推論アクティビティが記録されていることまでは保証しない。

そのため、この設計はプラットフォーム所有者に対し、可観測性をアクセス制御の一部として扱うよう求める。ポリシーはアクションを制限できる一方、ログは実際にどのプリンシパルがそれを実行したかの証拠を提供する。

3つの認証経路は異なる問題を解決する

このアーキテクチャが機能するのは、利便性、ワークロードID、外部フェデレーションを同じ認証情報ライフサイクルに無理に押し込まないためだ。

AWSワークロードにとって、クロスアカウントSigV4は既存のクラウドIDとの最も自然な整合性を提供する。アプリケーションはロールを引き受けることで、一時的なAWS認証情報を取得する。

次に、Claudeエンドポイントへの各リクエストに署名する。ワークロードアカウント、コンテナイメージ、デプロイ設定に、別途Claude APIキーを保存する必要はない。

このアプローチは、確立されたAWSのガイダンスに沿う。同社のIAMベストプラクティスは、長期利用のアクセスキーではなく、ワークロード向けの一時的なロール認証情報を推奨している。

本番ロールには、アプリケーションが必要とするアクションだけを含められる。基本的な同期アプリケーションでは、推論とトークン数計算の権限が必要になる場合があるが、ファイル、バッチ、管理アクションは不要かもしれない。

Claude Platform on AWSはaws-external-anthropic IAM名前空間を使用する。そのアクセス許可モデルは、メッセージリクエスト用のCreateInferenceなど、APIルートを個別のアクションに対応付ける。

このアクションは1つのワークスペースARNを参照できる。アプリケーションは、アカウント全体に及ぶClaude権限を継承することなく、本番ワークスペースへのアクセスを得る。

これは継続的に実行されるAWSワークロードにとって、3つの経路の中で最も強力だ。アプリケーションは永続的なClaudeシークレットを保持せず、AWSはリクエストを引き受けられたIDに帰属させられる。

開発者のノートPCには異なる制約がある。すべてのローカル実験でクロスアカウントロールチェーンを経由させると、セットアップコストが上がり、反復作業が遅くなる可能性がある。

そのためAWSは、開発用にワークスペーススコープのAPIキーを使用する。このキーは標準のAnthropicクライアントで動作し、Claude Platform on AWSのリージョナルエンドポイントを指す。

重要な留保は、このパターンのために新たに生成したキーが、自動的に十分狭い権限を持つわけではない点だ。AWSによると、その基盤となるIAMユーザーには、当初AnthropicLimitedAccessマネージドポリシーが付与される。

実装ガイドによれば、このマネージドポリシーはワークスペース全体へのアクセスを許可する。管理者はこれをデタッチし、開発用途に限定したインラインポリシーへ置き換える必要がある。

その手順は、開発者向け経路において最も重要な手動制御です。キーの生成自体は容易ですが、意図したワークスペース境界を強制するには、別途IAMの変更が必要です。

AWSは、その後に境界をテストすることを推奨しています。開発者はまず開発用ワークスペースへの呼び出しを成功させ、次に本番環境へのリクエストを試行し、IAMによって拒否されることを確認すべきです。

このネガティブテストは、成功したリクエストより重要です。開発環境からの応答は接続性を示すにすぎませんが、本番環境への呼び出しが拒否されて初めて、分離という主張を検証できます。

APIキーは引き続き自己認証型です。キーを所持していること自体が認証情報となるため、AWS、別のクラウド、またはノートPCから利用できます。

したがってチームは、承認済みのシークレットマネージャーに保存し、有効期限を設定すべきです。紛失したデバイス、役割変更、リポジトリへの誤公開に備えた失効手順も必要です。

外部ワークロードの経路では、この永続的なシークレットを不要にします。OIDCにより、互換性のあるIDプロバイダーがワークロードを識別するJSON Web Tokenを発行できます。

AWS Security Token Serviceはトークンを検証し、ロールの信頼条件を確認します。その後、AssumeRoleWithWebIdentityを通じて一時的なAWS認証情報を返します。

OIDC guidanceでは、長期認証情報の埋め込みを回避できるため、AWS外部のアプリケーションにはこのパターンを推奨しています。

外部ワークロードは一時的なAWS認証情報を使用し、短期間有効なClaudeベアラートークンを要求します。生成後、このベアラートークンを使えば、AWS認証情報を保持せずにClaudeを呼び出せます。

これは外部コンテナやCI/CDジョブで有用ですが、トークン更新はアプリケーションの一部になります。継続稼働するサービスは、有効期限前にトークンを更新しなければなりません。

OIDCの信頼ポリシーにも細心の注意が必要です。AWSの例では、トークンのオーディエンスおよびサブジェクトクレームを期待値と照合しています。

オーディエンスは、トークンの想定受信者を識別します。サブジェクトは、許可されたワークロード、サービスアカウント、リポジトリ、またはパイプラインIDを区別します。

緩いクレームフィルターは、意図した以上の外部IDを受け入れる可能性があります。正しいフェデレーション機構であっても、信頼条件が不正確なら過剰なアクセスを生み出します。

したがって、これらの経路は相互補完的であり、代替可能なものではありません。

• クロスアカウントSigV4は、すでにAWS IDで管理されている本番ワークロードに適しています。

• ワークスペーススコープのAPIキーは、ローカル開発の摩擦を減らします。

• OIDCフェデレーションは、検証可能なワークロードIDを提示できる外部自動化に適しています。

共通要素はワークスペースです。各認証情報経路は最終的に、その環境に適したワークスペース権限へ解決されるべきです。

一元化しても認証情報リスクはなくならない

設計が分離を改善するのは、すべてのロール、キー、信頼条件、エンドポイント、ログ設定が意図したワークスペースと一致している場合に限られます。

最も明確なリスクは開発者向け経路にあります。AWS自身の手順では、生成直後のAPIキーには、すべてのワークスペースへアクセスできる管理ポリシーが付与されているとされています。

管理者は、新たに作成されたバックエンドIAMユーザーを特定し、そのポリシーを削除して、より限定的なインラインポリシーをアタッチしなければなりません。

このワークフローは人的ミスの影響を受けやすいものです。管理者が誤ったユーザーをスコープ対象にしたり、管理ポリシーを残したり、誤ったワークスペースARNを参照したりする可能性があります。

その結果生じるキーも、引き続き機能します。開発用リクエストの成功だけでは、本番環境へのアクセスも保持していることは分かりません。

必須の拒否テストであれば、その誤りを検出できます。組織は本番環境アクセスのテストを、後から任意で行う検証ではなく、キー発行プロセスの一部にすべきです。

長期キーは、ロールベースのアクセスよりも帰属追跡が弱くなります。複数の開発者が1つのキーを共有すると、監査記録上は同一プリンシパルとして表示される可能性があります。

個人ごとのキーは帰属追跡を改善しますが、安全な保管、有効期限、失効、所有者追跡を必要とする認証情報の数を増やします。

クロスアカウント経路には別の失敗モードがあります。信頼ポリシーが広すぎる場合や、ワークロード側の引き受け権限が誤ったターゲットロールに到達する場合です。

aws:PrincipalOrgID条件は組織スコープの制限に役立ちます。ただし、正確なプリンシパルARNや慎重なロール命名の代わりにはなりません。

権限についても、アクションレベルでのレビューが必要です。aws-external-anthropic名前空間全体にワイルドカードアクセスを付与すれば、このガイドが示す最小権限構造を損ないます。

AWSは、単一ワークスペースでの推論やその他の制御のための詳細なIAM policy examplesを公開しています。チームは、実際に使用するAPI機能に対して、デプロイ済みポリシーを検証すべきです。

OIDC経路では、セキュリティの重心が外部IDクレームに移ります。その安全性は、発行者、オーディエンス、サブジェクトフィルター、ロールポリシー、トークン更新ロジックが連携して機能することに依存します。

リポジトリグループ全体を対象とするサブジェクトパターンは、無関係なパイプラインを認可する可能性があります。広範なサービスアカウントパターンは、意図した名前空間外のワークロードを受け入れる可能性があります。

一時認証情報は露出期間を制限しますが、その期間中の過剰な権限を修正するものではありません。短期間のアクセスは恒久的なアクセスより安全ですが、自動的に最小権限になるわけではありません。

生成されたClaudeトークンも、独立したベアラー認証情報になります。有効期限までは、所持しているだけで継承された認可境界内で利用できます。

アプリケーションは、ログ、ビルド出力、例外トレース、監視メタデータにトークンを出力しないようにすべきです。実務上可能な場合、トークンの有効期間はジョブの実行時間に合わせるべきです。

リージョンの動作も、別の運用上の制約を加えます。ワークスペースはAWSリージョン内に作成され、APIリクエストは対応するリージョンエンドポイントを対象にしなければなりません。

AWSは、このエンドポイントへのバインディングを推論の地理的範囲と区別しています。ワークスペースのセキュリティ設定によって、推論が米国ルーティングとグローバルルーティングのどちらを使用するかが独立して決まります。

短期キーは、生成されたリージョンと同じエンドポイントでのみ機能します。AWSのガイドによると、長期APIキーはリージョンに固定されません。

この違いは、デプロイ時に分かりにくい障害を生む可能性があります。トークン更新プロセスはあるリージョンで成功していても、アプリケーションが別のエンドポイントを参照している場合があります。

このアーキテクチャには、利用者が理解すべきより広い境界もあります。AWSによれば、Claude Platform on AWSはAnthropicによって運用され、リクエストとデータはAWSのセキュリティ境界の外部で処理されます。

これは、すべての処理がAWS管理のサービス境界内にとどまるという想定とは異なります。厳格なデータ所在地要件を持つ組織には、別途レビューが必要です。

AWSは、Claude Platform on AWSをAmazon Bedrockで利用可能なClaudeモデルと補完的なものとして位置付けています。したがって、選択は単に認証方式同士を比較するものではありません。

プラットフォーム機能、運用上の所有権、処理境界、リージョン要件も含まれます。マルチ環境アクセスは、すべてのワークロードに対してこれらの問題を解決するわけではありません。

一元化は、管理上のミスによる影響範囲を広げる可能性もあります。AI Servicesアカウントは、サブスクリプション、ワークスペース、APIキー、アクセスロールを保持します。

そのアカウントでの変更は、複数のアプリケーションアカウントに同時に影響する可能性があります。したがって設計では、このアカウントに対し、カジュアルな開発環境より強力な変更管理を適用すべきです。

可能であれば、チームはポリシー作成と承認を分離すべきです。Infrastructure as Codeは、追加のチームやワークスペース間でロール定義の不整合を減らすことにも役立ちます。

AWSによれば、より多くの環境を持つ組織は、チームまたはワークロードごとにワークスペースを作成し、クロスアカウントロールのパターンを繰り返すことができます。

このアプローチは分離モデルを拡張できますが、同時にポリシー、ロール関係、ログ、タグ、エンドポイント設定も増加させます。運用規律が制約要因になります。

したがって、一元化という中核的な約束は慎重に表現すべきです。このパターンはワークスペース分離の構成要素を提供しますが、その分離が維持されるかは、デプロイされたポリシーと認証情報の扱いによって決まります。

次に企業が検証すべきこと

次の検証は、3つの認証フローがデモで動作するかではなく、組織がこのアクセスモデルを一貫して運用できるかどうかです。

最初の指標は、自動化されたポリシー検証です。チームは、すべての本番ロールが想定される1つのワークスペースARNと必要なAPIアクションだけを対象としていることを確認すべきです。

開発者キーの発行には、ポリシーの置き換え、有効期限、シークレット保管、強制的な本番アクセス拒否テストを含める必要があります。記憶に依存するプロセスは、いずれ必ず逸脱します。

組織がデプロイパイプラインを通じてこれらのチェックを自動化すれば、AWSの一元化モデルは大規模運用においてより信頼できるものになります。反復的な手動例外は、その結論を弱めます。

2つ目の指標は監査カバレッジです。CloudTrailの管理イベントだけでは、呼び出し単位の推論可視性は得られません。

組織は、関連するClaudeワークスペースリソースタイプのデータイベントを有効化し、記録に有用なプリンシパルの帰属情報が含まれることを検証すべきです。

また、インシデント対応者がリクエストをEKSロール、開発者キー、外部OIDC IDに結び付けられるかもテストすべきです。

監査経路がこれらの違いを保持するなら、3経路のアーキテクチャは説明責任のあるアクセスを支援します。ログが呼び出し元を共有IDへと平坦化してしまうなら、一元化の調査上の価値は低くなります。

3つ目の指標は、AWSネイティブアプリケーションを超えた採用です。OIDC経路は、外部クラウド、Kubernetesデプロイメント、CI/CDシステム向けに設計されています。

実際の試金石は、長時間稼働するジョブ中にトークンを確実にローテーションできることです。リポジトリやサービスアカウントが変化しても、チームは狭いサブジェクトおよびオーディエンスクレームを維持しなければなりません。

認証障害が頻発すれば、開発者は長期シークレットへ回帰するでしょう。正確な信頼条件による安定した更新は、フェデレーション方式を強化します。

企業はワークスペースの増殖も監視すべきです。チームまたはワークロードごとに1つのワークスペースを作成すれば、分離、所有権、コスト配分を改善できます。

一貫したラベルやライフサイクルルールなしにワークスペースが増えすぎると、別の形のスプロールを生みます。古いキー、放棄されたロール、未使用のワークスペースには廃止プロセスが必要です。

専用のAI Servicesアカウントは、ガバナンスされたサービス境界となるべきです。その管理者には、すべてのワークスペース、ロール、認証情報に関する所有権記録が必要です。

プラットフォームチームは、アクセス判断をアプリケーションアーキテクチャやインシデント手順とともに記録できます。検索可能なengineering knowledge baseは、チームの変化に伴ってこうした対応関係を維持するのに役立ちます。

最も有用な評価は、1つの完全なアプリケーション経路から始まります。本番ワークロードをSigV4で接続し、開発クライアントを制限付きキーで接続し、パイプラインをOIDCで接続します。

次に、クロスワークスペースリクエストの拒否、トークン更新、CloudTrailデータイベント、緊急時の失効を検証します。これらの制御は、通常のポリシー変更後も維持されるでしょうか。

その答えは、最初のリクエストが成功することより重要です。Claude Platform on AWSのアクセスは現在、1つのサブスクリプションの下で3つの環境をサポートしていますが、そのセキュリティ価値は、分離を繰り返し証明できるかにかかっています。