До чего всё ещё может добраться скомпрометированный веб-шлюз?
Веб-шлюз ограничивает то, что открывает посетитель, а не то, до чего может добраться скомпрометированный хост. Две проверки, таблица полномочий и команды измерения доступности.
Предположим, хост шлюза скомпрометирован, пока его сертификат ещё действителен. Каждое правило, определявшее, какие страницы посетитель может запрашивать, остаётся в силе, и ни одно из этих правил не ограничивает соединение, которое атакующий теперь открывает с этого хоста в сторону подсети базы данных. Именно этот разрыв делает точку входа только для веба не тем же утверждением, что сегментированная сеть. Оба утверждения требуют отдельных проверок, из разных отправных точек, прежде чем любое из них можно сделать честно.
Два утверждения, и только одно из них начинается у посетителя
Первое утверждение о человеке: посетитель с браузером и действующей сессией может открыть одно приложение и ничего больше. Точка входа только для веба хорошо отвечает на это утверждение, потому что посетитель получает страницу, а не маршрут. Этот ответ полезен, и он же единственное утверждение, которое фиксирует большинство схем.
Второе утверждение о компоненте: предполагается, что шлюз или процесс приложения за ним находится под чьим-то чужим контролем. Из этого допущения вопрос меняется с того, какие URL разрешены, на то, до каких назначений и идентичностей процесс всё ещё может добраться.
У двух утверждений разные владельцы, они дают разные доказательства и отказывают независимо. Команда идентичности может показать первое тестом сессии; второе требует сетевой политики, проверки сервисной учётной записи и контроля хоста. Проект, фиксирующий только половину посетителя, выглядит полным на слайде проверки и слабым во время инцидента, потому что средства контроля, важные после компрометации, никогда не входили в охват. Назовите, какое утверждение поддерживает каждый контроль, иначе одно правило шлюза зачтут обоим.
Проработанный пример службы расходов и два способа, которыми она проигрывает
Возьмём службу расходов: публичный шлюз на 10.60.4.10 аутентифицирует сотрудников и передаёт одобренные запросы слушателю приложения на порту 8443, а это приложение достигает одного слушателя PostgreSQL на 10.60.4.20:5432 в роли expenses_app. Сотрудники не должны получать общий внутренний доступ. При нормальной работе проект действительно даёт вход, специфичный для приложения, нигде не публикуя слушателя базы данных. Адреса важны, потому что каждая последующая проверка в этой статье их называет.
Теперь уберите шлюз из доверенного набора. До каких назначений может добраться 10.60.4.10, когда его процесс принадлежит атакующему? Фильтр URL, ограничивавший посетителей, ничего не говорит о соединении, которое хост шлюза открывает в сторону подсети базы данных.
Уберите вместо этого процесс приложения, и полномочия меняют форму: роль expenses_app, службы, до которых может добраться этот сервер, и файлы, которые может читать эта учётная запись. В обоих случаях входная дверь может оставаться только вебовой, пока граница бэкенда отсутствует. Поэтому табличка на входной двери не является ответом ни на один из двух вопросов.
Составьте карту полномочий, которые каждая сторона действительно имеет
Договор, написанный как предполагаемые разрешения, склонен повторять проект вам. Напишите его как удерживаемые полномочия, проверку, опровергающую излишек, и владельца этой проверки, и каждая строка станет проверяемой. Эта таблица — предложение для примера выше, а не утверждение о продукте:
| Component | Authority it actually holds | Check that proves the denial | Owner of the check |
|---|---|---|---|
| Identity provider | Issues assertions and session cookies, and holds no network path of its own | A request to the application URL without a session is redirected to the login page | Identity team |
| Public gateway host | TCP reachability to whatever its routing table and egress rules permit | An egress rule drops 10.60.4.20:5432 and the probe reports the port filtered | Network platform team |
| Application role | SQL privileges granted to expenses_app inside the expenses database | A privilege query shows no ownership or create right on any other schema | Application team |
| Database listener | Accepts connections only from the source ranges named in its host-based rules | A connection from an unlisted address is refused before authentication | Database administrator |
| Management path | Administrative access reserved for patching, monitoring and recovery | A staff workstation cannot reach the administrative port or jump through it | Platform owner |
Собственность следует за полномочиями. Команда идентичности владеет утверждениями, команда сетевой платформы — маршрутами, команда приложения — ролью базы данных, администратор базы данных — слушателем и его правилами на основе хоста, а владелец платформы — плоскостью управления. Отказ без владельца — это предложение в документе, а не контроль.
Разделение также предотвращает двойной учёт. Ограничение порта не может выразить привилегию таблицы, а роль базы данных не может помешать хосту открыть сокет к несвязанной подсети.
Перечислите, до чего может добраться шлюз, вместо того чтобы утверждать это
Утверждение о границе ценно ровно настолько, насколько хорош перечень за ним. На хосте шлюза три команды охватывают выбор маршрута, живую проверку и политику выхода:
ip route get 10.60.4.20
nc -zv 10.60.4.20 5432
sudo nft list chain inet filter outputЧитайте вывод в этом порядке. Маршрут говорит, выбирается ли 10.60.4.20 вообще с этого хоста; проверка говорит, отвечает ли слушатель; список правил показывает, останавливает ли политика пакет или на его пути никогда ничего не было.
Повторите перечень с хоста приложения. Оттуда сторона базы данных — один запрос, выполненный в роли приложения:
psql -h 10.60.4.20 -U expenses_app -d expenses -c 'select rolname, rolsuper, rolcreatedb from pg_roles'Успешное соединение под ролью, которая не может читать другую схему, — иной результат, чем успешное соединение под ролью владельца. Только второе является находкой.
Зафиксируйте отказы, затем поставьте дату проверки
Приёмка записывается как результаты, а не намерения: сессия сотрудника не может добраться до слушателя, хост шлюза не может добраться до несвязанной подсети, а роль приложения не может создать базу данных. Каждая — отдельная проверка с названным владельцем и датой.
Держите мониторинг, установку исправлений и восстановление доступными через путь управления, предназначенный для них. Граница, которая блокирует и своего владельца, становится сбоем, и обычная первая реакция на такой сбой — снова расширить правило. Руководство CISA по периметру требует ограничивать входящий и исходящий доступ обоснованными портами и протоколами, включая трафик между внутренними сетями, то есть направление, инициируемое бэкендом, которое большинство схем опускает.
Поставьте дату проверки и назовите её владельца. Повторно выполните перечень и запрос привилегий после любого изменения образа шлюза, таблицы маршрутизации или роли приложения.