Najlepsze rozwiązania dotyczące zabezpieczeń

Artykuł
08/14/2024

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

W przypadku obsługi informacji i danych, zwłaszcza w rozwiązaniu opartym na chmurze, takiego jak Azure DevOps Services, bezpieczeństwo powinno być twoim priorytetem. Chociaż firma Microsoft zapewnia bezpieczeństwo podstawowej infrastruktury chmury, konfigurowanie zabezpieczeń w usłudze Azure DevOps jest Twoim zadaniem.

Chociaż nie jest to obowiązkowe, włączenie najlepszych rozwiązań może znacząco poprawić twoje środowisko i wzmocnić bezpieczeństwo. Poniższe zalecenia zostały zaprojektowane tak, aby ułatwić utrzymanie bezpiecznego środowiska usługi Azure DevOps.

Zabezpieczanie środowiska usługi Azure DevOps

Zastosuj następujące najlepsze rozwiązania dotyczące usuwania użytkowników, przeglądania zdarzeń inspekcji i integracji z identyfikatorem Entra firmy Microsoft.

Usuwanie użytkowników

Usuń nieaktywnych użytkowników z kont Microsoft (MSA): bezpośrednio usuń nieaktywnych użytkowników z organizacji , jeśli korzystasz z kont MSA. Nie można tworzyć zapytań dotyczących elementów roboczych przypisanych do usuniętych kont MSA.
Wyłącz lub usuń konta użytkowników usługi Microsoft Entra: jeśli nawiązane połączenie z identyfikatorem Entra firmy Microsoft, wyłącz lub usuń konto użytkownika Microsoft Entra przy zachowaniu aktywnego konta użytkownika usługi Azure DevOps. Ta akcja umożliwia kontynuowanie wykonywania zapytań dotyczących historii elementów roboczych przy użyciu identyfikatora użytkownika usługi Azure DevOps.
Odwoływanie paT użytkowników: regularnie przeglądaj i odwołuj istniejące dostawcy tożsamości użytkowników, aby zapewnić bezpieczne zarządzanie tymi krytycznymi tokenami uwierzytelniania.
Odwoływanie specjalnych uprawnień przyznanych poszczególnym użytkownikom: przeprowadź inspekcję i odwoływanie wszelkich specjalnych uprawnień przyznanych poszczególnym użytkownikom w celu zapewnienia zgodności z zasadą najniższych uprawnień.
Przypisz ponownie pracę od usuniętych użytkowników: przed usunięciem użytkowników przypisz ponownie elementy robocze do bieżących członków zespołu w celu efektywnego rozłożenia obciążenia.

Korzystanie z identyfikatora Entra firmy Microsoft

Ustanów ujednolicony system tożsamości: połącz usługę Azure DevOps z identyfikatorem Entra firmy Microsoft, aby utworzyć jedną płaszczyznę dla tożsamości. Ta spójność zmniejsza nieporozumienie i minimalizuje zagrożenia bezpieczeństwa przed błędami konfiguracji ręcznej.
Implementowanie szczegółowego ładu: użyj identyfikatora Entra firmy Microsoft, aby przypisać różne role i uprawnienia do określonych grup w różnych zakresach zasobów. Ta akcja zapewnia kontrolowany dostęp i jest zgodny z najlepszymi rozwiązaniami w zakresie zabezpieczeń.
Ulepszanie funkcji zabezpieczeń: Włącz inne funkcje zabezpieczeń za pomocą identyfikatora Entra firmy Microsoft, na przykład:
- Uwierzytelnianie wieloskładnikowe (MFA): wymagaj wielu czynników, takich jak hasło i weryfikacja telefonu na potrzeby uwierzytelniania użytkownika. Zasady dostępu warunkowego: zdefiniuj reguły dostępu na podstawie warunków, takich jak lokalizacja, urządzenie lub poziom ryzyka.

Aby uzyskać więcej informacji, zobacz następujące artykuły:

Przeglądanie zdarzeń inspekcji

