Шифрование At Rest

Шифрование At Rest

1) Зачем это нужно и что именно мы защищаем

Определение. Шифрование at rest — это защита данных, записанных на носитель (диски, снапшоты, бэкапы, объекты, логи, дампы памяти), с тем чтобы несанкционированный доступ к физическому носителю или к «сырому» хранилищу не раскрывал содержание.

• Блок-/файловые тома, объектные хранилища, базы данных, очереди/кейвэлью, кэш-дампы, логи/трейсы, резервные копии, экспорт/импорт, снимки ВМ/контейнеров, дампы ядра/процессов, подкачка/swap.
• Многоарендные сценарии: изоляция между клиентами/проектами/окружениями.

Чего не покрываем полностью: кража сеансов в памяти, атаки на живой процесс, уязвимости приложения, компрометация учетных данных. Для этого требуются шифрование «в полете», строгая аутентификация/авторизация, минимизация прав и мониторинг (см. связанные статьи: «Аутентификация и авторизация», «Подпись и верификация запросов»).

2) Модель угроз и цели контроля

• Потеря/кража носителя (диск, лента, USB, устройство разработчика).
• Несанкционированный доступ к бэкапам/снапшотам/логам.
• Злоупотребление привилегиями на уровне платформы/гипервизора/сторадж-нод.
• Пересечение арендаторов при ошибках конфигурации.
• «Замусоренные» временные файлы и дампы, попадающие в артефакты и образы.

1. Конфиденциальность данных на носителе.

2. Криптографическая изоляция арендаторов/окружений.

3. Управляемость ключей (создание, хранение, ротация, отозвание).

4. Аудитируемость (кто и когда использовал ключ).

5. Минимизация эксплуатационных рисков при инцидентах.

3) Базовые принципы архитектуры

Шифруем все по умолчанию. Opt-out запрещен без исключений на уровне риска.
Иерархия ключей (envelope encryption). Root/KEK → DEK (data encryption keys) → объекты/файлы/страницы БД.
KMS/HSM как источник доверия. Генерация и хранение KEK в KMS/HSM, операции обертывания/развертывания ключей выполняются там же.
Per-tenant / per-dataset ключи. Гранулярность под требования изоляции и ротации.
Разделение обязанностей. Команды платформы ≠ владельцы ключей арендатора; минимум привилегий (PoLP).
Crypto-agility. Возможность безопасно мигрировать алгоритмы/длины ключей.
Ротация как процесс, а не событие. Ключи и данные должны поддерживать «скользящую» замену.

4) Алгоритмы и режимы шифрования

Для объектов/файлов/записей: AES-256-GCM или AES-256-SIV (AEAD с аутентификацией).
Для блочных устройств/томов: AES-XTS-256/512 (защита от перестановок блоков; не AEAD — использовать поверх файловых форматов с MAC там, где важно целостность).

• TDE (Transparent Data Encryption) движка: Oracle TDE, SQL Server TDE, MySQL/InnoDB TDE и пр.
• Полевая/строчная криптография (FPE/детерминированное шифрование) — для возможностей поиска/джойнов на зашифрованных полях; применять осмотрительно.
• Генерация и хранение ключей: KEK — в KMS/HSM; DEK — в памяти приложений краткоживущие, при хранении — только в обернутом виде.

5) Иерархия ключей и KMS/HSM

1. Root key (статутный, в HSM/KMS). Не покидает периметр HSM/KMS.

2. KEK (Key Encryption Key). На проект/окружение/арендатора. Управляет жизненным циклом DEK.

3. DEK (Data Encryption Key). На объект/файл/таблицу/сегмент. Короткоживущий, ротация без остановки.

• Все операции обертывания/развертывания — через KMS API с аудитом.
• Политики: кто может «использовать» ключ ≠ кто может «управлять» ключом.
• Геораспределение ключей: pin-to-region + dual-control для межрегиона.
• Возможна «двухчековая» модель (двух операторов) для операций высокого риска.
• Для изоляции сильного уровня — отдельные key-rings на арендатора.

