Инженерное руководство по расследованию цифровых преступлений

Введение: когда бизнес-процессы превращаются в лабиринт для эксперта

Представьте себе город, где каждый дом построен по собственным чертежам, дороги не имеют карты, а жители говорят на разных языках. Так выглядит современная корпоративная информационная система (КИС) крупного предприятия. Здесь ERP-система (SAP, 1С, Oracle) разговаривает на языке транзакций, CRM (Salesforce, HubSpot) — на языке клиентов, BI (Power BI, Tableau) — на языке дашбордов, а интеграционная шина (Azure Service Bus, Kafka) выступает в роли разноязычного переводчика. Добавьте сюда Data Warehouse, ETL-процессы (Azure Data Factory, SSIS), системы контроля версий, Active Directory, и вы получите цифрового монстра, в котором за день теряются миллионы. 🦾

Когда в этой экосистеме происходит сбой — данные теряются, отчёты врут, базы клиентов уплывают к конкурентам, — найти виноватого почти невозможно. Бухгалтер скажет: «Это ERP глючит». Администратор ERP: «Это интегратор плохо настроил». Интегратор: «Это ваши данные кривые». А в это время убытки растут. Корпоративных информационных систем (КИС) — это инженерная дисциплина, которая позволяет проникнуть в самое сердце цифрового лабиринта и восстановить объективную картину событий. Союз «Федерация судебных экспертов» представляет техническое руководство по расследованию инцидентов в КИС. Три реальных кейса покажут, как работает эта методология на практике. 🛠️

Глава 1. Архитектурная декомпозиция КИС как многоуровневой системы

Корпоративная информационная система — это не монолит. Это иерархия уровней, каждый из которых имеет свою модель данных, свои журналы и свои уязвимости. Эксперт, проводящий Корпоративных информационных систем (КИС), обязан владеть инструментарием для исследования каждого уровня. 🏗️

Уровень 1: Источники данных (Data Sources). Транзакционные системы: ERP (SAP, 1С, Dynamics, Oracle), CRM (Salesforce, HubSpot), SCM, HRM, файлы Excel/CSV. Инструменты эксперта: журналы аудита (Audit Logs), журналы транзакций СУБД (LDF, redo logs, WAL), системные журналы, резервные копии.

Уровень 2: Интеграционный слой (Integration Layer). ETL-процессы (Azure Data Factory, SSIS, Talend, Informatica), ESB (Azure Service Bus, MuleSoft, RabbitMQ), API-шлюзы, очереди сообщений (Kafka). Инструменты эксперта: логи выполнения ETL, логи очередей, дампы сообщений, конфигурации маршрутизации.

Уровень 3: Хранилище данных (Data Warehouse / Data Lake). SQL Server, Azure Synapse, Snowflake, BigQuery, Redshift. Здесь могут быть хранимые процедуры, функции, триггеры, индексы. Инструменты эксперта: журналы транзакций (LDF), системные таблицы (например, sys.sql_modules), планы выполнения, трассировка запросов.

Уровень 4: Бизнес-аналитика (BI Layer). Power BI, Tableau, Qlik, SAP Analytics Cloud. Инструменты эксперта: DAX Studio (для Power BI), Performance Recorder (Tableau), Qlik Engine Logs, исходные файлы (.pbix,.twb,.qvf).

Уровень 5: Управление доступом (IAM Layer). Active Directory, Azure AD, Okta, Keycloak. Инструменты эксперта: журналы входа (4624, 4625 в Windows), политики доступа, группы безопасности.

Уровень 6: Клиентский слой (Client Layer). Веб-браузеры, SAP GUI, 1С: Предприятие, мобильные приложения. Инструменты эксперта: кэш браузера (Cache, localStorage, IndexedDB), логи 1С (.lgp,.lgf), файлы подкачки (pagefile.sys), история загрузок.

Инженерный принцип: Корпоративных информационных систем (КИС) требует анализа всех шести уровней. Ошибка на уровне ETL может не проявиться до уровня BI. Пропуск уровня — потеря доказательств. 🧩

Глава 2. Метод сквозной трассировки (End-to-End Tracing) данных

Сквозная трассировка — это «золотой стандарт» экспертизы КИС. Метод позволяет проследить путь одной записи от источника до конечного потребителя и выявить точку искажения. 📍

2.1. Алгоритм сквозной трассировки:

Выбор реперной записи (Reference Record). Выбирается документ (счёт-фактура, сделка, заказ), который гарантированно существует в исходной системе (ERP/CRM). Фиксируется его уникальный идентификатор (ID), а также значения ключевых полей (сумма, дата, количество).

Трассировка в источнике. Проверяется, что запись существует в исходной системе, не изменена задним числом. Используются журналы аудита и транзакционные логи СУБД.

Трассировка в ETL. В логах ETL-процесса ищется факт обработки записи. Сравнивается количество строк на входе и выходе. Анализируются преобразования (JOIN, WHERE, CAST).

Трассировка в Data Warehouse. Запись ищется в таблицах Data Warehouse. Сравниваются значения полей. Проверяются триггеры и хранимые процедуры, которые могли её модифицировать.

Трассировка в BI-модели. Проверяется, проходит ли запись через фильтры RLS (Row-Level Security). Проверяется, как вычисляются меры (DAX, LOD) с участием этой записи.

Трассировка в визуализации. Отображается ли запись на дашборде? Если да — соответствует ли сумма? Если нет — почему?

2.2. Инструменты для трассировки:

ERP (Dynamics 365 F&O): SQL Server, LDF-файлы, Audit Logs.

CRM (Salesforce): Audit Log, Login History, API Logs.

ETL (Azure Data Factory): Azure Monitor, Data Factory Logs, SQL Server Agent Logs.

Data Warehouse (Azure SQL DB): LDF-файлы, sys.dm_exec_query_stats, трассировка.

BI (Power BI): DAX Studio, Performance Analyzer, Power BI Activity Logs.

2.3. Эпистемическое значение: Сквозная трассировка даёт неопровержимое доказательство. Суд видит не абстрактные «ошибки», а конкретную запись, которая была потеряна или искажена на определённом этапе. Корпоративных информационных систем (КИС) без сквозной трассировки слепа. 👁️

Глава 3. Кейс №1: Сквозная трассировка потери данных в многоуровневой КИС

Фабула дела: Крупный производственный холдинг (Истец) объединил свою КИС: ERP (Microsoft Dynamics 365 F&O), ETL (Azure Data Factory), Data Warehouse (Azure SQL DB), BI (Power BI). После внедрения финансовый директор заметил, что себестоимость продукции в дашбордах Power BI на 22-28% ниже, чем в ERP. Убытки от неверного ценообразования — 200 млн рублей. Интегратор (Ответчик) утверждал: «Проблемы в исходных данных ERP». Суд назначил Корпоративных информационных систем (КИС). ⚙️

Инженерное расследование (эксперты Союза):

Шаг 1. Верификация исходных данных ERP. Эксперты выгрузили данные о себестоимости из SQL-базы ERP (таблица InventTrans). Запросили журналы аудита Dynamics 365 — никаких изменений. Данные корректны.

Шаг 2. Анализ ETL (Azure Data Factory). Эксперты извлекли JSON-определение конвейера LoadCostData. Нашли в SQL-запросе:

sql

SELECT ProductId, CAST(TotalCost AS INT) AS TotalCost, Quantity

FROM ERP.ProductionCost

WHERE Status = ‘Approved’

Преобразование CAST(TotalCost AS INT) округляло себестоимость до целого числа. Для продукции с себестоимостью 125,75 рублей в Data Warehouse попадало 125 рублей. Ошибка накопления: 0,6% — не главная причина.

Шаг 3. Анализ хранимых процедур в Data Warehouse. Эксперты проанализировали процедуру usp_CalculateCost. Никаких аномалий.

Шаг 4. Анализ DAX-формул в Power BI. Эксперты открыли файл.pbix через DAX Studio. В мере Total Cost обнаружили:

dax

Total Cost = DIVIDE( SUMX(Production, [TotalCost] * [Quantity]), COUNTROWS(Production) )

Вместо суммирования затрат (SUMX) формула вычисляла среднее значение (деление на количество строк). Это привело к занижению на 22-28%.

Шаг 5. Сквозная трассировка 10 реперных записей. Эксперты выбрали 10 продуктов с максимальным расхождением. Восстановили корректную себестоимость: исходные данные из ERP (без округления) прошли через исправленный ETL (без CAST) и исправленную DAX-меру (SUMX). Расхождение с исходным дашбордом подтвердилось — от 22% до 28%.

Инженерный вывод: Две независимые ошибки: округление в ETL (0,6% искажения) и семантическая ошибка в DAX (25% искажения). Ответственность — на интеграторе. Суд удовлетворил иск. Корпоративных информационных систем (КИС) позволила локализовать ошибку с точностью до конкретных строк кода. 🎯

Глава 4. Инженерный метод анализа ETL-логов и конвейеров

ETL-логи — это «чёрный ящик», который фиксирует каждый этап обработки данных. Ошибки здесь часто носят систематический характер и могут быть обнаружены статистическими методами. 📊

4.1. Ключевые метрики анализа ETL:

Количество строк на входе и выходе. Если выход всегда меньше входа на фиксированный процент — это признак ошибки фильтрации (INNER JOIN вместо LEFT JOIN, WHERE с условием, отбрасывающим записи).

Типы преобразований. CAST из DECIMAL в INT приводит к потере точности. CONVERT между строками и датами — к потере записей при неверных форматах.

Ошибки выполнения. NullReferenceException, TimeoutException — указывают на сбои в логике.

4.2. Инструменты анализа ETL:

Azure Data Factory: Azure Monitor, Log Analytics, KQL-запросы (ADFActivityRun, ADFPipelineRun).

SSIS (SQL Server Integration Services): Журналы выполнения в таблицах sysssislog, файлы.log.

Talend / Informatica: Встроенные логи консоли, файлы *.log.

4.3. Инженерный чек-лист при анализе ETL:

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

Проверить WHERE на предмет условий, отбрасывающих NULL.

Проверить преобразования типов на предмет потери точности.

Сравнить количество строк на входе и выходе за каждый период выполнения.

Проверить наличие механизмов повторных попыток (retry logic) в интеграциях.

4.4. Эпистемическое значение: ETL-логи являются объективным свидетельством, которое практически невозможно подделать. Они позволяют установить момент, когда данные начали теряться, и связать это с конкретными изменениями в коде. Корпоративных информационных систем (КИС) без анализа ETL-логов неполноценна. 🔍

Глава 5. Кейс №2: Расследование утечки данных через интеграционную шину

Ситуация: ООО «ТехноСнаб» (Истец) — дистрибьютор медицинского оборудования. Коммерческий директор Петров уволился и через месяц открыл конкурирующую фирму. Ключевые клиенты (объём продаж — 120 млн рублей в год) перешли к нему. Внутренний аудит в CRM (Salesforce) не выявил массового экспорта. Петров настаивал: «Ничего не выгружал». Суд назначил Корпоративных информационных систем (КИС). 🕵️

Инженерное расследование (эксперты Союза):

Шаг 1. Анализ Audit Log Salesforce. Эксперты выгрузили Audit Log и Login History за 2 недели до увольнения. Обнаружили: 23 операции экспорта сущностей Contact и Opportunity. Время экспорта: 22: 00-03: 00 (аномалия). IP-адрес: домашний провайдер Петрова.

Шаг 2. Анализ логов Azure Service Bus (интеграционная шина). Эксперты выгрузили логи очередей (queues) через Azure Monitor. Нашли сообщения с типами ContactExport и OpportunityExport в те же ночные часы. Тела сообщений содержали сериализованные JSON-массивы с контактами и сделками. Петров использовал интеграционную шину для обхода аудита CRM.

Шаг 3. Анализ логов Azure Data Factory. Эксперты нашли конвейер ExportToExternalBlob, который забирал сообщения из Service Bus и сохранял во внешний Blob Storage temp-petrov. Доступ к контейнеру имел только Петров (через SAS-токен).

Шаг 4. Анализ клиентской рабочей станции. Эксперты изъяли ноутбук Петрова (по судебному решению). В кэше браузера (Chrome) нашли фрагменты JSON-файлов с контактами и сделками. В Event Logs (Security.evtx) обнаружили события 4624 (вход) учётной записи Петрова в Azure Portal в ночное время.

Инженерный вывод: Сквозная трассировка: Salesforce → Service Bus → Data Factory → Blob Storage → локальный диск Петрова. Факт кражи доказан. Суд удовлетворил иск. Корпоративных информационных систем (КИС) разоблачила схему, скрытую в интеграционной шине. 🔥

Глава 6. Инженерный метод анализа журналов транзакций СУБД (LDF, redo logs)

Журналы транзакций СУБД — это самый низкоуровневый и самый надёжный источник доказательств. Они фиксируют каждое изменение данных, даже если аудит на прикладном уровне отключён. 💾

6.1. SQL Server: LDF-файлы и функция fn_dblog

Что фиксирует: каждую операцию INSERT, UPDATE, DELETE с LSN (Log Sequence Number), временем, SID пользователя, именем приложения.

Как анализировать: утилита ApexSQL Log, функция fn_dblog(NULL, NULL), скрипты на Python для парсинга LDF.

Что искать: операции UPDATE критических полей (себестоимость, цена, сумма) в нерабочее время; операции DELETE массового удаления записей.

6.2. Oracle: redo logs и LogMiner

Что фиксирует: SCN (System Change Number), SQL_REDO (восстановленный SQL), username.

Как анализировать: Oracle LogMiner (встроенный), сторонние утилиты.

6.3. PostgreSQL: WAL (Write-Ahead Log)

Что фиксирует: LSN, операции, before images.

Как анализировать: утилита pg_waldump, скрипты на SQL.

6.4. Инженерный чек-лист:

Получить образ диска сервера БД (on-premise) или экспорт LDF-файла (через суд).

Выгрузить все операции UPDATE/DELETE за интересующий период.

Отфильтровать по таблицам, полям, пользователям.

Извлечь before images для восстановления удалённых/изменённых записей.

Сопоставить с системными журналами Windows (Event Logs) для идентификации пользователя.

6.5. Эпистемическое значение: Журналы транзакций — это «золотой стандарт». Они практически не поддаются фальсификации. Корпоративных информационных систем (КИС) без анализа LDF/redo logs не может считаться глубокой. 🥇

Глава 7. Кейс №3: Обнаружение «закладки» в хранимой процедуре Data Warehouse

Обстоятельства: В ООО «Альфа-Холдинг» (Истец) в течение двух лет себестоимость продукции в отчётах Power BI была занижена на 15%. Убытки — 80 млн рублей. Подозрение пало на финансового директора Смирнова, который получал бонусы за «рост прибыли». Внутренний аудит ERP (Dynamics 365 F&O) не выявил изменений. Суд назначил Корпоративных информационных систем (КИС). 📉

Инженерное расследование (эксперты Союза):

Шаг 1. Анализ ERP. Данные в Dynamics 365 F&O корректны. Журналы аудита не показывают изменений себестоимости.

Шаг 2. Анализ ETL (Azure Data Factory). Преобразования корректны. Потери данных нет.

Шаг 3. Анализ хранимых процедур в Data Warehouse (Azure SQL DB). Эксперты извлекли код процедуры usp_CalculateCost через системное представление sys.sql_modules. Обнаружили:

sql

CREATE PROCEDURE usp_CalculateCost

AS

BEGIN

—… штатный расчёт…

IF EXISTS (SELECT 1 FROM Users WHERE UserName = SUSER_SNAME() AND Role = ‘CFO’)

BEGIN

UPDATE ProductionCost SET Cost = Cost * 0.85 WHERE ProductCategory = ‘Electronics’

END

END

Это была «закладка»: если пользователем является финансовый директор (CFO), то себестоимость для категории «Электроника» занижается на 15%. При этом для других пользователей (например, аудитора) процедура работала корректно.

Шаг 4. Анализ LDF-файла Data Warehouse. Эксперты проанализировали LDF-файл. Нашли запись ALTER PROCEDURE usp_CalculateCost в ночное время, за месяц до начала искажений. Пользователь — sql_admin, что соответствует учётной записи Смирнова. IP-адрес — домашний (92.xxx.xx.xx).

Шаг 5. Анализ системных журналов Windows (сервер БД). В журнале безопасности нашли события 4624 (вход) для учётной записи Смирнова в ночное время, с того же домашнего IP.

Инженерный вывод: «Закладка» в хранимой процедуре, срабатывающая только для определённой роли пользователя. Умысел доказан. Суд взыскал убытки. Корпоративных информационных систем (КИС) вскрыла схему, спрятанную в дебрях Data Warehouse. 💰

Глава 8. Инженерный метод анализа DAX-формул в Power BI

DAX — это функциональный язык, где ошибки в контексте фильтрации могут привести к катастрофическим искажениям. Эксперт должен уметь проводить формальную верификацию DAX-кода. 📐

8.1. Типовые анти-паттерны в DAX:

Неправильное использование CALCULATE без ALL или с неверными модификаторами фильтров.

Использование FILTER по всей таблице вместо CALCULATETABLE с прямыми условиями.

Деление на ноль без проверки знаменателя (DIVIDE с третьим параметром).

Неверная агрегация: SUM вместо AVERAGEX или наоборот.

Зависимость от порядка вычисления мер (меры, ссылающиеся на другие меры, определённые ниже).

8.2. Инструменты анализа DAX:

DAX Studio: отладчик, профайлер, экспорт мер.

Tabular Editor: просмотр метаданных модели.

Power BI Performance Analyzer: анализ времени выполнения.

8.3. Инженерный чек-лист:

Извлечь все меры и вычисляемые столбцы из файла.pbix.

Построить граф зависимостей между мерами.

Проверить каждую меру на предмет использования CALCULATE без ALL.

Проверить наличие констант-коэффициентов (например, * 0.85).

Протестировать меры на подмножестве данных, сравнивая с ручными расчётами.

8.4. Эпистемическое значение: Анализ DAX-формул позволяет не только найти ошибку, но и определить её природу: случайная (непонимание контекста) или намеренная («закладка» с константой 0.85). Корпоративных информационных систем (КИС) без анализа DAX слепа для BI-слоя.

Глава 9. Инженерный метод анализа клиентских кэшей и логов

Жулики часто забывают, что их действия оставляют следы не только на сервере, но и на их собственном компьютере. Клиентские следы — это «низко висящие фрукты» для эксперта. 🖥️

9.1. Источники клиентских следов:

Кэш браузера (Chrome, Edge, Firefox): папки Cache, Local Storage, IndexedDB. Могут содержать фрагменты выгруженных данных (CSV, JSON).

История загрузок: файлы Downloads, журнал загрузок браузера.

Файлы подкачки и гибернации: pagefile.sys, hiberfil.sys. Содержат фрагменты оперативной памяти, включая данные из веб-приложений.

Логи 1С (для файлового варианта): файлы.lgp,.lgf содержат историю действий пользователя.

Логи SAP GUI: saplog в папке пользователя.

9.2. Инструменты анализа:

Autopsy / FTK Imager: анализ образов дисков.

ChromeCacheView / EdgeCacheView: просмотр кэша браузера.

LogParser (Microsoft): анализ логов IIS, Event Logs.

1C LGP Viewer: просмотр логов 1С.

9.3. Инженерный чек-лист:

Изъять рабочую станцию подозреваемого (с санкции суда).

Создать побитовый образ диска (через write-blocker).

Проанализировать кэш браузера (искать файлы с расширениями.csv,.json,.xlsx, созданные в подозрительное время).

Проанализировать историю загрузок.

Извлечь фрагменты данных из pagefile.sys (если оперативная память не была очищена).

9.4. Эпистемическое значение: Клиентские следы часто являются решающей уликой, когда серверные логи уже «подчищены». В кейсе №2 именно кэш браузера Петрова подтвердил факт выгрузки данных.

Глава 10. Проблема распределённых временных меток и их нормализация

КИС может включать компоненты, работающие в разных часовых поясах и с разной синхронизацией времени. Эксперт должен уметь нормализовать временные метки для построения единой временной линии. 🕒

10.1. Источники временных меток:

Серверы: системное время, синхронизированное с NTP-сервером.

Облачные сервисы (Azure, AWS, Salesforce): UTC (по умолчанию).

Клиентские машины: локальное время пользователя.

10.2. Проблемы:

Рассинхронизация NTP. Если на сервере отключена синхронизация, время может «уплывать» на минуты и часы.

Перевод часов на летнее/зимнее время. В облачных сервисах обычно UTC, на локальных серверах — местное время.

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

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

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

Преобразовать все временные метки в UTC (единое время).

Сопоставить с данными пропускной системы, табеля учёта рабочего времени, логами VPN.

10.4. Эпистемическое значение: Без нормализации временных меток невозможно построить корректную временную линию событий. Корпоративных информационных систем (КИС) требует учёта временных зон.

Глава 11. Процессуальные аспекты: как подготовить инженерное заключение для суда

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

11.1. Структура инженерного заключения:

Вводная часть: данные об эксперте, аттестация, предупреждение об ответственности по ст. 307 УК РФ.

Описание объектов исследования: перечень систем (ERP, CRM, ETL, Data Warehouse, BI), версий, конфигураций.

Методология: описание методов (сквозная трассировка, анализ LDF-файлов, анализ DAX, анализ ETL-логов).

Ход исследования: пошаговое описание действий эксперта (с датами, временем, хеш-суммами).

Результаты: выявленные ошибки, искажения, потери данных (с графиками, таблицами, скриншотами).

Выводы: чёткие ответы на поставленные судом вопросы.

11.2. Требования к выводам:

Не давать правовую оценку. Эксперт не пишет «виновен», «совершил кражу». Эксперт пишет: «установлен факт массового экспорта данных из CRM в ночное время с IP-адреса, принадлежащего ответчику».

Не использовать вероятностные формулировки. «Возможно», «скорее всего» — недопустимо. Только «установлено», «выявлено», «подтверждено».

Приводить количественные оценки. «Объём экспортированных данных — 12 847 записей», «искажение себестоимости — 22-28%».

11.3. Обеспечение целостности:

К выводам прилагаются хеш-суммы (SHA-256) всех выгруженных данных.

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

Корпоративных информационных систем (КИС) требует от эксперта не только инженерных знаний, но и процессуальной дисциплины. ⚖️

Глава 12. Типовые ошибки при проведении экспертизы КИС (и как их избежать)

Ошибка №1: Анализ только одного слоя. «Я проверил ERP, всё чисто, значит, проблема не в интеграторе». А проблема была в DAX-формулах Power BI. Решение: Анализировать все слои КИС.

Ошибка №2: Игнорирование временных меток. «Петров выгружал данные в 3 часа ночи, но это, наверное, ошибка часов». Нет, это не ошибка. Решение: Нормализовать временные метки, сопоставлять с пропускной системой.

Ошибка №3: Работа только с выгрузками, без прямого доступа. Ответчик предоставил выгрузку Audit Log Salesforce. А выгрузка была отфильтрована (скрыты операции экспорта). Решение: Требовать прямой read-only доступ к системе.

Ошибка №4: Отсутствие сквозной трассировки. «В ETL потеряно 20% записей, значит, интегратор виноват». А в ERP эти записи были удалены самим заказчиком. Решение: Трассировать реперные записи от источника до дашборда.

Ошибка №5: Неучёт клиентских следов. Все серверные логи чисты. Но на рабочей станции Петрова — кэш браузера с выгруженными данными. Решение: Изымать рабочие станции.

