Microsoft Foundry で押さえておきたい Azure リソースのセキュリティ設定まとめ
Azure においてAI を使ったシステムを構築する場合、モデルやエージェントの実行場所としてMicrosoft Foundry が使われます。AI のシステムにおいてもセキュリティは大事であり、事前に防げるものや何かあった時に調査を行える設定は押さえておきたいです。今回はMicrosoft Foundry で押さえておきたいAzure リソースのセキュリティ設定について、ネットワーク、認証・認可、データ暗号化、ガバナンス、ロギングのような観点で説明します。
10 July, 2026
前提条件、注意事項
- 本記事は2026年7月10日現在の内容となります。今後のアップデートにより仕様変更が発生することがあります。
- 一部プレビューの機能があるため、業務利用する場合はよく検討の上で使用してください
Microsoft Foundry におけるセキュリティ
Microsoft Foundry では、Azure リソースの管理を行うコントロールプレーンと モデル、エージェントの管理を行うデータプレーンに分かれます。コントロールプレーンはFoundry リソースやプロジェクトの作成、ネットワーク設定、診断ログ、RBAC、暗号化などを管理します。データプレーンは、モデル推論、エージェントの対話、評価ジョブ、Content Safety の呼び出しといった、実際のAI 機能を管理します。
今回はコントロールプレーンのセキュリティに絞って説明をします。
ネットワークセキュリティ
Microsoft Foundry では、Azure リソースに対するネットワークアクセス制御を構成できます。
| 設定 | 概要 | ユースケース |
|---|---|---|
| All networks | インターネット経由ですべてのアクセスを有効化する。 | 一時的な個人検証 |
| Selected networks and private endpoints | 指定した仮想ネットワークまたはIP アドレス、プライベートエンドポイントのみ接続可能とする。 | 長期的な個人検証、ネットワーク制限で許容されるシステム |
| Disabled | パブリックアクセスを無効化し、プライベートエンドポイントのみ接続可能とする。 | 閉域網を求められるシステム |
All Networks を除く各ネットワーク設定の違いは以下のイメージです。
これらの設定に加え、Microsoft Foundry のプロジェクトでは Managed Virtual Network (マネージド仮想ネットワーク) によるネットワーク分離を構成できます。プライベートエンドポイントの閉域と違い、Managed Virtual Network を利用すると、Foundry の Agent Service が利用する実行環境のアウトバウンド通信も Microsoft 管理のネットワーク境界内で制御できます。Agent の動作を含め完全な閉域網を作成したい場合に利用します。ただし、プライベート エンドポイントは主に Foundry エンドポイントへの受信経路を私設化する機能であり、エージェント実行環境の送信通信を自動的にすべて閉域化するものではありません。完全なネットワーク分離を求める場合は、Managed Virtual Network または BYO Virtual Network を利用し、ツールごとのネットワーク分離と必要な送信先を確認してください。
個人のちょっとした検証用途であれば All Networks でも気になりませんが、業務で使用する場合、AI による意図しないデータ漏洩や外部通信、外部 API の不正利用のようなリスクになります。また、個人でも機密性の高いデータを使用する場合は、すべてのネットワークを許可する設定は推奨されません。これらのリスクを最小限に抑えるため、Microsoft Foundry のネットワーク設定は基本的に特定のネットワークのみ許可するか、プライベート エンドポイント、ネットワークの分離を使った閉域空間を推奨します。
Microsoft Foundry のエンドポイントとの通信は HTTPS (TCP/443) で行うため、NSG を利用する場合は必要な通信許可を実施してください。プライベートエンドポイントを利用する場合は、プライベートDNS ゾーンを利用した名前解決が必要となるため、DNS サーバーへの通信経路が確保されていることを確認してください。
Microsoft Foundry のエージェントは Azure AI Search、Azure Storage、Azure Cosmos DB、Azure Functions、外部 API のような各種サービスと連携できます。そのため、接続先サービスに応じて必要な通信経路を許可する必要があります。エージェントに対し通信制御を行う場合は、NSG ではサービス タグや IP アドレス ベースで必要な通信を許可します。FQDN ベースで送信先を制御する場合は、Azure Firewall のアプリケーション ルールなどを使用し、必要な通信先へのアクセスが遮断されないようにしてください。
認証
認証の概要
Microsoft Foundry では Entra ID と API キーによる認証がサポートされています。Entra ID ではマネージド ID による詳細な RBAC の設定を行うことができ、API キーは詳細な RBAC の設定はできませんが、ちょっとした検証で素早く使うことができます。Microsoft Foundry のマネージド ID には、リソースに紐づくシステム割り当てマネージド ID と、独立したリソースとして付与できるユーザー割り当てマネージド ID があります。Microsoft Foundry のマネージド ID は、Azure リソースに対するシークレットレス認証や、エージェント ID のトークン交換を支える認証チェーンで利用されます。エージェント ID 認証に対応した MCP や A2A などのツールから Azure リソースを操作する場合、対象リソースに対する RBAC は原則としてエージェント ID に付与します。
Entra ID 認証とAPI キー認証の違いをまとめると以下のようになります。
| Entra ID 認証 | API キー認証 | |
|---|---|---|
| 容易性 | マネージド ID またはユーザー認証の設定と、Foundry への RBAC 設定が必要なため、初期設定はやや複雑 | エンドポイントと API キーのみで利用可能で、初期導入が非常に容易 |
| 機能・統合 | RBAC による細かなアクセス制御や、エージェントサービス連携、Managed Identity を用いた安全な接続が可能 | 認証は単純なキーによるアクセスのみ。RBAC 制御やエージェント単位の権限制御は利用不可 |
| 安全性 | 短期トークンベースの認証を使用し、キーの長期保存が不要。条件付きアクセスや MFA による高度なセキュリティポリシー適用が可能 | API キーが認証情報となるため、漏洩時に不正利用されるリスクが高い。キーは長期利用されやすい |
| 運用・管理 | ID (ユーザー / Managed Identity)、RBAC、条件付きアクセスなどを含めた統合的な管理が可能。監査ログやアクセス制御の中央管理が可能 | API キーの安全な保管と定期的なローテーションが必要。アクセス制御はキー単位となり柔軟性が低い |
| 監査・ガバナンス | Azure の監査ログ、Entra ID のサインインログ、RBAC によるアクセス履歴の追跡が可能 | 誰がアクセスしたかの識別が困難（キー共有時）。監査性が低い |
| ユースケース | 本番環境、企業システム、セキュリティやガバナンスが求められるシステム | PoC、開発初期段階、一時的な検証用途 |
個人の検証やちょっとしたプロトタイプを作りたい、くらいであればAPI キーでも問題ありませんが、実運用で最小のRBAC などを考慮した場合はマネージドID の認証が推奨されます。また、Entra ID 認証を行う場合、IaC のようにリソースの再作成や権限付与の変更を考慮する必要があります。複数のリソースで ID を共有する場合や、リソースを再作成しても同じプリンシパル ID を維持したい場合は、ユーザー割り当てマネージド ID が適しています。一方、単一リソース専用の ID としてリソースの削除にあわせて廃棄したい場合は、システム割り当てマネージド ID を利用できます。
以下は、Foundry リソースにユーザー割り当てマネージド ID を関連付け、ストレージ アカウントへの権限を付与する例です。エージェント ID 認証を使用するツールの場合は、マネージド ID ではなくエージェント ID に対象リソースの RBAC を付与する構成もあります。利用する認証方式とツールの仕様に応じて付与先を選択してください。
# ユーザー割り当てマネージドIDを作成する
az identity create \
--name id-foundry-test \
--resource-group rg-foundry-test \
--location japaneast
# ユーザー割り当てマネージドIDにRBACを付与する
# 例ではストレージアカウントに対するStorage Blob Data Contributor権限を付与する
az role assignment create \
--assignee-object-id $(az identity show \
--name id-foundry-test \
--resource-group rg-foundry-test \
--query principalId \
--output tsv) \
--assignee-principal-type ServicePrincipal \
--role "Storage Blob Data Contributor" \
--scope /subscriptions/00000000-0000-0000-0000-000000000000/resourceGroups/rg-foundry-test/providers/Microsoft.Storage/storageAccounts/stfoundrytest
# Microsoft Foundryにユーザー割り当てマネージドIDを付与する
UA_ID=$(az identity show \
--name id-foundry-test \
--resource-group rg-foundry-test \
--query id -o tsv) && \
RESOURCE_ID=$(az cognitiveservices account show \
--name aif-foundry-test \
--resource-group rg-foundry-test \
--query id -o tsv) && \
az rest --method PATCH \
--url "https://management.azure.com${RESOURCE_ID}?api-version=2024-10-01" \
--body "{
\"identity\": {
\"type\": \"SystemAssigned,UserAssigned\",
\"userAssignedIdentities\": {
\"${UA_ID}\": {}
}
}
}"
補足: エージェント ID
エージェント ID は、2025年5月のMicrosoft Buildでプレビューとして発表され、その後、2026年3月にFoundry Agent ServiceがGAとなったタイミングから利用できるようになりました。
Microsoft Foundry で最初の未公開エージェントを作成すると、プロジェクト内で共有するエージェント ID が自動的に作成されます。エージェントを公開すると、公開済みエージェント専用のエージェント ID が作成されます。エージェント ID の実体はサービス プリンシパルであり、RBAC や Entra ID ロールの割り当てが可能です。また、必要に応じて外部サービスへの認証に利用することもできます。
さらに、エージェント ID に対してもサインインログや監査ログが記録されるため、ユーザーと同様の方法でエージェントの動作やアクセス状況を追跡することができます。公開済みエージェントには新しい専用エージェント ID が割り当てられるため、開発中の共有エージェント ID に付与した RBAC は自動継承されません。公開時には、専用エージェント ID に必要な最小権限を再付与してください。
エージェント ID は、関連する Foundry プロジェクトまたは公開済みエージェントのエージェント アプリケーション リソースのライフサイクルに従って管理されます。公開済みエージェントを削除する場合は、関連リソースとエージェント ID の削除範囲を確認してください。
今回はAzure リソースに関する部分となるため細かい説明は省略しますが、エージェント ID について詳細を知りたい方は以下のドキュメントを参照してください。
Microsoft Foundry のエージェント ID の概念
認可 (RBAC)
Microsoft Foundry ではリソースにRBAC の権限を設定することで、ユーザーのFoundry ポータルの操作やアプリケーションの実行権限を管理できます。Foundry のRBAC については以下の権限があります。
| Azure ロール | 概要 | 付与対象 |
|---|---|---|
| Foundry Agent Consumer | 2026年6月頃に登場した公開済みエージェントのエンドポイント実行を行う権限。Foundry ポータルの閲覧権限は無いため、エージェントを実行したいだけの場合に不必要な権限付与を抑えられる。エージェントを直接実行するユーザーやマネージドID を介したエージェントの実行のみを行う場合に使用する。 | エージェントを直接呼び出したいユーザー、Bot 用のマネージドID |
| Foundry User | Foundry ポータルを使用し、モデルのデプロイ、ガードレールの設定、エージェントの公開のような管理操作はできない。 | Foundry でモデル、エージェントの開発を行う開発者 |
| Foundry Project Manager | Foundry User の権限にエージェントの公開とFoundry User 権限の付与をできる権限。Foundry User 同様にモデルのデプロイやガードレールの設定はできない。 | チームリーダーのような開発管理者 |
| Foundry Account Owner | Foundry プロジェクトの作成やモデルのデプロイ、権限付与 (Container Registry Contributor and Data Access Configuration Administrator、Foundry User、Log Analytics Reader) を行える。エージェントの作成や公開はできない。 | Foundry プロジェクト、モデルのデプロイを管理する開発のマネージャーやインフラ管理者 |
| Foundry Owner | Foundry で全ての操作が可能となる。Foundry プロジェクト作成のようなAzure リソースが関連する操作はAzure RBAC が必要。 | IT 管理者またはFoundry での緊急用ユーザー |
Foundry で主に開発を行うメンバーには Foundry User を使い、モデルのデプロイやエージェントの公開といった承認が必要になりそうな操作はチームリーダーやマネージャーに付与します。Foundry Owner は強い権限となるため、全体を管理する管理者や緊急用のアカウントとして使用します。
RBAC 付与の注意点は、Foundry のデータプレーン ロールだけでは、すべての Azure リソース管理操作を実行できないことです。ネットワーク、診断設定、外部リソース、ロール割り当てなどの操作では、対象リソース・対象スコープに応じた Azure RBAC 権限が別途必要となります。最小権限で抑える場合は、実施する操作ごとに Azure リソース側の必要権限が不足していないか確認の上で設定してください。
データ暗号化
Microsoft Foundry はデフォルトでMicrosoft Managed Keys (MMK) でデータの暗号化が行われます。加えて、要件に合わせた独自のCustomer Managed Keys でデータの暗号化を行うこともできます。
CMK では、最小 2048 bit の RSA キーを使用します。キーの格納先には Azure Key Vault または Azure Managed HSM を使用できます。サポートされるキーの種類、サイズ、リージョンは更新されるため、構成時には最新の公式ドキュメントを確認してください。Key Vault または Managed HSM を使用する場合は、以下の条件が必要となります。
- Microsoft Foundry リソースと同じリージョンに Key Vault または Managed HSM があること
- Key Vault または Managed HSM で論理的な削除と消去保護が有効であること
- Microsoft Foundry でシステム割り当てマネージド ID またはユーザー割り当てマネージド ID が有効であること
- Azure RBAC を使用する Key Vault では、Microsoft Foundry のマネージド ID に
Key Vault Crypto Userロールが付与されていること - Key Vault のアクセス ポリシーを使用する場合は、Microsoft Foundry のマネージド ID に
wrapKeyとunwrapKeyなどの必要なキー権限が付与されていること - Managed HSM を使用する場合は、Microsoft Foundry のマネージド ID に
Managed HSM Crypto Userロールが付与されていること
Foundry プロジェクトで CMK を有効化した後は、Microsoft マネージド キーに戻すことはできません。暗号化方式を戻すには、対象の Foundry リソースまたはプロジェクトを再作成する必要があるため注意してください。
CMK は一部の業界で扱われる規制や監査要件がある場合は必要ですが、それ以外はデフォルトのMMK の設定で十分です。CMK の設定は、Azure Storage、Azure AI Search、Azure Cosmos DB などの依存リソースへ自動的に継承されません。これらのリソースでも CMK が必要な場合は、各リソースで個別に暗号化設定を構成してください。キーの暗号化について詳細な情報を知りたい方は以下のドキュメントを参照してください。
データ暗号化モデル
監査・ログ、メトリクス、トレース収集
Microsoft Foundry では Azure リソースのログ、メトリクスを取得できる Azure Monitor 診断設定と、エージェントの動作に関連する情報を取得する Application Insights を設定できます。実運用ではセキュリティに関するさまざまな情報を取得できるため、診断設定と Application Insights の両方を設定します。企業によって監査、ログの要件がある場合には、ストレージ アカウントへの保存も忘れずに実施してください。
診断設定
Microsoft Foundry の診断設定ではAzure リソースに関連する監査ログやモデルのリクエストに関するログ、メトリクスを設定できます。
| ログ/メトリクス/トレース | 概要 | セキュリティユースケース |
|---|---|---|
| Audit Log | Azure OpenAI キーの取得、Microsoft Foundry の設定変更、モデルのデプロイ操作、RBAC 変更のような管理操作を記録するリソースログ。診断設定を作成すると AzureDiagnostics テーブルにルーティングされ Log Analytics でクエリ可能。既定では収集されず、診断設定の作成が必要。 |
特権操作の監査、不正な設定変更の検知、RBAC 変更の追跡によるアクセス権限の不正付与の検知。 |
| Request and Response Logs | モデル呼び出しや組み込み API 呼び出しに関する操作、呼び出し日時、応答コード、レイテンシーなどを記録するリソースログ。プロンプトや応答本文の記録可否・内容は、対象サービスとログ設定の仕様に依存する。診断設定を作成すると AzureDiagnostics テーブルにルーティングされ Log Analytics でクエリ可能。既定では収集されず、診断設定の作成が必要。 |
呼び出し元、操作、応答コード、呼び出し頻度、レイテンシーなどのメタデータを用いた、不正アクセスや異常な呼び出しパターンの調査・検知。 |
| Azure OpenAI Request Usage | Prompt Tokens、Completion Tokens など、モデル呼び出しごとのトークン消費量を記録するリソースログ。診断設定を作成すると AzureDiagnostics テーブルにルーティングされ Log Analytics でクエリ可能。エクスポートに料金が発生する。 |
モデルの不正使用 (過剰なトークン消費によるコスト攻撃、割り当て枯渇を狙った悪用) の検知。 |
| Trace Logs | サービス内部の処理過程を記録するトレースログ。カスタムの質問応答機能を使用した場合にのみ生成される。 診断設定を作成すると AzureDiagnostics テーブルにルーティングされ Log Analytics でクエリ可能。既定では収集されず、診断設定の作成が必要。 |
カスタム質問応答機能利用時における不審な処理・想定外の内部動作の調査。 |
| AllMetrics | リクエスト数、レイテンシー、エラーレート (4xx/5xx)、可用性率など、リソースの全プラットフォームメトリクスをまとめて収集するカテゴリ。診断設定でメトリクスエクスプローラーおよび Log Analytics の両方にルーティング可能。既定でメトリクスエクスプローラーには自動収集されるが、Log Analytics へのルーティングには診断設定の作成が必要。 | リクエスト数急増やエラーレート上昇の監視による DoS 攻撃・レート制限突破・不正アクセスの検知。 |
Trace Logs はカスタム質問応答機能を使用するケースであれば取得します。Foundry Agent Service のエージェント動作を調査する目的では、診断ログとは別に Application Insights と OpenTelemetry によるトレース設計を検討してください。
Application Insights
Microsoft Foundry ではエージェントに Application Insights を関連付けることで、エージェントのトレース、品質に関するログ、メトリクスを取得できます。取得できるテレメトリは、利用する機能、OpenTelemetry の計装、構成に依存します。プロンプトやモデル出力などのメッセージ内容は、明示的に内容記録を有効化した場合に収集対象となるため、機密情報の取り扱いに注意してください。また、Application Insights を設定することで、Azure portal の Agent ダッシュボードから関連項目を閲覧可能になります。主に可観測性のために取得する項目が多くありますが、セキュリティに関連する項目もいくつか取得できます。
| ログ/メトリクス/トレース | 概要 | セキュリティのユースケース |
|---|---|---|
| Foundry Tracing (エージェントトレース) | Application Insights に OpenTelemetry 準拠で保存される、ツール呼び出しや実行メタデータ (タイムスタンプ・レイテンシ・トークン使用量・エラーなど) を含む会話単位のトレース。プロンプト、ユーザー入力、モデル出力などのメッセージ内容が記録されるかは、OpenTelemetry の計装と内容記録の設定に依存する。プロジェクトに Application Insights を接続するとトレースを収集でき、Log Analytics の traces、dependencies などのテーブルでクエリ可能。 |
メタデータを用いた異常なツール呼び出しパターンの調査、ならびに内容記録を明示的に有効化した限定環境でのプロンプト インジェクションや機密情報送信のフォレンジック。閲覧には Log Analytics Reader、保護テーブル設定時は Privileged Monitoring Data Reader ロールが必要。 |
| Risk and Safety Evaluators (Hate and Unfairness / Sexual / Violence / Self-Harm) | サンプリングされたエージェント応答に対し、有害カテゴリごとのスコアを算出する評価機能。対応する評価または継続的監視を構成した場合に、Foundry ポータルの Agent Monitoring Dashboard (Monitor タブ) で確認できる。 | 本番トラフィックにおける有害コンテンツ生成を継続監視し、組織で定めたしきい値に基づいてアラートを構成する。 |
| Indirect Attack (XPIA) | 取得コンテキスト経由の間接的なジェイルブレイク (プロンプトインジェクション) への耐性を評価。Agent Monitoring Dashboard でのみ閲覧可能。 | RAG 構成でのプロンプトインジェクション攻撃の検知・監視。 |
| Sensitive Data Leakage | エージェントが機密情報を漏えいする脆弱性を評価。Agent Monitoring Dashboard でのみ閲覧可能。 | 個人情報・機密情報の意図しない出力を検知し、データ漏えいリスクを監視。 |
| Prohibited Actions | 明示的に禁止された挙動へのエージェントの関与度を測定。Agent Monitoring Dashboard でのみ閲覧可能。 | ガードレール逸脱・許可されていない操作 (決済実行、権限昇格など) の兆候を検出。 |
| Code Vulnerability | 生成されたコード内のセキュリティ上の問題を検出。Agent Monitoring Dashboard でのみ閲覧可能。 | コード生成エージェントが脆弱なコード (インジェクション、認証不備など) を出力していないか監視。 |
| Tool Call Accuracy / Tool Input Accuracy / Tool Call Success | ツール呼び出しの選択・パラメーター正確性・実行成功率を評価。Agent Monitoring Dashboard でのみ閲覧可能。 | 意図しない/不正なツール実行 (権限外 API 呼び出しなど) の検知。 |
| Run success rate | エージェント実行の成功率。Agent Monitoring Dashboard の要約カードとして表示。 | ワークロードごとに定めた SLO や通常時のベースラインからの異常な低下を検知する。 |
| Latency | エージェント応答のレイテンシ。Agent Monitoring Dashboard の要約カードとして表示。 | ワークロードごとに定めた SLO や通常時のベースラインからの異常な増加を検知する。 |
| Token usage | エージェントトラフィックのトークン消費量。Agent Monitoring Dashboard の要約カードとして表示。 | 異常なトークン消費急増 (コスト攻撃、乱用、DoS 的挙動) の検知。 |
| Red teaming results (preview) | スケジュール実行されるアドバーサリアルテスト (データ漏えい・禁止行動など) の結果。失敗はセキュリティリスクを示す。Agent Monitoring Dashboard でのみ閲覧可能。 | 定期的な自動レッドチーム演習でエージェントの脆弱性を継続的に発見・是正。 |
| Alerts (latency / token usage / evaluation scores / red team findings) (preview) | 対応するメトリクス、評価結果、レッドチーム機能に対するしきい値ベースのアラート設定。利用する機能を構成し、対象リージョンで利用可能な場合に Monitor 設定パネル (ダッシュボード) で構成・確認できる。 | セキュリティ・品質異常のリアルタイム検知と対応の迅速化。 |
Content recording (OTEL_INSTRUMENTATION_GENAI_CAPTURE_MESSAGE_CONTENT) |
ユーザーメッセージ、ツール呼び出し引数、モデル出力の内容をスパンに記録するオプション設定。Log Analytics 上のトレースデータの一部として保存・クエリ可能。 | 本番では機密情報混入リスクがあるため既定で無効。開発環境でのプロンプトインジェクション・データ漏えい調査に限定利用すべき項目として監視対象化。 |
| Trace context propagation / baggage | Azure OpenAI 呼び出しへの分散トレースコンテキスト伝播。baggage には任意のキー値 (ユーザー識別子など) が含まれ得る。Log Analytics 上のトレースデータの一部として保存・クエリ可能。 | サービス間呼び出しの相関分析。baggage 経由の機密情報漏えいリスクの監査対象。 |
これらの評価結果やアラートは、対応する評価、継続的監視、またはレッドチーム機能を構成した場合に取得できます。利用可否、プレビュー状態、対象リージョン、取得できるデータは機能により異なります。
Application Insights をエージェントに設定した場合、Azure portal の Agent に関するダッシュボードで情報を確認できます。
Application Insights はセキュリティだけではなくエージェントの品質調査にも使用するため、実運用では設定するようにしてください。また、Application Insights のログ情報を保存する要件がある場合は Application Insights に診断設定を行い、ストレージ アカウントにもログを転送するように設定してください。
プレビュー機能の無効化
Microsoft Foundry では、AZML_DISABLE_PREVIEW_FEATURE=true タグを設定することで、Foundry ポータル上のプレビュー機能を非表示にできます。タグを設定していない場合、プレビュー機能の抑制は行われません。
- キー：AZML_DISABLE_PREVIEW_FEATURE
- 値：true
Azure CLI で設定する場合は以下のコマンドとなります。
# Foundryポータルのプレビュー機能の無効化タグを設定する
az tag update \
--resource-id $(az cognitiveservices account show \
--name aif-foundry-test \
--resource-group rg-foundry-test \
--query id -o tsv) \
--operation merge \
--tags AZML_DISABLE_PREVIEW_FEATURE=true
タグ付けによる制御は、Foundry ポータル上のプレビュー機能を非表示にするためのものです。API レベルで特定機能の操作を制限するには、カスタム ロールで対応する dataActions、または Azure Monitor を利用するトレースなどでは actions を除外する必要があります。機能によっては個別の操作を制限できない場合や、対応する権限が変更される場合があるため、最新の公式ドキュメントで対象機能とアクセス許可を確認してください。
企業によってFoundry ポータルからプレビュー機能を制限したいケースがある場合には、タグの設定で一定の抑止をすることはできます。Foundry はプレビュー機能でも便利な機能もあるため、業務要件が無い場合は無理に設定する必要はありません。
まとめ
- 業務利用の場合、All Networks 以外を使いインターネットから自由に接続できないよう制限する。
- 認証は一時的な検証を除きEntra ID 認証 (マネージドID) を使用する。
- RBAC はモデル、エージェントで何を使用するか、開発者でどのようにつけるか検討して最小権限を付与する
- データ暗号化は業界特有の暗号化要件がある場合はCustomer Managed Keys (CMK) を使い、特に要件が無いようであればMicrosoft Managed Keys を設定する。
- 不審なアクセスや攻撃を検知するため、Azure Monitor の診断設定とApplication Insights を設定し、必要に応じてLog Analytics、ストレージアカウントに保存する
- 本番環境でプレビュー機能を無効化するにはMicrosoft Foundry リソースで AZML_DISABLE_PREVIEW_FEATURE = true のタグを設定する。
参考資料
- Foundry Agent Service のネットワーク オプション
- Foundry Agent Service のプライベート ネットワークを設定する
- Microsoft Foundry での認証と承認
- Microsoft Foundry のロールベースのアクセス制御
- 暗号化用のカスタマー マネージド キー
- Microsoft Foundry の診断ログを有効にする
- 生成 AI アプリケーションを監視する (プレビュー) (クラシック)
- Microsoft Foundry でプレビュー機能を無効にする
- Microsoft Foundry の Azure セキュリティ ベースライン
- az cognitiveservices account