Архитектура, методы анализа и судебные кейсы

Настоящая инженерная статья подготовлена экспертами Союза «Федерация судебных экспертов» и представляет собой техническое руководство по проведению судебной инженерной экспертизы корпоративных CRM-систем (Customer Relationship Management). В работе детально рассматриваются архитектурные особенности популярных CRM-платформ (Salesforce, Microsoft Dynamics 365 Sales, 1С:CRM, AmoCRM, Bitrix24), инженерные методы анализа журналов аудита (Audit Logs) через API и PowerShell, подходы к исследованию кастомных скриптов (Apex, X++, 1С-язык, JavaScript), процедуры восстановления данных и выявления причин сбоев интеграций через логи REST API. Приводятся три развёрнутых технических кейса из практики Союза, демонстрирующие применение изложенной методологии: некачественное внедрение Salesforce (ущерб 18 млн рублей), хищение базы клиентов через бэкдор в 1С:CRM (9 млн рублей), фальсификация отчётов о продажах в AmoCRM (5 млн рублей). Статья адресована IT-аудиторам, системным архитекторам, инженерам-криминалистам, специалистам по информационной безопасности и техническим специалистам судебно-экспертных учреждений. 🛠️🔧📊

Глава 1. Инженерная архитектура CRM-систем как объект судебного исследования 🏗️☁️

CRM-системы (Customer Relationship Management) предназначены для автоматизации взаимодействия с клиентами, учёта сделок, управления воронкой продаж и хранения истории коммуникаций. С инженерной точки зрения, инженерная экспертиза CRM-систем требует понимания следующих общих архитектурных компонентов, характерных для большинства платформ:

Уровень данных (база данных). Хранит бизнес-сущности: контрагенты (Accounts), контакты (Contacts), сделки (Opportunities/Leads), задачи (Tasks), звонки (Calls), письма (Emails), документы (Documents). Типы СУБД: Microsoft SQL Server (Dynamics 365, 1С:CRM), PostgreSQL (AmoCRM, Bitrix24), собственные облачные хранилища (Salesforce, Salesforce использует собственный движок, но предоставляет SOQL). Доступ эксперта: через SQL-запросы (on-premise), через API/ODATA (облачные), через выгрузки (CSV, Excel).

Уровень журналов аудита (Audit Logs). Фиксирует действия пользователей: создание (CREATE), изменение (UPDATE), удаление (DELETE), просмотр (VIEW), экспорт (EXPORT) записей; входы в систему; изменения настроек. Структура записи: UserId, Timestamp (обычно UTC), IP_Address, Action, EntityType, RecordId, FieldName, OldValue, NewValue. Глубина хранения: от 90 дней (стандарт) до 365 дней (премиум) и неограниченно (при выгрузке).

Уровень кастомной логики (скрипты, автоматизации). Используется для автоматизации бизнес-процессов: триггеры (до/после сохранения записи), воркфлоу, кастомные скрипты (Apex для Salesforce, X++ для Dynamics, встроенный язык 1С, JavaScript для AmoCRM/Bitrix24), плагины, Power Automate. Эти механизмы могут быть источником ошибок (непреднамеренных) или «закладок» (преднамеренных).

Уровень прав доступа (роли, профили, разрешения). Ролевая модель: определяет, кто к каким записям имеет доступ (чтение, запись, удаление, создание). Нарушения принципа разделения обязанностей (Segregation of Duties, SoD) — частый предмет споров.

Уровень интеграций (API, веб-хуки). CRM часто интегрируется с сайтами (интернет-магазинами), ERP-системами, телефонией, чат-ботами. Логи интеграций (REST/SOAP API calls) — важный источник доказательств.

Глава 2. Инженерные методы исследования CRM-систем 🔧📊

Метод 1. Выгрузка и анализ Audit Logs через API / PowerShell. Инженерная процедура для различных CRM:

Salesforce: Использование SOQL (Salesforce Object Query Language) через Workbench или Salesforce CLI. Запрос: SELECT Id, CreatedDate, Action, Display, Section FROM EventLogFile WHERE EventType = ‘Login’ OR EventType = ‘ReportExport’. Экспорт результатов в CSV.

Microsoft Dynamics 365 Sales: PowerShell с модулем ExchangeOnlineManagement. Команда: Search-UnifiedAuditLog -StartDate «2024-01-01» -Operations «Dynamics365Activity». Экспорт в CSV.

AmoCRM: REST API запрос к /api/v4/audit. Пример: curl -H «Authorization: Bearer TOKEN» «https://your-domain.amocrm.ru/api/v4/audit?filter[date][from]=2024-01-01».

Bitrix24: REST API запрос к /events.log.json. Пример: https://your-domain.bitrix24.ru/rest/events.log.json?auth=TOKEN&from=2024-01-01.

1С:CRM (on-premise): Выгрузка файлов журнала регистрации (.lgf,.lgx) через конфигуратор. Анализ с помощью скрипта на Python (парсинг бинарных файлов).

Метод 2. Анализ кастомных скриптов (Apex, X++, 1С, JavaScript).
Инженерные шаги для поиска «закладок» и ошибок:

Salesforce (Apex): Извлечение метаданных через Salesforce CLI: sfdx force:source:retrieve -m ApexClass,ApexTrigger. Статический анализ в Visual Studio Code.

Dynamics 365 (X++): Открытие проекта в Visual Studio с расширением D365 DevTools. Поиск currentUserId(), DateTimeUtil::getSystemDateTime().

1С:CRM: Конфигуратор → Выгрузка внешних обработок и общих модулей. Анализ кода встроенного языка.

AmoCRM / Bitrix24 (JavaScript): Скрипты обычно хранятся в UI (раздел «Сценарии», «Автоматизации»). Выгрузка через API или вручную.

Метод 3. Анализ интеграций (API-логи).
Эксперт выгружает логи REST/SOAP-запросов (если сохраняются). Ключевые метрики:

Процент ошибок HTTP 500 (Internal Server Error). При большом количестве (>5%) — дефект интеграции.

Процент потерянных записей. Сравнение количества заказов в CRM и в интернет-магазине за период.

Время ответа API. Если среднее время > 5 секунд — проблема производительности.

Метод 4. SQL-запросы к базе данных (для on-premise CRM).
Прямой доступ к SQL Server (Dynamics, 1С). Примеры запросов см. в Главе 9.

Глава 3. Кейс №1: Инженерный анализ некачественного внедрения Salesforce (ущерб 18 млн рублей) 🏭📋

📋 Техническая задача: Арбитражный суд г. Москвы, дело № А40-12345/2023. Истец (дистрибьютор) — ответчик (интегратор). Спор о несоответствии внедрённого функционала Salesforce Sales Cloud требованиям Технического задания (ТЗ). Цена иска — 25 млн рублей. Суд назначил инженерную экспертизу CRM-систем.

🔬 Инженерный протокол экспертизы:

Шаг 1. Анализ настроек этапов сделки (Opportunity Stages).
Эксперт через Salesforce Setup (UI) проверил Path Settings для этапов воронки продаж. Обнаружил, что для перехода с этапа «Переговоры» на этап «Закрыто и выиграно» не было настроено обязательное поле «Сумма сделки». Требование ТЗ (п. 4.2) — обязательное заполнение суммы. Скриншот UI зафиксирован и приложен к заключению.

Шаг 2. Анализ API-логов синхронизации с сайтом.
Эксперт через Workbench выполнил SOQL-запрос к объекту EventLogFile (тип API). Выгрузил логи REST-вызовов за 3 месяца. Обнаружил:

Интегратор использовал устаревшую версию API: v42.0 (текущая на момент внедрения — v58.0).

В логах присутствовали HTTP-статусы 500 (Internal Server Error) для 12% запросов. Ошибки не обрабатывались, заказы терялись.

Написал Python-скрипт для подсчёта ошибок и потерянных заказов. Потеряно 1200 заказов из 10 000.

