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

Один незакомічений .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 дні.

Аудит смарт-контрактів: як знаходять те, що не бачить компілятор

Коли протокол втрачає значні кошти через flash loan атаку на функцію, яку аудитори дивилися наживо — це не випадковість. Це системна прогалина в методології. Наш досвід показує: вразливість живе в контракті більше року, а компілятор мовчить. Ми перебудували процес аудиту так, щоб ловити такі кейси до деплою.

Що не знайде статичний аналіз?

Slither — стандартний перший інструмент. Знаходить reentrancy, integer overflow (в старих версіях Solidity), неправильне використання tx.origin, shadowing змінних, неініціалізовані сховища. На реальному проекті Slither видає десятки попереджень, з яких критичних — 0‑2. Решта — інформаційний шум.

Slither не знайде логічну вразливість. Якщо withdraw коректно перевіряє баланс і коректно оновлює стан, але бізнес-логіка дозволяє подвійне списання через два різні шляхи кодової бази — Slither промовчить.

Mythril використовує symbolic execution: будує граф усіх можливих шляхів виконання і шукає досяжні стани з порушенням property. Працює добре на ізольованих контрактах. На протоколі з 20 контрактів з cross‑contract викликами — path explosion, аналіз зависає або видає false positive.

Обидва інструменти обов'язкові як перший pass. Але вони не замінюють ручний аналіз.

Fuzzing: де Echidna та Foundry знаходять реальні баги?

Echidna — property‑based fuzzer від Trail of Bits. Ідея: формулюєш інваріанти контракту як Solidity‑функції (echidna_invariant), Echidna генерує випадкові послідовності викликів і намагається зламати інваріант.

Приклад інваріанта для lending протоколу:

function echidna_total_assets_ge_liabilities() public view returns (bool) {
    return totalAssets() >= totalLiabilities();
}

Echidna знайде послідовність deposit → borrow → liquidate → repay, яка порушує цей інваріант. Руками такий кейс не побудуєш — комбінацій занадто багато.

Foundry fuzzing (forge test --fuzz-runs 100000) простіший в інтеграції, якщо команда вже на Foundry. Підтримує stateful fuzzing через invariant тести. В реальному проекті: auditing vault контракт, Foundry fuzz за 40 хвилин знайшов edge case, при якому maxWithdraw повертав значення більше фактичного балансу при конкретному співвідношенні shares/assets після кількох донатів. Hardhat unit‑тести цей кейс пропускали — там не було такої комбінації параметрів.

Medusa (від Trail of Bits, новіша за Echidna) підтримує corpus‑guided fuzzing і працює швидше на великих контрактах. Якщо обсяг кодової бази > 5000 рядків Solidity — дивимося на Medusa.

Як інваріанти допомагають виявити критичні уразливості?

Формальна верифікація доводить, що контракт задовольняє специфікації для всіх можливих вхідних даних — не для N випадкових, а математично для всіх. Інструменти: Certora Prover, K Framework, Halmos.

Certora працює з CVL (Certora Verification Language): пишеш rules і invariants, Prover транслює їх у SMT‑формули і перевіряє через Z3/CVC5. MakerDAO, Aave, Uniswap використовують Certora в CI/CD pipeline — кожен PR верифікується автоматично.

Обмеження: не працює з необмеженими циклами, складно справляється з hash functions і signature verification. Для контрактів з простою математикою (AMM, lending) — відмінно. Для контрактів з довільними зовнішніми викликами — складно написати достатньо повну специфікацію.

Formal verification має сенс для контрактів, які: керують значним TVL, оновлюються рідко, мають чітко формалізовані інваріанти. Для продуктів, що швидко ітеруються, співвідношення витрат і користі не на користь верифікації.

Вектори атак, які пропускають джуніор‑аудитори

Storage collision в proxy патерні. Transparent proxy і UUPS використовують конкретні слоти для зберігання адреси імплементації (EIP‑1967). Якщо в імплементації випадково оголошена змінна в слоті 0, яка перетинається з proxy storage — отримуємо silent override. Slither це не впіймає, якщо proxy та імплементація в різних файлах.

Read‑only reentrancy. Класичний reentrancy guard захищає від зміни стану при рекурсивному виклику. Але якщо зовнішній контракт читає стан через view-функцію в середині транзакції — guard не допомагає. Кілька років тому Curve pools стали вектором атаки саме через це: зовнішній протокол читав get_virtual_price під час reentrancy‑вразливого стану Curve.

Oracle manipulation через TWAP. Spot price — стандартна ціль для flash loan атаки. TWAP складніше маніпулювати, але не неможливо: на малоліквідних парах Uniswap v2 можна зсунути TWAP за кілька блоків при достатньому капіталі. Правильний захист — використовувати Chainlink як primary oracle з TWAP як fallback, з перевіркою deviation threshold.

Gas griefing на unbounded loop. Функція ітерується по масиву користувачів. Атакуючий додає тисячі адрес з нульовими балансами — вартість виклику функції зростає до gas limit, функція стає недоступною. Захист: pull‑pattern замість push, обмеження довжини масивів, batch‑обробка зі збереженням позиції.

Front‑running на MEV. Транзакція видна в mempool до включення в блок. MEV‑бот бачить addLiquidity на значну суму, вставляє свій swap перед нею (sandwich attack). Для AMM це частина моделі. Для протоколів з ціновими функціями — потрібен minAmountOut / deadline параметр і його обов'язкова перевірка.

Структура повного аудиту

1. Scope definition і автоматичний аналіз (1‑2 дні). Фіксуємо commit hash, версію компілятора, список out‑of‑scope. Запускаємо Slither, Mythril, Aderyn. Triage: відокремлюємо реальні критичні баги від false positive. Складаємо карту залежностей контрактів.

2. Ручний аналіз (5‑15 днів). Кожен контракт порядково. Особлива увага: всі external і public функції, всі transfer/call/delegatecall, всі місця, де змінюється стан перед перевіркою або після зовнішнього виклику, всі математичні операції з участю користувацьких inputs. В середньому 95% знайдених уразливостей — логічні, а не технічні.

3. Fuzzing і тестування (2‑5 днів). Echidna або Foundry invariant tests для критичних інваріантів. Fork mainnet тести — перевіряємо поведінку в реальному оточенні з реальними оракулами. Наприклад, за 4 дні fuzzing знаходить в середньому 3 edge cases, не покритих unit‑тестами.

4. Звіт і мітигація. Звіт з severity (Critical/High/Medium/Low/Informational), описом вектора атаки, PoC‑кодом для Critical/High. Розробники виправляють, аудитори роблять re‑audit виправлень.

Аудит у CI/CD

Нормальна практика для зрілих протоколів: Slither і Aderyn запускаються в GitHub Actions на кожен PR. Certora Prover — на merge в main. Це не замінює повний аудит перед деплоєм, але ловить регресії.

# .github/workflows/audit.yml
- name: Run Slither
  uses: crytic/[email protected]
  with:
    target: 'src/'
    slither-args: '--filter-paths "test|mock|script"'

Інструменти аудиту: порівняння

Що входить в роботу (deliverables)

• Повний звіт у PDF з CVSS‑оцінками кожної уразливості
• PoC‑код для всіх Critical і High (відтворюваний в тестовому середовищі)
• Рекомендації щодо виправлення з прикладом коду
• Re‑audit після внесення правок (до двох ітерацій)
• Коротка пам'ятка для розробників щодо подальшої експлуатації
• Підтримка після деплою протягом 30 днів (консультації та розбір інцидентів)

Терміни

Аудит простого токена або NFT‑контракту — 3‑5 робочих днів. DeFi протокол з lending/AMM — 2‑4 тижні. Повний стек з кількома протоколами, cross‑chain, proxy upgrades — 4‑8 тижнів. Re‑audit виправлень — 3‑7 днів окремо.

Наша команда має 7+ років досвіду в безпеці смарт‑контрактів, перевірила 100+ проектів з сумарним TVL понад значну суму. Гарантуємо, що в процесі ми не пропустимо жоден відомий вектор — використовуємо ліцензовані версії Slither та найкращі конфігурації fuzzer'ів. Запобігнуті збитки для клієнтів оцінюються в значну суму.

Оцініть ваш проект — ми безкоштовно проаналізуємо код і запропонуємо комерційну пропозицію протягом 2 днів. Замовте аудит з гарантією якості та отримайте знижку на re‑audit при повторному зверненні.