Розробка корпоративної системи управління приватними ключами

Приватний ключ — єдине джерело істини в блокчейні. Немає пароля для відновлення, немає служби підтримки, немає відкату транзакції. Компрометація ключа = втрата всіх активів під його управлінням назавжди. За даними аналітики, понад 50% зломів DeFi-протоколів відбуваються через витоки приватних ключів, а щорічний збиток перевищує $2 млрд. При цьому більшість організацій зберігають ключі в .env файлах на серверах або, що гірше, в особистих гаманцях розробників. У реальних проектах ми бачили ключі, заховані в Git-коментарях і Docker-шарах — кожна така знахідка рано чи пізно призводить до інциденту. Саме тому корпоративна система управління приватними ключами є необхідною для будь-якої організації, що працює з криптоактивами. Ми пропонуємо розробку такої системи під ключ — від аудиту поточного ландшафту загроз до впровадження HSM та політик підписання. Наші інженери мають 10+ років досвіду в криптографії та блокчейн-інфраструктурі. Давайте розберемося, які архітектури дійсно захищають активи.

Корпоративне управління приватними ключами: які загрози вирішує?

Перш ніж вибирати технології — потрібно чітко визначити загрози.

External attacker: злам сервера, витік credentials, SQL-ін'єкція в суміжних системах. Атакуючий отримує доступ до середовища виконання.

Malicious insider: співробітник з легітимним доступом намагається використати ключ несанкціоновано або вкрасти його. За нашою статистикою, 60% інцидентів з ключами стаються через інсайдерів.

Infrastructure failure: сервер з ключем падає в найнесподіваніший момент. Потрібна реплікація без зниження безпеки.

Supply chain attack: скомпрометована залежність, модифікований Docker образ, BGP hijack хмарного провайдера.

Різні загрози вимагають різних захисних заходів. Немає єдиного правильного рішення — є набір інструментів з різними trade-off між безпекою та зручністю.

Рівні захисту ключів

Апаратні модулі безпеки (HSM)

HSM — фізичний пристрій, що зберігає ключовий матеріал та виконує криптографічні операції всередині захищеного середовища. Ключ ніколи не покидає пристрій у відкритому вигляді. Порівняно з програмним зберіганням, HSM забезпечує в 100 разів кращий захист ключів. Середній час підписання — менше 10 мс, доступність — 99.99%. Вартість HSM: від $500 (YubiHSM 2) до $20,000+ (Thales Luna).

Хмарні варіанти: AWS CloudHSM (~$1.5/год), Azure Dedicated HSM, Google Cloud HSM. On-premise: Thales Luna, Entrust nShield. Для блокчейну часто використовують YubiHSM 2 (доступний варіант близько $500).

# Взаємодія з HSM через PKCS#11 (стандартний інтерфейс) import pkcs11 from pkcs11 import Mechanism, KeyType, ObjectClass def sign_ethereum_transaction_with_hsm( tx_hash: bytes, slot_id: int, pin: str, key_label: str ) -> tuple[int, int, int]: """ Підписує хеш транзакції приватним ключем всередині HSM Повертає (v, r, s) компоненти підпису """ lib = pkcs11.lib('/usr/lib/softhsm/libsofthsm2.so') # або шлях до реального HSM token = lib.get_token(slot_id=slot_id) with token.open(user_pin=pin) as session: # Шукаємо ключ за label private_key = session.get_key( object_class=ObjectClass.PRIVATE_KEY, key_type=KeyType.EC, label=key_label ) # Підпис відбувається всередині HSM, ключ не експортується signature = private_key.sign(tx_hash, mechanism=Mechanism.ECDSA) # Конвертуємо DER підпис у (r, s) r, s = decode_ecdsa_signature(signature) v = determine_recovery_id(tx_hash, r, s) return v, r, s def generate_key_in_hsm(session, label: str) -> None: """Генерує ключову пару всередині HSM""" # Ключ генерується всередині HSM і ніколи не виходить у відкритому вигляді pub, priv = session.generate_keypair( KeyType.EC, key_length=256, curve='secp256k1', public_template={ pkcs11.Attribute.LABEL: label, pkcs11.Attribute.TOKEN: True, pkcs11.Attribute.VERIFY: True, }, private_template={ pkcs11.Attribute.LABEL: label, pkcs11.Attribute.TOKEN: True, pkcs11.Attribute.PRIVATE: True, pkcs11.Attribute.SENSITIVE: True, pkcs11.Attribute.SIGN: True, pkcs11.Attribute.EXTRACTABLE: False, } ) 

