Jak zaplanować backup środowiska CI/CD w chmurze i odtworzyć je po awarii

Po awarii dostawcy chmurowego pipeline przestaje działać w chwili, gdy zespół musi opublikować poprawkę bezpieczeństwa. Kod znajduje się w repozytorium, ale brakuje konfiguracji runnerów, sekretów, definicji wdrożeń i obrazu kontenera, który miał trafić na produkcję.

Backup środowiska CI/CD w chmurze powinien więc obejmować nie tylko kopię projektu w Git. Celem jest odtworzenie zdolności do bezpiecznego pobrania kodu, uruchomienia testów, zbudowania i podpisania artefaktu oraz wdrożenia go do właściwego środowiska. Do tego potrzebny jest plan uwzględniający zakres danych, RPO i RTO, zależności, bezpieczeństwo, automatyzację oraz regularne testy odtwarzania.

Zacznij od scenariusza awarii i określenia granic środowiska CI/CD

Backup CI/CD to coś więcej niż eksport ustawień narzędzia

Najczęstszy błąd polega na utożsamianiu kopii zapasowej z eksportem konfiguracji Jenkins, GitLab CI, GitHub Actions, Azure DevOps, TeamCity albo innego kontrolera pipeline’ów. Taki eksport może zachować definicje zadań, ale niekoniecznie obejmie repozytoria, konfigurację runnerów, obrazy bazowe, sekrety, certyfikaty, klucze podpisujące, rejestry artefaktów i uprawnienia do środowisk docelowych. ^[1]

Pełny backup CI/CD w chmurze trzeba analizować jako kopię całego łańcucha dostarczania oprogramowania. W jego skład wchodzą między innymi:

• repozytoria kodu aplikacji, bibliotek, skryptów i konfiguracji infrastruktury,
• definicje pipeline’ów, reguły uruchamiania, harmonogramy i zatwierdzenia,
• konfiguracja kontrolera CI/CD oraz agentów i runnerów,
• obrazy bazowe, cache zależności i narzędzia używane podczas budowania,
• artefakty buildów, obrazy kontenerowe, pakiety i manifesty wdrożeniowe,
• raporty testów, SBOM-y, wyniki skanowania i podpisy artefaktów,
• sekrety, certyfikaty, tokeny oraz konfiguracja dostępu,
• definicje środowisk, klastrów, sieci i usług zarządzanych,
• integracje z dostawcami chmurowymi, systemami zgłoszeń, komunikatorami i narzędziami bezpieczeństwa.

Nie każdy element musi być przechowywany w ten sam sposób. Repozytorium Git można replikować niemal na bieżąco, obrazy kontenerowe przechowywać w geograficznie oddzielnym rejestrze, a definicje infrastruktury odtwarzać z repozytorium Infrastructure as Code. Istotne jest jednak, aby dla każdej części środowiska istniała odpowiedź na pytanie: skąd ją pobierzemy, kto może to zrobić i w jakim czasie?

Rozważ różne klasy awarii

Plan disaster recovery pipeline’ów nie powinien opisywać wyłącznie całkowitej utraty regionu chmurowego. Znacznie częściej występują awarie pojedynczych usług, błędne zmiany konfiguracji, wygaśnięcie certyfikatu albo utrata uprawnień. Każdy z tych scenariuszy wymaga innej procedury.

Scenariusz „dostawca chmurowy nie działa” jest zbyt ogólny, aby na jego podstawie przygotować skuteczną procedurę. Trzeba doprecyzować, czy niedostępny jest tylko panel administracyjny, API, konkretny region, wszystkie zasoby sieciowe, czy także zewnętrzny system tożsamości. Inaczej będzie wyglądało odtworzenie pipeline’u po przypadkowym usunięciu projektu, a inaczej po kompromitacji klucza dostępowego. ^[4]

Wyznacz właścicieli i granice odpowiedzialności

Odtwarzanie środowiska CI/CD często zatrzymuje się nie na technologii, lecz na braku właściciela. Zespół platformowy może odpowiadać za kontroler pipeline’ów i runnery, ale nie znać wymagań dotyczących artefaktów aplikacyjnych. Zespół bezpieczeństwa może zarządzać kluczami, lecz nie wiedzieć, które certyfikaty są niezbędne do wdrożenia. Administrator chmury może odtworzyć sieć, ale nie powinien samodzielnie ustalać, które sekrety mogą zostać przywrócone.

Dla każdego elementu należy zapisać właściciela technicznego, osobę zatwierdzającą odtworzenie, lokalizację kopii oraz procedurę weryfikacji. Przykładowy podział może wyglądać następująco:

