Розрив між заявою та архітектурою
Кожен хмарний постачальник, що обробляє конфіденційні дані, робить певну версію однієї і тієї ж заяви: «Ми шифруємо ваші дані». Ця заява майже завжди правдива — і майже завжди недостатня.
Злом LastPass 2022 року є показовим прикладом. LastPass шифрував сховища паролів своїх користувачів. Вони використовували шифрування. Заява була точною. І все ж 25 млн користувачів мали свої зашифровані сховища викрадені, а $438 млн було вкрадено у користувачів LastPass у подальших злочинах із криптовалютою протягом 2025 року, відповідно до дослідження Coinbase Institutional.
Управління комісара з інформації Великобританії оштрафувало британське відділення LastPass на £1,2 млн у грудні 2025 року за «невпровадження належних технічних і організаційних заходів безпеки». Шифрування існувало. Заходи безпеки не відповідали необхідному стандарту.
Для підприємств, що оцінюють хмарні інструменти захисту конфіденційності — включаючи платформи анонімізації PII — прецедент LastPass змінює питання при закупівлі. Питання полягає не в тому, «чи шифрують вони наші дані?». Питання в тому, «чи можуть вони розшифрувати наші дані?»
Чотири питання нульового знання, що насправді важливі
При оцінці ZK-заяви постачальника чотири питання визначають, чи є архітектура справжньою:
1. Де відбувається деривація ключа?
У справжній ZK-архітектурі деривація ключа шифрування відбувається на стороні клієнта — у браузері або настільному додатку — до передачі будь-яких даних. Похідний ключ використовується для локального шифрування даних. Тільки зашифрований шифртекст передається на сервери постачальника.
Якщо постачальник виводить ключі шифрування на своїх серверах — ключі у нього. Якщо ключі у нього — він може розшифрувати. Заява технічно точна («ми шифруємо»), але вводить в оману щодо її наслідків.
2. Чи постачальник будь-коли має доступ до відкритого тексту?
Деякі інструменти шифрують дані у стані спокою, але розшифровують їх для обробки — запуску ШІ-моделей, аналітики, індексування для пошуку або формування журналів аудиту. Протягом вікна обробки відкритий текст доступний на інфраструктурі постачальника. Злом протягом цього вікна розкриває дані у незашифрованому вигляді.
3. Що відбувається у разі судового процесу?
Якщо державний орган видає повістку постачальнику, які дані він може надати? Постачальник із серверними ключами може бути зобов'язаний надати розшифрований вміст. Постачальник із ZK-архітектурою може надати лише зашифрований шифртекст — навіть під юридичним примусом у нього немає нічого корисного для надання.
4. Що розкриває повна компрометація сервера?
У справжній ZK-реалізації повний злом інфраструктури постачальника дає лише зашифровані блоки. Зловмисник отримує шифртекст без ключів для його розшифрування. У реалізації з ключами під контролем постачальника злом сервера розкриває ключі разом із даними.
Невдача реалізації LastPass
Злом LastPass виявив конкретний недолік реалізації: старіші облікові записи використовували PBKDF2 із лише 1 ітерацією для деривації ключа замість рекомендованих 600 000 ітерацій. Слабша деривація ключа зробила атаки методом повного перебору на викрадені сховища обчислювально здійсненними.
Це ілюструє, чому оцінка ZK-заяв вимагає вивчення деталей реалізації, а не лише архітектурних описів. Постачальник може використовувати ZK-дизайн, реалізуючи його слабко. Правильні питання охоплюють як архітектуру (місце деривації ключа), так і міцність реалізації (алгоритм та кількість ітерацій).
Злом Okta: інший режим невдачі
У жовтні 2023 року Okta повідомив, що понад 600 000 записів підтримки клієнтів витекли в результаті злому. Okta — платформа ідентифікації, яку багато підприємств використовують для захисту доступу до інших хмарних інструментів. Злом Okta був іншим режимом невдачі, ніж LastPass: не слабкістю ZK-реалізації, а компрометацією інфраструктури підтримки, що містила дані клієнтів.
Зростання кількості зломів SaaS на 300% у 2024 році (AppOmni/CSA) відображає обидва режими невдачі: архітектурні слабкості, як у LastPass, і компрометацію інфраструктури, як у Okta. ZK-архітектура усуває архітектурний режим невдачі. Вона не усуває всі ризики зломів, але гарантує, що навіть повна компрометація інфраструктури не розкриває дані клієнтів, що піддаються дешифруванню.
Як виглядає справжня оцінка
Для команд закупівель, що оцінюють ZK-заяви, чеклист:
Архітектурний перегляд:
- Запросіть документацію, що показує, де відбувається деривація ключа (на стороні клієнта чи сервера)
- Запитайте алгоритм шифрування, довжину ключа та кількість ітерацій
- Запросіть підтвердження, що відкритий текст ніколи не передається на сервери постачальника
Тестування сценаріїв зломів:
- Попросіть постачальника описати, що розкриє повна компрометація сервера
- Якщо відповідь містить щось інше, ніж «зашифрований шифртекст, який ми не можемо розшифрувати» — заява не є справжнім нульовим знанням
Перегляд судових процесів:
- Запитайте, чи може постачальник виконати повістку з вимогою надання відкритого тексту клієнта
- Справжні ZK-постачальники не можуть надати те, чого у них немає
Документація відповідності вимогам:
- Запросіть документацію відповідності постачальника Статті 32 GDPR
- Сертифікація ISO 27001 (зокрема Додаток A щодо криптографічних засобів контролю) надає зовнішнє підтвердження практик управління ключами
Штраф ICO у £1,2 млн для LastPass встановлює, що постачальники, що роблять заяви про шифрування, підлягають регуляторній оцінці того, чи відповідають ці заяви необхідному стандарту. Та сама система оцінки, яку застосовують регулятори, доступна командам закупівель до того, як відбудеться злом.
Джерела: