Zmiana danych dostępowych w Railway: sprawdź produkcję

Zmiana danych dostępowych obejmuje aktualizację usług, które z nich korzystają, unieważnienie starego dostępu i sprawdzenie, czy zamierzony proces działa z nowymi danymi. Zapisanie nowej zmiennej środowiskowej to część tej pracy. Trzeba jeszcze ustalić, które działające komponenty pobrały nową wartość i co pozostało do sprawdzenia.

Incydent bezpieczeństwa w Railway pokazuje ten problem w praktyce. W komunikacie z 21 października, omawianym na Hacker News, firma ostrzegła, że nieuprawniona osoba mogła uzyskać odszyfrowaną zawartość części zmiennych środowiskowych klientów. Railway zaleciło wymianę zapisanych danych dostępowych i sprawdzenie aktywności u dostawców. W tym czasie wstrzymano budowanie nowych wersji, co ograniczało klientom możliwość wdrożenia nowych danych.

Samo wygenerowanie kolejnego klucza nie rozwiązuje wszystkich zależności. Serwer WWW, proces działający w tle, zadanie cykliczne i pipeline wdrożeniowy mogą potrzebować danych dostępowych. Część z nich może korzystać z tej samej wartości, a część wymagać ponownego połączenia w inny sposób.

Żeby przywrócić działanie usług, potrzebujesz spisu tych zależności. Każdy komponent, którego jeszcze nie sprawdzono, powinien mieć osobę odpowiedzialną za dalszą pracę.

Co zmieniło się w instrukcjach Railway dotyczących przywracania usług?

Zanim skorzystasz ze starszego wpisu o incydencie, sprawdź aktualny komunikat dostawcy. Zalecenie opublikowane podczas blokady wdrożeń może nadal być przydatne, choć informacje o dostępności zdążyły się zdezaktualizować.

Według statusu incydentu, który sprawdziliśmy dla stanu z 23 października, godz. 22:06 UTC, budowanie wersji, wdrożenia, API i panel Railway działały prawidłowo. Wskazówki nadal obejmowały wymianę wrażliwych danych dostępowych, unieważnienie starych i ponowne wdrożenie zależnych usług. Firma zaznaczyła też, że brak powiadomienia o podwyższonym ryzyku nie potwierdza bezpieczeństwa danego obszaru roboczego.

Klienci, którzy wymienili już dane po opanowaniu incydentu, nie musieli powtarzać tej czynności wyłącznie z powodu nowej aktualizacji komunikatu.

Poradnik przywracania wdrożeń z 23 października opisuje kolejną lukę: commity wysłane podczas przerwy nie trafiały do kolejki. Usługi działały na ostatniej poprawnie wdrożonej wersji do czasu uruchomienia kolejnego wdrożenia. Mogły je też blokować unieważnione połączenia z GitHub, sesje CLI lub tokeny wdrożeniowe. Railway zaleca ponowne połączenie albo utworzenie właściwych danych dostępowych przed kolejną próbą.

Przywracanie usług wymaga więc odpowiedzi na dwa pytania: czy możesz wykonać wdrożenie i czy usługa otrzymała nowe dane dostępowe? Naprawienie mechanizmu wdrożeń odpowiada na pierwsze. Na drugie potrzebujesz potwierdzenia z komponentu, którego dotyczy zmiana.

Wstępny raport Railway podaje, że istniejące wdrożenia pozostały dostępne podczas przerwy w budowaniu nowych wersji. To opis działania platformy przedstawiony przez Railway. Nie dowodzi, że każda zewnętrzna integracja klienta nadal działała, zwłaszcza jeśli dostawca innej usługi unieważnił klucz. Dochodzenie wciąż trwało. Ten artykuł nie rozstrzyga, do których danych dostępowych klientów uzyskano dostęp.

Ustal, które komponenty korzystają z danych dostępowych

Zacznij od dostawcy, który wydaje dane dostępowe, i sprawdź, gdzie trafia ich wartość. Spis nazw sekretów mówi, co istnieje. Dopiero przypisanie ich do konkretnych komponentów pokazuje, gdzie nowa wartość musi zacząć obowiązywać.

Osobne wiersze przydadzą się komponentom, które działają lub są konfigurowane niezależnie. Proces WWW i worker mogą należeć do tego samego systemu, a mimo to pobierać konfigurację z różnych miejsc. Token CI może w ogóle nie trafiać do uruchomionej usługi: służy do autoryzacji wdrożenia.

