Подводка ведущего

Мы двигаемся дальше. И, как все знаете, в идеальной ситуации у экспертов всегда есть различные программные средства для того, чтобы все извлечь, со всем все работать, все сделать правильно, красиво. В общем, как надо. Но, как мы знаем, ситуации далеко не всегда бывают идеальными. Что делать в таком случае — об этом расскажет нам следующий спикер, Павенский Юрий. Встречайте аплодисментами.

— Так, а презентация?

— Владислав просто увлекся, утащил кликер, поэтому приходится побегать. Пожалуйста. Спасибо.

Доклад

Итак, добрый день, уважаемые коллеги, уважаемые участники Moscow Forensics Day 2026. Прежде всего, хочу выразить благодарность организаторам за приглашение и возможность выступить на сегодняшней 10-й юбилейной конференции. Меня зовут Павенский Юрий Алексеевич, я выступаю в качестве независимого эксперта. И сегодня предлагаю вместе разобраться, как проводить исследования электронных носителей информации в ситуации, когда корпоративная сеть передачи данных уже должным образом не функционирует, а привычного доступа к средствам защиты информации и соответствующей телеметрии больше не имеется.

Уверен, многие из вас задались вопросом, а как вообще на практике может возникнуть такая ситуация? Мы же ведь такая классная компания, правда, у нас имеется в распоряжении огромное количество различных средств защиты информации, включая сертифицированных, ну, например, такие как SIEM, EDR, DLP, TI, Web Application Firewall, NGFW, антивирусное ПО и многие-многие другие. Кроме того, мы систематически проводим пентесты, практические учения, совершенствуем процессы реагирования на инциденты и проходим через огромное количество проверочных мероприятий со стороны различных регуляторов. И опять же, вы здесь, наверное, скажете, но ведь результаты этих проверочных мероприятий всегда оцениваются на самом высоком уровне, что же нам может угрожать?

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

Давайте разберёмся в этом вопросе на примере конкретного инцидента.

Кейс: от утёкшей базы до шифрования и вымогательства

Допустим, в публичной сети интернет была опубликована база данных одного из известных интернет-магазинов, которая включала в себя персональные данные клиентов, адреса электронной почты и пароли, необходимые для доступа в личные кабинеты. В указанной базе данных фигурировал работник, который работал в компании разработчика одной из известных IDM-систем, который в качестве логина использовал личный адрес электронной почты.

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

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

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

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

И одновременно с этим, анализируя АРМы организации, они наткнулись на автоматизированное рабочее место работника IT-подразделения, на котором находилась незашифрованная копия личного мобильного устройства производства Apple. Естественно, она им очень понравилась, они ее забрали и в дальнейшем по результатам парсинга такой копии вытащили фотографии конфиденциальных документов, вытащили хранившуюся там электронную переписку, в том числе, которая содержала сведения об учетных данных, которые передавались одному из подрядчиков.

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

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

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

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

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

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

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

Это может быть сообщение, полученное от злоумышленника, и, соответственно, это может быть фрагмент данных, опубликованный в публичной сети интернет. Именно поэтому в рамках процесса реагирования на такого рода инцидентов существует 10 взаимосвязанных этапов от момента фиксации первичного сообщения и предварительного установления масштаба инцидента и заканчивая реконструкцией последовательности атаки, восстановления IT-инфраструктуры и закрытия инцидента. А, и опять же, хотел бы отметить, что наиболее подробно каждый этап мы сегодня рассматривать с вами не будем ввиду ограниченного времени моего выступления, значит, если вам это интересно, да, и вам хочется действительно понять, а что нужно делать в этой ситуации наиболее подробно, да, в рамках каждого этапа, вы можете вот отсканировать вот этот вот QR-кодик, значит, там вот в первой папочке будет документ, значит, называется «Общий порядок», да, реагирования.

Вот вы можете себе скачать, вот этот вот QR-код также будет на всех последующих слайдах, поэтому в любой удобный момент вы сможете получить доступ к такой информации. Но если кто-то не успеет отсканировать, можете потом подойти ко мне отдельно, я такую информацию вам предоставлю. Так вот, значит, ну опять же, в дальнейшем я сосредоточусь на основной логике выбора действий по отношению к каждому узлу в рамках такого инцидента, расскажу о том, как правильно сохранять волатильные артефакты и получать проверяемые копии данных. И вместе с этим мы также с вами осуществим реконструкцию последовательности атаки.

