Wyciek danych dostępowych: checklist zamknięcia zgłoszenia

Zgłoszenie wycieku danych dostępowych można zamknąć, gdy potrafisz wyjaśnić, co zatrzymało ekspozycję, co unieważniło stary sekret, co zapobiega powtórce i jak sprawdzono, czy doszło do nadużyć. Dowody i pozostałą pracę zapisz osobno. Ograniczenie dostępu do strony pobierania czy udany deploy odpowiadają tylko na część tych pytań.

Nie potrzebujesz do tego wielkiego działu reagowania na incydenty. Potrzebujesz osoby odpowiedzialnej za zgłoszenie, która odróżnia wykonaną czynność od potwierdzonego wyniku. Potrzebujesz też notatki o zamknięciu, którą kolejna osoba zrozumie bez odtwarzania przebiegu pięciu rozmów.

Czego przypadek Baseten uczy o zamykaniu zgłoszeń?

Usunięcie publicznego dostępu i unieważnienie danych dostępowych to osobne działania. Niedawna dyskusja na Hacker News przypomniała konkretny przykład, choć sam incydent wydarzył się wcześniej.

W artykule z 1 września Strix opisał znalezienie w lipcu działającego tokenu GitHub w obrazie kontenera Baseten. Według podanej chronologii zgłoszenie dotarło 13 lipca. Następnego ranka Baseten ograniczył dostęp do projektu w rejestrze, ale Strix poinformował, że token nadal działał. Po południu zespół bezpieczeństwa Baseten potwierdził rotację.

Autorzy chwalą reakcję zespołu i podają, że pozostałe zgłoszone problemy zamknięto 17 lipca. Nie opisują jednak niezależnego testu tokenu po rotacji. Przeczytaj relację Strix. Dyskusja na HN ponownie zwróciła uwagę na ten artykuł. Wyciągamy tu wnioski z opisanego publicznie incydentu lipcowego, nie informujemy o nowym włamaniu.

Przy koordynowaniu pracy warto zadać proste pytanie: co dokładnie znaczy „naprawione” w twoim zgłoszeniu? Osoba odpowiedzialna za infrastrukturę może mieć na myśli zablokowanie pobierania. Administrator tożsamości może mówić o unieważnieniu tokenu. Tymczasem osoba prowadząca incydent może nadal sprawdzać, co wydarzyło się przed obiema zmianami.

Przypisz odpowiedzialność za każdą odpowiedź

Przy zgłoszeniu wycieku danych dostępowych sprawdź osobno cztery kwestie. To proponowany sposób organizacji pracy, nie formalna norma ani zapewnienie, że każdy incydent przebiega tak samo.

Ograniczanie skutków i dochodzenie mogą trwać równolegle. Nie odkładaj pilnego działania do czasu dopracowania podsumowania. Tabela pomaga zapisywać postępy na bieżąco; nie ma tworzyć kolejki, w której jedna osoba czeka na drugą.

W małym startupie jedna osoba może łączyć kilka ról. Mimo to przy każdej odpowiedzi zapisz jej nazwisko. Ułatwi to przekazanie sprawy, jeśli incydent przeciągnie się na kolejną zmianę, urlop czy ostatni dzień współpracy z kontraktorem.

Ustalcie też, kto podejmuje ostateczną decyzję o zamknięciu. Osoba odpowiedzialna za zgłoszenie zbiera odpowiedzi. Nie powinna bez wyjaśnienia zastępować własną oceną potwierdzenia od administratora, który jeszcze nie zweryfikował zmiany.

Usuń ekspozycję, ale nie myl porządków z unieważnieniem

Usunięcie ekspozycji opisuj w konkretnym zakresie: określony plik, obraz, log lub endpoint przestał być dostępny dla osób, które wcześniej mogły z niego skorzystać. Zapisz, którą drogę dostępu sprawdzono i jaki artefakt był tą drogą dostępny.

Przy obrazie kontenera obok czytelnego tagu podaj stabilny identyfikator artefaktu. Przy opublikowanym logu wskaż uruchomienie procesu i drogę dostępu. Taki sposób dokumentowania polecamy, ponieważ zdanie „rejestr jest prywatny” mówi kolejnej osobie mniej niż identyfikator artefaktu i opis sprawdzenia dostępu.

GitHub w poradniku o danych wrażliwych stawia unieważnienie lub rotację sekretu przed czyszczeniem historii repozytorium. Wyjaśnia też, że przepisanie historii ma swoje koszty i może nie być konieczne po usunięciu ryzyka dostępu. Poradnik dotyczy repozytoriów Git. Rozróżnienie między unieważnieniem danych dostępowych a usunięciem ich kopii pomaga jednak również oceniać inne artefakty. Poradnik GitHub o usuwaniu danych wrażliwych.

