Udostępnij za pośrednictwem

Nowe zasady dotyczące osobistych tokenów dostępu

  • Artykuł

W tym przebiegu dodaliśmy nowe zasady, aby ograniczyć zakres i cykl życia osobistych tokenów dostępu (PAT). Ponadto zaktualizowaliśmy rozszerzenie powłoki systemu Windows Kontrola wersji serwera Team Foundation (TFVC) w celu obsługi programu Visual Studio 2019.

Aby uzyskać szczegółowe informacje, zapoznaj się z następującymi opisami funkcji.

Ogólne

Azure Pipelines

Azure Repos

Ogólne

Ograniczanie zakresu i cyklu życia osobistego tokenu dostępu za pomocą zasad dzierżawy Azure AD

Osobiste tokeny dostępu ułatwiają uwierzytelnianie w usłudze Azure DevOps w celu integracji z narzędziami i usługami. Jednak wyciekły tokeny mogą naruszyć bezpieczeństwo konta i danych usługi Azure DevOps, co zagraża aplikacjom i usługom.

Otrzymaliśmy opinię na temat administratorów, którzy nie mają niezbędnych kontroli w celu ograniczenia obszaru powierzchni zagrożenia stwarzanego przez wyciekły stacje dostępu użytkowników. Na podstawie tych opinii dodaliśmy nowy zestaw zasad, których można użyć do ograniczenia zakresu i cyklu życia osobistych tokenów dostępu usługi Azure DevOps w organizacji! Oto jak działają:

Użytkownicy przypisani do roli administratora usługi Azure DevOps w usłudze Azure Active Directory mogą przejść do karty usługi Azure Active Directory w ustawieniach organizacji dowolnej organizacji usługi Azure DevOps połączonej z Azure AD.

Kontrolki tokenu dostępu do obrazu

W tym miejscu administratorzy mogą wykonywać następujące czynności:

  1. Ograniczyć tworzenie globalnych osobistych tokenów dostępu (tokenów działających we wszystkich organizacjach usługi Azure DevOps, do których ma dostęp użytkownik).
  2. Ograniczyć tworzenie osobistych tokenów dostępu o pełnym zakresie.
  3. Zdefiniować maksymalny czas obowiązywania nowych osobistych tokenów dostępu.

Te zasady będą stosowane do wszystkich nowych paT utworzonych przez użytkowników dla organizacji usługi Azure DevOps połączonych z dzierżawą Azure AD. Każda z zasad ma listę dozwolonych użytkowników i grup, które powinny być wykluczone z zasad. Lista użytkowników i grup na liście dozwolonych nie będzie miała dostępu do zarządzania konfiguracją zasad.

Te zasady mają zastosowanie tylko do nowych tokenów PAT i nie wpływają na istniejące tokeny PAT, które zostały już utworzone i są używane. Po włączeniu zasad należy jednak zaktualizować wszystkie istniejące, niezgodne dostawcy usług zabezpieczeń, aby były objęte ograniczeniami, aby można je było odnowić.

Obsługa zasad dostępu warunkowego dla ruchu IPv6

Obecnie rozszerzamy obsługę zasad dostępu warunkowego (CAP) w celu uwzględnienia zasad ogrodzenia IPv6. Ponieważ widzimy, że osoby coraz częściej uzyskują dostęp do zasobów usługi Azure DevOps na urządzeniach z adresów IPv6, chcemy mieć pewność, że twoje zespoły będą wyposażone w udzielanie i usuwanie dostępu z dowolnego adresu IP, w tym tych pochodzących z ruchu IPv6.

Azure Pipelines

Zachowywanie potoków używanych w innych potokach

Wersje klasyczne miały możliwość automatycznego zachowywania kompilacji, które zużywają. Była to jedna z luk między klasycznymi wersjami i potokami YAML, a część z nich przestała przechodzić do kodu YAML. W tej wersji rozwiązaliśmy tę lukę.

Teraz możesz utworzyć wieloetapowy potok YAML reprezentujący wydanie i użyć w nim innego potoku YAML jako zasobu. Gdy to zrobisz, usługa Azure Pipelines automatycznie zachowa potok zasobów, o ile potok wydania zostanie zachowany. Po usunięciu potoku wydania dzierżawa potoku zasobów jest zwalniana i są przestrzegane jego własne zasady przechowywania.

Zmiany w automatycznym tworzeniu środowisk

