Microsoft Foundry での認証と承認

Microsoft Foundry での認証と承認は、プリンシパルが ID を証明し、操作を実行するためのアクセス許可を取得する方法を制御します。 Foundry は、操作をコントロール プレーン (リソース管理) とデータ プレーン (ランタイムの使用) に分割し、それぞれに独自の認証とロールベースのアクセス制御 (RBAC) サーフェスを使用します。

Foundry では、Microsoft Entra ID と API キーの 2 つの認証方法がサポートされています。 Microsoft Entra ID を使用すると、条件付きアクセス、マネージド ID、詳細な RBAC が有効になります。 API キーは迅速なプロトタイプ作成に使用できますが、ユーザーごとの追跡可能性がありません。 この記事では、これらのメソッドを比較し、ID をロールにマップし、一般的な最小特権のシナリオについて説明します。

前提 条件

• Azure サブスクリプション。 お持ちでない場合は、 無料アカウントを作成してください。
• カスタム サブドメインが構成された Microsoft Foundry リソース。
• Azure RBAC の概念の理解。
• ロールを割り当てるには、適切なスコープで 所有者 ロールまたは ユーザー アクセス管理者 ロールが必要です。
• (省略可能)プログラムによる認証用にインストールされた Azure CLI または Azure SDK for Python 。
• (省略可能)コード サンプル用の Python パッケージ: pip install azure-identity requests

コントロール プレーンとデータ プレーン

Azure の操作は、コントロール プレーンとデータ プレーンという 2 つのカテゴリに分かれています。 Azure は、リソース管理 (コントロール プレーン) と運用ランタイム (データ プレーン) を分離します。 そのため、コントロール プレーンを使用してサブスクリプション内のリソースを管理し、データ プレーンを使用してリソースの種類のインスタンスによって公開される機能を使用します。 コントロール プレーンとデータ プレーンの詳細については、 Azure コントロール プレーンとデータ プレーンに関するページを参照してください。 Foundry では、コントロール プレーン操作とデータ プレーン操作は明確に区別されます。 次の表では、2 つの違い、Foundry のスコープ、ユーザーの一般的な操作、ツールと機能の例、それぞれを使用する承認画面について説明します。

Bicep、Terraform、SDK のすべてのサンプルについては、 GitHub for Foundry の foundry-samples リポジトリを 参照してください。

次の一覧と図は、コントロール プレーンアクションとデータプレーンアクションの分離を詳細に示しています。 Foundry 内のコントロール プレーン アクションは次のとおりです。

• Foundry リソースの作成
• Foundry プロジェクトの作成
• アカウントキャパビリティホストの作成
• プロジェクト機能ホストの作成
• モデルの展開
• アカウントとプロジェクトの接続の作成

Foundry 内のデータ プレーン アクションは次のとおりです。

• エージェントの構築
• 評価の実行
• トレースと監視
• 微調整

次の図は、Foundry でのコントロール プレーンとデータ プレーンの分離のビューと、ロールベースのアクセス制御 (RBAC) の割り当て、およびユーザーがコントロール プレーンまたはデータ プレーンまたはその両方で持つ可能性のあるアクセスを示しています。 図に示すように、RBAC "アクション" はコントロール プレーンに関連付けられますが、RBAC "dataActions" はデータ プレーンに関連付けられています。

認証方法

Foundry では、Microsoft Entra ID (トークンベース、キーレス) と API キーがサポートされています。

Microsoft Entra ID

Microsoft Entra ID では、 https://ai.azure.com/.defaultスコープの OAuth 2.0 ベアラー トークンが使用されます。

次の場合に Microsoft Entra ID を使用します。

• 運用ワークロード。
• 条件付きアクセス、多要素認証 (MFA)、Just-In-Time アクセス。
• 最小限の特権 RBAC とマネージド ID の統合。

利点: きめ細かなロールの割り当て、プリンシパルごとの監査、制御可能なトークンの寿命、自動シークレット管理、サービスのマネージド ID。

制限事項: 初期セットアップの複雑さが高くなります。 ロールベースのアクセス制御 (RBAC) を理解する必要があります。 Foundry の RBAC の詳細については、 Microsoft Foundry のロールベースのアクセス制御に関するページを参照してください。

API キー

API キーは、Foundry リソースをスコープとした静的シークレットです。

次の場合に API キーを使用します。

• ラピッドプロトタイピング。
• 単一シークレットローテーションが許容される分離されたテスト環境。

利点: シンプルで言語に依存せず、トークンの取得を必要としません。

制限事項: ユーザー ID を表現できない、きめ細かくスコープを設定することが困難、監査が困難です。 一般に、エンタープライズ運用ワークロードでは受け入れられないので、Microsoft では推奨されません。

キーレス認証を有効にする方法の詳細については、「 Microsoft Entra ID を使用してキーレス認証を構成する」を参照してください。

Microsoft Entra ID で認証する (Python)

次の例は、 azure-identity ライブラリを使用して Microsoft Entra ID で認証し、Foundry エンドポイントに要求を行う方法を示しています。

from azure.identity import DefaultAzureCredential
import requests

# Create a credential object using DefaultAzureCredential
# This automatically uses environment variables, managed identity, or Azure CLI credentials
credential = DefaultAzureCredential()

# Get an access token for the Cognitive Services scope
token = credential.get_token("https://ai.azure.com/.default")

