Как проверить корпоративную почту через API: аудит настроек защиты

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

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

🔍 Что именно проверяет API-аудит

API-аудит смотрит на параметры защиты, а не на содержание переписки. Скрипт получает сведения о многофакторной аутентификации, сеансах, приложениях, правилах пересылки и почтовых протоколах. Результат содержит состояние настройки и уровень риска.

Такой подход полезен для регулярной проверки. Администратор видит изменения после увольнения сотрудника, подключения нового приложения или смены политики доступа. При этом аудит не заменяет расследование инцидента и не доказывает отсутствие компрометации.

У разных систем отличаются названия методов и разрешений. Microsoft 365 использует Microsoft Graph, а Google Workspace предоставляет Admin SDK и Gmail API. Корпоративный сервер может иметь собственный интерфейс или вообще не поддерживать нужные проверки.

Сначала составьте карту возможностей. Для каждого пункта укажите поставщика, метод API, требуемое право и ожидаемое состояние. Прямо сейчас разделите проверки настроек и проверки содержимого писем.

🛠️ Как подготовить приложение для проверки

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

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

API-аудит проводят только с разрешения владельца системы. Без такого разрешения даже безопасный запрос становится несанкционированным действием. В рабочем контуре сначала запускают небольшую проверку на тестовой группе.

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

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

🔐 MFA, условный доступ и доверенные устройства

Многофакторная аутентификация снижает риск входа по одному украденному паролю. API-аудит показывает, включена ли MFA для пользователя или группы. Он также помогает найти исключения для администраторов и сервисных учётных записей.

Одной MFA недостаточно. Важно проверить условный доступ: ограничения по устройству, местоположению, уровню риска и типу приложения. Названия условий зависят от платформы, поэтому отчёт должен хранить не только итог, но и источник значения.

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

Не удаляйте сеансы автоматически без правила эскалации. Сначала фиксируйте идентификатор, время, адрес сети и пользователя. Затем сравнивайте событие с кадровыми данными и заявленной рабочей географией.

Прямо сейчас сформируйте список исключений MFA. Для каждого исключения укажите владельца, причину и срок пересмотра.

🧩 OAuth-приложения и выданные разрешения

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

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

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

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

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

Прямо сейчас выгрузите перечень OAuth-приложений. Отметьте неизвестные, давно не использовавшиеся и получившие права шире своей задачи.

📨 Пересылка, внешние адреса и делегирование

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

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

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

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

Прямо сейчас сравните все внешние адреса пересылки со списком утверждённых доменов. Неизвестные правила вынесите на ручную проверку.

⚙️ Устаревшие протоколы и параметры домена

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

Исключение оформляют отдельно. В нём указывают систему, владельца, причину и план отказа. Постоянное исключение без срока быстро превращается в незаметный обход политики.

Проверка домена дополняет аудит ящиков. SPF показывает, какие отправляющие серверы разрешены от имени домена. DKIM добавляет цифровую подпись сообщения. DMARC задаёт действие для писем, которые не проходят проверку домена.

Для этих механизмов применяют рекомендации RFC 7208, RFC 6376 и RFC 7489. Важно смотреть не только на наличие записи. Анализируют режим политики DMARC, обработку отчётов и соответствие разрешённых отправителей реальной инфраструктуре.

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

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

📊 Журналы входов и изменения настроек

Журнал входов показывает, когда и откуда пользователь обращается к почте. Для анализа используют время, адрес сети, устройство, тип клиента и результат аутентификации. Один необычный вход не равен инциденту, но сочетание нескольких признаков требует проверки.

Отдельно анализируют изменения MFA, правил пересылки, OAuth-разрешений и делегатов. Важны автор, время, старое значение и новое значение. Если API возвращает только итоговое состояние, дополнительно используют журнал событий.

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

Результаты передают в централизованный журнал. Там отчёт связывают с учётной записью, версией скрипта и временем запуска. Персональные данные в итогах маскируют, если полный адрес не нужен для работы.

Старые события не удаляют до окончания установленного срока хранения. Доступ к журналам ограничивают ролями. Исправления в отчёте не должны скрывать исходную запись.

Прямо сейчас задайте минимальный набор полей для журнала. Проверьте, что каждое изменение настройки можно связать с конкретным администратором.

🛡️ Ограничение запросов и защита токенов

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

Постраничную выдачу обрабатывают последовательно. Скрипт не запрашивает один и тот же объект без причины. Результаты неизменяемых проверок можно временно кэшировать, но срок хранения указывают в правилах аудита.

Токены и ключи API защищают так же строго, как пароли администраторов. В журнал не записывают значение токена, полный адрес электронной почты и содержимое заголовков сообщений. В отчёте оставляют только данные, необходимые для решения.

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

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

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

📋 Универсальная таблица проверки

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

В качестве практического ориентира полезно использовать опубликованный перечень мер для Яндекс 360. При сверке 1 сентября 2026 года в нём находились 18 технических пунктов. Вкладка проверки через API была у 10 пунктов, а вкладка настройки через API — у пяти.

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

Для каждого пункта задайте приоритет. Высокий получают внешний вывод почты, неизвестные OAuth-права и входы с признаками захвата. Средний приоритет получают устаревшие исключения и неполные журналы.

Низкий приоритет не означает «можно забыть». Он показывает, что риск ограничен и исправление можно включить в плановые работы. Приоритет пересматривают после изменений инфраструктуры.

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

🚀 Как проводить аудит без лишнего риска

Начинайте с инвентаризации. Запишите поставщика, домены, общие ящики, сервисные учётные записи и подключённые приложения. Укажите, какие данные доступны через API и какие методы поддерживаются.

Затем регистрируйте приложение в отдельном проекте. Выдавайте права только на чтение. Запускайте запросы на небольшой группе и сравнивайте ответ API с панелью администратора.

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

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

API-аудит не проверяет намерения пользователя и не заменяет анализ содержимого при расследовании. Он показывает технические условия, которые делают захват почты сложнее. Поэтому его используют вместе с обучением сотрудников, контролем доступа и разбором событий.

Практический порядок прост: проверить MFA, затем сеансы, OAuth, пересылку, делегирование, протоколы, доменную защиту и журналы. После каждой проверки фиксируйте владельца и срок исправления.

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

📚 Читайте также

• OpenID Connect под нагрузкой: проверка корпоративного сервера
• OpenID Connect и федерация: проверяем доверие и права доступа
• Device Code Phishing через Microsoft: как OAuth-фишинг обходит MFA
• Токен в URL после Referer: новые каналы утечки и защита веб-приложений
• Кража почты через OAuth-фишинг: как злоумышленники получают доступ к корпоративной переписке

📖 Термины

API · IAM (Identity and Access Management) · MFA · OAuth · Фишинг

🔗 Источники

• API под ударом. Что делать?(2026-09-04 ✓)
• Продукты, решения, сервисы – Годовой отчет Positive Technologies 2025(2026-09-04 ✓)
• Чек‑лист безопасности Яндекс 360: через API проверяются 10 пунктов из 18, настраиваются 5(2026-09-04 ✓)