W twojej organizacji połączonej z firmą Microsoft Entra wykonaj następujące zadania, aby zwiększyć bezpieczeństwo i monitorować wzorce użycia:

Włącz inspekcję: śledzenie i wyświetlanie zdarzeń związanych z akcjami użytkownika, uprawnieniami i zmianami.
Regularnie przeglądaj zdarzenia inspekcji: poszukaj nieoczekiwanych wzorców użycia, zwłaszcza przez administratorów i innych użytkowników.

Zabezpieczanie sieci

Poniższe funkcje są skutecznymi sposobami zwiększenia bezpieczeństwa sieci podczas pracy z usługą Azure DevOps.

Konfigurowanie listy dozwolonych adresów IP: ogranicz dostęp do określonych adresów IP, aby zezwolić na ruch tylko z zaufanych źródeł, zmniejszając obszar ataków.
Użyj szyfrowania: zawsze szyfruj dane podczas przesyłania i przechowywania. Zabezpieczanie kanałów komunikacyjnych przy użyciu protokołów, takich jak HTTPS.
Weryfikowanie certyfikatów: Upewnij się, że certyfikaty są prawidłowe i wystawione przez zaufane urzędy podczas nawiązywania połączeń.
Implementowanie zapór aplikacji internetowych (WAFs): filtrowanie, monitorowanie i blokowanie złośliwego ruchu internetowego za pomocą funkcji WAFs w celu uzyskania dodatkowej warstwy ochrony przed typowymi atakami.

Aby uzyskać więcej informacji, zobacz Najlepsze rozwiązania dotyczące zarządzania aplikacjami.

Uprawnienia zakresu

System obsługuje uprawnienia na różnych poziomach — indywidualne, kolekcje, projekt i obiekt — i przypisuje je do co najmniej jednej wbudowanej grupy domyślnie. Aby zwiększyć bezpieczeństwo, wykonaj następujące czynności:

Zapewnianie dostępu do najniższych uprawnień: zapewnij użytkownikom i usługom minimalny niezbędny dostęp do wykonywania swoich funkcji biznesowych.
Wyłącz dziedziczenie: zawsze, gdy to możliwe, wyłącz dziedziczenie. Dziedziczenie może przypadkowo udzielić dostępu lub uprawnień nieoczekiwanym użytkownikom ze względu na jej charakter dozwolony domyślnie. Aby uzyskać więcej informacji, zobacz sekcję dotyczącą dziedziczenia uprawnień

Aby uzyskać więcej informacji na temat uprawnień, zobacz następujące artykuły:

Uprawnienia na poziomie projektu

Ograniczanie dostępu do projektów i repozytoriów: zmniejsza ryzyko wycieku poufnych informacji i wdrażania niezabezpieczonego kodu przez ograniczenie dostępu do projektów i repozytoriów. Użyj wbudowanych lub niestandardowych grup zabezpieczeń, aby zarządzać uprawnieniami.
Wyłącz opcję "Zezwalaj na projekty publiczne": w ustawieniach zasad organizacji wyłącz opcję tworzenia projektów publicznych. W razie potrzeby przełącz widoczność projektu z publicznego na prywatny. Użytkownicy, którzy nie zalogowali się, mają dostęp tylko do odczytu do projektów publicznych, podczas gdy zalogowani użytkownicy mogą mieć dostęp do projektów prywatnych i wprowadzać dozwolone zmiany.
Ogranicz tworzenie projektu: uniemożliwia użytkownikom tworzenie nowych projektów w celu utrzymania kontroli nad środowiskiem.

Dostęp gościa zewnętrznego

