本ブログは 2026 年 6 月 16 日に公開された AWS Blog “ Threat tactic spotlight: Subdomain takeover ” を翻訳したものです。 このブログ記事では、サブドメイン乗っ取り (subdomain takeover) を検出して防止する方法を説明します。サブドメイン乗っ取りとは、脅威アクターがダングリング DNS レコード (dangling DNS record) を悪用し、トラフィックを攻撃者が管理するリソースにリダイレクトする手口です。この記事では、この問題の概要と発生する仕組みを説明し、さまざまな AWS の機能やサービスを使用してこの手口の影響を緩和する方法を紹介します。 責任共有モデル では、クラウド内の設定のセキュリティを確保することはお客様の責任です。AWS は、強固なデフォルト設定、 Well-Architected フレームワークのセキュリティの柱 のガイダンス、およびセキュリティサービスを通じて、お客様がその責任を果たせるよう支援しています。また、AWS Customer Incident Response Team (AWS CIRT) は、お客様の特定の設定を悪用するために脅威アクターが使用する新たな手口や流行している手口を監視しています。これにより、お客様は十分な情報に基づいて設計上の判断を下し、対応計画を改善できます。 AWS CIRT は、サブドメイン乗っ取りの機会を狙う脅威アクターが、既に存在しないリソースを指すパブリック DNS の CNAME レコードを積極的にスキャンしていることを確認しています。 注: サブドメイン乗っ取りの手口は、AWS サービスの脆弱性を利用するものではありません。ダングリング DNS レコードを悪用して、トラフィックを攻撃者が管理するリソースにリダイレクトするものです。 DNS の基礎知識 CNAME レコード: CNAME (Canonical Name) レコードは、あるドメイン名を別のドメイン名に向ける DNS エントリです。例えば、api.example.com が api.example.s3-website-us-east-1.amazonaws.com を指すように設定できます。DNS のこの機能により、実際のリソースには機械的に生成された長い AWS ホスト名が割り当てられていても、お客様は覚えやすくわかりやすいドメイン名を設定できます。ただし、ターゲットのリソースを削除した後もそれを指す CNAME レコードが残っていると、「ダングリング」レコードとなり、セキュリティ上の問題が生じます。 ダングリングレコード: リソース (S3 バケットなど) を削除した後もそれを指す DNS レコードが残っている場合、その DNS レコードは存在しないリソースを指す「ダングリング」状態になります。グローバルに共有される名前空間内のリソースの場合、脅威アクターが削除済みのリソース名を取得し、お客様の DNS レコードを通じて悪意のあるコンテンツを配信できる可能性があります。 サブドメイン乗っ取りとは？ サブドメインとは、ドメインの前に付加するプレフィックスで、リソースへのアクセスを整理するために使用します。サブドメイン乗っ取りは、お客様が基盤となるリソースを削除した後、脅威アクターが同じ名前で新しいリソースを作成し、そのリソースを指したまま残っている DNS レコードを悪用することで発生します。 サブドメイン乗っ取りが起こり得るのは、グローバルに共有される DNS 名前空間を使用する AWS リソースを CNAME レコードが指している場合です。このような名前空間では、AWS のお客様であれば誰でもリソース名を選択できます。次の AWS リソースがこの条件に該当します。 Amazon S3 (グローバル名前空間): mybucket.s3.amazonaws.com のようなバケット名はグローバルに一意であり、バケットが削除されると、どのアカウントでもその名前を取得できます。注: アカウントリージョナル名前空間 (2026 年 3 月にリリース) を使用して作成された S3 バケットは、スコープがお客様のアカウントに限定されるため、この問題の対象にはなりません。 Amazon CloudFront: d111111abcdef8.cloudfront.net のようなディストリビューションのドメイン名は AWS によって割り当てられるため、攻撃者が選択することはできません。ただし、お客様がディストリビューションを削除した後、別のお客様が新たに作成したディストリビューションにたまたま同じドメイン名が割り当てられると、ダングリング CNAME を通じて、そのお客様のコンテンツが配信される可能性があります。 AWS Elastic Beanstalk: myapp.elasticbeanstalk.com のような環境名はグローバルに一意であり、環境を終了すると、どのアカウントでもその名前を取得できます。 Amazon VPC、Amazon EC2 インスタンス、プライベートホストゾーンなどのリソースは、グローバルに取得可能な DNS 名前空間を公開していないため、この手口の対象にはなりません。 MITRE ATT&CK では、この手法を T1584.001: Compromise Infrastructure – Domains に分類しています。 シナリオ例の分析 次のシナリオを考えてみましょう。 S3 ウェブサイトエンドポイントを指す DNS CNAME レコードを作成したとします。これにより、サブドメイン subdomain.example.com は subdomain.example.s3-website-us-east-1.amazonaws.com に解決され、subdomain.example という名前の S3 バケットからコンテンツが配信されます。チームがバケットを削除した際に DNS レコードの削除を忘れると、サイトにアクセスしたユーザーには、バケットが存在しないことを示すエラーが表示されます。しかし、この時点で脅威アクターがこのエラーに気付いてそのバケット名を取得すると、独自のサイトを構築できてしまいます。ユーザーが subdomain.example.com サイトにアクセスすると、そのサイトが表示されることになります。 図 1 は、静的ウェブサイトをホストするように設定された subdomain.example という名前の S3 バケット (グローバルに一意なバケット名) と、その S3 ウェブサイトエンドポイント subdomain.example.s3-website-us-east-1.amazonaws.com を示しています。 図 1: 静的ウェブサイトとして設定された S3 バケット 図 2 に示すように、Amazon Route 53 を使用して、Amazon のドメイン名に解決される CNAME レコードを作成します。これにより、ユーザーはわかりやすい名前でアクセスでき、URL に含まれる長い S3 ウェブサイト名を覚える必要がなくなります。 図 2: オリジンバケットを指す CNAME レコードが設定された DNS リゾルバー その後、お客様の AWS 管理者は S3 バケットからのコンテンツ配信を停止することにし、 図 3 に示すようにバケットを削除します。 図 3: CNAME レコードを削除せずにリソースを削除 S3 バケットは削除されたものの CNAME レコードが残っているため、DNS レコードはダングリング状態になります。脅威アクターはこの状況を突き止め、 図 4 に示すように、自身が管理する AWS アカウントで同じグローバル名 subdomain.example を持つ新しい S3 バケットを作成します。これにより脅威アクターは、この新しいバケットからコンテンツを配信できるようになり、その中には悪意のあるコンテンツが含まれる可能性もあります。ユーザーはこの切り替えに気付かず、見覚えのある URL から配信されているように見えるため、コンテンツを信頼して subdomain.example.com へのアクセスを続けます。 図 4: サブドメイン乗っ取りの発生 サブドメイン乗っ取りによって想定される影響 次のような影響が考えられます。 評判へのリスク: DNS レコードが指している脅威アクターのサイトから配信されるコンテンツはお客様が管理できないため、組織の評判が損なわれるリスクがあります。 フィッシングキャンペーンにさらされる可能性: 組織内のユーザーがサブドメインをブラウザにブックマークしている場合、リソースが既に利用できないことを知らないまま、マルウェアをホストしているサイトや、ユーザーの認証情報を詐取するフィッシングに使用されているサイトに、何の疑いもなくアクセスしてしまう可能性があります。 ブロック: サブドメインが悪意のあるアクティビティを理由にセキュリティベンダーからフラグ付けされると、業務に影響が及ぶ可能性があります。 経済的損失: サブドメイン乗っ取りのインシデントに対応する間、サービス提供が中断される可能性があり、経済的な影響が生じる場合があります。 プロアクティブな検出 AWS Config によるプロアクティブな検出 プロアクティブに検出するには、AWS Config を使用して Route 53 の CNAME レコードを継続的に監視し、ターゲットのリソースがアカウント内に存在することを確認します。 前提条件: この方法では、監視対象のリソースタイプ (S3 バケット、CloudFront ディストリビューション、Elastic Beanstalk 環境) に対して AWS Config レコーダーを有効にしておく必要があります。AWS Config で記録されていないリソースタイプは、インベントリチェックに表示されません。詳細については、「 コンソールを使用した AWS Config のセットアップ 」を参照してください。 DNS 解決チェックではなく AWS Config インベントリを使用する理由 一般的な方法は、CNAME が有効なエンドポイントに解決されるかどうかを確認することです。しかし、この方法には重大な欠陥があります。攻撃者が既にリソースを取得している場合、DNS 解決は成功します。ただし、その解決先はお客様のリソースではなく攻撃者のリソースです。応答しているリソースがお客様の所有物ではないことに気付く手がかりはありません。 AWS Config に記録された設定項目をクエリすれば、その DNS 名で単に 何か が応答するかどうかではなく、リソースが お客様の アカウントのインベントリに存在するかどうかを確認できます。この方法なら、乗っ取りが既に発生した後でも、ダングリング CNAME を正しく特定できます。 実装方法: アカウントレベルと組織レベルのスコープ リファレンス実装では、単一のアカウント内の AWS Config インベントリをクエリします。そのため、アカウント A の CNAME レコードが、同じ AWS 組織内のアカウント B に正当に存在するリソースを指している場合でも、ルールはそのレコードを NON_COMPLIANT としてフラグ付けします。 アカウント間でリソースを共有している組織では、AWS Config アグリゲータを使用するようにソリューションを変更できます。AWS Config アグリゲータは、組織内のすべてのアカウントを対象にリソースインベントリをクエリします。これは、IAM Access Analyzer がアカウントレベルと組織レベルの両方のスコープをサポートしているのと同様の考え方です。この方法を使用するには、組織レベルの AWS Config アグリゲータを事前に設定しておく必要があります。また、Lambda 関数の IAM ロールには config:SelectAggregateResourceConfig 権限が必要です。 AWS は、まずはシンプルなアカウントレベルのスコープから始め、環境にクロスアカウントのリソース共有が含まれる場合は組織レベルに拡張することをお勧めします。 基本的な考え方は、Route 53 ホストゾーンの CNAME レコードをクエリするカスタム AWS Config ルールを作成することです。このルールは、各 CNAME のターゲットを解析し、S3、CloudFront、Elastic Beanstalk などの既知の AWS リソースパターンを指しているかどうかを判断します。パターンに一致した CNAME ごとに、ルールはターゲットを AWS Config インベントリと照合し、リソースが実際にアカウント内に存在するかどうかを確認します。リソースが見つからない場合、ルールは CNAME レコードを NON_COMPLIANT としてマークし、レビューが必要なものとして提示します。 AWS Config ルールでは、次の既知の AWS リソースパターンを対象とします。 S3: *.s3.amazonaws.com, *.s3-website-<region>.amazonaws.com 訳注: S3 ウェブサイトエンドポイントは、リージョンによって s3-website.<region>.amazonaws.com (ドット形式) になる場合もあるため、検出パターンではこの形式も考慮してください。参照: Amazon S3 ユーザーガイドの「 ウェブサイトエンドポイント 」 CloudFront: *.cloudfront.net Elastic Beanstalk: *.elasticbeanstalk.com 注: 外部のサードパーティサービスを指す CNAME レコードは、参照先のリソースが AWS Config インベントリに含まれないため、この検出メカニズムの対象外です。 AWS Config ルールによる NON_COMPLIANT の検出結果は、AWS Security Hub に送信して一元的に可視化したり、SNS 通知をトリガーしてセキュリティチームにアラートを送ったりできます。 図 5: ダングリング DNS 検出ソリューション リファレンス実装: AWS は、この検出方法の完全な実装を、 オープンソースのソリューションとして公開 しています。このソリューションでデプロイされる Lambda 関数は、すべての Route 53 ホストゾーンから CNAME レコードを検出し、パターンマッチングを使用して S3、CloudFront、Elastic Beanstalk を指すターゲットを特定します。続いて、AWS Config インベントリをクエリし、各ターゲットリソースがアカウント内に引き続き存在するかどうかを確認します。ダングリングレコードを検出すると、Security Hub で重要度 HIGH の検出結果を生成します。オプションで SNS 通知を送信し、セキュリティチームにアラートを送ることもできます。また、継続的なコンプライアンス追跡のための CloudWatch メトリクスダッシュボードも含まれています。 デプロイ: # Clone the repository git clone https://github.com/aws-samples/sample-dangling-dns-detection cd sample-dangling-dns-detection # Build the Lambda deployment package ./scripts/package.sh # Upload to S3 aws s3 cp dist/dangling-dns-detection.zip s3://YOUR_BUCKET/ # Deploy the CloudFormation stack aws cloudformation deploy \ --template-file infrastructure/template.yaml \ --stack-name dangling-dns-detection \ --parameter-overrides \ LambdaCodeS3Bucket=YOUR_BUCKET \ EvaluationFrequency=TwentyFour_Hours \ --capabilities CAPABILITY_NAMED_IAM このスタックは、指定したスケジュール (デフォルト: 24 時間ごと) で実行される AWS Config カスタムルールを作成します。このルールは、すべての CNAME レコードを評価し、コンプライアンスステータスを報告します。 影響の緩和 サブドメイン乗っ取りを緩和するには、予防のための手順と、発生時の対応能力の両方が必要です。 予防: 標準作業手順 最も効果的な緩和策は、リソースのプロビジョニング解除に関する標準作業手順を定め、基盤となるリソースより先に DNS レコードを確実に削除することです。 DNS ゾーン内で、プロビジョニング解除を予定しているリソースの完全修飾ドメイン名 (FQDN) を指す CNAME レコードを削除します。 DNS の TTL が期限切れになるまで待ってから、リソースを削除します。DNS リゾルバーは TTL の期間中レコードをキャッシュします (例えば、TTL が 3,600 の場合、リゾルバーは最大 1 時間、古いレコードを返す可能性があります)。TTL が期限切れになる前にリソースを削除すると、キャッシュされた CNAME エントリによってトラフィックがまだそのリソースに向けられている間に、脅威アクターがリソース名を取得できてしまう可能性があります。 不要になったリソースをプロビジョニング解除します。 削除した CNAME レコードについて DNS チェックを実行し、その名前がリソースに解決されなくなったことを確認します。 重要な原則: 必ず最初に DNS レコードを削除し、TTL が期限切れになるのを待ってから、リソースを削除してください。この順序を守ることで、ダングリングレコードが悪用される隙をなくすことができます。 予防: S3 のアカウントリージョナル名前空間 前述のとおり、AWS は 2026 年 3 月に Amazon S3 汎用バケットのアカウントリージョナル名前空間 を導入しました。これは S3 固有の乗っ取り経路の緩和に向けた意義のある一歩ですが、運用上の重要な制限事項に注意する必要があります。 既存のバケットには適用されません。 グローバル名前空間で既に作成されたバケットは、アカウントリージョナル名前空間に移行できません。これらのバケット名はグローバルに一意のままであり、バケットを削除すると誰でもその名前を取得できます。 グローバル名前空間が引き続きデフォルトです。 コンソール、CLI、SDK のいずれで新しいバケットを作成する場合も、グローバル名前空間がデフォルトで選択されたままです。新しいオプションを知らないお客様は、今後もグローバルスコープのバケットを作成し続けることになります。 既存の IaC テンプレートは更新が必要です。 アカウントリージョナル名前空間の使用を明示的に選択していない既存の Infrastructure as Code (IaC) テンプレート (CloudFormation、CDK、Terraform) では、引き続きグローバル名前空間でバケットがプロビジョニングされます。CloudFormation の場合は、BucketNamespace プロパティを account-regional に設定します。その他の IaC ツールについては、それぞれのドキュメントで同等の設定を確認してください。組織は、テンプレートを監査し、オプトインするよう更新する必要があります。 こうした理由から、この記事で説明したダングリング DNS の検出方法は引き続き不可欠です。既存の S3 インフラストラクチャを持つ組織や、同等の名前空間のスコープ設定が用意されていない CloudFront および Elastic Beanstalk のリソースについては、特に重要です。 対応: 通知と修復 ダングリング DNS レコードが検出されると、「プロアクティブな検出」セクションで説明したリファレンスソリューションは、AWS Security Hub で重要度 HIGH の検出結果を自動的に作成し、AWS Config で CNAME レコードを NON_COMPLIANT として報告します。デプロイ時に SNS トピック ARN を指定すると、E メール、Slack、その他のチャネルを通じて通知を送信し、セキュリティチームや運用チームにアラートを送ることもできます。本番環境では、ヒューマンインザループのワークフローを検討してください。チームメンバーが通知を確認し、DNS レコードの削除を実行前に承認する仕組みです。これにより、一時的な問題の発生時に正当なレコードを誤って削除することを防げます。 リファレンスソリューションには、コンプライアンスステータスと評価メトリクスを経時的に追跡するための CloudWatch ダッシュボードも含まれています。これにより、チームはホストゾーン全体の DNS の健全性を継続的に可視化できます。 注: 完全に自動化された修復 (DNS レコードの自動削除) にはリスクが伴い、誤検知によって正当なサービスが中断される可能性があります。AWS は、まずは検出と通知から始め、検出精度と運用の成熟度に応じて自動化を検討することをお勧めします。 まとめ サブドメイン乗っ取りは、防止可能な設定ミスでありながら、組織に重大な影響を及ぼす可能性があります。多層防御のアプローチを取ることで、最も効果的に保護できます。 予防: 基盤となるリソースのプロビジョニングを解除する前に DNS レコードを削除する標準作業手順を導入します。 検出: AWS Config カスタムルールを使用して、アカウント内に存在しなくなったリソースを指す CNAME レコードをプロアクティブに特定します。 対応: SNS または Security Hub を通じて通知を設定し、ダングリングレコードが検出されたときにチームが迅速に対応できるようにします。 監視: CloudWatch ダッシュボードを使用して継続的な可視性を確保し、DNS の健全性とコンプライアンスステータスを追跡します。 重要なのは、DNS を適切に管理すること、つまり CNAME レコードが存在しないリソースを指している状況を把握することが、第一の防御策になるという点です。AWS Config による自動検出は、運用手順が機能しなかった場合のセーフティネットになります。さらに、問題を検出したときにすぐ実行できる対応用のプレイブックを用意しておけば、影響を抑え、平均復旧時間を短縮できます。 Matthew Gurr Matthew は、AWS Customer Incident Response Team (AWS CIRT) のアジアパシフィック地域における Senior Incident Response lead です。お客様がセキュリティイベントに事前に備えられるよう支援することに情熱を注いでいます。余暇には、サイクリング、音楽、読書を楽しんでいます。 Luis Pastor Luis は AWS の Senior Security Solutions Architect で、Infrastructure Security and Compliance Technical Field Communities を率いています。金融サービス、ヘルスケア、小売の各業界のエンタープライズのお客様に向けてセキュリティアーキテクチャを推進しており、クラウドセキュリティの変革と規制コンプライアンスフレームワークを専門としています。AWS に入社する前は、ハイブリッドクラウド環境でセキュリティソリューションを設計していました。 Geoff Sweet Geoff は 1990 年代後半からこの業界に携わっています。電気工学の分野でキャリアをスタートし、ドットコムブームの時期に IT 業界に入りました。これまでに、システムアーキテクト、ネットワークアーキテクト、そしてここ数年はセキュリティアーキテクトなど、さまざまな役割を担ってきました。Geoff はインフラストラクチャセキュリティを専門としています。 Ariam Michael Ariam は AWS の Solutions Architect です。Worldwide Public Sector のさまざまなお客様、特に SLG (州政府・地方自治体) および連邦政府の民生機関のお客様を支援してきました。セキュリティ、特にデータ保護に情熱を注いでおり、お客様による暗号化の実装やベストプラクティスの実践を支援しています。 本ブログは Security Solutions Architect の 中島 章博 が翻訳しました。

