Хорошая безопасность — это многоуровневая система, где каждый слой выполняет свою задачу, недоступную другим. Ограничение токена рамками сервера ограничивает его область действия. Ротация токена ограничивает время его жизни. Но ни то, ни другое не говорит о том, откуда пришел запрос.
Мы усердно работали над созданием нового уровня защиты, который может это сделать.
IP Allowlisting — это новая функция безопасности Postmark, которая позволяет указать инфраструктуру, с которой должна отправляться ваша почта. Она уже доступна во всех тарифных планах Postmark без дополнительной оплаты. По умолчанию она отключена, пока вы ее не активируете.
Как работает IP Allowlisting #
Вы добавляете до 10 диапазонов IP-адресов в формате CIDR, которым разрешено отправлять электронную почту с использованием API Postmark. Запросы на отправку из-за пределов этих диапазонов отклоняются с кодом состояния 403, который включает IP-адрес, с которого пришел запрос.
Вы можете настроить диапазоны в двух местах:
На уровне сервера. Диапазоны применяются к этому серверу, охватывая все потоки сообщений (Message Streams) на нем. Мы рекомендуем начинать именно с этого.
На уровне вашей учетной записи. Диапазоны применяются к каждому серверу, который у вас есть. Если у сервера есть собственные диапазоны, они будут иметь приоритет над настройками уровня учетной записи.
Вот и все! Простой и понятный инструмент безопасности для защиты вашей отправки через API. Защищайте отдельные серверы или всю учетную запись целиком.
Если вы редко работаете с блоками CIDR, потребуется всего 30 секунд, чтобы разобраться с ними и правильной нотацией. Блоки CIDR позволяют включить сгруппированную коллекцию IP-адресов (так называемые диапазоны). Блок CIDR — это IP-адрес, за которым следует суффикс, указывающий, сколько адресов он охватывает. Чем меньше суффикс, тем шире диапазон:
Таким образом, /32 привязывает белый список к одной машине, а /24 охватывает подсеть. Большинство команд в конечном итоге используют значения в этом диапазоне.
Где найти свои диапазоны, зависит от того, как вы отправляете почту. Отдельная виртуальная машина имеет статический публичный IP-адрес, который можно узнать в панели управления вашего провайдера. Облачные рабочие нагрузки за NAT-шлюзом отправляют запросы с адресов шлюза, а не с отдельных экземпляров. Локальная инфраструктура отправляет почту с того выхода, который настроила ваша сетевая команда, и они будут знать его.
Важен именно тот IP-адрес, с которого фактически приходят ваши API-запросы, и это не всегда тот адрес, о котором вы думаете. Если вы не уверены, заблокированный запрос подскажет вам: ответ 403 включает IP-адрес, который зафиксировал Postmark.
Подходит ли вам IP Allowlisting? #
Белые списки оправдывают себя, когда отправка через API осуществляется с известного, стабильного набора IP-адресов. Это могут быть ваши собственные серверы, фиксированный облачный выход или управляемый NAT-шлюз. Если вы можете назвать IP-адреса, с которых должна приходить ваша почта, вы можете отклонить все остальные.
Это особенно подходит, если вы отправляете почту от имени своих клиентов, работаете в рамках режима соответствия требованиям, который предполагает наличие сетевых средств контроля, или выполняете отправку из инфраструктуры, которая уже управляется командой безопасности.
Если ваши IP-адреса для отправки часто меняются или их невозможно перечислить — например, бессерверные вычисления без уровня NAT, масштабируемые группы без фиксированного выхода, отправка, инициируемая CI-раннерами — белый список будет работать против вас. Вам придется постоянно обновлять диапазоны, и любой пропущенный диапазон заблокирует вашу собственную почту. В этом случае это не подходящий инструмент, и оставить его выключенным — разумное решение.
Как включить его, не заблокировав собственную почту #
Режим сбоя здесь очевиден: диапазон, в котором отсутствует один из ваших собственных IP-адресов, блокирует вашу отправку. Две вещи помогут этого избежать.
Начните с более широкого диапазона, чем вам кажется нужным. Диапазон, который шире необходимого, все равно отклоняет все, что находится за пределами вашей инфраструктуры. Слишком узкий диапазон блокирует вас. Сужайте его, как только подтвердите, что именно отправляет запросы.
Протестируйте на сервере, от которого вы не зависите. Создайте тестовый сервер, добавьте туда свои диапазоны и отправьте на него запрос из вашей производственной среды. Если отправка проходит, значит, ваши диапазоны охватывают инфраструктуру, с которой вы действительно отправляете почту. Если нет, код 403 укажет IP-адрес, который вы упустили, и ничего критичного не произойдет.
Примечание: Как мы упоминали выше, начните с уровня сервера, а не с уровня учетной записи. Диапазоны учетной записи применяются ко всем серверам сразу, поэтому неполный диапазон повлияет на всю вашу отправку через API. Проверьте свои диапазоны на одном сервере, а затем расширяйте область действия.
Как только ваши диапазоны будут установлены, включите белый список. Никакие ограничения не действуют, пока вы этого не сделаете, и вы можете отключить его в любой момент — это также самый быстрый способ исправить ситуацию, если ожидаемая отправка была отклонена.
Полезно знать #
Несколько моментов, которые стоит учесть при настройке.
- Белые списки применяются только к конечным точкам отправки электронной почты. SMTP-отправки не проверяются по вашим диапазонам. Если вы не используете SMTP на сервере, его отключение добавит еще один уровень защиты. Ваши другие вызовы API — управление шаблонами, чтение статистики, обработка подавлений — работают с любого IP-адреса при наличии действительного токена; белый список — это контроль именно отправки.
- Он намеренно настраивается через пользовательский интерфейс. Отсутствие возможности изменять белый список через API добавляет еще один уровень контроля над тем, кто может влиять на настройки защиты вашей отправки.
- Каждый сервер и ваша учетная запись имеют свои собственные настройки. Если вы управляете большим парком серверов, установите диапазоны учетной записи по умолчанию и переопределяйте их только для тех серверов, которые отправляют почту из других мест.
Примечание: Белый список — это контроль на пути отправки Postmark, а не брандмауэр или WAF. Он решает, какие IP-адреса могут отправлять электронную почту через вашу учетную запись, и не меняет правила безопасности на сетевом уровне, которые стоят перед Postmark. IP-адрес в вашем белом списке все равно может быть заблокирован средствами защиты, находящимися вне пути отправки Postmark.
Мы уже думаем о том, что будет дальше, и команды, использующие эту функцию, помогут нам в этом. Если вам нужно, чтобы она делала что-то еще, сообщите нам.
Чем IP Allowlisting отличается от выделенных и общих IP-адресов #
Две разные вещи используют слово «IP» здесь, и их стоит различать.
Выделенные и общие IP-адреса относятся к адресу, с которого отправляется ваша почта — это идентификатор отправителя, который видят принимающие почтовые серверы, и то, к чему привязывается ваша репутация отправителя. Общие IP-адреса являются стандартными в Postmark: это тщательно проверенные пулы, которые позволяют начать отправку без необходимости «прогрева». Выделенные IP-адреса — это дополнение для отправителей с большими объемами.
IP Allowlisting относится к адресу, с которого приходят ваши API-запросы — это выход вашей инфраструктуры, а не инфраструктура отправки Postmark. Включение этой функции не меняет IP-адреса, с которых доставляется ваша почта, и не влияет на репутацию или прогрев.
Это также противоположность внесению IP-адресов Postmark в белый список внутри вашего собственного брандмауэра. Там вы решаете, что ваша сеть принимает от нас. Здесь вы решаете, что мы принимаем от вас.
Настройте это #
Если ваша отправка через API осуществляется с IP-адресов, которые вы можете назвать, настройка белого списка займет несколько минут и обеспечит реальное ограничение того, где может быть использован токен.
Настроить IP Allowlisting →
