Судебная экспертиза базы данных MongoDB

Экспертиза MongoDB нужна, когда спор зависит от BSON-документов, структуры коллекций, журналов, репликации, шардинга, резервных копий, сбоя или результата миграции. Специалист исследует не только выгрузку: устанавливает точную версию и уровень совместимости функций (feature compatibility version), схему развёртывания, механизм хранения, dbPath, набор реплик (replica set) или шардированный кластер, параметры подтверждения записи (write concern) и чтения (read concern), oplog, аудит и журналы приложения. Это специализированное направление экспертизы баз данных и СУБД.

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

После сбоя или спорного удаления не запускайте mongod --repair, повторную инициализацию или синхронизацию узла, уплотнение данных и восстановление поверх единственной копии. Не копируйте отдельные файлы WiredTiger из работающего dbPath как независимую базу. Зафиксируйте роли и состояние узлов, позиции репликации (optimes), время и часовой пояс, конфигурацию и доступные резервные копии; секреты и ключи передают только согласованным защищённым способом. Эти действия выполняет владелец системы или уполномоченный им администратор; если кластер принадлежит другой стороне, сохранение доказательств организуют через суд.

Если уже по присланным материалам видно, что ответ получить нельзя, мы не берём задачу в работу и сразу сообщаем об этом. Принятая задача не обязательно завершится положительным выводом. Если это выясняется только в ходе исследования, работа считается выполненной: заключение объясняет, почему ответ получить нельзя и каких данных не хватило. Например, заключение может обосновать, что окно oplog за спорный период закрылось. Назначать ли после этого дополнительную или повторную экспертизу, решает назначивший её орган. При частичной возможности ответа в заключении указывают, на какие вопросы он получен, на какие — нет и почему.

Кто и как снимет копию, определяют после ознакомления с объектом. Копию может снять заказчик или его администратор по согласованному плану, наш специалист — удалённо либо с выездом в рамках отдельной консультации, либо эксперт в ходе экспертизы. Выбор зависит от сложности системы, доступности и трудоёмкости: снимки узлов получают, а границы oplog фиксируют по-разному на одиночном сервере и на нагруженном кластере. Если инфраструктура находится под контролем другой стороны, порядок доступа определяет суд; состояние системы фиксируют с участием эксперта.

Принудительная переконфигурация (rs.reconfig с force: true) откатывает записи, подтверждённые большинством, и потому меняет исследуемое состояние. Но держать боевой кластер нерабочим ради сохранности следов не нужно: до восстановления работы снимите копии файлов данных всех доступных узлов, сохраните rs.status(), rs.conf(), границы oplog и каталог отката, зафиксируйте время — и возвращайте доступность.

Документированная процедура согласованного снимка блокирует запись командой db.fsyncLock(). Это остановка записи во всей системе, и снимается она только вручную. Блокировка считается счётчиком: если её ставили несколько раз, снимать нужно столько же, проверяя возвращаемое значение, пока счётчик не обнулится. Окно согласуйте с владельцем системы заранее, оцените длительность по объёму данных и назначьте ответственного за снятие. Отдельно проверьте, не сменился ли за время блокировки основной узел: новый основной узел блокировку не наследует, и набор снимков в таком случае описывают как интервальный, а не согласованный.

Что именно исследуют в MongoDB

MongoDB Community, Enterprise и Atlas имеют разные доступные источники и порядок получения. Одиночный сервер, набор реплик и шардированный кластер также нельзя сводить к одному файлу. В шардированном развёртывании документы распределены по шардам, а метаданные размещения и маршрутизации связаны с серверами конфигурации и mongos.

В зависимости от схемы развёртывания исследуют:

• версии исполняемых файлов, уровень совместимости функций, механизм хранения и параметры запуска;
• базы, коллекции, представления, UUID, правила проверки, индексы, пользователей, роли и настройки профилирования;
• файлы данных WiredTiger, журнал и контрольные точки либо логические BSON-выгрузки;
• конфигурацию набора реплик, состояния участников, выборы, позиции репликации, откат и окно oplog;
• для шардинга — шарды, серверы конфигурации, mongos, основную базу шарда, диапазоны данных, зоны и события их перемещения;
• журнал аудита, диагностический журнал, коллекции профилировщика, FTDC, журналы приложения и облачные события;
• метод резервного копирования, согласованность снимка, шифрование данных на диске и внешний KMS.

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

