VPN шифрує подорож, а не копію на диску чи в хмарі

Простежте один файл від ноутбука до колеги: він є на диску, проходить через тунель, потрапляє в хмарне сховище й копіюється в резервну копію. Лише одна з цих ділянок охоплена VPN, і це найкоротше живуча. Інші копії продовжують існувати після закриття тунелю — під тим шифруванням сховища, яке їхні власники справді налаштували. Знання того, яка копія чим захищена, не дозволяє сплутати робочий тунель із політикою захисту даних.

Простежте один файл через три копії

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

Намалюйте цей шлях, перш ніж щось вибирати. Малюнок зазвичай показує, що копія, про яку найбільше хвилюються, та, що в дорозі, існує найменше секунд. Він також показує, на якому переході немає відповідального в кімнаті, і зазвичай це той, якому потрібна увага.

Робота тунелю закінчується на його власній кінцевій точці

Звичайний VPN шифрує ділянку між двома своїми кінцевими точками. За дальньою кінцевою точкою трафік знову стає звичайним IP, якщо його не захищає щось інше; тому сеанс браузера може залишатися зашифрованим від початку до кінця, поки тунель охоплює лише перший відрізок.

Ніщо на цій ділянці не говорить про те, як служба-отримувач зберігає завантаження, що вона пише у свої журнали та які метадані облікового запису зберігає. Це властивості системи-отримувача, і вони залишаються чинними незалежно від того, чи запит прийшов через тунель. Оператор, який рекламує зашифроване передання, описав подорож, а не склад.

Ваш диск і ваше сховище ключів — окремі рішення

Шифрування всього диска захищає том, коли машина вимкнена, і залежить від ключа, який пристрій або користувач надає під час завантаження. Сховище менеджера паролів шифрує власний вміст ключем, похідним від головного секрету. Увімкнення VPN не робить ні того, ні іншого й не зашифрує експорт у відкритому вигляді, який уже лежить у папці завантажень.

На експортах це стає конкретним. Експорт сховища, зроблений для міграції, — це файл у відкритому вигляді з усіма секретами, і він переживає тунель, сеанс і перезавантаження, якщо хтось його не видалить.

file export-notes.json
head -c 80 export-notes.json
sha256sum export-notes.json

Якщо цей вивід — читабельний текст, файл не захищений. Видаліть його, щойно міграція завершиться, і пам’ятайте, що безпечне стирання на сучасних носіях залежить від пристрою й не є однією переносною командою.

Що насправді охоплює шифрування на боці хмари

Серверне шифрування захищає збережений об’єкт від того, хто отримає базовий носій, а постачальник і далі тримає ключі, здатні його прочитати. Клієнтське шифрування, за якого файл шифрується перед вивантаженням, тримає відкритий текст поза досяжністю постачальника, але переносить зберігання ключів і відновлення на вас.

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

Копії розмножуються тихо. Спільне посилання, клієнт синхронізації, локальний кеш і завдання резервного копіювання створюють кожен ще один об’єкт за політикою, яку ви, можливо, не обирали. Перелічіть їх для даних, які важливі, бо найсильніше шифрування на шляху не має значення, якщо копія у відкритому вигляді лежить у спільній папці.

Доказ — це відновлення, а не швидкість вивантаження

Корисний доказ схеми зберігання полягає в тому, що потрібні люди можуть відновити дані, а непотрібні — ні. Пропускна здатність вивантаження вимірює зовсім інше й лестить будь-якій схемі, яку ніколи не відновлювали. Виберіть по одному файлу з кожної копії, на яку ви покладаєтеся, і доведіть, що він повертається.

Відновіть по одному файлу з кожної копії, на яку ви покладаєтеся, використовуючи матеріал для відновлення, а не сеанс, який її створив. Ключ, що зберігається лише в машині, яка відмовила, — не план відновлення, а резервна копія, для відновлення якої потрібен втрачений сейф, — це інший різновид єдиної точки відмови.

Настанови NIST з керування ключами охоплюють питання життєвого циклу, які переживають будь-яке окреме продуктове рішення. Зберігайте відповіді разом із даними, які вони захищають, і переглядайте їх, коли змінюється копія, отримувач або постачальник сховища.