У меня есть команда разработчиков, которые пишут как интранет, так и внешний веб-сайт.
Веб-сайт состоит из двух серверов и балансировщика нагрузки внутри DMZ.
В DMZ есть отверстие, открытое для LAN (http / 80), для доступа к службам API из LAN.
например WAN -> haproxy -> web01 (+ web02) -> pinhole -> LAN Services (haproxy -> lan01 / lan02)
Проблема в том, что разработчики поставили все их служб в локальной сети, включая те, которые работают только с веб-сайтом. то есть web01 / 02 на данный момент действует как агрессор.
Что еще хуже, службы локальной сети были привязаны к нашей инфраструктуре AD, а внутренние API-интерфейсы доступны для DMZ, поскольку как внутренние, так и внешние API работают на порту 80.
Разработчики не хотят разделять свои API, чтобы иметь «внутреннее» и «внешнее» представление, и эти API в настоящее время не имеют аутентификации / авторизации.
некоторые службы также работают только на «lan01», а не на «lan02» из-за использования локального файлового хранилища, т. е. отсутствия высокой доступности.
Теперь существует зависимость от всей внутренней инфраструктуры корпорации (DNS, AD), чтобы внешний веб-сайт мог функционировать.
Нет понятия безопасных методов, т. Е. Определенные LAN API работают как привилегии уровня "SYSTEM", и нет контроля над тем, с какими системами обращаются разработчики (поскольку у них есть учетные данные администратора домена).
Я предлагал перенести большую часть сервисов, обслуживающих веб-сайты, обратно в DMZ и заблокировать эти сервисы, но мне сказали, что разработчики не могут делать различия между тем, что является приложением «LAN», и тем, что такое интернет-приложение.
У кого-нибудь есть предложения, как с этим бороться? Похоже, что ждет кошмар безопасности.
Найдите новых разработчиков, потому что их работа сверху вниз кажется ужасной.
Похоже, они игнорируют даже самые основные рекомендации OWASP. Вы не упоминаете ни размер компании, ни свою роль, но работа разработчиков не выдержит проверки безопасности.
Ура