# AWS STS、静的IAMロールを増やさず権限限定

> 信頼されないコードの隔離、ソース変更の承認とプライベートCI/CD、データセンターの費用・資源要件を整理します。実行権限、開発経路、施設計画の各境界で、何を技術統制や運用条件として具体化すべきかを確認できます。相互に独立した更新を、導入前の判断材料として読み解きます。

Canonical URL: https://labs.eastbraver.com/digest/ai-digest-20260922
Published: 2026-09-22T06:30:00+09:00
Category: ai-digest
Tags: agentcore, agentic-infra, ai-agent, amazon-bedrock, aws, infrastructure, software-engineering, governance

まず読むべきは、Benchlingが信頼されないコードの実行環境、通信経路、データ権限を分離し、隔離違反を継続的インテグレーションで検査する事例です。続いて、Secure Source Managerのファイル・ブランチ別承認とプライベートCI/CD接続を確認します。カリフォルニア州では、データセンターに費用負担と資源情報の開示を求める法制化が進みました。

3件は独立した更新ですが、共通する判断は、AI導入に伴う境界をどこまで強制可能な要件に落とすかです。実行環境では通信とジョブ単位の権限、開発経路では変更承認とCI/CD接続、施設計画では公益事業費用と水・エネルギー情報を、それぞれ技術統制または運用条件として確認する必要があります。（[出典1](https://aws.amazon.com/blogs/machine-learning/how-benchling-secured-multi-tenant-ai-agents-with-amazon-bedrock-agentcore/) / [出典2](https://cloud.google.com/blog/products/identity-security/strengthen-your-cicd-pipeline-with-new-secure-source-manager-capabilities/) / [出典3](https://www.gov.ca.gov/2026/09/21/governor-newsom-signs-most-comprehensive-data-center-laws-in-the-nation-providing-communities-more-control-on-water-electricity-and-land-use/)）

> [!NOTE] 収集範囲
> この号は、一部の収集元から情報を取得できない状態で作成した。取得できなかった収集元に更新がなかったことを示すものではない。
>
> - AI関連の報道: 収集元5件中1件を取得できなかった

## Benchling、AgentCoreの実行環境とデータ権限を多層分離

Benchlingは、AgentCore Code Interpreterを本番環境とは別の[信頼されないコード用実行環境](/guides/sandbox)に置き、ネットワーク境界とデータ権限を分けてマルチテナント実行を隔離した。実行用VPCにはインターネットゲートウェイもNATゲートウェイもなく、セキュリティグループをポート443に制限している。（[出典1](https://aws.amazon.com/blogs/machine-learning/how-benchling-secured-multi-tenant-ai-agents-with-amazon-bedrock-agentcore/)）

名前解決はRoute 53 Resolver DNS Firewallで、明示的に許可したS3エンドポイントなどに限定する。通信経路もVPCエンドポイントだけに絞り、VPCエンドポイントポリシーに記載されていないS3バケットへの要求をネットワーク層で拒否する。（[出典1](https://aws.amazon.com/blogs/machine-learning/how-benchling-secured-multi-tenant-ai-agents-with-amazon-bedrock-agentcore/)）

権限管理では、テナントごとの静的IAMロールを増やさず、AWS STSを通じて各実行セッションへ[ジョブ単位の認証情報](/guides/ai-identity-authorization)を注入する。信頼されないコードから参照できるのは当該ジョブに必要な特定データだけで、本番アカウントの認証情報や顧客データストア全体は直接公開しない。（[出典1](https://aws.amazon.com/blogs/machine-learning/how-benchling-secured-multi-tenant-ai-agents-with-amazon-bedrock-agentcore/)）

この境界は設定だけでなく、DNSトンネリング、未許可エンドポイントへの直接接続、許可範囲外のS3バケットへのアクセスを継続的インテグレーションで試験している。いずれかの試行が成功した場合はパイプラインを失敗させ、リリースを止める。（[出典1](https://aws.amazon.com/blogs/machine-learning/how-benchling-secured-multi-tenant-ai-agents-with-amazon-bedrock-agentcore/)）

**EastBraverの見立て:** 運用上の判断点は、テナント別の静的IAMロールを増やすことではなく、AWS STSによるジョブ単位の権限縮小と、継続的な流出試験を一体で設計することにある。（[出典1](https://aws.amazon.com/blogs/machine-learning/how-benchling-secured-multi-tenant-ai-agents-with-amazon-bedrock-agentcore/)）

- 出典: [AWS](https://aws.amazon.com/blogs/machine-learning/how-benchling-secured-multi-tenant-ai-agents-with-amazon-bedrock-agentcore/)（公式情報、2026-09-22 01:27 JST）

## Secure Source Manager、承認統制とCI/CD接続の2機能を一般提供

Google Cloudは、Secure Source Managerで開発・CI/CDワークフローを簡素化し、保護する2つの新機能を一般提供した。Code Ownersはコード変更の承認を細分化し、Developer Connect連携はCI/CDシステムへの無許可アクセスを抑える。（[出典1](https://cloud.google.com/blog/products/identity-security/strengthen-your-cicd-pipeline-with-new-secure-source-manager-capabilities/)）

Google Cloudによると、Code Ownersは、権限を持つ利用者による不正なコード変更を緩和するため、ファイル単位およびブランチ単位でプルリクエストの承認者を管理する。導入時はリポジトリのルートにCODEOWNERSファイルを作成し、一律的なIAMのApproverロールをファイル固有の所有権へ置き換える。パス別の承認者やブランチ別の所有者も指定できる。（[出典1](https://cloud.google.com/blog/products/identity-security/strengthen-your-cicd-pipeline-with-new-secure-source-manager-capabilities/)）

Developer Connect連携は、Secure Source ManagerとCloud Buildを接続する。Google Cloudは、企業ネットワークの侵害時にも、バージョン管理、ビルド、成果物、デプロイ系への無許可アクセスを遮断することを狙う機能だと説明している。提示された構成では、Secure Source ManagerからPrivate Service Connectを経由してCloud Buildへ接続する。（[出典1](https://cloud.google.com/blog/products/identity-security/strengthen-your-cicd-pipeline-with-new-secure-source-manager-capabilities/)）

提示されたプライベートCI/CDブループリントでは、リポジトリ、ビルドプール、成果物ストレージをプライベートネットワーク内に置き、VPC Service Controlsでプロキシエンドポイントへのアクセスを制限する。（[出典1](https://cloud.google.com/blog/products/identity-security/strengthen-your-cicd-pipeline-with-new-secure-source-manager-capabilities/)）

**比較表: 2つの機能が塞ぐ経路と追加する構成**

Code Ownersはリポジトリ内の変更承認を細分化し、Developer Connect連携はネットワーク侵害時を含むCI/CDシステムへの無許可アクセスに対処する。（[出典1](https://cloud.google.com/blog/products/identity-security/strengthen-your-cicd-pipeline-with-new-secure-source-manager-capabilities/)）

| 観点 | Code Owners | Developer Connect連携 |
| --- | --- | --- |
| 対象となる経路 | 権限を持つ利用者による無許可のコード変更。（[出典1](https://cloud.google.com/blog/products/identity-security/strengthen-your-cicd-pipeline-with-new-secure-source-manager-capabilities/)） | 企業ネットワーク侵害時を含む、CI/CDシステムへの無許可アクセス。（[出典1](https://cloud.google.com/blog/products/identity-security/strengthen-your-cicd-pipeline-with-new-secure-source-manager-capabilities/)） |
| 既存構成への追加 | ルートのCODEOWNERSファイルと、パス別・ブランチ別の所有者設定。（[出典1](https://cloud.google.com/blog/products/identity-security/strengthen-your-cicd-pipeline-with-new-secure-source-manager-capabilities/)） | Developer Connectを使ったSecure Source ManagerとCloud Buildの接続。（[出典1](https://cloud.google.com/blog/products/identity-security/strengthen-your-cicd-pipeline-with-new-secure-source-manager-capabilities/)） |

**EastBraverの見立て:** 導入判断では、Code Ownersを変更承認の統制、Developer Connect連携をCI/CD接続の保護として分けて捉えるとよい。前者ではCODEOWNERSファイルを作成し、Google Cloudが示す構成例では後者によりSecure Source ManagerをCloud Buildへ接続する。（[出典1](https://cloud.google.com/blog/products/identity-security/strengthen-your-cicd-pipeline-with-new-secure-source-manager-capabilities/)）

- 出典: [Google Cloud](https://cloud.google.com/blog/products/identity-security/strengthen-your-cicd-pipeline-with-new-secure-source-manager-capabilities/)（公式情報、2026-09-22 01:00 JST）

## カリフォルニア州、データセンターの費用・資源要件を法制化

カリフォルニア州のギャビン・ニューサム知事は、データセンターの電力、水、土地利用に関する7法案に署名した。対象はAB 1577、AB 2383、AB 2469、AB 2619、SB 886、SB 887、SB 1168で、州政府は住民への費用転嫁を防ぎ、計画段階の情報を地域へ示すことを狙いとしている。（[出典1](https://www.gov.ca.gov/2026/09/21/governor-newsom-signs-most-comprehensive-data-center-laws-in-the-nation-providing-communities-more-control-on-water-electricity-and-land-use/)）

電力面では、SB 1168がカリフォルニア州公益事業委員会に料金体系の選択肢を検討させ、データセンターが送配電や負荷増加に伴う費用の合理的な割合を負担することを求める。SB 886は、対象施設の接続と電力供給について、2028年1月1日までに新しい料金表を設けるか既存規則を更新し、対象外の顧客への費用転嫁を防ぐよう求める。（[出典2](https://leginfo.legislature.ca.gov/faces/billNavClient.xhtml?bill_id=202520260SB1168) / [出典3](https://leginfo.legislature.ca.gov/faces/billNavClient.xhtml?bill_id=202520260SB886)）

水利用では、AB 2469がデータセンターの新設または最大ピーク水使用量を増やす拡張の許可条件を定める。申請者は水供給評価、推定水使用量、水効率対策を提出し、2028年1月1日以降は渇水計画も提出する。必要な導水、処理・貯留、配水設備の改修費は申請者が全額負担する。（[出典4](https://leginfo.legislature.ca.gov/faces/billNavClient.xhtml?bill_id=202520260AB2469)）

> [!CAUTION] 確認できていない点
> 公益事業委員会が今後定める料金体系と料金表の具体的な算定方法は、成立法の時点では確定していない。7法案の個別要件は一律ではなく、施設の新設・拡張、接続時期、受電形態などで適用範囲が異なる。

**EastBraverの見立て:** 事業影響の評価では、電力系統の費用負担、水利用を増やす建設・拡張時の開示義務、迅速化手続きの適格要件を分けて確認する必要がある。法案ごとに対象条件と施行時期が異なるため、7法案を単一の規制として扱うべきではない。（[出典1](https://www.gov.ca.gov/2026/09/21/governor-newsom-signs-most-comprehensive-data-center-laws-in-the-nation-providing-communities-more-control-on-water-electricity-and-land-use/) / [出典2](https://leginfo.legislature.ca.gov/faces/billNavClient.xhtml?bill_id=202520260SB1168) / [出典3](https://leginfo.legislature.ca.gov/faces/billNavClient.xhtml?bill_id=202520260SB886) / [出典4](https://leginfo.legislature.ca.gov/faces/billNavClient.xhtml?bill_id=202520260AB2469)）

- 出典: [カリフォルニア州政府](https://www.gov.ca.gov/2026/09/21/governor-newsom-signs-most-comprehensive-data-center-laws-in-the-nation-providing-communities-more-control-on-water-electricity-and-land-use/)（公式情報、2026-09-21 現地時間）
- 法案本文: [SB 1168](https://leginfo.legislature.ca.gov/faces/billNavClient.xhtml?bill_id=202520260SB1168) / [SB 886](https://leginfo.legislature.ca.gov/faces/billNavClient.xhtml?bill_id=202520260SB886) / [AB 2469](https://leginfo.legislature.ca.gov/faces/billNavClient.xhtml?bill_id=202520260AB2469)