Zabezpieczanie repozytoriów i żądań ściągnięcia

Usługi Azure DevOps | Azure DevOps Server | Azure DevOps Server 2022

Zabezpiecz Azure Repos, łącząc kontrolę dostępu, zasady dla żądań ściągnięcia i sprawdzanie stanu najważniejszych gałęzi. W tym artykule opisano, jak ograniczyć bezpośrednie zmiany, wymagać zatwierdzenia przez odpowiednich recenzentów, wymuszać wymagania dotyczące elementów pracy i kompilacji oraz dodać kontrole usługi GitHub Advanced Security przed scaleniem żądań pull request.

Zagrożenia i mechanizmy kontroli

Użyj poniższych mechanizmów razem, aby ograniczyć najczęstsze ryzyka związane z pull requestami.

Prerequisites

Przed skonfigurowaniem zasad gałęzi:

• Upewnij się, że repozytorium docelowe i gałąź już istnieją.
• Zdecyduj, które grupy mogą zarządzać uprawnieniami, pomijać zasady i zatwierdzać żądania pull request.
• Jeśli planujesz wymagać walidacji kompilacji lub kontroli stanu GitHub Advanced Security, najpierw utwórz potok kompilacji.

Punkt odniesienia zabezpieczeń dla większości zespołów

W przypadku typowej gałęzi produkcyjnej, takiej jak main, zacznij od tego punktu odniesienia:

Krok 1. Ograniczanie dostępu do repozytorium i gałęzi

Zacznij od uprawnień. Zasady są najbardziej skuteczne, gdy tylko niewielki zestaw użytkowników może je pominąć.

Przeglądanie uprawnień repozytorium

Uprawnienia repozytorium umożliwiają kontrolowanie, kto może odczytywać, współtworzyć, administrować ustawieniami lub współtworzyć żądania ściągnięcia. Aby uzyskać szczegółowe informacje o uprawnieniach, zobacz Ustawianie uprawnień repozytorium Git.

Użyj następującego wzorca:

• Udziel współtwórcom uprawnień, których potrzebują do pracy w gałęziach funkcji.
• Rezerwuj administrowanie repozytorium dla małej grupy administracyjnej.
• Unikaj szerokiego przyznawania uprawnień pomijania zasad.

Ogranicz uprawnienia gałęzi

W przypadku chronionych gałęzi dokładnie przejrzyj i ogranicz następujące uprawnienia:

• Pomijanie zasad podczas finalizowania pull requestów
• Omijanie zasad przy wypychaniu
• Wymuszone wypychanie (przepisywanie historii, usuwanie gałęzi i tagów)
• Edytowanie zasad
• Zarządzanie uprawnieniami

Użyj opcji Ustaw uprawnienia gałęzi, aby skonfigurować te ustawienia.

Zalecany wzorzec dla main:

Krok 2. Wymagaj rygorystycznego przeglądu pull requestów

Wymaganie minimalnej liczby recenzentów

Użyj opcji Wymagaj minimalnej liczby recenzentów w przypadku ważnych gałęzi, takich jak main i gałęzie wydań.

Zalecane ustawienia:

• Minimalna liczba recenzentów: 2 dla gałęzi współdzielonych o wysokiej wartości
• Wymagaj co najmniej jednego zatwierdzenia w ostatniej iteracji
• Zezwalaj osobom zgłaszającym na zatwierdzanie własnych zmian: Off
• Zabroń osobie, która ostatnio wypchnęła zmiany, zatwierdzania własnych zmian: On gdy chcesz zapewnić większy rozdział obowiązków

Konfigurowanie minimalnych zasad recenzenta

az repos policy approver-count create \
  --blocking true \
  --branch main \
  --enabled true \
  --minimum-approver-count 2 \
  --creator-vote-counts false \
  --reset-on-source-push true \
  --repository-id <repository-id>

Sprawdź wynik:

• Lista zasad gałęzi pokazuje, że zasady recenzentów są włączone.
• Żądania pull request kierowane do gałęzi nie mogą zostać ukończone, dopóki nie zostanie uzyskana wymagana liczba zatwierdzeń.

Aby uzyskać szczegółowe informacje o zasadach, zobacz Zasady i ustawienia gałęzi.

Automatyczne dołączanie recenzentów do poufnych plików

Użyj Recenzenci dodawani automatycznie, gdy określone pliki lub foldery wymagają zatwierdzenia przez konkretną osobę lub zespół.

Dobrymi kandydatami są:

• wdrażanie i kod infrastruktury
• kod uwierzytelniania i autoryzacji
• foldery wrażliwe na zgodność
• udostępnione szablony potoków

Skonfiguruj zasady automatycznego uwzględniania recenzentów

