Udostępnij przez

Zabezpieczanie agentów, projektów i kontenerów

Azure DevOps Services | Azure DevOps Server | Azure DevOps Server 2022

Podczas zabezpieczania usługi Azure Pipelines rozważ ochronę udostępnionej infrastruktury, repozytoriów, projektów i nie tylko.

Ten artykuł jest częścią serii, która ułatwia implementowanie środków zabezpieczeń dla usługi Azure Pipelines. Aby uzyskać więcej informacji, zobacz Secure Azure Pipelines.

Wymagania wstępne

Kategoria Wymagania
Azure DevOps — Zaimplementuj zalecenia z Make your Azure DevOps secure oraz Secure Azure Pipelines.
— Podstawowa wiedza na temat języka YAML i usługi Azure Pipelines. Aby uzyskać więcej informacji, zobacz Tworzenie pierwszego pipeline'u.
uprawnienia - Aby zmodyfikować uprawnienia potoków: Członek grupy Administratorów projektu.
- Aby zmodyfikować uprawnienia organizacji, należy być członkiem grupy Administratorów kolekcji projektów.

Ochrona udostępnionej infrastruktury

Chronione zasoby w usłudze Azure Pipelines to abstrakcja rzeczywistej infrastruktury. Postępuj zgodnie z tymi zaleceniami, aby chronić podstawową infrastrukturę.

Korzystanie z pul hostowanych przez firmę Microsoft

Pule hostowane przez firmę Microsoft zapewniają izolację i czystą maszynę wirtualną dla każdego uruchomienia potoku. Jeśli to możliwe, użyj pul hostowanych przez firmę Microsoft zamiast pul hostowanych samodzielnie.

Oddzielni agenci dla każdego projektu

Agent może skojarzyć tylko z jedną pulą. Agentów można udostępniać między projektami, kojarząc pulę z wieloma projektami. W praktyce wiele projektów może używać tego samego agenta kolejno. Chociaż ekonomiczne, takie podejście może wprowadzać ryzyko ruchu bocznego.

Aby zmniejszyć ruch poprzeczny i zapobiec zanieczyszczeniu krzyżowemu między projektami, należy zachować oddzielne pule agentów, z których każdy jest przeznaczony dla określonego projektu.

Uruchamianie agentów przy użyciu kont z niskimi uprawnieniami

Uruchamianie agenta w ramach tożsamości z bezpośrednim dostępem do zasobów usługi Azure DevOps może być ryzykowne. To ryzyko jest powszechne w organizacjach korzystających z identyfikatora Entra firmy Microsoft.

Dlaczego to ryzyko ma znaczenie:

  • Jeśli uruchomisz agenta w ramach tożsamości obsługiwanej przez Entra ID, może on bezpośrednio uzyskać dostęp do interfejsów API usługi Azure DevOps bez polegania na tokenie dostępu zadania.
  • Adwersarze, którzy uruchamiają kompromitowany pipeline na tych agentach budowy, mogą potencjalnie przejąć kontrolę nad całą organizacją Azure DevOps.

Zalecenie: Uruchom agenta przy użyciu nieuprzywilejowanego konta lokalnego:

  • Agenci systemu Windows: użyj usługi sieciowej (NT AUTHORITY\NETWORK SERVICE), usługi lokalnej lub konta usługi zarządzanej przez grupę (gMSA).
  • Agenci systemu Linux i agenci systemu macOS: utwórz dedykowane konto użytkownika innego niż główny (na przykład svc_azuredevops). To konto nie powinno mieć dostępu do sudo ani do pliku sudoers w celu zapewnienia maksymalnego bezpieczeństwa.

Ważne

W usłudze Azure DevOps grupa Konta usług dla kolekcji projektów może być myląca. Z racji dziedziczenia, członkowie kont serwisowych zbioru projektów są również członkami Administratorów Kolekcji Projektów. Niektórzy klienci uruchamiają swoich agentów kompilacji, używając tożsamości wspieranych przez Entra ID, a te tożsamości mogą być częścią projektowych kont usług kolekcji.