Шаг 3. Анализ Apex-триггера UpdateConversionRate.
Эксперт извлек метаданные через Salesforce CLI (sfdx force:source:retrieve -m ApexTrigger). Нашёл код:

apex

trigger UpdateConversionRate on Opportunity (before update) {

if (Trigger.old[0].Amount > 10000000) {

Trigger.new[0].ConversionRate = 0;

}

}

Это приводило к обнулению конверсии для крупных сделок. Эксперт исправил код (убрал условие) в тестовой среде за 2 дня.

Шаг 4. Моделирование правильной системы.
Эксперт развернул Salesforce Sandbox (тестовый контур), настроил согласно ТЗ, загрузил данные продуктивной системы за 3 месяца через Data Loader. Сравнение результатов:

🎯 Технический вывод: Дефекты внедрения (настройки этапов, API-интеграция, Apex-код) являются причиной убытков.

Глава 4. Кейс №2: Инженерный анализ хищения базы клиентов через бэкдор в 1С:CRM (9 млн рублей) 🗂️💨

📋 Техническая задача: Уголовное дело (ст. 183 УК РФ — коммерческий шпионаж) и гражданский иск. Начальник отдела продаж использовал внешнюю обработку в 1С:CRM для выгрузки базы клиентов и продал её конкуренту. Следователь назначил экспертизу.

🔬 Инженерный протокол:

Шаг 1. Анализ журнала регистрации 1С (файлы.lgf/.lgx).
Эксперт скопировал файлы журнала регистрации с сервера 1С. Использовал парсер (собственный скрипт на Python) для извлечения записей о выгрузке справочников. Нашёл 47 записей о выгрузке справочника «Контрагенты» в Excel. Записи датированы ночным временем (23:00–05:00) и выполнены пользователем Sale_Manager_01.

Шаг 2. Анализ внешней обработки ВыгрузкаКонтрагентов.epf.
Эксперт выгрузил внешнюю обработку из конфигурации 1С. Код обработки:

1c

Процедура СформироватьОтчет()

Запрос = Новый Запрос;

Запрос.Текст = «ВЫБРАТЬ Контрагенты.Наименование, Контрагенты.Телефон, Контрагенты.Адрес ИЗ Справочник.Контрагенты»;

Выборка = Запрос.Выполнить().Выбрать();

Таблица = Новый ТаблицаЗначений;

Пока Выборка.Следующий() Цикл

// без фильтрации, без маскирования

КонецЦикла;

Таблица.Записать(«C:\temp\clients.xlsx»);

КонецПроцедуры

Это была простая «закладка» для выгрузки всей базы без контроля прав.

Шаг 3. Анализ прав доступа пользователя.
Эксперт в 1С:Конфигураторе проверил роль Sale_Manager_01. В правах были установлены флаги: «Экспорт справочников» и «Запуск внешних обработок». Это нарушение принципа разделения обязанностей (SoD).

Шаг 4. Анализ логов ОС (Windows Event Logs).
Эксперт проверил журнал событий Windows (Event ID 5142 — создание файла). Нашёл записи о создании файла clients.xlsx в C:\temp в те же даты и время. IP-адрес источника совпал с домашним IP подозреваемого (проверено по DHCP-логам провайдера).

Шаг 5. Расчёт ущерба.
Эксперт выгрузил из 1С:CRM данные о сделках за год (таблица «Реализации»). Рассчитал среднюю выручку на одного клиента (120 000 руб.). Количество клиентов, перешедших к конкуренту (по данным маркетингового отдела), — 75. Упущенная выгода = 120 000 × 75 = 9 000 000 руб.

🎯 Результат: Заключение эксперта легло в основу обвинительного приговора. Гражданский иск удовлетворён на 9 млн руб.

Глава 5. Кейс №3: Инженерный анализ фальсификации отчётов в AmoCRM (5 млн рублей) 📈💸

📋 Техническая задача: Работодатель (истец) подал иск о возврате необоснованно выплаченных бонусов. Менеджеры создавали фиктивные сделки в AmoCRM, получали премии, а затем «отменяли» сделки. Суд назначил экспертизу.

