Переадресация почты в Exchange и Microsoft 365: PowerShell, EAC и аудит

Меня зовут Семёнов Евгений Сергеевич, я директор АйТи Фреш. Переадресация почты — одна из тех задач, которая выглядит «легко-два-клика», а на практике вокруг неё крутится половина инцидентов утечек данных в малом и среднем бизнесе. За 15 лет я несколько раз помогал клиентам разбираться, как из их Exchange Server утекли коммерческие тайны через тихонько настроенную переадресацию на личный Gmail. В этой статье — всё, что я делаю, когда меня вызывают навести порядок в email-форвардингах: команды, политики, аудит и реальные кейсы.

Зачем вообще нужна переадресация и почему она опасна

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

• Отпуск или больничный. Менеджер уезжает на 3 недели — его почта переадресуется заместителю. Самое штатное использование, без него отдел встаёт.
• Увольнение сотрудника. Бывший сотрудник был ответственным за крупного клиента — все письма с его адреса автоматически уходят преемнику в течение 6–12 месяцев, чтобы клиент не «потерялся».
• Общие почтовые ящики. info@, sales@, support@ — фактически распределяющие группы или ящики с переадресацией на текущих ответственных.
• Интеграции. Helpdesk-система получает заявки через переадресацию с support@. CRM собирает обращения через input-ящик.

А вот сценарии, где переадресация — это уже про инциденты безопасности:

• Сотрудник настроил себе переадресацию ВСЕЙ почты на личный Gmail, чтобы «удобнее работать дома». При этом его персональный аккаунт компрометируется чаще корпоративного, и через два месяца уведомления от банка-клиента, тендерная переписка и контакты клиентов утекают на сторону.
• Уволенный сотрудник за неделю до увольнения настроил forwarding на личный адрес. Полгода после ухода продолжает получать всю переписку отдела — а вы не знаете.
• Скомпрометированный аккаунт. Хакер, получивший доступ к Outlook Web App, не сразу что-то делает — он молча настраивает Inbox Rule «всё пересылать на attacker@evil.com и удалять» — и месяцами тихо собирает данные.

В моей практике 4 из 7 кейсов «у нас утекли данные» в 2024–2025 году произошли именно через незаметные переадресации. Поэтому в любом аудите безопасности почты у клиента я первым делом смотрю — кто куда пересылает письма.

Способы переадресации: что выбрать в каком случае

В Exchange (что on-premises, что Microsoft 365) есть четыре механизма переадресации, и важно понимать разницу:

Главное правило, которое я внушаю всем своим клиентам — административную переадресацию делать ВСЕГДА через PowerShell или EAC на уровне ящика, а не учить пользователей крутить Inbox Rules. Иначе через год вы забудете, кто куда что пересылает.

Базовые PowerShell-команды для on-premises Exchange

Подключаемся к Exchange Management Shell от учётной записи с ролью Recipient Management или Organization Management:

# Установить переадресацию на внутренний адрес с сохранением копии
Set-Mailbox -Identity ivanov@itfresh.ru `
  -ForwardingAddress petrov@itfresh.ru `
  -DeliverToMailboxAndForward $true

# Переадресация на внешний адрес (например, при увольнении на партнёра)
Set-Mailbox -Identity sales@itfresh.ru `
  -ForwardingSmtpAddress contact@partner.ru `
  -DeliverToMailboxAndForward $false

# Снять переадресацию
Set-Mailbox -Identity ivanov@itfresh.ru `
  -ForwardingAddress $null `
  -ForwardingSmtpAddress $null

# Посмотреть текущие настройки
Get-Mailbox ivanov@itfresh.ru | Select Name,ForwardingAddress,ForwardingSmtpAddress,DeliverToMailboxAndForward

Ключевой параметр — DeliverToMailboxAndForward. Если $true — копия остаётся в исходном ящике, если $false — письмо только пересылается. Я почти всегда ставлю $true, потому что иначе при разрыве правила (отозвали SMTP-адрес у получателя) письма просто пропадают, и через месяц вы узнаёте об этом от клиента.

Тот же арсенал в Microsoft 365 / Exchange Online

Подключаемся к Exchange Online через модуль PowerShell:

# Установка модуля
Install-Module -Name ExchangeOnlineManagement -Scope CurrentUser

# Подключение
Connect-ExchangeOnline -UserPrincipalName admin@itfresh.ru

# Команды Set-Mailbox / Get-Mailbox работают практически идентично on-premises
Set-Mailbox -Identity ivanov@itfresh.ru `
  -ForwardingAddress petrov@itfresh.ru `
  -DeliverToMailboxAndForward $true

