Шифрование баз данных: методы защиты информации в Web3

В большинстве публичных сетей запись в блокчейн означает обратное: данные доступны каждому узлу, индексатору, аналитическому сервису и любому наблюдателю, который умеет читать состояние протокола. Распределенность защищает от единой точки отказа, но не скрывает содержимое.

Это базовая архитектурная ошибка, из-за которой проект сначала публикует чувствительные метаданные, а затем пытается добавить приватность поверх уже раскрытой модели. Для защиты данных в блокчейн-проектах нужно заранее разделить три задачи: шифрование содержимого, контроль доступа и доказательство корректности операции. AES решает только первую. MPC и threshold cryptography — вторую. ZKP — третью. FHE пытается совместить вычисления с сохранением конфиденциальности, но платит за это серьезным вычислительным overhead.

Универсального алгоритма для всех сценариев нет. Есть набор криптографических примитивов и несколько архитектур хранения. Их приходится комбинировать.

Почему публичный блокчейн не защищает данные по умолчанию

Публичный блокчейн — это система с намеренно избыточной видимостью состояния. Валидаторы должны проверить транзакции, узлы — синхронизировать реестр, а внешние клиенты — восстановить состояние смарт-контрактов. Если в транзакции находится открытый JSON, строка, идентификатор пользователя или ссылка на чувствительный объект, считать эти данные приватными нельзя.

Даже удаление записи не решает проблему. В блокчейне удаление обычно означает изменение актуального состояния контракта. История транзакций остается доступной, а данные могут быть сохранены архивными узлами, индексаторами, аналитическими платформами и сторонними архивами.

На практике у Web3-приложения есть несколько разных поверхностей утечки:

• содержимое транзакций и calldata;
• события смарт-контрактов, включая emit с персональными идентификаторами;
• публичное состояние контракта;
• открытые таблицы децентрализованных СУБД;
• IPFS-объекты, если CID связан с открытым или предсказуемым содержимым;
• логи RPC-провайдеров и индексаторов;
• метаданные доступа: время операции, размер объекта, адрес отправителя, частота запросов;
• клиентская часть dapp, где ключ расшифрования может оказаться в памяти браузера.

Последний пункт обычно недооценивают. Сильный шифр не компенсирует слабую модель ключей. Если браузер получает секрет после обычной проверки адреса кошелька, злоумышленнику достаточно скомпрометировать сессию, расширение или фронтенд. В этом случае криптографический алгоритм может быть безупречным, а система — уязвимой.

Приватность в Web3 определяется не наличием шифра, а тем, кто способен расшифровать данные и при каких условиях.

Поэтому шифрование баз данных начинается не с выбора AES-256 или FHE. Сначала описывается модель угроз: кто видит ciphertext, кто управляет ключами, какие операции должны быть проверяемыми, а какие — полностью скрытыми.

Архитектура хранения: что остается в блокчейне

Для чувствительных данных почти всегда используется гибридная схема. Блокчейн хранит не сам документ, а минимальный набор проверяемых атрибутов:

• хэш объекта;
• идентификатор записи;
• ссылку или CID на зашифрованный объект;
• политику доступа;
• состояние разрешения;
• доказательство корректности операции;
• иногда — корень Merkle-структуры или commitment.

Само содержимое размещается вне блокчейна: в децентрализованном хранилище, распределенной базе данных или обычной инфраструктуре с дополнительным криптографическим слоем. Это снижает стоимость записи и не превращает блокчейн в публичный архив персональных данных.

Типовая логика выглядит так:

1. Клиент формирует объект данных.

2. Объект шифруется до отправки в хранилище.

3. Для ciphertext рассчитывается хэш, например SHA-256.

4. Зашифрованный объект размещается вне блокчейна.

5. В блокчейн записываются хэш, идентификатор и правила доступа.

6. Получатель проходит проверку права доступа.

7. Ключ или его доля передается только после успешной авторизации.

8. Клиент расшифровывает объект локально.

В этой схеме SHA-256 не защищает содержимое. Он проверяет целостность. Если ciphertext заменили, хэш перестанет совпадать. Но любой, кто получил сам ciphertext, все еще может пытаться атаковать шифр. Это разные свойства, и смешивать их в архитектурной документации нельзя.

Децентрализованные СУБД и инфраструктурные протоколы вроде Polybase, Tableland, Ceramic и Lit Protocol позволяют разделить слой данных и слой политики доступа. Но наличие такого компонента не означает автоматического шифрования всех таблиц. Например, в Tableland защита зависит от того, добавил ли разработчик криптографический слой на стороне клиента или подключил внешний механизм управления ключами.

Если данные отправляются в базу в открытом виде, сеть распределяет открытый текст. Децентрализация здесь только увеличивает число копий.

Что должно быть публичным, а что — нет

Полностью скрывать все состояние тоже не всегда нужно. Смарт-контракту часто требуется видеть факт разрешения, статус заявки или commitment, но не содержимое документа. Полезно проектировать данные по уровням:

Чем больше данных помещается в публичный слой, тем сложнее обеспечить приватность задним числом. Особенно проблемны уникальные идентификаторы, временные метки и связи между адресами. Даже зашифрованный объект может раскрывать профиль поведения через размер, частоту обновлений и корреляцию с публичными транзакциями.

AES-256: рабочий слой шифрования данных

Для самой записи в базе чаще всего нужен не экзотический криптографический протокол, а нормальное симметричное шифрование. AES-256 остается практичным выбором для хранения файлов, сообщений, медицинских записей, коммерческих документов и структурированных полей.

В архитектуре Polynote на базе Polybase для шифрования данных перед отправкой в коллекцию применяется AES-CBC-256. Это важная деталь, но не повод автоматически считать схему безопасной. CBC — режим конфиденциальности, а не полноценной аутентификации сообщения. Если разработчик не добавил MAC или отдельную проверку целостности, ciphertext может быть модифицирован без знания ключа. Результат — уязвимость класса malleability и потенциальные ошибки при расшифровании.

Для новых систем обычно предпочтительнее аутентифицированное шифрование — например, AEAD-режимы. Конкретный выбор зависит от криптографической библиотеки, требований совместимости и протокола ротации ключей. Само обозначение AES-256 ничего не говорит о безопасности, если не указаны:

• режим работы;
• способ генерации nonce или IV;
• источник энтропии;
• схема хранения ключа;
• механизм проверки целостности;
• правила ротации;
• поведение при отзыве доступа;
• формат ошибок при расшифровании.

Одна из типовых ошибок — использовать один ключ для всей базы. Компрометация такого ключа раскрывает все записи сразу. Более надежная модель использует иерархию ключей:

• мастер-ключ защищает ключи данных;
• отдельный ключ используется для набора записей или tenant;
• для конкретного объекта применяется data encryption key;
• ключи данных оборачиваются мастер-ключом;
• доступ выдаётся через отдельную policy layer.

Такой подход позволяет отзывать доступ и ротировать ключи без перешифрования всего массива. Но он усложняет recovery. Если единственный ключ потерян, децентрализация не восстановит plaintext. Она только распределит отказ между несколькими участниками, если архитектура это предусматривает.

Почему шифрование на клиенте предпочтительнее

Шифрование после передачи данных на сервер или в распределенную БД уже не закрывает канал между клиентом и сервисом. Оператор инфраструктуры может увидеть plaintext до момента шифрования. Если задача — защитить данные от самой инфраструктуры хранения, объект должен шифроваться на стороне клиента.

Это особенно критично для dapp, где серверная часть часто воспринимается как несущественная. На практике backend может:

• выдавать ключи;
• подписывать политики доступа;
• формировать разрешения;
• вести индексы;
• обслуживать recovery;
• управлять сессиями.

Каждый такой компонент становится частью доверенной вычислительной базы. Если он видит открытый текст или полный ключ, система не является end-to-end приватной, даже если данные лежат в IPFS или децентрализованной БД.

