Claude Platform on AWSのIAMアクション一覧と最小権限ポリシー

Claude Platform on AWSでは、APIの全ルートがAWS IAMのアクションに対応します。サービスプレフィックスはaws-external-anthropic、リソースタイプはworkspaceの1種類で、アクションは71個です。この記事では、ルートとアクションの対応、マネージドポリシー5種の中身、そして「推論だけ許したつもりが読み取り権限まで付く」落とし穴を見ます。最後に、ワークスペース単位の分離とZDR(Zero Data Retention)向け機能ロックダウンの例ポリシーを載せます。

セットアップと認証の流れはClaude Platform on AWSでClaude Codeを使うで扱っています。ここは権限設計に絞ります。

71アクションはどう分類されるか

アクション名はAWSのVerbNoun形式です。Get*とList*のワイルドカードで読み取り専用の境界が引けるよう、動詞が使い分けられています。リソースはワークスペースのARNで指定します。

arn:aws:aws-external-anthropic:{region}:{account-id}:workspace/{workspace-id}

ARNのリージョンは、ワークスペースが紐づくリージョンです。末尾はwrkspc_...形式のワークスペースIDで、anthropic-workspace-idヘッダーに渡す値と同じものです。

71個を機能別に数えると次のとおりです。

最後の2つは、どのルートにも対応しない特殊なアクションです。CallWithBearerTokenは、SigV4ではなくAPIキー(ベアラートークン)で認証するための権限です。AssumeConsoleは、AWSコンソールの「Open Claude Console」からClaude Consoleを開くための権限で、ConsoleのAdminかDeveloperというロールは、IAM権限とは別にAnthropicの担当者が割り当てます。

ルートとアクションの対応で気をつける点

対応表そのものは長いので、要点だけ拾います。あるアクションが複数のルートを許可する場合があり、しかも動詞から想像する範囲と一致しないことがあります。

• GetBatchInferenceは、バッチのメタデータ取得と結果ダウンロードの両方を許可する
• GetFileは、ファイルのメタデータとコンテンツ(バイト列)取得の両方を許可する
• GetSkillは、スキルのメタデータとバージョン一覧、コンテンツのダウンロードを許可する
• GetSessionは、セッションのメタデータに加えて、イベント全体(会話履歴)とセッションリソースの読み取りを許可する
• GetMemoryStoreは、ストアのメタデータ、すべてのメモリ、メモリのバージョン履歴の読み取りを許可する

つまりGet*は「メタデータ取得」ではなく「中身の読み取り」を含みます。読み取り専用のつもりで付けた権限で、ファイルの実体や会話履歴が読めます。

Denyの網をすり抜ける動詞

もう一つの注意点は、書き込み系の動詞が名前どおりに分かれていないことです。次の対応を知らずにDelete*だけを拒否しても、削除相当の操作は止まりません。

ProcessEnvironmentWork、RotateWebhookSecret、RegisterKey、DisableKeyは、Create*・Update*・Delete*のいずれのワイルドカードにも当たりません。ある種類のリソースの変更を完全に禁じたいなら、Create*・Update*・Archive*と個別動詞を列挙して拒否します。

*Fileのような接尾辞パターンにも罠があります。IAMのアクション照合は大文字小文字を区別しないため、aws-external-anthropic:*FileはCreateFile・GetFile・DeleteFileに当たる一方、ListFilesには当たりません。さらに「Profile」の末尾も「file」なので、CreateUserProfile・GetUserProfile・UpdateUserProfileまで巻き込みます。Files APIだけを対象にするなら、4つのアクションを明示的に並べます。

CloudTrailでの分類

CloudTrailでは、各アクションがデータイベントか管理イベントに分類されます。ボールトとWebhookは、秘密情報(ボールト認証情報とWebhook署名シークレット)を扱うため管理イベントです。ワークスペース、暗号鍵、コンプライアンスも組織単位のコントロールプレーン操作なので管理イベントになります。

推論、バッチ、モデル、ファイル、スキル、ユーザープロファイル、それ以外のManaged Agents系アクションはデータイベントです。データイベントは大量に発生する種類の記録なので、監査ログの設定で扱いが変わります。設定はAWS側のCloudTrailの仕様に従います。

また、各アクションはanthropic-betaヘッダー付きのリクエストにも使われます。ベータ版ルートのために別のアクションを許可する必要はありません。対応表にないルートは、ゲートウェイが既定で拒否します。Admin APIとして使えるのは、ワークスペースと暗号鍵のルートだけです。

