Статический allow-list: белый список без иллюзий
Цикл «Не светим лишнего». Выпуск 4.
Если у нас есть офис со статическим внешним адресом, открыть ему доступ к корпоративной панели проще простого: добавили IP в allow-list, сделали правило и забыли. Иногда это действительно лучший вариант.
Статический список хорошо подходит площадкам, филиалам, собственным серверам, внешним API и известным шлюзам. В нём мало движущихся частей, нет отдельного портала и нечему разъехаться по времени.
Но белый список часто начинают воспринимать как список пользователей. А это уже ошибка.
Что видит firewall
Firewall видит исходный адрес пакета после всех внешних NAT. Если в офисе двести человек выходят через один публичный IP, для нашего периметра это один источник. Если подрядчик включил корпоративный VPN, мы увидим адрес выхода этого VPN. Если мобильный оператор использует CGNAT, рядом с нашим инженером под тем же IP могут находиться другие абоненты.
Поэтому запись 198.51.100.27 -> allow означает только одно: любой подходящий трафик, пришедший с 198.51.100.27, проходит это условие. Кто его отправил — решает уже следующий слой.
Где статический список уместен
- межплощадочный доступ между собственными фиксированными адресами;
- внешний сервер, который обращается к нашему API;
- корпоративный VPN-шлюз, где пользователь уже аутентифицирован отдельно;
- bastion или jump host с контролируемой конфигурацией;
- мониторинг с известной площадки;
- временно — известный адрес подрядчика, если есть процесс удаления.
Для людей с домашним динамическим Интернетом схема уже менее приятная. Сегодня адрес один, завтра другой. Администратор каждый раз лезет в правила, а старую запись обычно никто не удаляет.
Плюсы
- очень простая реализация;
- работает с любыми протоколами;
- легко увидеть и проверить;
- не требует действий от пользователя;
- хорошо сочетается с дополнительной авторизацией ресурса;
- почти не зависит от внешних сервисов.
Минусы
- IP не равен пользователю;
- общий NAT расширяет круг фактически допущенных клиентов;
- динамические адреса меняются;
- списки копят устаревшие исключения;
- при передаче адреса другому абоненту доверие может перейти вместе с ним;
- IPv4 и IPv6 приходится учитывать отдельно.
Где можно больно ошибиться
Разрешить адрес прокси по заголовку. Если приложение берёт X-Forwarded-For от любого клиента, злоумышленник просто напишет туда нужный IP. Сетевой firewall использует настоящий адрес соединения; веб-приложение должно доверять заголовкам только от своих reverse proxy.
Разрешить слишком широкую сеть. Подрядчик дал /24, потому что «у нас адреса могут меняться». Это уже 256 возможных источников, владельцев которых мы не контролируем.
Не вести владельца и срок. У каждой записи должны быть комментарий, ответственный, причина и дата пересмотра. trusted-temp-2 без истории через год никто не удалит.
Забыть про доступ в обход. Если HTTP закрыт по IP на reverse proxy, но backend доступен напрямую на другом адресе, вся конструкция бессмысленна.
Как сделать статические списки терпимыми
Я бы разделил их минимум на три класса: собственные площадки, системные интеграции и человеческие исключения. Первые два пересматриваются по инвентаризации. Третий класс лучше вообще не делать постоянным: выдавать запись с timeout или управлять ею через портал.
Следующий выпуск как раз про это — тот же allow-list, но с коротким сроком жизни, журналом и нормальным отзывом.
Ранее в цикле
- 2. Firewall без магии: закрыть всё и открыть ровно нужное
- 3. VPN: хороший инструмент, но не универсальный ответ