Изолировать, снимать или не трогать: логика по каждому узлу

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

То есть я считаю, что эти правила в целом должны быть гибкими и некатегоричными. Почему? Ну потому что если мы с вами изолируем все хосты, ну знаете, если у нас с вами, ну это я рассматриваю еще более-менее нормальный случай, если у нас вдруг какая-то система после инцидента еще будет жива, то после изоляции есть риск, что с этой системой вдруг что-то потом может пойти не так. Особенно с какой-нибудь базой данных, куда, например, копировались какие-то данные в этот момент. Или, например, если это какой-то, знаете, безумно сложный инцидент для расследования, мы рискуем просто бездумно потерять необходимые артефакты, которые позволили бы нам восстановить всю цепочку атаки.

Если мы говорим про полный сбор данных со всех хостов, давайте представим, что у нас в организации 2 тысячи хостов, 10 тысяч хостов, 100 тысяч хостов. Вы представляете, сколько по времени мы будем собирать полный пакет данных по каждому устройству? Я боюсь, мы будем собирать информацию до тех пор, пока компания наша не закроется в связи с этим инцидентом. Поэтому это тоже совсем неправильный подход, так делать точно не нужно.

Значит, наверное, вы спросите, а что же делать-то, если есть такие нюансы? Да все очень просто. Мы должны оценить связь узла с инцидентом. Это вот самое простое, что нужно сделать. Если мы такую связь установили, следующим шагом нам необходимо оценить, а продолжается ли ущерб, как на самом хосте, так и при помощи него, либо имеется ли какое-либо подозрительное сетевое соединение. Если какое-то одно из этих условий у нас имеется, значит, мы переходим далее. Смотрим, сохранился ли какой-либо сетевой доступ к каким-то оставшимся живым системам и ресурсам. Опять же, да, вы спросите, но у нас же корпоративная сеть не работает, какой же здесь может быть доступ к другим ресурсам?

Да на самом деле тоже все очень просто. Если у нас тачка живет в одном VLAN с такими системами, то велика вероятность, что такой доступ, возможно, к этим ресурсам сохранится. Поэтому также необходимо это иметь в виду. И последнее такое общее правило, оно подходит для всего. Важно также учитывать и технические ограничения, потому что так может получиться, что тачка, допустим, может не совсем стабильно работать. И если вы будете как-то не совсем правильно собирать данные с нее, есть риск, что тачка просто перестанет работать. Или, например, взять те же самые коммутаторы, маршрутизаторы. Взять, к примеру, Huawei, пусть будет так просто, как для примера.

Как вы прекрасно понимаете, существует огромное количество моделей по назначению. Могут устройства отличаться между собой. И вроде бы казалось бы, там может использоваться одна и та же операционная система Huawei VRP, а по факту могут на практике использоваться разные команды. Поэтому они в свою очередь при их выполнении могут опять же оказывать различное влияние на те же самые сетевые устройства. Поэтому это все также необходимо иметь в виду. Так вот, перехожу к конкретике. Еще раз, если у нас есть связь узла с инцидентом, но при этом, если у нас не продолжается какой-либо ущерб, отсутствуют подозрительные какие-то сетевые соединения, если у нас при этом не сохраняется какой-либо сетевой путь до наших ресурсов, то в этом случае не нужно бросать все и изолировать этот хост.

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

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

И восстановить мы ее, тем более в условиях, когда у нас удалены резервные копии AD-серверов, уже будет проблематично. Это как пример. Значит, вот поэтому, если мы с вами понимаем, что у нас есть хотя бы две минуты, коллеги, ну, более, наверное, не нужно. Если у нас, мы понимаем, что за эти две минуты никакой катастрофы с этим узлом не произойдет, вот при таких условиях, мы с вами можем получить волатильные данные.