# Use the token in your API request
headers = {
    "Authorization": f"Bearer {token.token}",
    "Content-Type": "application/json"
}

# Replace with your Foundry endpoint
endpoint = "https://<your-resource-name>.cognitiveservices.azure.com"

# Example: List deployments (adjust the path for your specific API)
response = requests.get(f"{endpoint}/openai/deployments?api-version=2024-10-21", headers=headers)
print(response.json())

予期される出力: モデルのデプロイを一覧表示する JSON 応答、または資格情報が不足しているか、ロールの割り当てが構成されていない場合の認証エラー。

リファレンス: DefaultAzureCredential | azure-identity ライブラリ

API キーを使用して認証する (Python)

次の例は、API キーを使用して認証する方法を示しています。 このアプローチは、迅速なプロトタイプ作成にのみ使用します。運用環境では Microsoft Entra ID をお勧めします。

import requests

# Replace with your actual API key and endpoint
api_key = "<your-api-key>"
endpoint = "https://<your-resource-name>.cognitiveservices.azure.com"

headers = {
    "api-key": api_key,
    "Content-Type": "application/json"
}

# Example: List deployments
response = requests.get(f"{endpoint}/openai/deployments?api-version=2024-10-21", headers=headers)
print(response.json())

予想される出力: モデルのデプロイを一覧表示する JSON 応答、または API キーが無効な場合は 401 エラー。

リファレンス: API アクセス キーのローテーション

機能サポート マトリックス

Foundry でサポートされている API キーと Microsoft Entra ID の機能を理解するには、次のマトリックスを参照してください。

ID の種類

Azure リソースとアプリケーションは、それぞれ特定のシナリオ向けに設計されたさまざまな ID の種類を使用して認証されます。 ユーザー プリンシパルは人間のユーザーを表し、サービス プリンシパルはアプリケーションまたは自動化されたプロセスを表し、マネージド ID は Azure リソースが他のサービスにアクセスするための安全で資格情報のない方法を提供します。 これらの違いを理解することは、対話型サインイン、アプリ間通信、またはワークロードの自動化に適した ID を選択するのに役立ちます。

Azure では、次の ID の種類がサポートされています。

組み込みロールの概要

Foundry で、組み込みロールを使用して、ユーザーに対して許可されるアクションを分離します。 ほとんどの企業では、組み込みロールの制御アクションとデータ プレーン アクションの分離が必要です。 他のユーザーは、必要なロールの割り当ての数を最小限に抑えるために、データとコントロール プレーンの役割を組み合わせることを期待しています。 次の表に、各シナリオに最適なシナリオと、対応する組み込みの Foundry ロールを示します。

組み込みロールの内訳と、コントロールとデータ プレーンのアクションを理解するには、次の図を確認します。

Microsoft Entra ID を設定する

Foundry で Entra ID 認証を設定する方法の概要については、「 キーレス認証の構成」を参照してください。

1. Microsoft Foundry リソースにカスタム サブドメインが構成されていることを確認します。 「カスタム サブドメイン」を参照してください。 トークン ベースの認証にはカスタム サブドメインが必要です。

2. 必要な組み込みロールまたはカスタム ロールを各プリンシパルに割り当てます。 ロールを割り当てるには、ターゲット スコープで 所有者 または ユーザー アクセス管理者 ロールが必要です。 一般的なロールの割り当て:

   • Foundry ユーザー: 事前にデプロイされたモデルを使用してビルドおよびテストする必要がある開発者向け。
   • Foundry Project Manager: プロジェクトを作成してデプロイを管理する必要があるチーム リーダー向け。
   • Foundry アカウント所有者: 完全なリソース管理を必要とし、データ プレーン アクセスに Foundry ユーザーを条件付きで割り当てることができる管理者向け。
   • Foundry Owner: すべてのリソースの管理とデータ プレーンへのアクセスの両方を必要とするユーザー向け。 Foundry ユーザー ロールを割り当てる CLI コマンドの例:

   az role assignment create \
     --assignee <principal-id> \
     --role "53ca6127-db72-4b80-b1b0-d745d6d5456d" \
     --scope /subscriptions/<subscription-id>/resourceGroups/<resource-group>/providers/Microsoft.CognitiveServices/accounts/<resource-name>
   

ロールの割り当てを確認するには、 az role assignment list --assignee <principal-id> --scope <resource-scope> を実行し、ロールが出力に表示されていることを確認します。

1. (省略可能)サービス プリンシパルの場合は、アプリの登録を作成し、クライアント シークレットまたは証明書を追加し、テナント ID、クライアント ID、シークレットまたは証明書をメモします。
2. (省略可能)マネージド ID の場合は、呼び出し元サービスでシステム割り当て ID を有効にするか、ユーザー割り当て ID をアタッチしてから、Foundry リソースでロールを割り当てます。
3. すべての呼び出し元がトークン認証を使用した後、キーベースの認証を削除します。 必要に応じて、デプロイ テンプレートでローカル認証を無効にします。

リファレンス: Foundry の Azure ロール | 割り当てる

一般的な認証エラーのトラブルシューティング

関連コンテンツ

• Foundry のロールベースのアクセス制御
• Microsoft Entra ID を使用してキーレス認証を構成する
• API アクセス キーをローテーションする
• Azure 組み込みロール (AI + 機械学習)
• 認証と承認 (Microsoft Entra ID)
• ID の基礎