Inne zagadnienia dotyczące zabezpieczeń usługi Azure Pipelines

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

Jeśli chodzi o zabezpieczanie usługi Azure Pipelines, należy pamiętać o kilku innych kwestiach, takich jak ochrona udostępnionej infrastruktury, repozytoriów, projektów i nie tylko.

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 oferują izolację i czystą maszynę wirtualną dla każdego uruchomienia potoku. Jeśli to możliwe, użyj pul hostowanych przez firmę Microsoft, a nie pul hostowanych samodzielnie.

Oddzielni agenci dla każdego projektu

Agent może być skojarzony 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 z kolei korzystać z tego samego agenta. Chociaż ekonomiczne, takie podejście może wprowadzać ryzyko ruchu bocznego.

Aby ograniczyć 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

Chociaż możesz być kuszony, uruchomienie agenta w ramach tożsamości z bezpośrednim dostępem do zasobów usługi Azure DevOps może być ryzykowne. Ta konfiguracja jest powszechna w organizacjach korzystających z identyfikatora Entra firmy Microsoft, ale stanowi zagrożenie. Jeśli uruchamiasz agenta w ramach tożsamości wspieranej przez identyfikator Firmy Microsoft Entra, może on bezpośrednio uzyskać dostęp do interfejsów API usługi Azure DevOps bez polegania na tokenie dostępu zadania. Aby uzyskać lepsze zabezpieczenia, rozważ uruchomienie agenta przy użyciu nieuprzywilejowanego konta lokalnego, takiego jak usługa sieciowa.

Ważne

W usłudze Azure DevOps istnieje grupa o nazwie Konta usług kolekcji projektów, która może być myląca. Po dziedziczeniu członkowie kont usługi kolekcji projektów są również traktowani jako członkowie administratorów kolekcji projektów. Niektórzy klienci uruchamiają swoich agentów kompilacji przy użyciu tożsamości wspieranej przez identyfikator Entra firmy Microsoft, a te tożsamości mogą być częścią kont usługi kolekcji projektów. Jeśli jednak przeciwnicy uruchamiają potok na jednym z tych agentów kompilacji, potencjalnie mogą przejąć kontrolę nad całą organizacją usługi Azure DevOps.

Istnieją wystąpienia, w których agenci self-hosted działają na kontach z wysokimi uprawnieniami. Ci agenci często używają tych uprzywilejowanych kont do uzyskiwania dostępu do wpisów tajnych lub środowisk produkcyjnych. Jeśli jednak przeciwnicy wykonują potok z naruszeniem zabezpieczeń na jednym z tych agentów kompilacji, uzyskują dostęp do tych wpisów tajnych. Następnie przeciwnicy mogą przechodzić później przez inne systemy dostępne za pośrednictwem tych kont.

Aby zwiększyć bezpieczeństwo systemu, zalecamy używanie konta z najniższymi uprawnieniami do uruchamiania własnych agentów. Rozważ na przykład użycie konta komputera lub tożsamości usługi zarządzanej. Ponadto należy powierzyć usłudze Azure Pipelines zarządzanie dostępem do wpisów tajnych i środowisk.

Minimalizuj zakres połączeń usług

Upewnij się, że połączenia usługi mają dostęp tylko do niezbędnych zasobów. Jeśli jest to możliwe, rozważ użycie federacji tożsamości obciążenia zamiast jednostki usługi dla połączenia usługi platformy Azure. Federacja tożsamości obciążenia używa technologii Open ID Connect (OIDC), standardowej technologii, aby ułatwić uwierzytelnianie między platformą Azure i usługą Azure DevOps bez polegania na wpisach tajnych.

Upewnij się, że twoje połączenie z usługą platformy Azure ma zakres dostępu tylko do niezbędnych zasobów. Unikaj udzielania szerokich praw współautora dla całej subskrypcji platformy Azure dla użytkowników.

