✅

Amazon Bedrockの長期APIキー作成と短期APIキー利用をIAMポリシーで拒否してみた

xthixsl_ml@レオナ

2026/08/08に公開

 はじめにFusicのレオナです。
Amazon Bedrockでは、AWS標準の署名認証であるSigV4に加えて、APIキーによるBearer認証を利用できます。また、APIキーには既存のAWS認証情報から生成する短期APIキーと、IAMユーザーに関連付けて発行する長期APIキーがあります。
利用環境やシステムのセキュリティ方針によっては、長期APIキーを新しく作成できないようにしたり、APIキーによるアクセスだけを制限したりしたい場合があります。
そこで本ブログでは、IAMユーザーやIAMロールに付与するアイデンティティベースのポリシーを使用し、以下の4点を検証します。
Amazon Bedrockの長期APIキーを新しく作成できないようにする
作成済みの長期APIキーによるAmazon BedrockおよびAmazon Bedrock Mantleのモデル一覧取得を拒否する
短期APIキーによるAmazon BedrockおよびAmazon Bedrock Mantleのモデル一覧取得を拒否する
短期APIキーによるアクセスを拒否した後も、同じAWS STS一時認証情報を使ったSigV4認証で、Amazon BedrockのListFoundationModelsを実行できることを確認する
まず、IAMポリシーによる明示的な拒否（Deny）を適用する前後で実行結果を比較し、それぞれの操作を制限できるか確認します。その後、検証結果をもとに、今回の制御をどのような場面で利用できるのかを整理します。
検証では、AWS CLIを使ってIAMポリシーを付与し、IAM Policy Simulatorでポリシーの判定を確認します。さらに、CloudTrailの監査ログから、実際のAPI実行結果を確認します。
以前にAWSマネジメントコンソールでAPIキーの作成手順についてブログにまとめたので合わせてご覧ください。
https://zenn.dev/fusic/articles/23f9bd726b3aee

 検証の前提
 長期APIキーと短期APIキーAmazon BedrockのAPIキーには、長期APIキーと短期APIキーがあります。主な違いは以下のとおりです。


項目
長期APIキー
短期APIキー


基になるIAM主体
IAMユーザー
既存のIAMユーザーまたはロールセッション

有効期間
設定した有効期限まで
最長12時間、または生成元セッションの残存時間の短い方

AWSの位置付け
探索用途のみ
本番利用で推奨

新規作成を制御する方法
iam:CreateServiceSpecificCredential
生成専用の拒否アクションなし

利用を制御する方法
関連IAMユーザーでBearer認証を制御
生成元プリンシパルでBearer認証を制御

長期APIキーは、IAMのService-specific credential、つまり特定のAWSサービス専用のIAM資格情報として作成されます。[1]iam:ServiceSpecificCredentialServiceName条件キーを使うと、Amazon Bedrock向けの資格情報だけに制御を限定できます。[2]
短期APIキーは、生成元プリンシパルの権限を引き継ぎます。有効期間は最長12時間で、生成元セッションの残存時間が短ければ、そちらに合わせて失効します。また、生成したリージョンでのみ利用できます。[3]

 対象とするエンドポイントAmazon Bedrock APIキーは、次の2つのエンドポイントで利用できます。
Amazon Bedrockエンドポイント
Amazon Bedrock Mantleエンドポイント
Amazon Bedrock Mantleは、OpenAI互換形式のAPIを提供するエンドポイントです。本ブログでは、Amazon BedrockのListFoundationModelsと、Amazon Bedrock Mantleで利用可能なモデルを取得するGET /v1/modelsを使用します。[4]
AuthorizationヘッダーにAPIキーをBearerトークンとして指定する方式を、本ブログではBearer認証と呼びます。2つのエンドポイントでは、Bearer認証の利用を制御するIAMアクションが分かれています。[5][6]
bedrock:CallWithBearerToken
bedrock-mantle:CallWithBearerToken
短期APIキーは、既存のAWS認証情報を使って署名済みトークンをローカルで組み立てます。そのため、IAMには「短期APIキーの生成操作だけ」を拒否する専用アクションがありません。今回の検証では、生成元のIAMロールでBearer認証の利用を拒否します。[6:1][7]

 検証構成

短期APIキーアーキテクチャ図 ※今回はAWS マネジメントコンソールでのAPIキー発行しません


長期APIキーアーキテクチャ図
長期APIキーの作成拒否と短期APIキーの利用拒否は、それぞれの検証用IAMロールへDenyを追加して確認します。作成済みの長期APIキーの利用拒否は、キーが関連付いた検証用IAMユーザーへDenyを追加して確認します。

 実行条件

項目
値


AWSリージョン
ap-northeast-1

AWS CLI
2.34.24

操作元
IAM Identity Centerが管理するAdministratorAccessロール

長期APIキー検証用ロール
<LONG_TERM_TEST_ROLE>

短期APIキー検証用ロール
<SHORT_TERM_TEST_ROLE>

Token Generator

@aws/bedrock-token-generator 1.1.0


長期APIキー用IAMユーザー
<LONG_TERM_TEST_USER>

モデル推論は検証対象にしていないため、InvokeModelなどの推論権限は付与していません。
また、今回確認したのは、上記の検証用IAMユーザーとIAMロールへIAMポリシーを付与した場合の結果です。アカウント内のすべてのIAMプリンシパルへ一括して適用した場合の動作は検証していません。

 検証
 1. 長期APIキーの作成を拒否する
 Deny適用前最初に、検証用IAMユーザー<LONG_TERM_TEST_USER>に関連付くAmazon Bedrock長期APIキーが0件であることを確認しました。
その後、検証用ロールから長期APIキーを1件作成し、すぐに削除しました。


タイミング
長期APIキー数


作成前
0

作成後
1

削除後
0

これにより、Denyを適用する前はiam:CreateServiceSpecificCredentialが成功することを確認しました。
長期APIキーの作成APIは秘密値を返します。検証では標準出力をCredential IDだけに絞り、終了時に一覧から削除しました。作成方法を示すためではなく、Deny適用前後を比較するための操作です。

 追加したDeny長期APIキーの作成を拒否するため、検証用ロールに次のStatementを追加しました。
{
  "Sid": "DenyCreatingBedrockLongTermApiKeys",
  "Effect": "Deny",
  "Action": "iam:CreateServiceSpecificCredential",
  "Resource": "*",
  "Condition": {
    "StringEquals": {
      "iam:ServiceSpecificCredentialServiceName": "bedrock.amazonaws.com"
    }
  }
}
Resourceを*にしたのは、このロールから任意のIAMユーザーに関連付けるAmazon Bedrock長期APIキーの作成を拒否するためです。
一方で、条件でbedrock.amazonaws.comに限定しているため、ほかのAWSサービスのService-specific credentialまで一律には拒否しません。

 Deny適用後ポリシーの反映後にロールを引き受け直し、同じ条件で長期APIキーの作成を試しました。
An error occurred (AccessDenied) when calling the
CreateServiceSpecificCredential operation:
... with an explicit deny in an identity-based policy
作成を試した後も、Amazon Bedrock向けの長期APIキーは0件のままでした。
IAM Policy Simulatorでも、サービス名によって以下のように判定が分かれました。


iam:ServiceSpecificCredentialServiceName
判定


bedrock.amazonaws.com
explicitDeny

codecommit.amazonaws.com
allowed

この結果から、DenyがCreateServiceSpecificCredential全体ではなく、Amazon Bedrock向けの作成要求に一致していることを確認できました。なお、CodeCommitについて確認したのはIAM Policy Simulatorの判定だけであり、Service-specific credentialの実作成は行っていません。

 SigV4認証への影響今回拒否したのは、長期APIキーを作成するIAM APIです。Amazon Bedrockへの通常のSigV4認証は対象にしていません。