Потому что, если, опять же, мы осуществим с вами сетевую изоляцию, мы потеряем с вами огромное количество таких артефактов. Это 100%. Поэтому пока они есть, надо этим пользоваться. Опять же, я вам не говорю о том, что, знаете, на примере Linux, я же не говорю, что нужно сейчас вводить вам порядка 67 и более команд для получения всех необходимых волатильных данных. Нет, конечно же, вручную это делать ни в коем случае не нужно.

Вы в две минуты тогда не уложитесь. Для этого рекомендуется использовать соответствующий автоматизированный скрипт. Если у вас его нет, считайте, что после сегодняшнего выступления он у вас есть. Вы также можете отсканировать QR-кодик. Там, соответственно, есть, во-первых, полный перечень команд, которые необходимо вводить для получения первоочередных каких-то волатильных данных. В зависимости от операционной системы семейства Windows, macOS, Unix- подобных операционных систем на базе ядра Linux.

До коммутаторов и маршрутизаторов я чуть попозже дойду, но там тоже, в принципе, такая информация есть. И лежат там соответствующие автоматизированные скрипты, которые вы также можете использовать на практике. Они повершелловские, вы их там… Ну, там где-то PowerShell, где-то другие там скрипты. В общем, можете их использовать на практике. За пару минут вся необходимая информация у вас выгрузится и даже создастся соответствующий отчет.

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

Ну, по крайней мере, в рамках этого этапа точно этого… Да вообще, в принципе, это делать не нужно, потому что тогда у нас поменяются постоянные данные. Так вот, и последнее, что, наверное, я скажу, это про виртуальные машины. Значит, если у нас имеется техническая возможность, и если мы уверены в том, что гипервизор не может внести какие-то недопустимые изменения в данные гостевой операционной системы, в этом случае мы можем создать моментальный снимок с сохранением оперативной памяти. При этом хочу сказать наперед, что до нажатия вот такой вот кнопочки, создания моментального снимка, ни в коем случае на этой тачке, пожалуйста, ничего не делайте.

Для того чтобы все сохранить в целостности и сохранности. Опять же, вы наверняка скажете, какой здесь может быть гипервизор, если у нас корпоративная сеть не работает, как мы к нему вообще подключимся. Но тоже на самом деле все очень просто. Если серверы находятся не на аутсорсе, где-то на другом краю России, в другой стране, в вашем офисе, конечно же, вы можете взять недоменное автоматизированное рабочее место в виде ноутбука и подключиться к соответствующему либо SAN-свитчу, либо непосредственно к management-порту данного оборудования. Тогда в этом случае вы получите доступ к гипервизору и далее, соответственно, к самой виртуальной машинке.

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

Очередность сбора волатильных данных

Так вот, мы с вами дошли непосредственно до этапа, который называется очередность сбора волатильных артефактов и получения данных с большим риском утраты. Значит, что здесь необходимо иметь в виду? Что именно на данном этапе, в первую очередь, нас интересует вообще не вся информация, которая вообще в целом есть на носителе. Именно, я говорю про конкретно этот этап, нас интересует в первую очередь сведения, которые могут как-то видоизмениться или утратиться в результате работы операционной системы, в результате действий злоумышленника, либо в результате сетевой изоляции. Что нас интересует в первую очередь? Нас в первую очередь интересует базовая информация об узле, такие как имя хоста, сведения о текущей учетной записи, версия операционной системы или загруженного ядра, системные дата, время, часовой пояс, время независимого источника.

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

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

Поэтому, если есть возможность, некоторые локальные журналы нужно также выгрузить. Не нужно выгружать абсолютно все. Бывает такое, что локальные журналы весят вообще терабайтами. И вы тогда до ночи будете, не знаю, неделю, наверное, будете выгружать, не знаю, сколько. Но, опять же, нас интересует информация, ну, хотя бы за последние 24 часа. Я не думаю, что там будет супер какой-то прям большой объем данных.

