Railway przywróciło normalną pracę platformy po październikowym incydencie, ale status usługi nie rozstrzyga bezpieczeństwa sekretów klientów. Na 26 października zadaniem zespołów jest ustalenie, które dane uwierzytelniające już wymieniły i czy stare przestały działać. Brak wiadomości od dostawcy nie jest dowodem braku narażenia.

Wyobraź sobie recepcję, która po włamaniu znów wydaje gościom karty i przyjmuje rezerwacje. Działający terminal mówi, że można obsłużyć kolejną osobę. Nie odpowiada jednak na pytanie, czy ktoś wcześniej skopiował klucze do pomieszczeń. Ta analogia pomaga oddzielić dwa zadania po incydencie Railway: uruchomienie platformy i zamknięcie dostępu do usług, których sekrety przechowywała. Dla właściciela aplikacji są to dwa osobne kryteria zakończenia pracy. Zespół może mieć działające wdrożenia oraz nierozliczone hasło do bazy. Może też zakończyć rotację i nie mieć powodu, żeby powtarzać ją po każdym kolejnym komunikacie. Potrzebny jest zapis wykonanych czynności, z datą i właścicielem, zamiast samego zielonego statusu.

Railway potwierdziło możliwość odczytu sekretów

Według wstępnego raportu Railway z 22 października atak trwał od 20 października, godziny 13:58 UTC, do 22 października, godziny 03:32 UTC, kiedy firma potwierdziła usunięcie dostępu sprawcy. Część sekretów odszyfrowano. Dostawca wskazał maksymalnie 1,85% przestrzeni roboczych, około 100 tysięcy, jako zakres możliwego narażenia zmiennych środowiskowych. Raport miał charakter wstępny i nie rozstrzygał dostępu do kodu klientów.

Pierwsze ujawnienie z 21 października dotyczyło możliwego odczytu odszyfrowanych zmiennych. Natomiast zalecenie z 23 października obejmowało prewencyjne unieważnienie i zastąpienie wrażliwych danych uwierzytelniających zapisanych przed 21 października oraz przegląd audytu GitHub i rejestrów kontenerów.

Nasza analiza zaczyna się od rozróżnienia sekretu i jego kopii. Usunięcie wartości z konfiguracji aplikacji nie daje jeszcze potwierdzenia, że usługa docelowa odrzuci poprzednie dane uwierzytelniające. Dlatego w rozliczeniu Railway powinny znaleźć się dwie odpowiedzi: gdzie aplikacja korzysta z nowej wartości oraz kto potwierdził unieważnienie poprzedniej. Ten podział ułatwia też rozmowę między programistą a administratorem usługi, do której sekret otwierał dostęp.

O zakończeniu rotacji decyduje unieważnienie starego sekretu, a nie samo zapisanie nowego w panelu.

Status resolved nie opisuje wszystkich zależności klienta

Historia statusu Railway, sprawdzona 26 października, pokazuje incydent platformowy jako rozwiązany; normalnie działają budowanie, wdrożenia, API i panel. Zamknięcie z 23 października o 22:06 UTC, czyli 24 października o 00:06 czasu polskiego, nie zmienia zalecenia rotacji, jeżeli klient jeszcze jej nie wykonał, oraz odtworzenia zależnych usług. Według raportu wstępnego uruchomione aplikacje działały również podczas wstrzymania nowych wdrożeń.

Wniosek redakcji dotyczy kryterium odbioru naprawy. Test polegający na otwarciu strony klienta odpowiada na pytanie o dostępność strony. Nie sprawdza automatycznie wszystkich połączeń wykorzystujących wymienione dane uwierzytelniające. Zalecamy oddzielne potwierdzenie działania tych zależności, które właściciel aplikacji wskazał w spisie rotacji. Zespół nie musi zgadywać całego katalogu możliwych integracji; powinien zacząć od konfiguracji, którą faktycznie utrzymuje w Railway.

Druga pułapka to interpretacja powiadomień. Railway podało, że prewencyjne unieważnienia przez dostawców miały szerszy zakres niż potwierdzony wpływ. Taki komunikat sam w sobie nie dowodzi kradzieży. W drugą stronę brak maila również nie daje podstaw do zamknięcia sprawy. W naszej ocenie zespół powinien oprzeć kwalifikację sekretu do przeglądu na miejscu i czasie jego przechowywania oraz zaleceniach dostawcy, nie na stanie skrzynki odbiorczej.

