Amazon Web Services ブログ
Amazon Bedrock における最小権限アクセスの実装
本ブログは 2025 年 2 月 11 日に公開された AWS Blog “Implementing least privilege access for Amazon Bedrock” を翻訳したものです。
2025 年 11 月 24 日: 条件ステートメントのロジックに対するサービスコントロールポリシー (SCP) のサポートが更新されたことに合わせて、モデルへのアクセスを制限するアプローチに関する内容を更新しました。
2025 年 4 月 9 日: Amazon Bedrock Guardrails に関する内容を更新し、最近追加された条件キー
bedrock:GuardrailIdentifierについて説明を追加しました。
2025 年 3 月 27 日: この記事の 2 つのポリシーを更新しました。
生成 AI アプリケーションでは、コンテンツを生成したり、機密情報となり得るデータにアクセスしたりするために、Amazon Bedrock や大規模言語モデル (LLM) など、さまざまなサービスや機能を組み合わせることがよくあります。このような組み合わせには、強力なアイデンティティとアクセス管理のコントロールが必要です。また、これらのコントロールをさまざまなレベルで適用する必要がある点が、この組み合わせの特徴です。このブログ記事では、Amazon Bedrock を使用するアプリケーションに最小権限のアクセスを適用できるシナリオとアプローチを紹介します。この記事のガイダンスを十分に活用するには、AWS API、AWS Identity and Access Management (IAM) ポリシー、AWS のセキュリティサービスについての理解が必要です。
まず、最小権限の原則を定義しましょう。最小権限の原則とは、ユーザー、プログラム、システムがタスクを実行するために必要な最小限のアクセス (アクセス許可) のみを付与することを推奨するセキュリティの概念です。基本的な考え方は、エンティティが持つアクセス許可が少ないほど、悪意のある行為や偶発的な事象による損害のリスクが低くなるというものです。この原則を AWS の利用に適用することには、2 つの目的があります。
- セキュリティ: アクセスを制限することで、セキュリティインシデントの潜在的な影響を軽減できます。ユーザーやサービスのアクセス許可が最小限であれば、損害が及ぶ範囲を大幅に縮小できます。
- 運用のシンプルさ: アクセス許可の管理は、適切な運用と保守を行わないと複雑になる可能性があります。アクセスコントロールに最小権限の原則を早い段階で適用することで、構成をできるだけ管理しやすい状態に保てます。さらに、ロール間の職務の分離と、アクセスコントロールに関する文書化された戦略を求める規制フレームワークもあります。これらの要件は、最小権限の原則を順守することで部分的に満たすことができます。
Amazon Bedrock は、単一の統合 API を通じて高性能な基盤モデル (FM) を利用できるフルマネージド型の AWS サービスです。Amazon Bedrock は AWS API を通じて使用します。AWS API では、推論などのデータプレーンの機能に関するアクションに加えて、Amazon Bedrock Guardrails や Amazon Bedrock Agents の設定など、コントロールプレーンと管理のためのアクションが提供されています。
一般的に、本番ワークロードで Amazon Bedrock を使用するまでには、次の段階を経ます。
- モデルの選択: 必要な機能 (検索拡張生成 (RAG)、ファインチューニングなど) を決定し、モデルを評価して選択します。必要に応じて EULA を承認します。
- モデルの適応: プロンプトエンジニアリング、アプリケーションへの Amazon Bedrock の統合、必要に応じたモデルのカスタマイズを行います。
- モデルのテスト: ソリューションを検証し、テストします。
- モデルの運用: ソリューションをデプロイして利用可能にし、モニタリングと運用を行います。
以降のセクションでは、各フェーズを順に取り上げ、最小権限の原則を適用する方法の概要を説明します。
モデルの選択
このフェーズでは、要件を満たすために必要な機能とモデルを選択し、最小権限の原則をどのように適用するかを定義します。対象となる機能には、例えばモデルのカスタマイズ、RAG、エージェントの使用などがあります。
定義したコントロールを開発フェーズで実装できるように、セキュリティを設計に組み込む必要があります。必要なセキュリティコントロールを定義するアプローチの 1 つが脅威モデリングです。この作業をプロセスの早い段階で行っておくと、その後のフェーズを進めやすくなります。その結果は、必要なガードレール、アーキテクチャの変更の要否、テストケースを後で決める際に活用できます。
このフェーズでは、ソリューションのデプロイ方法も決定します。お客様は通常、マルチアカウント構成で運用しているため、対象となる組織単位 (OU) とアカウントを選択する必要があります。生成 AI アプリケーション用に新しい OU を作成することをお勧めします。詳細については、AWS Security Reference Architecture の生成 AI に関する詳細な章を参照してください。サービスコントロールポリシー (SCP) と、SCP を使用してアクセス許可を制限する方法については後ほど説明します。生成 AI 用の OU は、こうしたガードレールを適用するのに適した場所です。
Amazon Bedrock では、AI21 Labs、Anthropic、Cohere、Meta、Mistral AI、Stability AI、Amazon などの主要な AI 企業が提供する、さまざまな高性能 FM を利用できます。この段階では、使用するモデルを選択して承認する必要があります。AWS Organizations の SCP が IAM ポリシー言語を完全にサポートするようになったため、SCP を使用して許可リスト方式でモデルへのアクセスを制限できます。以下は、アカウントのオペレーターが直接呼び出しで Anthropic と Amazon の FM のみを使用できるようにする SCP の例です。ワイルドカード文字のアスタリスク (*) を別の位置で使用すれば、モデルファミリーやモデルバージョン単位でも同様の制限を適用できます。
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "DenyAllExceptAnthropicAndAmazonFMs",
"Effect": "Deny",
"Action": [
"bedrock:InvokeModel",
"bedrock:InvokeModelWithResponseStream"
],
"NotResource": [
"arn:aws:bedrock:*::foundation-model/amazon.*",
"arn:aws:bedrock:*::foundation-model/anthropic.*"
]
}
]
}
サードパーティーの FM の場合、承認には EULA への同意が含まれることがあります。AWS は Amazon Bedrock のモデルアクセスを簡素化したため、このステップはバックグラウンドで自動的に行われます。それでも、法務部門がレビュー済みの EULA に準拠するために、アイデンティティと、各アイデンティティがサブスクライブできるモデルを制限することは可能です。以下は、アカウントのオペレーターがすべての Anthropic FM と 1 つの Meta Llama FM を有効にできるようにするアイデンティティベースのポリシーの例です。
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "AllowAcceptingModelEULAs",
"Effect": "Allow",
"Action": [
"aws-marketplace:Subscribe"
],
"Resource": "*",
"Condition": {
"Null": {
"aws-marketplace:ProductId": "false"
},
"ForAllValues:StringEquals": {
"aws-marketplace:ProductId": [
"c468b48a-84df-43a4-8c46-8870630108a7",
"b0eb9475-3a2c-43d1-94d3-56756fd43737",
"prod-6dw3qvchef7zy",
"prod-m5ilt4siql27k",
"prod-ozonys2hmmpeu",
"prod-fm3feywmwerog",
"prod-2c2yc2s3guhqy"
]
}
}
},
{
"Sid": "AllowUnsubscribingFromModels",
"Effect": "Allow",
"Action": [
"aws-marketplace:Unsubscribe",
"aws-marketplace:ViewSubscriptions"
],
"Resource": "*"
}
]
}このアプローチは、アクションを許可リストに登録するだけであれば有効です。ただし、高い権限を持つユーザーが AWS Marketplace API への広範なアクセス権を既に持っている場合もあります。そのような場合は、一部を除いてすべて拒否するアプローチを使用できます。前の例と同じモデルを対象とすると、ポリシーは次のようになります。
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "DenyAcceptingAllExceptCertainModelEULAs",
"Effect": "Deny",
"Action": [
"aws-marketplace:Subscribe"
],
"Resource": "*",
"Condition": {
"ForAnyValue:StringNotEquals": {
"aws-marketplace:ProductId": [
"c468b48a-84df-43a4-8c46-8870630108a7",
"b0eb9475-3a2c-43d1-94d3-56756fd43737",
"prod-6dw3qvchef7zy",
"prod-m5ilt4siql27k",
"prod-ozonys2hmmpeu",
"prod-fm3feywmwerog",
"prod-2c2yc2s3guhqy"
]
}
}
},
{
"Sid": "DenyUnsubscribingAllExceptCertainModels",
"Effect": "Deny",
"Action": [
"aws-marketplace:Unsubscribe",
"aws-marketplace:ViewSubscriptions"
],
"Resource": "*",
"Condition": {
"ForAnyValue:StringNotEquals": {
"aws-marketplace:ProductId": [
"c468b48a-84df-43a4-8c46-8870630108a7",
"b0eb9475-3a2c-43d1-94d3-56756fd43737",
"prod-6dw3qvchef7zy",
"prod-m5ilt4siql27k",
"prod-ozonys2hmmpeu",
"prod-fm3feywmwerog",
"prod-2c2yc2s3guhqy"
]
}
}
}
]
}条件で使用するプロダクト ID は、「Use product ID condition keys to control access」で確認できます。
モデルの適応
このフェーズでは、ソリューションを構築します。つまり、コードを記述します。作業の大部分は従来のソフトウェア開発と同じですが、プロンプトエンジニアリング、プロンプトのガードレール、モデルのモニタリング、エージェントの設計など、生成 AI に固有の領域もあります。この記事では、アイデンティティとアクセス管理の側面のみに焦点を当てます。
適応は、詳細なアクセス許可のセットを作成するフェーズです。データ境界は、ガードレールを定義および実装するための概念的なツールとして活用できます。データ境界は通常、粒度が粗いため、それだけでは最小権限の原則の目標を達成できません。ただし、きめ細かなポリシーと組み合わせることで、多層防御のアプローチを実現できます。データ境界には次のものがあります。
- アイデンティティ: 自社のネットワーク内で許可されるのは信頼できるアイデンティティのみであり、自社のリソースにアクセスできるのも信頼できるアイデンティティのみです。
- リソース: 自社のアイデンティティは信頼できるリソースにのみアクセスでき、自社のネットワークからアクセスできるのも信頼できるリソースのみです。
- ネットワーク: 自社のアイデンティティは想定されたネットワークからのみリソースにアクセスでき、自社のリソースには想定されたネットワークからのみアクセスできます。
Amazon Bedrock を使用するアプリケーションは、Amazon Virtual Private Cloud (Amazon VPC) を使用して、仮想プライベートクラウド (VPC) のネットワーク内でホストできます。これにより、AWS PrivateLink を使用して、データプレーン API とコントロールプレーン API の両方に対する VPC エンドポイントを作成できるようになります。PrivateLink でエンドポイントを作成すると、インターネットゲートウェイを使用せずに、VPC に接続されたコンピューティングリソース (Amazon Elastic Compute Cloud (Amazon EC2) や AWS Lambda など) から Amazon Bedrock にアクセスできます。つまり、これらのリソースをすべてプライベートサブネットにデプロイできます。さらに、これらのエンドポイントでリソースベースのポリシーを使用すれば、API コールに関するプリンシパル、アクション、リソース、条件を制限できます。
例として、VPC のプライベートサブネットで EC2 インスタンスが実行されており、そのインスタンスで Amazon Bedrock のモデル呼び出しを使用するアプリケーションをホストしているとします。また、Amazon Bedrock のデータプレーンに接続するためのインターフェイス VPC エンドポイントを作成済みであるとします。EC2 インスタンスは、<rolename> IAM ロールを使用するインスタンスプロファイルで設定されており、Amazon Bedrock の InvokeModel API コールを通じて、Anthropic の Claude Instant という 1 つの FM を呼び出せる必要があります。この場合、Amazon Bedrock のインターフェイス VPC エンドポイントにカスタムポリシーを設定することで、VPC、ひいてはその中の EC2 インスタンスに最小権限の原則を適用できます。次のポリシーをご自身のアカウントで使用するには、デフォルトのインターフェイス VPC エンドポイントポリシーを次の例に置き換えます。その際、<rolename> を許可するロールに、<account-id> を 12 桁のアカウント番号に置き換えてください。
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "AllowInvokingClaudeInstantV1Models",
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::<account-id>:role/<rolename>"
},
"Action": [
"bedrock:InvokeModel"
],
"Resource": "arn:aws:bedrock:*::foundation-model/anthropic.claude-instant-v1"
}
]
}このデータ境界のアプローチの詳細については、「Security Objective 2: Implement a data perimeter using VPC endpoint policies」を参照してください。
Amazon Bedrock で使用を許可するモデルは、ポリシー内で直接定義できます。ただし、Amazon Bedrock を使用するアプリケーションが複数ある場合は、新しいモデルの使用を許可するたびに複数のポリシーを更新しなければならないことがあります。そこで、データ境界のアプローチを補完するために、SCP を追加して推論に使用できるモデルを制限できます。Amazon Bedrock の推論はシンプルな API (InvokeModel と Converse) で行われるため、IAM ポリシーの条件要素を使用して、承認されていないモデルの使用を拒否できます。なお、2 つのポリシー (SCP と VPC エンドポイントポリシー) は似ていますが、動作が異なる点に注意してください。VPC エンドポイントポリシーは、PrivateLink を経由するネットワークパスが強制されている場合に適用されます。一方、SCP は、アタッチされているアカウントまたは OU 内のプリンシパルに適用されます。呼び出し元のアイデンティティがアカウントの外部にある場合は、VPC エンドポイントポリシーしか適用されないため、特に注意が必要です。
例えば、AWS Organizations の組織全体で、すべての AWS リージョンを対象に、すべての Anthropic FM の呼び出しをブロックしたいとします。次の SCP の例を対象の OU または AWS アカウントに適用すると、これを実現できます。
{
"Version": "2012-10-17",
"Statement": {
"Sid": "DenyInferenceForAnthropicModels",
"Effect": "Deny",
"Action": [
"bedrock:InvokeModel",
"bedrock:InvokeModelWithResponseStream"
],
"Resource": [
"arn:aws:bedrock:*::foundation-model/anthropic.*"
]
}
}同じパターンは、Amazon Simple Storage Service (Amazon S3) に保存されているデータなど、アプリケーションに必要なデータへのアクセスにも適用できます。
モデルのカスタマイズ
Amazon Bedrock 上に構築されたソリューションには、モデルのカスタマイズが含まれる場合があります。さまざまなカスタマイズのアプローチに共通しているのは、データを扱うという点です。このデータは機密性が高いと想定されるため、最小権限の原則の適用対象となります。ここでは、データが Amazon S3 に保存されており、カスタマーマネージドの AWS Key Management Service (AWS KMS) キーで暗号化できるシナリオを取り上げます。
データ境界の考え方と同様に、対策はネットワーク、アイデンティティ、リソースという複数のレベルで講じることができます。Amazon Bedrock のモデルのカスタマイズではサービスロールを使用するため、エンドツーエンドできめ細かな最小権限のアクセスを適用できます。Amazon Bedrock のサービスプリンシパルは、これらのサービスロールを引き受けて、お客様に代わってアクションを実行します。Amazon Bedrock のサービスプリンシパルがアカウント内のロールを引き受けられるようにするには、ロールに信頼ポリシーをアタッチする必要があります。
米国東部 (バージニア北部) リージョン (us-east-1) で Amazon Bedrock のカスタマイズジョブを実行しているとします。次の信頼ポリシーの例を使用すると、Amazon Bedrock のサービスプリンシパルのみがロールを引き受けられるようになります。
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "AllowBedrockServicePrincipalUnderConditions",
"Effect": "Allow",
"Principal": {
"Service": "bedrock.amazonaws.com"
},
"Action": "sts:AssumeRole",
"Condition": {
"StringEquals": {
"aws:SourceAccount": "<account-id>"
},
"ArnEquals": {
"aws:SourceArn": "arn:aws:bedrock:us-east-1:<account-id>:model-customization-job/*"
}
}
}
]
}前述の信頼ポリシーの例にある <account-id> は、必ずご自身の 12 桁のアカウント番号に置き換えてください。このポリシーでは、aws:SourceAccount 条件を追加することで、サービス間の混乱した代理問題を防止しています。混乱した代理問題とは、アクションを実行するアクセス許可を持たないエンティティが、より高い権限を持つエンティティにそのアクションを実行させることができてしまう状況のことです。AWS では、サービス間のなりすましによって混乱した代理問題が発生する可能性があります。サービス間のなりすましは、あるサービス (呼び出し元のサービス) が別のサービス (呼び出されるサービス) を呼び出すときに発生する可能性があります。AWS は、アカウント内のリソースへのアクセス権がサービスプリンシパルに付与されているすべてのサービスについて、データの保護に役立つツールを提供しています。ロールの信頼ポリシーで aws:SourceArn と aws:SourceAccount のグローバル条件コンテキストキーを使用すると、Amazon Bedrock が別のサービス (前述の例ではカスタマイズジョブ) に与えるリソースへのアクセス許可を制限できます。aws:SourceArn は、AWS アカウントだけでなく、ロールを引き受けるリクエストの具体的な送信元を定義するため、ここではより厳格な制限方法となります。
モデルのカスタマイズタスクの実行に必要なアクセス許可のみを付与する必要があります。例えば、トレーニングデータのバケット、検証データのバケット、出力バケット (Amazon Bedrock が出力メトリクスを配信する場所) へのアクセスに限定したいとします。同じサービスロールに次のポリシーをアタッチすると、それらのアクセス許可のみが付与されます。<training-bucket> プレースホルダーをトレーニングデータが含まれるバケット名に、<validation-bucket> を検証用のバケットに、<output-bucket> をメトリクスを保存するバケットに置き換えてください。
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "AllowAccessToTrainingAndValidationBucket",
"Effect": "Allow",
"Action": [
"s3:GetObject",
"s3:ListBucket"
],
"Resource": [
"arn:aws:s3:::<training-bucket>",
"arn:aws:s3:::<training-bucket>/*",
"arn:aws:s3:::<validation-bucket>",
"arn:aws:s3:::<validation-bucket>/*"
]
},
{
"Sid": "AllowAccessToOutputBucket",
"Effect": "Allow",
"Action": [
"s3:GetObject",
"s3:PutObject",
"s3:ListBucket"
],
"Resource": [
"arn:aws:s3:::<output-bucket>",
"arn:aws:s3:::<output-bucket>/*"
]
}
]
}このアプローチを補完するために、モデルのカスタマイズジョブで VPC を使用して、トレーニングデータへのアクセスを制限することをお勧めします。この場合、ネットワークはインターフェイス VPC エンドポイントを使用して S3 バケットにアクセスするため、技術的にはここでも VPC エンドポイントのリソースポリシーが関係します。これにより、別のネットワークコントロールとして、特定の VPC エンドポイント経由のアクセスのみを許可する S3 バケットポリシーを定義できます。カスタマイズジョブ自体のアクセスを制限したい場合は、次の例のようなバケットポリシーを適用します。その際、<training-bucket> をトレーニングデータが含まれるバケット名に、<vpce-id> を VPC 内にある VPC エンドポイントの ID に置き換えてください。
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "AccessToSpecificVPCEOnly",
"Effect": "Deny",
"Principal": "*",
"Action": "s3:*",
"Resource": [
"arn:aws:s3:::<training-bucket>",
"arn:aws:s3:::<training-bucket>/*"
],
"Condition": {
"StringNotEquals": {
"aws:SourceVpce": "<vpce-id>"
}
}
}
]
}さらに、VPC エンドポイントにアクセスできるプリンシパルと、それらのプリンシパルが Amazon S3 で実行できるアクションも制限します。この記事の前半にある Amazon Bedrock の呼び出しに関するセクションの例とほぼ同じであるため、簡潔さを優先してここではポリシーの例を省略します。
カスタマーマネージドの AWS KMS キーを使用した Amazon S3 での暗号化 (SSE-KMS) を強制する必要がある場合は、次の作業を行います。
- 暗号化されていないコンテンツのアップロードを拒否するステートメントをバケットポリシーに追加します。
- KMS キーポリシーを更新し、サービスロールがキーを使用した復号とキー情報の取得を行えるようにします。
次のポリシーの例は、バケットポリシーに追加するものです。暗号化されていないオブジェクトが S3 バケットに追加されるのを拒否する方法を示しています。ここでも、<training-bucket> をトレーニングデータが含まれる S3 バケットの名前に置き換えてください。
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "DenyObjectsThatAreNotSSEKMS",
"Effect": "Deny",
"Principal": "*",
"Action": "s3:PutObject",
"Resource": "arn:aws:s3:::<training-bucket>/*",
"Condition": {
"Null": {
"s3:x-amz-server-side-encryption-aws-kms-key-id": "true"
}
}
}
]
}最後に、Amazon Bedrock のサービスロールに KMS キーへのアクセスを許可するために、KMS キーポリシーに次のようなステートメントを追加する必要があります。<account-id> を 12 桁のアカウント番号に、<bedrock-service-role> を作成したロール (Amazon Bedrock のサービスプリンシパルが引き受けるロール) に置き換えてください。IAM ロールには、KMS キーでデータを復号するために必要なアクセス権のみを付与してください。
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "AllowUseOfKeyByBedrockRole",
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::<account-id>:role/<bedrock-service-role>"
},
"Action": [
"kms:Decrypt",
"kms:DescribeKey"
],
"Resource": "*"
}
]
}Amazon Bedrock は、カスタマイズされたモデルをカスタマーマネージドの KMS キーで暗号化することもできます。Amazon Bedrock は KMS キーグラントを使用して、カスタマイズされたモデルを暗号化し、後で推論用にデプロイする際に復号します。そのため、KMS キーポリシーで、同じ IAM ロールに KMS キーグラントを作成するアクセス許可を付与する必要があります。この目的で使用する KMS キーは、両方のキーにきめ細かなアクセス許可を設定できるように、通常はトレーニングデータの暗号化に使用したキーとは別のものにします。
ここでは、カスタマイズされたモデルの暗号化と復号に、2 つの異なるロールを使用するとします。モデルのカスタマイズジョブを実行するロールが KMS キーを使用できるようにするには、次のポリシーステートメントを KMS キーポリシーに追加します。その際、<account-id> を 12 桁のアカウント番号に、<region> を Amazon Bedrock を実行するリージョンに、<bedrock-model-customization-role> をモデルのカスタマイズジョブの実行に使用するロール名に、<invocation-role> を推論に使用するロール名に置き換えてください。
{
"Version": "2012-10-17",
"Id": "PermissionsCustomModelKey",
"Statement": [
{
"Sid": "PermissionsEncryptCustomModel",
"Effect": "Allow",
"Principal": {
"AWS": [
"arn:aws:iam::<account-id>:role/<bedrock-model-customization-role>"
]
},
"Action": [
"kms:Decrypt",
"kms:GenerateDataKey",
"kms:DescribeKey",
"kms:CreateGrant"
],
"Resource": "*",
"Condition": {
"StringLike": {
"kms:ViaService": [
"bedrock.<region>.amazonaws.com"
]
}
}
},
{
"Sid": "PermissionsDecryptModel",
"Effect": "Allow",
"Principal": {
"AWS": [
"arn:aws:iam::<account-id>:role/<invocation-role>"
]
},
"Action": [
"kms:Decrypt"
],
"Resource": "*",
"Condition": {
"StringLike": {
"kms:ViaService": [
"bedrock.<region>.amazonaws.com"
]
}
}
}
]
}KMS キーグラントを使用すると、カスタマイズジョブの完了後に、サービスロールに付与したアクセス許可を取り消すことができます。これにより、アクセス許可を最小権限に抑えられます。また、Amazon Bedrock はモデルの暗号化にセカンダリ KMS キーグラントを使用します。そのため、Amazon Bedrock がお客様に代わって実行するオペレーションが完了すると、グラントは直ちに自動で廃止されます。グラントの使用方法の詳細については、「Encryption of model customization jobs and artifacts」を参照してください。
これらの IAM ポリシーのガードレールを補完するために、ネットワークコントロールを追加して、プロセスのアクセス許可の範囲を絞り込むこともできます。この記事では IAM ポリシーに焦点を当てているため、詳細には触れず、プロセスの仕組みのみを説明します。
モデルのカスタマイズジョブを開始すると、モデルのデプロイアカウント内でモデルトレーニングジョブがトリガーされます。トレーニングジョブは、ベースモデルが保存されている S3 バケットからそのモデルを取得した後、カスタマイズ用のトレーニングデータを保持する S3 バケットに接続してカスタマイズを開始します。この処理は VPC を経由して行うことができます。その場合、サブネットやセキュリティグループなどの VPC 設定を指定すると、トレーニングジョブは指定どおりにその VPC に Elastic Network Interface (ENI) を配置します。これにより、トレーニングデータを読み取るための S3 バケットへのリクエストは、その ENI に対して VPC 内に設定されているルーティングルールに従うようになります。VPC のルーティングと ENI にアタッチされたセキュリティグループを使用して、モデルのカスタマイズジョブのネットワークアクセスを制限できます。
Amazon Bedrock Guardrails
Amazon Bedrock Guardrails は、生成 AI アプリケーションを大規模かつ安全に構築するための、設定可能な保護機能を提供します。Amazon Bedrock Guardrails の詳細については、サービスドキュメントを参照してください。2025 年 3 月、AWS は新しい条件キー (bedrock:GuardrailIdentifier) を追加しました。この条件キーを使用すると、ポリシーで特定のガードレールの使用を強制できます。これ以前は、Amazon Bedrock エージェントを使用する方法がありました。これについては次のセクションで説明します。
ここでは、特定のガードレールを使用する場合にのみ Amazon のモデルを呼び出せるロールを作成するとします。承認済みの設定を適用した Amazon Bedrock のガードレールは作成済みです。前の例と同様に、<region>、<account-id>、<guardrail-id>、<guardrail-version> を Amazon Bedrock のガードレールの値に置き換えてください。
この新しい条件は SCP でも使用できます。例えば、次の SCP を使用すると、すべての直接的なモデル呼び出しで、いずれかのガードレールの使用を強制できます。
この SCP では、特定のガードレールを強制していないことにお気付きかもしれません。これは意図的なものです。OU 全体などに適用できるように、SCP の粒度を粗く保っています。より具体的な制限は、個々のアカウントのポリシー (IAM または SCP) で適用できます。
Amazon Bedrock Agents
Amazon Bedrock Agents は、アプリケーション用の自律型エージェントを構築および設定する機能を提供します。Amazon Bedrock Agents の詳細については、「Automate tasks in your application using AI agents」を参照してください。
Amazon Bedrock エージェントを使用すると、推論タスクに特定のセキュリティ特性を適用することもできます。例えば、推論の呼び出しで、特定のプロンプト、IAM サービスロール、ナレッジベース、プロンプトと補完のコンテンツの制限、KMS キー、FM の使用を強制できます。このアプローチを有効に機能させるには、Amazon Bedrock エージェントの設定を作成および更新できるプリンシパルも制限する必要があります。これも、特定のプリンシパルにのみアタッチする IAM ポリシーで制限できます。
ここでは、特定の Amazon Bedrock エージェントを経由する場合にのみ Amazon Bedrock のモデルを呼び出せるロールを作成するとします。次の IAM プリンシパルのアクセス許可ポリシーの例は、指定した Amazon Bedrock エージェントに承認済みの設定が適用されていることを前提としています。ここでも、<region>、<account-id>、<bedrock-agent-id>、<bedrock-agent-alias-id> を Amazon Bedrock エージェントの値に置き換えてください。
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "AllowAgentInvocation",
"Effect": "Allow",
"Action": [
"bedrock:InvokeAgent"
],
"Resource": "arn:aws:bedrock:<region>:<account-id>:agent-alias/<bedrock-agent-id>/<bedrock-agent-alias-id>"
},
{
"Sid": "DenyDirectInvocation",
"Effect": "Deny",
"Action": [
"bedrock:InvokeModel",
"bedrock:InvokeModelWithResponseStream",
"bedrock:CreateModelInvocationJob"
],
"Resource": "arn:aws:bedrock:*::foundation-model/*"
}
]
}システム管理者またはオペレーターが、承認済みの Amazon Bedrock ガードレールを使用して Amazon Bedrock エージェントを設定していれば、前述のポリシーがアタッチされたプリンシパルはプロンプトでエージェントを呼び出すことはできますが、Amazon Bedrock のモデルを直接呼び出すことはできません。この方法は、Amazon Bedrock エージェントに適用したすべての設定を、呼び出し時に確実に強制するのに役立ちます。さらに、bedrock:InvokeModel と bedrock:InvokeModelWithResponseStream を拒否すると、Converse API と StartAsyncInvoke API も拒否されます。そのため、これらを Deny ステートメントに個別に追加する必要はありません。
以下は、アタッチされた IAM プリンシパルに、特定の Amazon Bedrock エージェントの設定を更新する権限を付与する IAM ポリシーステートメントの例です。<region>、<account-id>、<agent-id> を、使用しているリージョン、アカウント ID、エージェント ID に置き換えてください。すべてのエージェントを対象とする場合は、<agent-id> をアスタリスク (*) に置き換えます。
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "AllowUpdatingBedrockAgents",
"Effect": "Allow",
"Action": [
"bedrock:DisassociateAgentKnowledgeBase",
"bedrock:GetAgent*",
"bedrock:ListAgent*",
"bedrock:PrepareAgent",
"bedrock:TagResource",
"bedrock:UntagResource",
"bedrock:UpdateAgent*"
],
"Resource": [
"arn:aws:bedrock:<region>:<account-id>:agent/<agent-id>"
]
}
]
}エージェントが適さない場合、Amazon Bedrock のモデルで推論を実行するユーザーやアプリケーションには、bedrock:InvokeModel、bedrock:InvokeModelWithResponseStream、bedrock:CreateModelInvocationJob のいずれかのアクションを呼び出すアクセス許可が必要です。このような場合は、許可リスト方式で対象のモデルを制限することが望ましいでしょう。また、こうしたアクセス許可は、必要なロールやアプリケーションにのみアタッチします。
以下は、呼び出しを Anthropic の Claude Instant に限定するポリシーの例です。
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "AllowInvokationOnAnthropicClaudeInstantV1",
"Effect": "Allow",
"Action": [
"bedrock:InvokeModel",
"bedrock:InvokeModelWithResponseStream",
"bedrock:CreateModelInvocationJob"
],
"Resource": "arn:aws:bedrock:*::foundation-model/anthropic.claude-instant-v1"
}
]
}また、検出または事後対応のためのコントロールとして、Amazon EventBridge ルールを使用して、適切な Amazon Bedrock ガードレールを使用していないモデル呼び出しを検出することもできます。ただし、これはこの記事の範囲外です。
モデルのテスト
テストは、ソリューションをデプロイする前の最後のステップです。テストには、単体テスト、統合テスト、ユーザー受け入れテスト、ペネトレーションテストなどがあります。このフェーズでは、割り当てたアクセス許可が本当に最小権限になっているかどうかを改めて検証できます。
特にデータを扱う機能テストでは、テストに使用するデータの機密性が高い可能性があることを考慮することが重要です。テストのために合成テストデータを生成しない場合は、通常これに該当します。テストに使用するデータと、テストで生成され、そのデータの一部を含む可能性があるログへのアクセスを制限するコントロールは、本番環境で適用するものと同じにする必要があります。テスト段階だからといって、データアクセスコントロールが不要になるわけではありません。
前述のとおり、コントロールはアイデンティティだけでなく、ネットワークとリソースにも適用されます。このフェーズでは、これらすべてを検証し、その有効性を確認する必要があります。テストには次のようなものがあります (ただし、これらに限定されません)。
- Amazon Bedrock で許可されたアクションを VPC エンドポイント経由でのみ実行でき、VPC エンドポイントを使用しないアクションがブロックされることを検証します。
- VPC エンドポイントのリソースポリシーの有効性を検証し、認証および認可されたプリンシパルのみが VPC エンドポイントを使用できることを確認します。
- ナレッジベースを使用する場合は、Amazon Bedrock のサービスプリンシパルのみがナレッジベースにアクセスできることを検証します。
- Amazon Bedrock ガードレールを使用する場合は、その有効性を評価します。生成 AI アプリケーションの性質上、入力データと出力データは非常に多様になり得ます。そのため、十分な数のプロンプトを使用してガードレールをテストします。
- モデル呼び出しのログ記録を有効にしている場合は、ログが正しく書き込まれ、IAM のアクセス許可と暗号化によって保護されていることを検証します。
- ログには機密データが含まれている可能性があるため、必要な担当者のみがログにアクセスできることを検証します。ログを自動的にサニタイズして、新しい CloudWatch ロググループに転送することも検討します。
- 関連するすべての Amazon Bedrock の API コールが AWS CloudTrail に適切に記録されていること、および不審なアクティビティを効果的にモニタリングしてアラートを発行できることを検証します。
- プロンプトやレスポンスなどの機密情報が、CloudTrail ログやトレース出力に保存されていないことを確認します。
設計フェーズで脅威モデリングを実施している場合、その結果はセキュリティ関連のテストケースを作成するうえで貴重なインプットになります。
モデルの運用
このフェーズでは、最終段階としてソリューションを本番環境にデプロイします。オペレーターには、エージェント、ガードレール、プロンプトライブラリ、ナレッジベースなどの Amazon Bedrock リソースをプロビジョニングおよび管理するための、Amazon Bedrock のコントロールプレーンのアクセス許可が必要です。ただし、付与するのは、使用している Amazon Bedrock の機能をプロビジョニングおよび管理するためのコントロールプレーンのアクセス許可のみに限定する必要があります。また、これらのオペレーターが Amazon Bedrock の機能やそのリソース (Amazon Bedrock Agents、Amazon Bedrock Guardrails、プロンプトライブラリ) を呼び出したり設定したりできるのは、承認されたパイプラインを経由する場合のみとします。このイミュータブルインフラストラクチャのアプローチにより、データプレーンへの承認されていないアクセス、コントロールプレーンへの追跡されない変更、アプリケーションに支障をきたす可能性のある更新につながる状況や設定を、人間のユーザーが作り出すことを防止できます。
あるいは、割り当てるアクセス許可を必要最小限に抑えるために、パイプラインとパイプラインロールを使用した自動デプロイを利用することもできます。これにより、バージョン管理されたインフラストラクチャを実現できるだけでなく、人間のアイデンティティにアクセス権を付与しないことで最小権限の原則にも準拠できます。
デプロイ後は、ソリューションが稼働し、実際のユーザーがアクセスするようになります。この段階では、モニタリング、ログ記録、インシデント対応などが重要になります。Amazon Bedrock はデフォルトでは推論データやレスポンスデータを保存しませんが、生成 AI アプリケーションの精度を継続的に検証するために、これらのログ記録を有効にすることをお勧めします。
このソリューションを使用することで、次の領域へのアクセスを最小限に抑えることができます。
- ログに記録されたプロンプトとレスポンス
- ナレッジベース、RAG、または同様のソースを通じて利用可能なデータ
- インフラストラクチャを変更する権限
タスクごとに専用の最小権限のロールを用意し、複数のロールを使い分けてください。これにより、アクセス許可の範囲を最小限に抑えられます。また、最小権限を適用すると、特定のタスクには特定のロールを引き受ける必要があるため、意図しない変更のリスクも軽減されます。
AWS Security Reference Architecture に従うと、セキュリティモニタリングのデータが中央のセキュリティアカウントに集約されます。これにより、インフラストラクチャのセキュリティポスチャを包括的かつ一元的に把握できます。
機密情報のログ記録
運用上の重要な観点の 1 つは、LLM との間で送受信される情報をログに記録することです。この情報は機密データとなり得ます。Amazon Bedrock はプロンプトやレスポンスを保存しませんが、モデル呼び出しのログ記録を使用すると、AWS アカウント内の Amazon Bedrock におけるすべての呼び出しについて、呼び出しログ、モデルの入力データ、モデルの出力データを収集できます。モデル呼び出しのログ記録は、デフォルトでは有効になっていません。有効にすると、承認されたすべてのモデルのすべての呼び出しについて、プロンプト、補完、またはその両方が、設定したログの送信先に記録されます。プロンプトと補完のログの送信先として指定できるのは、Amazon S3 と CloudWatch です。これらの送信先にログを書き込む際は、オプションで、指定した KMS キーを使用してログを暗号化できます。
これらのログに記録される、ユーザーが入力したプロンプトやモデルが生成したレスポンスには、機密情報が含まれている可能性があります。そのため、これらのログへのアクセスは、この種の機密データへのアクセスを必要とし、かつその権限を付与されている担当者および自動化されたプロセスに限定する必要があります。Amazon S3 のログに Amazon Macie を使用したり、CloudWatch Logs のデータ保護機能を使用したりして、ログ内の機密情報を検出、モニタリング、マスクする方法もありますが、これはこの記事の範囲外です。
Amazon Bedrock ガードレールを導入していても、これらのログにはガードレール適用前のユーザー入力が含まれます。そのため、プロンプトと補完のログには機密情報が含まれていると想定する必要があります。この場合のベストプラクティスは、KMS キーでログデータを暗号化し、データ保護ポリシーをロググループに適用したうえで、少なくとも次の 3 つの IAM ロールを定義することです。
- BasicCompletionLogReviewer: ログのマスクされたバージョンへのアクセスと確認のみを目的とする IAM ロール。
- SensitiveDataCompletionLogReviewer: ログのマスクされていないバージョンへのアクセスと確認のみを目的とする、制限された IAM ロール。
- CompletionLogAdmin: Amazon S3 と CloudWatch の送信先に監査の検出結果を送信できるデータ保護ポリシーの作成、表示、削除のみを目的とする、制限された IAM ロール。
特定のロググループのログイベントの読み取りを許可するには、次のようなポリシーを BasicCompletionLogReviewer ロールにアタッチします。その際、<region>、<account-id>、<log-group-name>、<alias-name> を、CloudWatch ロググループと、そのロググループを暗号化する KMS キーに一致する値に置き換えてください。
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "AllowReadingMaskedLogStream",
"Effect": "Allow",
"Action": [
"logs:DescribeLogStreams",
"logs:GetLogEvents"
],
"Resource": "arn:aws:logs:<region>:<account-id>:log-group:<log-group-name>:*"
},
{
"Sid": "AllowDecryptOfLogEvents",
"Effect": "Allow",
"Action": [
"kms:Decrypt"
],
"Resource": "arn:aws:kms:<region>:<account-id>:alias/<alias-name>"
}
]
}データ保護ポリシーが有効な場合、前述のポリシーでは、ログのマスクされていないバージョンにはアクセスできません。SensitiveDataCompletionLogReviewer ロールにマスクされていないバージョンへのアクセスを許可するには、アクションを追加する必要があります。その際、<region>、<account-id>、<log-group-name>、<alias-name> を、CloudWatch ロググループと、そのロググループを暗号化する KMS キーに一致する値に置き換えてください。
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "AllowReadingMaskedLogEvents",
"Effect": "Allow",
"Action": [
"logs:DescribeLogStreams",
"logs:GetLogEvents",
"logs:Unmask"
],
"Resource": "arn:aws:logs:<region>:<account-id>:log-group:<log-group-name>:*"
},
{
"Sid": "AllowDecryptOfLogEvents",
"Effect": "Allow",
"Action": [
"kms:Decrypt"
],
"Resource": "arn:aws:kms:<region>:<account-id>:alias/<alias-name>"
}
]
}CompletionLogAdmin ロールのポリシーには、異なるアクセス許可が必要です。次のサンプルポリシーでは、3 種類すべての監査の送信先に監査の検出結果を送信できるデータ保護ポリシーについて、作成、表示、削除をユーザーに許可します。一方、マスクされていないデータの表示は許可しません。ポリシーは次の例のようになります。その際、<delivery-stream-id>、<bucket-name>、<log-group-name>、<alias-name> を、ご利用の環境に合わせた値に置き換えてください。なお、このポリシーには、最小権限の原則に沿って、設定された KMS キーによるログの復号をアタッチ先のロールに対して明示的に拒否するステートメントが含まれています。
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "AllowLogGroupsManagement1",
"Effect": "Allow",
"Action": [
"logs:CreateLogDelivery",
"logs:PutResourcePolicy",
"logs:DescribeLogGroups",
"logs:DescribeResourcePolicies"
],
"Resource": "*"
},
{
"Sid": "AllowLogGroupsManagement2",
"Effect": "Allow",
"Action": [
"logs:GetDataProtectionPolicy",
"logs:DeleteDataProtectionPolicy",
"logs:PutDataProtectionPolicy",
"s3:PutBucketPolicy",
"firehose:TagDeliveryStream",
"s3:GetBucketPolicy"
],
"Resource": [
"arn:aws:firehose:::deliverystream/<delivery-stream-id>",
"arn:aws:s3:::<bucket-name>",
"arn:aws:logs:::log-group:<log-group-name>:*"
]
},
{
"Sid": "AllowListKMSKeys",
"Effect": "Allow",
"Action": [
"kms:ListKeys",
"kms:ListAliases"
],
"Resource": "*"
},
{
"Sid": "DenyDecryptOfLogEvents",
"Effect": "Deny",
"Action": [
"kms:Decrypt"
],
"Resource": "arn:aws:kms:<region>:<account-id>:alias/<alias-name>"
}
]
}このアプローチにより、機密データソースであるこれらのログへの意図しないアクセスや漏えいを防ぎやすくなります。また、職務を分離することで最小権限の原則を順守できます。
IAM のアクセス許可の定期的な見直し
要件や機能は時間とともに変化するため、アクセス許可の管理は継続的な取り組みです。そのため、割り当てたアクセス許可を定期的に見直し、必要以上に広いアクセス許可になっていないかを確認することをお勧めします。例えば、Amazon Bedrock に API コールを行う Lambda 関数があり、その関数に追加のアクセス許可 (新しいモデルの使用など) が必要な変更を加えた場合、関数が使用する IAM ロールにアタッチされたポリシーを更新するのは妥当です。ただし、以前のモデルを使用するためのアクセス許可が同じポリシー内で引き続き必要かどうかは、必ずしも明確ではありません。また、すべてのモデルを対象とするように、アクセス許可が不必要に拡大されてしまう可能性もあります。最小権限の原則を適用する際は、デプロイ時にポリシーをテストしてアプリケーションのニーズを過不足なく満たしていることを確認するだけでなく、想定したニーズを定期的に見直すことも重要です。
AWS IAM Access Analyzer を使用すると、IAM ポリシーの変更案を確認およびシミュレーションして、特定のアプリケーションや関数に適しているかどうかを確かめることができます。また、IAM Access Analyzer を使用して、未使用の許可を継続的に確認することもできます。これにより、システムオペレーターは、Amazon Bedrock アプリケーションで使用されるポリシー内の未使用の許可を調査し、削除を判断する機会を得られます。ただし、インシデント対応やリカバリ、その他のまれなユースケースなど、普段は使用されていなくても、ときどき使用するために保持されているアクセス許可もあります。そのため、見直しの際には、未使用の許可をすぐに不要とみなすのではなく、その必要性を再検討する機会としてとらえてください。
最後に、新しい Amazon Bedrock API のモニタリングを IAM 戦略と連携させてください。特に拒否リスト方式を使用する場合は、サービスで新しい API、機能、FM が順次発表されることを考慮する必要があります。その一例が、新しい Converse API の発表です。この API は Invoke と同様の機能を一貫した方法で提供するため、よりシンプルに使用できます。このような変更を考慮することは、定期的なポリシーの見直しプロセスに欠かせません。
強力なアイデンティティとアクセス管理は、一度きりの対応ではなく、継続的な取り組みです。
まとめ
この記事では、Amazon Bedrock を使用する大規模言語モデル (LLM) ベースのアプリケーションに、最小権限の原則を適用する方法をいくつか紹介しました。開発ライフサイクルの各フェーズにおけるセキュリティの考慮事項を説明し、最小権限の原則に基づく独自の戦略を実装する際の出発点となる例を示しました。セキュリティへの取り組みは、プロセスの後半になってから始めるのではなく、早い段階から始めることが重要です。アプリケーションの稼働時に戦略が確実に効果を発揮するように、リスクと必要な対策をできるだけ早い段階で検討してください。
最後に、生成 AI の分野は急速に進化していることを忘れないでください。AWS は、生成 AI がほぼすべての顧客体験を変革する可能性を秘めていると考えています。セキュリティの観点から見ると、これは脅威の状況が時間とともに変化し、進化していくことを意味します。新たなリスクに常に適応し、それらを評価して最小権限の原則に基づく戦略に組み込んでください。
AWS のアカウントチームとスペシャリストが、この取り組みを喜んでサポートします。
この記事に関するご質問は、AWS サポートにお問い合わせください。
本ブログは Security Solutions Architect の 中島 章博 が翻訳しました。