Blokuj dostęp gościa zewnętrznego: wyłącz zasady "Zezwalaj na wysyłanie zaproszeń do dowolnej domeny", aby zapobiec dostępowi gościa zewnętrznemu, jeśli nie ma potrzeby jej działania.
Użyj odrębnych wiadomości e-mail lub nazw UPN: użyj różnych adresów e-mail lub głównych nazw użytkowników (UPN) dla kont osobistych i biznesowych, aby wyeliminować niejednoznaczność między kontami osobistymi i służbowymi.
Grupuj zewnętrznych użytkowników-gości: umieść wszystkich zewnętrznych użytkowników-gości w jednej grupie Firmy Microsoft Entra i odpowiednio zarządzaj uprawnieniami dla tej grupy. Usuń przypisania bezpośrednie, aby upewnić się, że reguły grupy mają zastosowanie do tych użytkowników.
Regularnie oceniaj reguły: regularnie przeglądaj reguły na karcie Reguły grupy na stronie Użytkownicy. Rozważ wszelkie zmiany członkostwa w grupie w identyfikatorze Entra firmy Microsoft, które mogą mieć wpływ na Twoją organizację. Aktualizacja członkostwa w grupie dynamicznej może potrwać do 24 godzin, a reguły są automatycznie ponownie oceniane co 24 godziny i zawsze, gdy zmienia się reguła grupy.

Aby uzyskać więcej informacji, zobacz B2B gości w identyfikatorze Microsoft Entra ID.

Zarządzanie grupami zabezpieczeń

Zabezpieczenia i grupy użytkowników

W poniższej tabeli przedstawiono zalecenia dotyczące przypisywania uprawnień do grup zabezpieczeń i grup użytkowników.

Robić	Nie
Użyj identyfikatora Entra firmy Microsoft, usługi Active Directory lub grup zabezpieczeń systemu Windows, gdy zarządzasz wieloma użytkownikami.	*Nie zmieniaj domyślnych uprawnień dla grupy Project Valid Users (Prawidłowe użytkownicy* projektu).** Ta grupa może uzyskiwać dostęp do informacji o projekcie i wyświetlać je. Aby uzyskać więcej informacji, zobacz Prawidłowe grupy użytkowników.
Podczas dodawania zespołów należy wziąć pod uwagę uprawnienia, które chcesz przypisać członkom zespołu, którzy muszą tworzyć i modyfikować ścieżki obszaru, ścieżki iteracji i zapytania.	Nie dodawaj użytkowników do wielu grup zabezpieczeń, które zawierają różne poziomy uprawnień. W niektórych przypadkach poziom uprawnień Odmów może zastąpić poziom uprawnień Zezwalaj . Załóżmy na przykład, że masz dwie grupy zabezpieczeń w projekcie usługi Azure DevOps: Deweloperzy i Testerzy. Grupa Deweloperzy ma uprawnienia do edytowania elementów roboczych ustawionych na Wartość Zezwalaj. Upewnij się jednak, że niektóre poufne elementy robocze nie są edytowane przez nikogo, z wyjątkiem kilku kluczowych osób. W tym celu utwórz nową grupę zabezpieczeń o nazwie Poufne elementy Edytory i ustaw uprawnienie do edytowania elementów roboczych na Odmów dla tej grupy. Jeśli użytkownik jest członkiem grupy Deweloperzy i Edytory elementów poufnych, uprawnienie Odmów z grupy Edytory elementów poufnych ma pierwszeństwo przed uprawnieniem Zezwalaj z grupy Deweloperzy. W związku z tym ten użytkownik nie może edytować poufnych elementów roboczych, mimo że ma uprawnienie Zezwalaj w grupie Deweloperzy . To zachowanie gwarantuje, że uprawnienia odmowy są wymuszane ściśle, zapewniając wyższy poziom zabezpieczeń i kontrolę nad poufnymi akcjami w środowisku usługi Azure DevOps.
Podczas dodawania wielu zespołów rozważ utworzenie grupy niestandardowej Administratorzy zespołu, w której przydzielasz podzestaw uprawnień dostępnych dla administratorów projektu.	*Nie zmieniaj domyślnych przypisań dokonanych w grupach Project Valid Users* .** Jeśli usuniesz lub ustawisz opcję Wyświetl informacje na poziomie wystąpienia na wartość Odmów dla jednej z grup Project Valid Users , żaden użytkownik w grupie nie będzie mógł uzyskać dostępu do dowolnego projektu, kolekcji lub wdrożenia, dla którego ustawiono uprawnienie.
Rozważ przyznanie folderom zapytań elementu roboczego uprawnienie Współtworzenie użytkownikom lub grupom, którzy wymagają możliwości tworzenia i udostępniania zapytań dotyczących elementów roboczych dla projektu.	*Nie przypisuj uprawnień, które są zanotowane jako Przypisywanie tylko do kont usług do kont* użytkowników.**
Zachowaj możliwie najmniejsze grupy. Dostęp powinien być ograniczony, a grupy powinny być często poddawane inspekcji.
Korzystaj z wbudowanych ról i domyślnych ról współautora dla deweloperów. Administratorzy uzyskują przypisanie do grupy zabezpieczeń Administrator projektu w celu uzyskania podwyższonych uprawnień, co pozwala im skonfigurować uprawnienia zabezpieczeń.

