Notatka
Dostęp do tej strony wymaga autoryzacji. Może spróbować zalogować się lub zmienić katalogi.
Dostęp do tej strony wymaga autoryzacji. Możesz spróbować zmienić katalogi.
usługi Azure DevOps
Kontrole uprawnień są częścią wielu operacji Azure DevOps Services. Na dużą skalę wiele jawnych przypisań uprawnień, wyjątków na poziomie zasobów i członkostwa w grupach może spowolnić ocenę uprawnień i aktualizacje. Duże listy kontroli dostępu wymagają również usługi pobierania i rozwiązywania większej liczby danych uprawnień i tożsamości.
Skorzystaj z zaleceń w tym artykule, aby zmniejszyć ilość danych uprawnień, które Azure DevOps Services przetwarzają.
Tip
Możesz użyć sztucznej inteligencji, aby ułatwić wykonywanie zadań usługi Azure DevOps. Aby rozpocząć, zobacz Włącz wsparcie AI z użyciem Azure DevOps MCP Server.
Miękkie limity wydajności
Użyj następujących limitów jako celów planowania dla dużych organizacji. Azure DevOps Services nie wymusza tych limitów ani nie blokuje zmian uprawnień, które je przekraczają. Jednak ich przekroczenie zwiększa ryzyko powolnych zapytań o uprawnienia, ewaluacji oraz aktualizacji członkostwa.
| Mierzenie | Zalecana maksymalna |
|---|---|
| AcEs w jednej przestrzeni nazw zabezpieczeń | 1,000,000 |
| Członkowie jednej grupy Microsoft Entra lub Azure DevOps | 10,000 |
Wpis kontroli dostępu (ACE) przechowuje uprawnienia przypisane do jednego użytkownika lub grupy. W przypadku grup zagnieżdżonych należy wziąć pod uwagę całkowite skuteczne członkostwo w przypadku korzystania z wytycznych dotyczących rozmiaru grupy.
Zalecane wskazówki
| Practice | Korzyść z wydajności |
|---|---|
| Przypisywanie uprawnień do grup zamiast poszczególnych użytkowników | Zamienia wiele wpisów kontroli dostępu użytkownika (ACE) na jeden grupowy wpis ACE. |
| Korzystanie z najszerszego zakresu dopasowania i dziedziczenia | Unika powtarzania identycznych kontroli dostępu do zasobów podrzędnych. |
| Użyj opcji Odmów tylko w przypadku wyjątków | Ogranicza jawne przesłonięcia i ACL na poziomie obiektu. |
| Używaj odpowiednio dobranych grup tożsamości | Zmniejsza niepotrzebne przetwarzanie członkostwa w grupach. |
| Równoważenie zasobów między projektami i organizacjami | Ogranicza liczbę zasobów ocenianych w ramach jednej granicy. |
| Przyrostowe stosowanie zmian uprawnień | Zmniejsza obciążenie dużych lub częstych aktualizacji kontroli dostępu. |
Przypisywanie uprawnień do grup
Użyj wbudowanych lub niestandardowych grup zabezpieczeń Azure DevOps do reprezentowania ról, zespołów i kohort dostępu. Przypisanie uprawnienia do grupy powoduje utworzenie jednego ACE. Przypisanie tego samego uprawnienia bezpośrednio do wielu użytkowników powoduje utworzenie ACE dla każdego użytkownika.
- Preferuj wbudowane grupy, takie jak Czytelnicy, Współautorzy i Administratorzy Project, gdy ich uprawnienia są zgodne z wymaganym dostępem.
- Utwórz grupę niestandardową, gdy wbudowana grupa nie jest zgodna z wymaganym dostępem.
- Nie zamieniaj jednej grupy na setki lub tysiące bezpośrednich przypisań użytkowników.
Korzystanie z najszerszego zakresu dopasowania i dziedziczenia
Ustaw uprawnienia tylko raz w najwyższym obsługiwanym zakresie odpowiadającym wymaganiom dostępu. Zezwalaj zasobom podrzędnym na dziedziczenie uprawnień i pozostaw dziedziczenie włączone, chyba że zasób podrzędny wymaga innego dostępu.
Przykład:
| Wymaganie dostępu | Preferowany zakres |
|---|---|
| Wykonywanie zadania na poziomie organizacji | Poziom organizacji, gdy uprawnienie jest dostępne na tym poziomie |
| Uzyskiwanie dostępu do wszystkich zasobów obsługiwanego typu w projekcie | Poziom projektu lub nadrzędny element typu zasobu na poziomie projektu |
| Uzyskiwanie dostępu do wszystkich repozytoriów Git w projekcie | Wpis repozytoriów Git najwyższego poziomu |
| Uzyskiwanie dostępu do wszystkich gałęzi w repozytorium | Poziom repozytorium |
| Uzyskiwanie dostępu do jednego repozytorium, gałęzi, potoku, ścieżki obszaru lub innego zasobu | Poziom obiektu |
Unikaj ustawiania identycznych uprawnień oddzielnie dla każdego repozytorium, gałęzi, potoku lub innego zasobu podrzędnego. W przypadku repozytoriów Git poszczególne repozytoria dziedziczą uprawnienia z pozycji „Repozytoria Git” najwyższego poziomu.
Wyłącz dziedziczenie tylko wtedy, gdy zasób potrzebuje innego dostępu niż jego element nadrzędny. Wyłączenie dziedziczenia w wielu zasobach zwykle wymaga bardziej jawnych przypisań.
Użyj opcji Odmów tylko w przypadku wyjątków
Udziel dostępu za pośrednictwem grupy, a dla tożsamości, które nie powinny otrzymać tego dostępu, pozostaw uprawnienia jako Nie ustawiono. Zamiast przyznawać szeroki dostęp, a następnie dodawać wiele wpisów Odmów, utwórz grupę z dokładnie wymaganymi uprawnieniami.
Użyj opcji Odmów tylko wtedy, gdy musisz zastąpić dziedziczone ustawienie Zezwalaj dla określonego wyjątku. Pojedynczy wpis Deny sam w sobie nie jest problemem z wydajnością. Jednak wiele wyjątków dodaje ACL i często wymaga większej liczby przypisań uprawnień na poziomie obiektu.
Używaj odpowiednio dobranych grup tożsamości
Użyj grup, które są zgodne z wymaganiami dotyczącymi dostępu, takimi jak jednostka biznesowa, projekt, produkt lub funkcja zadania. Ani grupy Entra, ani grupy Azure DevOps nie oferują lepszej wydajności. Zastosuj te same wskazówki dotyczące rozmiaru i zagnieżdżania do obu typów grup.
- Unikaj dodawania grupy obejmującej całą dzierżawę lub całą firmę, takiej jak grupa Wszyscy pracownicy.
- Unikaj głęboko zagnieżdżonych lub często zmieniających się struktur grup, gdy prostsza grupa zapewnia ten sam dostęp.
- Podziel bardzo dużą grupę na mniejsze kohorty dostępu, jeśli jej członkowie nie wymagają takiego samego poziomu dostępu.
- Jeśli każdy członek potrzebuje takiego samego dostępu, przypisz jedną grupę na poziomie dziedziczonego zakresu nadrzędnego zamiast używać indywidualnych przypisań lub zduplikowanych grup.
Grupy z ponad 10 000 członkami są ryzykiem wydajności. Zagnieżdżenie, częste zmiany w członkostwie i dostęp do wielu zasobów objętych uprawnieniami dostępu mogą zwiększyć wpływ. Ogranicz zbędną liczbę członków i podziel grupę na mniejsze grupy dostępu tam, gdzie to praktyczne.
Równoważenie zasobów między projektami i organizacjami
Unikaj koncentracji tysięcy repozytoriów i większości zasobów chronionych uprawnieniami w jednym projekcie, podczas gdy inne projekty zawierają tylko kilka. Operacje odnajdujące dostępne zasoby mogą wymagać oceny uprawnień w całym zestawie.
Dystrybuuj duże zestawy repozytoriów i innych zasobów w projektach, zanim za dużo zasobów zgromadzi się w jednym projekcie. Nie twórz jednego projektu na repozytorium; liczba projektów ma również praktyczne limity wydajności.
W skrajnej skali przedsiębiorstwa wiele mniejszych organizacji może działać lepiej niż jedna organizacja, która zawiera większość zasobów firmy i danych uprawnień. Podziel organizacje według stabilnych granic produktów lub obszarów biznesowych, aby rozłożyć obciążenie związane z zasobami i uprawnieniami. Użyj tego podejścia tylko wtedy, gdy korzyść skalowania przewyższa koszty związane z zarządzaniem zasobami w oddzielnych organizacjach.
Ogranicz zmienność automatyzacji uprawnień
Jeśli zarządzasz uprawnieniami za pomocą skryptów, interfejsów API REST lub przepływów pracy opartych na podejściu „konfiguracja jako kod”:
- Zastosuj tylko zmiany wymagane do osiągnięcia zamierzonego stanu. Nie usuwaj ani nie twórz ponownie niezmienionych przypisań uprawnień przy każdym uruchomieniu.
- Ustaw uprawnienia na poziomie nadrzędnym zamiast generować odpowiednie wpisy dla każdego zasobu podrzędnego.
- Wprowadzaj zmiany zbiorczo tam, gdzie są obsługiwane, i postępuj zgodnie z najlepszymi praktykami dotyczącymi interfejsu API REST usługi Azure DevOps.
- Unikaj pętli uzgodnień uprawnień o wysokiej częstotliwości.
- Unikaj rutynowego tworzenia i usuwania dużej liczby projektów lub zasobów z uprawnieniami.
- Usuń przestarzałe przypisania jawne, aby zmniejszyć listę kontroli dostępu (ACL) i wolumin ACE.