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

Привет! Я Евгений Семёнов, директор ITFresh. Сегодня поговорим о том, что может казаться пустяком, но на самом деле таит огромные риски. Переадресация почты – ну что тут такого, пара кликов, и всё готово, правда? Но позвольте мне сказать: в малом и среднем бизнесе именно из-за неё происходит добрая половина всех утечек данных. За 15 лет в IT я чего только не повидал! Коммерческие тайны утекают из 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-файла, где расписаны ВСЕ переадресации по всей организации. Представляете? Затем мы садимся с директором, и за полчаса проходим по каждой записи. Либо подтверждаем её – "А, ну да, это же штатный процесс, аккаунт уволенного сотрудника временно перенаправлен на месяц", – либо тут же закрываем. Например, когда выясняется, что "тётя Маша просто забыла отключить свою переадресацию полгода назад, как вернулась из отпуска".

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

Помню, как в январе 2026-го мне набрал директор одной дизайн-студии. Он был просто вне себя от беспокойства: «Евгений, это какой-то кошмар! Конкуренты уже второй раз приходят к нашему клиенту с почти таким же предложением, только на день раньше и на 8% дешевле!» Сразу стало понятно: здесь явно пахнет утечкой. Мы немедленно выехали на объект и взялись за полноценный аудит почты.

Запустили мой скрипт по всем 32 ящикам. И вот что обнаружили:

• Наш аудит показал: есть пара переадресаций на уровне почтового ящика. И знаете что? Это нормально. Обе настроены на ассистентов директора, так что здесь всё чисто и легитимно.
• Кроме того, нашлась одна транспортная политика (transport rule), которая копирует письма вебмастеру. Тоже никаких вопросов, это абсолютно нормально для рабочих процессов.
• А вот тут уже тревожный звоночек: три Inbox Rules. Они настроены на пересылку писем прямиком на личные Gmail-ящики. Владельцы — двое менеджеров и руководитель проектов. Эти правила появились примерно год назад, вроде как для «работы из дома». Но проблема в том, что после возвращения в офис о них просто забыли. А конфиденциальные данные продолжают уходить на сторону, между прочим.
• Приготовьтесь, это самое интересное и тревожное: мы обнаружили одну Inbox Rule, которая просто вопиет об утечке данных. Представьте: все письма с ключевыми словами «предложение» или «смета» автоматически пересылаются на адрес reklama-2024@protonmail.com, а затем сразу удаляются из папки «Входящие». Чей это фокус? Бывшего менеджера. Он уволился четыре месяца назад! Но его Outlook почему-то остался активен через мобильное приложение. Вот вам и дыра в безопасности.

Именно та самая последняя находка и оказалась источником утечки! Что выяснилось? После увольнения они, конечно, отключили AD-учётку сотрудника на рабочем компьютере, но напрочь забыли закрыть активные мобильные сессии. И что в итоге? Outlook на iPhone бывшего сотрудника продолжал абсолютно спокойно получать всю корпоративную почту, используя старый OAuth-токен. Представляете, все свежие коммерческие предложения, со всеми ценами и контактами, утекали прямиком к конкурентам! По нашим подсчётам, студия потеряла от полутора до двух миллионов рублей всего за полгода, проигрывая тендеры один за другим.

После закрытия инцидента я ввёл в студии регламент: при увольнении не только блокировать 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 руб. в зависимости от размера организации.