Dostęp just in time dla grup administratorów

Jeśli masz dostęp administratora kolekcji projektów i administratora projektu, możesz zmodyfikować konfigurację organizacji lub projektu. Aby zwiększyć bezpieczeństwo tych wbudowanych grup administratorów, rozważ zaimplementowanie dostępu just in time przy użyciu grupy usługi Microsoft Entra Privileged Identity Management (PIM). Takie podejście umożliwia przyznawanie podwyższonych uprawnień tylko wtedy, gdy jest to konieczne, co zmniejsza ryzyko związane z trwałym dostępem.

Konfigurowanie dostępu

Utwórz grupę z możliwością przypisywania ról w identyfikatorze Entra firmy Microsoft.
Dodaj grupę Microsoft Entra do grupy usługi Azure DevOps.

Uwaga

Podczas konfigurowania dostępu just in time przy użyciu grupy microsoft Entra Privileged Identity Management (PIM) upewnij się, że każdy użytkownik z podwyższonym poziomem dostępu zachowuje również standardowy dostęp do organizacji. Dzięki temu mogą wyświetlać niezbędne strony i odświeżać uprawnienia zgodnie z potrzebami.

Korzystanie z dostępu

Aktywuj dostęp.
Odśwież swoje uprawnienia w usłudze Azure DevOps.
Wykonaj akcję wymagającą dostępu administratora.

Uwaga

Użytkownicy mają podwyższony poziom dostępu w usłudze Azure DevOps przez maksymalnie 1 godzinę po dezaktywowaniu dostępu do grupy PIM.

Określanie zakresu kont usług

Tworzenie kont usług jednofunkcyjnych: każda usługa powinna mieć swoje dedykowane konto, aby zminimalizować ryzyko. Unikaj używania zwykłych kont użytkowników jako kont usług.
Postępuj zgodnie z konwencjami nazewnictwa i dokumentacji: używaj przejrzystych, opisowych nazw kont usług i dokumentowania ich przeznaczenia i skojarzonych usług.
Identyfikowanie i wyłączanie nieużywanych kont usług: regularnie przeglądaj i identyfikuje konta, które nie są już używane. Wyłącz nieużywane konta przed rozważeniem usunięcia.
Ogranicz uprawnienia: ogranicz uprawnienia konta usługi do minimum niezbędnego. Unikaj interaktywnych praw logowania dla kont usług.
Użyj oddzielnych tożsamości dla czytelników raportów: jeśli używasz kont domeny dla kont usług, użyj innej tożsamości dla czytelników raportów, aby odizolować uprawnienia i zapobiec niepotrzebnemu dostępowi.
Użyj kont lokalnych dla instalacji grup roboczych: podczas instalowania składników w grupie roboczej użyj kont lokalnych dla kont użytkowników. Unikaj kont domeny w tym scenariuszu.
Korzystanie z połączeń usług: używaj połączeń z usługami, gdy tylko jest to możliwe, aby bezpiecznie łączyć się z usługami bez bezpośredniego przekazywania zmiennych tajnych do kompilacji. Ogranicz połączenia z określonymi przypadkami użycia.
Monitorowanie aktywności konta usługi: zaimplementuj inspekcję i utwórz strumienie inspekcji w celu monitorowania aktywności konta usługi.

