← Справочные архитектуры / reference-architecture / architectures

Знакомство с развёртыванием Email Security

Электронная почта остаётся жизненно важным способом общения между людьми и организациями. Именно поэтому она стала идеальным каналом для злоумышленников, которые пытаются захватить учётные записи, украсть данные и получить доступ к внутренним системам. Способность снижать объём спама и противостоять фишингу и вредоносному ПО критически важна для безопасности организации. Более 90% инцидентов кибербезопасности начинаются с атаки через электронную почту.

Сервис Cloudflare Email security является ведущим на рынке решением, которое можно развернуть разными способами в соответствии с потребностями каждой организации. В этом документе описаны различные методы развёртывания Email security и причины выбора той или иной модели.

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

Cloudflare Email security предлагает комплексный набор инструментов и технологий для защиты вашей почтовой инфраструктуры от широкого спектра угроз. Внедрив Cloudflare Email security, вы значительно повышаете уровень защищённости организации и снижаете риски, связанные с атаками через электронную почту.

Эта эталонная архитектура подробно рассматривает развёртывание и настройку Cloudflare Email Security для повышения уровня защиты почты. В ней подробно разбираются ключевые компоненты и лучшие практики, обеспечивающие бесперебойную интеграцию этого решения в существующую ИТ-инфраструктуру.

Эта эталонная архитектура предназначена для ИТ-специалистов и специалистов по безопасности, которые рассматривают Cloudflare для защиты отдельных аспектов своего бизнеса. Она ориентирована на широкую аудиторию, в том числе:

• Специалисты по ИТ-безопасности: Инженеры по безопасности, архитекторы и администраторы, отвечающие за проектирование, внедрение и поддержку решений для защиты электронной почты.
• Сетевые инженеры: Сетевые инженеры, отвечающие за сетевую инфраструктуру и почтовые шлюзы.
• Облачные архитекторы: Облачные архитекторы, которые проектируют и внедряют облачные решения для защиты электронной почты.
• Руководители, принимающие решения в сфере безопасности и ИТ: Менеджеры и руководители, которым нужно разбираться в технических аспектах защиты электронной почты для принятия обоснованных решений.

Независимо от того, являетесь ли вы опытным специалистом по безопасности или только начинаете знакомиться с безопасностью электронной почты, этот документ даст вам необходимую информацию для эффективного развёртывания Cloudflare Email Security и управления им.

Чтобы глубже разобраться в Cloudflare, рекомендуем следующие материалы:

• Что такое Cloudflare? | Сайт ↗ (пять минут на чтение) или Видео ↗ (две минуты)
• Cloudflare Blog ↗ | Email security ↗ и Фишинг ↗
• CISA | Рекомендации по фишингу: остановка цикла атаки на первом этапе ↗

К концу этого документа по эталонной архитектуре вы узнаете, как Cloudflare защищает вашу электронную почту и какие моменты следует учитывать при выборе способа развёртывания. Вы познакомитесь с конкретными компонентами, технологиями и конфигурациями, используемыми в решении Cloudflare Email Security. Сюда входит то, как оно интегрируется с существующей инфраструктурой электронной почты и использует облачные сервисы.

Cloudflare Email security представляет собой современный подход к борьбе с фишинговыми атаками. Решение Cloudflare построено на технологиях AI и Machine Learning с использованием эластичных сервисов, а также опирается на обширную сеть анализа угроз Cloudflare. Cloudflare Email security изначально создавался как единственный по-настоящему облачный эластичный сервис с общей аналитикой и Обучение с учителем (Supervised ML) ↗ подходит для любого способа развёртывания, доступного для электронной почты. Однако выбор правильной модели развёртывания крайне важен для того, чтобы получить максимальную выгоду от защиты почты.

В этом документе рассматриваются следующие способы развёртывания и случаи их применения:

• Inline или MX
• Интеграция с Microsoft 365 API
• Журналирование или BCC с автоматическим перемещением
• Смешанное развёртывание

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

• Pre-delivery устранение позволяет настраивать способ доставки сообщений, добавляя текст к теме или телу письма и применяя перезапись URL к Cloudflare Remote Browser Isolation, и доставки сообщений в папку со спамом или в почтовый карантин на стороне получателя. Это позволяет проектировать систему с учетом конкретного пользовательского опыта.
• Мы можем удалять сообщения до того, как их обработают системы приема почты, такие как ServiceNow или решения для архивирования.
• Мы устраняем риск проблем с временем ожидания, возникающих из-за разницы между доставкой сообщения во входящие и его перемещением оттуда.
• Мы поддерживаем смешанные развертывания, например сочетание Microsoft 365 и Microsoft Exchange или Microsoft 365 и Google Workspace.

Если эти потребности для вас не важны или вы уже используете многоуровневую защиту без другого API-решения, наш метод на основе API развертывается быстро и эффективно, без изменений в потоке вашей почты. Если вы хотите получить преимущества API без риска API Throttling, лучшим выбором станет Journal/BCC, поскольку этот метод приема данных не использует вызовы API. Однако если вам нужна защита на уровне развертывания MX в сочетании с преимуществами API для внутренней переписки, оптимальным вариантом будет наше смешанное развертывание.

Если ваши потребности изменятся, вы сможете гибко перейти на другой способ развёртывания, не приобретая наше решение заново. Единственное ограничение в том, что клиенты с лицензиями Advantage и CyberSafe могут использовать только развёртывание Inline, тогда как лицензия Enterprise открывает доступ ко всем возможностям.

Прежде чем остановиться на конкретном варианте развёртывания, Cloudflare рекомендует рассмотреть все доступные варианты, оценить свои потребности и при необходимости проконсультироваться со своей командой по работе с аккаунтом.

При развертывании Inline вся почта, адресованная одному или нескольким доменам, фильтруется через Cloudflare прежде, чем попасть во входящие пользователя. Cloudflare можно развернуть в любой точке цепочки обработки почты. При развертывании в качестве первого хоп, необходимо изменить MX-записи DNS домена так, чтобы они указывали на Cloudflare. Если вы хотите, чтобы Cloudflare проверял сообщения после существующего SEG (Secure Email Gateway), Cloudflare можно добавить как промежуточный узел в цепочке обработки, после чего он будет передавать обработанные сообщения дальше по цепочке. На основе политик сообщения блокируются и (или) помещаются в карантин, если они помечены как Spam, Malicious, Bulk и другие.

На диаграмме выше показано следующее:

1. Письмо поступает в Cloudflare на основании Записи MX ↗.
2. Cloudflare проверяет тело письма, заголовок и вложения и назначает соответствующий статус:
   • Malicious
   • Спам
   • Bulk
   • Suspicious
   • Спуфинг
   • Чисто
3. Примените любую политику, например разрешение или блокировку определённых доменов.
4. Помещение писем с высоким риском в карантин
5. Все сообщения, получившие статус обработки от Cloudflare будет содержать заголовок X-CFEmailSecurity-Disposition добавляется. Этот заголовок могут использовать нижестоящие системы для применения особой обработки (перенаправление, внешний карантин и другое).
6. Пересылать весь корректный почтовый трафик.
7. К сообщениям можно применять изменения темы и (или) текста, чтобы добавить конечному пользователю видимую информацию о статусе их обработки.

С точки зрения безопасности предпочтительным способом развёртывания является Inline, поскольку он проверяет каждое письмо и не допускает попадания вредоносного содержимого во входящие пользователя. Это полностью исключает риски для пользователей.

• Сообщения обрабатываются и блокируются до доставки в почтовый ящик пользователя.
• Развёртывание Inline позволяет изменять сообщение, добавляя пометки в тему или тело письма, например дописывая [SPAM] или [EXTERNAL SPAM] в тему.
• Обеспечивает высокую доступность и адаптивное накопление сообщений: Cloudflare продолжает принимать входящие письма в очередь, даже когда последующие сервисы недоступны. Когда эти сервисы снова становятся доступны, доставка сообщений из очереди возобновляется.
• Сообщения с назначенным статус обработки которые не помещены в карантин, получают X-header которые могут использоваться для расширенной последующей обработки.
• Совместимо со всеми почтовыми системами, включая Microsoft Exchange On-Prem, Postfix, Lotus Notes, Google Workspace, Microsoft 365 и другие.