はじめに NTT西日本の芳と鈴木です。 本記事では、私たちが JANOG58 で発表した「 人のための自動化が AI エージェント運用への道を拓く ― IOWN APN × VXLAN/EVPN をまたぐマルチレイヤ抽象化の実践 」の内容をご紹介します。複数拠点にまたがる分散データセンタ（分散DC）の運用は、光（IOWN APN）と IP/Ethernet（VXLAN/EVPN）の両方に精通した少数の高スキル人材に依存しがちです。私たちはこの属人化を スキルレス基盤 で解消し、さらにその基盤が AI エージェントによる自律運用の実行基盤にもなる という仮説を、開発と検証を通じて確かめました。ネットワーク運用の自動化や AI エージェント活用に関心のある方に、その考え方と手応えをお届けします。 本記事は 2026 年 9 月時点の情報に基づきます。 対象読者 本記事が想定する対象読者は以下の通りです。 VXLAN/EVPN、光伝送の基礎、REST/NETCONF の概念をお持ちだと、より読み進めやすい内容です。 ネットワーク運用の属人化・スキル依存に課題を感じている方 IOWN APN や VXLAN/EVPN Multi-site など、マルチレイヤ・マルチベンダ環境の運用に携わっている方 ネットワーク自動化やオーケストレーション（Cisco NSO など）に取り組んでいる方 MCPやAgent Skills（SKILL.md、以下Skills）を活用したAIエージェント運用に興味がある方 目次 はじめに 対象読者 目次 1. 背景・目的 2. 分散DC運用の課題 ― マルチレイヤ・マルチベンダ・可視化分断 3. 解決アプローチ ― コントローラAPIによるスキルレス基盤 マルチレイヤ制御統合API トランザクションの一括管理 情報取得一元化API 4. スキルレス基盤はAI エージェントの実行基盤になるか 5. 比較検証 ― 属人/スキルレス/AI エージェントの 3 パターン 6. AI エージェントデモ ― NSO × MCP × Skills 7. まとめ 執筆者 参考資料・出典 商標 免責事項 1. 背景・目的 近年、生成 AI をはじめとする計算需要の高まりにより、1 拠点の DC では賄いきれない規模の GPU リソースが求められています。私たちは、複数拠点の DC を VXLAN/EVPN Multi-site と IOWN APN（All-Photonics Network）で結び、CPU・GPU・メモリ・分散ストレージを拠点を越えて自由に活用できる 分散DCアーキテクチャ の社会実装をめざしています。テナントやサービス、ワークロードごとに、VXLANオーバーレイから光波長パスまで含めた専用のネットワークパスをオンデマンドで払い出す、End-to-End のきめ細かな制御が狙いです。 分散DC全体図-複数拠点をVXLAN/EVPNとAPNで繋ぐアーキテクチャ 一方で、この基盤を日常的に運用しているのは少数のメンバーです。求められるスキルの幅は極めて広く、 APN レイヤ ：波長・周波数、光送信/受信レベル、FEC Ethernet レイヤ ：ブリッジング、RoCEv2、VLAN IP レイヤ ：ルーティング、VXLAN/EVPN、Multi-site といった、複数レイヤの深い知識が同時に必要になります。この「厳しい運用の現実」を出発点に、私たちは 属人依存 → スキルレス → 自律運用 という段階を描きました。まず一般スキルの運用者でも扱えるスキルレス基盤を開発し、その先でAI エージェントによる自律運用につなげることが、本取り組みの目的です。 2. 分散DC運用の課題 ― マルチレイヤ・マルチベンダ・可視化分断 分散DCの運用が難しいのは、単体でも複雑な設定が 組み合わさる ことで、さらに難易度が跳ね上がるためです。課題は大きく 3 つの軸に整理できます。 マルチレイヤ ：光波長パスの設定（物理構成に依存するパラメータや光レイヤ特有の概念）と、VXLAN オーバーレイの設定、そして両者をマッピングする分散 DC 特有の設定が、それぞれ別々の理解と対応を要求します。 マルチベンダ ：ベンダごとに設定方法が分かれ、一括変更ができず、自動ロールバックも効きません。設定順序への依存もあり、途中で失敗すると復旧が複雑になります。 可視化分断 ：設定情報やライブステータスがレイヤ・ベンダごとにサイロ化し、End-to-End 視点での状態把握や迅速な障害分析が困難です。 これらを解消する鍵として、私たちは ①マルチレイヤ制御統合API、②トランザクションの一括管理、③情報取得一元化API の 3 点を柱に据えました。 3. 解決アプローチ ― コントローラAPIによるスキルレス基盤 3 つの柱を、それぞれコントローラ API として実装しました。ここでは実装の詳細ではなく、考え方（抽象化の狙い）を中心にご紹介します。 3つの課題とスキルレス基盤の3要素 マルチレイヤ制御統合API 光波長パスと VXLAN オーバーレイの設定を抽象化し、共通モデルで API 化しました。運用者（および AI）は、物理構成に依存する煩雑なパラメータを意識することなく、 「どの拠点間を、どのインタフェースで、どう結ぶか」といった少数のパラメータ を指定するだけで設定できます。物理構成情報はコントローラ側の構造化データベースに保持し、API 側でマッピングすることでシンプル化を実現しています。 トランザクションの一括管理 複数ベンダ・複数機器にまたがる設定は、コントローラ側でトランザクションの一貫性を確保します。 機器設定は1 台ずつ順番に実施し、すべての機器設定が完了するまでトランザクションを終了させません。途中でエラーが発生した場合は、それまでに設定した機器を逆順でロールバック します。これにより、設定途中の不整合や、部分失敗時の復旧の複雑さを回避します。 情報取得一元化API 設定情報（End-to-End の光波長パスやオーバーレイ構成、トポロジ）と、各機器のライブステータス（光の送受信パワー、インタフェース情報、統計、アラーム、L2/L3 の状態など）を、 レイヤやベンダに依存しない共通の API から一元的に取得 できるようにしました。取得方法の違いをコントローラが吸収するため、利用者は統一されたインタフェースで End-to-End の状態を把握できます。 4. スキルレス基盤はAI エージェントの実行基盤になるか ここが本取り組みの中心となる仮説です。 人のために用意した「シンプルさ」は、そのまま AI エージェントの推論エラーリスクを下げる のではないか、という問いです。 AI エージェントに運用を任せる際に懸念されるのは、パラメータの誤り、API の取り違え、設定対象機器や順序の間違い、取得情報の誤りといった「判断ミス」です。スキルレス基盤の 3 要素は、これらの余地を構造的に小さくします。 統合され、少数パラメータに抽象化された API ：パラメータや API を誤る可能性が低い 対象機器は API のパラメータから自動特定 ：AI が機器や順序を個別に指定しないため、投入ミスが起きにくい 一元化された取得 API ：取得方法がレイヤ・ベンダに依存せず、取得ミスが起きにくい つまり、「人にとって扱いやすい基盤」を突き詰めることが、「AI にとって誤りにくい基盤」に一致する ―― これが私たちの立てた仮説です。 スキルレス基盤とAIの推論エラーリスク低減 5. 比較検証 ― 属人/スキルレス/AI エージェントの 3 パターン 仮説を確かめるため、VXLAN オーバーレイ設定を題材に、3 つの運用パターンを比較しました。 パターン 運用者 設定方法 設定ボリューム 必要スキル ① 高スキル保持者 従来どおり（CLI/Web GUI） 多（100行、設定対象スイッチ4台） VXLAN/EVPN Multi-site の専門スキル ② 一般スキル運用者 スキルレス基盤（コントローラ API）を使用 少（7パラメータ、コントローラAPI のみ） コントローラ API の使い方 ③ AI エージェント スキルレス基盤（コントローラ API）を使用 少（7パラメータ、コントローラAPI のみ） 不要 結果は以下のとおりです。 パターン 事前確認 設定 事後確認 トータル 考察 ① 5分 6分 8分 19分 - 高スキル保持者は手順を熟知しており、CLI操作が高速 - 「どこを見るか」を即座に判断でき、事前確認が短い ② 7分 8分 7分 22分 - 事前確認・設定も手順書どおり実施するため、時間がかかる - スキルに依存せず、一般スキルの運用者でも実施可能という別の価値がある ③ - - - 8分 - 設定、事前・事後確認をSkillsに基づき自律的に実行 - スキルレス基盤の上で、AIが高速かつ正確に動作できた ※③は事前確認から事後確認までを連続して実行するため、工程別の時間は計測していません。8分は自然言語で指示してから事後確認が完了するまでの時間で、人による確認の時間を含みます。 検証を通じて得られた考察は次の通りです。 パターン②（一般スキル運用者） は、手順書どおりに事前確認・設定・事後確認を進めるため、時間はかかります。一方で、 高スキル保持者と同等の品質 を、スキルに依存せずに実現できるという価値があります。 パターン③（AI エージェント） は、Skills に基づいて事前確認から設定・事後確認までを自律的に実行しました。事後確認の全項目が期待どおりの結果となり、設定誤りや手戻りも無かったことから、 高スキル保持者と同等の品質を、人手より短い時間で 達成できたと判断しています。スキルレス基盤の上で、AI が高速かつ正確に動作できることを確認しました。 VXLAN オーバーレイ設定を題材にした今回の検証では、スキルレス基盤を土台とした AI エージェント化によって、品質とスピードを両立できることを確認しました ―― これが検証から得られた結論です。 6. AI エージェントデモ ― NSO × MCP × Skills 実際のデモでは、Cisco NSO をコントローラの中核に据え、AI エージェント（マルチエージェント構成）と組み合わせました。全体像は次の通りです。 コントローラ（Cisco NSO） ：前章までのスキルレス基盤（統合API・トランザクション管理・情報取得API）を提供 MCP サーバー ：AI エージェントに、NSO の各機能（設定取得・コンフィグ作成・設定・ライブステータス取得）を実行ツールとして提供する基盤 Skills ：ネットワーク設定に必要な一連の作業（事前確認 → コンフィグ作成 → バリデーション → 設定 commit → 事後確認）を、再利用可能な手順として定義 マルチエージェントAIとコントローラの連携 デモでは、「 大阪と兵庫で VXLAN オーバーレイ 」といった自然言語の指示を起点に、Supervisor が Skills の手順を読み込み、各エージェントが情報取得・コンフィグ作成・設定実行・検証を分担しながら自律的にタスクを完了します。人間はループの中で確認（Human-in-the-Loop）を担い、AI と役割を分担する運用モデルを体現しました。 7. まとめ 課題 ：分散DC運用は属人化し、少数の高スキル人材に依存。マルチレイヤ・マルチベンダ・可視化分断で運用が複雑。 仮説 ：スキルレス基盤は AI エージェントの実行基盤になる。 解決アプローチ ：マルチレイヤ制御統合API（少数パラメータで設定）、トランザクションの一括管理（自動ロールバック）、情報取得一元化API（End-to-End で状態取得）。 検証結果 ：VXLAN オーバーレイ設定において、3 パターンとも同等の品質を確認。所要時間は高スキル保持者 19 分、一般スキル運用者 22 分、AI エージェント 8 分。 結論 ：今回の VXLAN オーバーレイ設定の検証から、スキルレス基盤が、人には「一般スキル運用者でもできる運用」を、AI には「速く正確な自律運用」をもたらすことが分かった。人のための自動化は、そのまま AI エージェント運用の土台になり得る。 「人のための自動化」を突き詰めることが、そのまま「AI エージェント運用への道」を拓く ―― 私たちはこの手応えを踏まえ、取り組みを障害対応や最適化といった領域、さらには他のネットワーク技術へと広げていきたいと考えています。 執筆者 芳 政信 （NTT西日本 デジタル革新本部 技術革新部 IOWN推進室） 造園土木職人からネットワークエンジニアへ転身。企業 VPN の詳細設計、社内ネットワークの運用管理、ネットワークインストラクタなどを経て、現在は IOWN に関する基盤技術の開発、ユースケース検証の実施などに従事しています。Model Driven Programmability/Network Programmability/DevNet が得意分野です。 鈴木 佑輔 （NTT西日本 デジタル革新本部 技術革新部 R&Dセンタ ネットワークサービス担当） キャリアネットワーク内で使われるシステムの開発・構築・運用に従事するサーバー寄りのエンジニア。サーバープラットフォームや監視・制御サーバーを担当。Markdown、サーバー仮想化、自動化、ガジェットが好きです。 参考資料・出典 本記事を執筆するにあたり、以下を参考にしました。 JANOG58 セッション「人のための自動化が AI エージェント運用への道を拓く ― IOWN APN × VXLAN/EVPN をまたぐマルチレイヤ抽象化の実践」 IOWN Global Forum PoC レポート 、および 当社の関連ニュースリリース（IOWN APN を活用した分散DCユースケース実証） 商標 「Cisco」「Cisco NSO」「Nexus」は、Cisco Systems, Inc. の米国およびその他の国における商標もしくは登録商標です。 「Claude」は、Anthropic, PBC の商標もしくは登録商標です。 「IOWN®」は、NTT株式会社の商標もしくは登録商標です。 記載の会社名・製品名は、それぞれの会社の商標もしくは登録商標です。 免責事項 本記事の内容は執筆時点の情報に基づく個人の見解を含み、所属組織の公式見解を示すものではありません。基本的な免責事項は https://engineers.ntt-west.co.jp/about に記載があります。

