Коды ошибок, специфичные для отдельных микросервисов — уязвимость?

Если ваша микро-сервисная архитектура отвечает кодами ошибок, указывающими, какой микро-сервис вызвал ошибку, разве это не раскрывает вызывающему информацию о том, как спроектирована ваша микро-сервисная архитектура?

Вызывающий -> Сервис A -> Сервис B -> Ошибка Сервиса B

Коды ошибок:
ServiceA-000001
ServiceB-000001
ServiceC-000001

Итак, если я отправляю запрос в A, я знаю, что он взаимодействует с B, и как-то я узнаю, что могу использовать эту цепочку.

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

Вопрос, похоже, подтверждает мои подозрения, но какие есть плюсы, минусы и доводы в поддержку этого?

Здесь применим основной принцип безопасности – неразборчивость не является безопасностью.

В этом случае следует оценить бизнес-выгоды от устранения неполадок и понимания системы по сравнению с тем, насколько легко вы облегчаете задачу злоумышленникам, изучающим вашу систему.

Злоумышленник все равно сможет разобрать большинство архитектурных вопросов. Ваша модель безопасности должна подразумевать, что они уже знают, так что утечка информации, которую вы описываете, имеет низкий риск.

Кратко;

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

Тогда вы можете сосредоточиться на том, чтобы убедиться, что в микро-сервисах нет уязвимостей.

Существует компромисс. Если вы замаскируете информацию о трассировке в кодах ошибок, то вашим инженерам будет сложнее понять, как взаимодействуют сервисы. Если ваша команда не может легко понять, как работают вещи, как они могут оценить слабые места в дизайне?

Замаскировав, как работает ваша система, вы также замаскировываете ее для вашего персонала.

Делая систему прозрачной, вы делаете ее прозрачной и для своего персонала. И вы можете сосредоточиться на исправлении уязвимостей и уязвимостей дизайна.

Вот почему мы доверяем AES больше, чем проприетарному и замаскированному шифру – он открыт и протестирован.

Тем не менее, асимметрия информации все еще является преимуществом для того, у кого ее больше. Реальная ценность этого принципа заключается в планировании безопасности, предполагая, что плохие парни знают все. Вы абсолютно должны сохранять информацию конфиденциальной. Но также предполагайте, что злодей знает или узнает. Т.е. в любой момент противник может узнать вашу архитектуру, поэтому никогда не предполагайте, что они не знают или не могут.

Да, я бы сказал, что эти префиксы кодов ошибок представляют собой ненужный риск.

Стандарты проверки безопасности приложений OWASP прекрасно охватывают это:

7.4.1 Подтвердите, что при возникновении неожиданной или чувствительной с точки зрения безопасности ошибки отображается общее сообщение, возможно, с уникальным идентификатором, который может использовать персонал для расследования.

Правильное место для информации, раскрывающей точно, какой микро-сервис потерпел неудачу и как, – это системы журналирования / наблюдаемости.