Шифрование данных в покое: LUKS, SSE-KMS, Vault

Шифрование данных в покое (encryption at rest): где рвётся защита

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

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

Второй пласт — кэш приложений и архивы журналов. Сессии и временные выгрузки ложатся на локальный диск узла, а логи содержат токены и персональные данные в открытом виде. Формально это не «данные», фактически — готовый доступ к сервису.

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

Политика шифрования тогда отвечает на три вопроса: что шифруется по умолчанию, где живут ключи и кто их ротирует. Ниже разбираем, как это закрывается.

Что меняется после внедрения: классы рисков и время реакции

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

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

Третий — аудит доступа к данным становится проверяемым. Каждая выдача ключа оставляет запись: кто, когда, к какому ресурсу и на каком основании получил доступ. Разбор инцидента идёт по журналу, а не по опросу команд и сверке логов приложений.

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

Сравнение подходов: encryption на диске, в хранилище и для секретов

Подходы к encryption at rest не заменяют друг друга: они закрывают разные классы риска, и выбор зависит от того, кому доверяем ключ и что защищаем — носитель, отдельный объект или секрет.

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

На практике схемы комбинируют: том и снапшоты шифруются на нижнем уровне, объекты — в хранилище, а доступы ко всему остальному живут в отдельном контуре с ротацией и аудитом.

Этапы внедрения: от инвентаризации данных до передачи

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

1. Инвентаризация данных. Собираем перечень томов, баз, объектных хранилищ, копий и выгрузок — включая те, что лежат на машинах инженеров. Без этого списка любая схема закрывает половину контура.
2. Классификация данных. Размечаем массивы по чувствительности: где нужен полный том, где достаточно шифрования объектов, а где данные не должны храниться вовсе. Класс задаёт и способ защиты, и режим доступа.
3. Схема ключей. Строим иерархию: корневой ключ в хранилище секретов, ключи шифрования данных — отдельно на контур и сервис, с раздельными правами. Ротация ключей закладывается сразу, вместе с расписанием и порядком вывода из эксплуатации.
4. Настройка шифрования. Включаем LUKS на блочных томах, серверное шифрование в объектном хранилище, шифрование в СУБД и в резервных копиях. Проверяем, что ключи не утекают в образы, конфиги и логи.
5. Проверка восстановления. Расшифровываем копию на чистом стенде строго по инструкции, а не по памяти инженера. Если восстановление не воспроизводится с первого раза по документу — регламент не готов.
6. Аудит и регламент доступа. Включаем журналирование операций с ключами, смотрим, у кого есть право на расшифровку, и сокращаем круг до действительно необходимого.
7. Передача и обучение. Отдаём схему, инструкции по ротации и восстановлению, разбираем их с дежурной сменой заказчика.

Итог работы — не отчёт, а способность вашей команды провести ротацию и поднять данные из копии без нас.

Артефакты передачи: конфигурации, схемы ключей, регламенты

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

• Рабочие конфигурации — профили LUKS для дисков и разделов, параметры серверного шифрования бакетов и баз, привязка к хранилищу ключей.
• Схема иерархии ключей — корневой ключ, ключи шифрования данных и ключи обёртки: что кого защищает, где лежит, как ротируется каждый уровень.
• Политики доступа к данным — каким ролям и сервисным учётным записям разрешена расшифровка, при каких условиях, как ведётся журнал обращений к ключам.
• Порядок ротации и отзыва — расписание плановой ротации, критерии внеплановой (утечка, уход сотрудника), поведение сервисов при отозванном ключе.
• Инструкция по восстановлению — шаги: доступ к хранилищу ключей, монтирование тома, подъём из резервной копии, проверка целостности; отдельный сценарий потери одного хранилища.
• Матрица ответственности — кто владеет ключами, кто выдаёт доступ, кто утверждает ротацию, к кому идёт эскалация при инциденте.
• Документация по шифрованию — карта данных с перечнем закрытых контуров, обоснование выбранной схемы и честные границы: что шифрование не покрывает.

Документы лежат рядом с конфигурациями в том же репозитории: при изменении инфраструктуры устаревшая инструкция ломает проверку на этапе сборки, а не всплывает в момент инцидента.

Кейс: переход на шифрование без остановки сервиса

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

Что нашли до старта

Инвентаризация дала неприятную картину: 34% томов не были закрыты шифрованием, а учёт вёлся в таблице, которая расходилась с реальностью на восемь машин. Ротация ключей занимала 14 ручных операций и растягивалась на дни, проверка резервных копий — около девяти часов выборочно, без подтверждённого восстановления. Узкое место оказалось в одном сегменте: тома там можно было перешифровать только с остановкой, поэтому их откладывали, и именно они копились дольше всего.

Что изменили

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

Итог по метрикам: доля неохваченных томов — 34% → 0, ротация ключей — 14 ручных шагов → один запуск, проверка резервных копий — девять часов выборочно → сорок минут по всем копиям. Простой за время миграции — ноль, отказов при перешифровке — ноль.

Чем шифрование на диске отличается от шифрования в хранилище?

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

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

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

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

Вопросы, которые задают инженеры перед стартом

Перед стартом шифрования в покое инженеры задают примерно один и тот же набор вопросов — про скорость, ключи и совместимость с уже работающими системами. Ниже короткие ответы без обтекаемых формулировок; детали под конкретную инфраструктуру разбираем на этапе проектирования.

Что будет, если потеряется ключ?

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

Можно ли включить шифрование на работающей системе?

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