Ověřování a autorizace v Microsoft Foundry

Ověřování a autorizace v Microsoft Foundry řídí, jak subjekty prokazují identitu a získávají oprávnění k vykonávání operací. Foundry rozděluje operace na kontrolní rovinu (správu prostředků) a datovou rovinu (využití runtime), přičemž každá z nich má vlastní ověřování a řízení přístupu založeného na rolích (RBAC).

Foundry podporuje dvě metody ověřování: Microsoft Entra ID a klíče rozhraní API. Microsoft Entra ID umožňuje podmíněný přístup, spravované identity a podrobné řízení přístupu na základě rolí (RBAC). Klíče rozhraní API zůstávají dostupné pro rychlé vytváření prototypů, ale chybí sledovatelnost jednotlivých uživatelů. Tento článek porovnává tyto metody, mapuje identity na role a popisuje běžné scénáře s nejnižšími oprávněními.

Důležité

Použijte Microsoft Entra ID pro produkční úlohy k povolení podmíněného přístupu, spravovaných identit a řízení přístupu na základě principu nejnižších oprávnění. Klíče rozhraní API jsou vhodné pro rychlé vyhodnocení, ale poskytují hrubě definovaný přístup.

Předpoklady

Předplatné Azure. Pokud ho nemáte, vytvořte bezplatný účet.
Prostředek Microsoft Foundry s nastavenou vlastní subdoménou custom.
Znalost konceptů Azure RBAC.
Pro přiřazení rolí potřebujete roli Owner nebo roli Správce přístupu uživatele v příslušném oboru.
(Volitelné) Sada SDK Azure CLI nebo Azure SDK pro Python nainstalovaná pro programové ověřování.
(Volitelné) Balíčky Pythonu pro ukázky kódu: pip install azure-identity requests

Řídicí rovina a rovina dat

Azure operace se dělí do dvou kategorií: řídicí rovina a rovina dat. Azure odděluje správu prostředků (řídicí úroveň) od provozního běhového prostředí (datová rovina). Proto použijete řídicí rovinu ke správě prostředků ve vašem předplatném a datovou rovinu k využití schopností, které poskytuje vaše instance určitého typu prostředku. Další informace o řídicí rovině a rovině dat najdete v tématu Azure řídicí roviny a roviny dat. Ve Foundry existuje jasný rozdíl mezi operacemi řídicí roviny a operacemi roviny dat. Následující tabulka vysvětluje rozdíl mezi oběma, rozsah v Foundry, typické operace uživatele, příkladné nástroje a funkce, a autorizační rozhraní pro použití každého z nich.

Letadlo	Rozsah v Foundry	Typické operace	Ukázkové nástroje	Oblast autorizace
Úroveň řízení	Nastavení a konfigurace prostředků, projektů, sítí, šifrování a připojení	Vytváření nebo odstraňování prostředků, přiřazování rolí, obměna klíčů, nastavení Private Link	Azure portal, Azure CLI, šablony ARM, Bicep, Terraform	Akce RBAC v Azure
Datová vrstva	Spouštění a používání odvozování z modelů, interakce s agenty, úlohy vyhodnocení a volání bezpečnosti obsahu	Dokončování chatu, generování vkládání, spouštění úloh vylaďování, odesílání zpráv agenta, analyzátor a operace klasifikátoru	SDKs, rozhraní API REST, testovací prostředí portálu Foundry	datové akce Azure RBAC

Všechny ukázky Bicep, Terraform a SDK najdete v úložišti foundry-samples na webu GitHub for Foundry.

Následující seznamy a diagram znázorňují detailně oddělení mezi řídicí rovinou a akcemi roviny dat. Akce řídicí roviny v Foundry zahrnují:

Vytváření prostředků Foundry
Vytváření projektu Foundry
Vytvoření hostitele schopností účtu
Vytvoření hostitele se schopnostmi projektu
Nasazení modelu
Vytvoření připojení účtu a projektu