Aby uzyskać więcej informacji, zobacz Typowe typy połączeń usługi.

Zakres połączeń usług

Połączenia usług zakresu: ogranicz dostęp, określając zakres połączeń usługi Azure Resource Manager z określonymi zasobami i grupami. Unikaj udzielania szerokich praw współautora w całej subskrypcji platformy Azure.
Użyj federacji tożsamości obciążenia: uwierzytelnianie za pomocą zasobów platformy Azure przy użyciu protokołu OpenID Connect (OIDC) bez wpisów tajnych. Utwórz federację tożsamości obciążenia automatycznie lub ręcznie, jeśli masz rolę Właściciel dla subskrypcji platformy Azure, nie łączy się ze środowiskami azure Stack lub Azure US Government, a wszystkie zadania rozszerzeń witryny Marketplace, których używasz, obsługują.
Grupy zasobów zakresu: upewnij się, że grupy zasobów zawierają tylko maszyny wirtualne lub zasoby potrzebne do procesu kompilacji.
Unikaj połączeń usługi klasycznej: wybierz nowoczesne połączenia usługi Azure Resource Manager zamiast klasyczne, które nie mają opcji określania zakresu.
Użyj kont usług zespołowych specyficznych dla celu: Uwierzytelnianie połączeń usług przy użyciu kont usług zespołowych specyficznych dla celu w celu zachowania zabezpieczeń i kontroli.

Aby uzyskać więcej informacji, zobacz Typowe typy połączeń usługi.

Wybieranie odpowiedniej metody uwierzytelniania

Wybierz metody uwierzytelniania z następujących źródeł:

Rozważ jednostki usługi i tożsamości zarządzane
Używanie osobistych tokenów dostępu (PATs) oszczędnie

Rozważ jednostki usługi

Zapoznaj się z alternatywami, takimi jak jednostki usługi i tożsamości zarządzane:

Użyj jednostek usługi: reprezentuje obiekty zabezpieczeń w aplikacji Firmy Microsoft Entra. Zdefiniuj, co aplikacja może zrobić w danej dzierżawie. Konfigurowanie podczas rejestracji aplikacji w witrynie Azure Portal. Konfigurowanie dostępu do zasobów platformy Azure, w tym usługi Azure DevOps. Przydatne w przypadku aplikacji wymagających określonego dostępu i kontroli.
Użyj tożsamości zarządzanych: podobnie jak jednostka usługi aplikacji. Podaj tożsamości dla zasobów platformy Azure. Zezwalaj usługom obsługującym uwierzytelnianie firmy Microsoft Entra na udostępnianie poświadczeń. Platforma Azure automatycznie obsługuje zarządzanie poświadczeniami i rotację. Idealne rozwiązanie do bezproblemowego zarządzania szczegółami logowania.

Używanie pats oszczędnie

Zakres paTs do określonych ról: przypisz pats tylko niezbędne uprawnienia do określonych zadań. Unikaj udzielania globalnego dostępu do wielu organizacji lub repozytoriów, aby zminimalizować ryzyko przypadkowego nieprawidłowego użycia.
Unikaj uprawnień zapisu lub zarządzania uprawnieniami do kompilacji i wydań: pakiety PAT nie powinny mieć uprawnień do zapisu lub zarządzania kompilacjami, wydaniami ani innymi krytycznymi zasobami. Ograniczenie tych uprawnień pomaga zapobiegać niezamierzonym akcjom, które mogą mieć wpływ na potoki lub wdrożenia.
Ustaw daty wygaśnięcia i zachowaj wpis tajny usługi PATs: zawsze ustawiaj datę wygaśnięcia dla punktów dostępu uprzywilejowanego. Regularnie przeglądaj i odnawiaj je zgodnie z potrzebami. Traktuj paTs jako krytyczne jako hasła, zachowując ich poufne i unikając udostępniania publicznego lub trwałego kodowania w kodzie aplikacji.
Unikaj trwałego kodowania pats w kodzie aplikacji: Zamiast osadzania paTs bezpośrednio w kodzie, używaj bezpiecznych plików konfiguracji lub zmiennych środowiskowych do przechowywania i pobierania paTs dynamicznie. dynamicznie.
Regularnie przeprowadzaj inspekcję i odwoływanie nieużywanych punktów dostępu uprzywilejowanego: administratorzy powinni okresowo przeglądać wszystkie pakiety PAT przy użyciu interfejsów API REST. Odwoływanie żadnych paT, które nie są już potrzebne lub nie spełniają zalecanych kryteriów.

