Как организовать безопасное общение между микросервисами?
Планирую разделить монолитное приложение на микросервисы, которые будут располагаться на разных серверах.
Я так понимаю, что эти микросервисы будут доступны из вне (т.е. из интернета). Поэтому появляется вопрос: Как организовать безопасное общение между микросервисами? Чтобы принимать запросы только от доверенных приложений (то есть - от других моих микросервисов).
PS: Было бы неплохо сделать так, чтобы можно было указать доступ для каждого конкретного метода.
Например, есть микросервис платежей, у которого есть 1) метод для выполнения платежа и 2) метод для просмотра истории платежей. И к первому методу доступ должен иметь только один определённый микросервис, а ко второму методу - вообще любой мой микросервис.
PS 2: Языки, на которых будут написаны микросервисы - Java и NodeJS.
Межсервисное взаимодействие ничем не отличается от клиент-серверного. Та же аутентификация и авторизация (тот же пресловутый openid credentials grant flow), тот же SSL. В некоторых редких случаях можно ограничиться white-list ip, но тут хватает ограничений и никаких ролей
Иван Шумов, спасибо за ответ!
Я думал насчёт того, чтобы микросервисы просто в каждом запросе к другим микросервисам передавали какую-то секретную строку. Типа своего идентификатора. Его можно прямо в код зашить. Ну или в переменные окружения.
По сути, это будет то же самое, когда зарегистрированный пользователь сайта передаёт куку с идентификатором сессии.
Если это всё будет по SSL, то вроде довольно безопасно, верно?
J. Snow, Да, кроме момента когда этот код будет скомпроментирован. Его нужно будет обновить, старые сессии сбросить и много еще чего. А еще туда надо будет зашить какие-то параметры ролей/прав доступа. В результате по пути появится еще один OAuth2/OIDC. Оно вам надо?
Иван Шумов, я что-то никак не пойму как мне использовать OAuth2/OID для микросервисов. Микросервисы будут должны как-то логиниться и запрашивать доступ у других микросервисов? Что-то мне непонятна эта схема)
Иван Шумов, Если кто то поднял неразборчивый режим на карте, а тем более зазеркалил порт маршрутизатора.
То ваш возглас, не более чем попытка прикрыть одно место. Уж извините за прямоту.
Владимир Коротенко, безопасности сети в плане взаимодействия между сервисами не существует. Можно ограничить адресацию, можно обернуть каналы через VPN, но, кроме того что это можно сделать только между своими ресурсами, так и не помогает если злоумышленник находится внутри сети. К тому же сеть не знает ничего про логику на 7ом уровне модели OSI, а значит что никакие разграничения по правам доступа внутри сервиса не применимы. Иными словами - ответ просто мимо
Иван Шумов, Тогда встречный вопрос типа на авторитете почему крупные компании таки делают разделение на горячую зону и холодную и не страдают вашим максимализмом?
Владимир Коротенко, DMZ это просто уменьшить attack surface и добавить точку контроля. Так отбиваться от атак проще, от DDoS, проще изолировать. Но если внутрь попадет злоумышленник то разницы, по сути, не будет. Ну и проблему, озвученную ТС, это не решает.
Межсервисное взаимодействие ничем не отличается от клиент-серверного. Та же аутентификация и авторизация (тот же пресловутый openid credentials grant flow), тот же SSL. В некоторых редких случаях можно ограничиться white-list ip, но тут хватает ограничений и никаких ролей
Итак внутри защищенного периметра, не DMZ мы имеем уязвимость в приложении. Вот настолько уязвимость что человек поднял уровень привилегий до рута. То есть молотком заколотится и только по ssl и только по доверенным сертификатам которые распространяются по каким каналам? Вот тут я вижу проблему.
Владимир Коротенко, еще раз читай внимательно. ТС спрашивает про то как гарантировать что одному микросервису можно обращаться к другому микросервису. Какие сети, о чем мы тут вообще говорим? Описанная проблема к вопросу не относится. Да, она важна, но она решается на инфраструктурой слое, исходя из того куда деплоится приложение. Относится это к вопросу сетевой коммуникации между виртуальными ресурсами. У человека же вопрос на уровне аутентификации и авторизации. Алло.
Как организовать безопасное общение между микросервисами? Чтобы принимать запросы только от доверенных приложений (то есть - от других моих микросервисов).
Мой ответ завести их в одну сеть, доверенную, а внешнее вынести в DMZ.
Это описано и документировано и применяется, зачем дополнительный костыль?
Владимир Коротенко, просто вопрос состоит еще из нескольких предложений, которые кто-то не удосужился прочитать. Также никто не говорил что микросервисы должны располагаться в одной сети или хотябы у одного хостера. Мы каждый день пользуемся десятками микросервисов, работающих over internet.
Основная цель человека - управлять разрешением на уровне операций в микросервисе. 2 микросервиса должны иметь разные права на операции в третьем. Каким местом сетевая безопасность решит данный вопрос если в обоих случаях трафик достигнет этого ресурса?
Иван Шумов, Это ваше решение, вы его приняли видимо по каким то соображениям, размазали периметр атаки по всему интернету. Возможно стоит сказать почему было принято такое решение. Какие это дает + и возможные минусы.
Причем я прошу сравнить с гетерогенной средой где все сервисы внутри, и наружу торчат только эндпоинты
Владимир Коротенко, дело в том что не надо путать разные слои безопасности и что решает проблему, а что нет. Сеть является слоем безопасности, несомненно, но изначальную проблему ТС не решает по тому что в случае изменения сетевой инфраструктуры придется переписывать все приложение. Просто перемещение микросервиса в другую сеть уже принесет боль. Я же предложил решение, которое будет контролировать коммуникацию между микросервисами вне зависимости от их инфраструктуры. Мы не знаем что это за микросервисы и что они будут делать, а значит и полагаться на сетевую коммуникацию тоже не можем.
В реальной жизни в обязательном порядке в бою применяются оба этих подхода, НО! Сетевая инфраструктура в данном вопросе вторична.
Еще стоит добавить что при разработке микросервисной архитектуры воспроизвести полноценное боевое окружение невероятно трудно и дорого, поэтому этого не делает никто. Даже AWS для своих разработчиков воспроизводит очень изолированные окружения с заглушками. А могли бы, как бы, и не жадничать. Разработка производится почти всегда локально и коммуникация проверяется даже с тестами на простейшей инфраструктуре. Поэтому требуются механизмы, которые будут работать вне зависимости от инфраструктуры.
Средний
Простой
Простой
Простой
Средний
