Udostępnij za pośrednictwem

Najlepsze rozwiązania dotyczące zabezpieczeń

  • Artykuł

DevSecOps

Embrace DevSecOps: Wdróż zasady Zero Trust, aby wzmocnić swoją platformę DevOps, zabezpieczyć swoje środowisko developerskiei płynnie zintegrować Zero Trust z przepływem pracy swoich programistów.

Uwaga

W kontekście ciągłej integracji/ciągłego wdrażania implementacja dostępu do najniższych uprawnień może być przeciwnaprodukcyjna ze względu na dynamiczny charakter architektury. Za każdym razem, gdy zostanie wprowadzona nowa usługa, należy wcześniej zaktualizować uprawnienia. Ponadto wycofywanie może wymagać dodatkowych uprawnień, które należy wziąć pod uwagę. To wyzwanie jest spotęgowane w środowiskach z wieloma rurami. Chociaż uprawnienia najniższych uprawnień mają na celu zminimalizowanie wpływu naruszeń zabezpieczeń, kluczowe jest zrównoważenie zabezpieczeń z wydajnością. Tę równowagę można osiągnąć, przyjmując bardziej permisywny dostęp i zmniejszając związane z nimi zagrożenia związane z mechanizmami kontroli wyrównywalnej i praktykami w zakresie zabezpieczeń opisanymi na tej stronie.

  • 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ń
  • Segmentacja środowiska: przydziel oddzielne konta platformy Azure na potrzeby programowania, testowania, produkcji i innych środowisk. Takie podejście zwiększa bezpieczeństwo poprzez minimalizację promienia wybuchu i zapobieganie konfliktom zasobów oraz zanieczyszczeniu danych. Ponadto umożliwia wiele zasobów tymczasowych, specyficznych dla funkcji w ramach konta dewelopera. W przypadku dużych organizacji rozważ przydzielanie co najmniej jednego konta na zespół na środowisko. Oddzielne konta dla obciążeń o krytycznym znaczeniu dla działania firmy mogą być również uzasadnione. Rozważ wdrożenie strefy docelowej platformy Azure w celu usprawnienia aprowizacji i zarządzania.
  • kontrola dostępu i zgodność: Wykorzystanie usługi Azure Policy w grupach zarządzania w celu ograniczenia dostępu do nieużywanych regionów i usług platformy Azure, zapewniając zgodność ze standardami organizacyjnymi.
  • Attribute-Based Kontrola dostępu (ABAC): Wdrożenie ABAC z prawidłowo oznakowanymi zasobami w celu zapobieżenia dostępowi szkodliwych aktorów i zapobiegania nieautoryzowanemu tworzeniu zasobów.

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 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

  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

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

  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.

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).

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ń.

Pojemniki

  • Użyj zaufanych obrazów: korzystaj z oficjalnych i zweryfikowanych obrazów z zaufanych źródeł, takich jak Usługa Azure Container Registry lub Docker Hub. Zawsze należy określić określoną wersję lub tag, aby zachować spójność i niezawodność, zamiast polegać na tagu latest. Regularnie aktualizuj obrazy podstawowe w celu uwzględnienia najnowszych poprawek zabezpieczeń i poprawek błędów.
  • Skanuj kontenery pod kątem luk w zabezpieczeniach i wymuszaj ochronę przed zagrożeniami w czasie wykonywania: użyj narzędzi, takich jak Microsoft Defender for Cloud, aby monitorować i wykrywać zagrożenia bezpieczeństwa. Ponadto usługa Azure Container Registry oferuje zintegrowane skanowanie luk w zabezpieczeniach w celu zapewnienia bezpieczeństwa obrazów kontenerów przed wdrożeniem. Możesz również zintegrować narzędzia do skanowania innych firm za pomocą rozszerzeń usługi Azure DevOps w celu sprawdzenia zabezpieczeń.
  • Zaimplementuj zasady zabezpieczeń, aby zapobiec eskalacji uprawnień i zapewnić uruchamianie kontenerów z najmniejszą ilością uprawnień niezbędnych: na przykład usługa Azure Kubernetes Service (AKS), kontroli dostępu opartej na rolachi zezwalają na wymuszanie zasad, które ograniczają uprawnienia kontenera, zapewniają wykonywanie niekorzystające i ograniczają dostęp do krytycznych zasobów. Zdefiniuj zasady kontroli zabezpieczeń podów (dla Kubernetes 1.22 lub nowszych), aby zastosować ograniczenia, takie jak uniemożliwienie używania uprzywilejowanych kontenerów lub uniemożliwienie kontenerom dostępu do sieci hosta.
  • Wykorzystaj zasady sieciowe: Zasady sieciowe mogą służyć do ograniczania komunikacji między kontenerami, co zapewnia dostęp do zasobów tylko autoryzowanym kontenerom w twojej sieci. Ponadto usługę Azure Policy dla usługi AKS można wykorzystać do wymuszania najlepszych rozwiązań w zakresie zabezpieczeń kontenerów, takich jak zapewnienie wdrożenia tylko zaufanych obrazów kontenerów.
  • Ustaw limity zasobów specyficznych dla kontenera: na przykład ustaw limity procesora CPU i pamięci, aby zapobiec używaniu nadmiernych zasobów przez kontenery, co może prowadzić do odmowy usługi lub luk w zabezpieczeniach.

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.