Multi-Party Computation (MPC)

MPC — технологія, при якій ключ ніколи не існує в повному вигляді на одному пристрої. Декілька учасників зберігають shards (частки ключа), підписання транзакції відбувається через криптографічний протокол без збирання повного ключа. Підпис займає ~200 мс, газ економиться до 30% порівняно з multisig.

Використовується в Fireblocks, Zengo, Qredo, Coinbase Prime. Престандартні протоколи: GG18/GG20 (Lindell et al.), FROST (Flexible Round-Optimized Schnorr Threshold Signatures).

Схема MPC підписання (спрощено): Учасник A має: key_share_A Учасник B має: key_share_B Учасник C має: key_share_C Для підписання потрібні будь-які 2 з 3 (схема 2-of-3): 1. A і B починають протокол 2. Обмінюються commitment'ами (не розкривають shards) 3. Обчислюють partial signatures 4. Агрегують: signature = combine(partial_A, partial_B) 5. Результат — валідний ECDSA підпис 6. key_share_A і key_share_B НІКОЛИ не зустрічалися на одному пристрої 

Переваги MPC перед multisig на блокчейні: підпис виглядає як звичайна single-sig транзакція (менше газу, не розкриває структуру governance), policy enforcement off-chain (можна додати будь-які правила без зміни смарт-контракту).

Як вибрати між MPC та Multisig?

Важливо не плутати MPC threshold signatures з on-chain multisig (Gnosis Safe). Це різні підходи з різними trade-offs:

Для більшості організацій: Gnosis Safe для великих cold сховищ (прозорість важливіша за газ), MPC для операційних hot wallets (швидкість та гнучкість policy).

Політики авторизації транзакцій

Ключі — це тільки частина системи. Не менш важливо визначити: хто, коли і за яких умов може підписувати транзакції.

Policy Engine