Przy planowaniu kolejnych kroków pomocny może być tekst: Jak pisać testy integracyjne przyjazne pipelines.

• zespół platformowy – kontroler CI/CD, runnery, szablony pipeline’ów i integracje techniczne,
• właściciele repozytoriów – kod, konfiguracja aplikacji, branch protection i reguły wydawnicze,
• zespół bezpieczeństwa – klucze, sekrety, certyfikaty, podpisy oraz kontrola dostępu,
• administratorzy chmury – konta, sieć, IAM, klastry i usługi zarządzane,
• zespoły aplikacyjne – krytyczność usług, kolejność wdrożeń i walidacja działania.

Mini-wniosek: plan odzyskiwania jest użyteczny dopiero wtedy, gdy opisuje konkretny zakres odpowiedzialności i realne scenariusze, a nie ogranicza się do stwierdzenia „mamy backup”.

1. Ustal RPO, RTO i kolejność przywracania usług

RPO i RTO dopasowane do procesu dostarczania

RPO określa maksymalną akceptowalną utratę zmian. Jeżeli RPO dla konfiguracji pipeline’u wynosi godzinę, kopia wykonywana raz na dobę nie spełnia wymagania. RTO oznacza maksymalny czas potrzebny na przywrócenie określonej funkcji. Nie musi oznaczać pełnego odtworzenia wszystkich danych historycznych; może dotyczyć na przykład ponownego zbudowania i wdrożenia krytycznej poprawki. ^[2]

W jednym środowisku CI/CD różne zasoby mogą mieć zupełnie inne wartości RPO i RTO. Kod i definicje wdrożeń powinny być dostępne niemal bez przerwy, ponieważ utrata ostatnich commitów może uniemożliwić odtworzenie właściwej wersji aplikacji. Historia logów starych buildów może mieć dłuższy czas odtworzenia, o ile nie jest wymagana do audytu lub analizy incydentu.

Wymagania biznesowe powinny poprzedzać wybór technologii. Krytyczne wdrożenia produkcyjne mogą wymagać szybkiego odtworzenia, lecz proces publikacji bibliotek wewnętrznych może działać w trybie ograniczonym. Inne priorytety będzie miał zespół utrzymujący system płatności, inne firma wydająca aplikację mobilną raz na kilka tygodni, a jeszcze inne organizacja, która musi szybko publikować poprawki bezpieczeństwa.

Macierz krytyczności i kolejność odtwarzania

Odtwarzanie środowiska DevOps powinno przebiegać według zależności, a nie według wygody administratora. Dashboard obserwowalności może być przydatny, ale nie zastąpi repozytorium, dostępu do sekretów ani runnera. Przydatna kolejność obejmuje następujące warstwy:

1. Tożsamość i dostęp – konta administracyjne, federacja, role, klucze awaryjne i zasady MFA.
2. Repozytoria – kod aplikacji, konfiguracja, definicje pipeline’ów i Infrastructure as Code.
3. Infrastruktura jako kod – sieć, magazyny, klastry, rejestry i usługi wymagane przez CI/CD.
4. Menedżer sekretów – klucze, certyfikaty, dane dostępowe i konfiguracja szyfrowania.
5. Artefaktoria – obrazy, pakiety, binaria, manifesty i podpisy.
6. Kontroler CI/CD – projekty, pipeline’y, kolejki, polityki i integracje.
7. Agenty i runnery – środowiska wykonawcze, obrazy narzędziowe i dostęp do sieci.
8. Integracje i obserwowalność – webhooki, powiadomienia, logi oraz metryki.

Każda zależność powinna być zapisana w runbooku. Pipeline nie uruchomi się bez runnera. Runner nie pobierze kodu bez dostępu do repozytorium. Proces budowania może wymagać dostępu do cache zależności, a wdrożenie nie powiedzie się bez sekretów i uprawnień do klastra. Jeżeli rejestr obrazów jest niedostępny, można czasem zbudować artefakt ponownie, ale tylko wtedy, gdy dostępne są wszystkie źródła i zależności.

Dobrym narzędziem jest macierz krytyczności, w której przy każdym zasobie zapisuje się priorytet, zależności, właściciela, lokalizację kopii i sposób walidacji. Dzięki temu zespół nie traci pierwszych godzin awarii na odtwarzanie mniej istotnych raportów, zanim odzyska możliwość budowania i dostarczania oprogramowania.

2. Zrób inwentaryzację danych, konfiguracji i usług, które naprawdę trzeba zachować

