IP-allowlist (список разрешённых адресов)

IP-allowlist — это правило, которое принимает трафик только с перечисленного набора адресов-источников и отбрасывает всё остальное. В SaaS он встречается в двух направлениях, и их постоянно путают. На входе клиент ограничивает, кто вправе вызывать его API или открывать его админку, и просит у вашего продукта список адресов, с которых пойдут ваши исходящие вызовы. На выходе уже ваш продукт ограничивает, каким адресам разрешено достучаться до приватного эндпоинта или внутренней поверхности. И то и другое — грубые меры: адрес не является личностью, и всякий, кто способен отправлять трафик с разрешённого адреса, наследует это право. Неудобство современного SaaS в самом обещании постоянных адресов-источников. Бессерверные платформы, автоматически масштабируемые воркеры и управляемые потребители очередей не гарантируют фиксированный исходящий адрес: пул меняется вместе с масштабированием провайдера, и брандмауэр клиента начинает тихо отбрасывать ваши вебхуки. Поставщики, которым это обещание всё же нужно, пропускают исходящий трафик через небольшой набор выделенных адресов или через прокси-слой, публикуют их и дальше относятся к ним как к интерфейсу: менять их — ломающее изменение, требующее уведомления, ровно как смена контракта API. Ломаются списки тоже обманчиво: пакет, отброшенный на брандмауэре клиента, не даёт ошибки у него и даёт тайм-аут у вас, поэтому сбой остаётся невидимым, пока кто-нибудь не сопоставит одно с другим. Поэтому allowlist лучше работает как один слой из нескольких, а не как история про аутентификацию: сочетайте его с подписанным запросом или клиентским сертификатом, чтобы адрес сужал поверхность атаки, а кто именно звонит — доказывала криптография. Публикуйте адреса там, где клиент может подписаться на изменения, и никогда не добавляйте новый молча.