Защита резервных копий от удалений и повреждений
Резервные копии традиционно считаются последним рубежом обороны в случае кибератаки. Однако их эффективность напрямую зависит от доступности и целостности самих копий. В условиях атак вымогателей злоумышленники целенаправленно ищут хранилища бэкапов, чтобы удалить или повредить их, прежде чем приступить к шифрованию основных систем. Это значительно усложняет восстановление данных и увеличивает ущерб для компаний.
Риски компрометации административных учеток
Стандартные модели разграничения доступа не всегда могут предотвратить такие сценарии. Если атакующий получает привилегированные учетные данные администратора проекта, он может использовать легитимный токен и стандартный API для выполнения своих вредоносных действий. Для системы хранения данных такой запрос выглядит как законное действие уполномоченного пользователя, что приводит к удалению резервных копий вместе с продуктивными данными.
Примеры критических уязвимостей
Особенно уязвимыми становятся ситуации, когда резервные копии хранятся на том же сервере, что и основной сайт или почтовый сервис компании. В случае взлома инфраструктуры, где сайт и почта являются ключевыми каналами коммуникации с клиентами, компрометация одного сервера может привести к полной потере как рабочих данных, так и их резервных копий, делая восстановление крайне затруднительным или невозможным.
Object Lock используем уже почти год для S3-бэкапов, и это реально спасает. Был случай, когда админ по ошибке запустил скрипт очистки старых версий, а благодаря WORM-режиму все критичные бэкапы остались нетронутыми. Единственный минус – иногда сложно заранее рассчитать нужный retention, но лучше перестраховаться. Советую всегда ставить чуть больший срок, чем кажется необходимым, чтобы потом не кусать локти.