anonym.legal

By · Last updated 2026-03-03

Назад на блоготGDPR & Усогласеност

Шифрирање нула-знаење наспроти нула-доверба во облак

LastPass исто така ги шифрирал податоците на своите корисници — и сепак биле украдени 438 милиони долари. Еве разликата помеѓу шифрирање на страна на серверот и вистинско нула-знаење.

March 3, 20269 мин читање
zero-knowledgeencryptionGDPRdata protectionSaaS securityLastPass

Илузијата за шифрирање

Ажурирано за 2026 година

Во декември 2022 година, LastPass им кажа на корисниците за прекршување. Нивната порака беше смирена: лозинките биле "шифрирани". Содржината на трезорот bila "обезбедена".

До 2025 година, над 438 милиони долари биле украдени од корисниците на LastPass. Кражбата дојде директно од нивните "безбедни" трезори.

Како? LastPass ги чувал клучевите.

Вашиот безбедносен тим мора да го знае ова пред да избере алатка за облак. Се применува на секоја алатка која ракува со чувствителни датотеки — вклучувајќи платформи за анонимизација на PII.

Шифрирање на страна на серверот наспроти архитектура нула-знаење

Повеќето алатки за облак велат дека "ги шифрираат вашите датотеки". Но тие користат шифрирање на страна на серверот (SSE). Еве што тоа значи:

СвојствоШифрирање на страна на серверотАрхитектура нула-знаење
Каде се случува шифрирањетоНа серверот на продавачотНа вашиот уред (прелистувач/десктоп)
Кој ги чува клучевитеПродавачотСамо вие
Продавачот може да ја чита вашата содржинаДаНе
Прекршување на сервер ги изложува датотекитеДаНе (само шифриран текст)
Продавачот може да биде принуден да ја сподели содржинатаДаНе (тие немаат)
Пристап на органи за правна заштитаПреку продавачотНе е можно без вашиот клуч

LastPass ги чувал клучевите. Тоа беше фаталниот недостаток. Напаѓачите влегле и ги добиле и шифрираниот текст и алатките за да го скршат. Користеле социјални трикови, напади со брутална сила на слаби лозинки и стари метаподатоци на сметки.

Зошто ова е важно за GDPR член 25

GDPR член 25 (Приватност по дизајн) е јасен. Контролорите мора да користат "соодветни технички и организациски мерки". Тие мора да бидат вградени од самиот почеток.

Европскиот одбор за заштита на податоци (EDPB) додал дека ова вклучува криптографска минимизација на податоци. Самиот систем мора да го блокира пристапот до записи. Само контроли на пристап не се доволни.

Продавач кој ги чува вашите клучови не може да го исполни член 25 во неговата строга форма. Еве зошто:

  1. Прекршување на нивниот систем може да ги изложи вашите записи.
  2. Судска наредба на продавачот може да ја предаде вашата содржина.
  3. Лош вработен може да ги гледа вашите датотеки.
  4. Напад во синџирот на снабдување може да изложи сè.

Германскиот Федерален комесар за заштита на податоци (BfDI) издал насоки за ова. Исто така и австриски Datenschutzbehörde. И двата велат дека нула-знаењето е најдобриот технички избор за обработка со висок ризик.

Реалниот преглед на прекршувања на SaaS

Извештајот на AppOmni / Cloud Security Alliance 2024 забележал пораст од 300% во прекршувањата на SaaS од 2022 до 2024. Клучните факти:

  • Времето до прекршување: 9 минути (порано мерено во часови)
  • Улогата на трети страни во прекршувањата: удвоена на годишно ниво (Verizon DBIR 2025)
  • Прекршување на Conduent: 25,9 милиони записи изложени (броеви за социјално осигурување, здравствени датотеки)
  • Прекршување на добавувач на NHS: 9 милиони пациенти изложени

Политичките зборови повеќе не се доволни. Силната архитектура е минималниот стандард. Ова се применува на сета обработка со висок ризик.

Kako изгледа вистинската архитектура нула-знаење

Вистинскиот систем нула-знаење ги има овие јасни особини:

1. Изведување клуч на страна на клиент Вашиот клуч доаѓа од вашата лозинка. KDF со висока меморија (Argon2id, bcrypt или scrypt) работи на вашиот уред. Клучот никогаш не го напушта.

2. Шифрирање на страна на клиент Вашата содржина е шифрирана пред да го напушти вашиот прелистувач или апликација. Серверот добива само шифриран текст. Без клучот, тој шифриран текст е безвреден.

3. Без складирање клуч на страна на сервер Продавачот не чува никакви клучови, ниту делови од клучеви, ниту резервни копии на клучеви. Ја користите вашата сопствена фраза за обновување за да го вратите пристапот.

4. Криптографска проверливост Системот мора да биде добро документиран. Мора да биде отворен за ревизија. Нејасните тврдења за "крај-до-крај шифрирање" без технички детали се предупредувачки знак.

Kako anonym.legal имплементира нула-знаење