Aby uzyskać więcej informacji, zobacz Manage PATs with policies - for administrators and Use PATs (Zarządzanie sieciami uprzywilejowanymi przy użyciu zasad — dla administratorów i używanie sieci PAT).

Zabezpieczanie usługi Azure Artifacts

Upewnij się, że rozumiesz różnicę między kanałami informacyjnymi, projektami i administratorami kolekcji projektów. Aby uzyskać więcej informacji, zobacz Konfigurowanie ustawień usługi Azure Artifacts.
Ustaw uprawnienia kanału informacyjnego.

Zabezpieczanie usługi Azure Boards

Zabezpieczanie usługi Azure Pipelines

Użyj szablonów rozszerzeń.
Ustawianie uprawnień potoku
Omówienie zabezpieczania usługi Azure Pipelines.

Zasady

Wymagaj zewnętrznych recenzentów: upewnij się, że co najmniej jeden recenzent spoza oryginalnego osoby żądającego w celu przeprowadzenia dokładnego procesu przeglądu. Osoba zatwierdzająca współwłaściciel zmiany i odpowiedzialność za wszelkie potencjalne skutki.
Wymagaj przekazania kompilacji ciągłej integracji: ustanów punkt odniesienia dla jakości kodu, wymagając przekazania kompilacji ciągłej integracji przed scaleniem żądania ściągnięcia. Testy ciągłej integracji obejmują linting kodu, testy jednostkowe i skanowania zabezpieczeń.
Nie zezwalaj na samodzielne zatwierdzanie: Uniemożliwiaj oryginalnemu żądającemu żądania ściągnięcia zatwierdzenie własnych zmian w celu zapewnienia niezachwianego procesu przeglądu i uniknięcia konfliktów interesów.
Nie zezwalaj na ukończenie żądania ściągnięcia za pomocą głosów "wait" lub "reject": Zapobiegaj uzupełnianiu żądania ściągnięcia, nawet jeśli niektórzy recenzenci głosują na czekanie lub odrzucanie, zachęcając do przesyłania wszystkich opinii przed scaleniem.
Resetuj głosy recenzentów dotyczące zmian: resetuj głosy recenzentów po wypchnięciu ostatnich zmian do żądania ściągnięcia, aby zapewnić recenzentom ponowne oceny zaktualizowanego kodu.
Blokowanie potoków wydania: ogranicz potoki wydania do określonych gałęzi (zwykle produkcyjnych lub głównych), aby uniknąć przypadkowych wdrożeń z innych gałęzi.
Wymuszanie zmiennych ustawianych w czasie kolejki: włącz opcję "Wymuszaj tabelę ustawiania w kolejce" dla zmiennych potoku, aby uniemożliwić użytkownikom zastępowanie wartości zmiennych podczas wykonywania potoku.
Nie zezwalaj na przesłonięcia zmiennych w edytorze: w przypadku zmiennych ustawionych w edytorze potoku nie zezwalaj na zastępowanie użytkowników w celu zachowania spójności i zapobiegania niezamierzonym zmianom.

Agenci

