Безвозвратное (безопасное) удаление данных - Страница 2 - Общий форум по информационной безопасности - Форумы Anti-Malware.ru Перейти к содержанию
Сергей Ильин

Безвозвратное (безопасное) удаление данных

Recommended Posts

Zilla
Это все ерунда .

это я знаю, но просто ради интереса, в теории же это возможно.. Но, конечно, никто не будет так заморачиваться..

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты
Андрей-001
Потому по оставшимся кусочкам

Блин, а где мой текст? Браузер завис, и что написал пропало.

По оставшимся кусочкам, которые якобы остаются на краях, можно будет прочитать только кашу на киселе.

Каждая ячейка диска хранит в себе всего одно бинарное значение, называемое "бит" (это или 0, или 1). При этом ноль и единица представлены в виде большой или меньшей намагниченности каждой ячейки с некоторой долей погрешности. При этом 0.95 и 1.05 принято считать единицей.

Во время чтения магнитная головка будет считывать состояние намагниченности ячеек, интерпретировать их в 0 и 1 и передавать ОС, которая уже будет интерпретировать совокупность нулей и единиц как определённые файловые системы, каталоги, текстовые документы, изображения и пр. При записи, магнитная головка изменит состояние намагниченности ячеек, сохраняя в них соответствующие данные.

Когда данные перезаписываются некой последовательностью битов (0 и 1), магнитное состояние поверхности изменяет своё физическое состояние и несет в себе лишь последние записанные данные. Потому однократная перезапись поверхности носителя эффективно уже уничтожает её содержимое.

Бытуют утверждения, что на некотором оборудовании можно считать с поверхности не просто 0 или 1, а даже 0.95 или 1.05 (это 0 записанный поверх единицы или, соотвественно, 1 записанная поверх единицы) и потом каким-то аналитическим путём уже получить старые данные.

Но об этом можно говорить только теоретически. Практически же в современных HDD плотность записи доведена уже до такого убойного состояния, что с полной уверенностью утверждать о том, что считанные с поверхности 0.95 это именно 1 поверх 0, а не просто плохая единица и не 1 поверх 0, который был записан поверх ещё одного нуля. При таком раскладе дела на анализ всех версий трактовки поверхности уйдут столетия на самом современном оборудовании.

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты
SBond

Спасибо Олегу Зайцеву, за хорошие ответы, ответы равны очень полезно к прочтению, спасибо :)

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты
Андрей-001
хорошенько потру наждачной бумагой, выброшу частями в разных местах

Лучше разберите хард, снимите блины и разбейте в дрыз как стекляшки ломиком или молотком.

Ещё один миф, когда до сих пор люди думают, что диски внутри HDD металлические. :D:D:D

-----------------

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

SBond

Обратите внимание на слова "запись файла" и "перезапись поверхности " - это две большие разницы. Чем современнее хард, тем плотнее запись, а на FATе, да этот фокус может прокатить, но на все 100% прокатить только из кармана пользователя в карман т.н. мастера по восстановлению. Он всё равно наболтает бочку простокваши и слупит с бедного юзера за работу последнее.

Потому, Как избежать потери данных? поважнее будет, см. тут.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты
SBond
Обратите внимание на слова "запись" и "перезапись" - это две большие разницы.

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты
UIT
что диски внутри HDD металлические

Других я не видел и особенно за материалом текущих не слежу. Надо было мне DTLA взять в свое время, вот бы и попробовал потом, молотком:)

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты
Андрей-001
Думаю ведь так каждый поступает, удаляет просто файл.

Не каждый. Далеко не каждый. Домохозяйки и домохозяева, да, так, а то даже и Корзину не чистят. Но если вы просто удалите файл в корзину, то восстановить его можно будет оттуда наверняка. Если вы удалите файл держа нажатой клавигу Shift, то восстаналивать файл будет уже труднее. Но это возможно сделать даже утилитками из Инета, если сразу спохватиться. Подробнее хотелось бы написать, но извините счас уже нет времени писать, что такое удаление и как реально оно осуществляется средствами ОС, как восстанавливается.

При желании удаления компроматной инфы, используйте хотя бы один из методов, интегрированный в Kaspersky Crystal, но после каждого способа делайте контрольную перезагрузку. Потом создавайте на том же месте аналогичный (одноименный), но альтернативный, пустой или забитый шелухой файл (папку), запускайте Kaspersky Crystal с другим методом, удаляйте "липу", делайте контрольную перезагрузку, потом снова "липу" и т.д. Так вернее будет, но хлопотно это. :)

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты
Сергей Ильин
Нет уж, если буду диск выбрасывать, сначала все перезапишу несколько раз, потом вскрою, хорошенько потру наждачной бумагой, выброшу частями в разных местах и в разное время хладные остатки (но пластину оставлю у себя:) Для избежания сюрпризов и большего душевного спокойствия.

Что же там такое на нем сейчас лежит? :) А если серьезно, то проще для утилизации забить в него дюбель.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты
UIT
Что же там такое на нем сейчас лежит?

Ничего компрометирующего и незаконного - нет. А вот личной информации много.

проще для утилизации забить в него дюбель.

Так у меня только домашние диски и разобрать в случае поломки мне более интересно.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты
Андрей-001
то проще для утилизации забить в него дюбель.

Точно, или сделать из него тем же дюбелем решето...

Где-то я и другие варварские методы описывал, но "разбить" блины лучше. К тому же и запасётесь мощными магнитами.

Только берегите пальцы при их расцеплении.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты
UIT
Точно, или сделать из него тем же дюбелем решето

Расскажите, дюбели прошивают в 100% винчестер и бывает ли рикошет дюбеля или разлет осколков от HDD?

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты
Андрей-001
Расскажите, дюбели прошивают в 100% винчестер и бывает ли рикошет дюбеля или разлет осколков от HDD?

Бывает. Технику безопасности никто не отменял. Пальцы подороже будут. А глаза и тем более...

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

Если только вы перед тем, чтобы избавиться от харда, не покажете какому-то спецу свой диск и не скажете: "Вот тут были мои данные, я их удалил. Не пытайся их восстановить и сделать на меня компромат!"

Тогда на 100% он попытается это сделать. ;)

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты
Зайцев Олег
Расскажите, дюбели прошивают в 100% винчестер и бывает ли рикошет дюбеля или разлет осколков от HDD?

Когда я для статьи подорвал один HDD во включенном состоянии пиропатроном, то с него сорвало крышку, а разбитый в дребезги диск разлетелся как шрапнель :)

piroteh_m.jpg

Так что технику безопасности при уничтожении данных лучше соблюдать :) А если серьезно, то если ценные данные зашифровать, то это уже очень серьезная защита - а если зашифрованный объект еще и удален необратимым удадением - то шансов что-то восстановить их в бытовых условиях никаких. Плюс шифрование решит еще одну проблему - если данные столь важны и критичны, то с них необходимо снимать резервные копии - а копия зашифрованного объекта надежнее в плане защиты от утечки (так как нередко "утекают" не сами данные, а их резервные копии)

post-280-1270789626_thumb.jpg

  • Upvote 5

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты
savvy

Мои два копейка.

Бытуют утверждения, что на некотором оборудовании можно считать с поверхности не просто 0 или 1, а даже 0.95 или 1.05 (это 0 записанный поверх единицы или, соотвественно, 1 записанная поверх единицы) и потом каким-то аналитическим путём уже получить старые данные.

Но об этом можно говорить только теоретически. Практически же в современных HDD плотность записи доведена уже до такого убойного состояния, что с полной уверенностью утверждать о том, что считанные с поверхности 0.95 это именно 1 поверх 0, а не просто плохая единица и не 1 поверх 0, который был записан поверх ещё одного нуля. При таком раскладе дела на анализ всех версий трактовки поверхности уйдут столетия на самом современном оборудовании.

Позвольте усомниться в доводах. Лично я не сталкивался, и вряд-ли столкнусь с специализированным оборудованием для восстановления данных с НЖМД. Но некоторые общие познания в электротехнике позволяют выдвинуть мне предположение что не всё так просто как кажется предыдущему оратору. Итак, пофантазируем в ожидании опровержения.

Во-первых, поскольку здесь, как и везде, речь идет о краевых зонах полей ячеек, то отсюда можно сделать два предположения. Первое было сделано коллегой: остаточная намагниченность влияет на _суммарный_ уровень магнитного поля, т.е. допускается что он составит 0.95 после записи 1 на место 0-ля, хотя здесь может и сказаться неточный уровень записи и сказать что здесь была остаточная намагниченность или же плохая запись действительно нельзя. Точнее будет сказать о записи 0-ля на место 1-цы, т.е. при уровне 0.05 уже как-то вероятней что была единица. Но забыт второй вывод, предпосылки к которому были: специализированное оборудование должно быть для того и специализированное, чтобы иметь считыватель чуствительнее, работать на низких оборотах и позиционировать считыватель именно на краях (а на краях мы получаем превальвирование уровня предыдущего сигнала нежели в центре). Тем кто скажет что технология и так на грани максимума (чуствительность или микроскопичность исследуемых областей) можно индуктивно возразить, что всегда есть более совершенные решения, просто они стоят намного дороже и не оправдаются на рынке ширпотреба (например так в космоиндустрии и в особых службах, опять же - госзаказ).

