Udostępnij za pośrednictwem

Zabezpieczanie potoku i przepływu pracy ciągłej integracji/ciągłego wdrażania

  • Artykuł

W tym artykule opisano sposób zabezpieczania potoków ciągłej integracji/ciągłego wdrażania i przepływu pracy.

Automatyzacja i metodologia Agile umożliwiają zespołom szybsze dostarczanie, ale także zwiększanie złożoności zabezpieczeń, ponieważ przepływ pracy rozszerza się na same zespoły deweloperów.

Na poniższym diagramie przedstawiono bazowy przepływ pracy ciągłej integracji/ciągłego wdrażania. Czerwona ikona konfiguracji wskazuje uprawnienia zabezpieczeń, które muszą być skonfigurowane przez klienta. Jest to zgodny ze wspólnym modelem odpowiedzialności, w którym platforma Azure i inni dostawcy zapewniają uprawnienia, które muszą zostać skonfigurowane przez klienta zgodnie z ich modelem ładu i wymaganiami biznesowymi.

Typowy przepływ pracy ciągłej integracji/ciągłego wdrażania, który ilustruje, w jaki sposób zmiany kodu w repozytorium Git będą wpływać na zasoby w chmurze

Przyjrzyjmy się każdemu etapowi tego typowego przepływu pracy, aby zrozumieć, jak konfiguracje często zależą od siebie. Przepływ pracy może mieć więcej etapów. Poniższe pojęcia pomogą Ci zrozumieć ciągłą integrację/ciągłe wdrażanie i ułatwić projektowanie przepływu pracy pod kątem zabezpieczeń.

Etap 1. Przepływ pracy usługi Git

Zmiany kodu, nie tylko oprogramowanie, ale także potok jako kod i infrastruktura jako kod, są zapisywane i zarządzane w usłudze Git. Git to rozproszone oprogramowanie do zarządzania kodem źródłowym. Gdy kod jest wypychany z komputerów lokalnych do scentralizowanego serwera Git, reguły biznesowe można zastosować przed zaakceptowaniem.

Żądania ściągnięcia i współpraca

Standardowy przepływ pracy, niezależnie od dostawcy oprogramowania do zarządzania konfiguracją oprogramowania (SCM) jako usługi (SaaS), polega na użyciu żądań ściągnięcia, które mogą działać zarówno jako zautomatyzowany strażnik jakości, jak i krok ręcznego zatwierdzania przed zaakceptowaniem kodu źródłowego.

