Чому важливо налаштувати шифрування даних криптопроекту?

Один незакомічений .env файл — і мільйони під загрозою. Потенційний збиток від витоку даних може сягати мільйонів доларів. Більшість Web3 проектів добре захищають смарт-контракти, але забувають про off-chain інфраструктуру, яка є attack surface. Приватні ключі, API секрети, KYC-документи, seed-фрази — все це потребує системного підходу. Ми налаштовуємо шифрування даних криптопроекту під ключ: від управління секретами до моніторингу інцидентів. Досвід наших інженерів у блокчейн-розробці — гарантія відсутності витоків. Зв'яжіться з нами, щоб оцінити ризики вашої інфраструктури.

Як забезпечити шифрування на всіх рівнях?

Управління секретами

80% інцидентів пов'язані з скомпрометованими обліковими даними. Базове правило: приватні ключі, 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-рівня. Секрети зберігаються зашифровано, доступ — через 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. Секрет монтується як файл, не потрапляє в environment variables (які часто логуються).

Шифрування приватних ключів

Чому HSM обов'язковий для signing ключів?

Для production підписуючих ключів (multisig, oracle, bridge) — HSM. Ключ ніколи не покидає пристрій, підпис виконується всередині. AWS CloudHSM / Google Cloud HSM підтримують secp256k1 (перевірте сумісність). HashiCorp Vault також може використовувати HSM як backend.

Nitro Enclaves (AWS) — віртуальна ізоляція: enclave не має постійного storage та network доступу. Навіть root на хост-машині не отримає доступ до даних всередині.

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 ); // Зберегти encrypted JSON, не приватний ключ // Розшифровка при старті застосунку const wallet = await ethers.Wallet.fromEncryptedJson( keystoreJson, process.env.KEYSTORE_PASSWORD! ); 

Keystore пароль — теж секрет. Зберігаємо в Vault або Secrets Manager.

Шифрування користувацьких даних (KYC та PII)

Якщо проект зберігає KYC-документи — вони підпадають під GDPR. Мінімальні вимоги:

• Encryption at rest: AES-256-GCM для даних в БД. KMS для управління ключами.
• Encryption in transit: TLS 1.3 скрізь, cert pinning для мобільних застосунків.
• Data minimization: зберігати лише хеш документа та статус, не сам документ.

-- Шифрування в PostgreSQL через pgcrypto INSERT INTO kyc_data (user_id, encrypted_document_hash, verified_at) VALUES ($1, pgp_sym_encrypt($2, current_setting('app.encryption_key')), NOW()); 

Шифрування даних в 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 з мінімальними дозволами.

RPC endpoint безпека

Публічний RPC — вектор атаки. Alchemy/Infura ключі ротуйте, використовуйте allowlists по origin. Власна RPC нода (geth/erigon) в private subnet — краще. Доступ лише через внутрішні сервіси.

Моніторинг та алертинг

OpenZeppelin Defender Sentinel моніторить on-chain події, надсилає алерти при аномальних транзакціях з privileged адрес. Forta — децентралізований моніторинг з community detection agents. Налаштування займає 1-2 тижні, але дає критичну видимість для реагування.

На одному з наших проєктів ми виявили, що 3 з 5 секретів зберігалися в репозиторії. Після впровадження HashiCorp Vault та ротації ключів ризик було усунуто за 2 тижні, а подальші інциденти припинилися.

Що входить в роботу при замовленні налаштування шифрування?

1. Аудит поточної інфраструктури: оцінка ризиків, виявлення витоків, рекомендації.
2. Проєктування архітектури: вибір менеджера секретів, HSM, схеми шифрування.
3. Впровадження: розгортання Vault/HSM, налаштування ротації ключів, інтеграція з застосунками.
4. Документація: схема інфраструктури, інструкції з ротації, політики безпеки.
5. Навчання команди: воркшоп з роботи з секретами та реагування на інциденти.
6. Підтримка: моніторинг, алертинг, планова ротація.

Повне налаштування шифрування для production криптопроекту — 3-6 тижнів залежно від обсягу інфраструктури. Для оцінки ризиків зв'яжіться з нами — отримайте консультацію за 2-3 дні.