Пријавувањето нула-знаење на anonym.legal користи:

  • Изведување клуч Argon2id: 64 MB меморија, 3 итерации — изборот на OWASP за апликации со висока безбедност
  • Шифрирање AES-256-GCM: Работи целосно во вашиот прелистувач или десктоп апликација пред да се испрати која било содржина
  • 24-зборна фраза за обновување BIP39: Единствениот начин за враќање на пристапот — не е складиран од anonym.legal
  • Нула пристап до клуч на страна на сервер: Серверите на anonym.legal добиваат само AES-256-GCM шифриран текст кој не можат да го дешифрираат

Целосно прекршување на сервер на anonym.legal би донело само шифрирани блобови. Без клучот на секој корисник — кој живее само на нивниот уред — тие блобови се безвредни.

Видете го нашиот преглед на безбедност и усогласеност и документација за усогласеност за целосни детали.

Листата за проверка при оценување на продавачи

Кога избирате алатка за облак за чувствителни записи, поставете ги овие прашања:

Прашања за архитектура:

  • Каде се случува шифрирањето — на вашиот уред или на серверот на продавачот?
  • Кој ги создава клучевите?
  • Каде се складираат клучевите?
  • Може ли продавачот да предаде копии во обичен текст на вашата содржина ако добие судска наредба?
  • Што се случува со вашите датотеки ако продавачот биде купен?

Прашања за отпорност на прекршување:

  • Ако системот на продавачот целосно биде прекршен, кои записи се изложени?
  • Ако вработен на продавачот стане злонамерен, која содржина може да ја види?
  • Ако напад во синџирот на снабдување го погоди продавачот, што е изложено?

Регулаторни прашања:

  • Може ли продавачот да покаже документација за GDPR член 25?
  • Дали надворешен ревизор го прегледал системот?
  • Дали постои сертификат ISO 27001 или SOC 2 кој го опфаќа шифрирањето?

Секој продавач кој не може да одговори "нула — содржината е шифрирана пред да го напушти вашиот уред" на прашањата за прекршување користи шифрирање на страна на серверот. Проверете го нашиот FAQ и речник за повеќе термини.

Случај на употреба: Должна грижа на германска здравствена осигурителна компанија

Службеник за усогласеност во голема германска здравствена осигурителна компанија (Krankenkasse) потребуваше алатка за анонимизација во облак. Задачата: обработка на дневници на жалби на сопственици на полиси. DPO имаше четири барања:

  • Продавачот не може да пристапи до записи на сопственици на полиси
  • Без обработка надвор од Германија
  • Технички мерки на GDPR член 32 документирани
  • Ризикот за прекршување кој може да се пријави на 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 складираат само шифриран текст кој не можат да го дешифрираат. Дознајте повеќе на нашата страница за основачот или истражете го системот на токени.

Извори

Подготвени да ги заштитите вашите податоци?

Започнете со анонимизација на PII со 285+ типови на ентитети на 48 јазици.

About this page

We update this page when our platform or the law changes.

Read our founder note for how we work.

Each change shows up in the timestamp at the top.

Related reading

We follow these rules

  • GDPR (EU 2016/679).
  • ISO/IEC 27001:2022.
  • NIS2 (EU 2022/2555).
  • HIPAA safe harbor under 45 CFR § 164.514(b)(2).

Our promise

We do not sell your data.

We do not train models on your text.

We store your files in Germany.

You can delete your account at any time.

You own your work.

Where we run

Our servers live in Falkenstein, Germany.

We use Hetzner. They hold ISO 27001 certification.

All data stays in the EU.

Backups run every day.

Need help?

Email support@anonym.legal.

We reply within one business day.

How we test

We run a full check suite on every release.

Each surface gets its own sweep script and report.

Human reviewers spot-check the output each week.

We track recall and precision on a labelled set.

Bad runs block the deploy.

What we never do

  • We never sell your information to third parties.
  • We never train models on what you upload.
  • We never keep your work after you delete it.
  • We never share keys with any outside firm.
  • We never run ads inside the product.

Plans in plain words

We sell credits, not seats.

One credit covers one short job.

Long jobs use a few credits each.

You can top up at any time.

Unused credits roll over each month.

Read the plans page for current rates.

Who built this

A small team of engineers and lawyers built this.

We ship from Europe and work in the open.

Our founder note spells out why we started.

Where to start

How the parts fit

A browser add-on cleans text inside Chrome.

A Word plug-in handles drafts in Office.

A small desktop tool works on whole folders.

An agent protocol link feeds large models safely.

All four share one core engine and one rule set.

Words from our team

We started this work after a lunch about cookies.

One friend kept getting odd ads on her phone.

We asked why a court file leaked through a draft.

We sketched the first build on a napkin that week.

By month three we had a tiny demo for a friend.

She used it on her first case the next day.

Common questions we hear

Can the tool read scanned PDFs? Yes, with OCR.

Does it work on long files? Yes, in small chunks.

Can I roll my own rule set? Yes, save it as a preset.

Does it run offline? The desktop build runs offline.

Do you keep my files? No, the cloud build wipes after each run.

Will it learn from my work? No, we never train on inputs.

A short tour of the workflow

Upload a file or paste a snippet of prose.

Pick the entities you want gone from the draft.

Choose a method: replace, mask, hash, encrypt, or redact.

Press run and watch the side panel show each hit.

Skim the result and tweak any rule that misfired.

Save the cleaned file or send it to a teammate.