Akce datové roviny v rámci Foundry zahrnují:

Vytvoření agentů
Spuštění vyhodnocení
Trasování a monitorování
Jemné doladění

Následující diagram znázorňuje pohled na oddělení řídicí roviny a roviny dat ve Foundry společně s přiřazeními řízení přístupu na základě rolí (RBAC) a tím, jaký přístup může mít uživatel v řídicí rovině, v rovině dat nebo v obou. Jak je vidět v diagramu, rBAC "actions" jsou přidružené k řídicí rovině, zatímco RBAC "dataActions" jsou přidružené k rovině dat.

Metody ověřování

Foundry podporuje Microsoft Entra ID (klíče založené na tokenech, bez klíčů) a klíče rozhraní API.

Microsoft Entra ID

Microsoft Entra ID používá nosné tokeny OAuth 2.0 omezené na https://ai.azure.com/.default.

Použijte Microsoft Entra ID pro:

Produkční úlohy.
Podmíněný přístup, vícefaktorové ověřování (MFA) a přístup jen včas.
Integrace RBAC s nejnižšími oprávněními a spravovaná identita

Výhody: Jemné odstupňování rolí, auditování podle subjektu, kontrolovatelné životnosti tokenů, automatizované řízení tajných dat a spravované identity pro služby.

Omezení: Vyšší složitost počátečního nastavení. Vyžaduje pochopení řízení přístupu na základě rolí (RBAC). Další informace o RBAC v Foundry najdete v tématu Řízení přístupu založené na rolích pro Microsoft Foundry.

Klíče rozhraní API

Klíče rozhraní API jsou statická tajemství vymezená pro prostředek Foundry.

Použijte klíče rozhraní API pro:

Rychlé vytváření prototypů
Izolovaná testovací prostředí, kde je přijatelné obměně s jedním tajným kódem.

Výhody: Jednoduché, jazykové nezávislé a nevyžadují získání tokenu.

Omezení: Nejde vyjádřit identitu uživatele, je obtížné určit rozsah podrobností a je obtížnější auditovat. Obecně nejsou přijímány podnikovými produkčními úlohami a nedoporučuje je Microsoft.

Další informace o povolení ověřování bez klíčů najdete v tématu Konfigurování ověřování bez klíčů pomocí Microsoft Entra ID.

Ověřování pomocí Microsoft Entra ID (Python)

Následující příklad ukazuje, jak se ověřit pomocí Microsoft Entra ID pomocí knihovny azure-identity a provést požadavek na koncový bod 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())

Očekávaný výstup: Odpověď JSON s výpisem nasazení modelu nebo chyba ověřování, pokud chybí přihlašovací údaje nebo přiřazení role není nakonfigurované.

Referenční informace: DefaultAzureCredential | azure-identity library

Ověřování pomocí klíče rozhraní API (Python)

Následující příklad ukazuje, jak provést ověření pomocí klíče rozhraní API. Tento přístup použijte pouze pro rychlé vytváření prototypů; Microsoft Entra ID se doporučuje pro produkční prostředí.

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())

Výstraha

Klíče rozhraní API poskytují úplný access prostředku a nemůžou být omezené na konkrétní uživatele nebo akce. Klíče pravidelně obměňujte a vyhněte se jejich uložení do správy zdrojového kódu.

Očekávaný výstup: Odpověď JSON s výpisem nasazení modelu nebo chyba 401, pokud je klíč rozhraní API neplatný.

Reference: Rotace přístupových klíčů rozhraní API

Matice podpory funkcí

V následující matici najdete informace o tom, jaké schopnosti v Foundry podporují klíč rozhraní API versus Microsoft Entra ID.

