Ілюзія шифрування
Оновлено для 2026 року
У грудні 2022 року LastPass повідомив користувачів про витік. Їхнє повідомлення було спокійним: паролі були «зашифровані». Вміст сховища був «захищений».
До 2025 року понад $438 мільйонів було вкрадено у користувачів LastPass. Крадіжка відбулася безпосередньо з їхніх «захищених» сховищ.
Як? LastPass тримав ключі.
Ваша команда безпеки повинна знати це перед вибором хмарного інструменту. Це стосується будь-якого інструменту, що обробляє чутливі файли, включно з платформами анонімізації PII.
Шифрування на стороні сервера проти архітектури нульового знання
Більшість хмарних інструментів кажуть, що «шифрують ваші файли». Але вони використовують шифрування на стороні сервера (SSE). Ось що це означає:
| Властивість | Шифрування на стороні сервера | Архітектура нульового знання |
|---|---|---|
| Де відбувається шифрування | На сервері постачальника | На вашому пристрої (браузер/десктоп) |
| Хто тримає ключі | Постачальник | Тільки ви |
| Постачальник може читати ваш вміст | Так | Ні |
| Витік сервера розкриває файли | Так | Ні (тільки шифротекст) |
| Постачальника можна примусити поділитися вмістом | Так | Ні (у них його немає) |
| Доступ правоохоронних органів | Через постачальника | Неможливо без вашого ключа |
LastPass тримав ключі. Це була фатальна помилка. Зловмисники зламали систему і отримали як шифротекст, так і інструменти для його злому. Вони використовували соціальну інженерію, перебір слабких паролів та метадані старих акаунтів.
Чому це важливо для Статті 25 GDPR
Стаття 25 GDPR (Захист даних за задумом) однозначна. Контролери повинні використовувати «відповідні технічні та організаційні заходи». Вони повинні бути вбудовані з самого початку.
Європейська рада з захисту даних (EDPB) додала, що це включає криптографічну мінімізацію даних. Сама система повинна блокувати доступ до записів. Одних лише засобів контролю доступу недостатньо.
Постачальник, який тримає ваші ключі, не може виконати Статтю 25 у її суворому трактуванні. Ось чому:
- Витік їхньої системи може розкрити ваші записи.
- Судова повістка постачальнику може передати ваш вміст.
- Недобросовісний співробітник може переглянути ваші файли.
- Атака на ланцюг постачання може розкрити все.
Німецький Федеральний уповноважений з захисту даних (BfDI) видав відповідні рекомендації. Австрійський Datenschutzbehörde також. Обидва вказують, що нульове знання є найкращим технічним вибором для обробки даних підвищеного ризику.
Перевірка реальності: витоки SaaS
Звіт AppOmni / Cloud Security Alliance 2024 зафіксував зростання витоків SaaS на 300% з 2022 по 2024 рік. Ключові факти:
- Час до витоку: 9 хвилин (раніше вимірювався годинами)
- Роль третіх сторін у витоках: подвоїлася рік до року (Verizon DBIR 2025)
- Витік Conduent: 25,9 мільйона записів розкрито (номери соціального страхування, медичні файли)
- Витік у постачальника NHS: 9 мільйонів пацієнтів розкрито
Декларативних слів більше недостатньо. Міцна архітектура є мінімальним стандартом. Це стосується всієї обробки даних підвищеного ризику.
Як виглядає справжня архітектура нульового знання
Справжня система нульового знання має ці чіткі ознаки:
1. Деривація ключів на стороні клієнта Ваш ключ походить від вашого пароля. На вашому пристрої запускається пам'яткостійка KDF (Argon2id, bcrypt або scrypt). Ключ ніколи не покидає пристрій.
2. Шифрування на стороні клієнта Ваш вміст шифрується перед тим, як покинути ваш браузер або застосунок. Сервер отримує лише шифротекст. Без ключа цей шифротекст марний.
3. Відсутність зберігання ключів на сервері Постачальник не зберігає ключів, частин ключів та резервних копій ключів. Ви використовуєте власну фразу відновлення для повернення доступу.
4. Криптографічна верифікованість Система повинна бути добре задокументована. Вона повинна бути відкрита для аудиту. Розпливчасті заяви про «наскрізне шифрування» без технічних деталей — це тривожний знак.
Як anonym.legal реалізує нульове знання
Вхід із нульовим знанням anonym.legal використовує:
- Деривація ключів Argon2id: 64 МБ пам'яті, 3 ітерації — вибір OWASP для застосунків із високим рівнем безпеки
- Шифрування AES-256-GCM: Повністю запускається у вашому браузері або десктопному застосунку перед відправкою будь-якого вмісту
- 24-слівна фраза відновлення BIP39: Єдиний спосіб відновити доступ — не зберігається anonym.legal
- Нульовий серверний доступ до ключів: Сервери anonym.legal отримують лише шифротекст AES-256-GCM, який вони не можуть розшифрувати
Повний витік сервера anonym.legal призведе лише до зашифрованих блобів. Без ключа кожного користувача — який знаходиться лише на їхньому пристрої — ці блоби марні.
Дивіться наш огляд безпеки та відповідності та документацію відповідності для повних деталей.
Контрольний список оцінки постачальника
Обираючи хмарний інструмент для чутливих записів, задайте ці питання:
Питання про архітектуру:
- Де відбувається шифрування — на вашому пристрої чи на сервері постачальника?
- Хто створює ключі?
- Де зберігаються ключі?
- Чи може постачальник передати відкрити копії вашого вмісту за судовою повісткою?
- Що станеться з вашими файлами, якщо постачальника придбають?
Питання про стійкість до витоків:
- Якщо система постачальника повністю зламана, які записи розкриваються?
- Якщо недобросовісний співробітник постачальника зловмисничає, який вміст він може побачити?
- Якщо атака на ланцюг постачання вражає постачальника, що розкривається?
Регуляторні питання:
- Чи може постачальник показати документацію щодо Статті 25 GDPR?
- Чи перевіряв систему зовнішній аудитор?
- Чи є сертифікат ISO 27001 або SOC 2, що охоплює шифрування?
Будь-який постачальник, який не може відповісти «нуль — вміст шифрується перед тим, як покинути ваш пристрій» на питання про витоки, використовує шифрування на стороні сервера. Перевіряйте наш FAQ та глосарій для більшої кількості термінів.
Кейс: комплаєнс-перевірка у німецькій страховій компанії охорони здоров'я
Комплаєнс-офіцер великої німецької страхової компанії (Krankenkasse) потребував хмарного інструменту анонімізації. Завдання: обробляти журнали скарг страхувальників. DPO мав чотири вимоги:
- Постачальник не може отримати доступ до записів страхувальників
- Жодної обробки поза Німеччиною
- Задокументовані технічні заходи за Статтею 32 GDPR
- Мінімізований ризик інцидентів, що підлягають повідомленню DPA
Великий американський SaaS для анонімізації не відповідав першій вимозі. Команда підтримки могла скидати сховища користувачів — доказ серверного доступу до ключів. Другий інструмент зберігав оброблений текст 30 днів для «журналу аудиту» — знову серверний доступ.
anonym.legal відповідав усім чотирьом критеріям. DPO міг написати: «Навіть повний витік постачальника не дасть використовних записів страхувальників — ключі існують лише на наших робочих станціях». Документація GDPR Статті 32 була готова за чотири години.
Перегляньте наші кейси для більшої кількості реальних прикладів.
Прецедент ICO
У грудні 2025 року Управління інформаційного комісара Великобританії оштрафувало британську юридичну особу LastPass на £1,2 мільйона. Причина: «невжиття відповідних технічних та організаційних заходів безпеки».
Штраф був не за сам витік. Він був за архітектурні рішення, що зробили витік настільки шкідливим. Погані налаштування KDF, розкриті метадані та серверне зберігання ключів — все це відіграло роль.
Регулятори тепер запитують: чи обмежила система наслідки витоку? Архітектура нульового знання дає на це чітку відповідь. Це найкращий доказ такого наміру.
Коли архітектура нульового знання не підходить
Шифрування з нульовим знанням має компроміси. Вони важливі для деяких кейсів:
Складність відновлення: Якщо користувачі втрачають ключі, їхні файли втрачаються назавжди. Задніх дверей немає. Висока плинність персоналу або слабкі звички управління ключами роблять це реальним ризиком.
Тертя при співпраці: Зашифрованим вмістом можна ділитися лише якщо інша сторона має правильні інструменти розшифрування. Це повільніше, ніж просте спільне посилання у стандартних хмарних застосунках.
Граничні регуляторні випадки: Деякі регіони вимагають доступу правоохоронних органів до записів за судовим рішенням. Системи з нульовим знанням блокують це за своїм задумом. Це може спричинити юридичні проблеми у фінансових послугах або телекомунікаціях, де діють правила законного перехоплення.
Обчислювальне навантаження: Деривація ключів Argon2id та шифрування AES-256-GCM додають затримку. Це найбільш відчутно при обробці в реальному часі з великим обсягом.
Для команд, що обробляють мільйони документів на день, може краще підійти гібридний підхід. Шифруйте лише найбільш чутливі поля. Залишайте метадані відкритими. Дивіться тарифні плани для обсягових рівнів.
Висновок
«Ми шифруємо ваші файли» — це не обіцянка безпеки. Це маркетингова фраза, що потребує перевірки.
Реальні питання прості. Хто тримає ключі? Де відбувається шифрування? Що розкривається у разі злому системи постачальника?
Для команд, що обробляють чутливі записи відповідно до GDPR, HIPAA або подібних правил, ці архітектурні рішення визначають як юридичний ризик, так і реальне розкриття у разі витоку.
LastPass шифрував вміст своїх користувачів. Архітектура нульового знання зробила б витік 2022 року незначною подією. $438 мільйонів, вкрадених у користувачів, — це ціна архітектурного скорочення шляху.
anonym.legal використовує архітектуру нульового знання для анонімізації PII. Деривація ключів Argon2id запускається у вашому браузері або десктопному застосунку. Шифрування AES-256-GCM відбувається до того, як будь-який вміст покидає ваш пристрій. Сервери anonym.legal зберігають лише шифротекст, який вони не можуть розшифрувати. Дізнайтеся більше на нашій сторінці засновника або ознайомтеся з токен-системою.