Uważaj na podszywanie się pod użytkownika w aplikacjach z niskim kodem/bez kodu

W zeszłym miesiącu napisałem artykuł o sposobie, w jaki platformy z niskim kodem/bez kodu oferują udostępnianie poświadczeń jako usługę, dlaczego to robią i jak to wygląda perspektywa napastnika. W tym artykule skupię się na implikacjach tego kompromisu i jego wpływie na dzisiejsze przedsiębiorstwa.

Oto dlaczego udostępnianie poświadczeń przedsiębiorstwa komuś innemu jest złą praktyką. Załóżmy, że chcę przekazać moje poświadczenia koledze, aby wykonać zapytanie do dzienników produkcyjnych w celu przeprowadzenia jednorazowej analizy zachowania użytkownika. W typowym przedsiębiorstwie przyznanie komuś uprawnień do przeszukiwania nowego źródła danych może oznaczać długi proces sprawdzania dostępu, zwłaszcza w przypadku danych produkcyjnych lub wrażliwych. Mój kolega łatwo się denerwuje. „Chciałem tylko zrobić to małe jednorazowe zapytanie, a czekam już od miesiąca!” mogliby powiedzieć. Mógłbym po prostu uruchomić dla nich zapytanie, ale jestem zasypany własnymi codziennymi zadaniami, a jednorazowe zapytania stają się skomplikowane.

Pozostało mi jedno szybkie rozwiązanie: mógłbym po prostu udostępnić swoją nazwę użytkownika/hasło koledze. Jeśli dostaną wyzwanie MSZ, chętnie je zaakceptuję. Nie muszę tracić czasu na uruchamianie zapytania, a mój kolega zostaje odblokowany. Wszyscy wygrywają! Prawidłowy?

Cóż, miałbyś rację w swojej analizie, ale brakuje Ci szerszego obrazu. Chociaż dla przedsiębiorstwa ważne jest, aby Twój kolega wykonał analizę zachowania użytkowników, równie ważne jest, jeśli nie ważniejsze, aby Twoje przedsiębiorstwo zachowało zgodność z całym szeregiem standardów prywatności i bezpieczeństwa oraz utrzymywało zaufanie klientów, podtrzymując zaangażowanie firmy w bezpieczeństwo .

Jeśli cele przedsiębiorstwa na wysokim poziomie Cię nie przekonują, rozważ centralne zespoły zarządzające IT lub bezpieczeństwa. Zespoły te opierają swoje działania i strategie bezpieczeństwa na fakcie, że każdy użytkownik ma swoją unikalną tożsamość. Zespoły IT konfigurują zasady dotyczące sieci i dostępu, które zakładają, że każdy użytkownik będzie jednocześnie zalogowany z jednego korporacyjnego adresu IP lub korporacyjnego laptopa; zespoły bezpieczeństwa korelują zdarzenia na podstawie identyfikatora użytkownika; Zespoły finansowe mogą agregować raporty kosztów na użytkownika i jego osobiste środowisko chmury. Udostępnianie danych uwierzytelniających podważa między innymi wszystkie te założenia. Usuwa podstawowe znaczenie tożsamości online.

Przykład z prawdziwego świata

Przejdźmy do świata low-code/no-code i przyjrzyjmy się rzeczywistemu scenariuszowi. W dużym przedsiębiorstwie Jane, zainspirowana pracownikiem zespołu obsługi klienta, zdała sobie sprawę, że gdy pracownicy z całej organizacji biorą udział w sprawie klienta, zwykle brakuje im kluczowych informacji o kliencie, takich jak historia zgłoszenia pomocy technicznej i ostatnie zakupy. Pogarsza to doświadczenie klienta, ponieważ musi on ciągle wyjaśniać swój problem, podczas gdy sprawa jest kierowana do właściwego pracownika, który może go rozwiązać.