Nie uzależniaj zamknięcia od niemożliwego do spełnienia warunku: udowodnienia, że zniknęła każda kopia w internecie. Zapisz decyzję dotyczącą usuwania kopii. Czy pozostawiona kopia nadal ujawnia kod źródłowy, dane klientów lub inny sekret? Jeśli tak, unieważnienie tych danych dostępowych nie rozwiązuje pozostałych problemów.

Usuwając niepotrzebne kopie, zachowaj dowody wymagane do dochodzenia w miejscu z ograniczonym dostępem. Publiczne zgłoszenie, rozmowa z badaczem i wewnętrzna dokumentacja incydentu nie muszą zawierać tego samego. Odwołuj się do sekretu przez wewnętrzny identyfikator, zamiast wklejać jego pełną wartość do każdej wiadomości.

Sprawdzaj tylko to, na co masz zgodę. Zgłoszenie dotyczące twojej usługi nie daje automatycznie prawa do testowania systemów dostawcy. Nasz poradnik o zakresie skanowania bezpieczeństwa pokazuje, jak wyznaczyć tę granicę przed rozpoczęciem testów.

Potwierdź, że stare dane dostępowe są nieważne

Przed zamknięciem zapytaj wprost o dane dostępowe, które wyciekły. „Utworzyliśmy nowy token” i „stary token nie pozwala się już uwierzytelnić” to dwa różne stwierdzenia.

Dokumentacja GitHub wyjaśnia, że unieważnione lub wygasłe tokeny nie mogą już uwierzytelniać żądań Git ani API. Wspomina też, że w logu bezpieczeństwa może pojawić się zdarzenie usunięcia autoryzacji. Zapis po stronie dostawcy jest więc przydatnym dowodem. Dokumentacja nie zapewnia jednak, że w każdej sytuacji zobaczysz takie samo zdarzenie. Wygasanie i unieważnianie tokenów GitHub.

Poproś administratora o zapisanie dostawcy, identyfikatora danych dostępowych, czasu unieważnienia i metody potwierdzenia. Tam, gdzie ma to uzasadnienie, uprawniona osoba może przeprowadzić ograniczony test zgodnie z zatwierdzoną procedurą. Rozróżnij potwierdzenie dostawcy, zaobserwowany wynik uwierzytelnienia i przypuszczenie kolegi z zespołu.

Nie wymagaj, by ponowny test przeprowadziła osoba z zewnątrz. Badacz może być niedostępny albo nie mieć pozwolenia na kolejne żądania. To nadal twój zespół odpowiada za zdobycie wystarczających dowodów za pośrednictwem własnych administratorów i systemów.

Poradnik OWASP o zarządzaniu sekretami traktuje unieważnienie, wymianę i usunięcie jako osobne działania podczas obsługi incydentu. Zaleca szybkie ograniczenie skutków i możliwość ustalenia, czy sekret został unieważniony. Poradnik OWASP o zarządzaniu sekretami.

Uwzględnij ten podział w planie zmiany. Przywrócenie zależnej usługi jest zadaniem operacyjnym, a zneutralizowanie ujawnionych danych dostępowych to wynik istotny dla bezpieczeństwa. Jeśli przez okres przejściowy działają oba sekrety, opisz to wprost. Wskaż osobę odpowiedzialną i ustal warunek zakończenia tego okresu. Udany test stanu aplikacji nie zastępuje potwierdzenia, że poprzedni sekret unieważniono.

Zmień proces, który doprowadził do wycieku

Nowe dane dostępowe muszą trafiać do aplikacji lub procesu budowania w bezpieczniejszy sposób. Inaczej kolejne udane wydanie może odtworzyć ten sam problem z nowym sekretem.

Docker ostrzega przed przekazywaniem sekretów do procesu budowania przez argumenty Dockerfile lub zmienne środowiskowe, ponieważ mogą pozostać w końcowym obrazie. Zalecane montowanie sekretów udostępnia dane dostępowe danej instrukcji budowania tylko tymczasowo. Poradnik Docker o sekretach podczas budowania.

Reguła sprawdzająca SecretsUsedInArgOrEnv zwraca też uwagę na utrwalanie sekretów w metadanych obrazu. Warto więc obejrzeć wynikowy artefakt, a nie ograniczać się do zmienionej linii kodu. Dokumentacja reguły Docker.

W notatce potwierdzającej przyjęcie poprawki proponujemy opisać dwie rzeczy: co zmieniło się w obsłudze sekretów i co sprawdzono w nowym artefakcie. Review kodu pozwala ocenić, czy zmiana wygląda poprawnie. Sprawdzenie świeżo wygenerowanego artefaktu odpowiada na pytanie, czy nadal występuje w nim problem, który miał zostać usunięty.

Dostosuj test do wycieku. Jeżeli build zapisywał adresy URL z danymi uwierzytelniającymi w konfiguracji, sprawdź ten plik. Jeśli zadanie publikujące ujawniało swoje zmienne środowiskowe, sprawdź powstały log oraz to, kto ma do niego dostęp. Sam zapis „skaner niczego nie wykrył” nie wystarczy bez zakresu skanowania i identyfikatora badanego artefaktu.

Przemyśl też, jakiego dostępu potrzebuje nowy sekret. GitHub zaleca GitHub Apps do działania w imieniu organizacji i do długotrwałych integracji. Jeśli nadal korzystasz z osobistego tokenu dostępu, świadomie dobierz uprawnienia i okres ważności. Sama zmiana rodzaju danych dostępowych nie dowodzi, że zakres uprawnień jest odpowiedni. Poradnik GitHub o osobistych tokenach dostępu.

Po naprawieniu bezpośredniej przyczyny mogą zostać szersze prace nad bezpieczeństwem. Oddziel je od ustaleń, na podstawie których zamykasz zgłoszenie. „Naprawiono build, którego dotyczyło zgłoszenie; Maya ma do piątku przejrzeć pozostałe pipeline’y budowania” to konkretna decyzja. Te prace nie uzasadniają stwierdzenia „cała obsługa sekretów jest już bezpieczna”.

Zbadaj skutki i wskaż granice ustaleń

Unieważnienie danych dostępowych rozstrzyga, czy nadal można się nimi posłużyć. Nie mówi, co wydarzyło się, gdy były ważne.

Poradnik GitHub o badaniu incydentów zaleca sprawdzenie w logu audytowym aktywności powiązanej z przejętym tokenem, udziału nieoczekiwanych podmiotów oraz istotnych ustaleń dotyczących ekspozycji. Ostrzega również, że w trakcie incydentu wektor ataku może się zmienić. Znalezienie ujawnionych danych dostępowych bywa więc początkiem dalszego dochodzenia. Obszary dochodzenia według GitHub.

W dokumentacji zamknięcia warto krótko opisać zakres sprawdzeń: systemy, okres objęty dostępnymi danymi, osobę, która je przejrzała, i wynik. Dodaj też, czego nie udało się ustalić.

Czytelnik nie powinien zgadywać, czy „nic podejrzanego” oznacza tydzień kompletnych zapisów, czy kilka godzin częściowych logów. W dostępnych zapisach możesz nie znaleźć nieoczekiwanej aktywności, a jednocześnie nie mieć danych z całego okresu ekspozycji. Napisz obie rzeczy, oddzielając obserwację od wniosku. Uczciwie określona granica pozwala osobie prowadzącej incydent zdecydować, czy potrzebne są dalsze prace.

Wybierając miejsca do sprawdzenia, uwzględnij uprawnienia ujawnionych danych dostępowych. Dostęp do konfiguracji wdrożeń rodzi inne pytania niż dostęp tylko do odczytu jednego pakietu. Zapisz uzasadnienie zakresu dochodzenia, żeby kolejna osoba mogła je zakwestionować bez powtarzania całej pracy.

Jeśli dochodzenie ujawni nowy problem, przypisz mu osobę odpowiedzialną i osobny identyfikator. Zamknięcie pierwotnego zgłoszenia nie może wymazać incydentu, który pozostaje otwarty gdzie indziej. Z drugiej strony nie trzymaj bezterminowo otwartego zgłoszenia badacza, jeśli jego konkretny problem został rozwiązany. Wyjaśnij, na jaką odrębną decyzję jeszcze czekasz.

Napisz notatkę o zamknięciu, którą ktoś inny może sprawdzić

Dobra notatka opisuje wynik, wskazuje dowody i wymienia niedokończone zadania. Powinna być na tyle krótka, by dało się ją przeczytać przy przekazywaniu sprawy, i na tyle konkretna, by można było zakwestionować jej ustalenia.

To rozróżnienie widać także w obsłudze alertów GitHub: usunięcie tokenu z repozytorium nie zamyka automatycznie alertu skanowania sekretów. Poradnik przewiduje też komentarz przy zamknięciu, który trafia do historii alertu. Zamykanie alertów skanowania sekretów.