Po określeniu priorytetów trzeba przejść od ogólnego zakresu do konkretnego katalogu zasobów. Sama nazwa usługi, na przykład „GitLab”, „Jenkins” albo „rejestr obrazów”, nie wystarcza. W praktyce odtworzenie zależy także od ustawień projektu, danych uwierzytelniających, reguł dostępu, certyfikatów, wersji pluginów i zależności zewnętrznych.

Dobrym uzupełnieniem tego tematu jest także poradnik: Tekton Chains – supply chain auditable builds.

Inwentaryzacja powinna odpowiadać na cztery pytania:

• co trzeba zachować,
• gdzie znajduje się źródło danych i kopia zapasowa,
• w jakiej wersji można odtworzyć zasób,
• jak sprawdzić, że po przywróceniu działa poprawnie.

Podziel zasoby według sposobu odtworzenia

Najwygodniej nie tworzyć jednej długiej listy wszystkich komponentów, lecz podzielić je na klasy. Każda klasa wymaga innej metody backupu i innego testu odtworzeniowego. ^[3]

Taki podział ułatwia wykrycie luk. Organizacja może mieć kopię kodu i obrazów, ale nie przechowywać informacji o tym, który obraz został zaakceptowany do wdrożenia, jaką wersję pipeline’u wykorzystano i kto zatwierdził publikację.

Oddziel dane od konfiguracji

Konfiguracja opisuje, jak zbudować usługę, natomiast dane pozwalają zachować jej stan i historię. W przypadku kontrolera CI/CD konfiguracją mogą być definicje jobów, ustawienia agentów i integracje, a danymi — historia uruchomień, kolejki, raporty oraz zapisane identyfikatory wersji.

Ten podział ma praktyczne znaczenie. Jeżeli usługa może zostać odtworzona z kodu i IaC, nie zawsze trzeba wykonywać jej pełny obraz binarny. Jeżeli jednak utrata historii zatwierdzeń lub raportów testów narusza wymagania audytowe, te dane muszą mieć osobną politykę przechowywania.

• Konfigurację deklaratywną trzymaj w kontroli wersji i przeglądaj tak jak kod.
• Dane stanu kopiuj zgodnie z ich zmiennością oraz znaczeniem dla odtworzenia.
• Dane tymczasowe oznacz wyraźnie, aby nie zwiększać kosztu backupu bez uzasadnienia.
• Metadane wydań zachowuj razem z artefaktem, którego dotyczą.

Przykładowo cache zależności może być odtwarzalny i mieć krótką retencję, ale manifest produkcyjnego obrazu, jego digest, podpis i wynik skanowania bezpieczeństwa powinny być przechowywane znacznie dłużej.

Zapisz źródło prawdy dla każdego elementu

W środowisku chmurowym ten sam parametr często występuje w kilku miejscach: w repozytorium, panelu usługi, zmiennej środowiskowej i narzędziu zarządzającym sekretami. Jeżeli katalog nie wskazuje źródła prawdy, podczas odtwarzania można przypadkowo przywrócić niespójną konfigurację.

Dla każdego zasobu warto zapisać między innymi:

• nazwę logiczną i identyfikator w chmurze,
• konto, projekt lub subskrypcję, w której działa,
• źródło konfiguracji,
• miejsce przechowywania kopii,
• format eksportu i wymagane narzędzie do importu,
• zależne zasoby oraz wymagane uprawnienia,
• okres retencji i datę ostatniego udanego backupu,
• osobę lub zespół wykonujący test odtworzenia.

Przykładowy wpis może wyglądać tak:

zasób: registry-prod
typ: rejestr obrazów
źródło konfiguracji: repozytorium platform-iac
kopia: registry-dr.example.net
zakres: obrazy produkcyjne, manifesty, podpisy, SBOM
retencja: 180 dni
zależności: KMS, IAM, DNS
walidacja: pull obrazu po digest, weryfikacja podpisu, test wdrożenia

Tak opisany rekord jest użyteczniejszy niż ogólna informacja „rejestr jest objęty backupem”. Administrator wie, co ma pobrać, z jakiego miejsca, za pomocą jakiego procesu i po czym poznać, że operacja się udała.

Nie pomijaj usług zewnętrznych i ustawień niewidocznych w repozytorium

Najczęstsze braki dotyczą elementów, które nie są częścią głównego narzędzia CI/CD. Należą do nich webhooki, aplikacje OAuth, reguły zapory, rekordy DNS, połączenia z systemem zgłoszeń, konfiguracja powiadomień oraz ograniczenia adresów IP. Po odtworzeniu pipeline może wyglądać poprawnie, ale nadal nie otrzymywać zdarzeń z repozytorium albo nie mieć dostępu do klastra.

Jeśli chcesz pogłębić ten wątek, sprawdź też: Kiedy potrzebujesz pentestu pipeline’u?.