同じ検証用ロールでListFoundationModelsを実行した結果は以下のとおりでした。


タイミング
取得件数


Deny適用前
64

Deny適用後
64

64件は検証時点であり、固定の値ではありません。ここで確認したのは、Deny適用前後の両方でSigV4認証によるモデル一覧取得に成功したことです。

 2. 作成済みの長期APIキーの利用を拒否するiam:CreateServiceSpecificCredentialを拒否しても、そのDenyだけでは作成済みの長期APIキーは無効になりません。そこで、作成拒否とは分けて、作成済みキーによるBearer認証を拒否できるか確認します。「Deny適用前後」は、LONG_TERM条件のBearer認証用Denyを適用する前後を指します。
LONG_TERM条件のDenyを適用する前に、有効期限1日の長期APIキーを検証用IAMユーザーへ関連付けました。さらに、そのIAMユーザーへ、モデル一覧取得とBearer認証に必要な次の4つのIAMアクションを許可するポリシーを付与しました。
bedrock:ListFoundationModels
bedrock:CallWithBearerToken
bedrock-mantle:ListModels
bedrock-mantle:CallWithBearerToken
AWS CLIの作成レスポンスは親プロセスがパイプで受け取り、キーの秘密値をターミナルには表示しませんでした。秘密値は環境変数やファイルにも保存せず、プロセスのメモリ内だけで保持しました。IAMポリシーとAPIキーの反映を待ってから、同じキーで2つのモデル一覧を取得しました。


エンドポイント
HTTPステータス
取得件数


Amazon Bedrock
200
64

Amazon Bedrock Mantle
200
41

次に、キーが関連付いたIAMユーザーへ、LONG_TERM条件のDenyを追加しました。[6:2]
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyBedrockLongTermBearer",
      "Effect": "Deny",
      "Action": "bedrock:CallWithBearerToken",
      "Resource": "*",
      "Condition": {
        "StringEquals": {
          "bedrock:bearerTokenType": "LONG_TERM"
        }
      }
    },
    {
      "Sid": "DenyMantleLongTermBearer",
      "Effect": "Deny",
      "Action": "bedrock-mantle:CallWithBearerToken",
      "Resource": "*",
      "Condition": {
        "StringEquals": {
          "bedrock-mantle:bearerTokenType": "LONG_TERM"
        }
      }
    }
  ]
}
2つのStatementに分けているのは、Amazon BedrockとAmazon Bedrock MantleでIAMアクションと条件キーが異なるためです。1つのStatementに両方の条件キーを入れるとAND評価になりますが、各エンドポイントのリクエストには対応する片方の条件キーしかないため、Denyが一致しません。[8]
このJSONをdeny-long-term-bearer.jsonとして保存し、AWS CLIで関連IAMユーザーへ追加しました。
aws iam put-user-policy \
  --user-name '<LONG_TERM_TEST_USER>' \
  --policy-name DenyBedrockLongTermBearer \
  --policy-document file://deny-long-term-bearer.json
Deny適用前に作成したキーを再作成せず、そのまま再試行しました。


エンドポイント
Deny適用前
Deny適用後
エラー種別


Amazon Bedrock
200
403
AccessDeniedException

Amazon Bedrock Mantle
200
401
access_denied

拒否を確認した時点でも、同じCredential IDのService-specific credentialはActiveで有効期限内でした。キーの無効化や期限切れではなく、関連IAMユーザーのLONG_TERM条件に一致したBearer認証が拒否された結果です。
IAM Policy Simulatorでも、長期APIキーの場合だけDenyに一致しました。


IAMアクション
APIキー種別
判定


bedrock:CallWithBearerToken
LONG_TERM
explicitDeny

bedrock:CallWithBearerToken
SHORT_TERM
allowed

bedrock-mantle:CallWithBearerToken
LONG_TERM
explicitDeny

bedrock-mantle:CallWithBearerToken
SHORT_TERM
allowed

例えば、Amazon Bedrock側のLONG_TERM判定は以下のCLIで確認できます。Amazon Bedrock Mantle側はIAMアクションと条件キーをbedrock-mantleへ置き換えます。
aws iam simulate-principal-policy \
  --policy-source-arn 'arn:aws:iam::<ACCOUNT_ID>:user/<LONG_TERM_TEST_USER>' \
  --action-names bedrock:CallWithBearerToken \
  --resource-arns '*' \
  --context-entries \
    'ContextKeyName=bedrock:bearerTokenType,ContextKeyValues=LONG_TERM,ContextKeyType=string'
検証後は次のCLIでキーをInactiveにしてから削除しました。
aws iam update-service-specific-credential \
  --user-name '<LONG_TERM_TEST_USER>' \
  --service-specific-credential-id '<CREDENTIAL_ID>' \
  --status Inactive

aws iam delete-service-specific-credential \
  --user-name '<LONG_TERM_TEST_USER>' \
  --service-specific-credential-id '<CREDENTIAL_ID>'
Amazon Bedrock向けのService-specific credentialが0件になったことを確認しました。

 3. 短期APIキーの利用を拒否する
 Deny適用前短期APIキー用には、15分間だけ引き受ける別の一時ロールを作成しました。
このロールには、モデル一覧の取得とBearer認証に必要な次の4つのIAMアクションだけを許可しました。
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AllowBedrockModelListingsWithBearer",
      "Effect": "Allow",
      "Action": [
        "bedrock:ListFoundationModels",
        "bedrock:CallWithBearerToken",
        "bedrock-mantle:ListModels",
        "bedrock-mantle:CallWithBearerToken"
      ],
      "Resource": "*"
    }
  ]
}
このロールのAWS STS一時認証情報から、AWS公式のToken Generatorを使って有効期間5分の短期APIキーを生成しました。
Token Generatorは、AWSの「キー生成API」を呼び出すのではなく、SigV4で署名した情報からトークン文字列をローカルで組み立てます。トークンはプロセスのメモリ内だけで扱い、標準出力、環境変数、ファイルには保存しませんでした。[7:1]
生成した短期APIキーをAuthorization: Bearerヘッダーに指定し、以下の2つのエンドポイントを呼び出しました。[5:1]
https://bedrock.ap-northeast-1.amazonaws.com/foundation-models
https://bedrock-mantle.ap-northeast-1.api.aws/v1/models
Deny適用前は、両方のモデル一覧を取得できました。
{
  "tokenGenerated": true,
  "bedrock": {
    "httpStatus": 200,
    "count": 64
  },
  "mantle": {
    "httpStatus": 200,
    "count": 41
  }
}

 追加したDeny同じ短期APIキー検証用ロールに、SHORT_TERM条件のDenyを追加しました。
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyBedrockShortTermBearer",
      "Effect": "Deny",
      "Action": "bedrock:CallWithBearerToken",
      "Resource": "*",
      "Condition": {
        "StringEquals": {
          "bedrock:bearerTokenType": "SHORT_TERM"
        }
      }
    },
    {
      "Sid": "DenyMantleShortTermBearer",
      "Effect": "Deny",
      "Action": "bedrock-mantle:CallWithBearerToken",
      "Resource": "*",
      "Condition": {
        "StringEquals": {
          "bedrock-mantle:bearerTokenType": "SHORT_TERM"
        }
      }
    }
  ]
}
2つのStatementに分けているのは、Amazon BedrockとAmazon Bedrock MantleでIAMアクションと条件キーが異なるためです。
IAM Policy Simulatorでは、SHORT_TERMのときだけexplicitDenyになり、LONG_TERMはallowedでした。長期APIキーによる実アクセスは、前の関連IAMユーザーへLONG_TERM条件のDenyを追加して確認しています。

 生成済みの同じ短期APIキーを再利用するDeny適用前に生成した短期APIキーをプロセスのメモリに保持し、ポリシー更新後も同じキーで再試行しました。
