Informacje o zabezpieczeniach, uwierzytelnianiu i autoryzacji

  • Artykuł

Azure DevOps Services | Azure DevOps Server 2022 — Azure DevOps Server 2019

Usługa Azure DevOps wykorzystuje wiele pojęć zabezpieczeń, aby zapewnić dostęp tylko tym użytkownikom, którzy powinni mieć dostęp do funkcji, funkcji i danych. Konta uzyskują dostęp do usługi Azure DevOps za pośrednictwem uwierzytelniania poświadczeń zabezpieczeń i autoryzacji uprawnień do konta w celu uzyskania dostępu do funkcji lub funkcji.

Ten artykuł opiera się na informacjach podanych w artykule Wprowadzenie do uprawnień, dostępu i grup zabezpieczeń. Administracja istratorzy korzystają z zrozumienia typów kont, metod uwierzytelniania, metod autoryzacji i zasad używanych do zabezpieczania usługi Azure DevOps.

Typy kont

  • Użytkownicy
  • Właściciel organizacji
  • Konta usług
  • Jednostki usługi lub tożsamości zarządzane
  • Agenci zadań

Authentication

  • Poświadczenia użytkownika
  • Uwierzytelnianie systemu Windows
  • Uwierzytelnianie dwuskładnikowe (2FA)
  • Uwierzytelnianie za pomocą klucza SSH
  • Osobiste tokeny dostępu
  • Konfiguracja protokołu Oauth
  • Biblioteka uwierzytelniania usługi Active Directory

Autoryzacja

  • Członkostwo w grupie zabezpieczeń
  • Kontrola dostępu oparta na rolach
  • Poziomy dostępu
  • Flagi funkcji
  • Przestrzenie nazw zabezpieczeń i uprawnienia

Zasady

  • Adres URL zasad ochrony prywatności
  • Zasady połączeń aplikacji i zabezpieczeń
  • Zasady użytkownika
  • Repozytorium Git i zasady gałęzi

Typy kont

  • Użytkownicy
  • Konta usług
  • Jednostki usługi lub tożsamości zarządzane
  • Agenci zadań

Authentication

  • Poświadczenia użytkownika
  • Uwierzytelnianie systemu Windows
  • Uwierzytelnianie dwuskładnikowe (2FA)
  • Uwierzytelnianie za pomocą klucza SSH
  • Osobiste tokeny dostępu
  • Konfiguracja protokołu Oauth
  • Biblioteka uwierzytelniania usługi Active Directory

Autoryzacja

  • Członkostwo w grupie zabezpieczeń
  • Uprawnienia oparte na rolach
  • Poziomy dostępu
  • Flagi funkcji
  • Przestrzenie nazw zabezpieczeń i uprawnienia

Zasady

  • Repozytorium Git i zasady gałęzi

Ważne

Usługa Azure DevOps nie obsługuje już uwierzytelniania poświadczeń alternatywnych od 2 marca 2020 r. Jeśli nadal używasz poświadczeń alternatywnych, zdecydowanie zachęcamy do przełączenia się do bezpieczniejszej metody uwierzytelniania (na przykład osobistych tokenów dostępu). Dowiedz się więcej.

Zarówno nasza usługa w chmurze, usługa Azure DevOps Services, jak i serwer lokalny, usługa Azure DevOps Server, obsługują projekty programistyczne, od planowania po wdrożeniu. Usługa Azure DevOps korzysta z infrastruktury platformy jako usługi platformy Microsoft Azure i wielu usług platformy Azure, w tym baz danych Azure SQL Database, w celu zapewnienia niezawodnej, globalnie dostępnej usługi dla projektów programistycznych.

Aby uzyskać więcej informacji na temat kroków, które firma Microsoft podejmuje, aby zapewnić bezpieczeństwo projektów w usługach Azure DevOps Services, które są dostępne, bezpieczne i prywatne, zobacz ten oficjalny dokument Azure DevOps Services Data Protection Overview (Omówienie ochrony danych usług Azure DevOps Services).

Klienci

Chociaż głównymi typami interesujących kont są konta użytkowników ludzkich, które dodajesz do organizacji lub projektu, usługa Azure DevOps obsługuje inne typy kont do wykonywania różnych operacji. Należą do nich następujące typy kont.

  • Właściciel organizacji: twórca organizacji usługi Azure DevOps Services lub przypisany właściciel. Aby dowiedzieć się, kto jest właścicielem organizacji w organizacji, zobacz Wyszukiwanie właściciela organizacji.
  • Konta usług: wewnętrzne konta usługi Azure DevOps używane do obsługi określonej usługi, takiej jak usługa puli agentów, potokiSDK. Opisy kont usług można znaleźć w temacie Grupy zabezpieczeń, konta usług i uprawnienia.
  • Jednostki usługi lub tożsamości zarządzane: aplikacje firmy Microsoft Entra lub tożsamości zarządzane dodane do organizacji w celu wykonywania akcji w imieniu aplikacji innej firmy. Niektóre jednostki usługi odnoszą się do wewnętrznych kont usługi Azure DevOps w celu obsługi operacji wewnętrznych.
  • Agenci zadań: wewnętrzne konta używane do uruchamiania określonych zadań zgodnie z harmonogramem.
  • Konta innych firm: konta, które wymagają dostępu do obsługi punktów zaczepienia sieci Web, połączeń z usługami lub innych aplikacji innych firm.