Zagrożenia dla wysoce uprzywilejowanych agentów:

Agenci self-hosted czasami działają w ramach wysoce uprzywilejowanych kont w celu uzyskania dostępu do danych poufnych lub środowisk produkcyjnych. Jeśli przeciwnicy uruchomią potok z naruszonymi zabezpieczeniami na jednym z agentów kompilacji, mogą:

  • Uzyskaj dostęp do tych tajemnic
  • Przechodzenie poprzecznie przez inne systemy dostępne za pośrednictwem tych kont

Najlepsze rozwiązania dotyczące zabezpieczeń agenta:

  • Użyj konta o najniższych uprawnieniach możliwego do uruchamiania własnych agentów.
  • Rozważ użycie konta komputera lub tożsamości usługi zarządzanej.
  • Pozwól usłudze Azure Pipelines zarządzać dostępem do środowisk i tajemnic.

Minimalizuj zakres połączeń usług

Połączenia usług powinny uzyskiwać dostęp tylko do niezbędnych zasobów.

Zalecenia dotyczące uwierzytelniania:

Zalecenia dotyczące zakresu:

  • Określanie zakresu połączenia usługi platformy Azure w celu uzyskania dostępu tylko do niezbędnych zasobów.
  • Unikaj udzielania szerokich praw współautora dla całej subskrypcji platformy Azure.
  • Podczas tworzenia nowego połączenia usługi Azure Resource Manager zawsze wybierz określoną grupę zasobów.
  • Upewnij się, że grupa zasobów zawiera tylko niezbędne maszyny wirtualne lub zasoby wymagane do kompilacji.
  • Podczas konfigurowania aplikacji GitHub przyznaj dostęp tylko do repozytoriów, które zamierzasz skompilować.

Ochrona projektów

Poza poszczególnymi zasobami kluczowe jest rozważenie grup zasobów w usłudze Azure DevOps. Zasoby są zorganizowane według projektów zespołowych i musisz zrozumieć, do jakich zasobów potok ma dostęp w oparciu o ustawienia projektu i zakres.

Każde zadanie w potoku otrzymuje token dostępu z uprawnieniami do odczytu otwartych zasobów. W niektórych przypadkach potoki mogą również aktualizować te zasoby. Ten model uprawnień oznacza, że chociaż konto użytkownika może nie posiadać bezpośredniego dostępu do określonego zasobu, skrypty i zadania uruchamiane w pipeline'u mogą nadal uzyskiwać do niego dostęp. Ponadto model zabezpieczeń usługi Azure DevOps umożliwia dostęp do tych zasobów z innych projektów w organizacji. Jeśli zdecydujesz się ograniczyć dostęp pipeline do niektórych zasobów, ta decyzja dotyczy wszystkich pipeline w projekcie — określonym pipeline nie można selektywnie przyznać dostępu do publicznych zasobów.

Oddzielne projekty

Biorąc pod uwagę charakter otwartych zasobów, rozważ zarządzanie każdym produktem i zespołem w oddzielnych projektach. Dzięki temu potoki nieumyślnie uzyskują dostęp do otwartych zasobów z innego produktu, co minimalizuje narażenie boczne. Jednak gdy wiele zespołów lub produktów współdzieli projekt, szczegółowa izolacja zasobów staje się trudna.

Jeśli organizacja usługi Azure DevOps została utworzona przed sierpniem 2019 r., przebiegi mogą nadal mieć dostęp do otwartych zasobów we wszystkich projektach organizacji. Administrator organizacji powinien przejrzeć krytyczne ustawienie zabezpieczeń w usłudze Azure Pipelines, które umożliwia izolację projektu dla potoków.

To ustawienie można znaleźć w obszarze lub bezpośrednio: . >

Zrzut ekranu przedstawiający interfejs użytkownika zakresu autoryzacji zadania

Ochrona repozytoriów

W repozytoriach kontroli wersji można przechowywać kod źródłowy, plik YAML potoku oraz niezbędne skrypty i narzędzia. Aby zapewnić bezpieczne zmiany kodu i potoku, ważne jest zastosowanie uprawnień i zasad gałęzi. Ponadto rozważ dodanie uprawnień potoku i kontrole do repozytoriów.