Для медицинских, биометрических и других чувствительных наборов данных это не теоретическая оговорка. Даже публичный материал о безопасности гормональной терапии, например разбор итогов экспертного симпозиума FDA о тестостероне при менопаузе, показывает, насколько контекст и медицинская принадлежность информации могут быть чувствительными. В Web3-проекте подобные документы нельзя связывать с публичным адресом кошелька без отдельной модели приватности.

Управление ключами: MPC и threshold cryptography

Симметричный шифр отвечает на вопрос «как зашифровать данные». Он не отвечает на вопрос «кто выдаст ключ и как не превратить этот компонент в единую точку компрометации».

Lit Protocol использует пороговую криптографию и MPC для распределения приватного ключа между узлами. В такой модели полный секрет не обязан существовать у одного оператора. Для операции требуется согласованное участие порогового числа узлов. Если задано условие t-of-n, то для действия нужны t участников из n, а компрометация меньшего числа узлов не должна раскрывать ключ.

Это не магическое свойство и не синоним полной децентрализации. Безопасность зависит от нескольких компонентов:

• схемы генерации и восстановления ключей;
• порога подписей или расшифрования;
• независимости операторов узлов;
• защиты коммуникаций между участниками;
• логики policy engine;
• устойчивости к Sybil-атакам;
• механизма обновления состава участников;
• контроля отказов и цензуры;
• аудита клиентского SDK.

MPC позволяет выполнять совместные операции так, чтобы участники не раскрывали свои секреты друг другу. Threshold cryptography распределяет способность выполнить действие между несколькими сторонами. В реальных Web3-системах эти подходы часто используются вместе, но они решают разные задачи.

Где ломается модель доступа

Основная уязвимость распределенного управления ключами часто находится не в математике, а в условии выдачи. Например, policy может разрешать расшифрование любому клиенту, который докажет владение конкретным NFT. Если NFT можно временно арендовать, передать или купить через flash-механизм, право доступа становится таким же временным и переносимым.

Другой пример — авторизация только по адресу кошелька. Адрес доказывает контроль над ключом подписи, но не доказывает личность пользователя, целостность устройства или отсутствие украденной сессии. Если ключ расшифрования выдается сразу после подписи сообщения, злоумышленник с доступом к кошельку получает и данные.

Устойчивая policy layer должна описывать не только субъект, но и контекст:

• тип ресурса;
• операцию — чтение, изменение, экспорт или удаление;
• срок действия разрешения;
• минимальный объем выдаваемых данных;
• условия отзыва;
• необходимость нескольких подписей;
• допустимую сеть или окружение исполнения;
• поведение при недоступности части узлов.

Здесь уместна мультиподпись, но она не заменяет шифрование. Multisig подтверждает коллективное решение, а не скрывает данные. Если содержимое записано в публичный блокчейн открытым текстом, пять подписей не сделают его приватным.

ZK-доказательства: приватность вычисления, а не шифрование базы

ZK-доказательство позволяет одной стороне доказать корректность утверждения, не раскрывая исходные данные. В Web3 это полезно для проверки баланса, принадлежности множеству, выполнения условия доступа или корректности вычисления над скрытым состоянием.

Но ZKP не является заменой AES. Доказательство обычно показывает, что утверждение выполнено, а не хранит конфиденциальный объект в зашифрованной базе. Если нужно сохранить документ, используется шифрование. Если нужно доказать свойство документа без раскрытия содержимого, поверх него добавляется ZK-механизм.

Пример архитектуры:

1. Пользователь шифрует документ симметричным ключом.

2. Для документа вычисляется commitment.

3. В блокчейн записывается commitment или корень Merkle-дерева.

4. Пользователь формирует ZK-доказательство свойства документа.

5. Смарт-контракт проверяет доказательство.

6. Сам документ остается зашифрованным и не публикуется.

