Share via

Najlepsze rozwiązania dotyczące zabezpieczeń

  • Artykuł

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

Podczas pracy z informacjami i danymi, szczególnie w rozwiązaniu opartym na chmurze, np. w usłudze Azure DevOps Services, priorytetyzowanie zabezpieczeń zawsze powinno być twoim głównym problemem. Chociaż firma Microsoft utrzymuje bezpieczeństwo podstawowej infrastruktury chmury, twoim zadaniem jest skonfigurowanie zabezpieczeń w usłudze Azure DevOps.

Mimo że nie jest to obowiązkowe, włączenie najlepszych rozwiązań podczas korzystania z usługi Azure DevOps może poprawić środowisko i zwiększyć bezpieczeństwo. Skompilowaliśmy następujące najlepsze rozwiązania, które mają na celu zapewnienie bezpieczeństwa środowiska usługi Azure DevOps:

Zabezpieczanie środowiska usługi Azure DevOps

Usuwanie użytkowników

  • Jeśli organizacja korzysta z kont MSA, usuń nieaktywnych użytkowników bezpośrednio z organizacji, ponieważ nie masz innego sposobu, aby uniemożliwić dostęp. Gdy to zrobisz, nie można utworzyć zapytania dla elementów roboczych przypisanych do usuniętego konta użytkownika. Aby uzyskać więcej informacji, zobacz Usuwanie użytkowników z usługi Azure DevOps.
  • Jeśli Twoja organizacja jest połączona z identyfikatorem Entra firmy Microsoft, możesz wyłączyć lub usunąć konto użytkownika Microsoft Entra i pozostawić aktywne konto użytkownika usługi Azure DevOps. W ten sposób możesz nadal wykonywać zapytania dotyczące historii elementów roboczych przy użyciu identyfikatora użytkownika usługi Azure DevOps.
  • Odwoływanie paT użytkowników.
  • Odwołaj wszelkie specjalne uprawnienia, które mogły zostać przyznane poszczególnym kontom użytkowników.
  • Przypisz ponownie pracę od użytkowników usuwanych do bieżących członków zespołu.

Korzystanie z identyfikatora Entra firmy Microsoft

Zintegruj usługę Azure DevOps z identyfikatorem Entra firmy Microsoft, aby mieć jedną płaszczyznę tożsamości. Spójność i jedno autorytatywne źródło zwiększa przejrzystość i zmniejsza ryzyko bezpieczeństwa związane z błędami ludzkimi i złożonością konfiguracji. Kluczem do kompleksowego ładu jest posiadanie wielu przypisań ról (z różnymi definicjami ról i różnymi zakresami zasobów do tych samych grup firmy Microsoft Entra). Bez identyfikatora Entra firmy Microsoft ponosisz wyłączną odpowiedzialność za kontrolowanie dostępu do organizacji.

Korzystanie z identyfikatora Entra firmy Microsoft umożliwia również dostęp do innych funkcji zabezpieczeń, takich jak uwierzytelnianie wieloskładnikowe lub inne zasady dostępu warunkowego.

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

Przeglądanie zdarzeń inspekcji

Po utworzeniu organizacji wspieranej przez firmę Microsoft Entra możesz włączyć inspekcję w zasadach zabezpieczeń. Okresowo przeglądaj zdarzenia inspekcji, aby monitorować i reagować na nieoczekiwane wzorce użycia przez administratorów i innych użytkowników.

Zabezpieczanie sieci

Oto kilka sposobów, aby to zrobić:

  • Skonfiguruj listę dozwolonych, aby ograniczyć określone adresy IP.
  • Zawsze używaj szyfrowania.
  • Zweryfikuj certyfikaty.
  • Zaimplementuj zapory aplikacji internetowej (WAFs), aby umożliwić filtrowanie, monitorowanie i blokowanie dowolnego złośliwego ruchu internetowego do i z usługi Azure DevOps.
  • Aby uzyskać więcej informacji, zobacz te wskazówki dotyczące najlepszych rozwiązań dotyczących zarządzania aplikacjami