Przepływ pracy żądania ściągnięcia ma na celu wprowadzenie problemów w dobrej kondycji, dlatego należy go stosować tylko do zabezpieczania określonych gałęzi usługi Git. Szczególnie gałęzie, które będą wyzwalać zautomatyzowane przepływy pracy, które mogą wdrażać, konfigurować lub w jakikolwiek inny sposób wpływać na zasoby w chmurze. Te gałęzie są nazywane gałęziami chronionymi i zwykle są zgodne z konwencjami nazewnictwa, takimi jak production lub releases/*.

Często żądania ściągnięcia wymagają:

  • Przeglądy elementów równorzędnych
  • Przekazywanie kompilacji ciągłej integracji
  • Zatwierdzanie ręczne

Jeśli wymagania zostaną spełnione, zmiany kodu zostaną zaakceptowane i można je scalić.

Ograniczanie dostępu do chronionych gałęzi

Przepływ pracy żądania ściągnięcia jest używany wraz z ograniczonymi mechanizmami kontroli dostępu. Nie można jednak wymusić przepływu pracy żądania ściągnięcia, chyba że serwer jest skonfigurowany do odrzucania bezpośrednich zmian w gałęziach chronionych.

Deweloper nie może wypchnąć bezpośrednio do production gałęzi, ale zamiast tego musi utworzyć żądanie ściągnięcia przeznaczone dla chronionej gałęzi. Każdy dostawca SCM ma inny wariant umożliwiający uzyskanie ograniczonego dostępu do chronionych gałęzi. Na przykład w usłudze GitHub ta funkcja jest dostępna tylko dla organizacji korzystających z zespołu GitHub lub chmury GitHub Enterprise.

Dokumentowanie modelu dostępu usługi Git

Ponieważ model współpracy jest złożony i ma wiele ruchomych części, warto utworzyć tabelę, która zawiera wszystkie możliwe sposoby wyzwalania wdrożeń kodu, na przykład:

Nazwa gałęzi Wymaga żądania ściągnięcia? Wdraża? Dostęp dewelopera Dostęp administratora
feat/* Nie Nie. Czytaj/zapisz Czytaj/zapisz
main Tak Przygotowanie Przeczytaj Czytaj/zapisz
production Tak, tylko z main Produkcyjne Przeczytaj Czytaj/zapisz

Ten przykład tabeli dostępu git jest nadmiernie uproszczony, aby zilustrować jego przeznaczenie. W praktyce często jest więcej aktorów, więcej celów wdrażania i wiele potoków, które są uruchamiane w różnych przypadkach użycia. Struktura tabeli może się różnić w zależności od wymagań organizacji i obciążeń.

Tabela powinna ułatwić udzielenie odpowiedzi na pytania, takie jak:

  • Jeśli deweloper wypycha zmiany kodu do gałęzi X, czy zostanie wdrożony? Jeśli tak, do jakiego środowiska?
  • W jakim momencie cyklu życia kodu aplikacji odbywa się skanowanie w celu zabezpieczenia?
  • Jeśli zostanie znaleziona luka w zabezpieczeniach, ile wypchnięć i zatwierdzeń kodu jest wymaganych, zanim trafi do środowiska produkcyjnego?

Ta tabela jest nie tylko przydatna do debugowania i dokumentacji statycznej, ale także do współpracy zespołowej. Jest to przejrzyste dla deweloperów, w których wprowadzono zdrowe tarcie w przepływie pracy w celu nadanie priorytetów jakości i bezpieczeństwa kodu. Co ważniejsze, pokazuje deweloperowi oczekiwaną ścieżkę zmian kodu w celu osiągnięcia środowiska produkcyjnego.

Ponieważ metodyka DevOps to podróż, model dostępu do usługi Git nie jest statyczny. Zmieni się i ewoluuje, gdy zespoły znajdą własne rytmy i dojrzałe. Dlatego ważne jest, aby przechowywać tę dokumentację jak najbliżej kodu, na przykład w repozytoriach Git.

Aby dowiedzieć się więcej o żądaniach ściągnięcia i chronionych gałęziach, zobacz:

Etap 2. Potoki jako kod

Przenoszenie potoku jako kodu przyspieszyło wdrażanie i wdrożenia automatyzacji przez przeniesienie definicji potoków i konfiguracji od dostawcy ciągłej integracji do deweloperów, przybliżając logikę kompilacji i wdrażania do odpowiedniej logiki aplikacji. Większa elastyczność w tym miejscu wiąże się również z większą odpowiedzialnością.

Kontrolki RBAC w potoku opartym na interfejsie użytkownika mogą uniemożliwić poszczególnym użytkownikom wprowadzanie destrukcyjnych zmian. Potoki jako kod często są jednak uruchamiane z tożsamościami uprzywilejowanymi i mogą zniszczyć obciążenia, jeśli zostanie to poinstruowane.

Etap 3. Zabezpieczanie poświadczeń wdrożenia

Potoki i repozytoria kodu nie powinny zawierać zakodowanych na kodzie poświadczeń i wpisów tajnych. Poświadczenia i wpisy tajne powinny być przechowywane w innym miejscu i używać funkcji dostawcy ciągłej integracji w celu zapewnienia bezpieczeństwa. Ponieważ potoki działają jako agenci bezgłówni, nigdy nie powinny używać hasła osoby fizycznej. Zamiast tego potoki powinny być uruchamiane przy użyciu głównych podmiotów zabezpieczeń, takich jak jednostki usługi lub tożsamości zarządzane. Dostęp do poświadczeń tego podmiotu zabezpieczeń, parametry połączenia bazy danych i kluczy interfejsu API innych firm powinien być również bezpiecznie zarządzany na platformie ciągłej integracji.

Sposób zabezpieczania poświadczeń, bram i zatwierdzeń są funkcjami specyficznymi dla dostawcy. Podczas wybierania platformy ciągłej integracji upewnij się, że obsługuje wszystkie wymagane funkcje.

Azure Pipelines to rozwiązanie do ciągłej integracji w skali przedsiębiorstwa, w którym poświadczenia są przechowywane jako połączenia z usługą, na których można skonfigurować zatwierdzenia i testy. Ta konfiguracja obejmuje ręczne zatwierdzanie i autoryzacje określonego gałęzi lub potoku.

Azure Key Vault

Jeśli platforma ciągłej integracji obsługuje ją, rozważ przechowywanie poświadczeń w dedykowanym magazynie wpisów tajnych, na przykład w usłudze Azure Key Vault. Poświadczenia są pobierane w czasie wykonywania przez agenta kompilacji, a obszar ataków jest zmniejszany.

Etap 4. Zabezpieczanie zasobów platformy Azure

Zasoby platformy Azure powinny być zabezpieczone zgodnie z zasadą najniższych uprawnień zastosowanych zarówno do uprawnień, jak i zakresu.

Aby uzyskać więcej informacji, zobacz:

Tworzenie ról niestandardowych dla agentów kompilacji

Automatyzacja ciągłej integracji/ciągłego wdrażania ma zastosowanie nie tylko do aplikacji, ale także do infrastruktury. Szablony infrastruktury jako kodu (IaC) zapewniają spójne wdrożenia i pomagają scentralizowanym zespołom platformy w chmurze skalować.

Ważne jest, aby zrozumieć, że automatyzacja IaC może pójść nie tak. Może on źle skonfigurować i w najgorszych scenariuszach trwale usunąć infrastrukturę. Podczas planowania podróży do chmury zidentyfikuj, które operacje są krytyczne dla działania firmy i wymagają interwencji człowieka.

Na przykład blokady zarządzania nie mogą zostać usunięte, mogą być stosowane do zasobów krytycznych dla działania firmy, takich jak dane. Aby temu zapobiec, możesz usunąć Microsoft.Authorization/*/Delete uprawnienia z jednostki usługi używanej w automatyzacji ciągłej integracji. W tym przykładzie i przypadku użycia jednostka usługi może utworzyć blokadę zarządzania, ale nie usunąć jej.

Zaleca się utworzenie roli niestandardowej dla agentów ciągłej integracji. Pamiętaj, że agenci kompilacji działają bez głowy, a agenci bezgłówni są bez mózgów. Starannie wybierz swoje uprawnienia.

Aby dowiedzieć się więcej, zobacz:

Zasoby

Następne kroki

Teraz, gdy już wiesz, jak zabezpieczyć metodyę DevOps, dowiedz się więcej na temat kompleksowego ładu z usługi DevOps do platformy Azure.

Kompleksowe zarządzanie z usługi DevOps do platformy Azure