פיתוח מערכת ניהול מפתחות פרטיים ארגונית

המפתח הפרטי הוא מקור האמת היחיד בבלוקצ'יין. אין סיסמת שחזור, אין מוקד תמיכה, אין אפשרות להחזיר עסקה. פגיעה במפתח = אובדן קבוע של כל הנכסים שבשליטתו. לפי נתונים אנליטיים, מעל 50% מהפריצות לפרוטוקולי DeFi נובעות מדליפת מפתחות פרטיים, כשהנזק השנתי עולה על 2 מיליארד דולר. ובכל זאת, רוב הארגונים מאחסנים מפתחות בקבצי # Взаимодействие с 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, } ) על שרתים או, גרוע מכך, בארנקים אישיים של מפתחים. בפרויקטים אמיתיים ראינו מפתחות חבויים בתגובות Git ובשכבות Docker — כל ממצא כזה מוביל בסופו של דבר לאירוע. אנו מציעים פיתוח מקצה-לקצה של מערכת ניהול מפתחות ארגונית — מסקר איומי הסייבר הנוכחיים ועד פריסת HSM ומדיניות חתימה. למהנדסים שלנו יש ניסיון של 10+ שנים בקריפטוגרפיה ובתשתיות בלוקצ'יין. בואו נבחן אילו ארכיטקטורות באמת מגנות על נכסים.

מאילו איומים ניהול מפתחות ארגוני מגן?

לפני בחירת טכנולוגיות, צריך להגדיר בבירור את האיומים.

• תוקף חיצוני: פריצה לשרת, דליפת פרטי התחברות, SQL injection במערכות סמוכות. התוקף מקבל גישה לסביבת ההרצה.
• עובד זדוני: עובד עם גישה לגיטימית מנסה להשתמש במפתח ללא הרשאה או לגנוב אותו.
• כשל תשתית: השרת עם המפתח נופל ברגע הכי גרוע. נדרשת שכפול ללא פגיעה באבטחה.
• מתקפת שרשרת אספקה: תלות שנפרצה, תמונת Docker ששונתה, חטיפת BGP על ידי ספק הענן.

איומים שונים דורשים אמצעי הגנה שונים. אין פתרון יחיד ונכון — יש סט כלים עם פשרות שונות בין אבטחה לנוחות.

רמות הגנה על מפתחות

מודולי אבטחה חומרתיים (HSM)

HSM הוא התקן פיזי שמאחסן חומר מפתח ומבצע פעולות קריפטוגרפיות בתוך מתחם חסין חבלה. המפתח לעולם לא עוזב את ההתקן בטקסט גלוי. HSM מספק הגנה חזקה פי 100 מפני חילוץ מפתחות בהשוואה לאחסון תוכנתי. זמן החתימה הממוצע הוא פחות מ-10 אלפיות השנייה, והזמינות היא 99.99%.

אפשרויות ענן: AWS CloudHSM, Azure Dedicated HSM, Google Cloud HSM. מקומי: 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,
        }
    )

חישוב רב-צדדי (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 רגילה (פחות גז, לא חושפת את מבנה הניהול), ואכיפת מדיניות מחוץ לרשת (ניתן להוסיף כללים ללא שינוי בחוזה החכם).

איך לבחור בין MPC ל-Multisig

חשוב לא לבלבל בין חתימות סף של MPC לבין multisig על-רשת (Gnosis Safe). אלה גישות שונות עם פשרות שונות:

לרוב הארגונים: Gnosis Safe לאחסון קר גדול (שקיפות חשובה יותר מגז), MPC לארנקים חמים תפעוליים (מהירות וגמישות מדיניות).

מדיניות הרשאת עסקאות

מפתחות הם רק חלק מהמערכת. חשוב לא פחות להגדיר מי יכול לחתום על עסקאות, מתי, ובאילו תנאים.

מנוע מדיניות

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 };
  }
}

רמות הרשאה

היררכיה ארגונית טיפוסית:

