Научное введение: Microsoft Dynamics 365 как объект судебного анализа

Microsoft Dynamics 365 — это не просто ERP-система, а экосистема, объединяющая финансы (Finance), управление цепочками поставок (Supply Chain Management), продажи (Sales), обслуживание клиентов (Customer Service), производство (Manufacturing) и управление проектами (Project Operations). В отличие от традиционных on-premise систем, Dynamics 365 работает как в облачной модели (SaaS), так и в гибридной, что создаёт уникальные вызовы для судебной экспертизы. Данные хранятся в Dataverse (ранее Common Data Service) и SQL Azure, логи аудита фиксируют каждое изменение, но могут быть очищены, а резервные копии Microsoft хранятся ограниченное время. 🏗️☁️

Мы, эксперты Союза «Федерация судебных экспертов», специализируемся на компьютерно-технической экспертизе microsoft dynamics 365. В отличие от традиционных файловых систем или локальных СУБД, исследование Dynamics 365 требует применения комплекса методов: анализа аудит-логов Dataverse, изучения Power Automate и Power Apps, исследования интеграций через API, а также судебных запросов к Microsoft для получения резервных копий и телеметрии.

В настоящей статье, написанной в научном стиле, мы представляем методологию компьютерно-технической экспертизы Microsoft Dynamics 365 для целей судебного доказывания. Рассматриваются архитектурные особенности системы, классификация следовой информации, эмпирические методы восстановления удалённых и изменённых данных, а также три реальных кейса из нашей практики. 🔬⚖️

Глава 1. Теоретическая модель Microsoft Dynamics 365 как источника цифровых доказательств

1.1. Архитектурная модель и особенности экспертного доступа

Microsoft Dynamics 365 построен на платформе Dataverse (ранее Common Data Service), которая представляет собой облачную базу данных на основе Azure SQL. Данные хранятся в виде таблиц (entities), каждая запись имеет уникальный идентификатор GUID. Архитектурные особенности, значимые для экспертизы:

Уровень 1. Dataverse (облачная база данных)

Хранит все бизнес-данные: счета, заказы, контакты, продукты, движения.

Данные физически находятся на серверах Microsoft Azure в дата-центрах.

Прямой доступ к SQL-базе невозможен (только через API или Power Query).

Уровень 2. Аудит (Audit Logs)

Dynamics 365 ведёт аудит всех изменений: создание, обновление, удаление.

Аудит можно включить для отдельных таблиц и полей.

Логи аудита хранятся в специальных таблицах Dataverse и могут быть очищены пользователем с правами администратора.

Уровень 3. API-логи и телеметрия

Microsoft собирает логи всех API-вызовов (через Azure Monitor).

Логи доступны через судебный запрос (требуется санкция суда).

Уровень 4. Резервные копии Microsoft

Microsoft создаёт резервные копии всех баз данных. Срок хранения зависит от тарифного плана (от 7 до 35 дней).

Доступны только через судебный запрос.

Уровень 5. Power Automate и Power Apps

Кастомные автоматизации могут модифицировать данные.

Логи выполнения хранятся в Azure Log Analytics.

Уровень 6. Журналы клиентских приложений

Outlook, Teams, браузеры — могут содержать локальный кэш данных.

Уровень 7. Интеграции (через API, Logic Apps)

Логи на стороне клиента (если интегратор их вёл).

Компьютерно-техническая экспертиза microsoft dynamics 365 требует понимания всех этих уровней.

Глава 2. Классификация следовой информации в Dynamics 365

На основе анализа более 30 экспертиз Dynamics 365, проведённых Союзом «Федерация судебных экспертов» в 2022-2025 гг., выделена следующая классификация цифровых следов. 📊

Категория 1. Следы изменений данных (Audit Logs)

При включённом аудите каждая запись фиксирует:

Дату и время изменения (createdon, modifiedon)

Пользователя, выполнившего изменение (userid)

Имя таблицы и поля (entityname, attributename)

Старое и новое значение (oldvalue, newvalue)

Тип операции (Create, Update, Delete)

Ограничение: аудит можно выключить или очистить.

Категория 2. Следы действий пользователей (Azure AD logs)

Логи входа в систему: время, IP-адрес, устройство, приложение.

Хранятся 30 дней (бесплатный уровень) или дольше (по запросу).

Категория 3. Следы API-вызовов (Azure Monitor)

Все вызовы к API Dynamics 365 через REST/SOAP.

Содержат: метод, endpoint, параметры, пользователя, IP-адрес, ответ.

Категория 4. Следы автоматизаций (Power Automate, Power Apps)

Логи выполнения потоков (flows): кто запустил, когда, какой результат.

Категория 5. Кастомные плагины и скрипты (Plugins, JavaScript)

Код, выполняющийся на сервере или на клиенте.

Может изменять данные в обход аудита.

Категория 6. Резервные копии Microsoft

Полный снимок базы данных на определённую дату.

Категория 7. Интеграционные логи

Логи на стороне клиента (если интегратор их вёл).

Понимание этой классификации позволяет эксперту выбрать оптимальный маршрут исследования.

Глава 3. Кейс №1: Восстановление удалённых счетов после очистки аудит-логов

🔬 Научная проблема: Разработать метод восстановления удалённых финансовых транзакций (счетов-фактур) в Microsoft Dynamics 365 в условиях, когда аудит-логи были очищены, а стандартные средства восстановления отсутствуют.

Эмпирические условия:

АО «ТрейдИнвест» подало иск к ООО «СтройРесурс» о взыскании 45 млн рублей.

Ответчик заявил, что в его Dynamics 365 нет записей о поставках, а аудит-логи «потерялись».

Истец утверждал, что счета-фактуры были удалены.

Методология исследования 🔬

Этап 1. Анализ доступных источников
Аудит-логи в системе ответчика были пусты. Однако через судебный запрос к Microsoft получены:

Логи Azure AD (входы пользователей).

API-логи из Azure Monitor.

Резервная копия базы данных за 3 дня до удаления.

Этап 2. Анализ API-логов
В API-логах обнаружено 1 234 вызова DELETE /api/data/v9.2/invoices. Каждый вызов содержал:

user_id: учетная запись главного бухгалтера.

timestamp: 15.03.2025 02: 17: 33 UTC.

ip_address: 185.xxx.xx.xx (VPN).

request_id и response_code: 204 (успешное удаление).

Этап 3. Восстановление из резервной копии Microsoft
Резервная копия за 14.03.2025 извлечена через судебный запрос. Выполнен SQL-подобный запрос через Dataverse API:

text

SELECT invoiceid, totalamount, customerid, createdon

FROM Invoice

WHERE customerid = ‘ТрейдИнвест’ AND createdon > ‘2024-10-01’

Результат: 1 234 записи на сумму 45 000 000 руб.

Этап 4. Кросс-валидация
Сравнение восстановленных сумм с первичными документами истца показало расхождение менее 0,1% (погрешность округления).

Вывод: даже при очищенных аудит-логах, возможно восстановление данных из резервных копий Microsoft и API-логов.

Компьютерно-техническая экспертиза microsoft dynamics 365 успешно реализовала эту методологию.

Глава 4. Кейс №2: Выявление нештатной работы Power Automate, изменявшей суммы заказов

🔬 Научная проблема: Обнаружить автоматическое изменение сумм заказов в Dynamics 365, выполненное через Power Automate (Microsoft Flow), при отсутствии записей в стандартном аудите изменений (так как поток работал от имени администратора).

Эмпирические условия:

ООО «ЛогистикХаб» обнаружило, что суммы 5 678 заказов занижены на 23 млн руб.

В аудите изменений записи отсутствовали (поток работал от имени администратора, имеющего право отключать аудит для своих действий).

Методология исследования 🔬

Этап 1. Анализ логов выполнения Power Automate
В Azure Log Analytics (по судебному запросу) получены логи выполнения потоков:

flow_id: Z1234567

flow_name: «Discount_Automation»

run_start: 2025-02-15 00: 05: 22

trigger: Scheduled (еженощно)

action: Update record (SalesOrder)

user: Dynamics365 Admin (системная учётная запись)

Этап 2. Анализ входных и выходных данных потока
Для каждого выполнения потока в логах сохранены:

input: идентификатор заказа

body: новые значения полей (включая totalamount с уменьшением на 5-15%)

output: статус выполнения (success)

Этап 3. Сравнение с эталонными данными
Истец предоставил договоры и спецификации. Сравнение показало, что суммы в договорах соответствуют totalamount до изменения. Разница в 23 млн руб. подтверждена.

Этап 4. Анализ прав доступа
В логах Azure AD обнаружено, что учётная запись, создавшая поток, принадлежала уволенному администратору. Последний вход в систему был за 3 дня до обнаружения проблемы.

Вывод: выявлен факт нештатной работы Power Automate, изменявшей суммы заказов.

Компьютерно-техническая экспертиза microsoft dynamics 365 позволила установить причину убытков.

Глава 5. Кейс №3: Спор о некачественном внедрении Dynamics 365 и нарушении SLA

🔬 Научная проблема: Установить соответствие фактически реализованного функционала Microsoft Dynamics 365 требованиям технического задания и определить факт нарушения интегратором соглашения об уровне обслуживания (SLA).

Эмпирические условия:

АО «ПромСтрой» подало иск к интегратору о взыскании 12 млн руб. убытков.

Истец утверждал, что интеграция Dynamics 365 с 1С работает с ошибками, производственный модуль не отслеживает себестоимость продукции, а время реакции на критические инциденты превышает 72 часа (вместо 4 часов по SLA).

Методология исследования 🔬

Этап 1. Анализ технического задания
Изучено ТЗ объёмом 250 страниц. Выделены 18 пунктов, которые, по мнению истца, не выполнены.

Этап 2. Тестирование в песочнице
Эксперту предоставлен доступ к тестовому контуру. Проведена проверка:

Пункт ТЗ 4.1: «Интеграция с 1С должна передавать документы в реальном времени». Анализ логов Azure Service Bus показал задержку до 4 часов. Причина: интегратор использовал пакетную обработку вместо событийной.

Пункт ТЗ 6.3: «Производственный модуль должен рассчитывать фактическую себестоимость продукции». При создании производственного заказа поле «Actual Cost» оставалось пустым. Причина: не настроены связи между таблицами «BOM» и «Work Order».

Этап 3. Анализ SLA
Изучены журналы обращений в службу поддержки интегратора. Среднее время реакции на критические инциденты — 76 часов (при норме 4 часа). Максимальное — 120 часов.

Этап 4. Заключение
8 из 18 пунктов ТЗ не выполнены (критические нарушения). SLA нарушен.

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

Компьютерно-техническая экспертиза microsoft dynamics 365 — ключевой инструмент доказывания в спорах с интеграторами.

Глава 6. Типовые вопросы, которые ставит суд перед экспертом Dynamics 365

На основе анализа судебной практики выделены наиболее частые вопросы. 🗂️

Категория «Удаление/изменение данных»:

Имеются ли в системе Microsoft Dynamics 365 (в аудит-логах, API-логах, резервных копиях) следы удаления или изменения финансовых транзакций за период [период]?

Если да, то кем, когда и с какого IP-адреса были выполнены операции?

Возможно ли восстановить удалённые данные и определить их суммы?

Категория «Соответствие функционала»:
4. Соответствует ли фактически реализованный функционал системы требованиям технического задания №[номер] от [дата]?
5. Если нет, то какие именно пункты не соответствуют и в чём выражается несоответствие?

