Comments 4
Вы пишете правильные вещи про риски и необходимость immutable storage. Но создаётся впечатление, что "настоящий" WORM - это только лента, что не так. Тем более, восстанавливаться с нуля, с перечитыванием метаданных с ленты, можно долго.
Есть много альтернатив - от реализации на уровне СХД (ONTAP, PowerStore, OceanProtect) до S3 с compliance object lock.
Тут Вы не совсем правы. Все указанные Вами технологии работающие в рамках инфраструктуры компании не дают такой гарантии как "железный" ленточный картиридж WORM. Если есть доступ у сотрудника, то на уровне СХД (ONTAP, PowerStore, OceanProtect) до S3, можно вполне себе изменить права на ресурсе и данные вполне себе стираются.
А картридж защищен на физическом уровне, на него просто головка не запишет/сотрет данные несмотря на любые права суперадмина.
Исключением может являться только наличие внешнего ресурса типа S3 на который ни у кого из компании нет прав на изменение политики доступа.
Если есть доступ у сотрудника, то на уровне СХД (ONTAP, PowerStore, OceanProtect) до S3, можно вполне себе изменить права на ресурсе и данные вполне себе стираются
Нет, наличие административного доступа в таких СХД не позволяет уничтожить данные никаким способом, в этом их смысл - обеспечить immutable. Только физически идти и ломать оборудование.
То же самое касается внешних S3 хранилищ - compliance lock не позволяет вам отменить блокировку или уменьшить ее срок, даже если у вас есть полный доступ ко всем бакетам.
Всё так, при использовании правильно настроенной программной неизменяемости (compliance, а НЕ governance / enterprise lock) на подобных СХД от крупных вендоров даже административные пользователи системы не смогут изменить или удалить данные.
Но если смотреть на модель угроз чуть шире, то появляется нюанс. Тот же SEC 17a-4, в соответствии с которым, среди прочего, подобные системы хранения сертифицируются, определяет, что соответствующие данные должны храниться "exclusively in a non-rewriteable, non-erasable format", но - важно - это относится только к самим данным, а не к системе в целом.
Соответственно, берем ONTAP. Попадаем в SP бутменю, запускаем wipeconfig, и вуаля: "(4) Clean configuration and initialize all disks.". И это всё ещё в подавляющем большинстве случаев удалённая история (Вы можете положа руку на сердце сказать что все Ваши менеджмент-сети везде прям физически отделены от интернетов?). И никакой SnapLock Compliance не спасает. А аппаратный WORM или всякий airgapping - спасёт.
Я здесь до какой-то степени жульничаю и привожу "катастрофический" сценарий, приведенный пример не входит в стандартную модель угроз системы, а атака выполняется через побочный канал. Но в реальной жизни побочный канал - такой же канал, как основной, а реальный атакующий не будет придерживаться правил.
Инсайдер в системе: как аппаратная блокировка перезаписи защищает данные от собственных сотрудников