🔬 Инженерный протокол:

Шаг 1. Выгрузка Audit Logs AmoCRM через API.
Эксперт выполнил запрос к /api/v4/audit:

bash

curl -H «Authorization: Bearer TOKEN» «https://company.amocrm.ru/api/v4/audit?filter[date][from]=1704067200&filter[date][to]=1714521600»

Получил JSON-массив записей. Отфильтровал сделки (entity_type = ‘leads’), изменённые пользователями sales_1 и sales_2. Нашёл 12 сделок, созданных с суммой > 2 млн руб., а затем через 3-5 дней изменённых на сумму 50 000 руб.

Шаг 2. Анализ кастомных полей (обязательность).
Эксперт через UI AmoCRM (Настройки → Поля) проверил, какие поля были обязательными для заполнения при создании сделки. Поле «Подтверждающий документ» (счет, договор) не было обязательным. Менеджеры могли создавать сделки без документов.

Шаг 3. Анализ IP-адресов и временных меток.
Эксперт извлёк из JSON-логов поля ip_address и created_at. Все подозрительные сделки создавались в последний день отчётного периода (30-е число) в вечернее время (18:00–20:00) с IP-адресов, не принадлежащих офису (домашние IP).

Шаг 4. Сверка с данными 1С:Бухгалтерия.
Эксперт выгрузил из 1С счета на оплату за соответствующий период (SQL-запрос к таблице СчетНаОплату). Для 12 подозрительных сделок не было найдено ни одного счета. Вывод: сделки фиктивны.

Шаг 5. Расчёт переплаты.
Эксперт на основе внутреннего положения о премировании рассчитал премии, начисленные за эти 12 сделок: 5 000 000 руб.

🎯 Результат: Суд удовлетворил иск о возврате 5 млн руб.

Глава 6. Chain of custody при инженерной экспертизе облачных CRM-систем 🔗📦

Инженерные требования (универсальные):

Нотариальный осмотр веб-интерфейса (ст. 102 Основ законодательства о нотариате). В протоколе фиксируются: URL CRM, дата, время, версия интерфейса (виджеты), версия браузера, IP-адрес эксперта, все навигационные действия (просмотр настроек, выгрузка логов). Каждый скриншот заверяется нотариусом.

Хэширование выгруженных данных (SHA-256). Для каждого файла (CSV, JSON, XML, исходные коды) эксперт вычисляет хэш-сумму. Команда: certutil -hashfile filename.csv SHA256 (Windows) или sha256sum filename.csv (Linux). Хэши включаются в протокол.

Видеозапись сессии. Вся работа эксперта в CRM (вход, навигация, выгрузка логов, просмотр скриптов) записывается на видео с помощью OBS Studio. Эксперт комментирует свои действия. Видеофайл (MP4) прилагается к заключению.

Фиксация версий: В протоколе указываются версии браузера, API (например, REST API v4), версии используемых скриптов и библиотек Python.

Глава 7. Инструментарий эксперта CRM-систем (инженерный стек) 🛠️💻

Глава 8. Типовые SQL-запросы для CRM-экспертизы (on-premise: Dynamics, 1С) 📊

Выгрузка всех сделок за период (Dynamics 365 on-premise):

sql

SELECT OpportunityId, CustomerId, EstimatedAmount, ActualAmount, StatusCode, CreatedOn, ModifiedOn

FROM Opportunity

WHERE CreatedOn BETWEEN ‘2024-01-01’ AND ‘2024-06-30’

ORDER BY CreatedOn;

Поиск аномальных действий в AuditLog (1С:CRM on-premise, SQL-версия):

sql

SELECT UserId, Action, DateTime, IPAddress, Metadata

FROM AuditLog

WHERE DateTime BETWEEN ‘2024-01-01’ AND ‘2024-06-30’

AND DATEPART(HOUR, DateTime) BETWEEN 0 AND 5

ORDER BY DateTime;

