2. DB 분할

Sensitive material 위치 + 서비스 ownership 기준으로 분할

Fireblocks 의 3-cloud 분할은 "sensitive 인가 / 외피인가 / cache 인가" 가 1차 기준.
이를 DB 분할로 옮기면 service ownership + mutability profile 기준의 다중 DB 토폴로지가 된다.

Fireblocks vs 본 reference

Fireblocks 는 internal DB 구조를 공개하지 않는다. 본 페이지의 7-DB 분할은 Fireblocks 의 6 system component 와 3-cloud 분할의 logical mirror — "동등한 sensitivity 격리를 DB 단위로 표현하면" 의 hypothesis.

7-DB 토폴로지 (hypothesis)

graph TB
  subgraph APP["Application services"]
    WS["Wallet / Workspace Service"]
    LS["Ledger Service"]
    APS["Approval / Policy Service"]
    SGS["Signing Service"]
    BCS["Broadcast Service
(Chain Adapter)"]
    RCS["Reconciliation Service"]
    AUS["Audit Service"]
  end

  subgraph DB1["walletdb
(Azure equiv.)"]
    T_W[("workspaces · vault_accounts
wallets · addresses
users · roles")]
  end
  subgraph DB2["ledgerdb"]
    T_L[("ledger_accounts · ledger_entries
internal_transfers · withdrawals
deposit_observations")]
  end
  subgraph DB3["approverdb"]
    T_A[("policy_rules · policy_change_log
approval_requests · approval_decisions
admin_quorums · approval_groups")]
  end
  subgraph DB4["auditdb
(append-only)"]
    T_AU[("audit_events · audit_checkpoints
signing_events · signing_requests
key_lifecycle · master_key_operations
recovery_events")]
  end
  subgraph DB5["chaindb"]
    T_C[("chain_events · transactions
broadcast_attempts · confirmations")]
  end
  subgraph DB6["providerdb"]
    T_P[("provider_accounts
provider_external_references
provider_event_log")]
  end
  subgraph DB7["recondb"]
    T_R[("reconciliation_sessions
reconciliation_snapshots
mismatch_findings")]
  end

  WS --> DB1
  LS --> DB2
  APS --> DB3
  SGS --> DB4
  BCS --> DB5
  AUS --> DB4
  RCS --> DB7
  RCS -.read-only.-> DB1
  RCS -.read-only.-> DB2
  RCS -.read-only.-> DB3
  RCS -.read-only.-> DB4
  RCS -.read-only.-> DB5
  RCS -.read-only.-> DB6
Figure 2. 7-DB split — 각 service 는 자기 DB 만 write, Reconciliation Service 만 모든 DB read-only.

분할의 5 가지 근거

근거의미
Sensitivity isolationFireblocks 의 3-cloud 분할의 1차 원칙. SGX-protected material 과 외피 metadata 는 동일 DB 에 두지 않음
Mutability isolationappend-only DB (auditdb) 의 vacuum / lock 패턴과 mutable DB 의 운영 profile 분리
Blast-radius reduction한 DB corruption / 보안 사고 = 그 DB 의 도메인만 영향
Operational separation각 service 의 ownership 명확 — 권한 escalation 회피
Audit separationExternal auditor 가 auditdb 만 read-only access — privacy 단순화

Trade-offs

  • Cross-DB FK 불가 — application 검증 + 정기 reconciliation 필요
  • Multi-DB transaction 불가 — outbox pattern 권장 (eventual consistency)
  • 운영 복잡도 ↑ — 7 instance 관리