Aby to poprawić, Jane stworzyła aplikację, która umożliwia pracownikom firmy przeglądanie tych kluczowych informacji o klientach, gdy ci pracownicy są częścią zespołu odpowiedzialnego za rozwiązywanie sprawy klienta. Najpierw poświęćmy chwilę, aby docenić siłę low-code/no-code, która pozwala Jane zidentyfikować potrzebę i samodzielnie ją rozwiązać, bez pytania o budżet czy czekania na alokację zasobów IT.

Podczas tworzenia aplikacji Jane musiała obejść wiele problemów, z których największym były uprawnienia. Pracownicy w całej organizacji nie mają bezpośredniego dostępu do przeszukiwania bazy danych klientów w celu uzyskania potrzebnych im informacji. Gdyby tak było, Jane nie musiałaby budować tej aplikacji. Aby rozwiązać ten problem, Jane zalogowała się do bazy danych i osadziła swoją uwierzytelnioną sesję bezpośrednio w aplikacji. Gdy aplikacja otrzyma żądanie od jednego użytkownika, użyje tożsamości Jane do wykonania tego zapytania, a następnie zwróci wyniki użytkownikowi. Ta funkcja osadzania poświadczeń, jak badaliśmy w zeszłym miesiącu, jest kluczową cechą platform z niskim kodem/bez kodu. Jane zadbała o skonfigurowanie w aplikacji kontroli dostępu opartej na rolach (RBAC) w taki sposób, aby każdy użytkownik miał dostęp tylko do spraw klientów, do których jest przypisany.

Aplikacja rozwiązała ważny problem biznesowy, dzięki czemu szybko zyskała popularność wśród użytkowników w całym przedsiębiorstwie. Ludzie byli zadowoleni, że mogą zapewnić lepszą obsługę swoim klientom, mając odpowiedni kontekst do rozmowy. Klienci też byli zadowoleni. Miesiąc po tym, jak Jane stworzyła aplikację, była już używana przez setki użytkowników w całej organizacji, a poziom zadowolenia klientów rośnie.

Tymczasem w SOC wyzwolono alert o wysokim stopniu ważności, pokazujący nienormalną aktywność wokół produkcyjnej bazy danych klientów, który został przydzielony do Amy, doświadczonej analityk bezpieczeństwa. Wstępne dochodzenie Amy wykazało, że wewnętrzny użytkownik próbował przeszukać całą bazę danych, pytając o informacje o wielu klientach z wielu adresów IP w całej organizacji. Wzorzec zapytania był bardzo złożony; zamiast prostego wzorca wyliczania, którego można się spodziewać, gdy baza danych jest przeszukiwana, dane tego samego klienta były odpytywane wiele razy, czasami przez różne adresy IP i w różnych datach. Czy może to być osoba atakująca próbująca zmylić systemy monitorowania bezpieczeństwa?

Po szybkim dochodzeniu Amy odkryła kluczową informację: wszystkie te zapytania dotyczące wszystkich adresów IP i dat wykorzystywały tożsamość jednego użytkownika, kogoś o imieniu Jane z zespołu obsługi klienta.

Amy skontaktowała się z Jane, by zapytać ją, co się dzieje. Z początku Jane nie wiedziała. Czy jej poświadczenia zostały skradzione? Czy kliknęła niewłaściwy link lub zaufała niewłaściwej przychodzącej wiadomości e-mail? Ale kiedy Jane powiedziała Amy o aplikacji, którą niedawno zbudowała, oboje zdali sobie sprawę, że może istnieć połączenie. Amy, analityk SOC, nie była zaznajomiona z low-code/no-code, więc skontaktowali się z zespołem AppSec. Z pomocą Jane zespół odkrył, że aplikacja Jane zawiera w sobie dane uwierzytelniające Jane. Z punktu widzenia bazy danych nie było aplikacji — była tylko Jane, wykonująca całą masę zapytań.

Jane, Amy i zespół AppSec postanowili zamknąć aplikację do czasu znalezienia rozwiązania. Użytkownicy aplikacji w całej organizacji byli sfrustrowani, ponieważ zaczęli na niej polegać, a klienci też to odczuwali.

