Владимир Коротенко, дело в том что не надо путать разные слои безопасности и что решает проблему, а что нет. Сеть является слоем безопасности, несомненно, но изначальную проблему ТС не решает по тому что в случае изменения сетевой инфраструктуры придется переписывать все приложение. Просто перемещение микросервиса в другую сеть уже принесет боль. Я же предложил решение, которое будет контролировать коммуникацию между микросервисами вне зависимости от их инфраструктуры. Мы не знаем что это за микросервисы и что они будут делать, а значит и полагаться на сетевую коммуникацию тоже не можем.
В реальной жизни в обязательном порядке в бою применяются оба этих подхода, НО! Сетевая инфраструктура в данном вопросе вторична.
Еще стоит добавить что при разработке микросервисной архитектуры воспроизвести полноценное боевое окружение невероятно трудно и дорого, поэтому этого не делает никто. Даже AWS для своих разработчиков воспроизводит очень изолированные окружения с заглушками. А могли бы, как бы, и не жадничать. Разработка производится почти всегда локально и коммуникация проверяется даже с тестами на простейшей инфраструктуре. Поэтому требуются механизмы, которые будут работать вне зависимости от инфраструктуры.
Владимир Коротенко, просто вопрос состоит еще из нескольких предложений, которые кто-то не удосужился прочитать. Также никто не говорил что микросервисы должны располагаться в одной сети или хотябы у одного хостера. Мы каждый день пользуемся десятками микросервисов, работающих over internet.
Основная цель человека - управлять разрешением на уровне операций в микросервисе. 2 микросервиса должны иметь разные права на операции в третьем. Каким местом сетевая безопасность решит данный вопрос если в обоих случаях трафик достигнет этого ресурса?
Владимир Коротенко, еще раз читай внимательно. ТС спрашивает про то как гарантировать что одному микросервису можно обращаться к другому микросервису. Какие сети, о чем мы тут вообще говорим? Описанная проблема к вопросу не относится. Да, она важна, но она решается на инфраструктурой слое, исходя из того куда деплоится приложение. Относится это к вопросу сетевой коммуникации между виртуальными ресурсами. У человека же вопрос на уровне аутентификации и авторизации. Алло.
Владимир Коротенко, DMZ это просто уменьшить attack surface и добавить точку контроля. Так отбиваться от атак проще, от DDoS, проще изолировать. Но если внутрь попадет злоумышленник то разницы, по сути, не будет. Ну и проблему, озвученную ТС, это не решает.
Владимир Коротенко, безопасности сети в плане взаимодействия между сервисами не существует. Можно ограничить адресацию, можно обернуть каналы через VPN, но, кроме того что это можно сделать только между своими ресурсами, так и не помогает если злоумышленник находится внутри сети. К тому же сеть не знает ничего про логику на 7ом уровне модели OSI, а значит что никакие разграничения по правам доступа внутри сервиса не применимы. Иными словами - ответ просто мимо
Иван Шумов
@inoise Куратор тега Amazon Web Services
J. Snow, ну, как минимум там нет централизованной системы безопасности и динамического конфигурирования. Да и опций примерно ноль. Не говоря уже о том чт использование k8s не оправдано примерно никак пока ты не на уровне Энтерпрайз. Это очень дорого и болезненно. В GCP его придумали для GCP, а другие облака подхватили по тому что большие и жирные клиенты не хотели переезжать без этого инструмента. Если у вас стартап то вам в первую очередь смотреть на максимально просто работающие инструменты и максимальную делегацию управления в облако.
Чтобы расти максимально быстро сегодня кроме AWS я серьезно не вижу вариантов. Они сделали прекрасный Fargate чтобы не управлять виртуалками под Docker, ECS + ECR для тех кому надо максимально просто и понятно запускать контейнеры с масштабированием. Тонна Serverless решений, которые вообще на 99% спасают вас от головных болей. Та же Aurora с MySQL интерфейсом и шикарными возможностями к репликации и failover без потери данных. И все за разумные деньги, если считать TCO и сравнивать аналогичный конфиг на других платформах
askar98, ну как бы все что хранится на клиенте имеет одинаковую безопасность. А лишние куки передаются в заголовках по сети. Если это не https то пиши пропало). Есть еще Session Storage, кстати
FanatPHP, я строю архитектуру в подавляющем случае Immutable. Поэтому рефакторинг производится только по праздникам, в крайних случаях. Рефакторинг не нужен там где нет изменения кодовой базы)
FanatPHP, ну, лично мне в принципе не важно что там с кодом если это не мешает двигаться вперёд и не заставляет буксовать в рефакторинге. Моя задача чтобы вот такие вопросы оставались на уровне холиваров и не влияли на продукт)
