Как понять, что данные скачал свой, а не чужой

MAATRIX

Алерт от мониторинга: пользователь скачал 40 тысяч записей из CRM за двадцать минут, хотя обычно за день выгружает пару сотен. Первая мысль — эксфильтрация, менять все пароли и звонить в службу безопасности. Вторая, более полезная — не паниковать, а за пятнадцать минут проверить пять конкретных вещей, которые обычно сразу разводят «аналитик готовит квартальный отчёт» и «кто-то выносит базу клиентов перед увольнением». Ниже — рабочая методика такой проверки, без раздувания одного случайного скачивания в инцидент недели и без риска прозевать реальную утечку.

Сопоставление с учётной записью: чья это активность на самом деле

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

Проверьте по порядку:

• Учётная запись активна и принадлежит реальному текущему сотруднику. Сверка по HR-справочнику: не уволен ли человек, не закрыт ли формально доступ, который фактически ещё работает. Ситуация, когда доступ уволенного продолжает работать месяцами — не редкость, разобрана отдельно в статье «SSH-ключ уволенного сотрудника работал ещё восемь месяцев».
• Это персональный аккаунт, а не общий/сервисный. Логины вида report_bot, etl_service, admin дают массовые выгрузки постоянно по расписанию — нормальный фоновый шум. Проблема в другом: если под таким аккаунтом реально может зайти человек (общий пароль знают трое), выгрузка не привязывается ни к кому конкретно — это стоит чинить как практику, а не разбирать как разовый инцидент.
• Не было ли признаков компрометации именно этого аккаунта — неудачных входов перед успешным, входа с нового устройства без MFA, смены пароля незадолго до события. Если аккаунт подхватил инфостилер и данные выгружает не сотрудник, а вредонос от его имени — разбор меняется с «поговорить с человеком» на «изолировать хост и реагировать на компрометацию».

Практически это делается сверкой по журналу аутентификации:

# последние входы под учёткой перед подозрительной выгрузкой
grep '"user":"a.petrova"' /var/log/app/auth.log \
  | jq -r '[.ts, .event, .ip, .mfa_ok, .device_id] | @tsv' \
  | tail -30

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

Контекст: соответствует ли объём и тип данных должностным обязанностям

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

Три вопроса себе (или руководителю подразделения):

• Соответствует ли тип данных роли. Бухгалтер, выгружающий таблицу зарплат — норма. Тот же бухгалтер, выгружающий полную базу email и телефонов клиентов из CRM — нет, даже если формально имел технический доступ (доступ «на всякий случай» и слишком широкие права — частая находка при таких разборах, но это тема отдельного аудита прав).
• Соответствует ли объём типичной задаче. Менеджер, готовящий отчёт по своим двадцати клиентам, не должен выгружать все сорок тысяч записей базы целиком. Если объём на порядок больше, чем нужно для заявленной задачи — стоит уточнить у сотрудника, зачем такой охват, до выводов.
• Разовая задача или систематический сбор. Аналитик, выгружающий раз в квартал большой срез для отчёта — обычное дело, если повторяется из квартала в квартал в похожем объёме. Тот же аналитик, начавший выгружать данные ежедневно небольшими порциями за неделю до увольнения — паттерн постепенного выноса под видом рутины: в моменте объём мал, но сумма за две недели говорящая.

Полезная практика — сравнивать не с абсолютным порогом, а с собственной историей аккаунта: не «выгрузка больше 10 000 записей — тревога», а «в 5+ раз больше медианы этого пользователя за три месяца — повод посмотреть». Такой подход меньше шумит на тех, у кого работа объективно связана с большими выгрузками — см. «Аналитик грузит выгрузку на 40 ГБ в Excel», где для такой роли крупная выгрузка — рутина, а не аномалия.

Время и место: рабочие часы, привычная локация, устройство

Формально «свой» аккаунт, использованный не в своё время и не в своём месте — весомый повод для проверки, даже если первые два пункта выглядят нормально.

Что смотреть:

• Время суток и день недели. Выгрузка в 3 часа ночи в субботу от сотрудника, обычно работающего с 10 до 19 по будням — расхождение, которое стоит объяснить, даже при небольшом объёме. Само по себе это не доказательство (мог доделывать отчёт вечером), но триггер для следующего шага — связаться с сотрудником, а не сразу считать инцидентом.
• Геолокация и IP. Сверка IP выгрузки с обычной геолокацией сотрудника и, если используется VPN, с журналом VPN-подключений — тем самым, о котором в статье про аудит доступов VPN. Резкая смена страны между двумя сессиями одного аккаунта за короткое время — классический признак компрометации, а не «поехал в отпуск»: физически невозможно быть в двух местах за час.
• Устройство и user-agent. При наличии привязки устройств (device fingerprint, corporate MDM) сверьте: тот же ноутбук, браузер, версия ОС. Новое неизвестное устройство вместе с необычным временем весомее, чем каждый признак по отдельности.