W tych dokumentach użytkownicy mogą odwoływać się do wszystkich tożsamości, które zostały dodane do Centrum użytkowników, co może obejmować użytkowników ludzkich i jednostek usługi.

  • Konta usług: wewnętrzne konta usługi Azure DevOps używane do obsługi określonej usługi, takiej jak usługa puli agentów, potokiSDK. Opisy kont usług można znaleźć w temacie Grupy zabezpieczeń, konta usług i uprawnienia.
  • Jednostki usługi lub tożsamości zarządzane: aplikacje firmy Microsoft Entra lub tożsamości zarządzane dodane do organizacji w celu wykonywania akcji w imieniu aplikacji innej firmy. Niektóre jednostki usługi odnoszą się do wewnętrznych kont usługi Azure DevOps w celu obsługi operacji wewnętrznych.
  • Agenci zadań: wewnętrzne konta używane do uruchamiania określonych zadań zgodnie z harmonogramem.
  • Konta innych firm: konta, które wymagają dostępu do obsługi punktów zaczepienia sieci Web, połączeń z usługami lub innych aplikacji innych firm.

Najbardziej efektywnym sposobem zarządzania kontami jest dodanie ich do grup zabezpieczeń.

Uwaga

Właściciel organizacji i członkowie grupy project collection Administracja istrators otrzymują pełny dostęp do większości funkcji i funkcji.

Uwierzytelnianie

Uwierzytelnianie weryfikuje tożsamość konta na podstawie poświadczeń podanych podczas logowania się do usługi Azure DevOps. Te systemy integrują się z funkcjami zabezpieczeń udostępnianymi przez te inne systemy i polegają na nich:

  • Microsoft Entra ID
  • Konto Microsoft (MSA)
  • Active Directory (AD)

Microsoft Entra ID i MSA obsługują uwierzytelnianie w chmurze. Zalecamy, aby identyfikator Entra firmy Microsoft był potrzebny do zarządzania dużą grupą użytkowników. W przeciwnym razie, jeśli masz niewielką bazę użytkowników dostępną do organizacji w usłudze Azure DevOps, możesz użyć kont Microsoft. Aby uzyskać więcej informacji, zobacz About accessing Azure DevOps with Microsoft Entra ID (Informacje o uzyskiwaniu dostępu do usługi Azure DevOps przy użyciu identyfikatora Entra firmy Microsoft).

W przypadku wdrożeń lokalnych usługa AD jest zalecana podczas zarządzania dużą grupą użytkowników. Aby uzyskać więcej informacji, zobacz Konfigurowanie grup do użycia we wdrożeniach lokalnych.

Metody uwierzytelniania, integracja z innymi usługami i aplikacjami

Inne aplikacje i usługi mogą być zintegrowane z usługami i zasobami w usłudze Azure DevOps. Aby uzyskiwać dostęp do konta bez konieczności wielokrotnego monitowania o poświadczenia użytkownika, aplikacje mogą używać następujących metod uwierzytelniania.

  • Osobiste tokeny dostępu do generowania tokenów w imieniu użytkownika dla:

    • Uzyskiwanie dostępu do określonych zasobów lub działań, takich jak kompilacje lub elementy robocze
    • Klienci, tacy jak Xcode i NuGet, którzy wymagają nazw użytkowników i haseł jako podstawowych poświadczeń oraz nie obsługują kont Microsoft i funkcji usługi Microsoft Entra, takich jak uwierzytelnianie wieloskładnikowe
    • Uzyskiwanie dostępu do interfejsów API REST usługi Azure DevOps

  • Protokół OAuth usługi Azure DevOps do generowania tokenów w imieniu użytkowników na potrzeby uzyskiwania dostępu do interfejsów API REST. Interfejsy API Konta i Profile obsługują tylko uwierzytelnianie OAuth.

  • Uwierzytelnianie SSH w przypadku generowania kluczy szyfrowania, gdy jest używany system Linux, macOS lub Windows z usługą Git dla systemu Windows i nie możesz korzystać z menedżerów poświadczeń usługi Git ani z osobistych tokenów dostępu na potrzeby uwierzytelniania HTTPS.

  • Jednostki usługi lub tożsamości zarządzane do generowania tokenów firmy Microsoft w imieniu aplikacji lub usługi, które zwykle automatyzują niektóre przepływy pracy, które muszą uzyskiwać dostęp do zasobów usługi Azure DevOps. Większość akcji tradycyjnie wykonywanych przez konto usługi i osobisty token dostępu można wykonać przy użyciu jednostki usługi lub tożsamości zarządzanej.