W katalogu trzeba uwzględnić także:

• integracje z dostawcami Git i systemami zgłoszeń,
• role i konta techniczne używane przez pipeline’y,
• federację tożsamości oraz aplikacje zarejestrowane w systemie IAM,
• reguły sieciowe, prywatne endpointy i listy dozwolonych adresów,
• DNS, certyfikaty TLS i automatyczne mechanizmy ich odnowienia,
• ustawienia podpisywania obrazów, pakietów i commitów,
• konfigurację powiadomień oraz integracji z systemami monitoringu.

Nie oznacza to, że każdą usługę trzeba eksportować do tego samego magazynu. Ważne jest, aby informacja o sposobie jej odtworzenia znajdowała się w katalogu, a procedura nie zależała od pamięci pojedynczego administratora.

Oznacz dane, których nie wolno przywracać bez dodatkowej kontroli

Backup nie powinien automatycznie oznaczać prawa do automatycznego importu. Szczególnej ostrożności wymagają sekrety, klucze podpisujące, certyfikaty produkcyjne i poświadczenia kont uprzywilejowanych. Ich kopia musi być szyfrowana, a dostęp do niej powinien wymagać dodatkowego zatwierdzenia.

W katalogu warto dodać klasy dostępu, na przykład:

• publiczne lub odtwarzalne – konfiguracja IaC, obrazy bazowe, definicje pipeline’ów,
• wewnętrzne – logi, raporty i ustawienia integracji,
• poufne – sekrety aplikacyjne, tokeny i certyfikaty,
• krytyczne – klucze główne, klucze podpisujące i awaryjne dane dostępowe.

Przywrócenie krytycznego sekretu powinno obejmować sprawdzenie jego pochodzenia, integralności, okresu ważności i zakresu uprawnień. W niektórych przypadkach bezpieczniej jest wygenerować nowe poświadczenie i użyć kopii wyłącznie jako informacji pomocniczej, zamiast ponownie aktywować dawny klucz.

Regularnie usuwaj nieaktualne wpisy

Inwentaryzacja szybko się dezaktualizuje. Zespół może usunąć projekt, zmienić nazwę rejestru, przenieść repozytorium albo zastąpić integrację inną usługą, a dokumentacja nadal będzie wskazywać poprzedni zasób. Dlatego katalog powinien być aktualizowany jako część procesu zmiany, a nie tylko podczas corocznego przeglądu.

Praktycznym rozwiązaniem jest wymaganie aktualizacji wpisu przy:

• utworzeniu nowego repozytorium lub pipeline’u produkcyjnego,
• zmianie dostawcy chmurowego albo regionu,
• dodaniu nowej integracji lub konta technicznego,
• zmianie sposobu przechowywania sekretów,
• wycofaniu usługi i zakończeniu jej retencji.

Raz na ustalony okres warto automatycznie porównać katalog z rzeczywistymi zasobami chmury i systemu kontroli wersji. Różnice powinny trafiać do właścicieli do wyjaśnienia, ponieważ nieudokumentowany zasób może stać się brakującym elementem podczas awarii.

Najlepszy katalog backupu nie jest statycznym dokumentem. Powinien być wersjonowany, możliwie generowany z istniejących źródeł i sprawdzany podczas ćwiczeń odtworzeniowych. Dzięki temu zespół przechowuje nie tylko kopie danych, ale również wiedzę potrzebną do ich właściwego użycia.

Co warto zapamiętać

• Backup środowiska CI/CD powinien obejmować cały łańcuch dostarczania oprogramowania, a nie tylko repozytorium Git lub eksport konfiguracji pipeline’u.
• Zakres kopii należy określić na podstawie scenariuszy awarii, zależności, właścicieli zasobów oraz wymagań RPO i RTO.
• Do ochrony wymagają się między innymi repozytoria, definicje pipeline’ów, runnery, obrazy bazowe, artefakty, sekrety, certyfikaty, klucze, uprawnienia i infrastruktura jako kod.
• Odtwarzanie powinno przebiegać według zależności: od tożsamości i dostępu, przez repozytoria oraz infrastrukturę, po menedżer sekretów, artefaktoria, kontroler CI/CD i runnery.
• Skuteczność planu potwierdzają regularne testy odtwarzania, niezależne kopie oraz runbooki opisujące odpowiedzialność, lokalizację danych i sposób walidacji.

Źródła

• [1] GitLab Docs – Back up GitLab ↑
• [2] GitLab Docs – Restore GitLab ↑
• [3] GitLab Docs – Backup and restore a GitLab instance ↑
• [4] Microsoft Learn – Data protection overview – Azure DevOps Services ↑