Практический пример сверки по логам VPN и приложения:

# сессии VPN пользователя за сутки инцидента
grep 'a.petrova' /var/log/wireguard/handshakes.log | tail -5

# geoip по IP, с которого была выгрузка
whois 91.203.XX.XX | grep -E 'country|netname'

# сравнение с обычной геолокацией по истории входов за месяц
grep '"user":"a.petrova"' /var/log/app/auth.log \
  | jq -r '.ip' | sort | uniq -c | sort -rn | head -10

Если IP выгрузки регулярно встречается в истории аккаунта — это обычная точка входа (домашний провайдер, офис, привычный VPN-выход), вопрос снимается. Если IP появился впервые и относится к другой стране или дата-центру, а не к провайдеру физических лиц — это стоит прояснить в первую очередь.

Паттерн выгрузки: разовый экспорт или методичный сбор

Способ, которым были скачаны данные, часто говорит больше, чем объём сам по себе. Легитимные выгрузки и подготовка к эксфильтрации выглядят технически по-разному.

Последний пункт особенно показателен: архивация данных прямо перед выгрузкой (zip -r export.zip ./data) там, где это не типично для процесса — частый признак подготовки к переносу вовне: архив легче слить целиком, чем россыпь файлов. При наличии DLP или логирования операций с файлами на конечных точках паттерн «выгрузка → архивирование → отправка во внешний сервис или запись на съёмный носитель» стоит собрать в одно правило корреляции в SIEM, а не смотреть на каждое событие отдельно.

Если данные выгружались через API — проверьте журнал использования ключа: не был ли он ранее засвечен где-то, откуда его мог перехватить кто-то другой. Методика такого поиска — в статье «API-ключ утёк — как найти по логам, кто его жжёт».

Если сомнения остаются: эскалация без сразу «обвинительного уклона»

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

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

1. Зафиксируйте факты до разговора — точное время, объём, состав данных, откуда был доступ, чтобы разговор был предметным, а не «нам кажется, вы что-то натворили».
2. Спросите напрямую руководителя сотрудника или его самого: «Такого-то числа была выгрузка N записей из таблицы X, для какой задачи?» В большинстве случаев ответ приходит быстро и снимает вопрос — квартальный отчёт, миграция в CRM, разовая просьба другого отдела.
3. Если ответа нет, он неубедителен или противоречит фактам — повод для эскалации в службу безопасности или к юристам, с сохранением всех логов как есть, без попыток «доследовать» самостоятельно дальше технических средств.
4. Держите ограничение доступа временным и обратимым — полная блокировка без объяснений часто эскалирует ситуацию сильнее, чем сама выгрузка, особенно если в итоге всё окажется легитимным.

Если по итогам выясняется, что это был неправомерный доступ и данные реально ушли наружу — дальнейшие шаги уже не про диагностику, а про формальное реагирование: чеклист первых часов и обязательства перед регулятором разобраны в статье «Утечка данных: что обязаны сделать и в какие сроки». А если случай пограничный и стоит разобрать его письменно для команды независимо от вывода — подход описан в «Как писать разбор инцидента, чтобы из него учились».

Практика на будущее: согласование крупных выгрузок заранее

Лучший способ не гадать постфактум, легитимна ли была выгрузка — сделать так, чтобы крупные выгрузки заранее были известны и согласованы, а не обнаруживались только по алерту мониторинга.

Работающая на практике схема — пороги и обязательное согласование, привязанные к объёму, а не к должности:

# пример политики порогов для DLP/SIEM-правила
export_policy:
  default_threshold_records: 1000       # выше — уведомление руководителю
  requires_preapproval_records: 5000    # выше — обязательное согласование ДО выгрузки
  requires_preapproval_pii: true        # для персональных данных порог ниже вдвое
  exempt_service_accounts:
    - etl_nightly_report
    - backup_export_service
  approval_ttl_hours: 48                # согласование действует ограниченное время

Смысл такой политики не в том, чтобы заблокировать легитимную работу аналитиков — исключения для сервисных аккаунтов и разумные пороги как раз для этого. Смысл в том, чтобы для выгрузок выше порога существовал явный след согласования, к которому можно апеллировать при разборе: «согласовано с руководителем такого-то числа для задачи такой-то» — вместо реконструкции легитимности постфактум по косвенным признакам времени и IP.

Дополнительно стоит завести простой документ — список ролей и типичных для них объёмов/типов выгрузок, который HR и IT синхронизируют при найме, переводе и увольнении. Именно рассинхрон между «формально доступ есть» и «фактически человек в другой роли или уже не работает» чаще всего создаёт ложные тревоги — а иногда и реальные дыры, как в примере с забытым доступом уволенного сотрудника выше.

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