Schopnost nebo funkce	klíč rozhraní API	Microsoft Entra ID	Poznámky
Základní odvozování modelů (chat, vkládání)	Ano	Ano	Plně podporováno.
Dolaďovací operace	Ano	Ano	Entra ID přidává audit na úrovni jednotlivých subjektů.
Služba Agenti	Ne	Ano	Pro přístup k nástrojům pro spravované identity použijte ID Entra.
Evaluations	Ne	Ano	Použijte ID Entra.
Analýza hovorů týkajících se bezpečnosti obsahu	Ano	Ano	RBAC použijte k omezení vysoce rizikových operací.
Úlohy dávkové analýzy (Porozumění obsahu)	Ano	Ano	Pro škálování je doporučeno Entra ID.
Využití dětského hřiště portálu	Ano	Ano	Playground používá režim připojení projektu.
Izolace sítě pomocí Private Link	Ano	Ano	Entra ID přidává podmíněný přístup.
Minimální oprávnění s předdefinovanými a vlastními rolemi	Ne	Ano	Klíče fungují podle principu vše-nebo-nic pro každý prostředek.
Spravovaná identita (systémově nebo uživatelsky přiřazená)	Ne	Ano	Povolí autentizaci bez tajných kódů.
Přiřazení uživatele podle žádosti	Ne	Ano	Token obsahuje ID tenanta a objektu.
Odvolání (okamžité)	Otočit klávesu	Odebrání role nebo zakázání účtu	Platí krátká životnost tokenu.
Podpora v automatizačních procesech	Ano (tajný kód)	Ano (služební principál nebo spravovaná identita)	Entra ID snižuje frekvenci rotace tajných klíčů.
Rozhraní API Asistentů	Ano	Ano	Doporučuje se použít ID Entra.
Dávkové odvozování	Ano	Ano

Typy identit

Azure prostředky a aplikace se ověřují pomocí různých typů identit, z nichž každý je určený pro konkrétní scénáře. cs-CZ: Uživatelské identity představují lidské uživatele, aplikační identity představují aplikace nebo automatizované procesy a spravované identity poskytují bezpečný způsob bez přihlašovacích údajů, jak umožnit Azure prostředkům přístup k jiným službám. Pochopení těchto rozdílů vám pomůže zvolit správnou identitu pro interaktivní přihlašování, komunikaci mezi aplikacemi nebo automatizaci úloh.

Azure podporuje následující typy identit.

Typ identityt	Description
Uživatelský identifikátor	Individuální uživatel v Microsoft Entra ID
Principál služby (registrace aplikace)	Identita aplikace, která používá tajný klíč klienta nebo certifikát
Spravovaná identita (přiřazená systémem)	Azure identita vázaná na prostředky, automaticky spravovaná platformou.
Spravovaná identita (přiřazená uživatelem)	Samostatná identita, která se přiřazuje k více prostředkům.

Přehled předdefinovaných rolí

Ve Foundry použijte předdefinované role k oddělení povolených akcí pro uživatele. Většina podniků chce oddělení akcí v ovládací a datové rovině pro své vestavěné role. Jiní očekávají, že kombinovaná role dat a řídicí roviny minimalizují požadovaný počet přiřazení rolí. Následující tabulka uvádí scénáře a odpovídající předdefinované role Foundry, které nejlépe vyhovují jednotlivým scénářům.

Scenario	Typické předdefinované role	Poznámky
Budujte agenty s předem nasazenými modely	Uživatel Azure AI	Pouze využití datové roviny; zápisy správy nejsou povoleny.
Správa nasazení nebo vyladění modelů	Azure AI Projektový manažer	Zahrnuje vytvoření a aktualizaci nasazení modelu.
Otočení klíčů nebo správa prostředků	vlastník účtu AI Azure	Vysoká oprávnění; zvažte vlastní roli podle zásady nejmenších privilegií.
Správa prostředků, správa nasazení, agentů sestavení	vlastník AI Azure	Vysoce privilegovaná samoobslužná role pro uživatele, kteří potřebují přístup k řídicí rovině i datové rovině. Pokud je vyžadována pozorovatelnost, zkombinujte s Čtečkou monitoringu Azure.
Pozorovatelnost, trasování, monitorování	Azure AI uživatel (minimální úroveň)	Přidání čtenáře Azure Monitor do Application Insights