В общем, ни разу не прозвучало каких-то технических выкладок с численным анализом, не упомянута дискретизация сигнала и "волновые" переходы и наложения.

Во-вторых, после получения данных, но не нулей и единиц, а именно уровней сигнала по всему участку, т.е. не линейно а в объеме в отношении блина (x,y,z), разумно их обрабатывать применяя как минимум два фактора:1) наложение уровней сигнала с полей ячейки на "соседей" и 2) учёт следующих уровней организации информационного носителя - это специфика ФС и специфика файлов данных, т.е. здесь соседствуют методы криптоанализа.

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты
Deja_Vu
остаточная намагниченность влияет на _суммарный_ уровень магнитного поля, т.е. допускается что он составит 0.95 после записи 1 на место 0-ля, хотя здесь может и сказаться неточный уровень записи и сказать что здесь была остаточная намагниченность или же плохая запись действительно нельзя. Точнее будет сказать о записи 0-ля на место 1-цы, т.е. при уровне 0.05 уже как-то вероятней что была единица.

1 считается, если мне не изменяет память при уровне 0.85 от идеала.

0 при 0.15.

Среднее значение - как битый.

При этом, все зависит от конкретного жесткого диска. Каждый производитель может сделать что угодно. Так, что чисто теоретически, можно по остаточной намагниченности что-то восстановить(что-то вроде текстого файла или bmp картинки, но не более). На практике же - это бред.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты
Андрей-001
несколько поспешно отметать напрочь "легенду" не углубляясь в исследуемую область.

Фантазия – дело хорошее, только когда находит своё воплощение. В деле восстановления данных важен только реально полученный результат. За расписанные теории и рассказанные мифы пользователь деньги не заплатит.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты
savvy
1 считается, если мне не изменяет память при уровне 0.85 от идеала.

0 при 0.15.

Среднее значение - как битый.

При этом, все зависит от конкретного жесткого диска. Каждый производитель может сделать что угодно. Так, что чисто теоретически, можно по остаточной намагниченности что-то восстановить(что-то вроде текстого файла или bmp картинки, но не более). На практике же - это бред.

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

Фантазия – дело хорошее, только когда находит своё воплощение. В деле восстановления данных важен только реально полученный результат. За расписанные теории и рассказанные мифы пользователь деньги не заплатит.

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

Но к чему Ваш пост собственно?

Господа, "критикуя - предлагай, предлагая - делай".

Повторяюсь, я не углублался в предпосылки, просто указал на их значимость против выражений типа "При записи информации в современных HDD метод записи данных уже предполагает полное перемагничивание участка поверхности диска. Потому остаточной намагниченности просто не существует."(оттуда мысль? нет выкладок) и "в современных HDD плотность записи доведена уже до такого убойного состояния..." (как измеряется "убойность"?). Вам уже предлагали ознакомится с статьей, но движения не видно.

Мой пост призывает к обсуждению, а не останавливаться на том что "нельзя и всё тут".

И вот вам ещё мысль: как минимум теоретически подкаст имеет место быть до поры пока магнитные ячейки не дойдут шириной в один домен магнитного поля.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты
Сергей Ильин

Коллеги, мне кажется, что ваши рассуждения про считывание остаточной намагниченности относятся только к случаях однократного затирания данных нулями, единицами или случаными последовательностями. В случае же использования использования, например, алгоритма Брюса Шнайдера (последовательное затирание нулями, единицами и 5 раз случайными числами) все это работать не будет.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты
Андрей-001
Мой пост призывает к обсуждению, а не останавливаться на том что "нельзя и всё тут".

А предлагаете обсуждать?

Тема-то называется "Безвозвратное удаление данных, Алгоритмы, методы, утилиты"

Мой пост призывает к обсуждению, а не останавливаться на том что "нельзя и всё тут".
как минимум теоретически подкаст имеет место быть до поры пока магнитные ячейки не дойдут шириной в один домен магнитного поля.

