Kontrola dostępu oparta na rolach dla usługi Microsoft Foundry

W tym artykule poznasz podstawowe pojęcia dotyczące kontroli dostępu opartej na rolach (RBAC) dla Microsoft Foundry, w tym zakresów, ról wbudowanych i typowych wzorców przypisywania w organizacjach.

Aby uzyskać więcej informacji na temat uwierzytelniania i autoryzacji w usłudze Microsoft Foundry, zobacz Authentication and Authorization.

Minimalne przypisania ról do rozpoczęcia pracy

Aby nowi użytkownicy Azure i Microsoft Foundry mogli rozpocząć, zacznij od tych minimalnych przypisań, aby zarówno tożsamość użytkownika, jak i tożsamość zarządzana projektu mogły uzyskiwać dostęp do funkcji Microsoft Foundry.

Bieżące przypisania można zweryfikować przy użyciu opcji Sprawdź dostęp użytkownika do pojedynczego zasobu Azure.

• Przypisz rolę Użytkownika usługi Foundry w zasobie usługi Foundry do podmiotu zabezpieczeń użytkownika.

  Ważna

  Niedawno zmieniono nazwy ról RBAC w usłudze Foundry. Użytkownik Foundry, właściciel Foundry, właściciel konta Foundry i menedżer projektu Foundry były wcześniej nazywane odpowiednio użytkownikiem Azure AI, właścicielem Azure AI, właścicielem konta Azure AI i menedżerem projektu Azure AI. Poprzednie nazwy mogą być nadal widoczne w niektórych miejscach, podczas gdy zmiana nazwy jest wdrażana. Identyfikatory ról i uprawnienia podstawowe są niezmienione przez zmianę nazwy.

• Przypisz rolę Użytkownika rozwiązania Foundry w zasobie foundry do tożsamości zarządzanej projektu.

• Jeśli użytkownicy muszą wyświetlić przydział lub uruchomić sprawdzenia kwalifikowalności wdrożenia, przypisz rolę Cognitive Services Usages Reader na poziomie subskrypcji. Aby uzyskać więcej informacji, zobacz Access quota and usage information (Informacje o limitach przydziału dostępu i użyciu).

Jeśli użytkownik, który utworzył projekt, może przypisywać role (na przykład mając rolę właściciela Azure w zakresie subskrypcji lub grupy zasobów), oba przypisania są dodawane automatycznie po utworzeniu projektu za pomocą interfejsu użytkownika portalu Microsoft Foundry.

Aby ręcznie przypisać rolę użytkownika usługi Foundry , wykonaj następujące szybkie kroki.

Przypisz rolę „Użytkownik usługi Foundry” do tożsamości użytkownika

W portalu Azure otwórz zasób usługi Foundry i przejdź do pozycji Kontrola dostępu (IAM). Utwórz przypisanie roli dla Foundry User, ustaw opcję Członkowie na Użytkownik, grupa lub nazwa główna usługi, wybierz swoją nazwę główną użytkownika, a następnie wybierz pozycję Przejrzyj i przypisz.

Przypisywanie roli użytkownika usługi Foundry do tożsamości zarządzanej projektu

W portalu Azure otwórz zasób usługi Foundry i przejdź do pozycji Kontrola dostępu (IAM). Utwórz przypisanie roli dla Foundry User, ustaw w polu Członkowie wartość Tożsamość zarządzana, wybierz tożsamość zarządzaną swojego projektu, a następnie wybierz pozycję Przejrzyj i przypisz.

Terminologia dotycząca kontroli dostępu opartej na rolach w rozwiązaniu Foundry

Aby zrozumieć kontrolę dostępu opartą na rolach w usłudze Microsoft Foundry, rozważ dwa pytania dotyczące przedsiębiorstwa.

• Jakie uprawnienia mają mieć mój zespół podczas kompilowania w usłudze Microsoft Foundry?
• W jakim zakresie chcę przypisać uprawnienia do mojego zespołu?

Aby uzyskać odpowiedzi na te pytania, poniżej przedstawiono opisy niektórych terminologii używanych w tym artykule.

• Uprawnienia: Dozwolone lub blokowane akcje, które tożsamość może wykonywać w zasobie, takie jak odczytywanie, zapisywanie, usuwanie lub zarządzanie operacjami płaszczyzny sterowania i płaszczyzny danych.
• Scope: zestaw zasobów Azure, do których ma zastosowanie przypisanie roli. Typowe zakresy obejmują subskrypcję, grupę zasobów, zasób usługi Foundry, projekt Foundry lub pojedynczego agenta.
• Role: nazwana kolekcja uprawnień definiująca, które akcje można wykonać na zasobach Azure w danym zakresie.

Tożsamość uzyskuje rolę z określonymi uprawnieniami w wybranym zakresie na podstawie wymagań przedsiębiorstwa.

W Microsoft Foundry należy wziąć pod uwagę następujące zakresy podczas wykonywania przypisań ról.

• Foundry resource: zakres najwyższego poziomu definiujący granicę administracyjną, zabezpieczenia i monitorowanie dla środowiska Microsoft Foundry.
• Foundry Project: podzakres w zasobie Foundry używany do organizowania pracy i wymuszania kontroli dostępu do interfejsów API, narzędzi oraz przepływów pracy deweloperskich.
• Agent: węższy zakres w projekcie Foundry, który ma zastosowanie do pojedynczego agenta. Przypisania ról w tym zakresie są obecnie brane pod uwagę tylko w przypadku dostępu do punktów końcowych agentów, dlatego użyj tego zakresu, aby przyznać dostęp do punktów końcowych określonego agenta bez przyznawania dostępu do punktów końcowych wszystkich agentów w projekcie. Aby uzyskać więcej informacji, zobacz Przypisania ról o zakresie agenta.

Wbudowane role

Rola wbudowana0 w rozwiązaniu Foundry jest rolą utworzoną przez Microsoft obejmującą typowe scenariusze dostępu, które można przypisać członkom zespołu. Kluczowe wbudowane role używane w Azure obejmują właściciel, współautor i czytelnik. Te role nie są specyficzne dla uprawnień zasobów usługi Foundry.

W przypadku zasobów usługi Foundry użyj dodatkowych wbudowanych ról, aby postępować zgodnie z zasadami dostępu z najmniejszymi uprawnieniami. W poniższej tabeli wymieniono kluczowe wbudowane role Foundry oraz linki do dokładnych definicji ról w wbudowanych rolach AI + Machine Learning.

Aby uzyskać więcej informacji o przypisywaniu roli pojedynczemu agentowi, zobacz Przypisania ról dla agenta.

Uprawnienia dla każdej roli wbudowanej

W poniższej tabeli przedstawiono uprawnienia dozwolone dla każdej wbudowanej roli w usłudze Microsoft Foundry.

Aby zobaczyć uprawnienia przypisane do każdej z kluczowych wbudowanych ról Azure (Właściciel, Współautor, Czytelnik), skorzystaj z poniższej tabeli.

