Zabezpieczenie końcówek REST przed wyciekiem danych

0

Cześć,
Temat dość nietuzinkowy. Chciałbym poznać Wasze sposoby na radzenie sobie z problemem bezpieczeństwa danych. Aplikacja typu Client Side. Komunikacja z back-endem po restach. I teraz spójrzcie, mamy pole gdzie podajemy pesel klienta i po tym peselu przekazywanym jako input do resta, pobieramy dane personalne klienta. Oczywiście aby było wszystko jasne. Aplikacja działa w sieci wewnętrznej i nie jest absolutnie nigdzie udostępniana. Osoby które z niej korzystają mają rzecz jasna dostęp do tych danych i mogą je oglądać. Problem jest nieco głębszy. Autoryzacja odbywa się za pomocą tokena JWT. Załóżmy że mamy jakiegoś nie do końca uczciwego pracownika który kopiuje sobie token bezpieczeństwa i powiedzmy za pomocą postmana naparza w tą końcówkę peselami z generatora pobierając (oczywiście przy założeniu że trafi w pesel) dane klienta, budując sobie w ten sposób jakąś tam bazę którą może później sprzedać. Pytanie zadałem nie dla tego że nie mam pomysłu jak problem rozwiązać lecz bardziej chodzi mi o to, że może ktoś z Was podsunie jeszcze jakiś inny pomysł. To co mi przyszło do głowy i z czym się spotkałem, to był głównie monitoring. Monitorowanie ilości zapytań, jakiś system anty-fraud między serwerem http a back-endem w celu wyłapywania takich masowych zapytań. Timeouty na usługach tzn. dany user może strzelić w konkretną końcówką określoną ilość razy w jednostce czasowej. Generalnie wszystkie rozwiązania z jakimi się spotykałem to rozwiązania bardziej monitorujące ruch i wyłapywanie takich żądań. Pytanie czy są jakieś inne sposoby na radzenie sobie z takimi problemami.

2
  1. Przecież ten JWT wiadomo do kogo należy.
  2. Co za problem robić statystyki requestów? Wiesz który user, wiesz kiedy, wiesz kogo sprawdzał. Nie bardzo rozumiem gdze masz problem.
0

Oczywiście że tak. i takie coś jest robione. Każdy request jest logowany i logi trzymane są przez miesiąc czasu natomiast chodzi mi bardziej o jakieś programistyczne zabezpieczenie przed takimi rzeczami bo łapanie tego poprzez monitoring już mam i jest to robione :)

2

Możesz go odcinać. Jak np koleś z jednym tokenem odpytuje kilka razy na sekundę, to samo api, jeszcze z błędnym PESELem to go blokujesz na jakiś czas. Nie jesteś sie wstanie przed tym zabezpieczyć na 100 %.

5

Znaczy, chcesz się zabezpieczyć przed tym, że uprawniony ziomek zobaczy dane, do których jest uprawniony? ;-)

IMO powinieneś mieć wypracowane odpowiednie podejście biznesowe. Zastanówmy się, dlaczego ktoś miałby odpytywać po dowolnym PESEL?

Dostęp do określonych danych/osoby (via PESEL) nie wynika z zachcianki, tylko ma jakąś motywację biznesową. Jaka to motywacja/przyczyna/sprawa (kontekst)? Dodając taki kontekst do API, mógłbyś odpytać po PESELU tylko w konkretnym przypadku, a nie za każdym razem i dla każdego PESEL. Np. dostęp do konkretnych danych potrzebny jest do obsługi wniosku X. Jeśli wniosek X został przetworzony (proces "obsługa wniosku" zmienił status z "nowy" do "zakończony"), to odpytywanie o taki PESEL mogłoby zwyczajnie przestać działać .

Oczywiście można marudzić na takie podejście, że przecież to skomplikuje interfejs itd. No chyba, że interfejs "by design" ma udostępniać wszystkie dane ;-)

2

Może wystarczy skrócić czas ważności tokenu? No chyba że macie wieczne tokeny to faktycznie torchę przypał ;]

1

Można to ograć rolami czyli np. tylko dla pracownika A dane klienta o peselu X zostaną zwrócone, użytkownik B dostanie 403.

1 użytkowników online, w tym zalogowanych: 0, gości: 1, botów: 0