🟩 Экспертиза Microsoft Dynamics 365

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

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

Мы, эксперты Союза «Федерация судебных экспертов», специализируемся на экспертизе microsoft dynamics 365. В данной статье, написанной в методологическом стиле, мы представляем системный подход к исследованию Dynamics 365: от архитектуры Dataverse до анализа аудит-логов, API-логов Azure Monitor, резервных копий Microsoft и логов Power Automate. Три реальных кейса иллюстрируют применение разработанной методологии. 🔬⚖️

Глава 1. Архитектура Microsoft Dynamics 365 как объект экспертного исследования

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

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

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

Данные физически находятся на серверах Microsoft Azure в дата-центрах (в РФ — через локального провайдера, в ЕС — в Нидерландах/Ирландии).

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

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

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

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

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

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

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

Логи включают: метод (GET, POST, PUT, DELETE), endpoint, параметры, пользователя, IP-адрес, timestamp, response code.

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

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

Microsoft создаёт резервные копии всех баз данных Dataverse.

Срок хранения зависит от тарифного плана: от 7 до 35 дней (стандарт), для Premium — до 90 дней.

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

Уровень 5. Power Automate (Microsoft Flow) и Power Apps

Кастомные автоматизации могут создавать, обновлять, удалять и изменять данные.

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

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

Уровень 6. Azure Active Directory (AD) логи

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

Логи создания, изменения и удаления пользователей.

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

Уровень 7. Кастомные плагины и скрипты (JavaScript,.NET)

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

Может изменять данные в обход аудита (если не настроен аудит плагинов).

Экспертиза microsoft dynamics 365 требует понимания всех этих уровней и умения работать с каждым из них.

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

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

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

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

CreatedOn, CreatedBy (дата создания и автор)

ModifiedOn, ModifiedBy (дата изменения и автор)

DeletedOn, DeletedBy (дата удаления и автор — если аудит удаления включён)

AttributeName (имя изменённого поля)

OldValue, NewValue (старое и новое значение)

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

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

Sign-in logs: время, IP-адрес, устройство, приложение.

Audit logs: создание, изменение, удаление пользователей и групп.

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

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

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

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

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

Логи выполнения потоков: flow_name, run_start, trigger, action, input, output, user.

Логи ошибок выполнения.

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

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

Содержат удалённые записи (до перезаписи бэкапа).

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

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

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

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

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

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

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

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

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

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

API-логи из Azure Monitor.

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

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

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

timestamp: 02: 17: 33 UTC.

ip_address: 185.xxx.xx.xx (анонимный VPN).

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

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

xml

</filter>

</entity>

</fetch>

Результат: 1 234 записи на сумму 45 000 000 руб. Суммы совпали с первичными документами истца.

Этап 4. Кросс-валидация с логами Azure AD
Логи Azure AD показали, что учётная запись главного бухгалтера использовалась в ночь удаления с IP-адреса, который никогда не использовался ранее. СКУД подтвердил, что бухгалтер физически не был в офисе.

Вывод: установлен факт умышленного массового удаления счетов. Данные восстановлены из резервной копии Microsoft.

Экспертиза microsoft dynamics 365 успешно реализовала эту методологию.

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

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

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

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

В аудите изменений записи отсутствовали.

Подозрение пало на Power Automate.

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

Этап 1. Гипотеза
Power Automate может изменять данные от имени администратора, и такие изменения могут не попадать в стандартный аудит, если аудит для администратора отключён.

Этап 2. Анализ логов выполнения Power Automate
Через судебный запрос к Microsoft получены логи Azure Log Analytics. Обнаружен поток с именем «Discount_Automation»:

flow_name: Discount_Automation

flow_id: Z1234567

run_start: ежедневно в 00: 05 UTC

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

action: Update record (SalesOrder)

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

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

body: поле totalamount уменьшалось на случайный процент (5-15%)

Этап 3. Идентификация создателя потока
В логах Azure AD найдено, что поток был создан 01.01.2025 в 14: 32 учётной записью бывшего ИТ-директора. Последний вход в систему был за 3 дня до обнаружения проблемы.

Этап 4. Восстановление исходных сумм
Из логов выполнения потока восстановлены исходные значения totalamount (до изменения) для 5 678 заказов. Разница составила 23 млн руб., что подтверждено договорами истца.

Вывод: выявлен факт нештатной работы Power Automate.

Экспертиза microsoft dynamics 365 позволяет выявлять скрытые автоматизации.

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

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

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

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

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

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

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

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

Пункт 4.1 ТЗ (интеграция с 1С, задержка <5 минут): анализ логов Azure Service Bus показал задержку от 2 до 4 часов. Причина: пакетная обработка вместо событийной. Требование не выполнено.

Пункт 6.3 ТЗ (расчёт фактической себестоимости): создан тестовый производственный заказ, списание материалов — поле «Actual Cost» пустое. Причина: не настроены связи BOM и Work Order. Требование не выполнено.

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

Этап 4. Анализ переписки
Интегратор 14 раз перекладывал ответственность на Microsoft. Проверка документации Microsoft показала, что ни один из заявленных «багов» не подтвердился.

Вывод: интегратор нарушил условия договора и SLA.

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

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

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

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

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

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

Категория «Автоматизации Power Automate»:
4. Имеются ли в среде Power Automate потоки, выполняющие автоматическое изменение сумм заказов, счетов?
5. Кто создал эти потоки и когда?

Категория «Соответствие функционала»:
6. Соответствует ли фактически реализованный функционал системы требованиям технического задания?
7. Если нет, то какие именно пункты не соответствуют?

Категория «Нарушение SLA»:
8. Были ли нарушены интегратором обязательства по соглашению об уровне обслуживания (SLA)?

Экспертиза microsoft dynamics 365 даёт ответы на все эти вопросы.

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

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

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

Источник	Доступность	Метод извлечения
Аудит-логи Dataverse	Полный (если включён)	Power BI / FetchXML через Dataverse API
API-логи Azure Monitor	Через судебный запрос	Запрос к Microsoft
Логи Power Automate	Через судебный запрос	Azure Log Analytics
Логи Azure AD	Через судебный запрос	Azure Portal / Graph API
Резервные копии	Через судебный запрос	Запрос к Microsoft

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

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

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

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

Полученные данные проанализировать.

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

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

Процедура:

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

Суд выносит определение. Определение направляется в Microsoft.

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

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

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

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

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

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

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

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

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

Через API-логи (до 90 дней): факт удаления (100%).

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

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

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

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

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

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

Power BI — анализ аудит-логов.

Azure Log Analytics — анализ логов Power Automate.

FetchXML Builder — конструирование запросов.

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

Знание модели данных Dynamics 365.

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

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

Экспертиза microsoft dynamics 365 требует высокой квалификации.

Глава 11. Часто задаваемые методологические вопросы

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

Вопрос: Как долго Microsoft хранит резервные копии?
✅ Ответ: от 7 до 35 дней (стандарт), до 90 дней (Premium).

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

Вопрос: Стоит ли заказывать экспертизу при сумме иска менее 5 млн руб.?
✅ Ответ: Экономически может быть нецелесообразно. Окупается при иске от 3-5 млн руб.

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

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

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

Эмпирические значения (n=30):

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

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

C (средняя) = 500 000 руб.

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

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

Параметр	1С	SAP	Dynamics 365
Тип развёртывания	On-premise	On-premise / Cloud	Cloud (Azure)
Доступ к дискам	Есть	Есть	Нет
Аудит	Журнал регистрации	CDHDR/CDPOS	Audit Logs
Восстановление удалённых	Из свободных страниц	Из redo log	Из бэкапов MS
Сложность	Средняя	Высокая	Высокая

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

Разработан стандарт «СЭ-D365-2025» (проект):

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

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

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

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

Глава 15. Новые вызовы: Copilot, AI Builder, блокчейн

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

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

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

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

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

Выгрузить аудит-логи.

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

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

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

Шаг 3. Досудебное исследование (опционально)

Шаг 4. Подача ходатайства в суд

Шаг 5. Судебный запрос к Microsoft (при необходимости)

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

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

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

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

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

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

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

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