Poniższa tabela to proponowana przez nas metoda pracy, a nie wymóg Railway. Zawiera przykładowe komponenty i nie opisuje każdego systemu działającego na tej platformie.

W każdym wierszu zapisz dostawcę, środowisko, komponent, osobę odpowiedzialną i odnośnik pozwalający znaleźć nowe dane. Jeśli dostawca udostępnia identyfikator danych dostępowych, który nie jest sekretem, możesz go użyć. W przeciwnym razie podaj wewnętrzne oznaczenie konfiguracji, dzięki któremu właściwa osoba znajdzie zmianę bez ujawniania tajnej wartości.

Wyraźnie rozdziel środowisko testowe i produkcyjne. Dwie zmienne o tej samej nazwie mogą dawać dostęp do różnych kont. Z kolei jedne współdzielone dane mogą tworzyć kilka zależności na produkcji.

Poproś osobę odpowiedzialną za każdy komponent o potwierdzenie tego przypisania. Nie zakładaj, że wyszukanie wartości w repozytorium ujawni wszystkie jej kopie.

Do tabeli nie wklejaj tokenów, fragmentów haseł, nagłówków autoryzacji ani pełnych zestawów zmiennych środowiskowych. Zapis ma pomagać w sprawdzeniu zmiany, nie stać się kolejnym miejscem przechowywania sekretu.

Zdecyduj o ograniczeniu dostępu, zanim zaplanujesz wymianę

Plan wymiany musi uwzględniać to, że ujawnione dane mogą nadal działać. Od razu wyznacz osobę odpowiedzialną za decyzję o ograniczeniu dostępu, również wtedy, gdy wdrożenia są zablokowane.

Chęć płynnego przejścia na nowe dane nie może automatycznie oznaczać pozostawienia aktywnego dostępu, który mógł zostać przejęty. Unieważnienie danych może przerwać działanie zależnej usługi. Zależnie od dostawcy, podejrzewanego dostępu i dostępnych zabezpieczeń zaakceptowanie takiej przerwy może być konieczne. Kieruj się instrukcjami dostawcy dotyczącymi incydentu oraz obowiązującą w zespole procedurą reagowania.

Zapisz konkretnie, na czym polega konflikt: które dane trzeba unieważnić, jaki proces może się zatrzymać, kto ma uprawnienia do unieważnienia i kto przywraca działanie procesu. Osoba prowadząca obsługę incydentu dostaje wtedy jasną decyzję do podjęcia. Zdanie „czekamy na platformę” nie wyjaśnia ani ryzyka związanego z dostępem, ani konsekwencji dla dostępności.

Sprawdź też mechanizm wymiany, zanim założysz, że stary i nowy dostęp mogą działać równolegle. Część dostawców obsługuje kilka aktywnych kluczy, inni od razu zastępują dotychczasowe hasło. Planu wymagającego dwóch działających kluczy nie da się bez zmian zastosować u dostawcy, który dopuszcza tylko jeden.

Nasza wcześniejsza checklista zamykania zgłoszeń o ujawnionych danych dostępowych opisuje potwierdzanie unieważnienia dostępu i ograniczenia oceny skutków incydentu. Uwzględnij te pytania przy wymianie, a postęp przywracania usług śledź w wierszach poszczególnych komponentów. Utworzenie nowych danych nie potwierdza, że poprzednie przestały dawać dostęp.

GitHub wyraźnie opisuje tę różnicę w dokumentacji unieważniania tokenów: token, który wygasł lub został unieważniony, nie pozwala na uwierzytelnienie i nie da się go przywrócić. Trzeba utworzyć nowy. Inni dostawcy stosują własne zasady, więc sprawdź zachowanie konkretnej usługi. Nie zakładaj, że wszystkie dane dostępowe działają tak jak token GitHub.

Potwierdź, że działająca usługa pobrała nową konfigurację

Zapisz, jak każdy komponent stosuje konfigurację, a potem wskaż sprawdzoną instancję lub konkretne uruchomienie. Nowa wartość w magazynie sekretów niewiele mówi o procesie, który już działa, dopóki ten proces jej nie zastosuje.