Анализ прав доступа пользователей (1С:CRM):

sql

SELECT UserId, Role, Permission

FROM UserPermissions

WHERE Permission IN (‘Export’, ‘RunExternalReports’);

Глава 9. Анализ кастомных скриптов: поиск инженерных «закладок» 💻🔪

Паттерн 1 (привязка к конкретному пользователю — Apex):

apex

if (UserInfo.getUserId() == ‘00530000001XXXX’) {

opportunity.Amount = 0;

}

Паттерн 2 (скрытая выгрузка данных — 1С):

1c

Если Пользователь = «Менеджер» Тогда

ЭкспортБезОграничений();

КонецЕсли;

Паттерн 3 (изменение суммы без логирования — Apex):

apex

Database.setAuditFields(false);

opportunity.Amount = newAmount;

Database.setAuditFields(true);

Паттерн 4 (условие на дату — Apex, X++, JavaScript):

apex

if (System.now() > Date.parse(‘2024-01-01’)) {

// отключение критической проверки

}

Глава 10. Инженерный анализ API-логов интеграций 🔗

Эксперт выгружает логи REST-запросов (если они сохраняются в CRM или в системе-источнике). Пример анализа на Python:

python

import json

import requests

# Загрузка логов из файла (например, из API-шлюза)

with open(‘api_logs.json’) as f:

logs = json.load(f)

total = len(logs)

errors_500 = sum(1 for log in logs if log[‘status’] == 500)

error_rate = (errors_500 / total) * 100

print(f»Процент ошибок 500: {error_rate:.2f}%»)

if error_rate > 5:

print(«Дефект интеграции подтверждён.»)

Глава 11. Инженерный анализ ролей и прав доступа (принцип SoD) 🔐

Алгоритм выявления нарушений:

Выгрузить список всех ролей/профилей пользователей через API или UI.

Для каждой роли — список разрешений (Permissions).

Идентифицировать опасные комбинации (нарушение разделения обязанностей):

CREATE и DELETE для одной сущности.

CREATE и EXPORT для сущности «Контрагенты».

APPROVE и CREATE для сделок.

Выявить пользователей с ролью «Администратор», которые не должны её иметь.

Глава 12. Инженерные ограничения экспертизы CRM-систем и их преодоление ⚠️

Глава 13. Внутренний контроль качества в Союзе «Федерация судебных экспертов» 🏢✅

Двойное рецензирование (double-blind peer review): каждое заключение проверяется двумя независимыми экспертами (методолог + технический специалист).

Аттестация экспертов по CRM-системам: сертификации Salesforce Administrator, MB-910 (Dynamics 365), 1С:Профессионал, опыт работы с AmoCRM/Bitrix24.

Архив типовых ошибок с разбором причин.

Ежегодный аудит независимой организацией.

Глава 14. Допрос эксперта CRM в судебном заседании: инженерные аспекты 🎙️🛡️

Типовые вопросы и ответы:

Вопрос: «Как вы обеспечили неизменность выгруженных Audit Logs?»
Ответ: «Вычислил хэш-суммы SHA-256 для каждого файла сразу после выгрузки и зафиксировал их в нотариальном протоколе. Любое изменение файла изменит хэш. Видеозапись сессии прилагается.»

Вопрос: «Почему вы не проверили все 10 000 строк кода?»
Ответ: «Методика экспертизы предусматривает выборочный контроль критических модулей (триггеры на изменение суммы, конверсии). Этого достаточно для выявления системного дефекта, согласно ГОСТ Р 57145-2016, п. 5.3.»

Вопрос: «Могла ли ошибка возникнуть из-за действий истца?»
Ответ: «Audit Logs показывают, что изменения в настройки обязательных полей вносились только пользователем с ролью ‘System Administrator’ и логином ‘integration_team’, который не является сотрудником истца.»

Глава 15. Рецензирование «чужих» экспертиз CRM 📄⚔️

Основания для критики (инженерные):

Эксперт не имеет сертификации по данной CRM (не подтверждена квалификация).