Uprawnienia o określonym zakresie

System zarządza uprawnieniami na różnych poziomach — indywidualne, kolekcji, projektu i obiektu — i przypisuje je do co najmniej jednej wbudowanej grupy domyślnie.

Uprawnienia na poziomie projektu

  • Ogranicz dostęp do projektów i repozytoriów, aby zmniejszyć ryzyko wycieku poufnych informacji i wdrożenia niezabezpieczonego kodu w środowisku produkcyjnym.
  • Aby zarządzać uprawnieniami, użyj wbudowanych grup zabezpieczeń lub niestandardowych grup zabezpieczeń. Aby uzyskać więcej informacji, zobacz Udzielanie lub ograniczanie uprawnień do wybierania zadań.
  • Wyłącz opcję "Zezwalaj na projekty publiczne" w ustawieniach zasad organizacji, aby uniemożliwić każdemu użytkownikowi organizacji tworzenie projektu publicznego. Usługa Azure DevOps Services umożliwia zmianę widoczności projektów z publicznego na prywatny i odwrotnie. Jeśli użytkownicy nie zalogowali się do organizacji, mają dostęp tylko do odczytu do Twoich projektów publicznych. Jeśli użytkownicy się zalogowali, mogą mieć dostęp do projektów prywatnych i wprowadzać w nich wszelkie dozwolone zmiany.
  • Nie zezwalaj użytkownikom na tworzenie nowych projektów.

Dostęp gościa zewnętrznego

  • Blokuj dostęp gościa zewnętrznego całkowicie, wyłączając zasady "Zezwalaj na wysyłanie zaproszeń do dowolnej domeny". Dobrym pomysłem jest to, aby to zrobić, jeśli nie ma potrzeby biznesowego.
  • Użyj innej nazwy e-mail lub głównej nazwy użytkownika (UPN) dla kont osobistych i biznesowych, mimo że jest to dozwolone. Ta akcja eliminuje wyzwanie uściślania między kontami biznesowymi i osobistymi, gdy adres e-mail/nazwa UPN jest taki sam.
  • Umieść wszystkich zewnętrznych użytkowników-gości w jednej grupie Firmy Microsoft Entra i odpowiednio zarządzaj uprawnieniami tej grupy. Możesz łatwo zarządzać i przeprowadzać inspekcję w ten sposób.
    • Usuń przypisania bezpośrednie, aby reguły grupy były stosowane do tych użytkowników. Aby uzyskać więcej informacji, zobacz Dodawanie reguły grupy w celu przypisania poziomów dostępu.
    • Regularnie sprawdzaj reguły na karcie Reguły grupy na stronie Użytkownicy. Wyjaśnienie, czy jakiekolwiek zmiany członkostwa w grupie w identyfikatorze Entra firmy Microsoft mogą mieć wpływ na Twoją organizację. Aktualizacja członkostwa w grupie dynamicznej może potrwać do 24 godzin. Co 24 godziny i za każdym razem, gdy zmienia się reguła grupy, reguły są automatycznie ponownie oceniane w systemie.
  • Aby uzyskać więcej informacji, zobacz B2B gości w identyfikatorze Microsoft Entra ID.

Zarządzanie grupami zabezpieczeń

Zabezpieczenia i grupy użytkowników

Zapoznaj się z poniższymi zaleceniami dotyczącymi przypisywania uprawnień do grup zabezpieczeń i grup użytkowników.

Zrobić 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.
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 .
Podczas dodawania wielu zespołów rozważ utworzenie grupy niestandardowej team Administracja istrators, w której przydzielasz podzbiór uprawnień dostępnych dla Administracja istratorów programu Project. Nie zmieniaj domyślnych przypisań dokonanych w grupach Project Valid Users . Jeśli usuniesz lub ustawisz opcję Wyświetl informacjena 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. Administracja są przypisywane do grupy zabezpieczeń Project Administracja istrator w celu uzyskania podwyższonych uprawnień, co pozwala im skonfigurować uprawnienia zabezpieczeń.