Gdy tworzysz potok YAML i odwołujesz się do środowiska, które nie istnieje, usługa Azure Pipelines automatycznie tworzy środowisko. To automatyczne tworzenie może wystąpić w kontekście użytkownika lub w kontekście systemu. W następujących przepływach usługa Azure Pipelines wie o użytkowniku wykonującym operację:

  • Używasz kreatora tworzenia potoku YAML w środowisku internetowym usługi Azure Pipelines i odwołujesz się do środowiska, które nie zostało jeszcze utworzone.
  • Aktualizujesz plik YAML w edytorze internetowym usługi Azure Pipelines i zapisujesz potok po dodaniu odwołania do nieistniejącego środowiska.

W każdym z powyższych przypadków usługa Azure Pipelines ma jasne zrozumienie użytkownika wykonującego operację. W związku z tym tworzy środowisko i dodaje użytkownika do roli administratora środowiska. Ten użytkownik ma wszystkie uprawnienia do zarządzania środowiskiem i/lub dołączania innych użytkowników do różnych ról do zarządzania środowiskiem.

W kolejnych przepływach usługa Azure Pipelines nie ma informacji o użytkowniku tworzącym środowisko. Aktualizujesz plik YAML w innym zewnętrznym edytorze kodu, dodajesz odwołanie do nieistniejącego środowiska, a następnie powodujesz wyzwolenie potoku ręcznej lub ciągłej integracji. W takim przypadku usługa Azure Pipelines nie ma informacji o użytkowniku. Wcześniej radziliśmy sobie z tym przypadkiem tak, że dodawaliśmy wszystkich współautorów projektu do roli administratora środowiska. Każdy członek projektu mógł wtedy zmieniać te uprawnienia i uniemożliwiać innym dostęp do środowiska.

Otrzymaliśmy Twoją opinię na temat udzielania uprawnień administratora w środowisku wszystkim członkom projektu. Podczas nasłuchiwania opinii słyszeliśmy, że nie powinniśmy automatycznie tworzyć środowiska, jeśli nie jest jasne, kim jest użytkownik wykonujący operację. W tej wersji wprowadziliśmy zmiany w sposobie automatycznego tworzenia środowisk:

  • W przyszłości przebiegi potoków nie będą automatycznie tworzyć środowiska, jeśli nie istnieje i jeśli kontekst użytkownika nie jest znany. W takich przypadkach potok zakończy się niepowodzeniem z powodu błędu Nie znaleziono środowiska. Przed użyciem środowiska w potoku należy wstępnie utworzyć środowiska z odpowiednimi zabezpieczeniami i sprawdzić konfigurację.
  • Potoki ze znanym kontekstem użytkownika będą nadal automatycznie tworzyć środowiska tak samo jak w przeszłości.
  • Na koniec należy zauważyć, że funkcja automatycznego tworzenia środowiska została dodana tylko w celu uproszczenia procesu rozpoczynania pracy z usługą Azure Pipelines. Była przeznaczona dla scenariuszy testowych, a nie dla scenariuszy produkcyjnych. Zawsze należy wstępnie tworzyć środowiska produkcyjne z odpowiednimi uprawnieniami i sprawdzaniem, a następnie używać ich w potokach.

Okno dialogowe Usuwanie szczegółowych informacji z potoku kompilacji

Na podstawie opinii okno dialogowe Analiza zadania/potoku wyświetlane podczas nawigowania po potoku kompilacji zostało usunięte w celu ulepszenia przepływu pracy. Analiza potoku jest nadal dostępna, aby uzyskać potrzebne szczegółowe informacje.

Azure Repos

Aktualizacje do rozszerzenia powłoki systemu Windows Kontrola wersji serwera Team Foundation (TFVC) dla programu Visual Studio 2019

Poprzednia wersja rozszerzenia tfVC powłoki systemu Windows działała tylko na komputerach z zainstalowanym programem Visual Studio 2017.

Opublikowaliśmy nową wersję tego narzędzia, która jest zgodna z programem Visual Studio 2019. Rozszerzenie zapewnia integrację z Eksploratorem Windows i typowymi oknami dialogowymi plików. Dzięki tej integracji można wykonywać wiele operacji kontroli źródła bez konieczności uruchamiania programu Visual Studio lub narzędzia wiersza polecenia Team Foundation.

Następne kroki

Uwaga

Te funkcje będą wdrażane w ciągu najbliższych dwóch do trzech tygodni.

Przejdź do usługi Azure DevOps i spójrz.

Przejdź do usługi Azure DevOps

Jak przekazać opinię

Chcielibyśmy usłyszeć, co myślisz o tych funkcjach. Użyj menu Pomocy, aby zgłosić problem lub podać sugestię.

Utwórz sugestię

Możesz również uzyskać porady i pytania, na które odpowiada społeczność w witrynie Stack Overflow.

Dzięki,

Vijay Machiraju