Перед развёртыванием Email security через Inline необходимо учесть следующее:

1. Microsoft не поддерживает схемы развертывания, при которых почта сначала поступает в Microsoft Exchange или Microsoft 365, затем перенаправляется в решение для защиты почты через правила потока обработки почты для сканирования и устранения угроз, а после этого возвращается обратно в Microsoft 365. Хотя Cloudflare технически способен поддерживать такое развертывание, оно создает проблemы с атрибуцией (определением исходного отправителя) и доставкой.
2. Если Cloudflare будет выступать в роли MX, потребуются изменения в DNS. При наличии большого числа доменов необходимо обновить каждую DNS-зону.
3. Развёртывание Inline может усложнить архитектуру SMTP, если Cloudflare не развёрнут в качестве MX, например при развёртывании Inline за традиционным SEG (Mimecast/ProofPoint).
4. Развёртывание Inline может потребовать дублирования политик сразу в нескольких решениях и в MTA. Например, Cloudflare, SEG и MTA заметно по-разному обрабатывают разрешающие политики, и для одного и того же сообщения может потребоваться настройка исключений во всех них.
5. В многоуровневом развёртывании некоторые поставщики, например Mimecast и Barracuda, могут работать только в качестве MX. В этом случае Cloudflare Inline настраивается за этими поставщиками.
6. При использовании Mimecast рекомендуется отключить URL Rewriting, поскольку эта функция не позволяет Cloudflare декодировать и сканировать URL-адреса. Если эта функция остаётся включённой, возможности перехода по ссылкам ограничиваются оценкой репутации и возраста домена.

Cisco предлагает уникальную возможность интеграции с Cloudflare: коннектор в роли MX или размещение за Cloudflare по поддерживаемой схеме Hairpin. Во всех остальных отношениях это развёртывание работает так же, как Inline. См. разделы Cisco as MX Record и Cisco - Email security as MX Record.

Альтернативный подход заключается в интеграции через Graph API в Microsoft 365. В этой модели письма доставляются напрямую во входящие пользователя, после чего Cloudflare получает копии сообщений, сканирует их и перемещает в соответствии с настройками статус обработки.

Это выполняется путём подписки на все почтовые ящики пользователей в авторизованных доменах. В процессе авторизации можно выбрать область действия: только папка Inbox или все папки. При доставке письма в ящик подписка запускает в Microsoft 365 действие, которое отправляет Cloudflare копию письма для сканирования и присвоения вердикта. После присвоения вердикта наше решение проверяет auto-move политику и выполнить нужное действие.

На диаграмме выше показано следующее:

1. Письмо доставляется непосредственно во входящие пользователя через существующий маршрут.
2. Cloudflare получает сообщения для проверки через API почтового провайдера. Cloudflare проверяет тело письма, заголовок и вложения и назначает соответствующий статус:
   • Malicious
   • Спам
   • Bulk
   • Suspicious
   • Спуфинг
   • Чисто
3. Примените любую политику, например разрешение или блокировку определённых доменов.
4. В решении Cloudflare сообщения перемещаются согласно политике. Доступны следующие действия:
   • Входящие
   • Спам
   • Корзина
   • Мягкое удаление (восстанавливается пользователем)
   • Hard Delete (Admin Recoverable)

В обычных условиях этот процесс занимает менее 2-3 секунд от доставки письма во входящие до отправки запроса на перемещение. Google и Microsoft 365 не предоставляют SLA на срок выполнения этого действия. Если перемещение не удалось, наше решение повторяет попытку много раз с интервалом в пять минут.

• Простой способ добавить защиту в сложных архитектурах электронной почты без изменения работы почтового потока.
• Развёртывание без агента для Microsoft 365.
• Microsoft 365 Defender/ATP обрабатывает сообщение первым.
• Этот метод можно использовать для Proof of Value: сбора данных о письмах и отчётности без изменения потока почты. В этом сценарии политику устранения последствий стоит оставить ненастроенной, чтобы никакие действия не выполнялись.

Перед развёртыванием Email security через Развертывание API, необходимо учесть следующее:

• В зависимости от API-инфраструктуры сбои и технические окна Microsoft 365 или Google увеличивают время нахождения писем во входящих, поскольку сканирование и устранение угроз становится возможным только после доставки письма пользователю. Это ограничение характерно для всех поставщиков API.
• Microsoft 365 может ограничивать частоту запросов к Graph API отдельно для каждого сервиса. Mail API в составе Graph относится к разделу Outlook Services. Злоумышленник может использовать эти ограничения, чтобы фактически отключить любое развёртывание на основе API и получить тем самым дополнительное окно для атаки. Ограничения следующие:
  • 10,000 запросов API за период 10 минут
  • Четыре одновременных запроса
  • 150 мегабайт (MB) при загрузке (PATCH, POST, PUT) за период пять минут
  • См. Ограничения службы Outlook ↗
• На Gmail API распространяется суточный лимит использования, который применяется ко всем запросам от вашего приложения, а также лимиты скорости для каждого пользователя. Каждый лимит выражается в квотных единицах, то есть в абстрактных единицах измерения использования ресурсов Gmail. Основные лимиты запросов описаны ниже:
  • Ограничение скорости на одного пользователя составляет 250 единиц квоты в секунду (скользящее среднее значение, допускающее кратковременные всплески).
  • Использование квоты по методам определяется количеством единиц квоты, которое расходует запрос в зависимости от вызываемого метода.
  • Например, messages.get и messages.attachments.get расходуют пять единиц квоты. См. Использование квоты по методам ↗
• Требует доступа на чтение и запись к почтовым ящикам, а некоторые команды безопасности или администраторы почты такой доступ не разрешают.
• Полноценную поддержку API имеет только Microsoft 365. Google поддерживает исправление через API, но для доставки писем на сканирование по SMTP все равно требует правило соответствия (Compliance Rule). Локальный Exchange требует PowerShell и не имеет API для автоматического перемещения писем.
• Согласно требованиям Microsoft 365/Google сообщения нельзя изменять после доставки. Это значит, что мы не можем выполнять URL Rewriting в Cloudflare изоляция ссылок в электронной почте или добавлять текст в тему или в текст письма. Эти функции доступны только при развёртывании Inline.

Развёртывание BCC/Journaling очень похоже на развёртывание API и отличается только способом доставки писем в Cloudflare. Как и при использовании API, письмо сначала доставляется в почтовый ящик, но одновременно к нему добавляется адрес электронной почты, привязанный к конкретному аккаунту, поэтому копия письма передаётся в Cloudflare по SMTP для проверки.

Как только Cloudflare получает письмо, он сканирует его и определяет статус обработки письма. После того как письму присвоен статус, наше решение проверяет авторизации API и auto-move политику и выполнить нужное действие. Этот метод менее подвержен риску ограничения частоты запросов к API, поскольку API Microsoft 365 и Google используются только для устранения проблемных писем.

На этапе пилотного проекта такое развёртывание можно настроить с любым решением для защиты почты или почтовой платформой, которая поддерживает добавление получателя в копию (BCC). Это даёт представление о том, какие угрозы пропускают другие решения, но блокирует Cloudflare.