Глава 13. Судебная практика по экспертизе КИС (анализ)

Анализ судебных актов (по данным из открытых источников и практики Союза) позволяет выделить следующие тенденции: 📈

13.1. Признание экспертизы КИС допустимым доказательством. Суды всё чаще назначают комплексную экспертизу, понимая, что без неё невозможно установить истину в гетерогенной среде.

13.2. Доказательная сила сквозной трассировки. Суды высоко оценивают выводы экспертов, которые могут показать путь данных от источника до дашборда с фиксацией искажения на каждом этапе.

13.3. Последствия отказа в доступе. Отказ ответчика предоставить доступ к одному из компонентов КИС расценивается как недобросовестное поведение (ст. 10 ГК РФ). Суд может удовлетворить иск, даже если экспертиза не была проведена в полном объёме.

13.4. Значение журналов транзакций СУБД. Экспертные выводы, основанные на анализе LDF-файлов, признаются судами как высокодостоверные.

Глава 14. Часто задаваемые вопросы об экспертизе КИС

Вопрос 1: Можно ли провести экспертизу, если КИС полностью облачная (SaaS)? Ответ: Да. Эксперт получает доступ через API и интерфейсы администрирования. Логи выгружаются через встроенные инструменты (Microsoft 365 Admin Center, Salesforce Audit Log, Power BI Activity Logs).

Вопрос 2: Как долго хранятся логи в облачных КИС? Ответ: Salesforce — 6-18 месяцев, Power BI — 30-90 дней, Azure Data Factory — до 90 дней. Важно: истец должен действовать быстро.

Вопрос 3: Может ли эксперт восстановить данные, если ETL-код был удалён? Ответ: Если ETL-код удалён, но есть логи выполнения (Azure Monitor), можно восстановить логику преобразований (reverse engineering). Это сложнее и дороже, но возможно.

Вопрос 4: Сколько стоит экспертиза КИС? Ответ: От 1 до 5 млн рублей. Точную смету даём после ознакомления с объектами.

Вопрос 5: Нужно ли привлекать нескольких экспертов для разных компонентов? Ответ: Да. Для комплексной КИС нужна команда: эксперт по ERP, по CRM, по BI, по ETL, по СУБД. Союз «Федерация судебных экспертов» предоставляет таких специалистов.

Глава 15. Заключение: КИС не убежище, а лабиринт с выходом

Корпоративная информационная система — это сложнейший инженерный объект. Но именно эта сложность оставляет множество цифровых следов: журналы аудита CRM, транзакционные логи ERP, ETL-логи, DAX-формулы BI, хранимые процедуры Data Warehouse, кэши клиентских машин, системные журналы серверов. Корпоративных информационных систем (КИС) — это методология, позволяющая собрать эти следы в единую картину и восстановить истину. 🎯

Три кейса, представленные в этой статье, демонстрируют разные сценарии: ошибки интегратора в ETL и DAX (Кейс №1), кражу базы через интеграционную шину (Кейс №2), «закладку» в хранимой процедуре Data Warehouse (Кейс №3). Во всех трёх случаях правда была найдена, а виновные понесли ответственность.

Союз «Федерация судебных экспертов» обладает уникальной инженерной экспертизой в области КИС. Мы работали с Microsoft Dynamics, Salesforce, Power BI, Azure Data Factory, SQL Server и десятками других технологий. Мы находим то, что другие не видят. Мы восстанавливаем то, что другие считают потерянным.

Если ваш бизнес использует комплексную КИС, и вы столкнулись с потерей данных, манипуляциями, утечкой или ошибками интегратора — не пытайтесь разобраться сами. Не верьте распечаткам. Требуйте экспертизы. Требуйте нас.

📌 Наш сайт: https://kompexp.ru/

Статья подготовлена экспертами Союза «Федерация судебных экспертов» на основе реальных экспертиз КИС. Кейсы приведены с сохранением конфиденциальности. Методология соответствует научным стандартам.