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

10

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?

fml
źródło
1
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

Odpowiedzi:

3

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
2
@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