本ブログは 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 のガードレールの値に置き換えてください。 { "Version": "2012-10-17", "Statement": [ { "Sid": "AllowModelInvocationWithGuardrail", "Effect": "Allow", "Action": [ "bedrock:InvokeModel", "bedrock:InvokeModelWithResponseStream" ], "Condition": { "ArnEquals": { "bedrock:GuardrailIdentifier": "arn:aws:bedrock: <region> : <account-id> :guardrail/ <guardrail-id> : <guardrail-version> " } }, "Resource": "arn:aws:bedrock: <region> ::foundation-model/amazon.*" } ] } この新しい条件は SCP でも使用できます。例えば、次の SCP を使用すると、すべての直接的なモデル呼び出しで、いずれかのガードレールの使用を強制できます。 { "Version": "2012-10-17", "Statement": [ { "Sid": "DenyModelInvocationWithoutGuardrail", "Effect": "Deny", "Action": [ "bedrock:InvokeModel", "bedrock:InvokeModelWithResponseStream" ], "Resource": "*", "Condition": { "Null": { "bedrock:GuardrailIdentifier": "true" } } } ] } この 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 サポートにお問い合わせ ください。   Jonathan Jenkyn Jonathan (「JJ」) Jenkyn は、AWS Security Assurance Services の Sr Security Assurance Solution Architect です。30 年以上の経験を持つ実績あるセキュリティリーダーとして、堅牢なクラウドセキュリティを実現しています。JJ は AWS People with Disabilities アフィニティグループでも積極的に活動しており、ランニング、サイクリング、家族との時間を楽しんでいます。 Michael Tschannen Michael は、スイスを拠点とする AWS の EMEA Sr. Specialist SA Security です。キャリアの初期にペネトレーションテスターとして働いた後、防御側に転身しました。それ以来、自身が構築するすべてのソリューションにセキュリティとプライバシーを不可欠な要素として組み込み、日々お客様とそのデータを保護しています。 本ブログは Security Solutions Architect の 中島 章博 が翻訳しました。