Инженерные методы, анализ артефактов и практика доказывания

Инженерное введение: Microsoft Dynamics 365 как сложный объект судебного исследования ⚙️

Microsoft Dynamics 365 — это экосистема, объединяющая ERP (финансы, управление цепочками поставок, проекты) и CRM (продажи, обслуживание клиентов, маркетинг) в единой платформе, построенной на базе Dataverse (ранее Common Data Service), Azure и Power Platform. Её архитектурная сложность — глубокая интеграция с облачными сервисами Microsoft (Azure Active Directory, Azure Monitor, Power Automate, Power Apps, Logic Apps), наличие собственного языка для расширений (C# плагины, JavaScript/TypeScript для веб-ресурсов, Power Fx для Power Apps), а также возможность on-premise развёртывания (Dynamics 365 Customer Engagement on-premises) — создаёт уникальные вызовы для инженерной экспертизы.

🔬 В отличие от классических ERP (SAP, 1С), где эксперт может получить прямой доступ к серверам, в Dynamics 365 (cloud) вся работа ведётся через API, журналы аудита и потоки телеметрии. Это требует от эксперта владения методами анализа REST API, Azure Monitor Logs, Change Tracking и статического анализа C#-кода плагинов.

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

Глава 1. Инженерная архитектура Dynamics 365: уровни и артефакты 🏗️

Dynamics 365 имеет многоуровневую архитектуру, каждый уровень генерирует уникальные инженерные артефакты:

Ключевое различие: в облачной модели эксперт работает через API и встроенные инструменты аудита; в on-premise модели эксперт может получить прямой доступ к SQL Server и файловой системе.

Глава 2. Инженерная методология анализа Audit History Dynamics 365 📊

Audit History — это основной источник доказательств. Инженерный анализ включает:

2.1. Включение и настройка аудита.
Аудит должен быть включен на уровне сущностей (например, Order, Invoice, Account) и полей. Это делается через Power Platform Admin Center или через API. Если аудит был выключен — доказательств может не быть.

2.2. Выгрузка Audit History через API.
Используем Web API Dataverse. Пример запроса на C# (PowerShell):

powershell

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

$headers = @{«Authorization» = «Bearer $accessToken»}

$response = Invoke-RestMethod -Uri $url -Headers $headers

Выгружаем записи за необходимый период. Максимальный период хранения — 90 дней (можно продлить через платные лицензии).

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

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

UserId — GUID пользователя.

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

ObjectId — GUID записи.

ObjectTypeCode — тип сущности.

Attributes — изменённые поля (старые и новые значения).

ClientIp — IP-адрес (доступен не во всех версиях).

2.4. Инженерные методы анализа:

Временной анализ: поиск действий в нерабочее время (23: 00-06: 00).

IP-адресный анализ: группировка по IP. Если пользователь работает с разных IP в короткий промежуток времени — возможна компрометация.

Полевой анализ: частые изменения критических полей (totalamount, priceperunit) — признак фальсификации.

Статистический анализ: вычисление z-score для ежедневной активности. Дни с z > 3 — аномалии.

Глава 3. Инженерный анализ плагинов Dynamics 365 (C#) 📝

Плагины — это скомпилированные.NET-сборки (DLL), которые выполняются на сервере Dataverse. Они могут быть синхронными (до сохранения записи) или асинхронными.

3.1. Извлечение плагинов.
Плагины хранятся в базе данных Dataverse. Извлечь их можно через Plugin Registration Tool (из SDK) или через API. Команда:
PluginRegistration.exe /extract /pluginassembly: «assembly_name» /output: «C: \plugins»

3.2. Декомпиляция и статический анализ.
Используем ILSpy, dotPeek или dnSpy для декомпиляции DLL в C#-код.

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

InvalidPluginExecutionException с сокрытием ошибок.

context.PreEntityImages и context.PostEntityImages для обхода аудита.

service.Update с нефильтрованными данными.

ExecuteMultipleRequest для массовых операций.

HTTP-запросы через WebClient или HttpClient на внешние URL.

3.3. Анализ логов выполнения.
Логи плагинов можно получить через Azure Monitor (в облаке) или через трассировку (Plugin Trace Log). Пример запроса к Application Insights:

text

traces | where severityLevel == 3 | where message contains «Plugin»

Глава 4. Инженерный анализ Power Automate (Microsoft Flow) 🔄

Power Automate — это облачная платформа автоматизации, которая может выполнять действия от имени пользователя.

4.1. Выгрузка истории запусков.
Через Power Platform Admin Center или через API. Каждый запуск содержит:

startTime и endTime.

trigger (что запустило).

actions (последовательность действий с входными/выходными данными).

status (Succeeded, Failed, Canceled).

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

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

Потоки, отправляющие данные на внешние URL (действие HTTP).

Потоки, запущенные ночью.

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

Потоки с большим объёмом обрабатываемых записей (более 1000 строк за раз).

4.3. Анализ данных, передаваемых через HTTP-коннектор.
HTTP-коннектор может отправлять данные на любой URL. Логи сохраняют заголовки запросов и тело (если не отключено). Ищем IP-адреса, не принадлежащие организации.

Глава 5. Инженерный анализ Change Tracking (Dataverse) 🔄

Change Tracking — это механизм, позволяющий отслеживать изменения записей. Он доступен через API и может хранить историю дольше, чем Audit History (до 90 дней по умолчанию).

5.1. Выгрузка Change Tracking.
API-запрос:
GET [Organization URI]/api/data/v9.2/accounts?$select=name,accountid&$filter=modifiedon ge 2024-01-01

5.2. Восстановление удалённых записей.
Change Tracking фиксирует удаления (но не старые значения). Для полного восстановления нужно использовать другие источники (логи плагинов, Azure Monitor).

Глава 6. Инженерный анализ логов Azure Monitor и Application Insights 📈

Azure Monitor — это централизованное хранилище логов для всех сервисов Microsoft.

6.1. Типы логов:

SigninLogs — входы пользователей (Azure AD).

AuditLogs — изменения в Azure AD.

DataverseOperations — операции с Dataverse.

AppTraces — трассировка плагинов.

Requests — HTTP-запросы к API.

6.2. KQL-запросы (Kusto Query Language).
Пример: поиск всех действий пользователя user@company.com за последние 30 дней:

kql

SigninLogs

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

| project TimeGenerated, IPAddress, AppDisplayName, Status

6.3. Выявление аномалий через KQL.

Входы с необычных IP.

Частые ошибки авторизации (признак подбора пароля).

Массовые экспорты данных (много запросов с $select=*).

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

Если Dynamics 365 развёрнут on-premise (Dynamics 365 Customer Engagement on-premises), эксперт может получить прямой доступ к серверу.

7.1. Изъятие данных с SQL Server.

Создание битового образа диска с помощью write-blocker.

Копирование файлов.mdf (данные) и.ldf (журнал транзакций).

Анализ.ldf через fn_dblog(NULL, NULL) для восстановления удалённых записей.

7.2. Анализ журналов IIS.
IIS (Internet Information Services) логирует все HTTP-запросы к веб-приложению Dynamics 365. Логи содержат: дату, время, IP-адрес клиента, метод, URL, статус ответа. Эти логи невозможно очистить из Dynamics 365.

7.3. Анализ Event Log (Windows).
События безопасности (Event ID 4624 — успешный вход, 4625 — неудачный вход) фиксируются в журнале Security. Они показывают, кто и когда заходил на сервер.

Глава 8. Три инженерных кейса из практики 🔥

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

Выгрузка Audit History. Обнаружено 347 изменений цены ночью (23: 00-05: 00).

Извлечение и декомпиляция плагинов. Найден плагин PriceChangerPlugin, содержащий:

csharp

if (customer.Rating == «Gold») {

entity[«priceperunit»] = (decimal)oldPrice * 0.75m;

}

Анализ логов выполнения (Azure Monitor): плагин запускался в те же даты и время, что и изменения.

IP-адресный анализ: создатель плагина — менеджер, изменения с его домашнего IP.
Результат: Иск на 12,5 млн рублей удовлетворён.

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

Доступ к SQL Server (on-premise). Создание образа диска.

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

Анализ Event Log: вход CFO в 03: 00 за день до удаления.

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

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

Анализ логов Power Automate: найден поток CustomerDataExport, запуск по пятницам в 03: 00.

Код потока: FetchXML-запрос к Dataverse, затем HTTP POST на IP 185.xxx.xxx.xxx.

Владелец потока — уволенный IT-сотрудник.

Azure Monitor: 14 успешных выгрузок по 1 ГБ.
Результат: Суд взыскал 15 млн рублей.

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

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

Модель 1. Вероятность скриптовой активности.
P_script = 1 — (1 — 1/Δt)^N, где Δt — минимальный интервал между действиями. При Δt = 2 секунды, N=1000, P ≈ 1.

Модель 2. Z-score для выявления аномальных дней.
z = (x — μ) / σ, z > 3 → аномалия.

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

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

Создание read-only пользователя (эксперт).

Фиксация даты и времени.

Выгрузка Audit History через API.

Выгрузка всех плагинов (DLL + декомпиляция).

Выгрузка истории запусков Power Automate.

Выгрузка логов Azure Monitor (KQL).

Для on-premise: изъятие дисков с write-blocker.

Составление протокола с хеш-суммами (SHA-256).

Глава 12. Типичные инженерные ошибки при анализе Dynamics 365 ❌

Глава 13. Сравнение Dynamics 365 (cloud) и on-premise для экспертизы 📊

Глава 14. Подготовка экспертного заключения для суда 📄

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

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

Chain of custody (хеш-суммы, протоколы).

Методологию (какие методы, какие инструменты).

Исследование (поэтапно, с формулами, скриншотами).

Выводы (категоричные ответы на вопросы).

Приложения (выгрузки, скриншоты, диаграммы).

Глава 15. Пошаговый алгоритм для юриста (инженерный подход) 📋

Фиксация проблемы → 2. Обеспечительные меры (арест облачного аккаунта) → 3. Ходатайство о назначении экспертизы (согласовать вопросы) → 4. Организация доступа (read-only) → 5. Экспертиза (30-60 дней) → 6. Заключение → 7. Допрос эксперта → 8. Решение суда.

Инженерное заключение 🎓

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