az repos policy required-reviewer create \
  --blocking true \
  --branch main \
  --enabled true \
  --message "Security review required for protected paths." \
  --path-filter "/.azure/*;/infra/*;/pipelines/*" \
  --repository-id <repository-id> \
  --required-reviewer-ids <reviewer-email-or-emails>

Sprawdź wynik:

• Żądanie ściągnięcia, które zmienia pasujące pliki, automatycznie dodaje skonfigurowanych recenzentów.
• Żądanie ściągnięcia nie może zakończyć się, dopóki wymagane zasady recenzenta nie będą spełnione.

Aby uzyskać więcej informacji, zobacz Automatyczne dołączanie recenzentów kodu.

Krok 3. Wymuszanie możliwości śledzenia i walidacji

Sprawdzanie połączonych elementów roboczych

Włącz opcję Sprawdzaj połączone elementy robocze, gdy zespół potrzebuje śledzenia zmian między żądaniami ściągnięcia a śledzeniem elementów roboczych.

Skonfiguruj zasadę połączonych elementów roboczych

az repos policy work-item-linking create \
  --blocking true \
  --branch main \
  --enabled true \
  --repository-id <repository-id>

Sprawdź wynik: żądania pull request bez połączonych elementów roboczych pokazują, że zasada nie jest spełniona.

Aby uzyskać więcej informacji, zobacz Sprawdzanie połączonych elementów roboczych.

Walidacja kompilacji

Użyj weryfikacji kompilacji, aby wymagać pomyślnego ukończenia potoku dla żądań typu pull request przed scaleniem.

Zalecane ustawienia dla chronionych gałęzi:

• Wyzwalacz: automatyczny
• Wymaganie dotyczące zasad: Required
• Wygaśnięcie kompilacji: wybierz wartość odpowiadającą częstotliwości zmian w chronionej gałęzi

Konfigurowanie zasad weryfikacji kompilacji

az repos policy build create \
  --blocking true \
  --branch main \
  --build-definition-id <pipeline-id> \
  --display-name "PR validation" \
  --enabled true \
  --manual-queue-only false \
  --queue-on-source-update-only true \
  --repository-id <repository-id> \
  --valid-duration 0

Sprawdź wynik:

• Otwarcie lub zaktualizowanie żądania ściągnięcia powoduje dodanie skonfigurowanej kompilacji weryfikacyjnej do kolejki.
• Pull request nie może zostać ukończony, dopóki wymagana kompilacja nie zakończy się powodzeniem.

Aby uzyskać więcej informacji, zobacz Weryfikacja kompilacji.

Sprawdź rozwiązywanie komentarzy

Użyj opcji Sprawdź rozwiązywanie komentarzy, aby upewnić się, że wątki recenzji zostały rozwiązane, zanim żądanie ściągnięcia zostanie ukończone.

Konfigurowanie zasad rozwiązywania komentarzy

az repos policy comment-required create \
  --blocking true \
  --branch main \
  --enabled true \
  --repository-id <repository-id>

Sprawdź wynik: pull requesty z nierozwiązanymi komentarzami pozostają zablokowane, dopóki recenzenci lub autorzy nie rozwiążą wątków.

Aby uzyskać więcej informacji, zobacz Sprawdzanie rozwiązania komentarza.

Ogranicz typy scalania

Użyj ustawienia Ogranicz typy scalania jako ustawienia zarządzania historią repozytorium. Te zasady ułatwiają standaryzację sposobu wyświetlania zatwierdzeń żądań ściągnięcia po scaleniu, ale nie jest to bezpośrednia kontrola zabezpieczeń.

Wybierz strategię scalania na podstawie sposobu, w jaki zespół przegląda, śledzi i przeprowadza inspekcję historii.

Przykładowe zastosowania:

• Wymagaj scalań typu squash dla krótkotrwałych gałęzi funkcjonalności.
• Nie zezwalaj na przebazowanie ani squash w gałęziach, w których proces audytu oczekuje commitów scalających.

Zagadnienia dotyczące inspekcji i możliwości śledzenia:

• Squash tworzy czystszą historię gałęzi docelowej, ale zwija wiele zatwierdzeń źródłowych w jednym zatwierdzeniu w czasie scalania.
• Jeśli model audytu zależy od zachowania dokładnej sekwencji commitów z gałęzi funkcjonalnej, wybieraj strategie scalania z commitami scalającymi zamiast squasha.
• Zachowaj spójność zasad ze sposobem, w jaki deweloperzy sprawdzają i debugują historię w pull requestach oraz w gałęzi docelowej.

przykład interfejsu wiersza polecenia Azure DevOps:

az repos policy merge-strategy create \
  --blocking true \
  --branch main \
  --enabled true \
  --repository-id <repository-id> \
  --allow-no-fast-forward true \
  --allow-rebase false \
  --allow-rebase-merge false \
  --allow-squash false

Aby uzyskać więcej informacji, zobacz Ograniczanie typów scalania.

