Zabezpieczanie mikroserwisów

0

Witam,
Mam pytanie odnośnie autoryzacji w mikroserwisach i komunikacji pomiędzy nimi. Jeśli np postawię APIGateway, który będzie najpierw autoryzował do poszczególnych mikroserwisów to jeden problem mam rozwiązany. Natomiast moje pytanie, w jaki sposób zabezpieczyć bezpośrednio mikroserwisy pomiędzy sobą i gdyby ktoś ominął APIGateway? Przykład:
Mam 2 mikroserwisy A i B oraz AG(apigateway).
Wszystkie requesty z frontendu idą przez AG, który rozprowadza je do A i B i wszystko fajnie. Teraz A potrzebuje pobrać danych z B i wymiana jest poprzez HTTP - w jaki sposób pozwolić A żeby komunikowało się z B (a dokładnie w jaki sposób to zabezpieczyć)? Również powinno odbywać się to przez APIGateway (będzie 2x więcej requestów, ale mikroserwisy nie będą musiały znać swoich adresów), czy powinienem tworzyć np wewnętrzny token który by latał pomiędzy mikroserwisami?

1

disclaimer: Nie znam się

Gateway wystawia jwt, który jest respektowany przez A i B, bo A, B i Gateway mając secret key mogą go zweryfikować, a wszystko bez tokena jest odrzucane

7

ZTCW to gateway nie jest po to, by mikroserwisy na backendzie ze sobą rozmawiały tylko by stanowić punkt wejścia dla klientów z zewnątrz. Wyłączenie gatewaya nie powinno wpływać na działanie mikroserwisów, a tylko na dostępność usług z zewnątrz.

Tutaj jest przykładowa architektura:
https://docs.microsoft.com/pl[...]croservice-application-design

gateway-i-reszta.png

1
  1. Większość serwisów może być w ogóle nie dostępna z zewnątrz
  2. Jeśli stawiasz to na jakimś AWSie to dodajesz security groups które wpuszczają do danego serwisu tylko i wyłącznie wybrane serwisy
  3. Możesz dodać sobie header z jakimś tokenem "serwisowym" i go weryfikować kiedy dostajesz request
1

Ja to robię tak.
W serwisie, który powinien być "chroniony" sprawdzam, kto wykonuje tą operację, np:

public class MyService
{
     ILoggedUserProvider loggedUser;

    public async Task<IdentityResult> DoProtectedJob()
    {
        if(!loggedUser.IsAdmin())
          return IdentityResult.Failed(IdentityErrors.Unauthorized);
    }
}

Bardzo łatwe w implementacji, bardzo łatwe w testowaniu i działa :)

0

@Juhas: przypadkiem wtedy każdy microservice nie musi mieć całej bazy z uprawnieniami użytkowników?

0

Tym zajmuje się ILoggedUserProvider. On wie, czy zalogowany jest admin, czy nie admin. W najprostszej postaci.

2

Jestem przeciwnikiem konfigurowania security w gatewayu.

  1. Autoryzacja jest zdefiniowana z dala od reguł biznesowych - łatwo o desync.
  2. Nie mamy tokenu np. JWT, a więc nie mamy danych o użytkowniku
  3. Wszystko opiera się na bezpieczeństwie VPS. Ktoś zrobi RCE i ma wszystkie dane podane na tacy.

Mam dobre doświadczenia z standardem OpenID Connect np. Keycloak. Aby zawołać serwis musimy podać token, który zawiera dane o użytkowniku, role i jest podpisany przez serwer jego kluczem prywatnym. Poszczególne serwisy jedynie weryfikują podpis za pomocą klucza publicznego. Takie podejście jest dość dobrze skalowalne według mnie.

Cały czas mam token z mailem usera, jego rolami, imieniem etc. Mogę w moim serwisie dodać funkcję, wysyłania maila z życzeniami imieninowymi do VIP userów. :)

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