IAMポリシーの変更は即時にすべての箇所へ反映されるとは限りません。[9]この検証では、Deny追加直後には成功と拒否が混在しましたが、約1分後には次の状態が連続しました。
Amazon Bedrock：HTTP 403
Amazon Bedrock Mantle：HTTP 401
どちらもモデル一覧を取得できませんでした。
ここで重要なのは401と403の違いではなく、次の証跡がそろっていることです。
同じ短期APIキーが有効期限内だった
生成元のSTSセッションも有効期限内だった
モデル一覧を取得できなくなった
IAM Policy SimulatorがexplicitDenyだった
CloudTrailにも権限拒否が記録された
HTTPステータスはエンドポイントごとの実測結果であり、常に同じ値になることを保証するものではありません。

 Deny適用後に新しい短期APIキーを生成するDeny適用後、新しいロールセッションからToken Generatorを実行しました。
短期APIキーの文字列自体は生成できました。しかし、そのキーでモデル一覧を呼び出すと拒否されました。
{
  "tokenGenerated": true,
  "bedrock": {
    "httpStatus": 403,
    "errorType": "AccessDeniedException"
  },
  "mantle": {
    "httpStatus": 401
  }
}
この結果は、短期APIキーについて「生成操作だけを止める」のではなく、「生成されたキーを利用できないようにする」というIAMの制御モデルと一致します。

 4. 同じAWS STS一時認証情報によるSigV4認証を確認するDeny適用後に短期APIキーを生成したものと同じAWS STS一時認証情報を使い、SigV4認証でAmazon BedrockのListFoundationModelsを呼び出しました。
結果は成功し、64件を取得できました。この結果から、今回のDenyはListFoundationModelsそのものやロールセッション全体を拒否したのではなく、SHORT_TERMのBearer認証だけに一致したと判断できます。
なお、SigV4認証で確認したのはAmazon BedrockのListFoundationModelsだけです。Amazon Bedrock Mantleや、ほかのAmazon Bedrock APIについては検証していません。

 CloudTrailで実行結果を確認するIAMのイベントはグローバルサービスの記録先であるバージニア北部リージョン、Amazon BedrockとAmazon Bedrock Mantleのモデル一覧イベントは東京リージョンのEvent historyで確認しました。[10][11][12]
たとえば、Amazon Bedrock MantleのListModelsは以下のCLIで検索しました。
aws cloudtrail lookup-events \
  --region ap-northeast-1 \
  --lookup-attributes AttributeKey=EventName,AttributeValue=ListModels \
  --start-time '<START_TIME>'


リージョン
Event
認証方法
結果


us-east-1
CreateServiceSpecificCredential
SigV4
成功

us-east-1
UpdateServiceSpecificCredential
SigV4
成功

us-east-1
DeleteServiceSpecificCredential
SigV4
成功

us-east-1
CreateServiceSpecificCredential
SigV4
AccessDenied

ap-northeast-1
ListFoundationModels
長期APIキー
成功

ap-northeast-1
ListModels
長期APIキー
成功

ap-northeast-1
ListFoundationModels
Deny適用後の長期APIキー
AccessDenied

ap-northeast-1
ListModels
Deny適用後の長期APIキー
permission_denied_error

ap-northeast-1
ListFoundationModels
短期APIキー
成功

ap-northeast-1
ListModels
短期APIキー
成功

ap-northeast-1
ListFoundationModels
Deny適用後の短期APIキー
AccessDenied

ap-northeast-1
ListModels
Deny適用後の短期APIキー
permission_denied_error

ap-northeast-1
ListFoundationModels
SigV4
成功

