Внутренний ALB с публичным DNS-именем: действительно ли он открыт?

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

Шаг первый: читайте схему, а не IP

Поле схемы — это собственное заявление балансировщика о его границе. aws elbv2 describe-load-balancers --names app-internal возвращает Scheme со значением internal или internet-facing, плюс тип адреса для IPv4 или двойного стека. Балансировщик, обращённый в интернет, всё равно может перенаправлять на частные цели, поэтому вид частных адресов бэкенда ничего не доказывает о фронтенде.

Запишите схему, прежде чем смотреть на что-либо ещё, потому что каждое последующее суждение зависит от неё. Она также говорит, какие средства управления существуют, от групп безопасности и правил listener до набора функций этого типа балансировщика. Схема, скопированная со старого снимка консоли, хуже, чем отсутствие заметки. Перечитайте её из API и вставьте значение в заявку.

Шаг второй: посмотрите, во что разрешается имя

Запросите извне VPC с помощью dig +short app-internal-1234567890.eu-west-1.elb.amazonaws.com и отметьте, находятся ли ответы в 10.0.0.0/8, 172.16.0.0/12 или 192.168.0.0/16. Частный ответ от публичного резолвера — ожидаемое поведение для имени внутреннего балансировщика; это не доказательство того, что адрес маршрутизируется из интернета.

Разрешите то же имя изнутри VPC и сравните. Если два ответа различаются, вы видите именование split-horizon, и это различие — деталь проектирования, а не утечка.

Шаг третий: перечислите пути, которые могут к нему добраться

Частный адрес доступен откуда угодно, где есть маршрут и правило безопасности. Перечислите их намеренно: VPN между площадками, клиентский VPN, VPC peering, подключения transit gateway, Direct Connect и любой прокси или бастион внутри VPC. Один из них — предполагаемый путь, а остальные — те, которые искал бы злоумышленник.

Затем проверьте средства управления на каждом пути: группы безопасности на балансировщике, сетевые ACL на подсетях и маршрутизацию, которая вообще создаёт путь. Большинство заявленных случаев открытой внутренней службы решается здесь: либо существовал непреднамеренный peering, либо путь был преднамеренным, а в приложении не было аутентификации.

Шаг четвёртый: проверьте listener и приложение по отдельности

Попробуйте подключиться из сети, которая не должна достигать службы, и убедитесь, что не можете. Затем попробуйте из той, которая должна, и убедитесь, что достигаете listener. Эти два результата отделяют сетевую доступность от поведения приложения, и они — единственное доказательство, важное для вопроса об открытости.

Достижимый listener — не то же самое, что доступное приложение. Проверьте сертификат TLS и политику протокола, затем аутентификацию и авторизацию самого приложения. Внутренний инструмент, принимающий любого вызывающего в корпоративном VPN, открыт для каждого скомпрометированного ноутбука в этом VPN, что является другим риском по сравнению с обращённым в интернет, но всё же риском.

Помните, что средства управления различаются по типу. Межсетевые экраны прикладного уровня подключаются к одному семейству балансировщиков, а не к другому, поэтому подтвердите, что реально доступно для схемы и типа перед вами, вместо того чтобы предполагать равенство.

Шаг пятый: решите, важно ли само имя

Публичная разрешимость может раскрыть имя службы, регион и диапазон адресов. Относитесь к этому как к вопросу раскрытия информации с ответом в политике, а не как к автоматическому инциденту: держите конфиденциальные деловые термины вне имён ресурсов и отметьте раскрытие в реестре рисков, если соглашение об именовании раскрывает больше, чем вы хотите.

Если организация хочет частного именования, частная размещённая зона может обслуживать псевдоним, который разрешается только внутри связанных VPC. Это меняет имя, которое видят пользователи; это не делает имя, сгенерированное провайдером, секретным и не удаляет ни одного сетевого пути.

Не пытайтесь закреплять адреса, чтобы скрыть ответ. Адреса балансировщика меняются, закрепление ломает привычки проверки TLS, а контроль, который вам действительно нужен, — это кто может установить соединение и что приложение от него требует. Проверьте четыре факта, запишите их, и вопрос перестаёт быть двусмысленным.