Как защитить корпоративную почту от фишинга и взлома

Что именно нужно защищать

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

Различайте три ситуации: отправитель лишь выдаёт себя за знакомого человека; используется похожий домен; злоумышленник получил доступ к настоящей учётной записи. В последнем случае письмо может продолжать реальную переписку. Такой обман называют компрометацией деловой переписки, или BEC. Microsoft объясняет, почему знакомое имя не подтверждает подлинность запроса.

Практическая задача компании — разделить три проверки: кто вошёл в ящик, откуда пришло письмо и кто разрешил действие с деньгами. Один продукт не заменяет все три.

Как распознать подозрительное письмо

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

• Просят войти в почту. Откройте сервис через сохранённую закладку или привычное приложение. Не используйте ссылку из сомнительного письма.
• Прислали неожиданный документ. Сначала уточните у отправителя по известному каналу, какой файл он отправлял. Не открывайте его ради проверки.
• Торопят обойти согласование. Передайте запрос ответственному за оплату. Срочность не должна отменять проверку.
• Письмо кажется странным. Сообщите в IT через согласованный канал или кнопку жалобы на фишинг. Не пересылайте опасное вложение коллегам «для ознакомления».

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

Новые реквизиты проверяют вне переписки

Введите простое правило: изменение банковских реквизитов не подтверждается ответом на то же письмо. Microsoft рекомендует проверять подозрительные запросы через другой способ связи.

1. Приостановите оплату и сравните новые данные с карточкой контрагента.
2. Свяжитесь с известным представителем по номеру из договора или ранее проверенного справочника. Не берите номер из нового письма или приложенного счёта.
3. Уточните факт изменения и конкретные реквизиты. Если знакомый сотрудник недоступен, используйте заранее согласованный резервный контакт.
4. Зафиксируйте, кто и когда подтвердил изменение. Назначьте второго сотрудника для согласования замены реквизитов и платежа.

Это предлагаемый рабочий регламент, который следует закрепить внутри компании. Он должен действовать и для писем директора: должность отправителя не отменяет проверку. Если деньги уже отправлены по подозрительному запросу, немедленно свяжитесь с банком через официальный канал; такую первоочередную меру рекомендует NIST в руководстве для малого бизнеса.

MFA: защитите вход, но учитывайте ограничения

Включите многофакторную аутентификацию для сотрудников и администраторов. При поддержке почтовой платформой и устройствами предпочитайте устойчивые к фишингу способы: FIDO2/WebAuthn, включая подходящие passkeys и аппаратные ключи с подтверждением PIN-кодом или биометрией. Такой переход рекомендует CISA.

Ключевое отличие — криптографическая привязка входа к настоящему сервису. Обычный одноразовый код, который человек переносит вручную, такой привязки не даёт. Это различие описано в NIST SP 800-63B-4. Поэтому наличие второго фактора ещё не означает устойчивость к фишингу.

Администратору нужно проверить совместимость устройств, поддерживаемые варианты passkeys и восстановление доступа при потере ключа. Для Microsoft 365 ориентиром служит документация Microsoft Entra. Начните с небольшой группы, проверьте рабочие приложения и подготовьте понятную инструкцию сотрудникам.

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

SPF, DKIM и DMARC: защита домена, а не гарантия

Эти механизмы помогают принимающему серверу оценить происхождение письма. Их роли различаются; подробности приведены в документации Microsoft по аутентификации почты.

• SPF определяет допустимые источники отправки для домена служебного адреса MAIL FROM. Он сам по себе не проверяет видимое имя отправителя.
• DKIM добавляет проверяемую цифровую подпись к подписанным частям сообщения. Подпись не подтверждает добросовестность просьбы в письме.
• DMARC проверяет согласованность видимого домена From с доменом успешно прошедшего SPF или DKIM и задаёт рекомендуемую политику обработки неуспешной проверки.

Сначала составьте список легитимных отправителей: почта, CRM, рассылки, сайт. Настройте их аутентификацию и изучите отчёты. Политика p=none предназначена для наблюдения; переход к карантину или отклонению требует проверки доставки. Такой порядок описывает руководство Microsoft по внедрению DMARC.

Похожий домен может успешно пройти все проверки, а настоящий ящик — оказаться взломанным. Microsoft отдельно описывает подмену личности при успешной аутентификации письма. Сетевую защиту офиса, включая настройку FortiGate, рассматривайте как дополнительный слой: она не заменяет защиту облачной учётной записи и проверку платежей.

Если пароль уже введён или вход подтверждён

Сразу сообщите уполномоченному администратору по известному телефону или другому доступному каналу. Укажите время, адрес страницы и совершённые действия. Не отправляйте пароль. Сохраните исходное письмо для расследования по внутренней процедуре.

Администратор должен действовать по плану реагирования. Для Microsoft 365 официальная инструкция по скомпрометированному ящику включает следующие проверки:

1. Ограничить доступ к затронутой учётной записи на время расследования и отозвать активные сеансы.
2. Сменить пароль безопасным способом; проверить зарегистрированные методы MFA, неизвестные устройства, разрешения приложений и роли.
3. Проверить пересылку и правила входящих сообщений, включая скрытые правила. Удалить несанкционированные настройки.
4. Изучить журналы входов и аудита, отправленные письма и затронутые сервисы. Зафиксировать период и масштаб доступа.
5. Восстановить работу после устранения причин и проверки настроек; предупредить затронутых получателей через проверенный канал.

Одна смена пароля не заменяет расследование. Если пароль использовался ещё где-то, сообщите об этом администратору и смените его в затронутых сервисах.

Отдельная задача — своевременно закрывать доступ бывшим сотрудникам. Для этого пригодится чек-лист отключения доступов при увольнении.

Чек-лист: что можно проверить сегодня

Назначьте владельца каждой проверки. Результат должен подтверждаться настройкой, записью или короткой тренировкой, а не ответом «вроде включено».

Частые вопросы

Письмо пришло от знакомого поставщика. Можно доверять?

Знакомый адрес не подтверждает изменение реквизитов: ящик мог быть скомпрометирован. Для финансовых изменений используйте отдельную проверку по известному каналу.

Достаточно включить MFA всем сотрудникам?

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

Можно ли сразу поставить DMARC в режим reject?

Сначала проверьте все легитимные источники отправки и отчёты. Иначе могут пострадать письма сайта, CRM или рассылок. Ужесточайте политику после проверки доставки.

Официальные источники

1. Microsoft: компрометация деловой переписки и независимая проверка запросов.
2. CISA: признаки фишинга и действия получателя.
3. CISA: внедрение устойчивой к фишингу MFA.
4. NIST SP 800-63B-4: устойчивость аутентификации к фишингу.
5. Microsoft Entra: passkeys и FIDO2.
6. Microsoft: SPF, DKIM и DMARC.
7. Microsoft: поэтапная настройка DMARC.
8. Microsoft: ограничения аутентификации при подмене личности.
9. Microsoft: реагирование на компрометацию учётной записи.
10. NIST: рекомендации для малого бизнеса после фишинга.