Udziel uprawnień oszczędnie: ogranicz uprawnienia do najmniejszego niezbędnego zestawu kont w celu zmniejszenia obszaru ataków.
Konfigurowanie restrykcyjnych zapór dla agentów: skonfiguruj zapory tak restrykcyjne, jak to możliwe, jednocześnie zezwalając agentom na działanie, równoważenie zabezpieczeń i użyteczności.
Regularnie aktualizuj pule agentów: aktualizuj flotę agentów, regularnie aktualizując agentów w celu zapewnienia, że kod podatny na zagrożenia nie działa, zmniejszając ryzyko wykorzystania.
Użyj oddzielnej puli agentów dla artefaktów produkcyjnych: izoluj artefakty produkcyjne przy użyciu odrębnej puli agentów, uniemożliwiając przypadkowe wdrożenia z gałęzi nieprodukcyjnych.
Pule poufne segmentów: utwórz oddzielne pule dla obciążeń poufnych i niewrażliwych. Zezwalaj tylko na poświadczenia w definicjach kompilacji skojarzonych z odpowiednią pulą.

Definicje

Użyj języka YAML dla definicji potoków: zdefiniuj potoki przy użyciu języka YAML (Yet Another Markup Language), aby uzyskać lepszą możliwość śledzenia i przestrzeganie wytycznych dotyczących zatwierdzania i praktyk kontroli wersji.
Ogranicz dostęp do edycji definicji potoków: ogranicz dostęp do edycji definicji potoków do minimalnych niezbędnych kont, aby zmniejszyć ryzyko przypadkowych lub nieautoryzowanych zmian.

Dane wejściowe

Uwzględnij kontrole zmiennych w skryptach kompilacji: Zaimplementuj kontrole w skryptach kompilacji w celu ograniczenia potencjalnych ataków polegających na wstrzyknięciu poleceń za pomocą zmiennych settable. Zweryfikuj wartości wejściowe i zapobiegaj niezamierzonym lub złośliwym poleceniom.
Ogranicz zmienne kompilacji "settable at release time": Minimalizuj liczbę zmiennych kompilacji ustawianych w czasie wydania, aby zmniejszyć obszar ataków i uprościć zarządzanie konfiguracją.

Zadania

Unikaj zdalnego pobierania zasobów: zawsze, gdy to możliwe, unikaj pobierania zasobów z zewnętrznych adresów URL podczas procesu kompilacji. Jeśli zasoby zdalne są niezbędne, użyj sprawdzania wersji i skrótu, aby zapewnić integralność.
Unikaj rejestrowania wpisów tajnych: nigdy nie rejestruj poufnych informacji, takich jak wpisy tajne lub poświadczenia, w dziennikach kompilacji, aby zapobiec przypadkowemu narażeniu i naruszeniu zabezpieczeń.
Użyj usługi Azure Key Vault dla wpisów tajnych: zamiast przechowywać wpisy tajne bezpośrednio w zmiennych potoku, użyj usługi Azure Key Vault do bezpiecznego zarządzania wpisami tajnymi i pobierania ich.
Ogranicz uruchamianie kompilacji względem dowolnych gałęzi lub tagów: w przypadku potoków krytycznych pod względem zabezpieczeń ogranicz użytkownikom uruchamianie kompilacji względem dowolnej gałęzi lub tagu. Zdefiniuj określone autoryzowane gałęzie lub tagi, aby zapobiec przypadkowym lub nieautoryzowanym wykonywaniu.
Wyłącz dziedziczenie dla uprawnień potoku: uprawnienia dziedziczone mogą być zbyt szerokie i mogą nie odzwierciedlać dokładnie Twoich potrzeb. Wyłącz dziedziczenie i jawnie ustaw uprawnienia zgodnie z wymaganiami dotyczącymi zabezpieczeń.
Ogranicz zakresy autoryzacji zadań: zawsze ogranicz zakresy autoryzacji zadań do minimum niezbędnego. Dostosuj uprawnienia na podstawie określonych zadań wykonywanych przez każde zadanie.

Repozytoria i gałęzie