Według dokumentacji zmiennych Railway edycja zmiennych tworzy oczekujące zmiany, które trzeba sprawdzić i wdrożyć. W tym procesie zapisanie nowej wartości i zastosowanie jej we wdrożeniu to dwa odrębne zdarzenia. Zachowaj oznaczenie wdrożenia przy zapisie zmiany konfiguracji.

Inny system może wymagać restartu, ponownego wczytania konfiguracji albo zmiany ustawień integracji. Skorzystaj z mechanizmu opisanego dla danego komponentu. Restart nie jest uniwersalnym zaleceniem: część systemów obsługuje ponowne wczytywanie danych dostępowych, a niektóre zmiany wymagają innej czynności.

W dokumentacji przywracania usług warto rozdzielić trzy stany:

1. Nowe dane przygotowane: dostawca utworzył nowy dostęp, a uprawniona osoba zapisała go we właściwej konfiguracji.
2. Nowe dane zastosowane: komponent zakończył właściwą procedurę ich zastosowania; zapisano oznaczenie wdrożenia lub konfiguracji.
3. Proces sprawdzony: ograniczony test wykorzystał właściwą integrację, a jego wynik został zapisany.

Jeśli ostatni etap jest zablokowany, pozostaw te stany osobno. Zapis „nowa wartość zapisana; zastosowanie przez worker niepotwierdzone” mówi więcej niż pojedyncze zielone pole oznaczające zakończoną wymianę. Następna osoba wie, gdzie podjąć pracę.

Sprawdź również wersję kodu, którą wdrażasz. Wdrożenie przywracające usługę może zawierać zmiany powstałe w czasie awarii. Potwierdź, że zespół zamierza opublikować właśnie wybraną wersję. Nasz poradnik rozdzielania stanu repozytorium i opublikowanego wydania wyjaśnia, dlaczego stan repozytorium i udostępnione artefakty wymagają osobnych potwierdzeń.

Sprawdź jeden ściśle określony proces integracji

Wybierz kontrolowaną operację, która korzysta ze zmienionej zależności. Poprawna odpowiedź ogólnego endpointu sprawdzającego stan usługi może potwierdzać, że program odpowiada, choć połączenie z dostawcą poczty, płatności, pamięci masowej lub AI nadal nie zostało przetestowane.

Przed testem określ oczekiwany wynik. Dla powiadomień może to być jedna autoryzowana wiadomość do odbiorcy kontrolowanego przez zespół, przetworzona przez właściwy worker. Dla integracji API: dozwolony odczyt znanego zasobu.

Dobierz operację do dostawcy i posiadanych uprawnień. Weryfikacja przywracanej usługi nie powinna uruchamiać masowej wysyłki, generować zbędnych kosztów ani wykonywać operacji niszczących dane.

Zapisz komponent, czas, oznaczenie działającego wdrożenia lub konfiguracji oraz wynik. Dodaj identyfikator żądania u dostawcy albo oznaczenie wiadomości, jeśli są dostępne. Jeśli logi dostawcy ujawniają identyfikator danych dostępowych, który sam nie jest sekretem, może on pomóc ustalić, z jakiego dostępu skorzystano. Nie zakładaj, że każdy dostawca go rejestruje.

Zwróć uwagę na to, co potwierdza udany test. Połączenie z puli bazy danych lub token zapisany w pamięci podręcznej może umożliwić operację bez użycia nowo skonfigurowanych danych. Wyjaśnij tę wątpliwość za pomocą testów obsługiwanych przez dostawcę. Jeśli nie da się ustalić, z jakiego dostępu skorzystano, zapisz to i wyznacz osobę do dalszej weryfikacji.

Nieudana operacja również wymaga interpretacji. Błąd uwierzytelnienia, brak uprawnień, niedostępność usługi i niepoprawne żądanie testowe sugerują różne problemy. Zachowaj bezpieczny odnośnik do błędu i przekaż go właściwej osobie.

Wielokrotne generowanie nowych danych bez zrozumienia przyczyny błędu może utrudnić ustalenie, czy zapis konfiguracji jest wiarygodny.

Zapisz niezweryfikowane komponenty, zanim zakończysz przywracanie usług

Zakończ wymianę na podstawie potwierdzeń z każdego istotnego komponentu. Pozostaw nierozstrzygnięty wiersz otwarty, nawet gdy reszta systemu już działa.

