TL Terralien
Security, Identity, and Compliance

AWS KMS

モデルカスタマイズ成果物・Knowledge Base・エージェントをカスタマーマネージドキーで暗号化する仕組み。試験ではキーポリシーとBedrockサービスロールの権限をどう分けるかが問われます。

  • B｜実装まわり
  • D3 安全性・セキュリティ・ガバナンス

最終更新: 2026年8月18日

ひとことで言うと

暗号鍵そのものを外に出さずに管理するサービスです。Bedrockでは既定でAWS所有キーによる暗号化がかかっており、カスタマーマネージドキー（CMK）はオプトインの上乗せという位置づけです。

要するに、貸金庫の鍵を自分では持たない金庫室です。KMSキーは金庫室から一度も出ません。Bedrockが暗号化・復号したいときは、金庫室に「この操作をしてほしい」と頼み（kms:Decrypt等のAPI呼び出し）、金庫室側がキーポリシーで許可された相手かどうかを毎回確認してから応じます。鍵自体を貸し出すことはありません。

なぜ生まれたか

CMKが無いと（AWS所有キーのみ）CMKで変わること
暗号鍵の管理・ローテーションはAWS任せで、利用者側は制御・監査ができない鍵ポリシーで誰が鍵を使えるかを利用者側が明示的に制御
鍵単位でのアクセス監査ができないCloudTrail・CloudWatch Logsで鍵へのAPI呼び出しを個別に追跡
コンプライアンス要件で「顧客管理の鍵」を求められると満たせない鍵の作成・無効化・削除を利用者側で運用

Bedrockのモデルカスタマイズ・Knowledge Base・エージェントは、いずれも既定でAWS所有キーによる暗号化がかかっています。CMKは「それで足りない場合に足す」ものであって、CMKを使わないと暗号化されない、という設計ではありません。

何に使うか

対象CMKで何を暗号化するか関連ドメイン
Knowledge Baseデータ取り込み中の一時データ・永続データ・S3上のデータソースD1・D3
エージェントガードレールを紐づける場合はガードレール側のCMKも別途D1・D3
サードパーティのベクトルストア連携Secrets Managerに保存した接続情報の暗号化D1・D3
Bedrock Data Automation（マルチモーダル処理）音声・動画・画像ファイルの暗号化にCMKを利用可能D1・D3

試験でどう問われるか

問われ方正解に寄る条件引っかけの選択肢
Knowledge Baseを顧客管理のキーで暗号化したいが、既定では何もしなくても暗号化されているAWS所有キーが既定 → CMKは任意で上乗せする設計だと理解しているかCMKを設定しないと暗号化されないと誤解する
CMKでKnowledge Baseを暗号化したのに、サービスロールが動かないサービスロール（Bedrockがデータを読み書きする側）にはキーポリシー上の権限は不要。権限が要るのはナレッジベースを作成する側のIAMエンティティサービスロールにもキーポリシーで許可を追加しようとする
ガードレールをCMKで暗号化し、それをエージェントに紐づけて使いたいエージェントの実行ロールにガードレール用CMKの復号権限を個別に追加する必要があるガードレールを紐づければ暗号化キーの権限も自動で通ると考える
KMSキーの利用を、S3経由の呼び出しだけに限定したいキーポリシーの条件キー kms:ViaService で s3.<region>.amazonaws.com を指定IAMポリシー側だけで制御しようとする

Bedrockのサービスロール（Knowledge Baseやエージェントがデータを読み書きするためのロール）自体には、鍵を作成・付与するための権限は不要です。キーポリシー側で許可が要るのは「ナレッジベースを作成するIAMエンティティ」であり、ここを混同すると権限設計を誤ります。

実務でどう使うか

  • CMKでKnowledge Baseを暗号化すると、BedrockはグラントAPI（kms:CreateGrant）で一時的な使用権を得て、ナレッジベース削除時にそのグラントを解除します。 鍵そのものの削除とは別の仕組みです
  • Secrets Manager経由の第三者ベクトルストア接続情報を暗号化する場合、キーポリシーの条件は kms:ViaService を secretsmanager.<region>.amazonaws.com に向けます。 S3データソース用の条件（s3.<region>.amazonaws.com）とは別に用意する必要があります
  • CloudTrailの CreateGrant イベントで、Bedrockが実際にどのキーにいつグラントを作成したかを追跡できます。 監査要件で「誰がいつ暗号鍵にアクセスしたか」を問われた場合の裏付けになります

CMKを使うかどうかは「暗号化するかどうか」の選択ではありません。既定のAWS所有キーによる暗号化は常にかかっており、CMKは監査・制御を利用者側に持たせたい場合のオプトインです。

取り違えやすいもの

迷う相手切り分けの一言
Secrets ManagerKMSは鍵の保管・暗号化操作そのもの。Secrets Managerは秘匿値（パスワード・APIキー）の保管とローテーション。Secrets Manager自体の中身も既定でKMSにより暗号化される、という親子関係
AWS Encryption SDKKMSはAWS内のリソース暗号化に使う鍵管理サービス。Encryption SDKはクライアント側でデータを暗号化してからAWSに送るためのライブラリ
IAMIAMは「誰が何をできるか」全般。KMSキーポリシーはその中でも鍵の使用権限だけを扱う、リソースベースポリシーの一種

想起チェック

Q1. Knowledge BaseをCMKで暗号化した場合、暗号化・復号の権限が必要なのはどちら側？

ナレッジベースを作成するIAMエンティティ（ロール・ユーザー）側です。Bedrockのサービスロール（データを読み書きする側）自体にはキーポリシー上の権限は不要です。

Q2. Bedrockが既定でCMKを使わなくても、Knowledge Baseやエージェントのデータは暗号化されていない？

されています。既定でAWS所有キーによる暗号化がかかっており、CMKは監査・制御を利用者側に持たせたい場合に追加するオプションです。

出典（AWS公式）