Иллюзия Шифрования
В декабре 2022 года LastPass объявил о нарушении безопасности. Официальное заявление содержало успокаивающие формулировки: пароли пользователей были "зашифрованы". Данные в хранилище были "защищены".
К 2025 году более $438 миллионов было украдено у пользователей LastPass — прямо из их предположительно зашифрованных хранилищ.
Как? LastPass держал ключи.
Это критическое различие, которое каждая команда безопасности предприятия должна понять перед выбором любого облачного инструмента, который обрабатывает конфиденциальные данные — включая платформы анонимизации PII.
Шифрование на Стороне Сервера vs. Архитектура Нулевого Знания
Большинство облачных инструментов, которые утверждают, что "шифруют ваши данные", используют шифрование на стороне сервера (SSE). Вот что это на самом деле означает:
| Свойство | Шифрование на Стороне Сервера | Архитектура Нулевого Знания |
|---|---|---|
| Где происходит шифрование | На сервере поставщика | На вашем устройстве (браузере/настольном ПК) |
| Кто держит ключи | Поставщик | Только вы |
| Поставщик может читать ваши данные | Да | Нет |
| Нарушение сервера раскрывает данные | Да | Нет (только шифротекст) |
| Поставщик может быть вынужден предоставить данные | Да | Нет (они их не имеют) |
| Доступ регуляторов/правоохранительных органов | Через поставщика | Невозможно без вашего ключа |
LastPass использовал шифрование на стороне сервера с ключами, которые они контролировали. Когда злоумышленники нарушили их инфраструктуру, они получили как шифротекст, так и средства для его расшифровки — через социальную инженерию сотрудников, перебор слабых мастер-паролей и использование метаданных о старых аккаунтах.
Почему Это Важно для Статьи 25 GDPR
Статья 25 GDPR (Конфиденциальность по Дизайну) требует, чтобы контроллеры данных внедряли "соответствующие технические и организационные меры", которые интегрируют защиту данных в обработку "по дизайну и по умолчанию."
Европейский комитет по защите данных (EDPB) уточнил, что это включает криптографическое минимизирование данных — что означает, что сама архитектура должна делать данные недоступными для несанкционированных сторон, а не просто защищенными с помощью средств контроля доступа.
Поставщик, который держит ваши ключи шифрования, не может удовлетворить статью 25 в строгом толковании, потому что:
- Успешное нарушение их инфраструктуры может раскрыть ваши данные
- Юридическая повестка, направленная поставщику, может привести к раскрытию ваших данных
- Непорядочный сотрудник у поставщика может получить доступ к вашим данным
- Компрометация службы управления ключами поставщика может раскрыть ваши данные
Федеральный комиссар по защите данных Германии (BfDI) и австрийская Datenschutzbehörde выпустили рекомендации, в которых говорится, что архитектура нулевого знания является предпочтительной технической реализацией для обработки с высоким уровнем риска.
Реальность Нарушений SaaS
Отчет AppOmni / Cloud Security Alliance 2024 зафиксировал 300%-ное увеличение нарушений SaaS с 2022 по 2024 год. Сложность атак значительно возросла:
- Среднее время до нарушения: 9 минут (снижение с часов)
- Участие третьих лиц в нарушениях: удвоилось по сравнению с прошлым годом (Verizon DBIR 2025)
- Нарушение Conduent: 25.9 миллиона записей раскрыто (номера социального страхования, данные о медицинском страховании)
- Нарушение поставщика NHS: 9 миллионов пациентов раскрыто
В этой угрожающей среде архитектурные гарантии заменили обещания политики как минимально приемлемый стандарт для обработки данных с высоким уровнем риска.
Как Выглядит Истинная Архитектура Нулевого Знания
Истинная архитектура нулевого знания имеет следующие проверяемые свойства:
1. Генерация ключей на стороне клиента Ключ шифрования генерируется из вашего пароля с использованием памяти-сложного KDF (Argon2id, bcrypt или scrypt) на вашем устройстве. Полученный ключ никогда не покидает ваше устройство.
2. Шифрование на стороне клиента Данные шифруются до того, как покинут ваш браузер или настольное приложение. Сервер получает только шифротекст — бессмысленный без ключа.
3. Отсутствие хранения ключей на стороне сервера Поставщик не хранит ключи, фрагменты ключей и резервные копии ключей. Восстановление осуществляется через контролируемую пользователем фразу восстановления.
4. Криптографическая проверяемость Архитектура должна быть документируемой и подлежащей аудиту — желательно открытой для внешнего обзора. Неясные утверждения о "сквозном шифровании" без технических деталей должны вызывать скептицизм.
Как anonym.legal Реализует Нулевое Знание
Аутентификация нулевого знания anonym.legal использует:
- Генерация ключей Argon2id: 64MB памяти, 3 итерации — параметры, рекомендуемые OWASP для приложений с высокой безопасностью
- Шифрование AES-256-GCM: Полностью применяется в браузере/настольном ПК до передачи любых данных
- Фраза восстановления из 24 слов BIP39: Единственный способ восстановить доступ — не хранится anonym.legal
- Отсутствие доступа к ключам на стороне сервера: Серверы anonym.legal получают только шифротекст AES-256-GCM без ключей для его расшифровки
Полное нарушение безопасности сервера anonym.legal приведет к получению зашифрованных данных, которые нельзя расшифровать без ключа, полученного каждым пользователем — который существует только на их устройстве.
Контрольный Список Оценки Поставщика
При оценке любого облачного инструмента, который обрабатывает конфиденциальные данные, задайте следующие вопросы:
Вопросы по архитектуре:
- Где происходит шифрование/расшифровка — на вашем устройстве или на сервере поставщика?
- Кто генерирует ключи шифрования?
- Где хранятся ключи шифрования?
- Может ли поставщик предоставить открытые копии ваших данных в ответ на повестку?
- Что произойдет с вашими данными, если поставщик будет приобретен?
Вопросы по устойчивости к нарушениям:
- Если вся инфраструктура поставщика будет скомпрометирована, какие данные будут раскрыты?
- Если сотрудник поставщика станет непорядочным, к каким данным они могут получить доступ?
- Если атака на цепочку поставок скомпрометирует инфраструктуру поставщика, что будет раскрыто?
Регуляторные вопросы:
- Может ли поставщик предоставить документацию, удовлетворяющую статье 25 GDPR?
- Была ли архитектура проверена независимым аудитором безопасности?
- Есть ли сертификат ISO 27001 или SOC 2, охватывающий реализацию шифрования?
Любой поставщик, который не может четко ответить "ноль — ваши данные зашифрованы до того, как покинут ваше устройство" на вопросы по устойчивости к нарушениям, полагается на шифрование на стороне сервера.
Случай Использования: Должная Осмотрительность Немецкого Страховщика Здоровья
Офицер по соблюдению норм в крупной немецкой страховой компании (Krankenkasse) нуждался в облачном инструменте анонимизации для обработки журналов жалоб застрахованных лиц. Контрольный список DPO включал:
- Поставщик не может получить доступ к данным застрахованных лиц
- Нет обработки данных на инфраструктуре за пределами Германии
- Документированные технические меры статьи 32 GDPR
- Минимизирован риск нарушения, подлежащий отчету DPA
Ведущий SaaS по анонимизации из США не прошел первый критерий: их команда поддержки могла сбрасывать хранилища пользователей, что подразумевает доступ к ключам на стороне сервера. Второй инструмент хранил обработанный текст в течение 30 дней для целей "аудитного следа" — снова доступ на стороне сервера.
Архитектура нулевого знания anonym.legal удовлетворила все четыре критерия. DPO мог задокументировать: "Даже полное нарушение инфраструктуры поставщика не приведет к раскрытию данных застрахованных лиц — ключи шифрования существуют только на наших рабочих станциях." Документация по статье 32 GDPR была завершена за четыре часа.
Прецедент Принуждения ICO
В декабре 2025 года Офис комиссара по информации Великобритании оштрафовал юридическое лицо LastPass в Великобритании на £1.2 миллиона за "недостаток внедрения соответствующих технических и организационных мер безопасности."
Штраф был не за само нарушение — он был за архитектурные решения, которые сделали нарушение катастрофическим: недостаточные итерации KDF для старых аккаунтов, раскрытие метаданных и основополагающий выбор держать ключи на стороне сервера.
Регуляторы теперь оценивают не только произошло ли нарушение, но и минимизировала ли архитектура влияние нарушения. Архитектура нулевого знания является самым ясным техническим доказательством этого намерения.
Заключение
"Мы шифруем ваши данные" не является гарантией безопасности — это маркетинговое заявление, требующее проверки.
Важные вопросы: кто держит ключи, где происходит шифрование и что раскрывается, если инфраструктура поставщика скомпрометирована?
Для организаций, обрабатывающих конфиденциальные данные в соответствии с GDPR, HIPAA или любой сопоставимой системой, архитектурный ответ на эти вопросы определяет как вашу регуляторную подверженность, так и ваш фактический риск нарушения.
LastPass зашифровал данные своих пользователей. Архитектура нулевого знания сделала бы нарушение 2022 года несущественным. $438 миллионов, украденных у пользователей, были ценой архитектурного сокращения.
anonym.legal реализует архитектуру нулевого знания для анонимизации PII: генерация ключей Argon2id происходит в вашем браузере или настольном приложении, шифрование AES-256-GCM происходит до того, как данные покинут ваше устройство, а серверы anonym.legal хранят только шифротекст, который они не могут расшифровать.
Источники: