#security #microservices #api-gateway
#Безопасность #микросервисы #api-gateway
Вопрос:
Название в значительной степени подводит итог. Я разбиваю монолит и борюсь с некоторыми из меньших вариантов дизайна в мире микросервисов.
У меня есть API gateway, который является обратным прокси для всех других моих сервисов. Я пытаюсь сделать все службы максимально автономными, но мне интересно, какова наилучшая практика при работе с паролем пользователя. Это:
- Лучше полностью изолировать службу пользователя и отправлять пароль между шлюзом и службой в виде открытого текста.
- Хэшируйте пароль сразу после получения доступа к шлюзу и отправляйте хэш только службе, добавляя немного больше связи между службами.
Спасибо за совет!
Комментарии:
1. Цель хеширования пароля — защитить его в состоянии покоя. При транспортировке он защищен шифрованием. Хэшируйте пароль в сервисе.
2. @JohnWu Это отличный момент, который даже не приходил мне в голову. Это именно то, что я сделаю. Спасибо
Ответ №1:
Обычно шаблон заключается не в фактической отправке пароля между микросервисами, а в отправке токена авторизации, который подтверждает авторизацию. JWT является типичным в этом случае. Утверждение может включать информацию о пользователе, но не обязательно включать пароль, что более безопасно для всех.
Представлен новый сервис, который проверяет имя пользователя и пароль пользователя и обменивает их на защищенный токен, который включает подписанные метаданные, такие как идентификатор пользователя, уровни доступа и, возможно, другую информацию.
Подробности на jwt.io или найдите где-нибудь OAuth2.
Комментарии:
1. Вероятно, это верно, но только в том случае, если упомянутый API gateway действительно способен выполнять аутентификацию , а не вместо этого передает аутентификацию другой службе. Насколько я понял, последнее имеет место.
2. Неправда! JWT — это автономный аутентифицированный обмен удостоверениями. Некоторая другая служба может выполнять аутентификацию, и любая служба может декодировать и полагаться на нее.
3. Это не то, что я имел в виду, и, возможно, я неправильно понял суть операции. Я исходил из предположения, что исходное приложение, взломанное на микросервисах, включает в себя некоторую службу аутентификации. Таким образом, API gateway должен связаться с этой самой службой для аутентификации. Конечно , здесь можно использовать JWT после успешной аутентификации. То есть служба аутентификации будет выдавать JWT. Тем не менее, для первоначальной аутентификации службе аутентификации необходимо предоставить имя пользователя и пароль. Но, как я уже сказал, возможно, я неправильно понял первоначальный вопрос.
4. … так что это другой вариант использования, чем то, что вы написали. Вы говорите об авторизации , в то время как я говорил об аутентификации , которая, как я думал, была целью операции.
5. Всегда сложно декодировать полную архитектуру из нескольких операторов. Я думаю, важным моментом является то, что должен быть передан какой-то токен, и наиболее эффективно токен должен быть надежным для получателя без необходимости выполнения внешнего вызова какой-либо другой службы. JWT — это простой способ сделать это, независимо от того, как генерируются токены.