Так вот, опять же, я говорю про журналы, вы, наверное, спросите, о каких журналах я говорю. Но если мы говорим про операционные системы семейства Windows, я бы со своей стороны порекомендовал бы все-таки выгрузить часть данных с таких журналов, как System, Security, WinRM Operational, TS-RCM Operational, TS-LSM Operational, OpenSSH Operational, не помню, говорил, WinRM Operational. А, самое главное, конечно же, Windows PowerShell и PowerShell Operational. Если мы с вами говорим про линуксовые операционные системы, в этом случае нас интересуют такие журналы, как syslog, audit, secure, kern, messages, daemon, xrdp и xrdp-sesman. Sesman. А, и auth тоже, да, ну это вообще из самых основных журналов.

После того, а, если мы говорим про macOS, здесь нас, ну, в первую очередь будет интересовать syslog и Unified. Если, так, что дальше, да, после журналов нам делать? После того, как мы такие журналы выгрузили, нас интересуют сведения, значит, о загруженных драйверах, модулях расширения ядра и, соответственно, сведения об активных средствах межпроцессного взаимодействия. И самое последнее, что нас, опять же, также должно заинтересовать, это сведения о сетевом состоянии узла. То есть это сведения о его сетевых интерфейсах, об активных установленных сетевых подключениях, слушающих портах, таблице маршрутизации и сведения о соседних узлах. Здесь я имею в виду ARP и NDP.

Как я говорил, эти все данные нам необходимы. Опять же, мы ни в коем случае их не сохраняем на постоянный носитель, мы сохраняем либо на внешний носитель, либо в изолированное сетевое хранилище, которое функционирует независимо от основной корпоративной сети. Но опять же, есть такая возможность у кого-то есть, мало ли вдруг.

Коммутаторы и маршрутизаторы: как подключаться и что снимать

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

Это могут быть кривые руки работников IT-подразделения, которые настраивали в какой-то момент соответствующую конфигурацию. Либо это могут быть действительно злоумышленники. Как это было в этом самом кейсе. Так вот, как нам к таким сетевым устройствам подключаться? Понятно, что если в отсутствии связанности корпоративной сети, если мы как-то по сети подключиться к этим устройствам не можем, самый, наверное, единственный и правильный вариант – это подключиться с автономного недоменного ноута с использованием соответствующего консольного кабеля.

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

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

Это системные дата, время, часовой пояс. И опять же его отклонение от независимого источника. Значит, это может быть время непрерывной работы операционной системы. Версии операционной системы, это могут быть локальные журналы, административные сеансы, сетевые маршруты и какие-то оставшиеся данные в основных оперативных таблицах.

Что я еще хотел вам сказать по коммутаторам. А, да, самое главное, конечно же, в рамках сбора волатильных данных мы ни при каких обстоятельствах, ни в коем случае не используем команды записи. То есть мы используем, опять же, я хочу сказать, не просто команды просмотра информации, а мы используем заранее проверенные команды, исполнение которых должно быть для нас очевидным по тому, какой результат мы получим и к какой нагрузке на устройство это может привести. Потому что, опять же, говоря про нагрузку устройства, тут тоже есть свои нюансы. То есть вы, опять же, должны понимать, что любое подключение к сетевому устройству, не знаю, там, любой ввод команды, даже просмотра негативно отражается на истории командной оболочки, значит, на соответствующих локальных журналах, значит, также, соответственно, это может, а также на системах AAA это также может отразиться.

И самое главное, это может вызывать кратковременное увеличение нагрузки на само устройство. Опять же, да, говоря про сбор информации, вы, наверное, скажете: ну что ж, ну да, опять, тут надо вводить огромное количество команд вручную, опять же, это уйдет на это много времени, а зачем это все нужно? Согласен, не нужно вручную вводить все эти команды. То есть, опять же, используется для таких действий соответствующий автоматизированный скрипт, который сам лично использовал. Где-то, может быть, за одну-две минуты он вам выгрузит всю необходимую информацию.

И также, кстати, он есть по этой ссылочке, по QR-кодику.

Постоянные данные и проверяемые копии

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

Значит, опять же, да, какие…

[На этом запись обрывается на полуслове: доклад Юрия Павенского в трансляцию попал не целиком, вопросов из зала к нему в записи нет. Оставшаяся часть второго дня (Максим Суханов, Александр Дмитриев, Виктор Алюшин, Артур Игитян и закрытие конференции) в записи отсутствует.]