ניהול מחזור חיי מפתח

מחזור חיי מפתח: יצירה → רישום → שימוש תפעולי → רוטציה → ביטול. כל שלב דורש נהלים נפרדים.

היצירה חייבת להתבצע בסביבה מהימנה (HSM, מכונה מנותקת). מקור האנטרופיה מאומת. היצירה מתועדת עם חתימות עדים.

פיצול גיבוי: מפתחות מגובים באמצעות Shamir's Secret Sharing. סכימת 3-מתוך-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-מתוך-5, כל 3 חלקים מאפשרים לשחזר את המפתח המקורי, אבל 2 חלקים לא מספקים מידע. זה מספק סובלנות לתקלות ואבטחה: אובדן של חלק אחד או שניים אינו קריטי, וגניבה של פחות משלושה חסרת תועלת.

רוטציית מפתח: מתוכננת (פעם בשנה) ולא מתוכננת (חשד לפגיעה, עובד עם גישה עוזב). עבור חוזים על-רשת, דורש שינוי בעלים באמצעות multisig.

ביטול: במקרה של פגיעה, העברה מיידית של נכסים למפתח חדש. אי אפשר פשוט "לחסום" מפתח בבלוקצ'יין.

ביקורת וניטור

כל שימוש במפתח חייב להיות מתועד: מי ביקש חתימה, על מה נחתם, מי אישר, חותמת זמן, IP, טביעת אצבע של התקן.

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)

חריגות להתראה: חתימה מחוץ לשעות העבודה, כתובות יעד לא טיפוסיות, נפח עסקאות מעל הנורמה ההיסטורית, ניסיונות לחתום על עסקאות שנדחו.

לפי תקן NIST SP 800-57, ניהול מפתחות חייב לכלול ביקורת מלאה של כל הפעולות.

שחזור מאסון

תוכנית שחזור חייבת להיות מתועדת ונבדקת באופן קבוע (תרגילי שולחן). תרחישים: אובדן שרת אחד עם מפתח, אובדן מרכז נתונים, פגיעה בחלק אחד, עזיבת שומר מפתח.

RTO (זמן שחזור יעד) לרמות שונות:

בדיקות קבועות: סימולציית שחזור רבעונית בסביבת staging. ללא בדיקות, תוכנית שחזור היא רק מסמך.

מה כלול בעבודה

• ביקורת של תוכנית ניהול המפתחות הנוכחית וסקר איומים
• עיצוב ארכיטקטורה (HSM, MPC, מנוע מדיניות)
• פיתוח והגדרה של רכיבים
• אינטגרציה עם כלים קיימים (AWS, Hashicorp Vault, Kubernetes)
• תיעוד נהלים ותוכנית שחזור
• הדרכת צוות (שומרי מפתחות, מנהלים)
• תמיכה לאחר פריסה

טכנולוגיות וזמן פיתוח

תשתית: AWS CloudHSM או YubiHSM 2, Hashicorp Vault (ניהול סודות ומדיניות), Kubernetes לשירותי חתימה.

ספריות MPC: tss-lib (Go, יישום GG20), ZenGo-X/multi-party-ecdsa (Rust), Fireblocks SDK לארגונים.

צד שרת: Go או Rust לשירות חתימה רגיש לביצועים, Node.js/Python לשער API. ביקורת: ביקורת אבטחה של מערכת ניהול המפתחות היא חובה, רצוי עם בדיקות חדירה.

זמן פיתוח ל-KMS ארגוני: 4–6 חודשים למערכת ברמת ייצור עם HSM, MPC ומנוע מדיניות. אינטגרציה עם Gnosis Safe או Fireblocks במקום MPC מותאם אישית מקצרת את הזמן בחצי.

העריכו את ניהול המפתחות הנוכחי שלכם — צרו קשר לייעוץ חינם. הזמינו פיתוח KMS ארגוני וקבלו סקירת ארכיטקטורה במתנה.