Podczas gdy Amy zamknęła sprawę i udokumentowała swoje ustalenia, wiceprezes ds. obsługi klienta nie był zadowolony ze spadku poziomu zadowolenia klientów, więc poprosili Jane o znalezienie trwałego rozwiązania. Z pomocą dokumentacji platformy i zespołu Centrum Doskonałości organizacji, Jane usunęła swoją osadzoną tożsamość z aplikacji, zmieniła aplikację tak, aby używała tożsamości każdego użytkownika do wysyłania zapytań do bazy danych i zapewniła, że ​​użytkownicy uzyskują uprawnienia tylko do spraw klientów, z którymi są powiązani. . W nowej i ulepszonej wersji aplikacja wykorzystywała tożsamość każdego użytkownika do przeszukiwania bazy danych klientów. Jane i użytkownicy aplikacji byli zadowoleni, że aplikacja jest znowu online, Amy i zespół AppSec byli zadowoleni, że tożsamość Jane nie jest już udostępniana, a przedsiębiorstwo zauważyło, że poziom zadowolenia klientów ponownie zaczął rosnąć. Wszystko było dobrze.

Dwa tygodnie później SOC otrzymał kolejny alert o nieprawidłowym dostępie do produkcyjnej bazy danych klientów. Wyglądał podejrzanie podobnie do poprzedniego alertu w tej samej bazie danych. Ponownie adresy IP z całej organizacji używały tożsamości pojedynczego użytkownika do wysyłania zapytań do bazy danych. Ponownie, tym użytkownikiem była Jane. Ale tym razem zespół ds. bezpieczeństwa i Jane wiedzieli, że aplikacja używa tożsamości użytkowników. Co się dzieje?

Dochodzenie wykazało, że oryginalna aplikacja miała niejawnie udostępnione Uwierzytelniona sesja bazy danych Jane z użytkownikami aplikacji. Udostępniając aplikację użytkownikowi, ten użytkownik uzyskał bezpośredni dostęp do połączenie, otoczka wokół uwierzytelnionej sesji bazy danych udostępniana przez platformę low-code/no-code. Korzystając z tego połączenia, użytkownicy mogli bezpośrednio wykorzystać uwierzytelnioną sesję — nie musieli już przechodzić przez aplikację. Okazuje się, że kilku użytkowników dowiedziało się o tym i myśląc, że było to zamierzone zachowanie, używało sesji uwierzytelnionej bazy danych Jane do uruchamiania swoich zapytań. Pokochali to rozwiązanie, ponieważ bezpośrednie korzystanie z połączenia dało im pełny dostęp do bazy danych, nie tylko do spraw klientów, do których są przypisani.

Połączenie zostało usunięte, a incydent się skończył. Analityk SOC skontaktował się z użytkownikami, którzy korzystali z połączenia Jane, aby upewnić się, że odrzucili wszystkie zapisane przez siebie dane klientów.

Rozwiązanie problemu bezpieczeństwa niskiego kodu/braku kodu

Powyższa historia to prawdziwy scenariusz międzynarodowej firmy B2C. Niektóre szczegóły zostały pominięte lub dostosowane w celu ochrony prywatności. Widzieliśmy, jak pracownik mający dobre intencje może nieświadomie udostępniać swoją tożsamość innym użytkownikom, powodując szereg problemów w obszarze IT, bezpieczeństwa i firmy. Jak zbadaliśmy w zeszłym miesiącu, udostępnianie poświadczeń jest kluczową cechą low-code/no-code. To norma, nie wyjątek.

As low-code/no-code nadal kwitnie w przedsiębiorstwie, świadomie lub nie, kluczowe jest, aby zespoły ds. bezpieczeństwa i IT dołączyły do ​​rozmowy na temat rozwoju biznesu. Aplikacje z niskim kodem/bez kodu są dostarczane z unikalny zestaw wyzwań związanych z bezpieczeństwem, a ich płodny charakter oznacza, że ​​wyzwania te stają się dotkliwe szybciej niż kiedykolwiek wcześniej.