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

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

Recommended Posts

Сергей Ильин

Тема навеяна обзоров Kaspersky Pure, где есть функция безвозвратного удаления данных несколькими алгоритмами

28.jpg

Думаю, будет интересно поговорить о различиях методов удаления. Например, чем отличается наш ГОСТ P50739-95 от их US DoD 5220.22-M или NAVSO P-5239-26.

Вот некоторые популярные утилиты для безопасного удаления данных:

Paragon Disk Wiper

Acronis Drive Cleanser

Simple File Shredder

DataEraser

WipeDrive

Object Wipe

FCD5.

Из бесплатных шреддеров нашелся неплохой Eraser http://eraser.heidi.ie/

Какие программы используете и что порекомендуете для этих целей?

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


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

Сергей Ильин

В PURE данным модулем занимался Олег Зайцев(насколько я знаю). Думаю его стоит пригласить. :)

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


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

Отписал Олегу. :)

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


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

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

Хотя стиралка идет в комплекте и с популярной утилитой CCleaner, кстати. Так что у многих она и так стоит :)

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

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


Ссылка на сообщение
Поделиться на другие сайты
Зайцев Олег
Думаю, будет интересно поговорить о различиях методов удаления. Например, чем отличается наш ГОСТ P50739-95 от их US DoD 5220.22-M или NAVSO P-5239-26.

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

1. затирание контента документа нулями

2. затирание контента единицами

3. затирание кодом 0x55 или 0xAA (чередование единиц или нулей)

4. затирание случайными данными

5. затирание определенными последовательностями байт

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

Далее существуют разнообразные стандарты, определяющие, сколько проходов и какого типа необходимо выполнить, чтобы считать файл стертым. К примеру ГОСТ предписывает затирать нулями или случаными данными, алгоритм Брюса Шнайдера предполагает затирание сначала единицами (0xFF), потом нулями, а потом 5 раз случайными данными (т.е. всего 7 проходов). US NAVSO стандарт предполагает три операции - запись последовательностей типа 01000000, затем FFFFFF7E, затем случайны данные. US 5220.22-M хитрее - данные сначала зариаются случайными числами, затем - дополнительными кодами к записанным на первом проходе, затем снова случайными. Есть еще алгоритм Питера Гутмана, продукт его умеет выполнять, но судя по меню он туда не включен и на то есть причина - в том алгоритме предполагается 35 циклов перезаписи файла (!!), что для бытовых целей совершенно неразумно. Разница в алгоритмах лишь в том, сколько раз и как именно перезаписываются данные. Для большинства целей пригоден ГОСТ или быстрый алгоритм Pure (он мощнее ГОСТ, но основаная суть у них одинакова - затирание случайными данными в один проход).

С выбором все просто - для большинства целей достаточно быстрого алгоритма, а если речь идет о выборе, то полагается, что пользователь точно знает, какой алгоритм ему нужен (это обычно прописывается в политике безопасности)

  • Upvote 15

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


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

Это все есть. Смотрите внимательнее. :)

P.S. Олег, спасибо. ;)

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


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

Олег, благодарю за подробный отчет. Думаю, что многим стало понятно, что из себя представляют алгоритмы удаления данных.

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

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

http://www.anti-malware.ru/forum/index.php?showtopic=481

Просто есть некоторые негуманные методы. Например, такие :)

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


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

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

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


Ссылка на сообщение
Поделиться на другие сайты
spw
Какие программы используете и что порекомендуете для этих целей?

Вот: http://www.jetico.com

Раздел Wiping.

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


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

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

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


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

Может глупый вопрос, но вирусы антивирусами как удаляются? Простым удалением без корзины, перемещением в карантин или какими-то методами затирания? Ведь вирус тоже могут восстановить.

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


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

Вопрос глупый, но он меня мучает. :) Для чего создавать стандарты затираний. Допустим, стандартом предполагается 7 проходов. Для чего, если можно сделать сто пятьдесят?

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


Ссылка на сообщение
Поделиться на другие сайты
Зайцев Олег
Может глупый вопрос, но вирусы антивирусами как удаляются? Простым удалением без корзины, перемещением в карантин или какими-то методами затирания? Ведь вирус тоже могут восстановить.

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

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


Ссылка на сообщение
Поделиться на другие сайты
Зайцев Олег
Вопрос глупый, но он меня мучает. :) Для чего создавать стандарты затираний. Допустим, стандартом предполагается 7 проходов. Для чего, если можно сделать сто пятьдесят?

Это просто - отвечу анекдотом, придуманным в тему: "приходит к доктору пациент с запором. доктор и думает - а зачем пациенту ставить стандартную клизьму в 1 литр, можно же сразу поставить на 10 литров - вдруг поможет в 10 раз лучше" :)

Вот аналогично и со стиранием данных - это компромисс между полезным эффектом с одной стороны (а эфект прост - затереть данные так, чтобы нельзя было их восстановить по остаточной намагниченности на краях дорожек), а с другой - минимизировать затраты ресурсов (каждый проход - это время, прямо пропорциональное размеру диска и обратно - его быстродейсвтию) и износ носителя (какой смысл "пилить" HDD преретирая файл размер в 1 Тб в 200 проходов, если это даст не лучший эффект, что и трехпроходное стирание ?). Вот поэтому и появились стандарты - экспериментально было изучено, сколько раз и чем именно есть резон перезаписывать данные ... причем естественно сколько ученых, столько и мнений по этому поводу, и каждый в чем-то прав по своему. Замечу, что многие стандарты писались давно - когда плотность и метод записи были иными, не было флешек и SSD и так далее (если вспомнить скажем дискету 360 кб - диск был с CDROM по размеру, объем микроскопический, шаговый двигатель для позиционирования головки ... и к примеру современный диск на 2 Тб - разница между ними велика.

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


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

Вы писали о алгоритме с 35 циклами перезаписи, специальные средства восстановления могут восстановить данные, которые были например перезаписаны раз 30? Каков на сегодняшний момент максимум.

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


Ссылка на сообщение
Поделиться на другие сайты
Зайцев Олег
Вы писали о алгоритме с 35 циклами перезаписи, специальные средства восстановления могут восстановить данные, которые были например перезаписаны раз 30? Каков на сегодняшний момент максимум.

Минимум - 1. Максимум - бесконечность ... главный вопрос - где оптимум. По моему мнению оптимум - один цикл перезаписи случайными данными, этого на мой взгляд достаточно для подавляющего большинства пользователей (более того - для SSD и Flash больше одного цикла не повлияет на качество стирания, но зато гарантировано сократит его срок службы)

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


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

Извините. Я несколько о другом, я понимаю, что по остаточной намагниченности, применяя специальное оборудование могут восстановить первоначальные данные после 1 перезаписи. Вот есть алгоритм, включающий в себя 35 циклов затирания. Получается, даже если учесть некоторую избыточность в целях надежности, то допустим, перезаписав раз 10 данные (именно этот показатель для HDD мне и интересен) при наличии необходимости их можно восстановить? Вот после одного затирания информацию можно восстановить, а после 2; 3; 4;....30;... Где тот предел, дальше которого существующее оборудование не позволяет зайти.

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


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

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

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


Ссылка на сообщение
Поделиться на другие сайты
Зайцев Олег
Я несколько о другом, я понимаю, что по остаточной намагниченности, применяя специальное оборудование могут восстановить первоначальные данные после 1 перезаписи. Вот есть алгоритм, включающий в себя 35 циклов затирания. Получается, даже если учесть некоторую избыточность в целях надежности, то допустим, перезаписав раз 10 данные (именно этот показатель для HDD мне и интересен) при наличии необходимости их можно восстановить? Вот после одного затирания информацию можно восстановить, а после 2; 3; 4;....30;... Где тот предел, дальше которого существующее оборудование не позволяет зайти.

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

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

  • Upvote 10

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


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

Зайцев Олег.

Спасибо, теперь все мне понятно.

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


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

Это все ерунда ... ибо:

1. Если антивирус убил некий компонент малвари, то он его детектирует сигнатурно (а как же иначе ?), а раз так - то монитор антивируса или убъет файл после его пересоздания, или блокирует его создание, или блокирует его зарузку ... независимо от того, как был восстановлен файл

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

3. для восстановления файла необходимы привилегии администратора, открытие диска для прямого посекторного чтения/записи (последнее сразу вызовет подозрение у антивируса)

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


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

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

При записи информации в современных HDD метод записи данных уже предполагает полное перемагничивание участка поверхности диска. Потому остаточной намагниченности просто не существует.

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


Ссылка на сообщение
Поделиться на другие сайты
Зайцев Олег
Вот не думал я, что услышу здесь повторение известного мифа об остаточной намагниченности, по которой можно... :)

При записи информации в современных HDD метод записи данных уже предполагает полное перемагничивание участка поверхности диска. Потому остаточной намагниченности просто не существует.

Это не миф - реальность. Имеется в виду намагниченность не в той зоне, куда записаны данные - по краям "дорожки". Дело в том, что головка не может 100% точно навестись на дорожку и идеально перезаписать данные - она перезапишет скажем 99.9% дорожки, но где-то по краям останутся неперемагниченные домены. Головкой HDD эти данные никогда не прочитать, а вот специальным оборудованием в теории - можно (при этом если внимательно почитать мои посты - я особо акцентирую внимание на том, что есть разница между старыми носителями и современными HDD - где разница в плотности записи различается на порядки).

См. http://ru.wikipedia.org/wiki/%D0%9E%D1%81%...%86%D0%B8%D1%8F - раздел "Осуществимость восстановления перезаписанных данных"

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


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

Я тоже. Потому по оставшимся кусочкам

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


Ссылка на сообщение
Поделиться на другие сайты
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 может сказаться ?
×