マネージドポリシー5種

AWSは5つのマネージドポリシーを提供しています。いずれもResource: "*"が対象です。

推論に足りる最小のマネージドポリシーはAnthropicInferenceAccessです。同期・バッチの両方の推論をカバーします。一方で、名前から受ける印象より読み取りの範囲がはるかに広い点に注意が必要です。

推論用ポリシーで読めてしまうもの

AnthropicInferenceAccessはGet*とList*を含むため、名前空間内のあらゆるリソースを読めます。ファイルの実体、スキルの中身、バッチの結果、セッションの会話履歴、メモリの内容が対象です。GetKeyとListKeysも含まれるので、組織に登録された暗号鍵のARNとメタデータも見えます(鍵の実体は見えません)。List*はListComplianceActivitiesも含み、Compliance APIが組織で有効化されていれば、組織全体の監査ログであるアクティビティフィードを読めます。

読めないものもあります。ボールトの認証情報の秘密フィールドとWebhookの署名シークレットは書き込み専用で、GetVaultやGetWebhookは返しません。ファイルの作成・削除、スキル管理、ユーザープロファイル管理、ワークスペースの変更、暗号鍵の管理、Managed Agentsの書き込み系(作成・更新・アーカイブ・削除・処理・ローテーション)も含まれません。

既存の内容を読ませたくない主体には、必要なアクションだけを列挙したカスタムポリシーを使います。Managed Agents系の読み取りも除きたい場合は、AnthropicInferenceAccessの代わりに、必要な非Managed Agentsのアクションだけを並べます。

混同しやすい別の点

CreateInferenceとCreateBatchInferenceは別のアクションです。片方を拒否してももう片方は止まりません。モデル呼び出しを全面的に止めたいなら、両方を拒否します。

AssumeConsoleは、AnthropicReadOnlyAccess・AnthropicInferenceAccess・AnthropicLimitedAccess・AnthropicSelfHostedEnvironmentAccessのいずれにも含まれません。Claude Consoleへの導線が必要な主体には、AnthropicFullAccessか、AssumeConsoleを明示したカスタムポリシーが要ります。

セルフホスト型サンドボックスのワーカーには、AnthropicSelfHostedEnvironmentAccessが最小のマネージドポリシーです。ワーカーが認証するプリンシパルにだけ付けます。ProcessEnvironmentWorkは他のワイルドカードに当たらない専用アクションで、ワーカー以外に渡す理由がありません。

例ポリシーで見る設計パターン

以下は、ドキュメントの例に沿った形です。ARNのアカウントIDとワークスペースIDはダミーです。

単一ワークスペースの同期推論

本番ワークスペース1つに対して推論だけを行うプリンシパルの最小構成です。

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "aws-external-anthropic:CreateInference",
        "aws-external-anthropic:CountTokens",
        "aws-external-anthropic:GetModel",
        "aws-external-anthropic:ListModels",
        "aws-external-anthropic:GetWorkspace"
      ],
      "Resource": "arn:aws:aws-external-anthropic:us-west-2:123456789012:workspace/wrkspc_01AbCdEf23GhIj"
    }
  ]
}

AnthropicInferenceAccessと違い、読み取りはGetModel・ListModels・GetWorkspaceだけに絞られています。ListWorkspacesはアカウント単位のアクションなので、ワークスペースの一覧が必要ならResource: "*"の別ステートメントを足します。APIキーで認証する主体には、CallWithBearerTokenをResource: "*"で別ステートメントとして足します。このアクションはルートを持たず、ワークスペースARNに束縛できないためです。

ワークスペース単位の分離

顧客ごと、あるいはチームごとに、ロールを1つのワークスペースへ閉じ込める型です。

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "aws-external-anthropic:*",
      "Resource": "arn:aws:aws-external-anthropic:us-west-2:123456789012:workspace/wrkspc_01AbCdEf23GhIj"
    },
    {
      "Effect": "Allow",
      "Action": [
        "aws-external-anthropic:CallWithBearerToken",
        "aws-external-anthropic:AssumeConsole"
      ],
      "Resource": "*"
    }
  ]
}

