Дані в хмарі: шифрування, власники ключів і посилання для спільного доступу

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

Шифрування в стані спокою та під час передавання — за замовчуванням

Документація Google Cloud описує те, що за замовчуванням роблять більшість великих провайдерів: «Усі дані, що зберігаються Google, шифруються на рівні сховища за допомогою алгоритму Advanced Encryption Standard (AES), AES-256», застосовуваного автоматично, без потреби в налаштуванні з боку клієнта. Дані під час передавання між вашим пристроєм і провайдером окремо захищені протоколом TLS, розглянутим у курсі з криптографії цього університету. Ця базова лінія справді корисна — вона захищає, наприклад, від фізичної крадіжки жорсткого диска з дата-центру, — але відповідає лише на частину питання.

Хто тримає ключ, змінює те, для чого потрібен захист

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

Наскрізно зашифровані варіанти: лише клієнт тримає ключ

Менша кількість споживчих функцій йде далі, ніж керуване провайдером шифрування в стані спокою, поширюючи справжнє наскрізне шифрування (гарантію, розглянуту в курсі з криптографії) на саме хмарне сховище. Розширений захист даних Apple для iCloud — задокументований приклад: коли він увімкнений, наскрізне шифрування поширюється на резервні копії iCloud, Фото, Нотатки, iCloud Drive та інше, і Apple заявляє, що «ваші довірені пристрої зберігають єдиний доступ до ключів шифрування для більшості ваших даних iCloud» — тобто сама Apple не може їх розшифрувати, навіть за юридичним примусом, і прямо про це заявляє: «Ніхто інший не може отримати доступ до ваших наскрізно зашифрованих даних — навіть Apple». Компроміс, який Apple документує поряд із цим, реальний: оскільки Apple не тримає ключа, вона також не може допомогти відновити ці дані, якщо ви втратите доступ і заздалегідь не налаштували контакт для відновлення чи ключ відновлення. Надійний захист і легке відновлення облікового запису тягнуть у протилежні боки, і Розширений захист даних просить вас обрати.

Посилання для спільного доступу: тихий спосіб, яким дані покидають описану вище модель

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