6) Ротация, отзыв и комплаенс

Ротация DEK: прозрачно и постоянно (rolling re-encryption на уровне объектов/страниц).
Ротация KEK: периодическая (например, раз в 6–12 месяцев) + немедленный отзыв при подозрении на компрометацию.
Отзыв доступа: через KMS-политики; блокировка unwrap операций = мгновенная «крипто-уничтожаемость» данных.
Журналы аудита: кто, когда, с какими правами использовал ключи; хранить отдельно и тоже шифровать.
Нормативы и стандарты: ориентируемся на требования отрасли (например, GDPR/PCI-допуски/локальные регуляторы), используем сертифицированные криптомодули (например, соответствие уровням сертификации).

7) Паттерны по видам хранилищ

7.1 Блочные/файловые тома и ВМ/контейнеры

Полнодисковое шифрование (XTS) + управление ключами через KMS (инициализация тома при монтировании).
Защитить swap, crash-дампы, tmp-директории, контейнерные overlay-слои, образы/AMI.
Снимки/снапшоты — всегда в зашифрованном виде с отдельными DEK.

7.2 Объектное хранилище

Envelope encryption: уникальный DEK на объект; заголовки/метаданные — без утечек PII.
Контроль доступа к KMS ключу по арендаторам и окружениям.
Сервер-сайд шифрование (SSE с собственным KMS) или клиент-сайд (CSE) — выбирать по доверительной модели.

7.3 Базы данных

Включить TDE там, где доступно; ключи БД привязать к KMS через плагин/экстеншн.
Для особо чувствительных полей — прикладное шифрование (AEAD) до попадания в БД.
Журналы редо/транзакционные логи, архивные логи, дампы — шифровать отдельно, ключи — отдельные.

7.4 Логи/трейсы/метрики

Формат логов — без чувствительных данных по умолчанию (санитайзинг).
Архивы логов — отдельные ключи и короткие TTL хранения.
Доступ к чтению логов — через прокси-сервис с A&A и аудитом.

7.5 Резервные копии и офлайн-носители

Всегда шифровать на стороне клиента до записи на ленту/облако.
Хранить ключи отдельно (out-of-band), escrow с раздельным контролем.
Для чрезвычайных случаев — разделение секрета (например, m-of-n) для восстановления master-доступа.

8) Многоарендность (multi-tenant)

Ключ на арендатора: KEK-per-tenant + DEK-per-dataset.
Изоляция политиками: пространства имен KMS, IAM-границы, отдельные IDP-роли.
Удаление по запросу клиента: «крипто-стереть» — отозвать KEK арендатора и уничтожить DEK.
Отчетность для клиента: артефакты соответствия, логи доступа к ключам, подтверждение ротации.

9) Производительность и эксплуатация

Аппаратные ускорения (AES-NI/x86, ARMv8 Crypto Extensions).
Профилирование горячих путей: шифруем на границах I/O, избегаем двойного шифрования без нужды.
Пулы сеансов KMS, кэширование обернутых DEK в памяти (с TTL и защитой от дампов).
SLO/метрики: латентность unwrap, доля «перешифрованных» объектов, ошибки KMS, скорость бэкап-шифрования.

10) Процесс внедрения (reference runbook)

Шаг 0 — инвентаризация данных. Каталогировать все хранилища и пути утечки (tmp, дампы, экспорт, analytics-бакеты).
Шаг 1 — дизайн ключевой иерархии. Определяем уровни KEK/DEK, гранулярность, регионы, роли.
Шаг 2 — выбор режимов/библиотек. Одобренные алгоритмы, криптобиблиотеки, политики версий.
Шаг 3 — интеграция с KMS/HSM. Генерация/обертка/аудит, политики IAM, гео-пиннинг.
Шаг 4 — шифрование на запись. Включить по умолчанию, миграция существующих данных через бэкграунд-реэнкрипт.
Шаг 5 — ротация и аварийные сценарии. Регламенты, тесты «key compromise», «KMS недоступен».
Шаг 6 — мониторинг и аудит. Дашборды, алерты, регулярные отчеты соответствия.
Шаг 7 — обучение и «secure coding». Гайды для инженеров, запрет вывода секретов в логи/дампы.

11) Тестирование и верификация

Крипто-юнит-тесты: корректность AEAD (проверка тегов), валидация отказа при изменении байта.
Failure-tests: отключение KMS, устаревшие версии ключей, принудительный отзыв KEK.
Red/Blue-тесты: попытки прочитать «сырой» диск/снапшот/бэкап.
Проверка совместимости: миграция алгоритмов/длин ключей (crypto-agility).
Аттестация библиотек: использовать только проверенные криптомодули; фиксировать версии.

12) Частые ошибки и как их избежать

Двойное шифрование без смысла. Лишняя латентность и сложность. Держите слой, который дает нужную гранулярность и изоляцию.
Хранение ключей рядом с данными. Ключи — всегда отдельно, под другой моделью доступа.
Забытые артефакты. Незашифрованные временные файлы, экспорт CSV, дампы поддержки. Включите контроль в CI/CD и Data Loss Prevention.
Отсутствие ротации. Сделайте ротацию частью pipeline/cron, а не ручной процедурой.
Логи с чувствительными данными. Вводите контракт на формат логов и автоматические санитайзеры.

13) Мини-рецепты (псевдокод)

1) Request unwrap DEK from KMS by tenant KEK id dek = kms. unwrap(kek_id, wrapped_dek)

2) Generate fresh nonce/iv, encrypt payload (AEAD)
ciphertext, tag = aead_encrypt(dek, iv=random(), aad=metadata, plaintext=data)

3) Delete DEK from memory (zeroize), save {ciphertext, iv, tag, wrapped_dek}

For each object:
new_wrapped_dek = kms. rewrap(old_wrapped_dek, old_kek_id -> new_kek_id)
store(new_wrapped_dek)
We do not touch the data: we turn over only DEK

kms. disable_key (tenant_kek_id) # Deny unwrap kms. schedule_destroy (tenant_kek_id, hold_period_days=7) # Optional hold

14) Чек-листы

• Включено шифрование по умолчанию на всех типах хранилищ.
• Иерархия ключей описана и реализована; роли и IAM-политики настроены.
• KMS/HSM интегрирован, аудит ключевых операций включен.
• Ротация DEK/KEK автоматизирована; сценарии компрометации отработаны.
• Бэкапы, снапшоты, логи и дампы — зашифрованы; ключи хранятся отдельно.
• Настроены алерты на ошибки KMS, отклонения AEAD-тегов, долю незашифрованных артефактов.
• Пройдены тесты на недоступность KMS и отзыв ключей.

• Ежемесячный отчет об использовании ключей и попытках доступа.
• План crypto-agility и окно для безболезненной миграции алгоритмов.
• Периодический Red-team на извлечение данных с «сырых» носителей.

15) Вопросы и ответы (FAQ)

В: Достаточно ли полнодискового шифрования?
О: Для физических рисков — да, но для изоляции арендаторов и гибкой ротации лучше envelope с DEK-на-объект/набор.

В: Что делать при компрометации KEK?
О: Немедленно отозвать KEK в KMS, перевыпустить новый, выполнить rewrap всех DEK, проверить журналы и провести RCA.

В: Как шифровать поля, по которым ищем?
О: Использовать детерминированные схемы или FPE только при строгой оценке рисков (леки паттернов). Лучше проектировать запросы так, чтобы чувствительные поля не требовали индексируемого открытого вида.

В: Нужна ли отдельная команда для ключей?
О: Рекомендуется «Crypto/KMS-оператор» как роль с отдельными правами и процедурами.

• «Управление ключами и ротация»
• «S2S-аутентификация»
• «Подпись и верификация запросов»
• «OAuth2/OpenID Connect в ядре»
• «Гарантии доставки вебхуков»