Token Generatorによるトークンの組み立てはローカル処理なので、それ自体に対応するAWS API呼び出しやCloudTrailイベントはありません。生成元のAWS STS一時認証情報を取得するAssumeRoleは、別のイベントとして記録されます。
長期APIキーによるListModelsでは、成功と拒否のどちらにもcallWithBearerToken=trueとbearerTokenType=LONG_TERMが記録されました。ListFoundationModelsの成功イベントでもcallWithBearerToken=trueを確認しています。
APIキーはAuthorizationヘッダーで送信されますが、CloudTrailにはAPIキーの値は記録されません。[3:1]
今回のCreateServiceSpecificCredentialイベントでも、レスポンスに秘密値が含まれていないことを確認しました。

 検証結果の整理Deny適用前後の比較結果をまとめると、次のようになりました。


確認項目
結果
Denyの適用先
IAMアクションまたは条件


長期APIキーの新規作成
拒否できた
作成APIを呼ぶIAMユーザーまたはIAMロール

iam:CreateServiceSpecificCredentialとサービス名条件

作成済み長期APIキーの利用
拒否できた
キーが関連付いたIAMユーザー
2つのCallWithBearerTokenとLONG_TERM条件

短期APIキーの文字列生成
生成できた
該当なし
生成だけを拒否する専用アクションなし

短期APIキーの利用
拒否できた
生成元のIAMユーザーまたはIAMロール
2つのCallWithBearerTokenとSHORT_TERM条件

同じAWS STS一時認証情報によるSigV4

ListFoundationModelsは成功した
短期APIキー検証用ロール
Bearer認証用Denyの対象外

今回の検証では、長期APIキーの作成、長期APIキーの利用、短期APIキーの利用を、それぞれ別のIAMポリシー条件で制御できました。一方、短期APIキーはDeny適用後もトークン文字列を生成できたため、生成ではなくBearer認証の利用を制御する必要があります。

 検証結果から考える制御のユースケース
 長期APIキーの新規発行を防ぐ長期間利用できる認証情報を新しく発行させたくない場合は、長期APIキーを作成するIAMユーザーまたはIAMロールでiam:CreateServiceSpecificCredentialを拒否します。
iam:ServiceSpecificCredentialServiceName条件キーをbedrock.amazonaws.comに限定すれば、Amazon Bedrock向けの長期APIキー作成だけを対象にできます。
ただし、この制御で止められるのは新しいキーの作成です。すでに存在する長期APIキーは自動的には無効になりません。

 既存の長期APIキーを段階的に停止する既存システムを長期APIキーからSigV4認証などへ移行する場合は、キーが関連付いたIAMユーザーでLONG_TERM条件のBearer認証を拒否する方法が考えられます。
この方法では、キーをActiveのまま利用だけ拒否できるため、移行時の影響を確認しながら認証経路を切り替える用途に使えます。
一方で、キーの漏えいが疑われる場合は、IAMポリシーによる拒否だけでなく、長期APIキーを無効化または削除する必要があります。[13]

 APIキーを拒否してSigV4認証へ統一するIAMロールやAWS STS一時認証情報を利用できるシステムでは、APIキーによるBearer認証を拒否し、SigV4認証へ統一する運用が考えられます。
今回の検証では、短期APIキーに対するSHORT_TERM条件のDenyを追加した後も、同じAWS STS一時認証情報を使ったSigV4認証で、Amazon BedrockのListFoundationModelsを実行できました。
この制御により、生成元のロールセッション全体を停止するのではなく、APIキーを使った認証経路だけを制限できます。ただし、本稿でSigV4認証を確認したのはListFoundationModelsだけです。ほかのAPIについては、必要なIAMアクションと実際の動作を個別に確認する必要があります。

 Amazon BedrockとAmazon Bedrock Mantleの両方を制限するAmazon BedrockとAmazon Bedrock Mantleでは、APIキーの利用を制御するIAMアクションが異なります。
片方だけを拒否すると、もう片方のエンドポイントを利用できる可能性があります。APIキーによるアクセスを両方のエンドポイントで拒否する場合は、次の2つを対象にします。
bedrock:CallWithBearerToken
bedrock-mantle:CallWithBearerToken
長期APIキーと短期APIキーを区別する場合は、それぞれLONG_TERMまたはSHORT_TERMの条件を指定します。

 最後にAmazon Bedrockの長期APIキーの作成と、作成済みの長期APIキーおよび短期APIキーによるBearer認証を、IAMユーザーやIAMロールに付与するアイデンティティベースのポリシーで制限できるか試してみました。長期APIキーは、iam:CreateServiceSpecificCredentialとサービス名の条件を使うことで、Amazon Bedrock向けの新規作成だけを拒否できました。また、作成済みの長期APIキーについても、キーが関連付いたIAMユーザーでLONG_TERMのBearer認証を拒否すると、キーをActiveのままAmazon BedrockとAmazon Bedrock Mantleのモデル一覧取得を止められました。短期APIキーはDeny適用後もトークン文字列自体を生成できましたが、生成元のIAMロールでSHORT_TERMのBearer認証を拒否すると、両方のモデル一覧APIを利用できなくなりました。一方で、同じAWS STS一時認証情報を使ったSigV4認証では、Amazon BedrockのListFoundationModelsを引き続き実行できました。今回確認したのは、特定のIAMユーザーとIAMロールに対するモデル一覧取得の制御であり、モデル推論やアカウント内のすべてのIAMプリンシパルへの適用までは検証していません。それでも、Amazon BedrockとAmazon Bedrock MantleのそれぞれでBearer認証を制御し、SigV4認証を残したままAPIキーによるアクセスだけを拒否できることを、実際のAPI呼び出しとCloudTrailから確認できました。

脚注
Service-specific credentials for IAM users ↩︎
IAM and AWS STS condition context keys ↩︎
Amazon Bedrock API keys ↩︎ ↩︎
Amazon Bedrock Mantle ↩︎
Use an Amazon Bedrock API key ↩︎ ↩︎
Control permissions for generating and using Amazon Bedrock API keys ↩︎ ↩︎ ↩︎
AWS Bedrock Token Generator for JavaScript/TypeScript ↩︎ ↩︎
Conditions with multiple context keys or values ↩︎
Changes that I make are not always immediately visible ↩︎
CloudTrail concepts: global service events ↩︎
Monitor Amazon Bedrock API calls using CloudTrail ↩︎
Monitor bedrock-mantle API calls using CloudTrail ↩︎
Handle compromised long-term and short-term Amazon Bedrock API keys ↩︎

項目	長期APIキー	短期APIキー
基になるIAM主体	IAMユーザー	既存のIAMユーザーまたはロールセッション
有効期間	設定した有効期限まで	最長12時間、または生成元セッションの残存時間の短い方
AWSの位置付け	探索用途のみ	本番利用で推奨
新規作成を制御する方法	`iam:CreateServiceSpecificCredential`	生成専用の拒否アクションなし
利用を制御する方法	関連IAMユーザーでBearer認証を制御	生成元プリンシパルでBearer認証を制御

項目	値
AWSリージョン	`ap-northeast-1`
AWS CLI	`2.34.24`
操作元	IAM Identity Centerが管理するAdministratorAccessロール
長期APIキー検証用ロール	`<LONG_TERM_TEST_ROLE>`
短期APIキー検証用ロール	`<SHORT_TERM_TEST_ROLE>`
Token Generator	`@aws/bedrock-token-generator` `1.1.0`
長期APIキー用IAMユーザー	`<LONG_TERM_TEST_USER>`

タイミング	長期APIキー数
作成前	0
作成後	1
削除後	0

`iam:ServiceSpecificCredentialServiceName`	判定
`bedrock.amazonaws.com`	`explicitDeny`
`codecommit.amazonaws.com`	`allowed`

タイミング	取得件数
Deny適用前	64
Deny適用後	64

エンドポイント	HTTPステータス	取得件数
Amazon Bedrock	200	64
Amazon Bedrock Mantle	200	41

