Диск ушёл в утиль вместе с данными клиентов

MAATRIX

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

Почему замена диска — это не про данные, а про доступность

Когда диск умирает или начинает сыпать ошибками, вся операционная энергия уходит на то, чтобы сервис не упал. RAID-контроллер помечает диск как failed, приходит алерт, инженер выдёргивает накопитель, вставляет новый, запускает ресинк массива — и следит за прогресс-баром, пока идёт rebuild. Это правильная последовательность действий с точки зрения доступности: чем быстрее заменить деградировавший диск, тем меньше окно, когда массив работает в деградированном режиме и уязвим ко второму отказу.

Проблема в том, что на этом сценарий обычно заканчивается. Старый диск кладут в коробку — «на всякий случай, вдруг это не диск виноват, а контроллер» — или сразу относят туда, где заканчивается жизненный цикл железа: в ящик для гарантийного возврата поставщику, в контейнер для утилизации электроники, иногда просто в шкаф, откуда через полгода его отдадут кому-то «на запчасти». Ни на одном из этих шагов никто не спрашивает: а данные с него стёрты?

Это не гипотетический риск. Данные на вышедшем из строя диске в подавляющем большинстве случаев физически читаемы даже когда сам диск не проходит SMART-проверку целиком. Диск, который RAID-контроллер пометил как failed из-error rate или timeout'ов, почти всегда всё ещё можно подключить напрямую и прочитать блоками — контроллер выбраковывает диск по критериям надёжности массива, а не потому что данные на нём разрушены. Для SSD ситуация ещё хуже: контроллер накопителя может физически изнашиваться и терять способность записывать новые данные, при этом продолжая прекрасно отдавать уже записанные — то есть «умерший» для записи SSD может быть отличным источником чтения для того, кто получит его в руки.

Три канала утечки: гарантия, утилизация, продажа

У диска, покинувшего стойку, есть по факту три типовых маршрута дальше, и на каждом данные остаются доступны третьей стороне.

Гарантийный возврат. Диск с истекающим ресурсом или явным браком отправляется производителю или поставщику по RMA — часто без всякого стирания, потому что процесс замены и так под давлением времени, и «просто отправить брак обратно» кажется естественным финалом. Производитель получает физический носитель с полным содержимым файловой системы. У серьёзных вендоров есть процедуры уничтожения возвращённых по гарантии носителей, но это их внутренняя процедура, соответствие которой компания, отправившая диск, никак не проверяет и не может проверить постфактум.

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

Продажа и передача. Часть оборудования при апгрейде или закрытии проекта продаётся — напрямую, через маркетплейсы б/у-железа или в составе продажи всей стойки. Покупатель серверных SSD и HDD с вторичного рынка — обычная практика, и часть таких дисков попадает в продажу без единого прохода стирающей утилиты, потому что продавец на стороне поставщика считал это «не своей задачей», а покупатель на стороне компании, что закупала оборудование новым, никогда не думал о том, что когда-то это железо снова окажется на рынке.

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

Что на самом деле остаётся на диске после «удаления»

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

# «удаление» файла — просто снимает ссылку в файловой системе
rm /var/lib/postgresql/data/base/16384/12345
# сами блоки данных на диске физически никуда не делись

# быстрое форматирование — переписывает только метаданные ФС
mkfs.ext4 -F /dev/sdb1
# таблица инодов и суперблок новые, содержимое старых блоков — прежнее

# пересборка RAID при замене диска не трогает старый диск вообще
# он просто исключается из массива и физически изымается как есть

Для HDD данные буквально лежат в намагниченных секторах до тех пор, пока их физически не перезапишут — специализированное ПО восстановления читает их поблочно в обход файловой системы, не обращая внимания на то, что там числится «удалённым». Для SSD ситуация тоньше и в чём-то опаснее: из-за wear leveling логический адрес блока не соответствует напрямую физической ячейке, и даже команда перезаписи логического блока может оставить старую физическую копию данных нетронутой где-то в резервной области накопителя, если та ещё не была стёрта контроллером и переиспользована. Это подробно разобрано в статье про то, почему обычное обнуление ведёт себя на SSD не так, как ожидается — контроллер SSD распоряжается физическими ячейками сам, и файловая система не имеет прямого контроля над тем, что реально стёрто, а что просто помечено как свободное.

