Forward наружу только явно: Remote Domain, outbound policy и журнал, не «разрешите всем Gmail»

Короткий ответ

Внешняя автопересылка по умолчанию должна быть запрещена. Разрешайте точечно: конкретный домен партнёра / конкретный ящик, с заявкой, владельцем и датой пересмотра. Инструменты: политика исходящего auto-forwarding (Defender / outbound spam), RemoteDomain (AutoForwardEnabled), транспортные правила с аудитом, запрет пользователю ставить ForwardingSmtpAddress без роли. После настройки — инвентарь существующих forwards и алерт на новые. Не открывайте * на Gmail «для удобства дирекции». Не путайте с делегированием и shared mailbox внутри тенанта — они безопаснее для «секретарь читает».

Сначала прочитайте, что уже течёт: статья риск переадресации.

Симптомы и как отличить

Нужна эта инструкция, если:

• security хочет запрет, бизнес — исключения;
• уже словили скрытый forward;
• миграция с on-prem, где forward был нормой.

Отличия: ручная пересылка одного письма кнопкой Forward — не auto-forward. Auto — правило/свойство ящика/транспорт, срабатывает на каждое входящее.

Возможные причины хаоса

1. Default Remote Domain AutoForwardEnabled $true.
2. Outbound policy Automatic/On на весь мир.
3. Helpdesk ставит forwarding как «доступ подрядчику».
4. Нет аудита mailbox.
5. Исключения CA/legacy, через которые ставят правила боты.

Диагностика (as-is)

Connect-ExchangeOnline -UserPrincipalName admin@contoso.example
Get-RemoteDomain | Format-Table DomainName, AutoForwardEnabled, AutoReplyEnabled
Get-HostedOutboundSpamFilterPolicy | Format-List Name, AutoForwardingMode, *Notify*
Get-Mailbox -ResultSize Unlimited |
  Where-Object { $_.ForwardingSmtpAddress -or $_.ForwardingAddress } |
  Select-Object UserPrincipalName, ForwardingSmtpAddress, DeliverToMailboxAndForward

Выгрузите inbox rules с внешними ForwardTo батчами (не убейте троттлинг). Список — приложение к приказу о политике.

Проверьте, включён ли mailbox audit / unified audit на Set-Mailbox и rules.

Решение

1. Политика: deny default

Зафиксируйте письменно: автофорвард наружу запрещён, исключения по заявке.

Выключите auto-forward на Default Remote Domain, если это соответствует вашей версии/модели (проверьте эффект на test-ящике). Настройте outbound spam auto-forwarding: Off для всех, затем Allow для известных.

Не делайте оба слоя противоречиво (один On, другой Off) без теста — получите «то 520, то утечка».

2. Точечный allow

Варианты, от узкого к широкому:

A. Конкретные ящики — транспортное правило: if sender is tickets@contoso.example then allow redirect to support@fabrikam.example, с Copy to audit mailbox внутри тенанта.

B. Remote domain fabrikam.example с AutoForwardEnabled $true, остальные false. Подходит, когда партнёр целый домен и вы ему доверяете на уровне MX.

C. Outbound policy exception для группы «approved forwarders».

Каждый allow: владелец, тикет, review date.

3. Роли Helpdesk

Не давайте всем Recipient Management право менять forwarding без контроля. Отдельная роль / заявки.

4. Замена форварда

Подрядчик: shared mailbox + Full Access, гостевой доступ, отдельный ящик в вашем тенанте. Сотрудник в отпуске: делегирование, не личный mail.ru.

5. Аудит и алерт

Unified Audit: операции forwarding/rules. Еженедельный скрипт сравнения списка ForwardingSmtpAddress с «реестром исключений». Любой новый внешний адрес — инцидент до доказательства заявки.

# Сверка с «известным списком» — ведите CSV в тикетной, не в голове
Get-Mailbox -ResultSize Unlimited |
  Where-Object { $_.ForwardingSmtpAddress } |
  Export-Csv C:\Temp\forwarding-snapshot.csv -NoTypeInformation

Храните C:\Temp не как систему записи; это пример выгрузки на админской станции.

В тенанте contoso.onmicrosoft.com пилот: ящик ivan.petrov@contoso.example без исключения пытается inbox Redirect на внешний адрес — ожидайте отказ политики. Ящик тикетницы в allow-листе — тестовое входящее должно породить копию на партнёра и запись в аудите. Если копия ушла, а аудита нет — включите mailbox audit / unified audit до объявления «готово».

Не смешивайте journal (compliance) с auto-forward. Journal пишет в выделенный ящик внутри контура. Forward на lawyer@gmail.com — не journal, это исключение безопасности и обычно запрещено.

Remote Domain для fabrikam.example не открывает gmail. Документируйте MX партнёра, чтобы завтра «ещё один домен того же вендора» не пролез без заявки.

Как проверить, что проблема устранена

1. Пользователь без исключения: inbox rule на внешний → письмо не уходит, есть NDR/политика (зафиксируйте код у вас).
2. Исключённый поток (тикетница) доходит.
3. Снапшот forwarding = реестр.
4. Тестовый «злоумышленник» (ваш второй ящик) не может тихо включить forward без появления в аудите.

Message Trace на тест: нет скрытого второго recipient у обычных пользователей.

Если не помогло

• Тикетница всё ещё 5.7.520: она не в allow, или шлёт не auto-forward, а SMTP сами. Смотрите коннектор.
• Правила Outlook client-only обходят серверную политику частично: усиливайте запрет + MDM + обучение. Ищите клиентские правилами выборочно.
• Гибрид: on-prem transport forward не виден облачной outbound policy. Чините оба контура.
• DMARC на стороне получателя режет ваши форварды — ожидаемо, см. DMARC. Не лечите это +all.

Профилактика

• Onboarding: «gmail не архив».
• Offboarding: снять все forwards (увольнение + сессии по смыслу revoke).
• PIM на тех, кто может ставить transport rules.
• После инцидента — не возвращать AutoForward On globally.

FAQ

Пользователь переслал одно письмо руками — это запрещаем?

Обычно нет. Речь про автоматическое копирование потока. DLP может ограничить и ручное, если данные чувствительные — отдельная политика.

Нужен ли journal на внешний ящик юриста?

Юридический журнал — внутрь compliant archive (EO Archive / третья система), не на личный Gmail юриста.

Outlook «Redirect» vs «Forward»

Redirect сохраняет заголовки, Forward — как новое. Оба утекают. Политика должна крыть оба, где возможно.

Можно ли разрешить только VIP?

VIP чаще цель BEC. Лучше дать им делегата и MDM, не VIP-исключение на gmail.

Кто владелец allow-записи?

Именной менеджер процесса (например владелец тикетницы), не «IT». IT — исполнитель контроля.

5.7.520 на легитимном исключении

Проверьте, что политика смотрит тот же механизм (mailbox vs rule vs transport). Часто разрешили Remote Domain, а режет outbound spam, или наоборот.