Настройка шифрування даних криптопроекту
Більшість 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.
Шифрування приватних ключів
Апаратні модулі безпеки (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 подій, алерт при аномальних транзакціях із привільованих адрес.
Forta: децентралізований мониторинг, community detection agents для відомих атак.
Настройка займає 1-2 тижні, але дає критичну видимість для реагування на інциденти.
Повна настройка шифрування для production криптопроекту — 3-6 тижнів залежно від обсягу інфраструктури та вимог compliance.