Jaki jest najlepszy sposób na zabezpieczenie aplikacji mikrousług?

0

Tworzę aplikację w oparciu o architekturę mikrousług. Frontend jest napisany w Angular, backend składa się ze Spring Cloud Gateway, mikrousługi autoryzującej Spring Boot (z użytkownikami w MongoDB), która tworzy sesję przechowywaną w bazie danych Redis, kilku mikrousług Spring Boot z logiką biznesową oraz bazy danych. Zastanawiam się, jak zabezpieczyć swoją aplikację, aby wszystko było zgodne z aktualnymi trendami bezpieczeństwa w tym stosie technologii.

Obecnie każda mikrousługa ma dostęp do bazy danych Redis i zwraca dane, jeśli znajdzie w niej sesje użytkownika. Brama przekazuje wszystkie zapytania bez sprawdzania czegokolwiek. Moje bezpieczeństwo opiera się na Session Cookie. Wszystko działa, ale chciałbym, żeby projekt był poprawny architektonicznie i rozważam zmianę. Myślałem o dodaniu uwierzytelnienia tylko w bramce.

Jaki byłby najpoprawniejszy sposób na wykonanie takich architektury? W internecie jest wiele przykładów ale taka architektura jest dla mnie czymś nowym i nie wiem w którą stronę powinienem pójść. Zastanawiam się także czy ciasteczko sesyjne jest na pewno dobrym wyborem i czy któraś z alternatyw nie jest lepsza.

2

Wszystko w ramach potrzeb :) jeśli zdecydowałeś się na sesje, to trzymanie jej w szybkim cache ma jak najbardziej sens. Trochę mnie martwi uświadomienie wszystkich usług istnieniem tych sesji.

Alternatywnym podejściem jest stateless authentication, implementowana z użyciem krótkich tokenów JWT. Wówczas nie potrzebujesz żadnej bazy na przechowywanie sesji, tokeny walidujesz w Gateway, a reszty usług w ogóle nie wystawiasz na świat.

2

Mikroserwisy trzymane wewnętrznie, niedostępne z zewnątrz a jedynie wystawione poprzez API Gateway. W tej warstwie właściwe uwierzytelnianie sesji, a w poszczególnych serwisach dodatkowe sprawdzanie i autoryzacja, zakładając że przesyłasz JWT token lub coś podobnego jako forma autoryzacji requestów.

Oczywiście te "właściwe" uwierzytelnianie w API Gateway może oznaczać wysłanie odpowiedniego requesta do jakiegoś wewnętrznego serwisu odpowiedzialnego za bezpieczeństwo. Konkretna implementacja zależy od potrzeb.

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