Podczas tworzenia nowego połączenia usługi Azure Resource Manager zawsze wybieraj określoną grupę zasobów. Upewnij się, że grupa zasobów zawiera tylko niezbędne maszyny wirtualne lub zasoby wymagane do kompilacji. Podobnie podczas konfigurowania aplikacji GitHub przyznaj dostęp tylko do repozytoriów, które zamierzasz utworzyć przy użyciu usługi Azure Pipelines.

Ochrona projektów

Poza poszczególnymi zasobami kluczowe jest rozważenie grup zasobów w usłudze Azure DevOps. Zasoby organizują się według projektów zespołowych i rozumieją, do czego może uzyskiwać dostęp potok w oparciu o ustawienia i zawieranie projektu, jest niezbędne.

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. Oznacza to, że chociaż konto użytkownika może nie mieć bezpośredniego dostępu do określonego zasobu, skryptów i zadań uruchomionych w potoku, może 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 potoku do niektórych zasobów, ta decyzja dotyczy wszystkich potoków w projekcie — nie można selektywnie udzielić dostępu do otwartych 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 Ustawienia>organizacji Ustawienia potoków>lub bezpośrednio: . https://dev.azure.com/Organization_Name/_settings/pipelinessettings

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 repozytoriami publicznymi z usługi GitHub ważne jest, aby dokładnie rozważyć podejście do kompilacji rozwidlenia. Rozwidlenia pochodzące z spoza organizacji stanowią szczególne ryzyko. Aby chronić produkty przed potencjalnie niezaufanym kodem, weź pod uwagę następujące zalecenia

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 są skonfigurowane do tworzenia rozwidlenia, ale wpisy tajne i chronione zasoby nie są automatycznie widoczne dla zadań w tych potokach. Nie należy wyłączać tej ochrony w celu zachowania bezpieczeństwa.

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

Możesz wyłączyć automatyczne kompilacje rozwidlenia i zamiast tego używać komentarzy żądania ściągnięcia jako sposobu ręcznego kompilowania tych współtworzeń. 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. Może to umożliwić organizacjom zewnętrznym wykonywanie kodu zewnętrznego 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 w rozwidlonym żądaniu ściągnięcia dokładnie przejrzyj proponowane zmiany i upewnij się, że dobrze się z nim uruchamiasz.

Wersja uruchomionego potoku YAML jest wersją z żądania ściągnięcia. W związku z tym należy zwrócić 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, na przykład aplikacji 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 kod YAML zostanie użyty do uruchomienia potoku. Chociaż ten projekt zapewnia dużą elastyczność i samoobsługę, nie wszystkie zmiany są bezpieczne (niezależnie od tego, 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ę kilka innych kwestii.

Polegaj na ścieżce

Poleganie na ustawieniu agenta PATH jest niebezpieczne. Może nie wskazywać, gdzie to robisz, ponieważ został on potencjalnie zmieniony przez poprzedni skrypt lub narzędzie. 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 wyczyścić 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. Można oznaczyć dowolne lub wszystkie te woluminy 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 powinna ustawić pierwsze trzy katalogi jako tylko do odczytu i pozostawić work jako read-write. 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, co umożliwia większą kontrolę nad kodem wykonywanym w potoku. Możesz również wyłączyć wszystkie zadania w polu (z wyjątkiem wyewidencjonowania, która jest specjalną akcją na agencie). Zalecamy, aby w większości przypadków nie wyłączać zadań wbudowanych.

Zadania instalowane bezpośrednio z tfx programem są zawsze dostępne. Po włączeniu obu tych funkcji dostępne są tylko te zadania.

Korzystanie z usługi inspekcji

Wiele zdarzeń potoku jest rejestrowanych w usłudze Inspekcja. Okresowo przejrzyj dziennik inspekcji, aby upewnić się, że żadne złośliwe zmiany nie spadły w przeszłości. Odwiedź stronę https://dev.azure.com/ORG-NAME/_settings/audit , aby rozpocząć pracę.

Następne kroki

Przegląd zabezpieczeń