Так можно доказать наличие допустимого атрибута, не раскрывая весь набор полей. Например, возраст пользователя, принадлежность к разрешенному множеству или соответствие лимиту. Но ZKP не скрывает автоматически метаданные транзакции. Адрес отправителя, момент операции, размер calldata и факт обращения к конкретному контракту могут остаться публичными.

Существует и другой класс риска: доказательство может быть корректным, но схема — плохо спроектированной. Нужно проверять:

• какие публичные входы раскрываются;
• какие private inputs используются;
• что именно связывает доказательство с конкретным объектом;
• предотвращается ли replay;
• есть ли уникальный nullifier;
• как обновляется proving key;
• как проверяется trusted setup, если он нужен;
• существует ли возможность подмены commitment.

В исследовательском прототипе гибридного хранения медицинских данных средняя задержка ZKP-запросов к блокчейну составила 5,83 мс, а операции на эллиптических кривых ECC — 8,72 мс. Эти значения полезны как ориентир для конкретной экспериментальной системы, но не как универсальный benchmark для любого Web3-хранилища. Реальная задержка зависит от размера схемы, proving system, оборудования, сети и способа агрегации запросов.

В сети Starknet прувер S-two продемонстрировал пропускную способность 2 630 пользовательских операций в секунду при формировании ZKP. Это показывает, что proving infrastructure масштабируется, но не отменяет overhead подготовки witness, генерации доказательства и верификации. Кроме того, пропускная способность прувера не равна пропускной способности всей dapp-архитектуры.

ZKP скрывает данные только в пределах формально определенного утверждения. Всё, что не вошло в circuit, приватным не становится.

FHE: вычисления над ciphertext

Полностью гомоморфное шифрование позволяет выполнять операции над зашифрованными данными без предварительной расшифровки. После расшифрования результата получается тот же результат, который был бы получен при вычислении над открытым текстом.

Для Web3 это потенциально полезно в сценариях, где узлы должны обработать данные, но не должны их видеть:

• приватные голосования;
• закрытые аукционы;
• кредитный скоринг;
• конфиденциальные ордера;
• вычисления над медицинскими или финансовыми атрибутами;
• приватные правила распределения наград;
• скрытые параметры игровых механик.

Протоколы и инфраструктурные проекты вроде Fhenix, Inco и Mind Network исследуют применение FHE в Web3 и L2-средах. Но утверждать, что FHE уже заменило обычное симметричное шифрование, нельзя. Оно решает другую задачу и имеет существенно более высокий вычислительный overhead.

AES оптимален, когда нужно зашифровать и расшифровать большие объемы данных. FHE нужно, когда вычисление над plaintext недопустимо даже для исполнителя. Это принципиально разные режимы.

Практически полезная архитектура часто выглядит гибридной:

• большие документы и записи шифруются AES;
• ключ AES сам шифруется или распределяется через threshold cryptography;
• ограниченные атрибуты представляются в FHE-форме;
• смарт-контракт или внешний исполнитель выполняет операции над ciphertext;
• результат проверяется через ZKP или криптографическую подпись;
• plaintext появляется только на доверенной конечной точке.

FHE особенно чувствительно к типу операций. Простые сложения и умножения поддерживаются естественнее, чем произвольные SQL-запросы, сортировки и сложные join-операции. Точный уровень производительности для произвольно сложных запросов в продакшен-масштабе нельзя считать установленным универсальным фактом. Для архитектуры это означает одно: сначала формулируется минимальный набор вычислений, затем оценивается конкретная схема. Не наоборот.

Где FHE оправдано

FHE имеет смысл, когда стоимость раскрытия данных выше стоимости вычислительного overhead. Например, в закрытом аукционе участник должен получить результат сравнения ставок, но не должен раскрыть свою ставку узлам. В простом CRUD-приложении применение FHE, скорее всего, будет архитектурным overengineering.

Перед внедрением нужно ответить на четыре вопроса:

1. Какие операции действительно должны выполняться над зашифрованными данными?

2. Можно ли вынести часть вычислений на клиент?

