Forwarded, исходный IP и приватность в цепочке прокси
RFC 7239 стандартизирует заголовок Forwarded для передачи сведений, которые теряются при проксировании. Эти сведения чувствительны, поэтому включать их следует осознанно.
Главное за минуту
- Forwarded доверяют только в контролируемой цепочке.
- Для диагностики часто достаточно псевдонимного correlation ID.
- Edge заново формирует заголовок вместо доверия внешнему значению.
- Передавайте только параметр, необходимый конкретному потребителю.
Какие данные передаются
Параметры for, by, host и proto могут раскрывать адрес клиента, интерфейс прокси, исходный host и схему соединения.
Сначала определите, какой компонент действительно использует for, by, host или proto и для какого решения. Если приложению нужна только исходная схема для redirect, не передавайте полный клиентский адрес. Для расследований часто достаточно correlation ID и записи на доверенном edge. Документируйте направление цепочки, формат IPv6 и поведение при неизвестном или обфусцированном идентификаторе.
Подмена клиентом
Внешний клиент способен сам прислать заголовок. Граничный прокси должен удалить недоверенное значение или сформировать новую проверяемую цепочку.
На внешней границе удаляйте Forwarded и эквивалентные X-Forwarded-* от недоверенного клиента, затем формируйте собственное значение. Внутри разрешайте добавление только известным proxy hops с аутентифицированным соединением. Приложение должно доверять ограниченному числу узлов и читать цепочку по документированному правилу; слепое принятие первого адреса позволяет подменить аудит и правила доступа.
Минимизация
Передавайте только параметры, необходимые конкретной функции. Стандарт допускает обфусцированные идентификаторы для трассировки без раскрытия внутренней структуры.
Если точный IP не нужен после оперативного окна, заменяйте его устойчивым псевдонимным идентификатором с отдельным защищённым ключом либо агрегируйте до сети, если это соответствует цели. Псевдонимизация не всегда выводит данные из режима персональных, поэтому основание и защита остаются необходимыми. Не добавляйте адрес в клиентские ответы, telemetry tags и сообщения об ошибках.
Срок и доступ
Если IP попадает в журнал, укажите цель, круг доступа и срок хранения. Экспортируйте его только при наличии установленного основания.
Для каждой копии IP укажите хранилище, круг ролей, поиск, экспорт и автоматическое удаление. Полный адрес в краткосрочном security-журнале и агрегированная статистика могут иметь разные сроки. Перед новым использованием, например для маркетинговой аналитики, заново оцените цель и основание. Актуальные правовые требования и договорные обязанности проверяйте до запуска функции.
Практический чек-лист
- 1Определите доверенные proxy hops.
- 2Удаляйте входные недоверенные заголовки.
- 3Передавайте минимальный набор параметров.
- 4Проверьте доверенный hop count и порядок чтения.
- 5Удалите IP из telemetry tags и ошибок.
Источники и документы
Материал подготовлен по первичным, официальным и техническим источникам. Формулировки статьи являются самостоятельным изложением.
Материал носит справочный характер. Требования необходимо сверять с актуальной редакцией закона и, при необходимости, с профильным специалистом. Это не индивидуальная юридическая консультация.