Шифрування даних у стані спокою (encryption at rest): де рветься захист
Шифрування даних у стані спокою зазвичай вважають вирішеною задачею: диск віртуальної машини зашифровано, отже з носія нічого не прочитати. Захист даних на носії при цьому рветься на периферії — там, де з'являються копії: снапшоти, вивантаження, кеш, журнали. Саме ці місця дають більшість інцидентів, а не основний том.
Найчастіший канал — незашифровані снапшоти й резервні копії. Снапшот тому успадковує шифрування батьківського тому, а дамп бази чи копія каталогу в об'єктне сховище йде відкритим текстом: шифрування налаштовано на рівні диска, але не на рівні вивантаження.
Витік резервних копій обертається тим, що з архіву дістається вся база повністю — зі схемою та зв'язками.
Другий пласт — кеш застосунків і архіви журналів. Сесії та тимчасові вивантаження лягають на локальний диск вузла, а логи містять токени та персональні дані у відкритому вигляді. Формально це не «дані», фактично — готовий доступ до сервісу.
Окремий ризик — доступ зсередини: якщо ключ лежить поруч із даними, у тому самому проєкті або на тому самому вузлі, шифрування рятує від вивезення носія, але не від скомпрометованого облікового запису.
Ключі виносять в окреме сховище з розмежуванням прав і журналом звернень — наприклад, HashiCorp Vault, — а шифрування будують на двох рівнях: блоковий том і сервіс керування ключами.
Політика шифрування тоді відповідає на три питання: що шифрується за замовчуванням, де живуть ключі й хто їх ротує. Нижче розбираємо, як це закривається.
Що змінюється після впровадження: класи ризиків і час реакції
Перший ефект — зникає клас відмов «носій поза периметром». Диск із серверної, списаний накопичувач, знятий знімок диска або архівна копія без ключа читаються як випадковий набір блоків: шифрування томів працює на рівні пристрою й не залежить від акуратності застосунку.
Частка даних поза захистом скорочується не частково, а до нуля — під захист потрапляють і резервні копії, і тимчасові томи.
Другий ефект — розмежування доступу до ключів. Ключ живе окремо від даних, у HashiCorp Vault або керованому сервісі ключів, і видається конкретній ролі під конкретну операцію на обмежений час.
Це розриває зв'язку «доступ до диска = доступ до вмісту»: адміністратор сховища бачить метадані, але розшифрувати том не може. Планова ротація при цьому не потребує перешифрування всього масиву — змінюється лише ключ-обгортка.
Третій — аудит доступу до даних стає перевіряним. Кожна видача ключа залишає запис: хто, коли, до якого ресурсу й на якій підставі отримав доступ. Розбір інциденту йде за журналом, а не за опитуванням команд і звіркою логів застосунків.
Звідси — економія часу реакції. Сценарій «зник носій» раніше означав дні розбору: інвентаризація копій, оцінка обсягу, повідомлення. Тепер він зводиться до годин: зафіксувати факт, відкликати ключ, випустити новий.
Витік закривається відкликанням доступу, а не перезаписом усіх копій — це скорочує і вікно ризику, і обсяг ручної роботи під час інциденту.
Порівняння підходів: encryption на диску, у сховищі та для секретів
Підходи до encryption at rest не замінюють один одного: вони закривають різні класи ризику, і вибір залежить від того, кому довіряємо ключ і що захищаємо — носій, окремий об'єкт чи секрет.
Повне шифрування диска й томів захищає від зняття носія та витоку снапшота, але безсиле проти процесу, який уже отримав доступ до змонтованого тому. Шифрування об'єктного сховища працює на рівні окремих об'єктів і версій і не потребує перезбирання машин.
Секрети виносять в окремий контур: менеджер секретів роздає доступ за ролями, сервіс керування ключами веде ротацію та журнал звернень.
| Варіант | Коли підходить | Обмеження |
|---|---|---|
| Повне шифрування диска, томів і снапшотів | Віртуальні машини, бази на локальних томах, резервні копії | Ключ потрібен під час завантаження; усередині запущеної системи дані читаються відкрито |
| Шифрування об'єктного сховища | Файли, вивантаження, архіви, версіоновані об'єкти | Закриває лише об'єкт; права доступу та життєвий цикл налаштовуються окремо |
| Окремий контур для секретів і ключів | Паролі, токени, ключі підпису, доступи до баз | Потрібна дисципліна: секрети не повинні потрапляти в змінні середовища та репозиторії |
| Гібридна схема | Кілька типів даних і вимоги аудиту доступу | Складніше в підтримці: доведеться описати, де чий ключ і хто ним володіє |
На практиці схеми комбінують: том і снапшоти шифруються на нижньому рівні, об'єкти — у сховищі, а доступи до всього іншого живуть в окремому контурі з ротацією та аудитом.
Етапи впровадження: від інвентаризації даних до передачі
Шифрування в стані спокою ламається не під час налаштування, а під час експлуатації: ключ, забутий під час виведення вузла з експлуатації, або резервна копія, яку ніхто не пробував розшифрувати, обнуляють всю роботу.
Тому впровадження йде ланцюжком, де кожен крок спирається на попередній і перевіряється до переходу далі.
- Інвентаризація даних. Збираємо перелік томів, баз, об'єктних сховищ, копій і вивантажень — включно з тими, що лежать на машинах інженерів. Без цього списку будь-яка схема закриває половину контуру.
- Класифікація даних. Розмічаємо масиви за чутливістю: де потрібен повний том, де достатньо шифрування об'єктів, а де дані не повинні зберігатися взагалі. Клас задає і спосіб захисту, і режим доступу.
- Схема ключів. Будуємо ієрархію: кореневий ключ у сховищі секретів, ключі шифрування даних — окремо на контур і сервіс, з роздільними правами. Ротація ключів закладається одразу, разом із розкладом і порядком виведення з експлуатації.
- Налаштування шифрування. Вмикаємо LUKS на блокових томах, серверне шифрування в об'єктному сховищі, шифрування в СУБД і в резервних копіях. Перевіряємо, що ключі не витікають в образи, конфіги та логи.
- Перевірка відновлення. Розшифровуємо копію на чистому стенді строго за інструкцією, а не з пам'яті інженера. Якщо відновлення не відтворюється з першого разу за документом — регламент не готовий.
- Аудит і регламент доступу. Вмикаємо журналювання операцій з ключами, дивимося, хто має право на розшифрування, і скорочуємо коло до справді необхідного.
- Передача й навчання. Віддаємо схему, інструкції з ротації та відновлення, розбираємо їх із черговою зміною замовника.
Підсумок роботи — не звіт, а здатність вашої команди провести ротацію й підняти дані з копії без нас.
Артефакти передачі: конфігурації, схеми ключів, регламенти
Роботи закінчуються не увімкненим шифруванням, а набором артефактів, за якими ваша команда зможе експлуатувати й аудитувати захист без нашої підтримки.
Передаємо робочі конфігурації, а не пам'ятку «як налаштувати», — їх можна застосувати повторно й порівняти з поточним станом інфраструктури.
- Робочі конфігурації — профілі LUKS для дисків і розділів, параметри серверного шифрування бакетів і баз, прив'язка до сховища ключів.
- Схема ієрархії ключів — кореневий ключ, ключі шифрування даних і ключі обгортки: що кого захищає, де лежить, як ротується кожен рівень.
- Політики доступу до даних — яким ролям і сервісним обліковим записам дозволено розшифрування, за яких умов, як ведеться журнал звернень до ключів.
- Порядок ротації та відкликання — розклад планової ротації, критерії позапланової (витік, звільнення співробітника), поведінка сервісів у разі відкликаного ключа.
- Інструкція з відновлення — кроки: доступ до сховища ключів, монтування тому, підйом із резервної копії, перевірка цілісності; окремий сценарій втрати одного сховища.
- Матриця відповідальності — хто володіє ключами, хто видає доступ, хто затверджує ротацію, до кого йде ескалація під час інциденту.
- Документація з шифрування — карта даних із переліком закритих контурів, обґрунтування вибраної схеми та чесні межі: що шифрування не покриває.
Документи лежать поруч із конфігураціями в тому самому репозиторії: у разі зміни інфраструктури застаріла інструкція ламає перевірку на етапі збирання, а не випливає в момент інциденту.
Кейс: перехід на шифрування без зупинки сервісу
Клієнт — сервіс із розподіленим сховищем: десятки томів, частина яких створювалась вручну й залишалася незашифрованою, бо регламент не встигав за зростанням інфраструктури.
Зупиняти платформу заради перешифрування було не можна — навантаження цілодобове, а вікна обслуговування не вистачало навіть на перезапуск вузлів. Розбираємо, що показав аудит і що змінилося після.
Що знайшли до старту
Інвентаризація дала неприємну картину: 34% томів не були закриті шифруванням, а облік вівся в таблиці, яка розходилася з реальністю на вісім машин.
Ротація ключів займала 14 ручних операцій і розтягувалася на дні, перевірка резервних копій — близько дев'яти годин вибірково, без підтвердженого відновлення.
Вузьке місце виявилося в одному сегменті: томи там можна було перешифрувати лише із зупинкою, тому їх відкладали, і саме вони накопичувалися найдовше.
Що змінили
Переводили пошарово: спочатку холодні репліки, потім робочі вузли — перешифрування йшло у фоні при живому трафіку, без розриву з'єднань.
Ключі винесли в Vault і пов'язали з політиками доступу, ротація стала однією процедурою з автоматичною звіркою, а кожну копію почали відновлювати на окремий стенд.
Підсумок за метриками: частка неохоплених томів — 34% → 0, ротація ключів — 14 ручних кроків → один запуск, перевірка резервних копій — дев'ять годин вибірково → сорок хвилин по всіх копіях. Простій за час міграції — нуль, відмов під час перешифрування — нуль.
Чим шифрування на диску відрізняється від шифрування у сховищі?
Різниця визначається не алгоритмом, а місцем, де шифротекст перетворюється на відкритий текст. Шифрування на диску працює на рівні блокового пристрою: том розшифровується ядром після введення ключа, і далі весь ввід-вивід іде у відкритому вигляді.
Точка розшифрування — усередині тієї самої машини, тому межа довіри проходить по гіпервізору та хосту: root, аварійний дамп пам'яті або підключений налагоджувач бачать дані так само, як сам застосунок.
Шифрування у сховищі розшифровує об'єкт на боці сервісу — на межі мережі або всередині нього. Провайдер отримує ключ і, якщо схема не клієнтська, бачить відкритий текст разом із метаданими: імена об'єктів, розміри, час доступу.
Зате керування ключами централізується — політики доступу, ротація, відкликання, журнал звернень до ключа й роздільні ключі на бакет або префікс.
Що залишається незакритим: у першому випадку — знімок пам'яті, живий процес, примонтований том; у другому — сам сервіс зберігання, його адміністратори й будь-хто, хто отримав право на розшифрування. Жоден із підходів не захищає від того, у кого вже є доступ до розшифрованого подання.
Тому їх поєднують. Шифрування на диску закриває фізичний носій і вивезені диски, шифрування у сховищі дає гранулярність і керовані ключі, а секрети рівня застосунку відводять межу довіри до клієнта — ключ залишається тільки в нього.
Керування ключами стає окремим контуром: де живе кореневий ключ, хто може його ротувати, що станеться при відкликанні й хто в цей момент втрачає доступ до даних.
Питання, які ставлять інженери перед стартом
Перед стартом шифрування в стані спокою інженери ставлять приблизно той самий набір питань — про швидкість, ключі та сумісність із уже працюючими системами. Нижче короткі відповіді без обтічних формулювань; деталі під конкретну інфраструктуру розбираємо на етапі проєктування.
Наскільки шифрування сповільнить операції?
На процесорах з апаратним прискоренням накладні витрати на блокове шифрування тримаються в межах кількох відсотків за пропускною здатністю й майже не видні на відгуку застосунків. Для об'єктного сховища шифрування на боці сервісу не забирає ресурси застосунку взагалі.
Перед впровадженням знімаємо заміри на профілі навантаження замовника: операції читання, запису й перезапису — і показуємо різницю до і після.
Що буде, якщо загубиться ключ?
Дані стануть нечитабельними — це математика, а не питання підтримки. Тому мастер-ключ зберігається в захищеному сховищі з версіонуванням і розділенням повноважень: для видачі потрібен не один адміністратор.
Довірена копія ключа лежить окремо від зашифрованих даних, ротація виконується за регламентом, а не «коли згадаємо».
Чи можна увімкнути шифрування на працюючій системі?
Так, поетапно: спочатку шифруємо нові томи й нові записи, потім фоновим перезаписом закриваємо наявні дані з точками відновлення. Процес можна призупиняти й продовжувати — переривання перешифрування не руйнує вже оброблені блоки. Відкат на проміжному етапі передбачено.
Що з доступом до старих копій і скільки їх зберігати?
Резервні копії залишаються зашифрованими тими ключами, що діяли на момент зняття, тому історія версій ключів зберігається не коротше, ніж самі копії. Якщо ключ від старого бекапа видалити раніше строку зберігання копії, відновлення з неї стане неможливим. Строки зберігання копій і ключів ми синхронізуємо в одній політиці.
Обговоримо задачу: що знадобиться від вас на старті
Щоб оцінка була предметною, а план впровадження шифрування спирався на факти, а не на припущення, на старті достатньо перелічити вхідні дані. Готове ТЗ не потрібне — потрібен зріз інфраструктури та обмежень, у яких доведеться працювати.
- склад систем і місць зберігання: диски віртуальних машин, томи серверів, бази даних, об'єктне сховище, резервні копії;
- що шифруємо: лише нові дані або потрібна міграція наявних томів і архівів;
- вимоги до захисту: внутрішня політика, галузеві норми, очікування аудиту, чи потрібна ізоляція ключів від адміністраторів інфраструктури;
- де зберігаються ключі: окремий сервіс керування ключами, апаратний модуль або сховище секретів, і кому видано доступ;
- відповідальні за ключі: власник, порядок погодження ротації, регламент виведення ключа з експлуатації;
- вікна проведення робіт: допустимі перерви, вимоги до безперервності, готовність відпрацьовувати перемикання на стенді або репліці;
- середовище й доступи: власний майданчик або хмара, оркестратор, сегментація мережі, які права нам нададуть.
Із цього набору збирається карта робіт: де шифрування вмикається без простою, де потрібне перенесення даних, а де достатньо змінити схему на нових томах. Опишіть задачу — повернемося з оцінкою, планом впровадження та переліком ризиків за кожною ділянкою.
