Czy mikrousługi za bramą API muszą weryfikować token dostępu?

Mam kilka mikrousług, które są dostępne tylko zewnętrznie za pośrednictwem interfejsu API Gateway.

Moja brama API jest skonfigurowana jako zasób OAuth i sprawdza poprawność tokena (sprawdza podpis itp.) Przed przekazaniem żądania do jednej lub więcej mikrousług.

Chociaż moje mikrousługi potrzebują tokena, aby zweryfikować zakresy i roszczenia, czy istnieje teraz potrzeba, aby ta usługa również zweryfikowała token?

Wydaje się to nieco przesadne, ale nie mogę znaleźć żadnych porad online na temat tego scenariusza.

Czy sprawdzanie poprawności tokena w bramce API jest wystarczająco dobre? Czy jest to najlepsza praktyka, aby sprawdzić to ponownie później?

microservices

— fml
źródło

Czy te same usługi są dostępne podczas wewnętrznego omijania bramy ?

— Greg Burghardt

I cannot find any advice online about this scenario.Ponieważ zależy to od kilku czynników, które różnią się w zależności od projektu. Prawdopodobnie w większości opracowań podających się za architekturę MS, nie potrzebują jej. Co więcej, w takich architekturach powinien istnieć serwer autoryzacji, który zrobi to zamiast usług (i oczywiście zamiast bramy). Jest serwerem autoryzacji, który zezwala na przekazanie żądania lub nie.

— Laiv

Jeśli jakiekolwiek połączenia wewnętrzne mogą ominąć bramę, sprawdź poprawność tokena w każdej mikrousługie lub zmuś wszystkie połączenia - wewnętrzne i zewnętrzne - do przejścia przez bramę.

Osobiście nie ufałbym również połączeniom wewnętrznym. Niech przechodzą przez bramę, nawet do ograniczenia ruchu poprzez reguły zapory ogniowej. Dowiedz się, kto i do kogo mówi. Pomaga to ograniczyć powierzchnię ataku, jeśli ktoś kiedykolwiek naruszy twoją sieć.

Wprowadza to jeden punkt awarii, ale ryzyko to można zmniejszyć poprzez równoważenie obciążenia serwerów i posiadanie serwerów awaryjnych w przypadku katastrofalnych problemów.

Z drugiej strony, jeśli każda usługa sprawdza poprawność tokena, a cokolwiek na temat procesu sprawdzania poprawności zmienia się, musisz zaktualizować usługi N + 1.

— Greg Burghardt
źródło

Słyszałem argument, że „nie można również ufać ruchowi wewnętrznemu”. Jednak udostępnienie aplikacji (względnie) niewielkiej liczbie użytkowników w intranecie jest dalekie od udostępnienia tej samej aplikacji w publicznym Internecie. Jest zasadniczo taki sam, jak różnica między magnesem głośnika a cyklotronem.

— Robert Harvey

@RobertHarvey: Myślę, że usprawiedliwienie, które słyszałem dla „nie ufaj wewnętrznemu ruchowi”, jest nie tyle uzasadnionym ruchem, co blokowaniem sieci w przypadku ingerencji. Zwłaszcza jeśli twój system obsługuje informacje osobowe, zdrowotne, finansowe lub wrażliwe. Jeśli ktoś się włamie, jest ograniczony w tym, z czym jeszcze może porozmawiać.

— Greg Burghardt,

Jeśli ktoś dostanie się do twojego systemu, sprawdzanie poprawności tokena będzie mniejszym problemem. To, czy powinieneś sprawdzić poprawność tokena w zaufanej sieci (i niedostępnej dla obcokrajowców), może zależeć od rodzaju przeprowadzanych przez nas sprawdzeń i jeśli nie zostanie przeprowadzona żadna weryfikacja. Na przykład wydajność. Wróć do twojego rozumowania. Czy zaimplementowałbyś TLS w sieci prywatnej? Czy zaszyfrowałbyś komunikację między dwoma komponentami pracującymi obok siebie? Prawdopodobna odpowiedź zależy .

— Laiv