tokeny API bez ograniczeń uprawnień

Tokeny API bez ograniczeń uprawnień zwiększają skalę potencjalnych szkód po ich wycieku.

Tokeny API bez ograniczeń uprawnień – czym jest problem

Token API jest poświadczeniem używanym przez program, skrypt, usługę albo urządzenie do komunikowania się z innym systemem. Zwykle zastępuje ręczne logowanie i pozwala wykonywać określone operacje bez każdorazowego wpisywania hasła. Samo użycie tokenu nie stanowi błędu. Ryzyko pojawia się wtedy, gdy token otrzymuje szerszy zakres uprawnień, niż jest potrzebny do konkretnego zadania, albo gdy nie przewidziano ograniczeń dotyczących zasobów, operacji, czasu i miejsca użycia.

Określenie „bez ograniczeń uprawnień” opisuje sytuację, w której jeden klucz dostępu może odczytywać, zmieniać lub usuwać dużą część danych i konfiguracji. Taki token bywa wygodny podczas szybkiego uruchamiania integracji, ponieważ nie trzeba analizować wymagań aplikacji. W środowisku produkcyjnym tworzy jednak pojedynczy, szeroki punkt ryzyka. Jeżeli zostanie ujawniony w repozytorium, logach, kopii zapasowej, wiadomości lub na zainfekowanym komputerze, osoba nieuprawniona może wykorzystać zakres dostępu znacznie szerzej, niż wynikałoby to z pierwotnego zastosowania.

Skutki zależą od rodzaju systemu. Może dojść do pobrania informacji, podmiany rekordów, usunięcia zasobów, zmiany ustawień, utworzenia kolejnych kont dostępowych albo wykorzystania usługi do działań obciążających infrastrukturę. Nie musi być widoczny jeden spektakularny incydent. Częściej problem rozwija się stopniowo: najpierw następuje odczyt danych, później modyfikacja konfiguracji, a na końcu utrata kontroli nad kolejnymi elementami systemu.

Tokeny API bez ograniczeń uprawnień a zasada najmniejszych uprawnień

Najważniejszym punktem odniesienia jest zasada najmniejszych uprawnień. Zgodnie z nią aplikacja powinna otrzymać wyłącznie taki zakres dostępu, jaki jest konieczny do wykonania zaplanowanego zadania. Jeśli skrypt ma pobierać status zamówienia, nie powinien jednocześnie móc usuwać użytkowników, zmieniać ustawień konta i eksportować całej bazy. Jeżeli usługa zapisuje wyniki w jednym katalogu, nie ma powodu przyznawać jej dostępu do całego magazynu danych.

W praktyce zakres uprawnień warto analizować na kilku poziomach. Pierwszy dotyczy operacji, takich jak odczyt, zapis, usuwanie i zmiana konfiguracji. Drugi odnosi się do zasobów, czyli konkretnych projektów, tabel, folderów, kont lub funkcji. Trzeci obejmuje czas ważności tokenu, a czwarty sposób jego użycia, na przykład dozwolone adresy sieciowe, aplikacje lub środowiska. Ograniczenie tylko jednego z tych elementów może nie wystarczyć. Token z prawem odczytu wszystkich danych nadal może powodować poważne konsekwencje, nawet jeśli nie może niczego usunąć.

Warto odróżnić token szeroki od tokenu administracyjnego używanego świadomie w krótkim, kontrolowanym procesie. Dostęp podwyższony może być niezbędny podczas migracji albo jednorazowej zmiany, ale powinien być czasowy, monitorowany i przechowywany w sposób ograniczający możliwość ujawnienia. Stały token o pełnych uprawnieniach, umieszczony w pliku konfiguracyjnym aplikacji, jest znacznie trudniejszy do obrony. Dodatkowym problemem staje się brak wiedzy o tym, gdzie został skopiowany i ile osób lub procesów nadal z niego korzysta.

Tokeny API bez ograniczeń uprawnień – typowe drogi wycieku i objawy

Do ujawnienia tokenu może dojść podczas publikowania kodu w repozytorium, przesyłania konfiguracji do zewnętrznej osoby, tworzenia archiwum projektu albo wykonywania kopii zapasowej. Częstym źródłem są logi, w których aplikacja zapisuje pełny adres żądania wraz z nagłówkiem autoryzacyjnym lub parametrami. Ryzyko zwiększa także przechowywanie poświadczenia w zwykłym pliku tekstowym, arkuszu, notatce, obrazie ekranu albo historii poleceń.

Niepokój powinny wzbudzić żądania wykonywane o nietypowej porze, nagły wzrost liczby odczytów, operacje z nieznanego miejsca, zmiany konfiguracji bez zgłoszonego wdrożenia oraz pojawienie się nowych tokenów lub kont. Trzeba jednak pamiętać, że brak widocznych objawów nie oznacza braku wykorzystania. Jeżeli system nie rejestruje operacji powiązanych z konkretnym tokenem, ustalenie zakresu incydentu może być trudne.

W przypadku podejrzenia wycieku nie powinno się ograniczać do usunięcia jednej kopii klucza. Należy unieważnić token, sprawdzić, czy nie utworzono dodatkowych poświadczeń, przejrzeć historię operacji i ustalić, jakie dane mogły zostać odczytane lub zmienione. Następnie trzeba wymienić sekrety w bezpieczny sposób, poprawić konfigurację oraz rozważyć ograniczenie uprawnień. Samo wygenerowanie nowego tokenu o takim samym, szerokim zakresie nie usuwa przyczyny problemu.

Tokeny API bez ograniczeń uprawnień – praktyczne wskazówki ochrony

W pierwszej kolejności należy zinwentaryzować wszystkie tokeny: ich właścicieli, zastosowania, daty utworzenia, zakresy uprawnień i miejsca użycia. Poświadczenia, których przeznaczenia nie da się potwierdzić, powinny zostać wycofane po sprawdzeniu zależności. Dla aktywnych tokenów warto ustalić minimalny zakres, krótki okres ważności oraz procedurę odnowienia. Pomocne bywa rozdzielenie poświadczeń dla środowiska testowego i produkcyjnego, aby błąd w jednym miejscu nie otwierał dostępu do drugiego.

Tokenów nie powinno się umieszczać bezpośrednio w kodzie aplikacji ani w publicznych plikach konfiguracyjnych. Bezpieczniejszym rozwiązaniem jest przechowywanie ich w przeznaczonym do tego magazynie sekretów, z kontrolą dostępu i rejestrowaniem odczytów. W aplikacji należy także unikać wypisywania pełnych nagłówków żądań do logów. Jeśli diagnostyka wymaga identyfikatora tokenu, można rejestrować wyłącznie jego zamaskowany fragment.

Ważną warstwą ochrony jest monitoring. Rejestrowanie użycia tokenów ułatwia odróżnienie zwykłej pracy od nietypowej aktywności. Warto ustawić alerty dotyczące nagłych zmian zakresu uprawnień, masowego odczytu, operacji usuwania oraz użycia z nieznanych lokalizacji. Należy również przygotować prostą procedurę unieważnienia poświadczenia, ponieważ w czasie incydentu poszukiwanie informacji o tym, kto może wyłączyć token, wydłuża reakcję.

Jeżeli token jest wykorzystywany przez aplikację działającą na komputerze, trzeba sprawdzić także bezpieczeństwo samego urządzenia. Złośliwe oprogramowanie, nieaktualny system, rozszerzenie przeglądarki lub niechroniony profil użytkownika mogą doprowadzić do przejęcia klucza niezależnie od poprawności konfiguracji serwera. Ochrona dostępu obejmuje więc zarówno ustawienia interfejsu API, jak i stan komputera, kopii zapasowych oraz kont używanych do administracji.

Kiedy tokeny API bez ograniczeń uprawnień wymagają zgłoszenia do serwisu

Do serwisu warto zgłosić się wtedy, gdy token był zapisany na komputerze, do którego mogły mieć dostęp osoby nieuprawnione, gdy zauważono nieznane procesy, komunikaty o zmianie ustawień, nietypowe logowanie albo nagłe spowolnienie pracy aplikacji. Pomoc może być potrzebna również po utracie laptopa, infekcji, nieudanej aktualizacji, awarii dysku lub przywróceniu systemu z kopii, której pochodzenie nie jest pewne. W takich sytuacjach ważne jest zabezpieczenie dowodów: nie należy bez potrzeby kasować logów, usuwać katalogów ani wielokrotnie uruchamiać narzędzi, które mogą zmienić stan systemu.

W Warszawskim Pogotowiu Komputerowym 24/7 można skonsultować stan komputera używanego do pracy z tokenami, sprawdzić podstawowe oznaki naruszenia i uporządkować działania po podejrzeniu wycieku. Przed przekazaniem urządzenia nie należy wysyłać tokenu w treści wiadomości ani umieszczać go w publicznym zgłoszeniu. Jeżeli poświadczenie nadal jest aktywne, właściwym krokiem pozostaje jego unieważnienie po stronie właściwego systemu, a następnie utworzenie nowego tokenu z ograniczonym zakresem i kontrolowanym okresem użycia.

Najbezpieczniejsze podejście zakłada, że token jest elementem dostępu o określonym celu, a nie uniwersalnym hasłem do całej infrastruktury. Ograniczenie zakresu, kontrola czasu ważności, bezpieczne przechowywanie, monitoring oraz gotowa procedura unieważnienia zmniejszają możliwe skutki błędu lub wycieku. Dzięki temu pojedyncze ujawnienie nie musi prowadzić do utraty kontroli nad wszystkimi zasobami.