Шифрованный транзит не даёт доступа к оператору

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

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

Определите обе границы, прежде чем трогать конфигурацию

Первая граница — разговор: какие пары шлюзов могут установить туннель и какой внутренний трафик допускается через него. Вторая — оператор: какие адреса и сервисы хосты с меньшим доверием могут достичь вне туннеля. Команды обычно строят первую, а вторую наследуют от любой уже существовавшей маршрутизации, и так ограниченный проект тихо становится широким. Это наследование — обычная первопричина, когда проверка обнаруживает хост с меньшим доверием, разговаривающий с чем-то, что никто не одобрял.

Запишите обе как списки адресов, портов и направлений. Если список нельзя записать, граница ещё не определена.

Шаг 1: ограничьте внешний туннель

На интерфейсе, обращённом к оператору, разрешите только то, что нужно туннелю: IKE на UDP 500 и 4500 между двумя адресами шлюзов и ESP там, где не используется обход NAT. Отклоняйте всё остальное, что приходит на этот интерфейс, включая протоколы управления. Спецификация ESP описывает службы защиты; она ничего не говорит о том, какими собственными сервисами оператора могут пользоваться шлюзы. Выразите это как явный список разрешений, чтобы недавно опубликованный сервис оператора не стал доступен по умолчанию.

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

Проверьте это со стороны с меньшим доверием, а не из консоли шлюза. Хост там должен не суметь достичь DNS-сервера оператора ещё до поднятия туннеля.

Шаг 2: решите, что доставляет дальний шлюз

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

Схема, которая останавливается на успешном расшифровании, пропустила самое важное решение.

Шаг 3: сохраняйте владение по слоям

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

Назначьте владельца каждому слою. Слои без владельца — те, что дрейфуют.

Шаг 4: проверьте, затем передайте это органу

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

Для регулируемых или секретных сред отнесите проект в ответственный орган безопасности и используйте его одобренную архитектуру разделения. Конфигурация VPN и концептуальное объяснение не создают аккредитации. Этот шаг — не бумажная работа; он решает, может ли проект вообще существовать.