Что может и чего не может установить эксперт

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

При достаточных материалах эксперт может установить:

• какие документы, поля, типы BSON, индексы и правила проверки присутствуют в заданном пространстве имён;
• какие успешные изменения отражены в доступном диапазоне local.oplog.rs и к каким пространствам имён они относятся;
• соответствует ли резервная копия или снимок заявленному моменту и возможно ли восстановление на заданную точку;
• происходили ли выборы, понижение основного узла, откат, начальная синхронизация или заметное отставание репликации;
• какие запросы и действия отражены в реально настроенных журналах аудита, профилировщика и диагностики;
• соответствуют ли настройки шардинга и репликации требованиям и полностью ли выполнена миграция.

Oplog не записывает неуспешные операции и чтения, не хранит бессрочную историю и не является универсальным журналом физического пользователя. Журнала аудита в редакции Community нет вовсе — он доступен только в MongoDB Enterprise и в управляемых сервисах, причём с разным набором настроек; это стоит проверить до того, как строить вопросы на записях аудита. Техническую учётную запись, метаданные клиента, адрес или соединение сопоставляют с приложением, IdP, ОС и сетью. Эксперт устанавливает связь события с техническими идентификаторами, а вопрос о том, какое физическое лицо действовало и с каким умыслом, разрешает суд или иной уполномоченный орган.

Материалы и сохранность

Для каждого объекта фиксируют источник, узел, путь или облачный проект, средство получения и его версию, дату, время и часовой пояс, размер и контрольную сумму SHA-256 завершённой мастер-копии. Мастер-копию сохраняют неизменной, исследование ведут на рабочей копии; после каждой передачи повторно проверяют SHA-256 и записывают отправителя, получателя, время и носитель. Перед сбором работающего кластера согласуют минимальное воздействие и учитывают, что диагностические команды, резервное копирование и сброс данных на диск сами создают события.

В комплект обычно включают:

• конфигурацию mongod и mongos, параметры запуска, версии и уровень совместимости функций;
• согласованные снимки файловой системы или томов со всеми нужными данными и журналами либо облачные резервные копии;
• BSON-выгрузки с метаданными, команды и версии MongoDB Database Tools, а также отчёты об ошибках;
• конфигурацию набора реплик и шардинга, состояния участников, позиции и отставание репликации, балансировщик и метаданные диапазонов;
• копию доступного oplog с границами ts, журналы аудита и диагностики, данные профилировщика, FTDC и сведения о ротации;
• каталог отката, события выборов, понижения основного узла, повторной и начальной синхронизации и обслуживания;
• журналы приложения, драйвера, входного шлюза или прокси, IdP, ОС и оркестратора;
• правила схемы, техническое задание, политику резервного копирования, карту миграции и спорный период.

Для зашифрованного механизма хранения сохраняют конфигурацию и доступность ключей, но не помещают секреты в общий незашифрованный комплект. В управляемых сервисах, включая Atlas, используют штатную документированную процедуру снимка или восстановления на заданную точку, а не самодельный файловый сбор. Фиксируют идентификатор задания, состав кластера, время начала и завершения, заявленную точку, статус, регион, ошибки и полученные файлы; выгрузку документируют так же, как локальный объект.

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

WiredTiger, контрольные точки и журнал

WiredTiger создаёт согласованные контрольные точки файлов данных; после аварийного завершения MongoDB использует сохранившийся журнал, чтобы воспроизвести пригодные записи после последней контрольной точки. Попадание подтверждённой клиенту записи в восстановленное состояние зависит от действовавших writeConcern, параметра j, writeConcernMajorityJournalDefault и фактической синхронизации на диск. Журнал предназначен для устойчивости и восстановления после сбоя, но не равнозначен oplog и не является бессрочной хронологией прикладных операций.

Физический снимок должен быть согласованным. Если файлы данных и журнал находятся на разных томах, их снимки координируют на один момент. Простое копирование отдельных .wt во время записи может дать смесь состояний. Исходные файлы сохраняют как мастер-копию, а запуск и любые действия восстановления выполняют на рабочем клоне с совместимой версией и зафиксированной конфигурацией.

