Zabezpieczanie repozytoriów i potoków
Gdy używasz automatyzacji do wdrażania infrastruktury, potok i repozytorium stają się zaawansowane i ważne. Ponieważ teraz reprezentują one jedyny sposób, w jaki zmiany są stosowane do kontrolowanych środowisk.
Wiele części organizacji usługi Azure DevOps, repozytorium GitHub i potoków musi być chronionych. Poniższa tabela zawiera niektóre z najważniejszych elementów do ochrony, a także przykłady luk w zabezpieczeniach, które mogą wystąpić, jeśli te elementy nie są odpowiednio chronione.
| Element do ochrony | Przykładowa luka w zabezpieczeniach |
|---|---|
| Twoja organizacja usługi Azure DevOps lub repozytorium GitHub, w tym kto ma do niego dostęp i co mogą zrobić. | Niezadowolony były pracownik usuwa repozytorium kodu. |
| Ważne gałęzie w repozytorium i co należy zrobić, aby zmienić kod w tych gałęziach. | Ktoś przypadkowo zatwierdzi niezabezpieczony kod Bicep w głównej gałęzi repozytorium. |
| Kod wewnątrz repozytorium, w tym definicje infrastruktury, testy i kod aplikacji. | Ktoś zapomni przetestować napisany przez nich kod i nie działa poprawnie po wydaniu go do środowiska produkcyjnego. |
| Definicja potoku. | Ktoś przypadkowo dodaje krok potoku, który zapisuje bazę danych parametry połączenia w dzienniku potoku. |
| Agenci lub moduły uruchamiające potok. | Potok uruchomiony względem roboczego żądania ściągnięcia instaluje na agencie lukę w zabezpieczeniach, która jest później używana do wdrożenia produkcyjnego. |
| Wszystkie zadania lub składniki innych firm, które mogą być uruchamiane w potoku. | Zadanie potoku innej firmy wysyła poświadczenia jednostki usługi do złośliwej witryny internetowej. |
| Jednostki usługi używane przez potok do uzyskiwania dostępu do platformy Azure. | Jednostka usługi nieprodukcyjnej przypadkowo wprowadza zmianę w środowisku produkcyjnym. |
| Wpisy tajne używane przez potok do uzyskiwania dostępu do systemów zewnętrznych. | Członek zespołu zapisuje nowy plik definicji potoku dla prototypu i przypadkowo łączy go ze środowiskiem produkcyjnym. |
Teraz dowiesz się więcej o niektórych podejściach, których można użyć do zastosowania ładu i mechanizmów kontroli wokół repozytorium kodu i potoków wdrażania, w usługach Azure DevOps i GitHub.
Zarządzanie użytkownikami i uprawnieniami
Zastanów się, jak udzielić dostępu do organizacji usługi Azure DevOps lub repozytorium GitHub. Zastanów się, kto ma dostęp i co może zrobić.
Dobrym rozwiązaniem jest użycie wystąpienia firmy Microsoft Entra w organizacji jako dostawcy tożsamości potoku. Dzięki temu możesz mieć pewność, że za każdym razem, gdy ktoś dołączy lub opuści organizację, dostęp do potoku zostanie automatycznie udzielony lub odwołany. Za pomocą identyfikatora Entra firmy Microsoft można również łatwo zaimplementować zabezpieczenia, takie jak dostęp warunkowy i uwierzytelnianie wieloskładnikowe.
Uwaga
Aby korzystać z integracji firmy Microsoft Entra z usługą GitHub, twoja organizacja potrzebuje licencji GitHub Enterprise.
Możesz również tworzyć zespoły (w usłudze GitHub) lub grupy (w usłudze Azure DevOps), które reprezentują zestawy użytkowników, którzy mogą mieć przyznane uprawnienia razem. W ten sposób nie trzeba przypisywać uprawnień indywidualnie. Łatwo jest zmienić uprawnienia użytkowników, dodając je do i usuwając je z zespołu lub grupy.
Napiwek
Usługa Azure DevOps używa modelu uprawnień najniższych uprawnień , który różni się od modelu używanego przez platformę Azure. W usłudze Azure DevOps odmowa uprawnień zastępuje uprawnienia zezwalania. Oznacza to, że w przypadku przypisania do wielu grup z różnymi zestawami uprawnień będzie można wykonywać tylko akcje dozwolone przez wszystkie grupy.
Upewnij się, że rozumiesz, w jaki sposób uprawnienia są przypisywane, szczególnie do grup.
Ochrona ważnych gałęzi kodu
Potoki i automatyzacja powinny być oparte na identyfikowaniu określonych gałęzi kodu, takich jak główne. Kod dla tych wyznaczonych gałęzi jest zwykle zaufany i może być wdrażany w środowiskach produkcyjnych. Zastosuj kontrolki, aby upewnić się, że kod w ważnych gałęziach został zweryfikowany i sprawdzony.
Rozważ użycie reguł ochrony gałęzi (w usłudze GitHub) lub zasad gałęzi (w usłudze Azure Repos), aby zapobiec bezpośrednim zatwierdzaniu ważnych gałęzi kodu. Następnie możesz wymagać, aby zespół używał żądań ściągnięcia, aby scalić wszelkie zmiany. Aby sprawdzić, czy zmiany są prawidłowe przed scaleniem, można zastosować zautomatyzowane kontrole i procesy ręcznego przeglądu.
Testowanie i przeglądanie kodu
Upewnij się, że twój zespół rozumie oczekiwania dotyczące przeglądania i testowania całego kodu, w tym definicji infrastruktury.
Definicje potoku to pliki YAML, więc są one formą kodu. Należy przejrzeć i ocenić zmiany definicji potoku. W przeciwnym razie ktoś może przypadkowo lub złośliwie utworzyć krok potoku, który wycieka poświadczeń jednostki usługi lub wprowadza niebezpieczną zmianę w infrastrukturze platformy Azure.
Wszelkie zmiany w plikach definicji potoku należy dokładnie przejrzeć. Upewnij się, że wszyscy członkowie zespołu rozumieją, że potoki są wysoce uprzywilejowane i wymagają szczególnej uwagi.
Ochrona agentów potoku i modułów uruchamiających
Potok działa na agentach (w przypadku usługi Azure Pipelines) lub modułów uruchamiających (w przypadku funkcji GitHub Actions). Agentów i modułów uruchamiających można traktować jako maszyny wirtualne. Definicja potoku kontroluje te maszyny wirtualne, uruchamiając podane zadania i skrypty.
Zarówno usługi Azure Pipelines, jak i GitHub Actions udostępniają hostowanych agentów i modułów uruchamiających, które firma Microsoft lub GitHub konfiguruje i utrzymuje. Właściciel platformy konfiguruje maszyny zgodnie z zalecanymi rozwiązaniami w zakresie zabezpieczeń. Obowiązki właściciela platformy obejmują stosowanie poprawek w zabezpieczeniach systemu operacyjnego.
Zamiast tego możesz użyć własnych maszyn fizycznych lub wirtualnych dla agentów i modułów uruchamiających. Maszyny tego typu są nazywane własnymi agentami i modułami uruchamiającym. Jeśli używasz własnych agentów i modułów uruchamiających, odpowiadasz za upewnienie się, że maszyny są prawidłowo skonfigurowane i chronione przed zagrożeniami.
Agenci hostowani przez firmę Microsoft i moduły uruchamiające hostowane w usłudze GitHub są efemeryczne. Wszystkie pliki lub zmiany konfiguracji agenta lub modułu uruchamiającego są niszczone po zakończeniu przebiegu potoku. W przypadku samodzielnego hostowania agenta lub modułu uruchamiającego ten sam komputer prawdopodobnie będzie używany dla wielu oddzielnych potoków lub środowisk, w tym środowisk produkcyjnych i nieprodukcyjnych. Załóżmy, że ktoś tworzy definicję potoku, która modyfikuje niektóre ważne pliki w systemie operacyjnym agenta i uruchamia potok z żądania ściągnięcia. Następnym razem, gdy wdrożenie zostanie uruchomione w środowisku produkcyjnym, może ponownie użyć agenta. Teraz nie masz możliwości przewidywania wpływu uszkodzonego pliku na środowisko produkcyjne.
Z tych powodów dobrym rozwiązaniem jest użycie agentów hostowanych przez firmę Microsoft i modułów uruchamiających usługę GitHub zawsze wtedy, gdy jest to możliwe. Jeśli musisz używać modułów uruchamianych samodzielnie, dokładnie oceń czynniki ryzyka związane z ich konfiguracją i użyciem.
Ocena składników innych firm uruchamianych w potoku
Jeśli używasz udostępnionych przez społeczność rozszerzeń GitHub Actions lub Azure DevOps, dowiedz się, kto je utworzył i co robi. Składniki potoków innych firm mogą mieć dostęp do poświadczeń jednostki usługi, a tym samym całego środowiska na platformie Azure.
W usłudze Azure DevOps administrator organizacji zwykle zatwierdza każde rozszerzenie, zanim będzie można go używać. Jeśli jesteś administratorem organizacji, rozważ ryzyko bezpieczeństwa związane z każdym używanym składnikiem. Odpowiadasz za sprawdzenie, czy są wiarygodne i bezpieczne.
Za każdym razem, gdy używasz akcji lub zadania innej firmy, należy określić wersję. Rozważ określenie dokładnej wersji, która została sprawdzona. Zezwolenie potokowi na automatyczne korzystanie z nowszej wersji może spowodować ryzyko, że nie sprawdzono.
Ochrona jednostek usługi potoku
Potoki używają jednostek usługi do uzyskiwania dostępu do platformy Azure i innych usług. Ważne jest, aby chronić jednostki usługi i upewnić się, że ich poświadczenia nie mogą być niewłaściwie używane. Rozważ zastosowanie wielu warstw ochrony.
Najpierw możesz rozważyć ochronę poświadczeń dla jednostek usługi:
- Jeśli to możliwe, użyj tożsamości zarządzanych lub tożsamości obciążeń, aby uniknąć całkowitego przechowywania poświadczeń. Chociaż nie można używać tożsamości zarządzanych ani tożsamości obciążeń ze wszystkimi potokami, dobrym rozwiązaniem jest to, aby to zrobić, gdy możesz.
- Zaplanuj regularne zmienianie lub obracanie poświadczeń jednostki usługi. Na przykład organizacja może mieć zasady rotacji poświadczeń co 90 lub 120 dni. Zastanów się, kto będzie odpowiedzialny za rotację i jak zaktualizujesz wszystkie miejsca, w których jest używane poświadczenie.
- Rozważ wyznaczenie tajnego opiekuna, którego rolą jest zarządzanie wpisami tajnymi, kluczami i certyfikatami, aby nie były widoczne dla innych części organizacji.
Następnie pomyśl o uprawnieniach udzielanych jednostkom usługi:
- Zastosuj zasady dostępu warunkowego firmy Microsoft entra do jednostek usługi potoku. Te zasady pomagają identyfikować ryzykowne logowania i zachowania. Jeśli na przykład jednostki usługi potoku zawsze loguje się z jednego regionu geograficznego, dostęp warunkowy może wykrywać i zapobiegać logowaniu się z nieoczekiwanych lokalizacji, co może wskazywać, że poświadczenia zostały naruszone.
- Dokładnie zastanów się nad uprawnieniami udzielanym każdemu jednostce usługi. Załóżmy na przykład, że masz jednostkę usługi używaną do odczytywania konfiguracji zasobu udostępnionego. Zastanów się, czy możesz udzielić dostępu tylko czytelnika do tej jednostki usługi, ponieważ jednostka usługi nie musi wykonywać żadnych czynności, które wymagają większej liczby uprawnień.
- Użyj minimalnego zakresu dla każdego uprawnienia przypisanego do jednostki usługi. Jeśli na przykład jednostka usługi musi zostać wdrożona tylko w jednej grupie zasobów, określ zakres przypisania roli do tej grupy zasobów zamiast do całej subskrypcji.
- Użyj oddzielnych jednostek usługi dla każdego środowiska. W ten sposób, nawet jeśli poświadczenia podmiotu zabezpieczeń zostały naruszone lub jeśli ktoś uzyska dostęp do jednego środowiska, nie może uzyskać dostępu do innych środowisk.
Ochrona połączeń i wpisów tajnych usługi
Połączenie usługi (w usłudze Azure Pipelines) lub wpis tajny (w usłudze GitHub) zawiera poświadczenia jednostki usługi używanej przez potok w celu uzyskania dostępu do środowiska platformy Azure. Ważne jest, aby chronić połączenia i wpisy tajne usługi oraz określać, które potoki używają każdego połączenia z usługą i wpisu tajnego. W przeciwnym razie możesz przypadkowo włączyć środowisko nieprodukcyjne, aby użyć jednostki usługi, która ma dostęp do zasobów produkcyjnych.
W usłudze Azure DevOps podczas tworzenia połączenia z usługą można skonfigurować je tak, aby wymagać zatwierdzenia przed użyciem nowego potoku lub środowiska.
Usługa Azure DevOps umożliwia również kojarzenie kontroli z określonymi połączeniami usług. Testy dodają kolejną warstwę ochrony. Można na przykład skonfigurować sprawdzanie połączenia usługi produkcyjnej, aby sprawdzić, czy jest on używany tylko w kodzie z głównej gałęzi repozytorium. Ta kontrola pomaga zapobiec wdrożeniu nieautoryzowanego kodu w środowisku produkcyjnym.
W usłudze GitHub można skonfigurować wpisy tajne specyficzne dla środowiska, dzięki czemu gdy przepływ pracy funkcji GitHub Actions współpracuje z tym środowiskiem, udostępnia tylko wartość wpisu tajnego. Korzystając z wpisów tajnych specyficznych dla środowiska i kontrolek środowiska, takich jak zatwierdzenia, można zmniejszyć ryzyko, że wdrożenie nieprodukcyjne jest używane do wdrażania w środowisku produkcyjnym. Możesz również użyć tożsamości obciążeń, aby uniknąć używania poświadczeń w przepływach pracy funkcji GitHub Actions i wyeliminować możliwość uwidocznienia poświadczeń.
Korzystanie z funkcji zabezpieczeń usługi GitHub
Usługa GitHub udostępnia funkcje zabezpieczeń, które należy oceniać i używać. Do tych funkcji należą:
- Dependabot, który skanuje zależności kodu źródłowego pod kątem znanych luk w zabezpieczeniach.
- Skanowanie wpisów tajnych, które identyfikuje tekst w repozytorium, który wygląda jak klucze lub poświadczenia. Dobrym rozwiązaniem jest przechowywanie wpisów tajnych w repozytorium. Jeśli otrzymasz alert o wpisie tajnym w repozytorium, rozważ naruszenie wartości wpisu tajnego, a następnie odwołaj go lub zmień.
- Inspekcja, aby dowiedzieć się, kto wprowadził zmiany w konfiguracji usługi GitHub.
- Omówienie zabezpieczeń, które konsoliduje wszystkie alerty zabezpieczeń w repozytoriach organizacji.
Korzystanie z dzienników inspekcji usługi Azure DevOps
Usługa Azure DevOps udostępnia dzienniki inspekcji , które ułatwiają zrozumienie, kto wprowadził zmiany w potokach, zasadach gałęzi, repozytoriach i innych zasobach. Dobrym rozwiązaniem jest włączenie inspekcji i regularne przeglądanie dzienników inspekcji.
Ochrona repozytorium i potoku
Omówiliśmy ważne kontrolki, które można zastosować do repozytorium i potoku. Teraz rozważmy, które kontrolki mogą być używane do ochrony każdego z ważnych elementów wymienionych wcześniej w tej lekcji:
| Element do ochrony | Kontrolki do zastosowania |
|---|---|
| Twoja organizacja usługi Azure DevOps lub repozytorium GitHub, w tym kto ma do niego dostęp i co mogą zrobić. |
|
| Ważne gałęzie w repozytorium i co należy zrobić, aby zmienić kod w tych gałęziach. | Zastosuj reguły ochrony gałęzi lub zasady gałęzi. |
| Kod wewnątrz repozytorium, w tym definicje infrastruktury, testy i kod aplikacji. |
|
| Definicja potoku. | Wymuszanie wymagań dotyczących przeglądu kodu. |
| Agenci lub moduły uruchamiające potok. |
|
| Wszystkie zadania lub składniki innych firm, które mogą być uruchamiane w potoku. | Przejrzyj ryzyko bezpieczeństwa skojarzone ze wszystkimi rozszerzeniami i zadaniami innych firm. |
| Jednostki usługi używane przez potok do uzyskiwania dostępu do platformy Azure. |
|
| Wpisy tajne używane przez potok do uzyskiwania dostępu do systemów zewnętrznych. |
|