Zasada zabezpieczeń mikroserwisów

Hej, postanowiłem stworzyć swój pierwszy projekt z wykorzystaniem mikroserwisów o ile zasadę działania kojarzę i mam pogląd co mniej więcej mam zrobić to kwestia zabezpieczeń mnie zastanawia a mianowicie:

1. Tworzę mikroserwisy, którę będą wykonywać jakieś swoje funkcjonalności.
2. Tworzę gateway api, które będzie wysyłać żądania http do poszczególnych mikroserwisów. (czytałem, że w tym miejscu może odbywać się autoryzacja i uwierzytelnianie użytkowników)

No i na punkcie drugim się zatrzymałem z tego powodu, że jeśli gateway api autoryzuje czy uwierzytelnia a następnie wysyła żądanie, to gdzie w tym całym procesie są mikroserwisy? Chodzi mi o to, że jeśli one wykonują tylko i wyłącznie swoje funkcjonalności to nie mają pojęcia o tych zabezpieczeniach i jeśli ktoś by wysłał żądanie bezpośrednio do mikroserwisu z pominięciem tego gateway'a to otrzymałby dane?

Pytanie może wydawać się śmieszne ale prawda jest taka, że tego nie rozumiem i chciałbym się dowiedzieć w jaki sposób jest to tworzone (bez konkretnych zagadnień implementacyjnych tylko sam zamysł )

i jeśli ktoś by wysłał żądanie bezpośrednio do mikroserwisu z pominięciem tego gateway'a to otrzymałby dane?

Nikt nie broni ci na poziomie serwisu mieć uwierzytelnienia jakąś rolą ROLE_SERVICE które używają serwisy do komunikacji między sobą. Jednocześnie bardzo często większość serwisów w ogóle nie jest widoczna z zewnątrz więc nie da się wysłać do nich bezpośredniego requestu w zaden sposób. Z zewnątrz widać tylko reverse proxy / api gateway. Serwisy między sobą będą się widzieć po jakichś wewnętrznych adresach.

W jakimś AWSie ustawiłbyś sobie np. security group tak, że dany serwis jest osiągalny tylko z wybranych hostów (innych serwisów) a dla wszystkich innych jest niedostępny.
W prostym przypadku serwisy byłyby po prostu widzialne tylko po lokalnym adresie/lokalnym hoście i w ogóle nie dostępne z zewnątrz.

Shalom napisał(a):

Z zewnątrz widać tylko reverse proxy / api gateway. Serwisy między sobą będą się widzieć po jakichś wewnętrznych adresach.

Czyli generalnie (zwykle) nie pisze się zabezpieczeń w przypadku implementacji mikroserwisów? Gateway api jest widoczny a resztę serwerów blokuje firewall?

zwykle

Nie wiem, widziałem i takie i takie rozwiązania. Brak zabezpieczenia na poziomie serwisu oznacza ze gdyby jakimś cudem ktoś znalazł w twoich serwisach podatność SSRF, to mógłby ją wykorzystać do stukania do serwisów "bezpośrednio", więc zawsze to jakieś ryzyko. Od biedy można zrobić takie "zabezpieczenie" ze serwisy między sobą wysyłaja sobie jakis header z sekretna wartością i sprawdzają go sobie, jeśli nie chcesz się bawić w role i autoryzacje.

Shalom napisał(a):

jeśli nie chcesz się bawić w role i autoryzacje.

Jeśli bym robił jednak te role i autoryzacje to te serwisy powinny odbierać żądanie z jakimś tokenem a następnie wysyłać ten token do jakiegoś serwisu autoryzacyjnego w celu walidacji?

To zależy. Jeśli chcesz wykonywać te akcje w imieniu użytkownika to tak. Ale nie wiem czy masz konkretnie taki use-case. To ma zwykle miejsce jeśli następuje komunikacje między jakimś twoim serwisem, a jakimś nie-twoim serwisem :) Np. wyobraźmy sobie, że chcesz wykonać akcje w imieniu użytownika np. na githubie. Dostajesz OAuth token githubowy i teraz możesz wysyłać żądania z tym tokenem do githuba i robić coś "jako ten użytkownik". W efekcie użytkownik robi auth w twojej aplikacji, a ty potem mapujesz to sobie na token z githuba.

Dużo częściej serwisy jednego systemu między sobą używają swoich własnych ról i uprawnień i mają swoje własne tokeny. W takim sensie ze serwis X może wykonywać akcje A i B na serwisie Y i nie ma nic wspólnego z użytkownikiem który inicjował tą akcje.
To czy użytkownik może zlecić daną akcje w X jest sprawdzane przez autoryzacje użytkownika, ale później na poziomie X->Y operujesz już tylko rolami serwisów.

Jeśli różne serwisy muszą dokonywać uwierzytelniania i/lub autoryzacji to warto pomyśleć nad dostarczeniem jakiejś biblioteki dla tych serwisów, oraz generowaniem asymetrycznych tokenów (nie mam pojęcia czy tak to się tłumaczy na język polski). Wtedy do sprawdzania tokenów wystarczy klucz publiczny, a biblioteka kliencka może posiadać szczegóły implementacji sprawdzania konkretnych rzeczy w tokenie, np. czy użytkownik może dokonać konkretnej operacji. Wtedy uniezależnisz serwis od konieczności komunikowania się z serwisem autoryzacji.

Dużego doświadczenia w temacie nie mam, ale chyba nie bez powodu taki Redis czy Mongo w domyślnych konfiguracjach nie mają haseł dostępowych.