Нужно ли микросервисам за шлюзом API проверять токен доступа?

10

У меня есть куча микросервисов, которые доступны только снаружи через API-шлюз.

Мой API-шлюз настроен как ресурс OAuth и проверяет токен (проверяет подпись и т. Д.) Перед передачей запроса на одно или несколько микросервисов.

Хотя моим микросервисам нужен токен для проверки областей и утверждений, есть ли необходимость в том, чтобы этот сервис также проверял токен?

Кажется, это немного излишне, но я не могу найти никаких советов в Интернете об этом сценарии.

Достаточно ли хороша проверка токена на шлюзе API? Или лучше проверять это позже?

microservices FML
источник
1
Доступны ли эти же службы при обходе шлюза внутри ?
Грег Бургардт
I cannot find any advice online about this scenario.Потому что это зависит от нескольких факторов, которые варьируются от проекта к проекту. Вероятно, в большинстве разработок, претендующих на звание архитектуры MS, им это не нужно. Более того, в таких архитектурах должен быть сервер авторизации, который будет делать это вместо сервисов (и, конечно, вместо шлюза). Является ли сервер авторизации, который разрешает передачу запроса или нет.
Laiv

Ответы:

3

Если какие-либо внутренние вызовы могут обойти шлюз, либо проверьте токен в каждом микросервисе, либо заставьте все вызовы - внутренние и внешние - проходить через шлюз.

Лично я бы не стал доверять внутренним звонкам. Пусть они пройдут через шлюз даже до точки ограничения трафика с помощью правил брандмауэра. Знайте, кто с кем разговаривает и почему. Это помогает ограничить вашу поверхность атаки, если кто-нибудь проникнет в вашу сеть.

Это создает единую точку отказа, но этот риск может быть уменьшен за счет балансировки нагрузки на серверах и наличия резервных серверов под рукой в ​​случае катастрофических проблем.

С другой стороны, если каждая служба проверяет токен и что-либо в процессе проверки изменяется, у вас есть N + 1 служб для обновления.

Грег Бургардт
источник
Я слышал аргумент, что «вы также не можете доверять внутреннему трафику». Но показ приложения (относительно) небольшому числу пользователей в интрасети далек от того, чтобы показать это приложение общедоступному Интернету. По сути, это то же самое, что разница между магнитом динамика и циклотроном.
Роберт Харви
2
@RobertHarvey: Я думаю, что оправдание «не доверяй внутреннему трафику», которое я услышал, - это не столько законный трафик, сколько защита от сети в случае вторжений. Особенно, если ваша система обрабатывает личную, медицинскую, финансовую или конфиденциальную информацию. Если кто-то вмешивается, он ограничен в том, что еще он может говорить.
Грег Бургхардт
Если кто-то войдет в вашу систему, проверка токена будет меньше ваших проблем. Нужно или не нужно проверять токен в доверенной сети (и не доступны для иностранных пользователей), может зависеть от того, какие проверки мы проводим, и если какие-либо проверки снова не выполняются. Как, например, производительность. Вернемся к вашим рассуждениям. Вы бы внедрили TLS в частной сети? Вы бы зашифровали связь между двумя компонентами, работающими рядом друг с другом? Вероятный ответ зависит .
Laiv