1つ目のステートメントの*には、アカウント単位のアクション(CreateWorkspace、ListWorkspaces、ListComplianceActivities、暗号鍵系)も含まれます。ただし、ワークスペースARNの制約で実質的に無効になります。その結果、このロールはワークスペースの作成や一覧、暗号鍵登録の管理、コンプライアンスのアクティビティフィードの読み取りができません。効かない権限が入っているという意味で、ポリシーとしては少し冗長です。

もう一つ見落としやすい点があります。自分のワークスペースに登録済みの鍵を紐づける操作は、UpdateWorkspaceで許可されます。SigV4だけで使い、Claude Consoleも開かないロールなら、2つ目のステートメントは外せます。

ZDR対象ワークスペースの機能ロックダウン

バッチ処理とファイルアップロードを止め、同期推論だけを残す例です。サーバー側に残してはいけないZDR対象のデータを扱うワークスペースを想定しています。

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Deny",
      "Action": [
        "aws-external-anthropic:CreateBatchInference",
        "aws-external-anthropic:CreateFile"
      ],
      "Resource": "arn:aws:aws-external-anthropic:us-west-2:123456789012:workspace/wrkspc_01AbCdEf23GhIj"
    }
  ]
}

Denyだけのポリシーは、単独では何も許可しません。AnthropicInferenceAccessや上の単一ワークスペース例のようなAllowポリシーと併用します。

このDenyが止めるのは作成だけです。ワークスペースに「ファイルもバッチも存在しない」状態を保ちたいなら、次のアクションも足して拒否します。

• ファイル: GetFile、ListFiles、DeleteFile
• バッチ: GetBatchInference、ListBatchInferences、CancelBatchInference、DeleteBatchInference

先の対応表から分かるとおり、AnthropicInferenceAccessにAllowされたGet*・List*は、ここでDenyを足さない限り既存ファイルの読み取りを許します。Denyは明示的に書いたものだけが効くので、列挙漏れがそのまま穴になります。

ワークスペース管理の自動化

CI/CDのロールにワークスペースの作成と管理だけを任せる例です。推論の権限は付けません。

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "aws-external-anthropic:CreateWorkspace",
        "aws-external-anthropic:GetWorkspace",
        "aws-external-anthropic:ListWorkspaces",
        "aws-external-anthropic:UpdateWorkspace",
        "aws-external-anthropic:ArchiveWorkspace"
      ],
      "Resource": "*"
    }
  ]
}

CreateWorkspaceとListWorkspacesはアカウント単位なので、ワークスペースARNを指定しても効果がなく、Resource: "*"を使います。ワークスペースの作成・更新・アーカイブは、AWSコンソールや、Adminロールを持つClaude Consoleからも行えます。

ポリシーを付ける手順

ポリシーJSONをファイルに保存したら、AWS CLIでロールにインラインポリシーとして付けられます。

aws iam put-role-policy \
  --role-name claude-inference-role \
  --policy-name claude-single-workspace \
  --policy-document file://single-workspace.json

ロール名とポリシー名は例です。上の「機能ロックダウン」のように、AllowとDenyを別のポリシーに分けても、同じロールにまとめて付けられます。IAMは明示的なDenyを常に優先します。

設計の判断軸

設計の起点は、そのプリンシパルが「何を読めるか」を先に決めることです。書き込み側は列挙で絞りやすい一方、読み取り側はワイルドカードで広がりがちです。

Claude Code Bedrock IAM設定とクロスリージョン推論プロファイルの組み方でBedrock側の設計を扱っています。Claude Platform on AWSではワークスペースが権限のリソース単位で、同じAPIにファイルやセッションなど保存を伴うリソースが載ります。そのぶん、読み取りの範囲を意識する必要があります。

まとめ

Claude Platform on AWSの権限設計は、71アクションのうち、どれを許すかではなく、どれを許してしまっているかを確かめる作業です。推論用のAnthropicInferenceAccessは最小のマネージドポリシーですが、Get*とList*のために、ファイルの実体からセッションの会話履歴まで読めます。読ませたくないなら、単一ワークスペース例のようにアクションを列挙します。

変更を禁じるDenyは、Delete*だけでは足りません。UpdateSkill・UpdateSession・UpdateVault・UpdateMemoryStore・Archive*・ProcessEnvironmentWork・RotateWebhookSecret・RegisterKey・DisableKeyが別の動詞で残ります。403やAccessDeniedの切り分けは、Claude Platform on AWSでClaude Codeを使うのトラブルシューティングも参照してください。