Aby publikować agentów, musisz mieć co najmniej rolę Foundry Project Manager dla zasobu Foundry. Aby uzyskać więcej informacji, zobacz Agent applications in Microsoft Foundry (Aplikacje Microsoft Foundry.

Użyj tych kart, aby poznać różnice między wbudowanymi rolami, które są przypisywane na poziomie zasobów Foundry (z wyjątkiem roli właściciela, która jest przypisywana na poziomie subskrypcji)

Przykłady mapowań kontroli dostępu opartej na rolach w przedsiębiorstwie dla projektów

Oto przykład implementacji kontroli dostępu opartej na rolach (RBAC) dla zasobu rozwiązania Foundry przedsiębiorstwa.

Informacje o limitach przydziału dostępu i użyciu

Usługa Foundry używa informacji platformy Azure o przydziałach i użyciu na potrzeby takich funkcji jak weryfikacja wdrożenia i raportowanie przydziałów. Kontrola dostępu oparta na rolach na platformie Azure reguluje dostęp do informacji na poziomie subskrypcji.

Przypisz rolę Cognitive Services Usages Reader na poziomie subskrypcji, aby zapewnić minimalny wymagany poziom uprawnień potrzebny do wglądu w limity przydziału. Inne role na poziomie subskrypcji, które obejmują Microsoft.CognitiveServices/locations/usages/read, również mogą zapewniać dostęp, ale mogą przyznawać szersze uprawnienia.

Jeśli Foundry nie może pobrać informacji o limitach, niektóre funkcje mogą nie wyświetlać dostępnych limitów ani prawidłowo weryfikować wdrożeń. Sprawdź, czy zalogowany użytkownik ma wymagane uprawnienia w zakresie subskrypcji.

Zarządzanie przypisaniami ról

Aby zarządzać rolami w narzędziu Foundry, musisz mieć uprawnienia do przypisywania i usuwania ról w Azure. Wbudowana rola Azure Owner zawiera to uprawnienie. Role można przypisać za pośrednictwem portalu Foundry (okienko Zarządzanie), modułu IAM w portalu Azure lub interfejsu wiersza polecenia platformy Azure (Azure CLI). Role można usunąć przy użyciu funkcji IAM lub Azure CLI portalu Azure.

az role assignment create --role "53ca6127-db72-4b80-b1b0-d745d6d5456d" --assignee "joe@contoso.com" --scope /subscriptions/00000000-0000-0000-0000-000000000000/resourceGroups/this-rg 

PROJECT_SCOPE="/subscriptions/<subscriptionId>/resourceGroups/<resourceGroupName>/providers/Microsoft.CognitiveServices/accounts/<accountName>/projects/<projectName>"

az role assignment create \
    --assignee-object-id "<principalId>" \
    --assignee-principal-type ServicePrincipal \
    --role "eed3b665-ab3a-47b6-8f48-c9382fb1dad6" \
    --scope "$PROJECT_SCOPE"

Przypisania ról zakresu agenta

Przypisz role na poziomie konkretnego agenta, a nie całego projektu. Takie podejście umożliwia udzielanie dostępu do punktu końcowego jednemu agentowi bez udzielania dostępu do punktu końcowego wszystkim agentom w projekcie. URI zakresu agenta ma następujący format:

/subscriptions/<subscriptionId>/resourceGroups/<resourceGroupName>/providers/Microsoft.CognitiveServices/accounts/<accountName>/projects/<projectName>/agents/<agentName>

Na przykład następujące polecenie przypisuje rolę Foundry Agent Consumer (identyfikator definicji roli eed3b665-ab3a-47b6-8f48-c9382fb1dad6) do nazwy głównej usługi w zakresie konkretnego agenta.

AGENT_SCOPE="/subscriptions/<subscriptionId>/resourceGroups/<resourceGroupName>/providers/Microsoft.CognitiveServices/accounts/<accountName>/projects/<projectName>/agents/<agentName>"

az role assignment create \
    --assignee-object-id "<principalId>" \
    --assignee-principal-type ServicePrincipal \
    --role "eed3b665-ab3a-47b6-8f48-c9382fb1dad6" \
    --scope "$AGENT_SCOPE"

Mechanizm przypisywania ról dla zakresów agentów jest oparty na tym samym modelu RBAC platformy Azure co przypisania w zakresie projektu. Dowolną rolę, którą można przypisać na poziomie projektu, można również przypisać na poziomie agenta. Jednak na poziomie agenta przypisania ról są obecnie oceniane wyłącznie na potrzeby dostępu do punktu końcowego agenta i nie przyznają szerszych uprawnień do płaszczyzny sterowania ani uprawnień administracyjnych.

Tworzenie ról niestandardowych dla projektów

Jeśli wbudowane role nie spełniają wymagań przedsiębiorstwa, utwórz rolę niestandardową, która umożliwia precyzyjną kontrolę nad dozwolonymi akcjami i zakresami. Oto przykładowa definicja roli niestandardowej na poziomie subskrypcji:

{
  "Name": "My Enterprise Foundry User",
  "IsCustom": true,
  "Description": "Custom role for Foundry at my enterprise to only allow building Agents. Assign at subscription level.",
  "Actions": [
    "Microsoft.CognitiveServices/*/read",
    "Microsoft.Authorization/*/read",
    "Microsoft.CognitiveServices/accounts/listkeys/action",
    "Microsoft.Resources/deployments/*"
  ],
  "NotActions": [],
  "DataActions": [
    "Microsoft.CognitiveServices/accounts/AIServices/agents/*"
  ],
  "NotDataActions": [],
  "AssignableScopes": ["/subscriptions/<your-subscription-id>"]
}

Zapisz definicję w pliku i utwórz rolę:

az role definition create --role-definition custom-role.json

Aby uzyskać więcej informacji na temat tworzenia roli niestandardowej, zobacz następujące artykuły.

• portal Azure
• Azure CLI
• Azure PowerShell
• Wyłącz funkcje w wersji zapoznawczej w Microsoft Foundry. Ten artykuł zawiera więcej szczegółowych informacji na temat określonych uprawnień w ramach Foundry, zarówno na płaszczyźnie kontrolnej, jak i danych, i które można wykorzystać przy tworzeniu ról niestandardowych.

Uwagi i ograniczenia

• Aby wyświetlić i przeczyścić usunięte konta usługi Foundry, musisz mieć przypisaną rolę współpracownika na poziomie subskrypcji.

• Użytkownicy z rolą Współautor mogą wdrażać modele w narzędziu Foundry.

• Aby utworzyć role niestandardowe w zasobie, musisz mieć rolę Właściciel w zakresie zasobu.

• Jeśli masz uprawnienia do przypisywania ról w usłudze Azure (na przykład rolę Właściciel przypisaną do tożsamości użytkownika na poziomie zakresu konta) i wdrożysz zasób Foundry z poziomu portalu Azure lub interfejsu użytkownika portalu Foundry, rola Foundry User zostanie automatycznie przypisana do tożsamości użytkownika. To przypisanie nie ma zastosowania podczas wdrażania Foundry z SDK lub CLI.

  Ważna

  Niedawno zmieniono nazwy ról RBAC w usłudze Foundry. Użytkownik Foundry, właściciel Foundry, właściciel konta Foundry i menedżer projektu Foundry były wcześniej nazywane odpowiednio użytkownikiem Azure AI, właścicielem Azure AI, właścicielem konta Azure AI i menedżerem projektu Azure AI. Poprzednie nazwy mogą być nadal widoczne w niektórych miejscach, podczas gdy zmiana nazwy jest wdrażana. Identyfikatory ról i uprawnienia podstawowe są niezmienione przez zmianę nazwy.

• Podczas tworzenia zasobu Foundry, wbudowane uprawnienia kontroli dostępu opartej na rolach (RBAC) zapewniają Ci dostęp do zasobu. Aby korzystać z zasobów utworzonych poza usługą Foundry, upewnij się, że zasób ma uprawnienia umożliwiające dostęp do niego. Oto kilka przykładów:

  • Aby użyć nowego konta Azure Blob Storage, dodaj zarządzaną tożsamość zasobu usługi Foundry do roli usługi Odczyt danych obiektu blob usługi Storage na tym koncie magazynowym.
  • Aby użyć nowego źródła Wyszukiwanie AI platformy Azure, dodaj pozycję Foundry do przypisań ról Wyszukiwanie AI platformy Azure.

• Aby dostroić model w narzędziu Foundry, potrzebne są uprawnienia zarówno płaszczyzny danych, jak i płaszczyzny sterowania. Wdrażanie wymodelowanego modelu jest uprawnieniem warstwy kontrolnej. W związku z tym jedyną wbudowaną rolą z uprawnieniami płaszczyzny danych i płaszczyzny sterowania jest rola Właściciel rozwiązania Foundry . Jeśli wolisz, możesz również przypisać rolę Użytkownika usługi Foundry dla uprawnień płaszczyzny danych i rolę Właściciel konta usługi Foundry dla uprawnień płaszczyzny sterowania.

Uprawnienia specyficzne dla typu wdrożenia

W poniższych sekcjach omówiono powierzchnię uprawnień dla określonych typów wdrożeń. Użyj ich wraz z wbudowanymi tabelami ról w obszarze Uprawnienia dla każdej wbudowanej roli podczas planowania przypisań ról dla określonego obciążenia.

Zarządzane operacje płaszczyzny sterowania obliczeniowego

Wdrożenia zarządzanych zasobów obliczeniowych (wersja zapoznawcza) podlegają własnemu zestawowi operacji dostawcy zasobów platformy Azure w ramach dostawcy Microsoft.CognitiveServices. Te operacje kontrolują, kto może tworzyć, odczytywać, aktualizować i usuwać zarządzane wdrożenie obliczeniowe oraz kto może odczytać dostępną pojemność akceleratora i użycie limitu przydziału dla konta usługi Foundry.

W tej sekcji wymieniono pięć wymaganych operacji płaszczyzny sterowania, wbudowane role, które je nadają, oraz czym różni się mapowanie ról na uprawnienia od mapowania stosowanego we wdrożeniach standardowych (rozliczanych za token i PTU).

Wymagane operacje

Do pełnego zarządzania wdrożeniami zarządzanych zasobów obliczeniowych na koncie rozwiązania Foundry wymagane jest pięć operacji:

Mapowanie ról na uprawnienia

W poniższej tabeli przedstawiono, które wbudowane role zapewniają uprawnienia do każdej z pięciu zarządzanych operacji płaszczyzny sterowania dla zasobów obliczeniowych.

Wbudowane role platformy Azure Owner i Contributor nadają uprawnienia do wszystkich pięciu operacji dzięki uprawnieniu z akcją wieloznaczną na poziomie subskrypcji lub grupy zasobów.

Porównanie: wdrożenia standardowe a wdrożenia zarządzanego środowiska obliczeniowego

Zakres uprawnień płaszczyzny sterowania dla wdrożeń zarządzanego przetwarzania odzwierciedla zakres uprawnień dla wdrożeń standardowych (pay-per-token i PTU); nazwy operacji różnią się jedynie segmentem typu zasobu (deployments vs managedComputeDeployments, oraz modelCapacities vs managedComputeCapacities).

W poniższej tabeli przedstawiono podsumowanie porównania pokrycia CRUD poszczególnych ról w dwóch rodzinach wdrożeń:

Zalecane przypisania ról

Podczas przypisywania dostępu do tych operacji za pomocą zarządzanych zasobów obliczeniowych użyj następujących punktów początkowych:

• Wdrażanie i obsługiwanie zarządzanych wdrożeń mocy obliczeniowej: przypisz rolę Cognitive Services Contributor w zakresie konta Foundry.
• Widok tylko do odczytu dla wdrożeń i przydziałów: przypisz rolę Cognitive Services User lub Foundry User w zakresie konta Foundry.
• Zarządzanie projektem Foundry, ale bez wdrażania modeli: przypisz rolę Foundry Project Manager w zakresie konta Foundry. Kierownicy projektów mogą wyświetlać wdrożenia i limit przydziału, ale nie mogą ich tworzyć ani usuwać.
• Wywoływanie zarządzanego wdrożenia zasobów obliczeniowych za pomocą usługi Microsoft Entra ID podczas inferencji: przypisz rolę Foundry User w zakresie konta Foundry, niezależnie od roli płaszczyzny sterowania przypisanej użytkownikowi (lub bez żadnej roli płaszczyzny sterowania w przypadku użytkowników korzystających wyłącznie z inferencji).

Aby zapoznać się z przepływem pracy kompleksowego wdrażania, zobacz Wdrażanie modeli typu open source przy użyciu zarządzanych zasobów obliczeniowych.

Powiązana zawartość

• Zadania z podwyższonym poziomem uprawnień w usłudze Microsoft Foundry — wymagania dotyczące roli dla wszystkich zadań administracyjnych, w tym przypisania roli i infrastruktury agenta.
• Utwórz projekt.
• Sprawdź dostęp użytkownika do pojedynczego zasobu Azure.
• Uwierzytelnianie i autoryzacja w narzędziu Foundry.
• Wyłącz funkcje w wersji zapoznawczej w Microsoft Foundry.
• Instrukcja dotycząca uprawnień agenta hostowanego.

Załącznik

Przykłady izolacji dostępu

Każda organizacja może mieć różne wymagania dotyczące izolacji dostępu w zależności od osób użytkowników w przedsiębiorstwie. Izolacja dostępu odnosi się do tego, które role są przypisywane użytkownikom w przedsiębiorstwie do oddzielenia uprawnień przy użyciu naszych wbudowanych funkcji lub zunifikowanej, bardzo liberalnej roli. Istnieją trzy opcje izolacji dostępu dla rozwiązania Foundry, które można wybrać dla organizacji w zależności od wymagań dotyczących izolacji dostępu.

Brak izolacji dostępu. Oznacza to, że w przedsiębiorstwie nie masz żadnych wymagań oddzielających uprawnienia między deweloperem, menedżerem projektu ani administratorem. Uprawnienia do tych ról można przypisać między zespołami.

W związku z tym należy...

• Przyznawanie wszystkim użytkownikom w przedsiębiorstwie roli Właściciel rozwiązania Foundry w zakresie zasobów

  Ważna

  Niedawno zmieniono nazwy ról RBAC w usłudze Foundry. Użytkownik Foundry, właściciel Foundry, właściciel konta Foundry i menedżer projektu Foundry były wcześniej nazywane odpowiednio użytkownikiem Azure AI, właścicielem Azure AI, właścicielem konta Azure AI i menedżerem projektu Azure AI. Poprzednie nazwy mogą być nadal widoczne w niektórych miejscach, podczas gdy zmiana nazwy jest wdrażana. Identyfikatory ról i uprawnienia podstawowe są niezmienione przez zmianę nazwy.

Izolacja dostępu częściowego. Oznacza to, że menedżer projektu w przedsiębiorstwie powinien być w stanie opracowywać projekty, a także tworzyć projekty. Jednak administratorzy nie powinni móc opracowywać w programie Foundry, a jedynie tworzyć projekty i konta usługi Foundry.

W związku z tym należy...

• Przypisz administratorowi rolę Właściciel konta Foundry w zakresie zasobu
• Przypisz deweloperom i kierownikom projektów rolę Foundry Project Manager na zasobie

Pełna izolacja dostępu. Oznacza to, że administratorzy, menedżerowie projektów i deweloperzy mają przypisane jasne uprawnienia, które nie nakładają się na ich różne funkcje w przedsiębiorstwie.

Dlatego powinieneś...

• Przypisz administratorowi rolę Właściciel konta Foundry w zakresie zasobu
• Przypisz deweloperowi rolę Reader w zakresie zasobów usługi Foundry oraz rolę Foundry User w zakresie projektu
• Przypisz menedżerowi projektu rolę Foundry Project Manager w zakresie zasobu
• Nadaj odbiorcom agenta rolę Odbiorca agenta Foundry na poziomie projektu (lub na poziomie agenta w celu sterowania poszczególnymi agentami)

Używanie grup Microsoft Entra z usługą Foundry

Microsoft Entra ID zapewnia kilka sposobów zarządzania dostępem do zasobów, aplikacji i zadań. Korzystając z grup Microsoft Entra, można udzielić dostępu i uprawnień grupie użytkowników zamiast do poszczególnych użytkowników. Administratorzy IT w przedsiębiorstwie mogą tworzyć grupy Microsoft Entra w portalu Azure, aby uprościć proces przypisywania ról dla deweloperów. Podczas tworzenia grupy Microsoft Entra można zminimalizować liczbę przypisań ról wymaganych dla nowych deweloperów pracujących nad projektami usługi Foundry, przypisując grupie wymagane przypisanie roli do niezbędnego zasobu.

Wykonaj następujące kroki, aby użyć grup Microsoft Entra ID z usługą Foundry:

1. Utwórz grupę Security w grupie Groups w portalu Azure.
2. Dodaj właściciela i głównych użytkowników w organizacji, którzy potrzebują współdzielonego dostępu.
3. Otwórz zasób docelowy i przejdź do Kontrola dostępu (IAM).
4. Przypisz wymaganą rolę do użytkownika, grupy lub jednostki usługi i wybierz nową grupę zabezpieczeń.
5. Wybierz Przejrzyj + przypisz, aby przypisanie roli dotyczyło wszystkich członków grupy.

Typowe przykłady:

• Aby tworzyć agentów, uruchamiać śledzenie i korzystać z podstawowych funkcji Foundry, przypisz rolę Foundry User do grupy Microsoft Entra.
• Aby umożliwić interakcję z agentami bez szerszych uprawnień deweloperskich, przypisz Foundry Agent Consumer do grupy Microsoft Entra.
• Aby użyć funkcji śledzenia i monitorowania, przypisz czytelnika do połączonego zasobu usługi Application Insights do tej samej grupy.

Aby dowiedzieć się więcej o grupach Microsoft Entra ID, wymaganiach wstępnych i ograniczeniach, zobacz:

• Dowiedz się o grupach, członkostwie w grupach i dostępie w Microsoft Entra.
• Jak zarządzać grupami w Microsoft Entra.