Zarząd potrzebuje wyniku rotacji, nie licznika zmian

Proponujemy, aby osoba odpowiedzialna za incydent Railway przedstawiła zarządowi krótką tabelę sekretów i właścicieli. Przy każdym wpisie powinny znaleźć się data wymiany, potwierdzenie unieważnienia starej wartości i wynik sprawdzenia zależnej usługi. To rekomendacja redakcji dotycząca organizacji pracy; nie oznacza, że dostawca potwierdził wykorzystanie każdego sekretu klienta. Tabela ma ograniczyć przeoczenia i pozwolić wskazać konkretny brak.

Takie rozliczenie chroni również przed niepotrzebnym powtarzaniem pracy. Jeżeli zespół zakończył rotację po odcięciu dostępu sprawcy i ma potwierdzenia, sam kolejny komunikat o przywróceniu platformy nie uzasadnia automatycznej ponownej wymiany. Nowa informacja o narażeniu mogłaby zmienić tę ocenę, ale nie wolno jej dopowiadać. Na 26 października odpowiedź powinna opisywać wykonane działania i nierozstrzygnięte punkty, zamiast obiecywać pewność wykraczającą poza raport Railway.

Zielony status platformy zamyka awarię dostawcy; klient zamyka swoją część na podstawie dowodów wykonanej pracy.

Koszt reakcji obejmuje także czas administratorów i sprawdzanie integracji po zmianach. Naszym zdaniem bardziej użyteczne od ogólnego polecenia wymiany wszystkiego ponownie jest przypisanie jednej osoby do każdego nierozliczonego wpisu. Dzięki temu właściciel produktu widzi, co ogranicza zakończenie prac, a wykonawca nie musi odgadywać, czy zadanie przejął inny zespół.

Polski klient powinien rozdzielić role własne i wykonawcy

Dla polskiej firmy korzystającej z Railway przez zewnętrzny zespół proponujemy jeden punkt kontaktu odpowiedzialny za zebranie potwierdzeń. Umowa na utrzymanie aplikacji nie odpowiada sama na pytanie, kto może unieważnić dane uwierzytelniające w każdej usłudze. To trzeba ustalić na podstawie rzeczywistych uprawnień, bez zakładania, że wykonawca kontroluje wszystkie konta klienta.

W naszej rekomendacji rozmowa z wykonawcą 26 października powinna dotyczyć dat i wyników. Zdanie „Railway już działa” wymaga uzupełnienia o listę sprawdzonych zależności. Zdanie „wymieniliśmy sekrety” wymaga wskazania, które stare wartości unieważniono. Jeżeli firma nie ma pełnego spisu, można zacząć od jednej aplikacji i zapisać brakujące dane jako zadania. Taki początek jest uczciwszy niż deklaracja zakończenia reakcji bez dowodów.

Co z tym zrobić w poniedziałek

  1. W 20 minut sprawdź jeden wykaz sekretów Railway. Przy danych zapisanych przed 21 października oznacz wykonaną rotację albo brak potwierdzenia i przypisz właściciela. Nie zapisuj samych wartości sekretów w zestawieniu.
  2. W 30 minut rozlicz jedną zakończoną rotację. Potwierdź unieważnienie starego sekretu w usłudze docelowej i działanie aplikacji z nowym. Zapisz datę oraz wynik, bez automatycznego powtarzania wymiany.
  3. W 20 minut otwórz przegląd audytu. Wyznacz osobę do sprawdzenia GitHub i rejestru kontenerów zgodnie z zaleceniem Railway. Zanotuj dostępność logów i zakres dalszego przeglądu; nie deklaruj pełnego dochodzenia w pół godziny.

Railway może przywrócić platformę, ale właściciel aplikacji musi rozliczyć jej zależności. Zakończenie reakcji powinno oznaczać brak nierozpoznanych obowiązków, nie brak nowych maili. Dobrze udokumentowana rotacja pozwala też przestać powtarzać czynności, które już wykonano.

Źródła

Redakcja cyberinsight.pl.