Krok 4. Dodawanie kontroli stanu zabezpieczeń zaawansowanych GitHub

Kontrole stanu usługi GitHub Advanced Security pomagają zapobiegać scalaniu pull requestów, jeśli wprowadzane są nowe luki w zabezpieczeniach o krytycznym lub wysokim poziomie ważności.

Przed dodaniem zasad sprawdzania stanu:

1. Włącz GitHub Advanced Security w repozytorium.
2. Skonfiguruj wymagane zadania w potoku Advanced Security.
3. Dodaj zasadę weryfikacji kompilacji dla gałęzi pull requestu.
4. Włącz Wait for Processing: true na potrzeby opisanych zadań Advanced Security.
5. Uruchom potok pomyślnie co najmniej raz, aby kontrola stanu pojawiła się na liście Status do sprawdzenia.

AdvancedSecurity/NewHighAndCritical Zacznij od tego, czy repozytorium ma już nierozwiązane alerty. Po zmniejszeniu zaległości rozważ przejście do AdvancedSecurity/AllHighAndCritical.

Ścieżka przeglądarki:

1. Otwórz gałąź docelową w sekcji Zasady gałęzi.
2. W obszarze Kontrole stanu wybierz pozycję +.
3. Ustaw Status do sprawdzenia na AdvancedSecurity/NewHighAndCritical.
4. Pozostaw wartości domyślne opcji zaawansowanych .
5. Zapisz zasady.

Kontrole stanu usługi Advanced Security konfiguruje się w sekcji Kontrole stanu w przeglądarce po włączeniu skanowania Advanced Security i weryfikacji kompilacji dla repozytorium. Aby zapoznać się z wymaganą konfiguracją, zobacz Konfigurowanie kontroli stanu żądania ściągnięcia.

Sprawdź wynik:

• Żądania ściągnięcia z nowymi wysokimi lub krytycznymi wynikami pokazują, że sprawdzanie stanu zakończyło się niepowodzeniem.
• Zasady gałęzi blokują uzupełnianie, dopóki wyniki nie zostaną rozwiązane lub zasady zostaną wprowadzone jako opcjonalne.

Aby uzyskać szczegółowe informacje o konfiguracji, zobacz:

• Skonfiguruj sprawdzanie stanu pull requestu
• Dostępne kontrole statusu dla pull requestu

Przykładowe plany wdrażania

Linia bazowa repozytorium o niższej wrażliwości

Jeśli repozytorium ma niższą czułość i chcesz zacząć od czegoś łatwego do opanowania:

1. Ogranicz uprawnienia pomijania gałęzi w systemie main.
2. Wymagaj co najmniej jednego lub dwóch recenzentów.
3. Włącz połączone elementy robocze.
4. Dodaj walidację kompilacji.
5. Włącz rozwiązywanie komentarzy.

Repozytorium o wysokiej poufności

Jeśli repozytorium zawiera zasoby krytyczne dla wdrażania, zarządzania tożsamością lub zgodności:

1. Ogranicz uprawnienia do pomijania zasad administratorom.
2. Wymagaj dwóch recenzentów dla main.
3. Dodaj automatycznie dodawanych recenzentów do chronionych ścieżek.
4. Wymagaj połączonych elementów roboczych.
5. Dodaj walidację kompilacji.
6. Dodaj kontrole stanu usługi GitHub Advanced Security, jeśli używasz usługi Azure DevOps Services.

Opcjonalnie: Użyj pomocy sztucznej inteligencji, aby przejrzeć konfigurację zasad gałęzi

Pomoc dotycząca sztucznej inteligencji jest opcjonalna. Uprawnienia gałęzi, zasady i kontrole stanu wymuszają ochronę repozytorium niezależnie od tego, czy używasz sztucznej inteligencji.

Za pomocą tych podpowiedzi możesz szybciej przeanalizować konfigurację zasad, zidentyfikować luki i uzyskać podstawowe zalecenia. Jeśli skonfigurujesz Azure DevOps serwer MCP, asystent może użyć kontekstu Azure DevOps, aby poprawić odpowiedzi. Aby uzyskać wskazówki dotyczące konfiguracji, zobacz Włącz asystę SI za pomocą serwera Azure DevOps MCP.

Użyj monitów, takich jak następujące, aby rozpocząć pracę:

Przed ich zastosowaniem należy zawsze weryfikować wygenerowane polecenia i zalecenia dotyczące uprawnień repozytorium, ustawień gałęzi i bieżącej dokumentacji Azure DevOps.

Wskazówki dotyczące rozwiązywania problemów

Treści powiązane

• Ustawianie uprawnień do repozytorium Git
• Ustaw uprawnienia gałęzi
• Zasady i ustawienia odgałęzień
• Dostępne kontrole statusu dla pull requestu
• Konfigurowanie GitHub Advanced Security
• Informacje o pull requestach