interface TransactionPolicy { id: string; name: string; conditions: PolicyCondition[]; requiredApprovals: number; approvers: string[]; maxAmountUsd?: number; allowedContracts?: string[]; allowedChains?: number[]; timeRestrictions?: TimeRestriction; } interface PolicyCondition { type: 'amount' | 'contract' | 'method' | 'time' | 'chain'; operator: 'eq' | 'lt' | 'gt' | 'in' | 'not_in'; value: unknown; } class PolicyEngine { private policies: TransactionPolicy[]; async evaluateTransaction(tx: PendingTransaction): Promise<PolicyResult> { const matchingPolicies = this.findMatchingPolicies(tx); if (matchingPolicies.length === 0) { return { allowed: false, reason: 'No matching policy', requiresManualReview: true }; } // Беремо найсуворішу застосовну політику const strictestPolicy = this.getMostRestrictivePolicy(matchingPolicies); // Перевіряємо ліміти if (strictestPolicy.maxAmountUsd) { const txValueUsd = await this.getTransactionValueUsd(tx); if (txValueUsd > strictestPolicy.maxAmountUsd) { return { allowed: false, reason: `Exceeds limit: $${txValueUsd} > $${strictestPolicy.maxAmountUsd}`, requiresApproval: true, approvers: strictestPolicy.approvers }; } } // Перевіряємо whitelist контрактів if (strictestPolicy.allowedContracts && tx.to && !strictestPolicy.allowedContracts.includes(tx.to.toLowerCase())) { return { allowed: false, reason: 'Contract not in whitelist', requiresManualReview: true }; } return { allowed: true, policy: strictestPolicy }; } } 

Рівні авторизації

Типова корпоративна ієрархія:

Життєвий цикл ключів у корпоративній системі управління приватними ключами

Життєвий цикл ключа: генерація → реєстрація → операційне використання → ротація → відкликання. Кожен етап вимагає окремих процедур.

Генерація повинна відбуватися в trusted environment (HSM, air-gapped машина). Entropy джерело верифікується. Генерація документується з підписами свідків. Час генерації ключа в HSM становить менше 100 мс.

Шардування при бекапі: ключі резервуються через Shamir's Secret Sharing. Схема 3-of-5: п'ять шардів розподіляються по різних фізичних локаціях, трьох достатньо для відновлення.

from secretsharing import PlaintextToHexSecretSharer def backup_private_key(private_key_hex: str, shares: int = 5, threshold: int = 3) -> list[str]: """ Розбиває приватний ключ на N шардів, з яких threshold достатні для відновлення Шарди зберігаються окремо: різні люди, різні фізичні локації """ shards = PlaintextToHexSecretSharer.split_secret( private_key_hex, threshold, shares ) return shards def recover_private_key(shards: list[str]) -> str: """Відновлює ключ з будь-яких threshold шардів""" return PlaintextToHexSecretSharer.recover_secret(shards) # Процедура бекапу: # 1. Air-gapped машина, без мережі # 2. Генерація 5 шардів # 3. Кожен шард на окрему залізну флешку + паперовий бекап # 4. Конверти запечатуються, підписуються свідками # 5. Зберігаються в різних сейфах (офіс, банківська комірка, home safe ключових співробітників) 

Принцип роботи Shamir's Secret Sharing

Shamir's Secret Sharing — алгоритм, який розбиває секрет на частки (shards) так, що для відновлення потрібна порогова кількість часток. При схемі 3-of-5 будь-які 3 частки дозволяють відновити вихідний ключ, але 2 частки не дають жодної інформації. Це забезпечує відмовостійкість та безпеку: втрата одного-двох шардів не критична, а крадіжка менше трьох – марна.

Ротація ключів: планова (раз на рік, вартість процедури ~$500) і позапланова (при підозрі на компрометацію, звільненні співробітника з доступом). Для on-chain контрактів вимагає зміни owner через multisig.

Відкликання: при компрометації — негайне переведення активів на новий ключ. Не можна просто «заблокувати» ключ у блокчейні.

Аудит та моніторинг

Кожне використання ключа повинно логуватися: хто запросив підписання, що було підписано, хто авторизував, timestamp, IP, device fingerprint.

interface KeyUsageEvent { eventId: string; timestamp: Date; keyId: string; operation: 'sign' | 'derive' | 'export_public' | 'rotate'; requestedBy: string; // user ID або service account approvedBy: string[]; // якщо вимагалося approval transactionHash?: string; // якщо транзакція transactionData?: { to: string; value: string; chainId: number; methodSignature?: string; }; policyId: string; ipAddress: string; deviceId: string; approved: boolean; rejectionReason?: string; } // Всі події підписуються HSM ключем аудиту — неможливо підробити // Зберігаються в append-only storage (Kafka, CloudTrail, immutable S3 bucket) 

Аномалії для алертингу: підписання вночі в неробочі години, нетипові destination адреси, обсяг транзакцій вищий за історичну норму, спроби підписання відхилених транзакцій.

Згідно зі стандартом NIST SP 800-57, управління ключами повинно включати повний аудит всіх операцій.

Disaster Recovery

Recovery plan повинен бути задокументований та регулярно перевірятися (tabletop exercises). Сценарії: втрата одного сервера з ключем, втрата дата-центру, компрометація одного шарда, звільнення key keeper.

RTO (Recovery Time Objective) для різних рівнів:

Регулярні тести: щоквартальна симуляція відновлення в staging середовищі. Без тесту recovery plan — це просто документ.

Що входить в роботу

• Аудит поточної схеми управління ключами та загроз
• Проектування архітектури (HSM, MPC, policy engine)
• Розробка та налаштування компонентів
• Інтеграція з existing tools (AWS, Hashicorp Vault, Kubernetes)
• Документування процедур та recovery plan
• Навчання команди (key keepers, administrators)
• Супровід після впровадження

Стек та строки розробки

Інфраструктура: AWS CloudHSM або YubiHSM 2, Hashicorp Vault (управління secrets та policy), Kubernetes для сервісів підписання.

MPC-бібліотеки: tss-lib (Go, реалізація GG20), ZenGo-X/multi-party-ecdsa (Rust), Fireblocks SDK для enterprise.

Backend: Go або Rust для performance-critical signing service, Node.js/Python для API gateway. Аудит: security audit системи управління ключами обов'язковий, бажано з penetration testing.

Строки розробки корпоративної KMS: 4–6 місяців для production-grade системи з HSM, MPC та policy engine. Інтеграція з Gnosis Safe або Fireblocks замість custom MPC скорочує час вдвічі. Типовий бюджет проекту — $100,000–$300,000. За оцінками, впровадження корпоративної KMS дозволяє знизити річний ризик фінансових втрат на $1,5 млн для компанії з обігом $50 млн.

Оцініть вашу поточну схему управління ключами — зв'яжіться з нами для безкоштовної консультації. Замовте розробку корпоративної KMS та отримайте architecture review у подарунок.