Как безопасно защитить микросервисы в AWS VPC с сервером ALB и OAuth?
Tldr: см. общие вопросы см. ниже.
Я построил инфраструктуру, описанную ниже (в приложении) в AWS. OAuth указывает сервер аутентификации, который выдает токены (Authorizes), а затем аутентифицирует токены при каждом запросе и разрешает прокси для внутреннего ALB.
Он основан на архитектуре микро-сервисов и использует oauth для выдачи токенов и аутентификации их из клиентских приложений. Клиентские приложения могут быть приложениями внутри VPC или приложениями, внешними по отношению к VPC. Как видите, я хочу, чтобы все запросы проходили через сервер OAuth, прежде чем они попадут на внутренний ALB. Теперь разные типы приложений должны использовать разные типы грантов для получения токенов доступа. Эти маркеры доступа будут содержать область действия, которая относится к маршрутам (конечным точкам API) внутреннего ALB.
Теперь у меня есть несколько вопросов, которые, я надеюсь, будут максимально краткими:
AWS VPC ALB Вопросы
Какой самый безопасный способ гарантировать, что только приложения oauth взаимодействуют с внутренним ALB, а не с другими приложениями в общедоступной подсети? Таким образом, мы можем быть уверены, что все запросы к внутреннему ALB аутентифицированы? Нужно ли каким-либо образом подключать новую подсеть oauth only к входу внутреннего ALB, но как мне ограничить вход внутреннего ALB?
С этой же целью, как я могу гарантировать, что приложения в одной подсети не взаимодействуют друг с другом? По сути, как я могу гарантировать, что никакие внутренние приложения не взаимодействуют друг с другом и должны быть переданы на внешний балансировщик нагрузки и, следовательно, в oauth из частной подсети.
Маршрут 53 SLL терминация ALB
Останавливает ли SSL-терминация на определенном порту трафик, направляемый из разных доменов. Если я выполняю вызов на порт 433 ALB из внутреннего ALB с завершением SSL, нужно ли мне звонить с хоста (route53thing.com), указанного в сертификате, или я могу использовать DNS-имя хоста ALB(something.elb.amozonaws). com) разрешено AWS, хорошо?
Области применения и OAuth
Как сравнить URL каждого запроса и его токен с областями oauth? Я хочу связать области видимости с конечными точками API. Таким образом, каждый запрос направляется в конечную точку маршрута с access_token, который содержит области действия. Эту область необходимо сравнивать с URL-адресом запроса для каждого запроса, чтобы убедиться, что он разрешен. Oauth поставляется с этой функциональностью? Я бы не догадался. Однако какой смысл в том случае, если это не так? Похоже, область видимости - это просто массив, который мне нужно выполнить после аутентификации, а не особенность в oauth. Я, наверное, что-то упускаю:-).
Этот пост уже слишком длинный, поэтому я по понятным причинам не могу разобраться во всех деталях, но если вы хотите получить больше подробностей, я, конечно, дам их. Даже помощь в правильном направлении была бы полезна в этом пункте.
Заранее спасибо.