А что тут ещё обсуждать? Теорию взросления или утолщения магнитных ячеек...

Да, так мы далеко уйдём. В dev/null, как минимум.

Для обсуждения способов восстановления данных на форуме есть специальный раздел.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты
Deja_Vu

Как я понимаю, мы обсуждаем, что даже однократное перезаписывание области на диске уже исключает возможность восстановления данных.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты
GISED

Интересная темка... Удаляю с помощью Тюн Ап Утилит... там есть вот такие методы

Быстрое удаление

Быстрое удаление в соответствии с DOD 5220.22

Быстрое удаление, метод Gutmann

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты
Андрей-001
всегда было интересно чем они отличаются...

Метод П. Гутмана состоит из 27 проходов, ориентированных на уничтожение записей, закодированных методами MFM и различными распространенными модификациями RLL. Маскирующие последовательности подобраны таким образом, чтобы обеспечить максимально возможное число переключений знака намагниченности каждого битового интервала. Это значительно затрудняет восстановление перезаписанных данных, поскольку делает нетривиальным раздельное считывание наложенных друг на друга записей.

Метод Б. Шнайдера состоит из семи проходов: первые два - запись единиц и нулей соответственно, и последние пять - запись случайных данных. Однако ни количество проходов, ни выбор маскирующих последовательностей не обоснованы. Вместо этого Шнайдер заявляет: "Последние исследования Национального института стандартов и технологий, выполненные с помощью электронных туннельных микроскопов, показали, что даже этого может быть недостаточно. Честно говоря, если ваши данные достаточно ценны, можете считать, что их полное удаление с магнитного носителя невозможно. Сожгите носитель или сотрите его в порошок. Дешевле купить новый носитель, чем потерять ваши секреты".

Из справки Kaspersky CRYSTAL

  • Быстрое удаление. Процесс удаления состоит из двух циклов перезаписи данных: записи нулей и псевдослучайных чисел. Основное достоинство данного алгоритма – скорость выполнения. Двух циклов достаточно, чтобы затруднить работу программ восстановления данных. Даже если файл будет восстановлен, данные в нем будут безвозвратно уничтожены.
  • ГОСТ Р 50739-95, Россия. Алгоритм проводит один цикл перезаписи псевдослучайными числами и защищает от восстановления данных стандартными средствами. Этот алгоритм соответствует второму классу защищенности из шести по классификации Государственной технической комиссии.
  • Стандарт VSITR, Германия. Проводит семь циклов перезаписи. Алгоритм считается надежным, но требует больше времени для выполнения.
  • Алгоритм Брюса Шнайера. Процесс состоит из семи циклов перезаписи. Метод отличается от немецкого VSITR последовательностью перезаписи. Этот усовершенствованный метод удаления информации, считается наиболее надежным.
  • Стандарт NAVSO P-5239-26 (MFM), США и NAVSO P-5239-26 (RLL), США. Использует три цикла перезаписи. Стандарты различаются лишь последовательностью перезаписи информации.
  • Стандарт DoD 5250.22-М, США. Используется три цикла перезаписи. Считается надежным методом защиты от людей, не обладающих специальными средствами, но во многих случаях данные все же удается восстановить.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты
UIT
Стандарт DoD 5250.22-М, США. Используется три цикла перезаписи. Считается надежным методом защиты от людей, не обладающих специальными средствами, но во многих случаях данные все же удается восстановить.

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты
Андрей-001
как минимум лучше перезаписывать больше трех раз

Существует всего три способа уничтожения информации:

1) Программные методы уничтожения информации (сохранение работоспособности накопителя);

2) Аппаратные методы уничтожения информации (вывод накопителя из строя);

3) И самые действенные и самые дешёвые - это Физические или варварские методы уничтожения самого носителя информации.

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты
UIT