Aby uzyskać więcej informacji, zobacz Prawidłowe grupy użytkowników.

Dostęp just in time dla grup administratorów

Konfigurację organizacji lub projektu można zmienić, jeśli masz dostęp do Administracja istratora kolekcji projektów i Administracja istratora projektu. Aby chronić dostęp do tych wbudowanych grup administratorów, należy wymagać dostępu just in time przy użyciu grupy microsoft Entra Privileged Identity Management (PIM).

Konfigurowanie dostępu

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

Uwaga

Upewnij się, że każdy użytkownik z podwyższonym poziomem dostępu przy użyciu grupy PIM ma również standardowy dostęp do organizacji, aby mógł wyświetlić stronę w celu odświeżenia swoich uprawnień.

Korzystanie z dostępu

  1. Aktywuj dostęp.
  2. Odśwież swoje uprawnienia w usłudze Azure DevOps.
  3. 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

  • Upewnij się, że konta usług mają zerowe prawa logowania interakcyjnego.
  • Ogranicz uprawnienia konta usługi do niezbędnego minimum.
  • Użyj innej tożsamości dla konta czytelnika raportów, jeśli używasz kont domeny dla kont usług. Aby uzyskać więcej informacji, zobacz Konta usług i zależności.
  • Użyj kont lokalnych dla kont użytkowników, jeśli instalujesz składnik w grupie roboczej. Aby uzyskać więcej informacji, zobacz Wymagania dotyczące konta usługi.
  • Jeśli to możliwe, użyj połączeń usług. Połączenia usług zapewniają bezpieczny mechanizm łączenia się z usługami assortowanych bez konieczności bezpośredniego przekazywania zmiennych tajnych do kompilacji. - Ogranicz te połączenia do określonego miejsca, które powinny być używane i nic więcej.
  • Monitorowanie aktywności konta usługi i tworzenie przesyłania strumieniowego inspekcji. Inspekcja umożliwia wykrywanie podejrzanych logowań i działań oraz reagowanie na nie.
  • Aby uzyskać więcej informacji, zobacz Typowe typy połączeń usługi.

Zakres połączeń usług

  • Zakres usługi Azure Resource Manager i inne połączenia usług tylko do zasobów i grup, do których potrzebują dostępu. Połączenia usług nie powinny mieć szerokich praw współautora w całej subskrypcji platformy Azure.
  • Użyj federacji tożsamości obciążenia dla połączeń usługi Azure Resource Manager (ARM). Federacja tożsamości obciążenia umożliwia tworzenie połączeń usługi bez wpisów tajnych w usłudze Azure Pipelines z platformą Azure.
  • Nie należy udzielać użytkownikom ogólnych ani szerokich uprawnień współautora w subskrypcji platformy Azure.
  • Nie używaj klasycznych połączeń usługi platformy Azure, ponieważ nie ma możliwości określenia zakresu uprawnień.
  • Upewnij się, że grupa zasobów zawiera tylko maszyny wirtualne lub zasoby, do których kompilacja potrzebuje dostępu.
  • Użyj konta usługi zespołu specyficznego dla celu, aby uwierzytelnić połączenie z usługą.
  • 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

Zapoznaj się z alternatywnymi rozwiązaniami, takimi jak jednostki usługi i tożsamości zarządzane, które umożliwiają używanie tokenów firmy Microsoft Entra do uzyskiwania dostępu do zasobów usługi Azure DevOps. Takie tokeny niosą ze sobą mniejsze ryzyko w przypadku wycieku w porównaniu z sieciami PAT i zawierają korzyści, takie jak łatwe zarządzanie poświadczeniami.

Używanie pats oszczędnie

Jeśli to możliwe, zalecamy, aby zawsze używać usług tożsamości do uwierzytelniania zamiast kluczy kryptograficznych, ponieważ bezpieczne zarządzanie kluczami przy użyciu kodu aplikacji jest trudne i może prowadzić do błędów, takich jak przypadkowe publikowanie poufnych kluczy dostępu do publicznych repozytoriów kodu, takich jak GitHub. Jeśli jednak musisz użyć osobistych tokenów dostępu (PAT), weź pod uwagę następujące wskazówki:

  • Usługi PATs powinny być zawsze ograniczone do określonych ról.

  • Dostawcy paT nie powinni zapewniać globalnego dostępu do wielu organizacji.

  • Dostawcy paTs nie powinni udzielać uprawnień do zapisu ani zarządzania w kompilacjach lub wydaniach.

  • Dostawcy paTs powinni mieć datę wygaśnięcia i być przechowywane w tajemnicy, ponieważ są one tak krytyczne jak hasła.

  • PaTs nigdy nie powinny być zakodowane w kodzie aplikacji, nawet jeśli jest kuszące, aby uprościć kod.

  • Administracja istratorzy powinni regularnie przeprowadzać inspekcję wszystkich paT przy użyciu Interfejsy API REST i odwoływanie wszystkich, które nie spełniają powyższych kryteriów.

  • Zachowaj wpisy dostępu tajnego. Tokeny są tak krytyczne jak hasła.

  • Przechowywanie tokenów w bezpiecznym miejscu.

  • Nie rachuj tokenów kodu twardego w aplikacjach. Może to być kuszące, aby uprościć kod, aby uzyskać token przez długi czas i przechowywać go w aplikacji, ale nie rób tego.

  • Nadaj tokenom datę wygaśnięcia.

  • Aby uzyskać więcej informacji, zapoznaj się z następującymi artykułami:

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.
  • Aby uzyskać więcej informacji, zobacz Ustawianie uprawnień kanału informacyjnego.

Zabezpieczanie usługi Azure Boards

Zabezpieczanie usługi Azure Pipelines

Zasady

  • Wymagaj co najmniej jednego recenzenta spoza oryginalnego obiektu żądającego. Udziały zatwierdzające współwłaściciel zmian i powinny być równie pociągnięte do odpowiedzialności za potencjalny wpływ.
  • Wymagaj przekazania kompilacji ciągłej integracji. To wymaganie jest przydatne w przypadku ustanawiania jakości kodu bazowego za pomocą lintingu kodu, testów jednostkowych i kontroli zabezpieczeń, takich jak skanowanie wirusów i poświadczeń.
  • Upewnij się, że oryginalny program żądający ściągnięcia nie może zatwierdzić zmiany.
  • Nie zezwalaj na ukończenie żądania ściągnięcia (żądanie ściągnięcia), nawet jeśli niektórzy recenzenci zagłosują na oczekiwanie lub odrzucenie.
  • Resetuj głosy recenzenta kodu po wypchnięciu ostatnich zmian.
  • Zablokuj potoki wydania, uruchamiając je tylko w określonych gałęziach produkcyjnych.
  • Włącz opcję "Wymuszaj tabelę ustawianą w czasie kolejki dla zmiennych" w ustawieniach potoku organizacji.
  • Nie zezwalaj na ustawienie "Zezwalaj użytkownikom na zastąpienie tej wartości podczas uruchamiania tego potoku" dla zmiennych ustawionych w edytorze.

Agenci

  • Przyznaj uprawnienia najmniejszej możliwej liczbie kont.
  • Mieć najbardziej restrykcyjną zaporę, która pozostawia agentów do użycia.
  • Regularnie aktualizuj pule, aby upewnić się, że flota kompilacji nie uruchamia kodu podatnego na zagrożenia, który może wykorzystać złośliwy aktor.
  • Użyj oddzielnej puli agentów do tworzenia artefaktów, które są dostarczane lub wdrażane w środowisku produkcyjnym.
  • Segmentuj "wrażliwą" pulę z niewrażliwych pul i zezwalaj tylko na używanie poświadczeń w definicjach kompilacji, które są zablokowane dla tej puli.

