To piąty artykuł z naszego cyklu o bezpieczeństwie tożsamości nieludzkich (Non-Human Identities, NHI). W poprzednich częściach omówiliśmy m.in. czym są konta maszynowe i dlaczego stanowią niewidzialne zagrożenie, wskazaliśmy 10 najczęstszych błędów w zarządzaniu NHI, przeanalizowaliśmy specyfikę NHI w chmurze oraz przedstawiliśmy plan działania dla CISO na dobry początek porządkowania tych tożsamości.

Autor: 6 min czytania

Teraz skupiamy się na „sekretach” NHI – czyli hasłach, kluczach API, tokenach dostępowych i certyfikatach używanych przez konta maszyn. To one stanowią prawdziwe klucze do królestwa w infrastrukturze IT. Niewłaściwe zarządzanie nimi bywa źródłem poważnych incydentów – według analiz w 31% przypadków incydentów związanych z NHI przyczyną był wyciek lub zaniedbanie sekretów. Co więcej, aż 37% organizacji przyznaje, że sekrety maszynowe są u nich przechowywane w zmiennych środowiskowych lub wprost zahardkodowane w kodzie aplikacji– to tykająca bomba zegarowa. W niniejszym artykule pokażemy, jakie zagrożenia się z tym wiążą oraz jak skutecznie chronić credentials NHI w praktyce. Ponieważ temat jest rozbudowany, postanowiliśmy artykuł podzielić na dwie części i dziś zapraszamy do lektury pierwszej z nich.

Jakie są główne zagrożenia przy niewłaściwym zarządzaniu sekretami NHI?

  • Sekrety w kodzie i konfiguracjach

Umieszczanie haseł, tokenów czy kluczy API bezpośrednio w kodzie źródłowym, skryptach czy plikach konfiguracyjnych to jeden z najpoważniejszych błędów. Takie wyciekające sekrety (Secret Leakage) mogą łatwo zostać odkryte przez osoby niepowołane – czy to przez przegląd kodu lub logów, czy nawet atak malware na stacje deweloperów. Gdy klucz lub hasło trafi w ręce atakującego, ten może się podszyć pod legalną aplikację i uzyskać nieautoryzowany dostęp do systemów lub danych (np. do API lub bazy danych). W efekcie prowadzi to do poważnych naruszeń bezpieczeństwa i trudnych do wykrycia włamań.

  • Brak rotacji i długoterminowe klucze

Statyczne, długo niezmieniane poświadczenia stanowią ogromne ryzyko. Hasła kont usługowych często ustawiane są raz na wiele lat (albo w ogóle nierotowane), a tokeny API bywają ważne bezterminowo. Jeśli atakujący pozyska taki długotrwały sekret, może utrzymywać trwały dostęp (persistent access) do środowiska ofiary bez wzbudzania alarmów przez długi czas – konta maszynowe rzadko wymuszają przecież zmianę hasła czy stosują MFA. W praktyce oznacza to, że włamywacz może miesiącami poruszać się po naszej infrastrukturze, pozostając niewykrytym. Liczne głośne incydenty pokazały, że brak regularnej zmiany kluczy/certyfikatów maszynowych umożliwia atakującym utrzymanie dostępu nawet przez wiele miesięcy – dopóki ktoś przypadkiem nie odkryje anomalii.

  • Dostęp bez audytu i rozliczalności

Częsty problem to współdzielenie kont maszynowych między ludźmi lub wykorzystywanie tych kont przez administratorów do szybkiego obejścia restrykcji. Na przykład kiedy deweloper używa danych logowania konta serwisowego, by ręcznie wykonać jakieś zadanie, w logach widnieje tylko aktywność tego konta technicznego – brak jest informacji kto konkretnie za tym stał. Taki brak szczegółowego audytu i rozliczalności powoduje, że naruszenia czy błędy są trudne do przypisania do osoby. Dla atakującego to sytuacja idealna: może użyć przejętych poświadczeń maszyny, a wszystkie jego działania będą wyglądały jak legalna aktywność systemu. Bez odpowiedniego monitoringu organizacja może długo nie zauważyć, że ktoś niewłaściwy korzysta z uprawnień maszyny.

  • Słabe hasła i domyślne klucze

Niestety poświadczenia kont nieludzkich często nie spełniają standardów silnego hasła. Zdarzają się proste, niezgodne z polityką hasła nadawane na potrzeby integracji systemów, „by tylko działało”. Bywa też, że pozostają domyślne dane logowania (default credentials) dostarczone przez producenta aplikacji czy urządzenia. Takie sekrety są podatne na zgadywanie lub ataki słownikowe i stanowią łatwy wektor ataku – co gorsza, rzadko ktoś je zmienia, więc atakujący mają dużo czasu na złamanie słabego hasła.

  • Nadmierne uprawnienia i ponowne użycie (reuse) sekretów 

Przekombinowane, zbyt szerokie uprawnienia przypisane do kont maszynowych oraz używanie jednego konta/klucza do wielu aplikacji to kolejny błąd. Jeśli jeden token API daje dostęp do całej zawartości naszej chmury, jego przejęcie oznacza katastrofę. Tymczasem analiza incydentów pokazuje, że większość wyciekłych tokenów ma uprawnienia zapisu lub admina – np. aż 96% tokenów GitHub znalezionych w repozytoriach miało uprawnienia zapisu, a 95% dawało dostęp do całego repozytorium danej organizacji. To efekt niestosowania zasady najmniejszych uprawnień. Podobnie współdzielenie jednego sekretu między różne usługi łamie zasadę izolacji – wyciek w jednym miejscu od razu zagraża innym systemom. Nadawanie nadmiernych praw oraz ponowne używanie sekretów bardzo utrudnia też bezpieczną rotację – bo zmiana takiego hasła wymaga skoordynowania wielu zależnych usług na raz.

Dlaczego te błędy są tak groźne? Maszynowe tajemnice często uchodzą uwadze klasycznych mechanizmów bezpieczeństwa. W efekcie stanowią ulubiony cel atakujących – według ekspertów praktycznie wszystkie największe incydenty ostatnich lat miały wspólny mianownik: napastnicy odnaleźli i wykorzystali uprzywilejowane poświadczenia NHI, by dostać się głębiej do systemów. To pokazuje, że ochrona sekretów nieludzkich to dziś obowiązkowy punkt obrony.

Na koniec pierwszej części przypomnijmy: bezpieczeństwo tożsamości nieludzkich (w tym ich sekretów) to proces. Wymaga on świadomego podejścia i ciągłego doskonalenia. Zagrożenia ewoluują – ale trzymając się pewnych zasad, o których napiszemy w drugiej części opracowania, znacząco utrudnimy życie zarówno przypadkowym gapowiczom, jak i zdeterminowanym włamywaczom. Sekrety naszych maszyn pozostaną… tajne, tak jak być powinno. Bezpiecznej pracy!