Для самостоятельно обслуживаемого шардированного кластера физический срез планируют как отдельную изменяющую операцию. Сначала фиксируют топологию и состояние репликации, останавливают балансировщик, прикладные записи, изменения схемы и топологии. Дальнейший порядок выбирают строго по фактической версии. Начиная с MongoDB 7.1, а также 7.0.2, 6.0.11 и 5.0.22, документированная процедура блокирует кластер командой db.fsyncLock() через mongos и на основном узле набора серверов конфигурации, затем создаёт снимки основного сервера конфигурации и основных узлов всех шардов. До снимка фиксируют результат проверки fsyncLocked=true, fsyncUnlocked=false на обеих точках и отсутствие незавершённых операций. После снимков выполняют db.fsyncUnlock(), подтверждают обратное состояние и возобновляют балансировщик с проверкой его работы. Для других версий используют относящееся к ним руководство или согласованный с поддержкой порядок; прямую работу с шардом не считают универсально безопасной. В MongoDB 8.0 роль directShardOperations опасна и допустима только для обслуживания или по указанию поддержки.

Согласованность томов одного узла не доказывает единый момент всего кластера. Если записи не были приостановлены либо снимки шардов и серверов конфигурации создавались в разные интервалы, фиксируют для каждого узла начало и конец, clusterTime и границы oplog. При восстановлении отдельно проверяют пропуски и дубли документов, перемещения диапазонов и распределённые транзакции; неподтверждённый набор снимков не называют точным срезом на одну секунду.

--repair предназначен для особых случаев восстановления повреждённого состояния и способен изменять данные. После обычной аварийной остановки WiredTiger использует контрольную точку и журнал; запуск repair «на всякий случай» не нужен и может уничтожить следы. В экспертном исследовании сначала документируют ошибку и делают копию.

Oplog, откат и восстановление на заданную точку

Oplog — специальная ограниченная коллекция local.oplog.rs с циклически обновляемыми записями об операциях, изменивших данные набора реплик. Вторичные узлы асинхронно копируют и применяют эти записи. Неуспешная операция или операция без изменения данных записи не создаёт; чтения в oplog не отражаются. Старые записи вытесняются по мере заполнения, поэтому на каждом узле фиксируют фактические начальную и конечную метки времени.

При переключении роли бывший основной узел может откатить записи, которые не успели реплицироваться на доступное большинство. Эксперт сопоставляет общую точку, файлы отката, журналы, номер эпохи выборов (term), позиции репликации и требование подтверждения записи (write concern). Запись, которую видел один клиент до отката, не обязательно вошла в устойчивую общую историю. Подтверждение большинством снижает риск, но его фактическое использование проверяют по приложению и конфигурации.

Восстановление на заданную точку обычно опирается на согласованную резервную копию и непрерывную последовательность oplog после неё либо на штатную систему управляемого сервиса. Текущий oplog без подходящего базового снимка не создаёт полную прежнюю базу. Горизонт ограничен самым ранним необходимым событием, согласованностью шардов и сохранностью метаданных. Если спор целиком о том, что и когда изменилось в записях, требуется экспертиза изменений и удаления данных.

Аудит, профилировщик и диагностический журнал

Аудит MongoDB записывает выбранные события доступа и администрирования, но существует не везде: в Community его нет, в Enterprise и управляемых сервисах он включается отдельно и работает в пределах настроенного фильтра. Проверяют формат, назначение вывода, фильтр, текущую конфигурацию, ротацию и период. Отсутствие события, которое фильтр не охватывал, нельзя трактовать как доказательство отсутствия действия.

Профилировщик базы собирает сведения об операциях в коллекции system.profile конкретной базы с учётом уровня, slowms, выборки и ограниченного размера. Он может влиять на производительность и не является неизменяемым аудитом. Диагностический журнал отражает сообщения сервера и операции в зависимости от детализации, порога медленных операций и настроек компонентов; строки могут содержать чувствительные данные и ротируются.

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

Набор реплик и шардированный кластер

Исследование набора реплик включает всех доступных участников: их конфигурации, состояния, номера эпох выборов (term), позиции и источники синхронизации, отставание, начальную синхронизацию и откат. Реплика не является независимым архивом: она применяет операции основного узла (primary), а повторная синхронизация может заменить локальный набор данных. Снимок одного узла описывает только согласованное состояние этого узла на момент создания.