Definicje

  • Zarządzanie definicjami potoków za pomocą języka YAML (Jeszcze inny język znaczników). YAML jest preferowaną metodą zarządzania definicjami potoków, ponieważ zapewnia możliwość śledzenia zmian i może przestrzegać wytycznych dotyczących zatwierdzania.
  • Zabezpiecz definicję potoku Edytuj dostęp do minimalnej liczby kont.

Dane wejściowe

  • Uwzględnij sprawdzanie kondycji zmiennych w skryptach kompilacji. Sprawdzanie kondycji może ograniczyć atak polegający na wstrzyknięciu polecenia za pomocą zmiennych settable.
  • Ustaw jak najmniej zmiennych kompilacji na wartość "Settable w czasie wydania".

Zadania

  • Unikaj zdalnego pobierania zasobów, ale w razie potrzeby użyj sprawdzania wersji i skrótu.
  • Nie rejestruj wpisów tajnych.
  • Nie przechowuj wpisów tajnych w zmiennych potoku, użyj usługi Azure Key Vault. Regularnie skanuje potoki kompilacji, aby upewnić się, że wpisy tajne nie są przechowywane w zmiennych potoku kompilacji.
  • Nie zezwalaj użytkownikom na uruchamianie kompilacji dla dowolnych gałęzi lub tagów w potokach o krytycznym znaczeniu dla zabezpieczeń.
  • Wyłącz dziedziczenie w potoku, ponieważ uprawnienia dziedziczone są szerokie i nie odzwierciedlają dokładnie potrzeb uprawnień.
  • Ogranicz zakresy autoryzacji zadań we wszystkich przypadkach.

Repozytoria i gałęzie

  • Ustaw zasadę "Wymagaj minimalnej liczby recenzentów", tak aby każde żądanie ściągnięcia było przeglądane przez co najmniej dwóch osób zatwierdzających.
  • Skonfiguruj zasady zabezpieczeń specyficzne dla każdego repozytorium lub gałęzi, a nie dla całego projektu. Zasady zabezpieczeń zmniejszają ryzyko, wymuszają standardy zarządzania zmianami i zwiększają jakość kodu zespołu.
  • Przechowywanie wpisów tajnych produkcyjnych w oddzielnym magazynie Key Vault i zapewnienie, że dostęp jest udzielany tylko na podstawie potrzeb, aby nieprodukcyjne kompilacje były oddzielone.
  • Nie mieszaj środowisk testowych z środowiskiem produkcyjnym, w tym używania poświadczeń.
  • Wyłącz rozwidanie. Im więcej rozwidlenia, tym trudniej jest śledzić bezpieczeństwo każdego rozwidlenia. Ponadto użytkownik może łatwo rozwidlić kopię repozytorium na własne konto prywatne.
  • Nie udostępniaj wpisów tajnych do kompilacji rozwidlenia.
  • Rozważ ręczne wyzwalanie kompilacji rozwidlenia.
  • Użyj agentów hostowanych przez firmę Microsoft dla kompilacji rozwidlenia.
  • W przypadku usługi Git sprawdź definicje kompilacji produkcyjnej w repozytorium git projektu, aby można je było skanować pod kątem poświadczeń.
  • Skonfiguruj kontrolę gałęzi, aby tylko potoki uruchomione w kontekście production gałęzi mogły używać elementu prod-connection.
  • 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

  • Wyłącz uwierzytelnianie oparte na osobistym tokenie dostępu (PAT), więc przepływ OAuth jest używany z połączeniem usługi GitHub.
  • Nigdy nie uwierzytelniaj połączeń usługi GitHub jako tożsamości będącej administratorem lub właścicielem jakichkolwiek repozytoriów.
  • Do uwierzytelniania połączeń usługi GitHub nigdy nie używaj pełnego zakresu tokenu PAT (osobistego tokenu dostępu) do uwierzytelniania połączeń usługi GitHub.
  • Nie używaj osobistego konta usługi GitHub jako połączenia usługi z usługą Azure DevOps.