Большая разница в Microsoft 365 — внешний forwarding по умолчанию заблокирован с 2020 года через Outbound Spam Policy в Microsoft Defender. Чтобы разрешить переадресацию на внешний адрес, надо либо добавить ящик в исключения политики, либо изменить параметр AutoForwardingMode:

# Посмотреть текущую политику
Get-HostedOutboundSpamFilterPolicy | Select Name,AutoForwardingMode

# Разрешить переадресацию для конкретной группы ящиков (создав отдельную политику)
New-HostedOutboundSpamFilterPolicy -Name "AllowForward" -AutoForwardingMode On
New-HostedOutboundSpamFilterRule -Name "AllowForwardRule" `
  -HostedOutboundSpamFilterPolicy "AllowForward" `
  -SentTo "contact@partner.ru" `
  -From "sales@itfresh.ru"

Аудит: как найти все переадресации в организации

Это та часть, которую большинство админов делает «когда жареный петух клюнет». Я делаю это раз в полгода у каждого клиента — обязательная плановая работа.

Скрипт, который я запускаю при аудите. Он собирает три вещи: переадресации на уровне ящика, Inbox Rules с переадресацией, transport rules с пересылкой:

# Audit-Forwarding.ps1
# 1. Mailbox-level forwarding
Write-Host "=== Mailbox-level forwarding ===" -ForegroundColor Cyan
Get-Mailbox -ResultSize Unlimited | Where-Object {
  $_.ForwardingAddress -ne $null -or $_.ForwardingSmtpAddress -ne $null
} | Select Name,PrimarySmtpAddress,ForwardingAddress,ForwardingSmtpAddress,DeliverToMailboxAndForward |
  Export-Csv "C:\Audit\mailbox-forwarding.csv" -NoTypeInformation

# 2. Inbox rules with forwarding
Write-Host "=== Inbox rules with forwarding ===" -ForegroundColor Cyan
$rules = @()
Get-Mailbox -ResultSize Unlimited | ForEach-Object {
  $mbx = $_.PrimarySmtpAddress
  Get-InboxRule -Mailbox $mbx -ErrorAction SilentlyContinue | Where-Object {
    $_.ForwardTo -ne $null -or $_.RedirectTo -ne $null -or $_.ForwardAsAttachmentTo -ne $null
  } | ForEach-Object {
    $rules += [PSCustomObject]@{
      Mailbox = $mbx
      RuleName = $_.Name
      ForwardTo = ($_.ForwardTo -join "; ")
      RedirectTo = ($_.RedirectTo -join "; ")
      ForwardAsAttachmentTo = ($_.ForwardAsAttachmentTo -join "; ")
      Enabled = $_.Enabled
    }
  }
}
$rules | Export-Csv "C:\Audit\inbox-rules-forwarding.csv" -NoTypeInformation

# 3. Transport rules with forwarding
Write-Host "=== Transport rules with forwarding ===" -ForegroundColor Cyan
Get-TransportRule | Where-Object {
  $_.RedirectMessageTo -ne $null -or $_.BlindCopyTo -ne $null -or $_.AddToRecipients -ne $null
} | Select Name,RedirectMessageTo,BlindCopyTo,AddToRecipients,Enabled |
  Export-Csv "C:\Audit\transport-rules.csv" -NoTypeInformation

Write-Host "Готово. CSV-отчёты в C:\Audit\" -ForegroundColor Green

За 5–10 минут вы получаете три csv-файла, по которым видно ВСЕ переадресации в организации. Дальше я сажусь с директором и за 30 минут проходим — каждая запись или подтверждается (это же штатный процесс — аккаунт уволенного на месяца), или закрывается (это же «тётя Маша забыла отключить переадресацию полгода назад, когда вернулась из отпуска»).

Кейс: дизайн-студия и утечка через Gmail

Январь 2026 года, ко мне звонит директор дизайн-студии: «Евгений, у нас странная ситуация — конкуренты второй раз делают почти такое же предложение клиенту с разницей в день и ценой ниже на 8 %». Подозрение на утечку. Приехали, начали аудит почты.

Запустили мой скрипт по 32 ящикам. Нашли:

• 2 переадресации на уровне ящика — обе легитимные, на ассистентов директора.
• 1 transport rule на копирование вебмастеру — тоже норм.
• 3 Inbox Rules с пересылкой на личные Gmail — у двух менеджеров и у одного руководителя проектов. Все три настроены год назад, формально для «работы из дома», на деле — забыты после возвращения в офис.
• 1 Inbox Rule «forward всё содержащее „предложение“ или „смета“ на reklama-2024@protonmail.com и удалить из inbox» — у бывшего менеджера, который уволился 4 месяца назад, но его Outlook остался активен через мобильное приложение.

Последняя находка и была источником утечки. После увольнения отключили только AD-учётку на десктопе, но не вышли из активных мобильных сессий — Outlook на iPhone бывшего сотрудника продолжал получать корпоративную почту по OAuth-токену. Все коммерческие предложения уходили конкуренту вместе с ценами и контактами. Студия потеряла на этом по моим оценкам 1.5–2 миллиона рублей за полгода в виде проигранных тендеров.

После закрытия инцидента я ввёл в студии регламент: при увольнении не только блокировать AD-аккаунт, но и обязательно выполнять Revoke-AzureADUserAllRefreshToken в M365, плюс — раз в квартал прогонять мой Audit-скрипт.

Защитные политики, которые ставлю по умолчанию

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

• Disable external auto-forwarding в Microsoft Defender для Exchange Online → Anti-spam → Outbound spam filter policy → AutoForwardingMode = Off (по умолчанию у Microsoft с 2020 года).
• Transport rule «Block external auto-forward» для on-premises Exchange — блокирует пересылку наружу через Inbox Rules с MessageType=AutoForward.
• RemoteDomain * AutoForwardEnabled $false — глобальный запрет на forwarding наружу через Get-RemoteDomain Default | Set-RemoteDomain -AutoForwardEnabled $false.
• Условный доступ Conditional Access — обязательная двухфакторка для административных порталов и для устройств вне корпоративной сети.
• Audit log retention — минимум 1 год хранения mailbox audit log в Exchange Online (по умолчанию 90 дней — мало).

Что делать при увольнении сотрудника: чек-лист

Самый частый сценарий, в котором переадресация важна и опасна одновременно — увольнение. Мой стандартный регламент для клиентов:

1. За 30 минут до объявления об увольнении — заблокировать пароль AD/M365.
2. В Exchange сразу выполнить Set-Mailbox -ForwardingAddress преемник@... -DeliverToMailboxAndForward $true.
3. Запустить Get-InboxRule -Mailbox увольняемый@... | Disable-InboxRule -Confirm:$false — отключить ВСЕ его правила.
4. Выполнить Revoke-MgUserSignInSession -UserId увольняемый@... в Microsoft Graph PowerShell — это сбросит ВСЕ активные токены, включая мобильные приложения.
5. Перевести ящик в Shared Mailbox через Set-Mailbox -Type Shared — освобождает лицензию, но сохраняет историю.
6. Дать преемнику Full Access через Add-MailboxPermission -Identity увольняемый@... -User преемник@... -AccessRights FullAccess.
7. Через 6–12 месяцев экспортировать содержимое в PST через eDiscovery, удалить ящик.

FAQ — что чаще всего спрашивают

Какая разница между ForwardingAddress и ForwardingSmtpAddress?

ForwardingAddress используется для переадресации на адрес внутри организации (получателя из GAL). ForwardingSmtpAddress — на любой внешний email-адрес. Только один из этих параметров может быть установлен одновременно.

Можно ли запретить пользователям самим настраивать переадресацию вовне?

Да, через RemoteDomain с AutoForwardEnabled=$false, через transport rule с блокировкой external auto-forward, или через Outbound Spam Policy в Microsoft 365 Defender. С 2020 года Microsoft по умолчанию блокирует external forwarding в M365.

Что лучше — ForwardingAddress или Inbox Rule пользователя?

Для административной переадресации (увольнение, отпуск, реорганизация) — ForwardingAddress на mailbox-уровне через PowerShell. Для самостоятельных правил — Inbox Rule. Inbox Rule опаснее с точки зрения безопасности и обхода аудита.

Как проверить все настроенные переадресации в организации?

Выполнить Get-Mailbox с фильтром по ForwardingAddress/ForwardingSmtpAddress, затем Get-InboxRule для каждого ящика с фильтром по ForwardTo/RedirectTo/ForwardAsAttachmentTo. Один скрипт на всю организацию — 30 минут работы.

Сколько стоит аудит переадресаций в Exchange?

В АйТи Фреш аудит переадресаций до 100 ящиков с письменным отчётом и закрытием обнаруженных утечек — 12 000–25 000 руб. в зависимости от размера организации.