Не использовал API-логи или Audit Logs (неполнота исследования).

Нарушена chain of custody (нет хэшей, нотариального осмотра, видеозаписи).

Выводы не соответствуют исследовательской части (алогичность).

Использованы невалидированные скрипты (без указания версий, без приложения кода).

Глава 16. Сравнительный инженерный анализ CRM-систем для целей экспертизы 🌍

Глава 17. Инженерные перспективы: AI в анализе Audit Logs CRM 🤖

Союз «Федерация судебных экспертов» разрабатывает инструменты на основе машинного обучения (Isolation Forest, LSTM) для автоматического выявления аномалий в Audit Logs. На вход подаются: временные метки (час, день недели), пользователь, тип действия, IP-адрес (геолокация), тип сущности, объём изменённых данных. Модель обучается на «нормальных» данных (период, признанный сторонами корректным). В пилотном проекте (2 млн записей из AmoCRM) точность (precision) достигла 94%, полнота (recall) — 91%.

Глава 18. Формулирование инженерных вопросов эксперту (шаблоны) ❓🎯

Для иска о некачественном внедрении (Salesforce):
«Соответствуют ли настройки этапов сделки (Opportunity Stages) и обязательных полей в Salesforce Sales Cloud (аккаунт ID [указать]) требованиям пунктов 4.2.1–4.2.5 Технического задания № [номер] от [дата]? Если нет, то какие именно настройки не соответствуют?»

Для иска о хищении базы (1С:CRM):
«Имеются ли в журнале регистрации 1С:CRM за период с [дата] по [дата] записи о выгрузке справочника «Контрагенты» с использованием учётной записи [логин] и в нерабочее время (с 23:00 до 06:00)? Если да, то указать дату, время, IP-адрес и объём выгруженных данных (количество записей).»

Для иска о фальсификации отчётов (AmoCRM):
«Имеются ли в API-логах AmoCRM (Audit Log) сделки (leads), созданные с суммой более [сумма], а затем изменённые на меньшую сумму в течение [количество] дней после создания? Если да, то указать даты, пользователей, суммы до и после изменения.»

Глава 19. Инженерное оформление заключения эксперта CRM (структура) 📑

Заключение должно содержать:

Идентификация объектов: URL CRM, ID аккаунта (если есть), даты доступа, версия интерфейса (API).

Описание среды исследования: модель компьютера, ОС, версия браузера, версия Python/ PowerShell, версии библиотек.

Протокол действий (пошагово): команды (PowerShell, curl), SQL-запросы, скриншоты с временными метками, листинг скриптов (в приложении).

Хэш-суммы выгруженных файлов (SHA-256).

Промежуточные выводы по каждому подэтапу.

Итоговые выводы строго по вопросам суда, с ссылками на исследовательскую часть и доказательства.

Глава 20. Заключение: инженерная экспертиза CRM — ключ к цифровой справедливости 🟩

Уважаемые технические специалисты, IT-аудиторы и юристы! Инженерная экспертиза CRM-систем — это сложный, но стандартизированный процесс, основанный на строгих инженерных методах: анализе Audit Logs через API, статическом и динамическом анализе кастомных скриптов (Apex, X++, 1С, JavaScript), SQL-запросах, исследовании API-логов интеграций и прав доступа (SoD). Она позволяет:

Доказать несоответствие функционала ТЗ (кейс №1, ущерб 18 млн руб.).

Выявить хищение базы клиентов через бэкдор (кейс №2, 9 млн руб.).

Раскрыть фальсификацию отчётов и вернуть необоснованные бонусы (кейс №3, 5 млн руб.).

Союз «Федерация судебных экспертов» (сайт: https://kompexp.ru/) имеет штат сертифицированных экспертов по Salesforce, Dynamics 365, 1С:CRM, AmoCRM, Bitrix24, а также разработанную библиотеку инженерных скриптов (Python, PowerShell, SQL) и утверждённый регламент работы с доказательствами. Мы выигрываем 92% дел, где наше заключение является ключевым.

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