Категория «Нарушение SLA»:
6. Были ли нарушены интегратором обязательства по соглашению об уровне обслуживания (SLA)? Если да, то какие именно?
7. Повлияли ли выявленные нарушения на размер убытков истца?

Компьютерно-техническая экспертиза microsoft dynamics 365 даёт ответы на все эти вопросы.

Глава 7. Методология сбора доказательств в Dynamics 365

Сбор доказательств в облачной системе требует строгой последовательности. 📋

Доступные источники и методы извлечения:

Алгоритм сбора:

Запросить у стороны выгрузку аудит-логов (если не очищены).

Если аудит-логи очищены или недостаточны — подать судебный запрос к Microsoft.

В запросе указать: резервную копию на дату до удаления, API-логи за период, логи Power Automate (если есть подозрения).

Полученные данные проанализировать с помощью Dataverse API и Power Query.

Компьютерно-техническая экспертиза microsoft dynamics 365 невозможна без этих методов.

Глава 8. Судебный запрос к Microsoft как третьему лицу

Microsoft — крупная корпорация, и без судебного решения они не предоставят логи и бэкапы. ⚖️

Процедура:

Подать ходатайство об истребовании доказательств у Microsoft.

Суд выносит определение. Определение направляется в российское представительство Microsoft (ООО «Майкрософт Рус») или в штаб-квартиру в США (через Министерство юстиции).

Microsoft предоставляет данные в зашифрованном виде (срок — от 30 до 90 дней).

Сложности:

Microsoft может отказать, сославшись на коммерческую тайну других клиентов.

В случае отказа суд делает выводы в пользу истца (ст. 65 АПК РФ).

Глава 9. Ограничения методов (научная честность)

Честно называем границы. ⚠️

Когда восстановление невозможно:

Резервные копии Microsoft перезаписаны (стандартный срок — 7-35 дней).

Аудит был отключён, API-логи не сохранились, Power Automate не использовался.

Процент восстановления:

Через резервные копии (до 35 дней): 99-100%.

Через API-логи (до 90 дней): факт удаления (100%), содержимое — только если было в запросе.

Через аудит-логи (если не очищен): 100% изменений.

Всегда указываем эти ограничения в заключении.

Глава 10. Инструментарий эксперта Dynamics 365

Технические средства, необходимые для экспертизы. 🛠️

Программное обеспечение:

Dataverse API (Web API,.NET SDK) — программное извлечение данных.

Power BI — анализ выгруженных аудит-логов.

Power Automate — для автоматизации сбора данных.

Azure Log Analytics — анализ логов выполнения потоков.

Excel / Power Query — для обработки больших объёмов.

Требования к эксперту:

Знание модели данных Dynamics 365 (таблицы, связи, типы).

Умение писать FetchXML и LINQ-запросы.

Опыт работы с Dataverse API.

Понимание процесса судебного запроса к Microsoft.

Глава 11. Часто задаваемые научные вопросы

Вопрос: Можно ли восстановить удалённую запись в Dynamics 365 штатными средствами?
✅ Ответ: Нет. Штатных средств восстановления нет. Только через резервные копии Microsoft (судебный запрос).

Вопрос: Как долго Microsoft хранит резервные копии?
✅ Ответ: Зависит от тарифного плана: от 7 до 35 дней. Уточняется в договоре.

Вопрос: Может ли эксперт определить, кто удалил данные, если аудит очищен?
✅ Ответ: Да, через API-логи Azure Monitor (сохраняются до 90 дней).

Вопрос: Что делать, если оппонент использует Dynamics 365 Business Central (on-premise)?
✅ Ответ: Экспертиза отличается (есть доступ к дискам и SQL Server). Уточняйте при заказе.

Вопрос: Какова научная обоснованность методов?
✅ Ответ: Методы основаны на официальной документации Microsoft, стандартах ISO/IEC 27037 и нашей многолетней практике.

Глава 12. Экономическая эффективность экспертизы Dynamics 365

Модель ожидаемой полезности. 💰

Формула: EV = S × q — C — (1-q) × F, где:

S — сумма иска,

q — вероятность выигрыша с экспертизой,

C — стоимость экспертизы,

F — судебные расходы.

Эмпирические значения (по нашей статистике, n=30):

q (с нашей экспертизой) = 0,95

q (без экспертизы) = 0,30

C (средняя сложность) = 500 000 руб.

Пример (иск 20 млн руб.):
EV(с экспертизой) = 20×0,95 — 0,5 — 0,05×0,2 = 19 — 0,5 — 0,01 = 18,49 млн руб.
EV(без экспертизы) = 20×0,30 — 0 — 0,70×0,2 = 6 — 0,14 = 5,86 млн руб.

Чистый выигрыш: 12,63 млн руб.

Экспертиза окупается многократно.

Глава 13. Сравнительный анализ: Dynamics 365 vs 1С vs SAP

Компьютерно-техническая экспертиза microsoft dynamics 365 требует облачных методов.

Глава 14. Стандартизация методик и проблема воспроизводимости

Одна из ключевых проблем — низкая воспроизводимость у разных экспертов. Мы предлагаем решение. 📏

Стандарт «СЭ-D365-2025» (проект, разработанный Союзом «Федерация судебных экспертов»):

Раздел 1. Требования к изъятию данных (судебный запрос, логирование).

Раздел 2. Методика анализа аудит-логов Dataverse.

Раздел 3. Методика анализа API-логов Azure Monitor.

Раздел 4. Методика анализа резервных копий Microsoft.

Раздел 5. Требования к оформлению заключения.

Статус: стандарт прошёл общественное обсуждение в СРО.

Глава 15. Новые вызовы: искусственный интеллект и блокчейн в Dynamics 365

Научно-технический прогресс ставит новые задачи. 🔮

Тренд 1. Искусственный интеллект (Dynamics 365 Copilot, AI Builder)
AI может генерировать фальшивые проводки. Экспертиза будет выявлять статистические аномалии.

Тренд 2. Квантовая криптография
Пост-квантовые алгоритмы подписи.

Тренд 3. Блокчейн-интеграции (Azure Blockchain)
Некоторые транзакции могут нотаризироваться в блокчейне.

Мы инвестируем 20% годового бюджета в R&D.

Глава 16. Алгоритм действий при подготовке к экспертизе

Шаг 1. Сохранение данных

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

Сохранить логи интеграций.

Зафиксировать время обнаружения проблемы.

Шаг 2. Консультация с экспертом
Бесплатно.

Шаг 3. Досудебное исследование (опционально)
Быстро, дёшево.

Шаг 4. Подача ходатайства в суд
С нашими формулировками вопросов.

Шаг 5. Проведение судебной экспертизы
Включая судебный запрос к Microsoft.

Шаг 6. Использование заключения в суде

Глава 17. Процессуальные особенности

Эксперт предупреждается об уголовной ответственности по ст. 307 УК РФ. Заключение является самостоятельным доказательством (ст. 64 АПК РФ). При отказе стороны предоставить доступ — суд делает выводы против неё (ст. 65 АПК РФ).

Глава 18. Заключение: научный подход как гарантия истины

Три кейса показали возможности компьютерно-технической экспертизы microsoft dynamics 365:

✅ Восстановление удалённых счетов из резервных копий Microsoft (45 млн руб.).
✅ Выявление нештатной работы Power Automate (23 млн руб.).
✅ Доказательство нарушения SLA и несоответствия ТЗ (12 млн руб.).

🟩 Мы — Союз «Федерация судебных экспертов». Сайт: https://kompexp.ru/
Специализируемся на экспертизе Dynamics 365, Power Platform и интеграций. Бесплатная консультация.

Облако не защищает от правосудия. Научная экспертиза достанет истину и оттуда. 🔧⚖️