Poniższy fikcyjny przykład pokazuje format. Organizację, identyfikatory, godziny i ustalenia wymyślono; nie opisują Baseten ani żadnego klienta Kit.

Zgłoszenie: Dane dostępowe używane przy budowaniu ujawnione w artefakcie release-184.

Ekspozycja: Lena ograniczyła dostęp do artefaktu o 10:15 UTC. Test przeprowadzony za zgodą potwierdził, że nie można już pobrać artefaktu wskazaną w zgłoszeniu publiczną drogą dostępu. Pozostałe artefakty sprawdzono w ramach podlinkowanego zadania inwentaryzacji.

Stare dane dostępowe: Arun unieważnił dane dostępowe build-reader-previous o 10:18 UTC. Potwierdzenie dostawcy i wynik zatwierdzonej weryfikacji zapisano w folderze incydentu z ograniczonym dostępem. Zależne usługi korzystają już z nowych danych.

Zapobieganie powtórce: Lena zmieniła obsługę sekretów podczas budowania. Nowy artefakt i jego metadane sprawdzono pod kątem opisanego sposobu wycieku. Dowody wskazują nowy artefakt i czas przeglądu.

Skutki: Jo przejrzała dostępne zapisy systemu tożsamości i repozytoriów z podanego okresu ekspozycji. Nie znaleziono w nich nieoczekiwanego użycia. Wcześniejsze zapisy pobrań z rejestru były niedostępne, więc nie możemy ustalić, kto uzyskał starsze kopie.

Decyzja: Jo zatwierdziła zamknięcie tego zgłoszenia. Podlinkowane zadanie ulepszenia logowania nadal jest przypisane Arunowi. Wiadomość do badacza opisuje zakończone działania naprawcze i granice dochodzenia, bez podawania danych dostępowych.

Zwróć uwagę, czego ta notatka nie stwierdza. Nie zapewnia, że wszystkie kopie zniknęły, że badacz osobiście potwierdził każdą czynność ani że brak podejrzanych wpisów w logach dowodzi, iż nikt nie uzyskał dostępu do systemu.

Te same nagłówki mogą posłużyć za pusty szablon. Odpowiedź „nie dotyczy” przyjmuj tylko z uzasadnieniem osoby odpowiedzialnej. Jeśli zgłoszone dane dostępowe były już nieważne, zapisz, jak to ustalono i czy ujawniony artefakt zawiera coś jeszcze, co wymaga uwagi.

Jeśli zespół ma taką możliwość, przed zatwierdzeniem zamknięcia poproś drugą osobę o przeczytanie notatki. Niech wskaże jedno zdanie, którego nie potrafi powiązać z jasnymi dowodami. To nasza praktyczna sugestia, jak wychwycić niejednoznaczności przy przekazywaniu spraw, a nie obowiązkowy etap certyfikacji.

Zachowaj decyzję i rozmowę przy zgłoszeniu w Kit

Podsumowanie dowodów trzymaj przy zgłoszeniu, żeby było jasne, skąd wynika jego status. Osoba, która wróci do niego później, powinna móc ustalić, kto uznał poprawkę za zweryfikowaną i czego dotyczyła ta decyzja.

Kit zapisuje, kto i kiedy zmienił status zgłoszenia, oraz opcjonalny komentarz do zmiany. Uprawniony członek zespołu może oznaczyć poprawkę jako zweryfikowaną i dodać notatkę. Procedurę opisuje dokumentacja triażu.

Ta czynność rejestruje decyzję człowieka. Kit nie unieważnia ujawnionych danych dostępowych, nie wymaga czterech opisanych wyżej sprawdzeń ani potwierdzenia badacza przed zmianą statusu. Twój zespół musi zebrać dowody i zdecydować, co wystarczy. Podsumuj je w notatce, a po szczegóły odeślij do dokumentacji z ograniczonym dostępem.

W rozmowie przy zgłoszeniu można prowadzić dyskusje wewnętrzne i wysyłać wiadomości widoczne dla badacza. Szczegóły techniczne dochodzenia zostaw w odpowiednim kanale. Badaczowi przekaż, które działania naprawcze zakończono i czy ewentualne dalsze prośby mieszczą się w dozwolonym zakresie. Poradnik komunikacji z badaczami wyjaśnia te opcje widoczności.

Przy kolejnym wycieku zacznij od czterech nagłówków: ekspozycja, stare dane dostępowe, zapobieganie powtórce i skutki. Przypisz odpowiedzialność jeszcze w trakcie reagowania. Gdy zamkniesz zgłoszenie, notatka powinna wyjaśniać ustalenia bez zmuszania kogokolwiek do zgadywania, co znaczyło „naprawione”.