Настройка шифрования данных криптопроекта
Большинство Web3 проектов хорошо думают о безопасности смарт-контрактов и плохо — о безопасности off-chain инфраструктуры. Приватные ключи, API секреты, пользовательские данные, seed фразы, ключи шифрования бэкапов — всё это создаёт attack surface, который нужно закрывать системно, а не по принципу «авось не взломают».
Управление секретами
Никаких секретов в коде
Базовое правило, которое нарушается удивительно часто. Приватный ключ, RPC endpoint с API key, Telegram bot token в .env файле, захарденный в репозиторий — это утечка данных. GitHub scanning (официальный, Gitleaks, Trufflehog) регулярно находит подобные случаи в публичных репозиториях.
# Gitleaks: проверка репозитория на утечки секретов
gitleaks detect --source . --verbose
# Или как pre-commit hook
gitleaks protect --staged
HashiCorp Vault
Для production-уровня управления секретами — HashiCorp Vault. Секреты хранятся зашифровано, доступ — через dynamic secrets с TTL, аудит-лог каждого обращения.
# Получение секрета через Vault CLI
vault kv get -field=private_key secret/blockchain/signer
# В приложении: динамический токен с коротким TTL
vault token create -policy="blockchain-signer" -ttl=1h
Для приложений в Kubernetes — Vault Agent Injector или External Secrets Operator. Секрет монтируется как файл в pod, не попадает в environment variables (которые логируются).
AWS Secrets Manager / GCP Secret Manager
Для cloud-native инфраструктуры — cloud-native secret managers. Автоматическая ротация, интеграция с IAM, шифрование через KMS.
import boto3
def get_private_key():
client = boto3.client('secretsmanager', region_name='us-east-1')
response = client.get_secret_value(SecretId='blockchain/signer-key')
return response['SecretString']
Ротация ключей: для подписывающих ключей — ротация через смену адреса в контракте (multisig или governance). Для API keys — автоматическая через Secrets Manager rotation lambda.
Шифрование приватных ключей
Hardware Security Modules (HSM)
Для production подписывающих ключей (multisig участники, oracle операторы, bridge операторы) — HSM. Ключ никогда не покидает HSM в открытом виде, подпись выполняется внутри устройства.
AWS CloudHSM / Google Cloud HSM: облачные HSM с поддержкой secp256k1 (не всегда нативно — нужна проверка). Hashicorp Vault также может использовать HSM как backend.
Nitro Enclaves (AWS): виртуальная изоляция для sensitive операций. Enclave не имеет постоянного storage, не имеет network доступа кроме специального канала. Даже root на хост-машине не может получить доступ к данным в enclave.
Keystore шифрование
Для менее критичных ключей (hot wallets с лимитами) — EIP-55 keystore формат:
// ethers.js: создание зашифрованного keystore
const wallet = ethers.Wallet.createRandom();
const encrypted = await wallet.encrypt(
process.env.KEYSTORE_PASSWORD!,
{
scrypt: { N: 131072, r: 8, p: 1 } // высокий cost factor для production
}
);
// Сохранить encrypted JSON, НЕ приватный ключ
// Расшифровка при старте приложения
const wallet = await ethers.Wallet.fromEncryptedJson(
keystoreJson,
process.env.KEYSTORE_PASSWORD!
);
Keystore пароль — тоже секрет. Храним в Vault или Secrets Manager, не в env файле.
Шифрование пользовательских данных
KYC и PII данные
Если проект хранит KYC данные (паспорта, адреса) — они подпадают под GDPR и аналоги. Минимальные требования:
Encryption at rest: AES-256-GCM для данных в БД. В PostgreSQL — pgcrypto или column-level encryption через приложение. KMS для управления ключами шифрования.
Encryption in transit: TLS 1.3 везде. Cert pinning для мобильных приложений. HSTS для web.
Data minimization: хранить только то, что необходимо. Если KYC проверен — хранить только хэш документа и статус, не сам документ.
-- Шифрование чувствительных полей в PostgreSQL через pgcrypto
CREATE EXTENSION IF NOT EXISTS pgcrypto;
-- Вставка зашифрованных данных
INSERT INTO kyc_data (user_id, encrypted_document_hash, verified_at)
VALUES (
$1,
pgp_sym_encrypt($2, current_setting('app.encryption_key')),
NOW()
);
-- Чтение
SELECT pgp_sym_decrypt(encrypted_document_hash, current_setting('app.encryption_key'))
FROM kyc_data WHERE user_id = $1;
End-to-end шифрование для messaging
Если протокол включает messaging (P2P коммуникации, DAO discussions) — E2EE через libsodium или ECIES (Elliptic Curve Integrated Encryption Scheme) с ключами, деривированными от Ethereum приватных ключей.
XMTP протокол делает именно это — E2EE messaging между Ethereum адресами. Интеграция через @xmtp/xmtp-js SDK.
Шифрование данных в IPFS
IPFS — публичная сеть. Всё загруженное доступно всем. Для приватных данных с IPFS хранением — шифрование перед загрузкой:
import { create } from 'ipfs-http-client';
import { box, randomBytes } from 'tweetnacl';
import { encodeBase64 } from 'tweetnacl-util';
async function uploadEncrypted(data: Uint8Array, recipientPublicKey: Uint8Array) {
const nonce = randomBytes(box.nonceLength);
const { publicKey, secretKey } = box.keyPair();
// Шифруем для получателя
const encrypted = box(data, nonce, recipientPublicKey, secretKey);
const payload = {
nonce: encodeBase64(nonce),
ephemeralPublicKey: encodeBase64(publicKey),
ciphertext: encodeBase64(encrypted)
};
const ipfs = create({ url: 'https://ipfs.infura.io:5001' });
const result = await ipfs.add(JSON.stringify(payload));
return result.cid.toString();
}
Infrastructure Security
Сетевая изоляция
Signing ноды, bridge операторы, oracle ноды — не должны быть публично доступны. VPC с private subnets, security groups с минимальными разрешениями.
Public subnet: Load Balancer, API gateway
Private subnet: Application servers, RPC nodes
Isolated subnet: Signing services, key management
RPC endpoint безопасность
Публичный RPC — вектор атаки. Alchemy/Infura ключи нужно ротировать, использовать allowlists по origin, мониторить аномальные запросы.
Собственная RPC нода (geth/erigon) в private subnet — лучше для production. Доступ только через внутренние сервисы.
Мониторинг и алертинг
OpenZeppelin Defender Sentinel: мониторинг on-chain событий, алерт при аномальных транзакциях из privileged адресов.
Forta: децентрализованный мониторинг, community detection agents для известных атак.
Настройка занимает 1-2 недели, но даёт критическую видимость для реагирования на инциденты.
Полная настройка шифрования для production криптопроекта — 3-6 недель в зависимости от объёма инфраструктуры и требований compliance.