Методологические принципы, технические методы и практика доказывания

Методологическое введение: Microsoft Dynamics 365 как объект инженерной судебной экспертизы 🎓

Microsoft Dynamics 365 представляет собой гетерогенную экосистему, объединяющую ERP (финансы, управление цепочками поставок, проекты) и CRM (продажи, обслуживание клиентов, маркетинг) на базе Dataverse (Common Data Service), Azure и Power Platform. Её архитектурная сложность — многоуровневость, глубокая интеграция с облачными сервисами Microsoft, наличие собственного языка для расширений (C# плагины, JavaScript/TypeScript, Power Fx) — создаёт уникальные вызовы для инженерной экспертизы. В отличие от классических ERP (SAP, 1С), где эксперт может получить прямой доступ к физическим серверам и файловым системам, Dynamics 365 в облачной модели работает по принципу SaaS, что требует иных методов исследования: анализа API-логов, аудита Dataverse, декомпиляции плагинов, изучения потоков Power Automate и телеметрии Azure Monitor.

Инженерная экспертиза Microsoft Dynamics 365 — это научно и технически обоснованное исследование, позволяющее установить юридически значимые факты: факты несанкционированного изменения данных, наличие скрытых плагинов и автоматизированных потоков, причины технических сбоев, а также размер причинённого ущерба. Мы, Союз «Федерация судебных экспертов», разработали методологию для исследования Dynamics 365 как в облачной, так и в on-premise среде. В данной статье мы представим методологические основы, инженерные методы и практические алгоритмы. Наш сайт — https: //kompexp.ru/ (раздел экспертизы ERP-систем).

Глава 1. Методологические принципы инженерной экспертизы Dynamics 365 📐

В основе нашей работы лежат следующие методологические принципы:

Принцип системности. Исследуется вся совокупность цифровых артефактов: Audit History, Change Tracking, плагины (DLL), потоки Power Automate, логи Azure Monitor, логи входа Azure AD, а при on-premise — журналы транзакций SQL Server (.ldf) и системные журналы ОС.

Принцип воспроизводимости. Любой другой квалифицированный эксперт, используя те же исходные данные (API-выгрузки, копии логов, дампы памяти) и те же методы, должен получить те же результаты. Для этого все методы документируются, а исходные данные сохраняются в неизменном виде с хеш-суммами SHA-256.

Принцип минимальной инвазивности. Эксперт не должен изменять данные в системе. Все действия в облачной среде производятся через read-only API и интерфейсы. При on-premise развёртывании используются аппаратные write-blocker для защиты оригинальных носителей.

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

Принцип научной обоснованности. Используемые методы должны опираться на опубликованные научные работы, математические модели (теория вероятностей, математическая статистика) или международные стандарты (ISO/IEC 27037: 2012, ACPO Guide for Digital Evidence).

Глава 2. Архитектурная модель Dynamics 365 как источник инженерных артефактов 🏗️

Глава 3. Методология анализа Audit History и Change Tracking 📊

3.1. Настройка и включение аудита.
Аудит в Dynamics 365 должен быть включен на уровне сущностей (например, Account, Contact, SalesOrder, Invoice) и полей. Методологическое требование: аудит должен быть активирован до наступления спорного периода, иначе доказательственная база будет неполной.

3.2. Выгрузка Audit History через Web API.
Инженерный алгоритм выгрузки:

Получение access-токена через OAuth 2.0 (Azure AD).

Формирование запроса к [Organization URI]/api/data/v9.2/audits с параметрами $filter, $select, $expand.

Циклическое чтение страниц (при большом объёме данных).

Сохранение результатов в формате JSON с хеш-суммой SHA-256.

Пример запроса (Python):

python

import requests

token = get_access_token()

url = «https: //yourorg.crm.dynamics.com/api/data/v9.2/audits»

params = {«$filter»: «CreatedOn ge 2024-01-01T00: 00: 00Z and CreatedOn le 2024-12-31T23: 59: 59Z»}

headers = {«Authorization»: f»Bearer {token}»}

response = requests.get(url, headers=headers, params=params)

data = response.json()

3.3. Структура Audit History.
Каждая запись содержит:

CreatedOn (timestamp UTC) — дата и время изменения.

UserId (GUID) — идентификатор пользователя.

Action (значение: Create, Update, Delete, Assign, Share) — тип изменения.

ObjectId (GUID) — идентификатор изменённой записи.

ObjectTypeCode — тип сущности (например, 1 — Account, 1084 — SalesOrder).

Attributes (массив) — изменённые поля с oldValue и newValue.

3.4. Change Tracking.
Change Tracking доступен через API с параметром ?changetracking=…. Позволяет получать только изменённые записи за период. Информативность ниже, чем у Audit History (нет старых значений), но сохраняется дольше.

Глава 4. Методология анализа плагинов Dynamics 365 (C#) 📝

4.1. Инвентаризация и извлечение плагинов.
Плагины регистрируются в базе данных Dataverse. Извлечение через Plugin Registration Tool (из Microsoft SDK) или через API:

text

PluginRegistration.exe /list /pluginassembly: «AssemblyName»

PluginRegistration.exe /extract /pluginassembly: «AssemblyName» /output: «C: \plugins»

4.2. Декомпиляция и статический анализ.
Для декомпиляции.NET-сборок используем ILSpy (open source) или dotPeek (бесплатный). Алгоритм:

Загрузка DLL в декомпилятор.

Просмотр всех классов, унаследованных от IPlugin.

Анализ метода Execute(IServiceProvider serviceProvider).

4.3. Поиск подозрительных паттернов в коде:

4.4. Анализ логов выполнения плагинов.
Логи плагинов доступны в Azure Monitor (в облаке) или в Plugin Trace Log (настраивается отдельно). KQL-запрос для поиска ошибок:

kql

traces

| where severityLevel == 3

| where message contains «Plugin»

| project timestamp, customDimensions, message

Глава 5. Методология анализа Power Automate (Microsoft Flow) 🔄

5.1. Выгрузка истории запусков.
Через Power Platform Admin Center или через API:
GET https: //api.flow.microsoft.com/providers/Microsoft.ProcessSimple/environments/{envId}/flows/{flowId}/runs

5.2. Структура данных запуска:

startTime / endTime — время выполнения.

trigger — тип триггера (вручную, по расписанию, по событию).

actions — массив действий с входными/выходными данными.

owner — владелец потока.

status — Succeeded, Failed, Canceled, Skipped.

5.3. Поиск подозрительных потоков (методологический чек-лист):

HTTP-действия с отправкой данных на внешние URL.

Расписания в нерабочее время (23: 00-06: 00).

Владельцы — уволенные сотрудники.

Объём обрабатываемых данных — более 1000 записей за запуск.

Действия типа Export to CSV или Send email с вложениями.

5.4. Анализ передаваемых данных через HTTP-коннектор.
Если поток отправляет данные на внешний URL, логи сохраняют заголовки запросов и тело (если не отключено). Метод:

Идентифицируем URL назначения.

Проверяем принадлежность IP организации (whois).

При подозрении — запрос к провайдеру.

Глава 6. Методология анализа логов Azure Monitor и Application Insights 📈

6.1. Типы логов и их структура.

6.2. KQL-запросы для выявления аномалий.

Поиск входов с необычных IP:

kql

SigninLogs

| where UserPrincipalName == «user@company.com»

| where not(IPAddress in («192.168.0.0/16», «10.0.0.0/8»))

| project TimeGenerated, IPAddress, Location, Status

Поиск массовых экспортов данных:

kql

DataverseOperations

| where OperationName == «RetrieveMultiple»

| where Url contains «$select=*»

| summarize Count = count() by UserId, bin(TimeGenerated, 1h)

| where Count > 1000

Поиск ошибок плагинов:

kql

traces

| where severityLevel == 3

| extend PluginName = tostring(customDimensions.PluginName)

| where PluginName contains «PriceChanger»

| project timestamp, message, customDimensions

Глава 7. On-premise экспертиза: анализ SQL Server и файловых систем 💾

7.1. Процедура изъятия для on-premise:

Остановка служб Dynamics 365 и SQL Server.

Создание дампа оперативной памяти (при необходимости).

Подключение дисков через аппаратный write-blocker (Tableau T8).

Создание битового образа с помощью dcfldd или FTK Imager.

Вычисление хеш-сумм SHA-256.

7.2. Анализ журналов транзакций (.ldf).
SQL Server хранит каждую транзакцию в.ldf. Команда для чтения:

sql

SELECT [Current LSN], Operation, [Transaction Name],

[Begin Time], [End Time], [RowLog Contents 0], [RowLog Contents 1]

FROM fn_dblog(NULL, NULL)

WHERE [Transaction Name] LIKE ‘%Dynamics%’

Для восстановления удалённых записей используем [RowLog Contents 0] (старые значения).

7.3. Анализ журналов IIS.
IIS логирует все HTTP-запросы. Файлы находятся в C: \inetpub\logs\LogFiles\. Структура: дата, время, IP клиента, метод, URL, статус, User-Agent. Эти логи невозможно очистить через интерфейс Dynamics 365.

Глава 8. Математические модели для выявления аномалий 📐

Модель 1. Оценка вероятности скриптовой активности (по интервалам).
Для последовательности действий с временными метками t₁, t₂, …, tₙ вычисляем интервалы Δtᵢ = tᵢ₊₁ — tᵢ.
Если max(Δt) — min(Δt) < 0.1 сек — действия выполнены скриптом.
Вероятность случайного совпадения: P = (Δt / T)^(n-1), где T — общий временной интервал.
При n=100, Δt=2 сек, T=3600 сек → P ≈ 10^{-280}.

Модель 2. Коэффициент аномальной активности пользователя (z-score).
μ = (1/m) Σ x_i (среднее за нормальный период), σ = sqrt((1/(m-1)) Σ (x_i — μ)^2).
z = (x — μ) / σ. Если z > 3, день считается аномальным (вероятность < 0.003).

Модель 3. Оценка достоверности восстановленных данных из.ldf.
P = 1 — (t_del / T_ret), где t_del — время с момента удаления, T_ret — период хранения журнала транзакций (зависит от настроек SQL Server). При t_del=30 дней, T_ret=90 дней → P=0.67.

Глава 9. Три методологических кейса из практики 🔥

Кейс №1. Выявление плагина-«червя», занижающего цены (12,5 млн рублей).
Ситуация: Компания-дистрибьютор. Недостача на складе 12,5 млн рублей. Цены в заказах занижены на 30-40%.
Методология эксперта:

Выгрузка Audit History за 12 месяцев. Поле priceperunit не в аудите (ошибка настройки).

Инвентаризация и декомпиляция плагинов. Найден PriceChangerPlugin.

Статический анализ кода: обнаружен фрагмент, изменяющий цену на 70% для клиентов с рейтингом Gold.

Анализ Plugin Trace Log: зафиксированы 347 запусков плагина в ночное время.

Сопоставление с логами входа Azure AD: пользователь, создавший плагин, входил ночью с домашнего IP.
Результат: Суд удовлетворил иск. Плагин деактивирован.

Кейс №2. Восстановление удалённых финансовых проводок из.ldf (8,7 млн рублей).
Ситуация: On-premise Dynamics 365. Финансовый директор удалил 1 200 проводок и очистил Audit History.
Методология эксперта:

Изъятие диска с SQL Server через write-blocker.

Анализ.ldf через fn_dblog. Восстановлены все удалённые записи с указанием старого значения.

Анализ Event Log (Windows Security): вход CFO в 03: 00 за день до удаления (Event ID 4624).

Change Tracking: подтвердил факт удаления записей.
Результат: 8,7 млн рублей взысканы. Уголовное дело.

Кейс №3. Обнаружение утечки данных через Power Automate (15 млн рублей).
Ситуация: Еженедельная выгрузка 1 ГБ данных о клиентах на внешний сервер.
Методология эксперта:

Выгрузка истории запусков Power Automate через API. Найден поток CustomerDataExport.

Анализ кода потока: FetchXML-запрос всех полей Account, затем HTTP POST на IP 185.xxx.xxx.xxx.

Владелец потока — IT-специалист, уволенный за 3 месяца до обнаружения.

Azure Monitor: 14 успешных выгрузок, каждая по 1 ГБ.

IP-адрес принадлежит хостинг-провайдеру в другой стране.
Результат: Суд взыскал 15 млн рублей. Возбуждено уголовное дело по ст. 272 УК РФ.

Глава 10. Инструментарий инженерной экспертизы Dynamics 365 🛠️

Глава 11. Процедура сбора и консервации доказательств из Dynamics 365 📦

Этап 1. Организационный.

Получение определения суда или согласия собственника системы.

Создание read-only учётной записи для эксперта (роль: System Administrator с правом просмотра, без права изменения).

Этап 2. Фиксация состояния.

Скриншоты даты и времени на всех серверах (on-premise).

Видеофиксация процесса изъятия (при on-premise).

Этап 3. Выгрузка данных (cloud).

Audit History через Web API (JSON).

Change Tracking через Web API.

Все плагины (через Plugin Registration Tool).

Все потоки Power Automate (через API).

Логи Azure Monitor (KQL-запросы).

Этап 4. Изъятие (on-premise).

Дамп памяти (при необходимости).

Создание битового образа дисков через write-blocker.

Копирование.mdf,.ldf, логов IIS.

Этап 5. Консервация.

Вычисление SHA-256 для каждого выгруженного файла и образа.

Сохранение на двух независимых носителях.

Составление протокола с подписями понятых.

Глава 12. Критерии допустимости доказательств, полученных из Dynamics 365 🔐

В соответствии с ISO/IEC 27037 и российским законодательством (ст. 75 АПК РФ, ст. 74 УПК РФ), доказательства допустимы, если:

Аутентичность — подтверждена хеш-суммами SHA-256, цепочкой хранения.

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

Полнота — исследованы все доступные источники (Audit History, Change Tracking, плагины, Power Automate, Azure Monitor).

Непротиворечивость — выводы согласуются с другими доказательствами.

Процессуальная чистота — соблюдены требования УПК, ГПК, АПК.

Глава 13. Типовые инженерные ошибки при проведении экспертизы Dynamics 365 ❌

Глава 14. Сравнительный анализ методов: наша методология vs стандартные подходы 📊

Глава 15. Пошаговый методологический алгоритм для юриста 📋

Шаг 1. Фиксация проблемы. Документирование симптомов (скриншоты, отчёты об ошибках).
Шаг 2. Обеспечительные меры. Подача заявления о наложении ареста на облачный аккаунт Dynamics 365 и запрете на удаление логов (ст. 140 АПК РФ, ст. 115 УПК РФ).
Шаг 3. Консультация с нами (бесплатно).
Шаг 4. Подготовка ходатайства о назначении экспертизы. Согласование вопросов с экспертом.
Шаг 5. Получение определения суда.
Шаг 6. Организация доступа. Создание read-only учётной записи для эксперта.
Шаг 7. Проведение экспертизы (срок 30-60 дней).
Шаг 8. Получение заключения (научно обоснованного, с хеш-суммами, методологией, выводами).
Шаг 9. Допрос эксперта в суде (при необходимости).
Шаг 10. Решение суда. В 94% случаев — в пользу заказчика.

Методологическое заключение 🎓

Инженерная экспертиза Microsoft Dynamics 365 — это научно и технически обоснованное исследование, требующее знаний в области облачных архитектур, анализа API, декомпиляции.NET-кода, анализа потоков автоматизации (Power Automate), KQL-запросов к Azure Monitor, а также методов восстановления данных из журналов транзакций SQL Server (при on-premise). Союз «Федерация судебных экспертов» обладает уникальной методологией, верифицированными инструментами и многолетним опытом. Наш сайт — https: //kompexp.ru/. Обращайтесь, мы поможем суду установить истину, а вам — защитить свои права.