Шифрування 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 в ядрі»
• «Гарантії доставки вебхуків»