Ponadto przejrzyj domyślne ustawienia kontroli dostępu dla repozytoriów.

Należy pamiętać, że projekt usługi Git oznacza, że ochrona na poziomie gałęzi ma ograniczenia. Użytkownicy z dostępem wypychanym do repozytorium mogą zazwyczaj tworzyć nowe gałęzie. Jeśli pracujesz z projektami open source w usłudze GitHub, każda osoba mająca konto usługi GitHub może rozwidlić repozytorium i zaproponować współtworzenie kontu. Ponieważ potoki są skojarzone z repozytorium (nie określonymi gałęziami), ważne jest, aby traktować pliki kodu i YAML jako potencjalnie niezaufane.

Rozwidlenia

Podczas pracy z publicznymi repozytoriami na GitHubie warto dokładnie przemyśleć podejście do kompilacji forków. Forki pochodzące spoza organizacji mogą stanowić szczególne ryzyko. Aby chronić produkty przed potencjalnie niezaufanym kodem, postępuj zgodnie z tymi zaleceniami.

Uwaga

Te zalecenia dotyczą przede wszystkim tworzenia publicznych repozytoriów z usługi GitHub.

Nie udostępniaj wpisów tajnych do rozwidleń kompilacji

Domyślnie potoki tworzą rozwidlenia, ale nie ujawniają automatycznie wpisów tajnych i chronionych zasobów do zadań w tych potokach. Nie wyłączaj tej ochrony, aby zachować bezpieczeństwo.

Zrzut ekranu przedstawiający interfejs użytkownika ochrony przed kompilacją rozwidlenia.

Uwaga

Po włączeniu kompilacji rozwidlenia w celu uzyskania dostępu do wpisów tajnych usługa Azure Pipelines ogranicza token dostępu używany domyślnie. Ten token ma ograniczony dostęp do otwartych zasobów w porównaniu z zwykłym tokenem dostępu. Aby przyznać rozwidlenie kompiluje te same uprawnienia co zwykłe kompilacje, włącz opcję Utwórz kompilacje rozwidlenia mają takie same uprawnienia jak zwykłe ustawienia kompilacji .

Rozważ ręczne wyzwalanie kompilacji rozwidlenia

Wyłącz automatyczne kompilacje forków i zamiast tego można użyć komentarzy pull requestów jako sposobu ręcznego kompilowania tych kontrybucji. To ustawienie umożliwia przejrzenie kodu przed wyzwoleniem kompilacji.

Korzystanie z agentów hostowanych przez firmę Microsoft dla kompilacji rozwidlenia

Unikaj uruchamiania kompilacji z rozwidlenia na własnych agentach. Jeśli używasz własnych agentów, organizacje zewnętrzne mogą uruchamiać kod zewnętrzny na maszynach w sieci firmowej. Jeśli to możliwe, użyj agentów hostowanych przez firmę Microsoft. W przypadku własnych agentów zaimplementuj izolację sieci i upewnij się, że agenci nie utrzymują stanu między zadaniami.

Przegląd zmian kodu

Przed uruchomieniem potoku dla rozwidlenia pull request, dokładnie przejrzyj proponowane zmiany i upewnij się, że jesteś pewny co do jego uruchomienia.

Wersja uruchomionego potoku YAML jest wersją z żądania ściągnięcia. Zwróć szczególną uwagę na zmiany w kodzie YAML i na kod uruchamiany po uruchomieniu potoku, na przykład skrypty wiersza polecenia lub testy jednostkowe.

Ograniczenie zakresu tokenu usługi GitHub

Podczas tworzenia rozwidlenia żądania ściągnięcia w usłudze GitHub usługa Azure Pipelines gwarantuje, że potok nie może zmienić żadnej zawartości repozytorium GitHub. To ograniczenie ma zastosowanie tylko wtedy, gdy używasz aplikacji GitHub usługi Azure Pipelines do integracji z usługą GitHub. Jeśli używasz innych form integracji z usługą GitHub, takich jak aplikacja OAuth, ograniczenie nie zostanie wymuszone.

