Dane osobowe 37 milionów klientów amerykańskiego T-Mobile – należące do nich adresy rozliczeniowe, adresy e-mail oraz daty urodzenia – dostały się w ręce cyberprzestępców. Stało się to w wyniku ataku na jeden z niezabezpieczonych odpowiednio interfejsów API należących do tego telekomunikacyjnego giganta. Jak to możliwe? Są to skutki zaniedbań firm w zakresie zabezpieczania i zapobiegania nieautoryzowanym dostępom do API. Dziś trzeba traktować tę kwestię priorytetowo.
Interfejsy programowania aplikacji są jak układ nerwowy, który umożliwia przesyłanie i odbieranie danych między różnymi systemami, takimi jak sieć internetowa, różne aplikacje czy urządzenia Internetu rzeczy (IoT). Dzięki API mamy możliwość korzystania z ogromnych zasobów danych i funkcji typowych dla cyfrowej gospodarki. Do niedawna niestety zabezpieczanie tego obszaru postrzegane było jako sprawa drugorzędna. Dziś ta taktyka zaczyna przynosić niebezpieczne skutki. I pomimo tego, że wspomniany incydent naruszenia API w T-Mobile mógł skończyć się dużo gorzej – finalnie nie wyciekły hasła, kody PIN i inne informacje dotyczące kont finansowych klientów, to nigdy nie powinno dojść do takiego zaniedbania.
Rutynowe API
Problem z bezpieczeństwem API, z którym boryka się wiele organizacji, polega na tym, że nie zawsze jest jasne, kto właściwie w firmie odpowiada za ten obszar. Zdarza się, że programiści rutynowo tworzą interfejsy do udostępniania danych, czasem nie mając pełnej wiedzy na temat cyberbezpieczeństwa. Popełniają więc błędy, które ułatwiają cyberprzestępcom pracę i umożliwiają kradzież danych.
– Zespoły ds. cyberbezpieczeństwa w firmach najczęściej nie mają żadnej kontroli i wiedzy nad tym, jak tworzone i wdrażane są w firmach API – mówi Mateusz Ossowski, CEE Channel Manager w firmie Barracuda Networks, która jest producentem rozwiązań z obszaru bezpieczeństwa IT. – W rezultacie stają się one niezabezpieczonymi punktami końcowymi. Wiele z nich jest na szczęście tworzonych na potrzeby wewnętrzne.
Zdarza się jednak, że do naruszenia dochodzi właśnie przez API, które omyłkowo zostało wystawione na świat, choć powinno być przeznaczone do użytku wewnętrznego. Dlatego obie wersje muszą być traktowane z jednakową uwagą przez ekspertów ds. cyberbezpieczeństwa. Wystarczy bowiem naprawdę niewiele, aby zespoły deweloperskie udostępniły wewnętrzne API użytkownikom spoza organizacji.
Zombie API
Dobrą strategią staje się zwiększenie poziomu odpowiedzialności za bezpieczeństwo API przez programistów. Jednak liczbę utworzonych do tej pory interfejsów API można mierzyć w milionach. Wiele z nich tworzy tzw. zbiór „Zombie API”, który składa się z interfejsów porzuconych przez zespoły programistów, acz nadal zapewniających dostęp do danych.
Znalezienie i zabezpieczenie wszystkich punktów końcowych API, które zostały kiedykolwiek utworzone, należy więc nadal do obowiązków zespołów ds. bezpieczeństwa cybernetycznego. Niezależnie od tego, kto w organizacji jest ostatecznie odpowiedzialny za bezpieczeństwo API, pewne jest, że nie poświęca się temu zagadnieniu wystarczająco dużo uwagi. Podobnie jak niezabezpieczonym odpowiednio aplikacjom internetowym, których jednak jest znacznie mniej niż API. Niestety wiedza na ten temat kuleje i możemy się spodziewać, że skutki zaniedbań w tym zakresie mogą się kumulować nie tylko w 2023 roku, ale i w kolejnych latach.
