Автопересылка – это плохо
Разрешение пользователям пересылать свои электронные письма за пределы Exchange Online – это плохо, особенно если они не хранят копию пересылаемых сообщений в своем почтовом ящике. Помимо удаления электронной почты из-под контроля, налагаемого политиками управления данными, это создает риск того, что конфиденциальная информация передается за пределы организации, включая случай, когда злоумышленник взламывает почтовый ящик и включает пересылку без ведома владельца почтового ящика. Это делается для того, чтобы понять трафик, который взломанный пользователь получает в целях подготовки к осуществлению атаки на бизнес-электронную почту.
В этой двухчастной серии я сначала рассмотрю, как ограничить пользователей OWA от создания адресов автопересылки с использованием RBAC. Во второй статье описываются некоторые другие блокировки, которые применяются ко всем клиентам для предотвращения утечки электронной почты из организации.
Кто автопересылает?
Пересылка – это функция сервера, поэтому после того, как пользователь настраивает адрес пересылки в OWA, любая почта, поступающая в почтовый ящик, пересылается. Чтобы выяснить, сейчас пересылается ли почта, выполните команду:
Get-Mailbox -RecipientTypeDetails UserMailbox -Filter {ForwardingSmtpAddress -ne $Null} -ResultSize Unlimited | Format-Table DisplayName, ForwardingSmtpAddress, DeliverToMailboxAndForward -AutoSize
DisplayName ForwardingSmtpAddress DeliverToMailboxAndForward
----------- --------------------- --------------------------
Vasil Michev (Technical Guru) smtp:[email protected] True
Ståle Hansen smtp:[email protected] True
Eoin Redmond smtp:[email protected]
Вы можете предпринять шаги для противодействия атакам, обучая пользователей, но лучше отказаться от возможности пересылать электронную почту. Мы можем сделать это, создав новую политику назначения пользовательской роли, которая не включает параметры командлета, необходимые для пользователя для создания автопересылки.
Как установить адрес автопересылки
Опция автоматического пересылки сообщений из Exchange Online (или в локальной среде) находится в разделе “Почта” настроек OWA (Рисунок 1).
После того, как адрес автоматической пересылки установлен, OWA информирует пользователя в том, что теперь называется менеджером учетной записи OWA, в панели меню (Рисунок 2).
Управление доступом на основе ролей и Exchange
Новая OWA обладает улучшенным интерфейсом, и механизм Управления доступом на основе ролей (RBAC), который существовал с Exchange 2010, лежит в основе этого блестящего нового вида, так же как и в Exchange Admin Center (EAC).
RBAC работает, позволяя доступ к командлетам PowerShell и их параметрам. Если вы не можете запустить командлет или передать значение в параметре, вы теряете доступ к функции. Политика назначения ролей, примененная к почтовому ящику, состоит из набора ролей, каждая из которых контролирует доступ к одной или нескольким функциям. Клиенты, такие как OWA, используют RBAC, чтобы знать, когда функция доступна пользователю. Если их почтовый ящик заблокирован от функции, потому что назначенная политика не включает правильный доступ, пользователь не отображает функцию. Это простой и эффективный механизм. По крайней мере, так оно и есть в теории.
Вы можете создавать и назначать политики назначения ролей пользователей через раздел Разрешения в EAC. Интерфейс хорошо работает, если вы хотите исключить большой объем функциональности, например, возможность выбора персональных меток удержания. Он не позволяет удалять функциональность более хирургически, например, разрешая людям управлять списками рассылки, которыми они владеют, и удаляя возможность создавать новые списки. Для внесения таких изменений необходимо использовать PowerShell.
Создание новой роли RBAC
RBAC для Exchange Online работает на основе ограничения пользователей в возможности запуска cmdlet’ов до уровня параметра. Администраторы могут запускать все cmdlet’ы и все параметры из-за занимаемых ими ролей. Обычные пользователи имеют более ограниченный набор ролей, поэтому могут делать меньше. Например, для настройки автоматической пересылки адреса в PowerShell вы запускаете cmdlet Set-Mailbox с помощью команды:
Set-Mailbox -Identity Kim.Akers -ForwardingSmtpAddress [email protected] -DeliverToMailboxAndForward $True
Следовательно, чтобы предотвратить возможность создания пользователем автоадреса пересылки, нам нужно удалить возможность запуска cmdlet’а Set-Mailbox с параметром ForwardingSmtpAddress.
Первый шаг для реализации блокировки с помощью RBAC заключается в создании новой роли управления с использованием существующей роли MyBaseOptions в качестве шаблона. Это означает, что все поддерживаемые опции в MyBaseOptions, включая возможность настройки автоматической пересылки адреса, наследуются новой ролью.
New-ManagementRole MyBaseOptions-NoForward -Parent MyBaseOptions
Отключение параметров cmdlet в роли
Мы не хотим удалять доступ ко всему функционалу Set-Mailbox, потому что этот командлет используется для управления другими настройками, такими как установка уведомления об отсутствии на рабочем месте, но мы хотим отключить доступ к параметрам, используемым в параметрах выбора OWA. Вот как удалить два параметра из командлета в разрешенных опциях в новой роли управления.
Set-ManagementRoleEntry MyBaseOptions-NoForward\Set-Mailbox -RemoveParameter -Parameters DeliverToMailboxAndForward, ForwardingSmtpAddress
Создание политики присвоения ролей
У нас теперь есть настроенная роль и нам нужно объединить ее с другими ролями, которые обычно получают пользователи в политике присвоения ролей пользователя, чтобы создать новую политику. Этой командой создается новая политика присвоения ролей пользователю, которая объединяет базовые роли и нашу настроенную роль.
New-RoleAssignmentPolicy -Name PolicyWithNoEmailForward -Roles MyContactInformation, MyRetentionPolicies, MyMailSubscriptions, MyTextMessaging, MyVoiceMail, MyDistributionGroupMembership, MyDistributionGroups, MyProfileInformation, MyBaseOptions-NoForward -Description "User role assignment policy that restricts the assignees from being able to autoforward email outside the organization"
Примечание: если базовые роли были обновлены, эти изменения переносятся в новую политику. Вы можете проверить назначения, открыв политику в EAC (Рисунок 3).
Альтернативный подход заключается в обновлении политики присвоения ролей пользователя по умолчанию через EAC так, чтобы она выглядела как на Рисунке 3. Однако данный способ повлияет на каждый ящик, к которому применена политика (часто на каждый ящик в организации). Возможно, вам не захочется делать это, поэтому новая политика может быть лучшим вариантом.
Применение новой политики присвоения ролей пользователю
Политики присвоения ролей пользователя применяются к почтовым ящикам путем выполнения командлета Set-Mailbox. Здесь мы присваиваем политику одному почтовому ящику.
Set-Mailbox -Identity James.Ryan -RoleAssignmentPolicy PolicyWithNoEmailForward
Пройдет некоторое время, прежде чем новая политика вступит в силу. После этого пользователь не сможет установить адрес пересылки, потому что OWA отметит, что в политике отсутствуют необходимые параметры командлета, и подавит пользовательский интерфейс (Рисунок 4).
PowerShell упрощает назначение политик для большого количества почтовых ящиков за один раз. Здесь мы находим набор почтовых ящиков, у которых есть адрес автопереадресации, и назначаем для них новую политику. В то же время мы удаляем существующий адрес автопереадресации, чтобы предотвратить пересылку любых других сообщений за пределы организации. Это важный шаг, потому что назначение политики отключает возможность установки новых переадресаций. Это ничего не делает для удаления существующих адресов переадресации.
Get-Mailbox -RecipientTypeDetails UserMailbox -Filter {ForwardingSmtpAddress -ne $Null} |
Set-Mailbox -RoleAssignmentPolicy "PolicyWithNoEmailForward" -ForwardingSmtpAddress $Null -DeliverToMailboxAndForward $False
На этом этапе, вероятно, будет хорошей идеей отправить вежливое сообщение владельцам затронутых почтовых ящиков, чтобы сообщить им хорошую новость о том, что электронная почта останется внутри организации.
В качестве окончательной проверки, чтобы узнать, какие почтовые ящики имеют нашу новую политику, выполните:
Get-mailbox -RecipientTypeDetails UserMailbox | ?{$_.RoleAssignmentPolicy -eq "PolicyWithNoEmailForward"} | Format-Table DisplayName, RoleAssignmentPolicy
DisplayName RoleAssignmentPolicy
----------- --------------------
Kim Akers PolicyWithNoEmailForward
Vasil Michev PolicyWithNoEmailForward
Ståle Hansen PolicyWithNoEmailForward
Eoin Redmond PolicyWithNoEmailForward
При необходимости администратор может сбросить автопереадресацию на почтовом ящике, запустив Set-Mailbox (пример ниже) или обновив почтовый ящик через EAC. RBAC не применяется в этих административных контекстах.
Set-Mailbox -Identity Kim.Akers -ForwardingSmtpAddress [email protected] -DeliverToMailboxAndForward $True
Часть первого решения
Остановка пользователей OWA от создания адресов автопереадресации – хороший первый шаг для предотвращения автоматической пересылки сообщений за пределы организации. Однако это только первый шаг. У других клиентов и приложений есть свои способы автоматизации пересылки, поэтому важно принять последовательный подход к проблеме.
Следующим шагом будет рассмотрение других барьеров, которые можно установить для предотвращения автоматического перенаправления. Об этом говорится в статье 2 этой серии.
Source:
https://petri.com/stop-owa-users-autoforwarding-email/