• Простой способ добавить защиту в сложных архитектурах электронной почты без изменения работы почтового потока.
• Развёртывание без агента для Microsoft 365. Microsoft 365 передаёт письма в Cloudflare после их доставки, а авторизацию API можно настроить с помощью политики Remediation, чтобы перемещать письма с определённым вердиктом за пределы папки «Входящие».
• Google использует Compliance Rules для BCC, которые можно комбинировать с API Authorization для перемещения писем после доставки. Это дает тот же результат, что и развертывание через API, описанное выше.
• Microsoft 365 и Google обрабатывают сообщение первыми. Это обеспечивает более многоуровневый подход, задействуя возможности безопасности Microsoft 365/Google в дополнение к Cloudflare.
• Вы можете задавать область проверяемых сообщений (внешние, внутренние или оба варианта)
• Этот метод можно использовать для Proof of Value: сбора данных о письмах и отчётности без изменения потока почты. Авторизация API для этого не требуется. Если API настроен для Microsoft 365 или Google, политику Remediation стоит оставить ненастроенной, чтобы никакие действия не выполнялись.

Перед развёртыванием Email security через BCC/Journaling необходимо учесть следующее:

• Те же ограничения, что и у API.
• Зависит от Google или Microsoft 365 для доставки сообщений через SMTP.
• Может потребоваться Connector в Microsoft 365 для обеспечения прямой связи.
• Согласно требованиям Microsoft 365/Google сообщения нельзя изменять после доставки. Это значит, что мы не можем выполнять URL Rewriting в Cloudflare Email Link Isolation или добавлять текст в поле Subject или Body письма. Эти функции доступны только при развёртывании Inline.

Смешанный вариант использует развёртывание Inline для внешних писем и BCC/Journaling для внутренних. Для этого применяются оба метода развёртывания, а Cloudflare настраивается на два хопа в режиме BCC/Journal. Такой сценарий даёт все преимущества доставки через MX для внешних сообщений, а также позволяет устранять вредоносные письма из внутренних источников. Вот несколько сценариев, где это полезно.

Смешанное развёртывание объединяет преимущества Inline-развёртывания для внешней почты и BCC/Journaling для внутренней.

При выборе смешанного развёртывания необходимо учитывать следующее:

• Обнаружение угроз во внутренних письмах ограничено из-за нехватки данных, таких как аутентификация письма, сервер отправки и путь доставки. Анализировать можно только содержимое тела письма.
• При использовании функции Protecting Users с реестром имперсонации во внутренних письмах возможно увеличение количества ложных срабатываний.

Cloudflare предлагает автоматизированные процессы на основе непрерывного анализа и пользовательских обращений. Эти функции позволяют Cloudflare перемещать сообщения с помощью API auto-move политику после доставки. Это лучше всего сочетается с отправкой сообщений о фишинге или сторонними отправками пользователей.

Cloudflare отдает приоритет обращениям администраторов (Administrator Submissions) о ложных срабатываниях и пропусках, отправленным через дашборд Cloudflare. Такой подход ускоряет рассмотрение и помогает Cloudflare заранее выявлять и устранять проблемы, которые могут затрагивать многих пользователей, улучшая продукт в целом. Администраторам рекомендуется просматривать обращения пользователей, находить все связанные сообщения и отправлять их через дашборд Cloudflare как подтвержденные ложные срабатывания или пропуски. Эти обращения будут рассмотрены и в дальнейшем использованы для улучшения моделей машинного обучения, механизмов обнаружения и движков.

Подытожим: Email Security предлагает три основные модели развёртывания: API, BCC/Journaling и Inline (или MX). Inline является предпочтительной моделью, поскольку она фильтрует и обезвреживает вредоносные сообщения до того, как они попадут в почтовый ящик пользователя, устраняя риск времени пребывания угрозы в системе и позволяя использовать такие функции, как URL Rewriting и изменение сообщений.

Модели API и BCC/Journaling представляют собой решения, работающие после доставки: они напрямую интегрируются с такими платформами, как Microsoft 365 или Google Workspace, для проверки и auto-move письма уже после того, как они попали в почтовый ящик пользователя. Такие методы постобработки проще внедрить и не требуют изменений в потоке почты, но у них есть ограничения: риск троттлинга API и невозможность изменить содержимое сообщения, например тему или текст письма.

И наконец, смешанное развёртывание сочетает преимущества Inline для защиты внешней почты (что критично для систем вроде CRM или тикет-систем, принимающих почту) с BCC/Journaling для проверки внутренней почты.