В шардированном кластере нужны согласованные данные всех шардов и набора серверов конфигурации. mongos маршрутизирует запросы, а балансировщик и перемещения диапазонов способны менять размещение данных. Локальная выборка с одного шарда не доказывает полноту коллекции. Для общей временной линии учитывают clusterTime, локальные oplog каждого шарда, перемещения диапазонов, распределённые транзакции и возможные расхождения часов.

Сбои, производительность и миграция

Причины сбоя исследуют по диагностическому журналу, FTDC, serverStatus и снимкам мониторинга, кэшу и билетам WiredTiger, управлению потоком, блокировкам, ошибкам страниц, контрольным точкам, задержке диска и репликации, выборам, пулам соединений и метрикам приложения. Профилировщик и explain помогают оценить планы запросов и индексы, но текущий план не доказывает прошлую конфигурацию.

При миграции сопоставляют базы, коллекции и UUID, число и содержимое документов, типы BSON, вложенные структуры и массивы, ObjectId, Decimal128, даты и часовые пояса, двоичные данные, индексы и их параметры, правила проверки, правила сортировки, TTL и частичные индексы, пользователей, роли, представления, ключи шардинга и зоны. Проверяют отклонённые документы, преобразования, повторные попытки, переключение на новую систему и записи после контрольной точки. Равное число документов не подтверждает одинаковую семантику приложения. Когда предметом спора становится сам перенос, а не устройство базы, требуется экспертиза миграции баз данных.

Примеры вопросов на экспертизу

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

До назначения стороны могут предложить суду или иному уполномоченному органу следующие формулировки технических вопросов. Для MongoDB полезно указать схему развёртывания, версию, базу и коллекцию, документ или критерий, период и часовой пояс. Например, можно предложить исследовать, отражено ли удаление документа X в oplog или журнале аудита и с какими техническими идентификаторами связана операция, либо до какого момента возможно восстановление по снимку Z и непрерывному диапазону oplog. Дополнительные примеры:

1. Какие документы и индексы содержатся в представленном состоянии пространства имён?
2. Какие изменения конкретных документов отражены в доступном диапазоне oplog?
3. Охватывают ли резервная копия и oplog заданный момент и возможно ли воспроизводимое восстановление?
4. Имеются ли признаки отката, начальной синхронизации, выборов или отставания репликации?
5. Какие действия отражены в представленном журнале аудита и с какими техническими идентификаторами?
6. Соответствуют ли снимки серверов конфигурации и всех шардов общему подтверждаемому состоянию, исключены ли пропуски и дубли?
7. Как распределены спорные данные между шардами и подтверждается ли полнота выборки?
8. Каковы технические причины зафиксированной ошибки или замедления?
9. Соответствуют ли конфигурации репликации и резервного копирования заданным требованиям?
10. Полностью ли перенесены перечисленные документы, типы, индексы и правила проверки?

Порядок работы, результат и стоимость

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

Если судебная экспертиза уже назначена, назначенный по делу эксперт не принимает от одной стороны напрямую дополнительные выгрузки, файлы данных и записи oplog и не даёт ей частную оценку по существу поручения: вопросы, доступ и новые материалы идут через назначившего субъекта. Это не исключает обращения стороны к другому, не назначенному по делу специалисту — за консультацией или рецензией по законно полученным материалам. Если специалист ранее выполнял содержательную работу для одной из сторон, это раскрывают при рассмотрении его кандидатуры; допустимость назначения и возможный отвод решает уполномоченный субъект с учётом мнения участников. Чтобы снизить риски, роли консультанта стороны и кандидата в судебные эксперты целесообразно разделять.

Результатом может быть консультация, внесудебное исследование, заключение специалиста, судебная экспертиза или рецензия. Ориентир по стоимости — от 100 000 ₽, срок — от 10 рабочих дней; влияют объём, топология, шифрование, число снимков и узлов, состояние oplog, стенд, период и вопросы. Процессуальный статус определяется назначением, доказательственное значение — судом. Для проверки ранее подготовленного заключения проводят рецензия на заключение экспертизы баз данных и СУБД.