NVMe-накопитель сервера вышел из строя и должен уехать в сервисный центр. Команда считает, что на нём были только временные страницы памяти: рабочие файлы базы лежат в другом хранилище, а приложение ничего не записывало на этот диск напрямую. Но «временная память» могла содержать фрагменты строк, индексов, ключей, токенов доступа или промежуточных результатов. Пока они находились в DRAM, команда воспринимала их как часть процесса. После прозрачного переноса те же байты оказались на блочном устройстве и получили другой срок жизни. Это не означает, что любой NVMe-уровень автоматически небезопасен. Меняется граница, внутри которой нужно доказать защиту. Вопрос уже не сводится к настройкам PostgreSQL или Redis: он затрагивает шифрование устройства, владение ключами, доступ администратора, замену оборудования и подтверждённую очистку.

Страница покидает границу оперативной памяти

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

Для эксплуатации это существенная перемена. DRAM и SSD по-разному переживают выключение, отказ и физическое изъятие. Накопитель способен хранить данные после потери питания и покинуть контролируемую серверную во время ремонта. На уровне страницы нет бизнес-смысла. Система не знает, содержит ли она открытый каталог, персональные данные или часть ключевого материала. Поэтому политика защиты не может исходить из предположения, что на NVMe попадёт только нечувствительный «холодный» объём.

Шифрование СУБД и памяти защищает разные копии

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

Отсюда следует важная граница: шифрование файлов СУБД не обязано защищать страницу, которую отдельный механизм памяти записал на другой блочный путь. Это не утверждение, что защита отсутствует. Это требование подтвердить, где именно выполняется шифрование и какие устройства входят в его область. Linux предлагает dm-crypt — официальный механизм шифрования блочного устройства через device mapper. Он может защищать данные на томе до записи на физический носитель. Но наличие технологии ещё не доказывает, что конкретный NVMe-уровень действительно проходит через неё и использует нужные правила. Проверяется весь путь: какой том видит механизм памяти, где происходит шифрование, остаются ли незашифрованные временные копии и что доступно после перезапуска. Название алгоритма без этой схемы создаёт ложное чувство завершённой защиты.

Пользу шифрования определяет управление ключами

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

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

Общий хост меняет модель изоляции

На уровне приложения клиент ожидает, что PostgreSQL или Redis не видит данные соседа. При прозрачном переносе нужно сохранить это свойство и на пути к NVMe. Страница одного арендатора не должна стать доступна другому через ошибку адресации, повторное использование области или неверные права. Особое положение имеют администраторы хоста. Они управляют устройствами, ключами, аварийными снимками и восстановлением. Изоляция арендаторов поэтому включает не только ограничения процессов, но и правила привилегированного доступа, журналирование действий и разделение обязанностей.

Прозрачность для СУБД не делает ответственность прозрачной. Владелец базы может не видеть устройство, однако провайдер всё равно обязан описать, где оказываются страницы и кто отвечает за защиту. Иначе клиент предполагает модель «только RAM», которой фактически уже нет. Сбой расширяет картину. Crash dump — файл с состоянием процесса или системы после аварии — способен содержать фрагменты памяти. Swap, служебные файлы и аварийные копии создают дополнительные места. Их не нужно перечислять бесконечно, но нельзя ограничить политику одним NVMe.

Удаление страницы не означает очистку SSD

Когда процесс освобождает память, адрес можно выдать другой задаче. Когда удаляется файл, файловая система перестаёт считать его доступным. Ни одно событие само по себе не доказывает, что прежние биты физически исчезли из флеш-памяти. SSD управляет размещением данных внутри устройства. Из-за внутреннего распределения записи обычная перезапись логического адреса не является универсальным способом очистить все физические копии. Поэтому вывод накопителя из эксплуатации требует отдельной процедуры.

NIST SP 800-88 Rev. 2 использует понятие media sanitization — проверяемой очистки носителя с учётом его типа, чувствительности данных и дальнейшего использования. Цель процедуры — сделать восстановление данных практически невозможным выбранным для организации способом. Один из вариантов — cryptographic erase, или криптографическое стирание: уничтожение ключа, который нужен для расшифровки данных на носителе.

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

Безопасность охватывает весь жизненный цикл

В классе решений gigaRAM подходящие страницы могут прозрачно обслуживаться через NVMe. Публичная продуктовая страница описывает эту механику, но сама по себе не доказывает конкретную реализацию шифрования или изоляции. Эти свойства закрепляются архитектурой и эксплуатационными правилами. Решение оценивают от появления страницы до конца жизни носителя. В обычной работе важны шифрование и изоляция. При перезапуске — доступность ключей. При сбое — дампы и аварийные копии. При замене — отзыв доступа и проверяемая очистка.

Иногда требования организации запрещают размещать конкретный класс данных на общем NVMe-уровне. Причиной может быть невозможность разделить ключи, подтвердить очистку, ограничить привилегированный доступ или уложиться в восстановление. Отрицательный вывод здесь защищает бизнес, а не блокирует технологию. В других случаях риск можно принять после ясного распределения ответственности. Но формулировки «это всего лишь память» и «SSD зашифрован» недостаточны. Первая игнорирует сохранность флеш-памяти, вторая — ключи, копии и жизненный цикл. Главный вывод: страницы СУБД на NVMe становятся хранимыми данными со своим путём доступа и удаления. Безопасность определяется не одной функцией, а связью записи, ключей, изоляции, восстановления, замены и утилизации носителя.

Источники. Meta Engineering — TMO описывает перенос страниц на более медленные уровни.

Linux dm-crypt — официальный механизм шифрования блочных устройств.

NIST SP 800-111 связывает шифрование хранимых данных с управлением ключами, а NIST SP 800-88 Rev. 2 — с проверяемой очисткой носителей.

PostgreSQL 17 — Encryption Options показывает границы разных уровней шифрования.

Страница продукта используется только для механики и позиционирования.