Poniższa notatka służy wyłącznie jako przykład przekazania pracy. Imiona, oznaczenia i wyniki pokazują format; nie opisują Railway ani klienta Kit.

Dane dostępowe: tożsamość u dostawcy poczty używana na produkcji, wewnętrzne oznaczenie mail-rotation-24.

Stary dostęp: Lena zapisała unieważnienie przez dostawcę przy podlinkowanym zdarzeniu w jego systemie.

Nowe dane: Arun zaktualizował wersję konfiguracji sender-12.

Zastosowanie: potwierdzono wdrożenie WWW release-208; zastosowanie konfiguracji przez worker wysyłający powiadomienia nadal nie zostało potwierdzone.

Test: dostawca przyjął jedną autoryzowaną wiadomość testową wywołaną przez serwer WWW. Test nie sprawdził wysyłki powiadomień w tle ani nie potwierdził dostarczenia wiadomości do skrzynki odbiorczej.

Pozostała praca: Lena odpowiada za sprawdzenie workera. Wysyłka kampanii pozostaje wstrzymana do czasu uzyskania wyniku.

Notatka pokazuje częściowy wynik i jasno wskazuje brakujące sprawdzenie. Osoba z zespołu może ustalić następne zadanie bez dopytywania, co autor miał na myśli, pisząc „wymieniono”.

Dołącz odnośnik do analizy skutków incydentu, ale opisuj ją osobno. Przywrócenie zamierzonego dostępu nie rozstrzyga, co wydarzyło się przed unieważnieniem danych. Podobnie brak podejrzanej aktywności w dostępnych logach nie dowodzi, że obejmują one cały okres możliwego ujawnienia. Wskaż sprawdzone systemy, przeanalizowany przedział czasu i istotne braki.

Sprawdź połączenie do wysyłki w Kit

Osobno skonfigurowane połączenie do wysyłki potraktuj jako kolejny komponent wymagający zmiany. Aktualizacja środowiska twojej usługi nie aktualizuje hasła zapisanego w zewnętrznej integracji.

W przypadku połączenia do wysyłki w Kit wpisz nowe dane we właściwym formularzu ustawień i zweryfikuj połączenie. Kit usuwa wcześniejsze potwierdzenie SMTP po zmianie takich danych jak host, port, nazwa użytkownika lub hasło. Weryfikacja SMTP polega na połączeniu ze skonfigurowanym serwerem i uwierzytelnieniu.

To test uwierzytelnienia. Nie wysyła wiadomości i nie potwierdza jej przyjęcia przez odbiorcę, umieszczenia w skrzynce odbiorczej, uwierzytelnienia domeny ani pobierania odpowiedzi.

Następnie przeprowadź kontrolowany test procesu, który chcesz przywrócić. Poradnik dostarczania poczty opisuje konfigurację połączenia, a checklista uwierzytelniania e-maili rekrutacyjnych omawia osobne zagadnienia dotyczące uwierzytelnienia domeny.

Jeśli korzystasz również z IMAP do wykrywania odpowiedzi, sprawdź jego konfigurację oddzielnie. Kit może używać osobnego hasła IMAP; gdy pole pozostaje puste, korzysta z hasła SMTP. Zapisz, który wariant działa w twoim połączeniu. Dzięki temu wymiana jednej wartości nie pozostawi niewyjaśnionej drugiej zależności.

Za unieważnienie starego hasła u dostawcy poczty nadal odpowiada twój zespół. Kit nie wymienia danych dostępowych Railway i nie prowadzi spisu komponentów korzystających z sekretu w chmurze. Połączenie do wysyłki jest jednym z miejsc, w których może być potrzebne zastosowanie i sprawdzenie nowych danych.

Przy kolejnej wymianie wskaż dostawcę wydającego dane, spisz korzystające z nich komponenty i wyznacz osobę odpowiedzialną za ograniczenie dostępu. Oddziel zastosowanie konfiguracji od testu działania. Zacznij od jednej rzeczywistej zależności i jasno opisz to, czego jeszcze nie potwierdzono.

Jeśli Kit jest jednym z narzędzi wysyłających twoją pocztę, wykorzystaj weryfikację połączenia do uzupełnienia tego zapisu. Możesz też rozpocząć okres próbny, żeby sprawdzić proces na kontrolowanej skrzynce.