3. Допустима ли задержка генерации и обработки ciphertext?

4. Что произойдет при ошибке, потере ключа или недоступности вычислительных узлов?

Если ответы не формализованы, FHE добавляет сложность без доказанного выигрыша по модели угроз.

Гибридное хранение и выбор метода

Шифрование чувствительной информации в dapps редко строится вокруг одного примитива. Рабочая схема обычно сочетает несколько слоев:

• AES для bulk encryption;
• SHA-256 или другой хэш для контроля целостности;
• MPC и threshold cryptography для распределения ключевого доступа;
• ZKP для доказательства свойств без раскрытия данных;
• FHE для отдельных вычислений над ciphertext;
• multisig для критических административных операций;
• аппаратные защищенные среды или hardware wallet для ключевого материала.

У каждого слоя собственный объект защиты. Ошибка возникает, когда один механизм рекламируется как решение всех задач.

Практическая схема выбора

Для проектирования безопасности баз данных Web3 полезно идти от угрозы, а не от модного названия протокола.

1. Определить, что именно должно быть скрыто.

Поле, документ, связь между пользователем и записью, факт операции или только значение отдельного атрибута. Если скрывать требуется только значение, полное FHE для всей базы не нужно.

2. Оставить в блокчейне минимальный commitment.

Публичный слой должен подтверждать состояние, а не хранить персональный архив. Чем меньше раскрывается в calldata и событиях, тем ниже поверхность анализа.

3. Шифровать данные до отправки в хранилище.

Если plaintext видит оператор БД, RPC-провайдер или backend, end-to-end модель отсутствует.

4. Разделить ключи по области действия.

Один глобальный ключ для всех tenant и объектов — удобная точка отказа. Ротация и отзыв должны быть частью протокола, а не ручной процедурой.

5. Формализовать policy.

Условие доступа должно быть проверяемым: субъект, ресурс, операция, срок, контекст и способ отзыва.

6. Добавлять ZKP только для конкретного утверждения.

Сначала описывается statement и private witness, затем выбирается proving system. Иначе проект получает тяжелый circuit, который ничего существенного не скрывает.

7. Применять FHE там, где вычисление над открытым текстом действительно недопустимо.

Для хранения больших объектов AES почти всегда рациональнее.

8. Проверить метаданные.

Размеры объектов, частота запросов, адреса, временные интервалы и паттерны доступа могут деанонимизировать пользователя даже при идеальном шифровании содержимого.

9. Провести аудит клиентского кода.

Ключ может утечь не через криптографическую библиотеку, а через логи, local storage, telemetry, исключения, devtools или уязвимый dependency.

10. Проверить отказоустойчивость.

Распределенный ключевой менеджмент должен описывать recovery, ротацию узлов, потерю quorum и блокировку скомпрометированного участника.

Вердикт

Оптимальная архитектура шифрования баз данных в Web3 — не максимальное количество криптографических терминов, а минимально достаточная комбинация примитивов.

Для большинства dapp базовый стек выглядит так: шифрование данных на клиенте, AES-256 с корректной аутентификацией, отдельные ключи данных, распределенное управление доступом через threshold cryptography или MPC и публикация в блокчейне только хэша, commitment и политики. ZKP добавляется, когда требуется доказать свойство записи без раскрытия содержимого. FHE — когда нужно выполнять вычисления над ciphertext и бизнес-логика действительно оправдывает вычислительный overhead.

Главный технический вывод жесткий: децентрализованное хранение само по себе не дает приватности. Публичная база с зашифрованными отдельными полями все еще может раскрывать структуру поведения. ZKP не заменяет шифрование. Multisig не заменяет управление ключами. FHE не является универсальным AES с маркетинговым апгрейдом.

Сначала строится модель угроз. Затем определяется, что может оставаться публичным. После этого выбирается криптографический примитив и измеряется его overhead на реальной схеме данных. Любой другой порядок — не архитектура, а подбор модных аббревиатур под уже написанный контракт.