Правильный процесс: стирание — обязательный шаг перед выводом диска за периметр

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

Порядок действий на практике:

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

1. Выполняется программное стирание поверх всего адресуемого пространства. Для HDD — многопроходная перезапись или как минимум однократный проход нулями/случайными данными плюс верификация; для SSD корректнее использовать команду безопасного стирания на уровне контроллера, а не файловую перезапись, потому что она гарантированно затрагивает и резервные области, которые обычная перезапись логических блоков не достаёт.

# HDD — перезапись случайными данными во весь объём устройства
shred -v -n 1 --random-source=/dev/urandom /dev/sdb

# SSD с поддержкой ATA Secure Erase — команда на уровне контроллера,
# а не файловая перезапись
hdparm --user-master u --security-set-pass p1 /dev/sdb
hdparm --user-master u --security-erase p1 /dev/sdb

# NVMe — встроенная команда format с криптографическим или user-data стиранием
nvme format /dev/nvme0n1 --ses=1

# после стирания — выборочная проверка, что сектора действительно пусты
dd if=/dev/sdb bs=1M count=100 | hexdump -C | head -20

1. Факт стирания документируется до того, как диск физически уйдёт за периметр. Минимально нужны: серийный номер диска, дата и метод стирания, кто выполнил, результат верификации. Формат неважен — таблица в трекере, запись в CMDB, отдельный лог-файл, — важно, чтобы для любого диска, покинувшего инфраструктуру когда-либо, можно было поднять запись и показать, что стирание было выполнено, а не просто предположительно случилось.

1. Для действительно чувствительных данных — не стирание, а уничтожение. Если на диске лежали данные, утечка которых означает регуляторные последствия, потерю доверия клиентов или прямой финансовый ущерб (платёжные данные, персональные данные в объёме, подпадающем под серьёзные требования, ключи шифрования, медицинские записи), программное стирание — не тот уровень гарантии, который стоит применять. Дешевле и надёжнее физически уничтожить накопитель: промышленный шредер для HDD и SSD, дегауссер для магнитных носителей (не работает для SSD — там нет магнитного слоя, который можно размагнитить), либо сверление/дробление пластин на месте с фиксацией на фото или видео как части акта об уничтожении. Это особенно уместно, когда диск отказал настолько, что программное стирание на нём вообще невозможно выполнить, — тогда единственный оставшийся вариант гарантированно закрыть риск — не дать носителю физически покинуть периметр в целом виде.

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

Шифрование на уровне диска как страховка, а не замена процесса

Отдельный практический вопрос — насколько шифрование диска (LUKS, шифрование на уровне контроллера накопителя, шифрование облачного диска у провайдера) снимает проблему. Ответ: частично и только при правильном обращении с ключами.

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

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

Что проверить в собственном процессе прямо сейчас

Прежде чем полагаться на то, что «у нас, наверное, всё стирается», стоит честно ответить на несколько вопросов о текущем процессе:

• Кто в компании физически несёт диск от стойки до места, откуда он дальше уходит — и знает ли этот человек, что перед этим шагом что-то должно произойти со стиранием?
• Есть ли хоть один диск за последний год, для которого не осталось записи о том, что стирание было выполнено?
• Что происходит с диском, который отказал настолько, что он вообще не читается штатными средствами — есть ли для этого случая процедура, отличная от «просто выкинуть»?
• Кто отвечает за RMA-возвраты — команда эксплуатации, которая думает про данные, или закупки/АХО, которая думает про логистику и гарантийные сроки?

Последний вопрос на практике самый частый источник дыры: гарантийные возвраты и списание оборудования организационно относятся к другому отделу, у которого стирание данных просто не входит в чек-лист, потому что это не их зона ответственности с их точки зрения. Процесс decommission диска должен быть закреплён за той же командой, которая отвечает за данные на этом диске, а не за той, которая отвечает за инвентарный учёт железа — или как минимум должен быть обязательный шаг-барьер между эксплуатацией и логистикой, через который диск не проходит без отметки о стирании.

Более широкий взгляд на вывод сервиса или сервера из эксплуатации целиком — не только дисков, но и учётных записей, сетевых правил, DNS-записей — разобран в чек-листе вывода сервиса из эксплуатации; стирание накопителей — лишь один пункт в этом списке, но один из немногих, которые физически необратимы, если пропущены.

Частые вопросы