Меня порадовал Б. Шнайдер и туннельный микроскоп:)

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

  • Сообщения

    • Ego Dekker
      Домашние антивирусы для Windows были обновлены до версии 19.0.14.
    • PR55.RP55
      Microsoft ускоряет Проводник в Windows 11 с помощью предзагрузки https://www.comss.ru/page.php?id=18618
    • AM_Bot
      Вендор Crosstech Solutions Group выпустил решение для защиты контейнерной инфраструктуры Crosstech Container Security (CTCS). Оно обеспечивает безопасность контейнерных сред: от сканирования образов до контроля запуска рабочих нагрузок и реагирования на инциденты в средах выполнения.      ВведениеФункциональные возможности Crosstech Container Security2.1. Анализ и контроль безопасности образов2.2. Контроль запуска контейнеров2.3. Безопасность в средах выполнения (Runtime Security)2.4. Безопасность окружения2.5. Внешние интеграцииАрхитектура Crosstech Container Security3.1. Основные компоненты Crosstech Container SecurityСистемные требования и лицензирование Crosstech Container Security4.1. Лицензирование4.2. Требования к аппаратной части4.3. Требования к программной части4.4. Процесс установкиСценарии использования5.1. Сценарий №1. Сканирование образов5.2. Сценарий №2. Политики безопасности образов контейнеров5.3. Сценарий №3. Контроль запуска контейнеров5.4. Сценарий №4. Мониторинг безопасности сред выполненияВыводыВведениеРоссийский рынок контейнерных разработок постоянно растёт. В 2024 году затраты на ПО для контейнеризации достигли 3 млрд рублей — это на 66 % больше, чем в 2023. Контейнерные технологии ускоряют процессы разработки, экономят ресурсы компаний, поэтому их всё чаще внедряют в свою работу ИТ-департаменты.Вместе с ростом масштабов контейнеризации увеличивается и поверхность атак: уязвимости в образах, ошибки конфигураций, несанкционированные действия внутри контейнеров. Crosstech Container Security помогает компаниям выстраивать комплексную систему защиты контейнерной инфраструктуры.Функциональные возможности Crosstech Container SecurityCrosstech Container Security объединяет функции анализа, мониторинга и управления безопасностью контейнерных сред. Решение охватывает весь жизненный цикл контейнера — от момента его создания до удаления. Продукт помогает DevSecOps-командам выявлять уязвимости, проверять конфигурации, контролировать сетевую активность и реагировать на инциденты в режиме реального времени.Анализ и контроль безопасности образовCrosstech Container Security интегрируется с реестрами хранения образов и позволяет проводить их сканирование как в ручном режиме, так и по расписанию. В результате анализа система обнаруживает дефекты в образах: уязвимости, неправильные конфигурации, секреты, а также фиксирует используемые в образах OSS-лицензии для пакетов и библиотек. По каждому найденному дефекту предоставляется детальная информация.CTCS поддерживает экспорт SBOM в форматах SPDX и CycloneDx, что упрощает аудит и обмен данными с другими решениями. Интерфейс продукта предоставляет визуализацию образов с маппингом (сопоставлением данных) на дефекты безопасности. CTCS также осуществляет дискаверинг (обнаружение) образов, располагающихся в защищаемых кластерах и на standalone-хостах.Для автоматизации контроля доступны настраиваемые политики безопасности образов, разделяемые по критериям:наличие уязвимостей в образах контейнеров выше заданной оценки критичности;наличие уязвимостей в образах контейнеров согласно заданным идентификаторам;обнаружение root в Dockerfile;возможность указания перечня образов, на которые будет распространяться созданная политика безопасности образов.При нарушении хотя бы одного из критериев политики администратор получает уведомление в интерфейсе CTCS и может оперативно принять меры: заблокировать образ, исключить его из деплоя или добавить в список исключений с указанием причины. Такой подход обеспечивает прозрачность процессов и повышает уровень доверия к среде разработки и эксплуатации.Контроль запуска контейнеровРешение обеспечивает контроль запуска контейнеров как в средах Kubernetes, так и на отдельных standalone-хостах в соответствии с заданными политиками безопасности. Это позволяет предотвращать запуск рабочих нагрузок, не соответствующих требованиям безопасности компании, ещё на этапе их инициализации.В зависимости от настроек администратор может выбрать режим реагирования: блокирование или оповещение о нарушении политики безопасности. Информация обо всех срабатываниях отображается в интерфейсе системы, обеспечивая прозрачность и возможность оперативного реагирования.Политики безопасности включают следующие критерии:попытка запуска контейнеров на базе образов, не соответствующих политикам безопасности;попытка запуска контейнеров из-под пользователя root;попытка запуска контейнеров с повышенными привилегиями ядра Linux;контроль запуска контейнеров на базе образов, не прошедших сканирование CTCS.Дополнительно решение поддерживает интеграцию с OPA Gatekeeper и имеет возможность создания и импорта политик через интерфейс CTCS.Безопасность в средах выполнения (Runtime Security)CTCS использует возможности инструмента Tetragon для создания и применения кастомных политик безопасности, позволяющих контролировать сетевые взаимодействия внутри контейнеров. Администраторы могут выбрать набор кластеров для распространения политик, что обеспечивает гибкость при внедрении требований безопасности.Вся информация о срабатываниях политик фиксируется в интерфейсе CTCS, предоставляя специалистам по информационной безопасности прозрачную картину активности в средах выполнения и возможность оперативного реагирования на инциденты.Безопасность окруженияРешение выполняет сканирование кластеров на соответствие стандартам конфигурирования CIS Kubernetes Benchmarks. Аналогично система проводит проверку standalone-хостов на соответствие CIS Docker Benchmarks. Дополнительно CTCS поддерживает сканирование конфигурационных файлов, расположенных в директориях нод кластеров, выполняя роль сканера на основе IaC (Infrastructure as Code, управление инфраструктурой через использование кода).Внешние интеграцииРешение поддерживает интеграцию с реестрами хранения образов, что обеспечивает доступ к актуальным данным для анализа и контроля безопасности контейнеров. Также CTCS поддерживает передачу журналов событий в системы сбора по протоколу Syslog для их централизованного хранения и обработки.Доступна интеграция с системой идентификации, управления доступом Keycloak с поддержкой OAuth и доменными службами каталогов. Это позволяет пользователям авторизовываться в интерфейсе системы через доменные учётные записи. Рисунок 1. Планы по развитию Crosstech Container Security Архитектура Crosstech Container SecurityАрхитектура CTCS реализована в формате однонаправленных соединений со стороны ядра системы в сторону агентов защиты (протокол TCP/IP), располагающихся в защищаемых кластерах. Такой подход позволяет использовать инстанс ядра в единственном экземпляре для инфраструктур, сегментированных по уровням доверия. Рисунок 2. Логическая архитектура Crosstech Container Security Основные компоненты Crosstech Container SecurityCTCS состоит из 3 основных компонентов:CTCS Core — группа микросервисов, отвечающая за управление системой: хранение данных, настроек, создание политик безопасности, бизнес-логика продукта, а также взаимодействие со смежными системами.CTCS Agent-Manager: модуль агент-менеджера реализован в формате оператора Kubernetes с целью контроля за установкой и изменениями кастомных ресурсов (custom resource definition, CRD), а также управления и передачи информации агент-воркерам, устанавливаемым на каждую защищаемую ноду в формате DaemonSet.CTCS Scanner — модуль, сканирующий образы контейнеров на уязвимости, неправильные конфигурации, конфиденциальные данные, информацию по OSS-лицензиям для пакетов и библиотек из состава образа, а также сканирующий кластеры на соответствие стандартам конфигурирования.Системные требования и лицензирование Crosstech Container SecurityПеред выбором модели лицензирования заказчикам рекомендуется оценить масштаб защищаемой инфраструктуры и нагрузку на кластеры. Crosstech Container Security предусматривает гибкий подход: ядро и агенты могут разворачиваться в разных сегментах сети, включая тестовые и продуктивные среды. Такой принцип позволяет оптимально распределять ресурсы и лицензии, избегая избыточных затрат.ЛицензированиеCTCS лицензируется по количеству защищаемых нод, на которые распространяются агенты защиты.В продукте реализовано гибкое лицензирование, которое позволяет заказчикам самостоятельно выбирать перечень защищаемых объектов. При достижении лимита по количеству лицензий, предусмотренных договором, администратор может отключить часть текущих объектов защиты и переназначить лицензии на новые кластеры и ноды. Рисунок 3. Включение/выключение агентов защиты Рисунок 4. Лицензии CTCS На странице лицензирования доступна подробная информация о параметрах действующей лицензии. Пользователь видит:количество оставшихся дней действия лицензии;количество нод, предусмотренных лицензией;актуальные данные о числе используемых нод в рамках лицензии;сведения о типе лицензии;информация о поставщике;информация о владельце лицензии.Рисунок 5. Страница «Лицензирование» Требования к аппаратной частиКластер, на котором производится установка CTCS, должен соответствовать минимальным характеристикам, приведённым ниже. Для определения значений millicpu (единицы времени процессора, эквивалентной тысячной части работы, которую может выполнить одно ядро CPU) рекомендуется воспользоваться документацией Kubernetes.Кластер, на который будет установлен helm-чарт ядра (без учёта сканера) должен иметь характеристики не ниже 8190 millicpu, 7410 MiB RAM.Для каждого экземпляра сканера: 3 CPU, 6 GB RAM, при добавлении дополнительных экземпляров значения увеличиваются пропорционально.В случае использования большего количества реплик значения пропорционально умножаются на их число. По умолчанию в чарте допускается до 6 реплик, что требует 18 CPU, 36 GB RAM.Каждый кластер для развёртывания чарт-агента должен иметь 2 CPU, 8 GB RAM.Необходимый минимум для каждой используемой СУБД PostgreSQL: 4 CPU, 8 GB RAM, 100 GB.Приведённые требования указаны для усреднённой конфигурации и могут быть изменены в зависимости от количества одновременных сканирований образов, генерируемых событий, деплоев, пространств имён (namespaces) и подов.Требования к программной частиДля корректной интеграции и работы приложение CTCS должно быть развёрнуто в кластере Kubernetes. При настройке системы в конфигурационном файле helm-чарта должны быть настроены необходимые параметры.Поддерживаемые контейнерные среды CRI (container runtime interface): containerd и docker.В момент выполнения инструкции на хосте администратора должны быть установлены следующие утилиты для выполнения установки:tar;helm;kubectl.Необходимые сервисы в инфраструктуре:PostgreSQL: рекомендуется размещать базу данных для хранения логов на отдельном инстансе от основной БД, чтобы избежать падения производительности основных операций при большом объёме логируемых событий;Keycloak (опционально, имеется возможность поставки в составе дистрибутива);Vault (опционально, имеется возможность использования стандартного объекта Kubernetes Secret).Требования к операционной системе и ядру:рекомендуется использовать ОС с версией ядра 5.4 или выше для обеспечения поддержки Tetragon;в ядре должна быть включена функция BTF;должны быть активированы модули eBPF и cgroup, а также корректным образом настроены или отключены модули безопасности Linux (LSM), контролирующие запуск eBPF-программ (в соответствии с официальной документацией Tetragon).Требования к версиям Kubernetes:центральная управляющая часть кластера – не ниже версии 1.23;дочерние кластеры – версия 1.23 или выше.Дополнительные требования:В кластере Kubernetes должен быть установлен, подключён и настроен storage class, в котором будет минимум 10 GB свободного места.В master-кластер должен быть установлен External Secrets (опционально).В дочерние кластеры должен быть установлен External Secrets (опционально).Во всех кластерах, где развёртывается ядро и агенты CTCS, должен быть установлен ingress-контроллер.Совокупность этих требований обеспечивает стабильную работу системы и корректное взаимодействие всех модулей CTCS. При соблюдении указанных параметров производительность решения остаётся предсказуемой даже при высокой интенсивности сканирований и большом количестве событий безопасности. Такой подход гарантирует надёжность, масштабируемость и устойчивость контейнерной инфраструктуры.Процесс установкиДля развёртывания CTCS вендор предоставляет архив, содержащий helm-чарты и образы системных контейнеров. При необходимости может быть предоставлена учётная запись для выгрузки дистрибутивов из репозиториев вендора напрямую.Сценарии использованияCrosstech Container Security закрывает ключевые задачи обеспечения безопасности контейнерных платформ — от анализа уязвимостей до защиты на уровне среды выполнения. Решение органично интегрируется в процессы DevSecOps и помогает компаниям повысить устойчивость инфраструктуры к современным киберугрозам без потери скорости разработки.Сценарий №1. Сканирование образовCTCS позволяет выполнять сканирование образов контейнеров, хранящихся как в интегрированных реестрах образов, так и локально в защищаемых кластерах. Рисунок 6. Подключённые реестры После интеграции с реестрами образов на вкладке «Образы» – «Реестры» отображается подключённый реестр и информация о хранящихся в нём образах. Реализовано в формате иерархии:Реестры.Название образа и количество его версий (тегов).Название образа и его версии.Карточка конкретного образа.Рисунок 7. Образ и список его версий Рисунок 8. Карточка образа На каждом уровне иерархии есть возможность запуска сканирования по требованию с выбором типа дефектов, которые будут учитываться в процессе сканирования. Дополнительно предоставляется общая информация об образе, данные о его соответствии установленным политикам, сведения о слоях образов с маппингом на обнаруженные дефекты. Рисунок 9. Слои образа На странице интеграций с реестрами в настройках доступно выставление расписания для проведения автоматизированного сканирования. Рисунок 10. Сканирование по расписанию Для работы с образами, обнаруженными локально в защищаемых кластерах, доступна отдельная вкладка «Образы» – «Локальные образы». Рисунок 11. Таблица локальных образов При запуске процесса сканирования доступен выбор ноды, на которой он будет проводиться. Если обнаруженный образ находится в интегрированном реестре, сканирование будет приоритетно выполняться на стороне ядра системы в рамках интеграции с реестром. Рисунок 12. Выбор нода для проведения сканирования Сценарий №2. Политики безопасности образов контейнеровВ рамках Crosstech Container Security реализовано создание политик безопасности для образов контейнеров. После их настройки система автоматически проверяет все известные образы на соответствие заданным критериям. По результатам проверки на карточке каждого образа отображается информация о соответствии или несоответствии политикам безопасности (Рисунок 7). Если образ нарушает несколько политик безопасности одновременно, в карточке отображается, какие именно политики безопасности были нарушены. Рисунок 13. Создание политики безопасности образов Сценарий №3. Контроль запуска контейнеровВ CTCS доступна интеграция с OPA Gatekeeper, обеспечивающая валидацию контейнерных деплоев и реагирование в соответствии с заданными политиками безопасности.При настройке политик безопасности доступен выбор режима реагирования — оповещение либо блокировка — а также определение перечня критериев безопасности, по которым будет осуществляться контроль. Рисунок 14. Таблица политик валидации и контроля запусков Политики безопасности могут создаваться по выделенным критериям (Рисунок 13) или импортироваться в виде кастомных политик (Рисунок 14). Рисунок 15. Создание политики валидации и контроля запусков Рисунок 16. Импорт кастомных политик безопасности Результаты срабатывания политик доступны в интерфейсе системы, что позволяет оперативно анализировать инциденты и корректировать настройки безопасности. Рисунок 17. Срабатывание политик валидации и контроля запусков Сценарий №4. Мониторинг безопасности сред выполненияВ текущей версии реализован мониторинг безопасности сред выполнения на базе Tetragon, что позволяет контролировать эксплуатацию рабочих нагрузок.В CTCS доступна форма для создания или импорта готовых политик безопасности с возможностью выбора области применения. Рисунок 18. Создание политики среды выполнения При срабатывании политик система отображает перечень событий в формате таблицы. Для каждого события можно перейти в режим детального просмотра, где отображается его идентификатор, дата и время создания, короткое описание и содержание в формате json. Рисунок 19. Событие срабатывания политики среды выполнения ВыводыАнализ решения Crosstech Container Security показал, что в версии 3.0.0 продукт предоставляет широкие функциональные возможности для защиты контейнерной инфраструктуры: от обеспечения безопасности образов контейнеров до контроля запуска и реагирования на нелегитимные процессы в средах выполнения в соответствии с политиками безопасности. CTCS также предоставляет инструменты для проведения сканирований защищаемых кластеров на соответствие стандартам конфигурирования, что повышает уровень безопасности контейнерной инфраструктуры.Достоинства:Архитектура. Благодаря однонаправленным соединениям со стороны ядра системы в сторону агентов защиты обеспечивается соответствие требованиям заказчиков, которые используют «Zero Trust»-модель на уровне сегментов инфраструктуры.Широкая площадь покрытия. CTCS обеспечивает контроль запуска контейнеров не только в рамках оркестратора Kubernetes, но и на отдельных хостах контейнеризации за счёт использования standalone-агентов.Гибкие возможности при работе с API. Весь функционал из веб-интерфейса CTCS также доступен для вызова через API, что позволяет специалистам заказчика решать нетривиальные задачи в рамках своей рабочей деятельности и интегрировать продукт в существующие процессы.Удобство при работе со сканированием образов. Иерархический подход обеспечивает гибкость при выборе области сканирования и повышает прозрачность анализа.Недостатки:Отсутствие возможности встраивания в процесс сборки (CI/CD) (планируется к реализации в первом квартале 2026 года).Отсутствие данных по ресурсам Kubernetes (Workloads, RBAC, Custom Resources, Feature Gates): планируется в 4-м квартале 2025 – 1-м квартале 2026).Отсутствие настройки гибкого разграничения прав доступа пользователей в интерфейс системы (реализация запланирована на первый квартал 2026).Отсутствие отчётности по результатам работы с системой (планируется в первом квартале 2026).Реклама, 18+. ООО «Кросстех Солюшнс Групп» ИНН 7722687219ERID: 2VfnxvVGwXfЧитать далее
    • demkd
    • PR55.RP55
      И ещё это: https://www.comss.ru/page.php?id=18330 Это и на работе Образов с Live CD может сказаться ?
×