Wymagaj minimalnej liczby recenzentów: włącz zasady, aby zapewnić, że każde żądanie ściągnięcia odbiera przeglądy od co najmniej dwóch osób zatwierdzających, promując dokładne przeglądy kodu i odpowiedzialność.
Konfigurowanie zasad zabezpieczeń specyficznych dla repozytorium: dostosuj zasady zabezpieczeń do każdego repozytorium lub gałęzi zamiast zasad dotyczących całego projektu, aby zmniejszyć ryzyko, wymusić standardy zarządzania zmianami i zwiększyć jakość kodu.
Izolowanie wpisów tajnych produkcyjnych w oddzielnym magazynie kluczy: przechowywanie wpisów tajnych produkcyjnych oddzielnie w usłudze Azure Key Vault i ograniczanie dostępu do bazy wiedzy wymagającej znajomości w celu zachowania separacji od kompilacji nieprodukcyjnych.
Segreguj środowiska testowe z środowiska produkcyjnego: unikaj mieszania środowisk testowych z produkcją, aby upewnić się, że poświadczenia i wpisy tajne nie są używane w kontekstach nieprodukcyjnych.
Wyłącz rozwidlenia: wyłączenie rozwidlenia ułatwia zarządzanie zabezpieczeniami przez zapobieganie rozprzestrzenianiu się rozwidlenia, co ułatwia śledzenie zabezpieczeń we wszystkich kopiach.
Unikaj dostarczania wpisów tajnych do rozwidlenia kompilacji: Powstrzymaj się od udostępniania wpisów tajnych z rozwidlonych kompilacji, aby zachować je poufne i nie są narażone na rozwidlenia.
Rozważ ręczne wyzwalanie kompilacji rozwidlenia: ręczne wyzwalanie kompilacji forksów zamiast zezwalania automatycznym wyzwalaczom na lepszą kontrolę nad sprawdzaniem zabezpieczeń.
Używaj agentów hostowanych przez firmę Microsoft dla kompilacji rozwidlenia: używaj agentów hostowanych przez firmę Microsoft w przypadku kompilacji rozwidlonych w miarę ich konserwacji i bezpieczeństwa.
Skanuj definicje kompilacji produkcyjnych w repozytoriach Git: regularnie sprawdzaj definicje kompilacji produkcyjnej przechowywane w repozytorium Git projektu pod kątem wszelkich poświadczeń lub poufnych informacji.
Konfigurowanie kontroli gałęzi dla kontekstu produkcyjnego: skonfiguruj kontrole kontroli gałęzi, aby ograniczyć używanie połączeń poufnych (na przykład prod-connection) do potoków uruchomionych w kontekście gałęzi produkcyjnej, zapewniając właściwą autoryzację i zapobiegając przypadkowemu niewłaściwemu użyciu.

Aby uzyskać więcej informacji, zobacz Inne zagadnienia dotyczące zabezpieczeń.

Zabezpieczanie usługi Azure Repos

Zabezpieczanie planów testów platformy Azure

Zabezpieczanie integracji z usługą GitHub

Użyj przepływu OAuth zamiast paTs: wyłącz uwierzytelnianie oparte na pat dla połączeń usługi GitHub i wybierz przepływ OAuth w celu zapewnienia lepszych zabezpieczeń i integracji.
Unikaj tożsamości administratora lub właściciela: nigdy nie uwierzytelniaj połączeń usługi GitHub przy użyciu tożsamości, która jest administratorem lub właścicielem jakichkolwiek repozytoriów. Ogranicz uprawnienia do niezbędnego poziomu.
Unikaj pełnozakresowych paT usługi GitHub: powstrzymaj się od używania pełnego zakresu dostępu do usługi GitHub w celu uwierzytelniania połączeń usług. Użyj tokenów z minimalnymi wymaganymi uprawnieniami.
Unikaj osobistych kont usługi GitHub jako połączeń usług: nie używaj osobistych kont usługi GitHub jako połączeń usług w usłudze Azure DevOps. Zamiast tego utwórz dedykowane konta usług lub użyj kont na poziomie organizacji.

Udostępnij za pośrednictwem