1. Cloud & Trust Boundaries

3-Cloud Provider 분할

Fireblocks 는 단일 cloud 가 아니라 sensitive material(?) 의 위치 기준으로 3 cloud 를 분할한다.

Azure = sensitive 의 root, AWS = 외피 (gateway / frontend), GCP = caching.
Azure ↔ AWS 통신은 SGX DMZ + PROXY 매개.

6 System Components

전체 시스템은 6 개 영역으로 나뉘어 있고 각각이 책임이 다르다. 민감 데이터를 다루는 영역과 외피 영역을 같은 cloud / network 에 두지 않는다.

graph TB
  subgraph FB_AWS["🟡 Fireblocks AWS — 외피 (민감 데이터 없음)"]
    GW["Dev API Gateway
외부 API 진입점"]
    TM["Transaction Manager
tx 라우팅"]
    BS["Balance Service
잔액 조회"]
    SS["Screening Service
AML · Travel Rule 검사"]
    CS["Certificate Store
인증서 보관"]
  end

  subgraph FB_AZURE["🔵 Fireblocks Azure SGX — Core (민감 데이터 보호)"]
    AE["Auth Engine
인증 검증"]
    PE["Policy Engine / TAPs
정책 평가"]
    SV["Secure Vault
서명 조립 + PKI"]
    CSE["Co-Signer Engine
서명 분산 라우팅"]
  end

  subgraph FB_SIG["🔵 Fireblocks Azure SGX — Co-Signers (2 of 3)"]
    C1["Co-Signer 1
key share #1"]
    C2["Co-Signer 2
key share #2"]
  end

  subgraph CUST_SIG["🟢 Customer 측 — Co-Signer 3 (1 of 3) · 신뢰 경계 분리"]
    C3M["Mobile device
iOS Keychain / Android TEE"]
    C3A["또는: API Co-Signer
customer SGX server"]
    CH["Callback Handler
customer 운영 검증 endpoint"]
  end

  subgraph NODES["🟡 Fireblocks AWS — Blockchain Nodes"]
    N["Node infrastructure
BTC / ETH / SOL / ..."]
  end

  subgraph COLD["⚪ Cold Workspace — 별도 격리 plane (offline)"]
    COLDW["Cold workspace
완전 오프라인
대량 자산 장기 보관
Hot workspace 와 분리"]
  end

  subgraph DR["🔴 Disaster Recovery — offline only · ★ SPOC"]
    DRS["xprv + fprv 재구성
air-gapped machine
정기 사용 금지"]
  end

  GW --> TM --> BS --> N
  TM --> SS
  GW --> AE
  SS --> PE
  PE --> SV --> CSE
  CSE --> C1
  CSE --> C2
  CSE -. 서명 요청 .-> C3M
  CSE -. 서명 요청 .-> C3A
  C3A -. 검증 콜백 .-> CH
  CSE --> N

  classDef azure fill:#dbeafe,stroke:#1e40af,color:#1e3a8a
  classDef aws fill:#fef3c7,stroke:#92400e,color:#78350f
  classDef customer fill:#dcfce7,stroke:#166534,color:#14532d
  classDef cold fill:#f3f4f6,stroke:#6b7280,color:#374151
  classDef dr fill:#fde2e2,stroke:#991b1b,color:#7f1d1d
  class AE,PE,SV,CSE,C1,C2 azure
  class GW,TM,BS,SS,CS,N aws
  class C3M,C3A,CH customer
  class COLDW cold
  class DRS dr
      

Zero-Trust Architecture

한 줄 요약: 내부 service 끼리도 서로를 신뢰하지 않는다. 매번 cert 로 검증.

Fireblocks 의 원문 (transaction-lifecycle.md p.5):

"All services in the Fireblocks core infrastructure operate in a zero-trust configuration. Each service has a derivation of root CA and validates every handoff between services."

풀어 쓰면:

• 같은 회사 내부망 안에 있는 service 끼리도 "내부니까 안전" 으로 가정하지 않는다.
• 한 service 가 다른 service 를 부를 때마다 cert (= 신원증명서) 를 보여주고, 받는 쪽이 이를 검증한다.
• 모든 cert 는 Root CA (회사의 최상위 인증기관) 에서 파생된다. Root → Intermediate → End cert 의 chain 으로 신원이 cryptographically 증명됨.
• SGX enclave 끼리도 예외 없이 derived cert 로 검증.

→ 공격자가 내부망 한 곳을 뚫어도 다른 service 에 접근하려면 cert 가 필요 → 횡적 이동 (lateral movement) 차단.

Authentication Architecture

한 줄 요약: 모바일·API 의 인증은 짧은 수명의 토큰 chain 으로 구성. 1 단계라도 만료되면 재발급 강제.

Cert chain (= 신원 증명 체인)

Root Key → Intermediate Cert → Co-Signer End Cert

• Root Key = Core Services 의 CA (Certificate Authority, 인증기관). 모든 cert 의 근원
• Intermediate Cert = Root 가 서명한 중간 cert. 실제 발급에 사용
• End Cert = Intermediate 가 서명한 말단 cert. 각 co-signer 에 배포
• Customer 측 component (mobile / API Co-Signer) 는 Root Key 의 public 부분만 사전 보유 → Fireblocks 가 서명해서 보내준 token 을 검증할 수 있음

Token lifecycle (= 인증 토큰의 수명 구조)

→ Access token 이 6 시간마다 새로 발급되므로 token 이 유출돼도 짧은 시간만 유효. Refresh token 이 노출되면 더 큰 피해 → mobile KeyChain 의 hardware-encrypted 영역에 보관.

신뢰 경계 (Trust Boundaries)

시스템의 각 영역이 누가 운영하고 무엇을 보호하는지. 영역이 다르면 보안 모델도 다르다 — 한 영역이 뚫려도 다른 영역의 자산이 즉시 노출되지 않게 설계.

★ 핵심 원칙: 어느 한 영역이 침해되어도 다른 영역의 자산은 별도 보호. 예 — Fireblocks SaaS 가 침해되어도 customer 측 co-signer 의 key share 1 개가 없으면 서명 불가능.