Gałęzie użytkowników

Użytkownicy w organizacji z odpowiednimi uprawnieniami mogą tworzyć nowe gałęzie zawierające nowy lub zaktualizowany kod. Ten kod może działać przez ten sam potok co chronione gałęzie. Jeśli plik YAML w nowej gałęzi zostanie zmieniony, zaktualizowany plik YAML uruchamia potok. Chociaż ten projekt zapewnia dużą elastyczność i samoobsługę, nie wszystkie zmiany są bezpieczne (bez względu na to, czy zostały wprowadzone złośliwie, czy nie).

Jeśli potok używa kodu źródłowego lub jest zdefiniowany w usłudze Azure Repos, musisz w pełni zrozumieć model uprawnień usługi Azure Repos. W szczególności użytkownik z uprawnieniem Tworzenie gałęzi na poziomie repozytorium może wprowadzić kod do repozytorium, nawet jeśli ten użytkownik nie ma uprawnień Współtworzenie.

Inne zagadnienia dotyczące zabezpieczeń

Podczas zabezpieczania potoków należy wziąć pod uwagę następujące aspekty zabezpieczeń.

Polegaj na ścieżce

Poleganie na ustawieniu agenta PATH jest niebezpieczne. Może nie wskazywać tam, gdzie myślisz, ponieważ poprzedni skrypt lub narzędzie mogło to potencjalnie zmienić. W przypadku skryptów i plików binarnych o znaczeniu krytycznym dla zabezpieczeń należy zawsze używać w pełni kwalifikowanej ścieżki do programu.

Wpisy tajne dziennika

Usługa Azure Pipelines próbuje usunąć wpisy tajne z dzienników wszędzie tam, gdzie to możliwe. To filtrowanie jest na zasadzie najlepszego wysiłku i nie może przechwytywać każdego sposobu, w jaki wpisy tajne mogą być wyciekane. Unikaj powtarzania wpisów tajnych w konsoli, używania ich w parametrach wiersza polecenia lub rejestrowania ich w plikach.

Blokowanie kontenerów

Kontenery mają kilka mapowań woluminów dostarczanych przez system w zadaniach, obszarze roboczym i składnikach zewnętrznych wymaganych do komunikowania się z agentem hosta. Wszystkie te woluminy można oznaczyć jako tylko do odczytu.

resources:
  containers:
  - container: example
    image: ubuntu:22.04
    mountReadOnly:
      externals: true
      tasks: true
      tools: true
      work: false  # the default; shown here for completeness

Zazwyczaj większość osób ustawia pierwsze trzy katalogi jako tylko do odczytu i pozostawia work jako do odczytu i zapisu. Jeśli nie zapisujesz w work katalogu w określonym zadaniu lub kroku, możesz też zrobić work tylko do odczytu. Jeśli jednak zadania potoku obejmują samodzielną modyfikację, może być konieczne zachowanie tasks jako odczyt-zapis.

Kontrolowanie dostępnych zadań

Możesz wyłączyć możliwość instalowania i uruchamiania zadań z witryny Marketplace. Takie podejście zapewnia większą kontrolę nad kodem, który jest uruchamiany w potoku. Możesz również wyłączyć wszystkie domyślne zadania, z wyjątkiem zadania Checkout, które jest specjalnym działaniem agenta. W większości przypadków nie wyłączaj zadań wbudowanych.

** Zadania instalowane bezpośrednio przy użyciu tfx są zawsze dostępne. Po włączeniu obu tych funkcji dostępne są tylko te zadania.

Korzystanie z usługi inspekcji

Usługa Audyt rejestruje wiele zdarzeń przepływu. Okresowo przejrzyj dziennik inspekcji, aby upewnić się, że żadne złośliwe zmiany nie spadły w przeszłości. Aby rozpocząć pracę, odwiedź stronę https://dev.azure.com/ORG-NAME/_settings/audit.

Następne kroki

Przegląd zabezpieczeń

  • Last updated on