エンドポイント	Deny適用前	Deny適用後	エラー種別
Amazon Bedrock	200	403	`AccessDeniedException`
Amazon Bedrock Mantle	200	401	`access_denied`

IAMアクション	APIキー種別	判定
`bedrock:CallWithBearerToken`	`LONG_TERM`	`explicitDeny`
`bedrock:CallWithBearerToken`	`SHORT_TERM`	`allowed`
`bedrock-mantle:CallWithBearerToken`	`LONG_TERM`	`explicitDeny`
`bedrock-mantle:CallWithBearerToken`	`SHORT_TERM`	`allowed`

リージョン	Event	認証方法	結果
`us-east-1`	`CreateServiceSpecificCredential`	SigV4	成功
`us-east-1`	`UpdateServiceSpecificCredential`	SigV4	成功
`us-east-1`	`DeleteServiceSpecificCredential`	SigV4	成功
`us-east-1`	`CreateServiceSpecificCredential`	SigV4	`AccessDenied`
`ap-northeast-1`	`ListFoundationModels`	長期APIキー	成功
`ap-northeast-1`	`ListModels`	長期APIキー	成功
`ap-northeast-1`	`ListFoundationModels`	Deny適用後の長期APIキー	`AccessDenied`
`ap-northeast-1`	`ListModels`	Deny適用後の長期APIキー	`permission_denied_error`
`ap-northeast-1`	`ListFoundationModels`	短期APIキー	成功
`ap-northeast-1`	`ListModels`	短期APIキー	成功
`ap-northeast-1`	`ListFoundationModels`	Deny適用後の短期APIキー	`AccessDenied`
`ap-northeast-1`	`ListModels`	Deny適用後の短期APIキー	`permission_denied_error`
`ap-northeast-1`	`ListFoundationModels`	SigV4	成功

確認項目	結果	Denyの適用先	IAMアクションまたは条件
長期APIキーの新規作成	拒否できた	作成APIを呼ぶIAMユーザーまたはIAMロール	`iam:CreateServiceSpecificCredential`とサービス名条件
作成済み長期APIキーの利用	拒否できた	キーが関連付いたIAMユーザー	2つの`CallWithBearerToken`と`LONG_TERM`条件
短期APIキーの文字列生成	生成できた	該当なし	生成だけを拒否する専用アクションなし
短期APIキーの利用	拒否できた	生成元のIAMユーザーまたはIAMロール	2つの`CallWithBearerToken`と`SHORT_TERM`条件
同じAWS STS一時認証情報によるSigV4	`ListFoundationModels`は成功した	短期APIキー検証用ロール	Bearer認証用Denyの対象外

Fusic 技術ブログPublication

さまざまな個性を受け入れて有機的につなぐ社内環境を整える。あらゆる事業機会の創出と実現を繰り返し、世の中に対する視点を絶えず増やして成長していく。あっと驚くような角度から発展できるポイントを見つけ、そこにいい感じにフィットする形でテクノロジーを組み込んで、世の中をちょっとずつ、時には大胆にアップデートしつづけていく。

はじめに

検証の前提

長期APIキーと短期APIキー

対象とするエンドポイント

検証構成

実行条件

検証

1. 長期APIキーの作成を拒否する

Deny適用前

追加したDeny

Deny適用後

SigV4認証への影響

2. 作成済みの長期APIキーの利用を拒否する

3. 短期APIキーの利用を拒否する

Deny適用前

追加したDeny

生成済みの同じ短期APIキーを再利用する

Deny適用後に新しい短期APIキーを生成する

4. 同じAWS STS一時認証情報によるSigV4認証を確認する

CloudTrailで実行結果を確認する

検証結果の整理

検証結果から考える制御のユースケース

長期APIキーの新規発行を防ぐ

既存の長期APIキーを段階的に停止する

APIキーを拒否してSigV4認証へ統一する

Amazon BedrockとAmazon Bedrock Mantleの両方を制限する

最後に

Discussion