Pokud chcete porozumět rozpisu předdefinovaných rolí a akcí řídicí roviny a roviny dat, projděte si následující diagram.

Návod

Pokud předdefinovaná role udělí nadbytečná oprávnění pro váš případ použití, vytvořte vlastní roli.

Nastavení Microsoft Entra ID

Základní pokyny k nastavení ověřování Entra ID v Foundry najdete v tématu Konfigurace ověřování bez klíče.

Ujistěte se, že váš prostředek Microsoft Foundry má nakonfigurovanou vlastní subdoménu. Vizte Vlastní subdomény. Pro ověřování na základě tokenu se vyžaduje vlastní subdoména.
Každému subjektu přiřaďte potřebnou integrovanou nebo vlastní roli. K přiřazení rolí potřebujete roli Owner nebo User Access Administrator v cílovém oboru. Běžná přiřazení rolí:
- Uživatel Azure AI: Pro vývojáře, kteří potřebují sestavovat a testovat s těmi předem nasazenými modely.
- Azure AI Project Manager: Pro vedoucí týmu, kteří potřebují vytvářet projekty a spravovat nasazení.
- Vlastník účtu Azure AI: Pro správce, kteří potřebují úplnou správu prostředků a mohou podmíněně přiřadit uživatele Azure AI pro přístup k rovině dat.
- Azure vlastník AI: Pro uživatele, kteří potřebují úplnou správu prostředků i přístup k rovině dat. Příklad příkazu rozhraní příkazového řádku pro přiřazení role uživatele Azure AI:
```
az role assignment create \
  --assignee <principal-id> \
  --role "Azure AI User" \
  --scope /subscriptions/<subscription-id>/resourceGroups/<resource-group>/providers/Microsoft.CognitiveServices/accounts/<resource-name>
```
Pokud chcete ověřit přiřazení role, spusťte az role assignment list --assignee <principal-id> --scope <resource-scope> a potvrďte, že se role zobrazí ve výstupu.
(Optional) Pro služební účet vytvořte registraci aplikace, přidejte klientský tajný klíč nebo certifikát a zaznamenejte si ID tenanta, ID klienta a tajný klíč nebo certifikát.
(Volitelné) U spravované identity povolte systémem přiřazenou identitu na volající službě, nebo připojte uživatelsky přiřazenou identitu a poté jí přiřaďte roli u prostředku Foundry.
Odeberte ověřování na základě klíčů, jakmile všichni volající začnou používat ověřování pomocí tokenu. Volitelně můžete v šablonách nasazení zakázat místní ověřování.

Reference: Assign Azure roles | Řízení přístupu na základě rolí pro Foundry

Řešení běžných chyb ověřování

Error	Příčina	Řešení
401 Neautorizováno	Chybějící nebo prošlý token; Neplatný klíč rozhraní API	Ověřte, že rozsah získání tokenu je `https://ai.azure.com/.default`. Znovu vygenerujte klíč rozhraní API, pokud používáte ověřování založené na klíči.
403 – Zakázáno	Chybějící přiřazení role RBAC	Přiřaďte odpovídající předdefinovanou roli (například Azure AI uživatele) na úrovni prostředku nebo projektové úrovni.
AADSTS700016	Aplikace nebyla v tenant nalezena.	Ověřte, že registrace aplikace existuje ve správném tenantovi a ID klienta je správné.
Vyžaduje se vlastní subdoména.	Prostředek používá místo vlastní subdomény regionální koncový bod.	Nakonfigurujte vlastní subdoménu na prostředku Foundry. Ověřování založené na tokenech vyžaduje vlastní subdoménu.

Váš názor

Byla tato stránka užitečná?

Last updated on 2026-03-11