Domyślnie Twoje konto lub kolekcja zezwala na dostęp do wszystkich metod uwierzytelniania. Możesz ograniczyć dostęp, ale należy konkretnie ograniczyć dostęp dla każdej metody. Jeśli odmówisz dostępu dla określonej metody uwierzytelniania, żadna aplikacja nie będzie mogła używać tej metody w celu uzyskania dostępu do Twojego konta. Wszelkie aplikacje, które wcześniej miały dostęp, otrzymają błąd uwierzytelniania i nie będą mogły uzyskać dostępu do konta.

Aby uzyskać więcej informacji na temat sposobu przechowywania poświadczeń, zobacz Magazyn poświadczeń dla usługi Azure DevOps.

Aby uzyskać więcej informacji na temat wybierania odpowiedniego mechanizmu uwierzytelniania, zobacz Wskazówki dotyczące uwierzytelniania.

Autoryzacja

Autoryzacja sprawdza, czy tożsamość, która próbuje nawiązać połączenie, ma niezbędne uprawnienia dostępu do usługi, funkcji, funkcji, obiektu lub metody. Autoryzacja zawsze następuje po pomyślnym uwierzytelnieniu. Jeśli połączenie nie jest uwierzytelnione, nie powiedzie się, zanim zostanie wykonane sprawdzanie autoryzacji. Jeśli uwierzytelnianie połączenia powiedzie się, określona akcja może być nadal niedozwolona, ponieważ użytkownik lub grupa nie ma autoryzacji do wykonania tej akcji.

Autoryzacja zależy od uprawnień przypisanych do konta. Uprawnienia są przyznawane bezpośrednio do konta lub za pośrednictwem członkostwa w grupie zabezpieczeń lub roli zabezpieczeń. Poziomy dostępu i flagi funkcji mogą również udzielać lub ograniczać dostęp do funkcji. Aby uzyskać więcej informacji na temat tych metod autoryzacji, zobacz Wprowadzenie do uprawnień, dostępu i grup zabezpieczeń.

Przestrzenie nazw zabezpieczeń i uprawnienia

Przestrzenie nazw zabezpieczeń przechowują dane, które określają poziom dostępu, jaki muszą wykonywać konta usługi Azure DevOps w celu wykonania konkretnej akcji dla określonego zasobu. Każda rodzina zasobów, takich jak elementy robocze lub repozytoria Git, jest zabezpieczona za pośrednictwem unikatowej przestrzeni nazw. Każda przestrzeń nazw zabezpieczeń zawiera zero lub więcej list kontroli dostępu (ACL). Każda lista ACL zawiera token, flagę dziedziczą i zestaw zera lub większej liczby wpisów kontroli dostępu (ACL). Każda aCE zawiera deskryptor tożsamości, dozwoloną maskę bitów uprawnień i maskę bitów odmowy uprawnień.

Aby uzyskać więcej informacji, zobacz Security namespaces and permission reference (Przestrzenie nazw zabezpieczeń i dokumentacja uprawnień).

Zasady zabezpieczeń

Aby zabezpieczyć organizację i kod, można ustawić wiele zasad. W szczególności można włączyć lub wyłączyć następujące zasady:

Ogólne

Zasady połączeń aplikacji i zabezpieczeń

Użyj zasad dzierżawy firmy Microsoft Entra, aby ograniczyć tworzenie nowych organizacji tylko do żądanych użytkowników. Te zasady są domyślnie wyłączone i prawidłowe tylko wtedy, gdy organizacja jest połączona z identyfikatorem Entra firmy Microsoft. Aby uzyskać więcej informacji, zobacz Ograniczanie tworzenia organizacji.

Następujące zasady określają dostęp, który chcesz przyznać użytkownikom i aplikacjom w organizacjach:

Zasady użytkownika

  • Dostęp gościa zewnętrznego (tylko wtedy, gdy organizacja jest połączona z identyfikatorem Entra firmy Microsoft). Po włączeniu zaproszenia mogą być wysyłane do kont e-mail użytkowników, którzy nie są członkami dzierżawy Microsoft Entra ID za pośrednictwem strony Użytkownicy . Aby uzyskać więcej informacji, zobacz Dodawanie użytkowników zewnętrznych do organizacji.
  • Zezwalaj administratorom zespołu i projektu na zapraszanie nowych użytkowników: ważne tylko wtedy, gdy organizacja jest połączona z identyfikatorem Entra firmy Microsoft. Po włączeniu administratorzy zespołu i projektu mogą dodawać użytkowników za pośrednictwem strony Użytkownicy . Aby uzyskać więcej informacji, zobacz Ograniczanie nowych zaproszeń użytkowników z Administracja istratorów projektu i zespołu.
  • Żądanie dostępu: tylko wtedy, gdy organizacja jest połączona z identyfikatorem Entra firmy Microsoft. Po włączeniu użytkownicy mogą żądać dostępu do zasobu. Żądanie powoduje wysłanie powiadomienia e-mail do administratorów z prośbą o przejrzenie i dostęp zgodnie z potrzebami. Aby uzyskać więcej informacji, zobacz Dodawanie użytkowników zewnętrznych do organizacji.
  • Zaproś użytkowników usługi GitHub: ważne tylko wtedy, gdy organizacja nie jest połączona z identyfikatorem Entra firmy Microsoft. Po włączeniu administratorzy mogą dodawać użytkowników na podstawie kont użytkowników usługi GitHub ze strony Użytkownicy . Aby uzyskać więcej informacji, zobacz Uwierzytelnianie i zapraszanie użytkowników usługi GitHub — często zadawane pytania.

Grupa Użytkownicy z zakresem projektu

Domyślnie użytkownicy dodani do organizacji mogą wyświetlać wszystkie informacje i ustawienia organizacji oraz projektu. Obejmuje to wyświetlanie listy użytkowników, listy projektów, szczegółów rozliczeń, danych użycia i nie tylko, które są dostępne za pośrednictwem Ustawienia organizacji.

Ważne

  • Funkcje ograniczonej widoczności opisane w tej sekcji dotyczą tylko interakcji za pośrednictwem portalu internetowego. Za pomocą interfejsów API REST lub azure devops poleceń interfejsu wiersza polecenia członkowie projektu mogą uzyskiwać dostęp do ograniczonych danych.
  • Użytkownicy-goście, którzy są członkami ograniczonej grupy z domyślnym dostępem w identyfikatorze Entra firmy Microsoft, nie mogą wyszukiwać użytkowników z selektorem osób. Gdy funkcja w wersji zapoznawczej jest wyłączona dla organizacji lub gdy użytkownicy-goście nie są członkami ograniczonej grupy, użytkownicy-goście mogą przeszukiwać wszystkich użytkowników firmy Microsoft Entra zgodnie z oczekiwaniami.

Aby ograniczyć wybranych użytkowników, takich jak osoby biorące udział w projekcie, użytkownicy-goście firmy Microsoft Entra lub członkowie określonej grupy zabezpieczeń, możesz włączyć funkcję Ogranicz widoczność i współpracę użytkowników do określonych projektów w wersji zapoznawczej dla organizacji. Po włączeniu tej opcji każdy użytkownik lub grupa dodana do grupy Użytkownicy o zakresie projektu są ograniczone w następujący sposób:

  • Może uzyskiwać dostęp tylko do stron Przegląd i Projekty w Ustawienia organizacji.
  • Może łączyć się i wyświetlać tylko te projekty, do których zostały dodane jawnie (zobacz Dodawanie użytkowników do projektu lub zespołu.
  • Może wybierać tylko tożsamości użytkowników i grup, które zostały jawnie dodane do projektu, z którymi są połączone.

Aby uzyskać więcej informacji, zobacz Zarządzanie organizacją, Ograniczanie widoczności użytkowników dla projektów i inne funkcje w wersji zapoznawczej oraz Zarządzanie funkcjami w wersji zapoznawczej.

Ostrzeżenie

Jeśli funkcja Ogranicz widoczność użytkownika i współpracę z określonymi projektami w wersji zapoznawczej jest włączona dla organizacji, użytkownicy z zakresem projektu nie mogą wyszukiwać użytkowników, którzy zostali dodani do organizacji za pośrednictwem członkostwa w grupie Microsoft Entra, a nie za pośrednictwem jawnego zaproszenia użytkownika. Jest to nieoczekiwane zachowanie i trwa rozwiązywanie problemów. Aby samodzielnie rozwiązać ten problem, wyłącz funkcję Ogranicz widoczność i współpracę użytkowników do określonych projektów w wersji zapoznawczej dla organizacji.

Repozytorium Git i zasady gałęzi

Aby zabezpieczyć kod, można ustawić wiele zasad repozytorium Git i gałęzi. Aby uzyskać więcej informacji, zobacz następujące artykuły.

Zabezpieczenia usług Azure Repos i Azure Pipelines

Ponieważ repozytoria i potoki kompilacji i wydania stanowią unikatowe wyzwania związane z zabezpieczeniami, stosowane są inne funkcje poza funkcjami omówionymi w tym artykule. Aby uzyskać więcej informacji, zobacz następujące artykuły.

Następne kroki

Dokumentacja uprawnień i grup