Wskazówki dotyczące uwierzytelniania dla Azure DevOps

Usługi Azure DevOps | Azure DevOps Server | Azure DevOps Server 2022

Użyj tego artykułu, aby wybrać metodę uwierzytelniania dla Azure DevOps na poziomie organizacji. Obejmuje ona stan zabezpieczeń, ład i łatwość utrzymania dla typowych metod, a następnie linki do wskazówek ukierunkowanych na implementację.

Aby uzyskać szczegółowe informacje o implementacji na poziomie aplikacji, zobacz Metody uwierzytelniania dla Azure DevOps.

Różnice między usługami i serwerami

Opcje uwierzytelniania różnią się między usługami Azure DevOps i Azure DevOps Server.

Platforma Zalecana wartość domyślna Notes
Azure DevOps Services Uwierzytelnianie oparte na Microsoft Entra Użyj Microsoft Entra logowania dla użytkowników i tożsamości aplikacji Microsoft Entra na potrzeby automatyzacji.
Azure DevOps Server Windows authentication, .NET bibliotek klienckich lub paTs, jeśli są obsługiwane Wzorce jednostki usługi i tożsamości zarządzanej na potrzeby uwierzytelniania Azure DevOps mają zastosowanie do usług Azure DevOps, a nie Azure DevOps Server.

Porównanie typowych opcji uwierzytelniania

Poniższa tabela umożliwia porównanie typowych opcji dla użytkowników, aplikacji, skryptów i potoków.

Method Najlepsze dla Stan zabezpieczeń Zarządzanie poświadczeniami Działa z Unikaj, gdy
Microsoft Entra logowanie użytkownika Interakcyjny dostęp użytkowników do organizacji Azure DevOps Silna opcja z scentralizowanym ładem tożsamości, dostępem warunkowym i uwierzytelnianiem wieloskładnikowymi Zarządzane przez Microsoft Entra cykl życia i zasady dzierżawy Azure DevOps Services Wdrażasz nienadzorowaną automatyzację aplikacji do aplikacji
Tożsamość zarządzana Azure hostowana automatyzacja, taka jak Azure Functions lub App Service Najsilniejsza opcja automatyzacji hostowanej Azure, ponieważ tokeny są krótkotrwałe i Azure zarządza cyklem życia tożsamości Brak wpisu tajnego klienta do przechowywania lub obracania Azure DevOps Services Obciążenie nie jest uruchamiane na Azure lub potrzebujesz przenośnej tożsamości w różnych środowiskach
Główna usługa Automatyzacja poza Azure lub w wielu środowiskach i systemach ciągłej integracji/ciągłego wdrażania Silna opcja w przypadku używania najniższych uprawnień i nowoczesnych wzorców poświadczeń Zarządzasz tożsamością aplikacji i poświadczeniami, chyba że przepływ federacyjny usuwa wpisy tajne Azure DevOps Services Tożsamość zarządzana może spełniać te same wymagania dotyczące obciążeń hostowanych Azure
połączenie usługi Azure DevOps Azure Pipelines dostęp do zasobów Azure DevOps Silna opcja automatyzacji potoku, ponieważ używa federacji tożsamości obciążenia i unika rozrastania dostępu w potokach Zarządzane za pomocą ustawień połączenia usługi Azure DevOps potoki usług Azure DevOps Scenariusz nie jest uruchamiany przez Azure Pipelines
Osobisty token dostępu (PAT) Krótkoterminowe skrypty osobiste, jednorazowe testowanie lub starsze scenariusze zgodności Najwyższe ryzyko, ponieważ pakiety PAT są długotrwałymi wpisami tajnymi elementu nośnego powiązanymi z kontami użytkowników Ręczne tworzenie, przechowywanie, rotacja i odwoływanie Azure DevOps Services i Azure DevOps Server Automatyzacja produkcyjna, w której dostępna jest jednostka usługi, tożsamość zarządzana lub połączenie z usługą

Ważna

Rozważ użycie bardziej bezpiecznych tokenów Microsoft Entra zamiast bardziej ryzykownych osobowych tokenów dostępu. Aby uzyskać więcej informacji, zobacz Zmniejszanie użycia PAT. Zapoznaj się ze wskazówkami dotyczącymi uwierzytelniania, aby wybrać odpowiedni mechanizm uwierzytelniania dla Twoich potrzeb.

  • Użyj Microsoft Entra logowania użytkownika, aby uzyskać dostęp użytkowników do organizacji usług Azure DevOps Services.
  • Najpierw użyj tożsamości zarządzanej na potrzeby automatyzacji hostowanej Azure.
  • Użyj jednostki usługi dla automatyzacji nie Azure lub między środowiskami.
  • Użyj połączenia usługi Azure DevOps, gdy Azure Pipelines wymaga Azure DevOps dostępu do zasobów.
  • Używaj paT tylko w przypadku scenariuszy tymczasowych, osobistych, starszych lub Azure DevOps Server, w których nie mają zastosowania bardziej bezpieczne opcje.

Kiedy należy używać paTs

Użyj paT w ograniczonych scenariuszach, takich jak:

  • Osobiste skrypty ad hoc
  • Rozwiązywanie problemów z jednorazowym interfejsem API
  • Starsze narzędzia, które nie mogą używać uwierzytelniania opartego na Microsoft Entra
  • Azure DevOps Server scenariuszy, w których nowoczesne przepływy tożsamości w chmurze nie są dostępne

W przypadku korzystania z pats:

  • Określanie zakresu do minimalnych wymaganych uprawnień.
  • Użyj najkrótszego praktycznego okresu istnienia.
  • Przechowuj i obracaj je jako wpisy tajne.
  • W miarę możliwości zastąp je opcjami opartymi na Microsoft Entra.

Aby uzyskać wskazówki dotyczące cyklu życia pat, zobacz Używanie osobistych tokenów dostępu i Zarządzanie zasadami pat.

Mechanizmy kontroli ładu i zasad

Użyj kontrolek organizacji i dzierżawy, aby wymusić stan uwierzytelniania:

Lista kontrolna podejmowania decyzji

Przed wybraniem metody uwierzytelniania potwierdź:

  • Czy jest to interakcyjny dostęp użytkownika, czy nienadzorowana automatyzacja?
  • Czy obciążenie jest hostowane w Azure, czy poza Azure?
  • Czy platforma docelowa Azure DevOps Services, czy Azure DevOps Server?
  • Czy ten scenariusz może uniknąć długotrwałych poświadczeń?
  • Czy zostały spełnione wymagania dotyczące zasad organizacji i inspekcji?

Przewodniki implementacji

  • Last updated on