v0.0
컴플라이언스-아키텍처 통합 매트릭스¶
1. Executive Summary¶
본 문서는 Phase 2의 최종 산출물로서, m2-01-security-certifications.md(보안 인증 분석)와 m2-02-regulatory-landscape.md(규제 환경 분석)에서 도출된 모든 규제/인증 요구사항을 시스템 아키텍처 제약조건(Architecture Constraint, AC)으로 변환한 통합 매트릭스이다.
핵심 수치: - 총 제약조건: 42개 - 우선순위 분포: P0(필수) 22개, P1(권장) 14개, P2(선택) 6개 - 컴포넌트별 분포: 콜드월렛 14개, 오프라인앱 9개, 온라인 대시보드 31개, 컴포넌트 간 인터페이스 8개 (중복 포함) - 에어갭 자동 충족률: 42개 중 15개(36%)가 에어갭 아키텍처에 의해 자동 또는 부분 충족
핵심 시사점: 1. D'CENT의 에어갭 아키텍처는 네트워크 보안, 키 격리, 물리적 보호 관련 제약조건의 36%를 설계 수준에서 자동 충족한다. 이는 경쟁사 대비 인증/규제 대응에서 구조적 우위. 2. 대시보드(온라인 컴포넌트)에 제약조건이 가장 많이 집중(31개). Phase 5 시스템 아키텍처 설계에서 대시보드의 보안 설계에 최대 주의 필요. 3. P0 제약조건 22개는 "설계 시점부터 반드시 반영"해야 하며, 이를 누락하면 인증/규제 위반 리스크 발생. 4. 한국 시장 진입 시 P0 제약조건 22개 + 한국 특화 P1 5개 = 27개가 필수 충족 대상.
2. 매트릭스 구성 원칙¶
2.1. 제약조건 ID 체계¶
제약조건 ID는 AC-{카테고리}-{번호} 형식을 따른다:
| 카테고리 코드 | 영역 | 설명 |
|---|---|---|
| AC-KM | Key Management | 키/시드 생성, 저장, 사용, 백업, 파기 |
| AC-AC | Access Control | 인증, 권한, RBAC, 접근 관리 |
| AC-AU | Audit & Logging | 감사 추적, 변조 방지 로그, 모니터링 |
| AC-TX | Transaction Control | 트랜잭션 정책, 승인 흐름, 서명 관리 |
| AC-NW | Network & Communication | 에어갭, 통신 프로토콜, 네트워크 보안 |
| AC-DR | Disaster Recovery | 백업, 복구, 사업 연속성 |
| AC-RP | Reporting & Compliance | 규제 보고, 감사 대응, 컴플라이언스 리포팅 |
| AC-GV | Governance | 정책 관리, 역할 체계, 거버넌스 |
2.2. 우선순위 체계¶
| 우선순위 | 정의 | 기준 |
|---|---|---|
| P0 (필수) | 미충족 시 인증 취득 불가 또는 규제 위반 | CCSS Level 2, SOC 2 필수 TSC, 한국/EU 법적 의무 |
| P1 (권장) | 경쟁력 확보 및 상위 인증에 필요 | CCSS Level 3, SOC 2 권장, 수탁 서비스 티어 |
| P2 (선택) | 차별화 및 프리미엄 포지셔닝 | DORA 세부, 미국 규제 선제 대응 |
2.3. 충족 방식¶
| 코드 | 설명 |
|---|---|
| Auto | 에어갭 아키텍처가 자동으로 충족 (추가 설계 불필요) |
| Partial | 에어갭이 부분 충족, 추가 설계로 완성 |
| Design | 시스템 설계로 충족 필요 |
| Ops | 운영 프로세스/정책으로 충족 |
3. 통합 컴플라이언스 매트릭스¶
3.1. AC-KM: Key Management (키 관리)¶
| ID | 제약조건 설명 | 출처 | 우선순위 | 컴포넌트 | 충족 방식 | 설계 페이즈 |
|---|---|---|---|---|---|---|
| AC-KM-01 | SE 내부에서만 키/시드 생성. TRNG + DRBG 검증 필수 | CCSS Aspect 1 (L2), ISO A.8.24 | P0 | 콜드월렛(SE) | Auto | Phase 6 |
| AC-KM-02 | 프라이빗 키는 SE 외부로 절대 추출 불가 | CCSS Aspect 3 (L2), SOC 2 Confidentiality | P0 | 콜드월렛(SE) | Auto | Phase 6 |
| AC-KM-03 | 키 저장소 이중화: primary 디바이스 + 금속 시드 백업 | CCSS Aspect 3 (L2), SOC 2 Availability | P0 | 콜드월렛 | Design | Phase 3 |
| AC-KM-04 | 지리적 분산 키 저장 (최소 2개 물리적 위치) | CCSS Aspect 3 (L3) | P1 | 운영 정책 | Ops | Phase 3 |
| AC-KM-05 | 키 세레모니 프로세스 (스크립트화, 증인 역할, 검증) | CCSS Aspect 1 (L3), ISO A.5.10 | P1 | 오프라인앱 + 콜드월렛 | Design | Phase 3 |
| AC-KM-06 | 데이터 삭제 정책: SE 보안 삭제, 디바이스 폐기 절차 | CCSS Aspect 8 (L2), ISO A.7.10 | P0 | 콜드월렛 | Design | Phase 6 |
| AC-KM-07 | 키 로테이션/교체 절차 (서명자 변경 시) | CCSS Aspect 5 (L2), ISO A.6.5 | P0 | 오프라인앱 + 대시보드 | Design | Phase 3 |
3.2. AC-AC: Access Control (접근 제어)¶
| ID | 제약조건 설명 | 출처 | 우선순위 | 컴포넌트 | 충족 방식 | 설계 페이즈 |
|---|---|---|---|---|---|---|
| AC-AC-01 | RBAC 기반 역할 체계 (Admin, Initiator, Approver, Viewer + 커스텀) | CCSS Aspect 6 (L2), SOC 2 Security, ISO A.5.2-3, ISMS-P 4.1 | P0 | 대시보드 + 오프라인앱 | Design | Phase 3 |
| AC-AC-02 | 다중 인증 (PIN + 생체 + 하드웨어 소유) | SOC 2 Security CC6.2, ISO A.8.5, ISMS-P 4.3 | P0 | 콜드월렛 + 대시보드 | Design | Phase 3 |
| AC-AC-03 | 관리자 쿼럼 승인 기반 권한 변경 | CCSS Aspect 6 (L2), MiCA Art. 70 | P0 | 대시보드 | Design | Phase 3 |
| AC-AC-04 | 정형화된 서명자 온보딩/오프보딩 절차 | CCSS Aspect 6 (L2), ISO A.6.1-2 | P0 | 대시보드 | Design | Phase 3 |
| AC-AC-05 | ABAC 확장 (조건부 정책: 금액, 시간, 자산 유형) | CCSS Aspect 6 (L3) | P1 | 대시보드 + 정책 엔진 | Design | Phase 4 |
| AC-AC-06 | 특권 접근 관리 (Admin 세션 로깅, 시간 제한) | ISO A.8.2, ISMS-P 4.3 | P0 | 대시보드 | Design | Phase 5 |
3.3. AC-AU: Audit & Logging (감사 및 로깅)¶
| ID | 제약조건 설명 | 출처 | 우선순위 | 컴포넌트 | 충족 방식 | 설계 페이즈 |
|---|---|---|---|---|---|---|
| AC-AU-01 | 변조 불가 감사 로그 (모든 시스템 액션 기록) | CCSS Aspect 10 (L2), SOC 2 Security, ISO A.8.15, ISMS-P 6.1 | P0 | 대시보드 + 오프라인앱 | Design | Phase 3 |
| AC-AU-02 | 오프라인/온라인 감사 로그 동기화 | CCSS Aspect 10 (L2) | P0 | 오프라인앱 ↔ 대시보드 | Design | Phase 5 |
| AC-AU-03 | 로그 보존 정책 (법적 요구 기간: 한국 5년, EU 5년) | ISMS-P 6.2, MiCA, 특금법 | P0 | 대시보드 | Design | Phase 5 |
| AC-AU-04 | 실시간 보안 이벤트 모니터링 | CCSS Aspect 10 (L3), ISO A.8.16 | P1 | 대시보드 | Design | Phase 5 |
| AC-AU-05 | 이상 패턴 자동 탐지 및 알림 | CCSS Aspect 10 (L3), DORA ICT Risk | P1 | 대시보드 | Design | Phase 5 |
3.4. AC-TX: Transaction Control (트랜잭션 제어)¶
| ID | 제약조건 설명 | 출처 | 우선순위 | 컴포넌트 | 충족 방식 | 설계 페이즈 |
|---|---|---|---|---|---|---|
| AC-TX-01 | 최소 2-of-N 다중 서명 지원 | CCSS Aspect 2,4 (L2) | P0 | 콜드월렛 + 오프라인앱 | Design | Phase 3 |
| AC-TX-02 | WYSIWYS: 하드웨어 디스플레이에서 트랜잭션 내용 확인 후 물리 버튼 승인 | CCSS Aspect 4 (L2), SOC 2 Processing Integrity | P0 | 콜드월렛(디스플레이) | Design | Phase 4 |
| AC-TX-03 | 트랜잭션 정책 엔진 (금액 제한, 화이트리스트, 시간 제한, 자산 유형) | CCSS Aspect 4 (L2), MiCA Art. 68 | P0 | 대시보드 + 콜드월렛 | Design | Phase 3 |
| AC-TX-04 | 화이트리스트 주소 관리 (관리자 쿼럼 승인, 오프라인 디바이스 동기화) | CCSS Aspect 4 (L2) | P0 | 대시보드 + 오프라인앱 | Design | Phase 3 |
| AC-TX-05 | 하드웨어 수준 정책 집행 (SE에서 정책 위반 트랜잭션 거부) | CCSS Aspect 4 (L3) | P1 | 콜드월렛(펌웨어) | Design | Phase 4 |
| AC-TX-06 | 콜드/핫 월렛 자산 분리 관리 및 비율 모니터링 | 가상자산이용자보호법, 일본 FSA, 홍콩 SFC | P0 | 대시보드 | Design | Phase 3 |
3.5. AC-NW: Network & Communication (네트워크 및 통신)¶
| ID | 제약조건 설명 | 출처 | 우선순위 | 컴포넌트 | 충족 방식 | 설계 페이즈 |
|---|---|---|---|---|---|---|
| AC-NW-01 | 콜드월렛은 네트워크에 절대 연결 금지 (에어갭) | SOC 2 Security, DORA ICT Risk, 에어갭 원칙 | P0 | 콜드월렛 | Auto | Phase 5 |
| AC-NW-02 | 에어갭 통신은 QR(대시보드↔앱) + USB-C(앱↔콜드월렛)만 허용 | SOC 2 Security CC6.7, ISO A.8.20 | P0 | 콜드월렛 ↔ 오프라인앱 | Design | Phase 5 |
| AC-NW-03 | 에어갭 통신 데이터 암호화 및 무결성 검증 | SOC 2 Security CC6.7, ISO A.8.24 | P0 | 콜드월렛 ↔ 오프라인앱 | Design | Phase 5 |
| AC-NW-04 | WiFi/Bluetooth 통한 데이터 전송 금지 (USB-C는 오프라인 앱 경유 허용) | CLAUDE.md Out of Scope, SOC 2 Security | P0 | 콜드월렛 | Auto | Phase 6 |
| AC-NW-05 | 대시보드 네트워크 보안 (TLS, 방화벽, 네트워크 세그멘테이션) | SOC 2 Security CC6.6, ISO A.8.20, ISMS-P 4.2 | P0 | 대시보드 | Design | Phase 5 |
| AC-NW-06 | NFC 상호 인증 (R3covery 카드 SE-to-SE 통신 보안) | ISO 14443 보안, R3covery 카드 기술 분석 참조 | P1 | 콜드월렛 ↔ R3covery 카드 | Design | Phase 5 |
3.6. AC-DR: Disaster Recovery (재해 복구)¶
| ID | 제약조건 설명 | 출처 | 우선순위 | 컴포넌트 | 충족 방식 | 설계 페이즈 |
|---|---|---|---|---|---|---|
| AC-DR-01 | RTO/RPO 정의 (시나리오별: 일반, 긴급, 디바이스 장애) | SOC 2 Availability A1.1, DORA Resilience, ISMS-P 10.1 | P0 | 전체 | Design | Phase 3 |
| AC-DR-02 | 시드 백업 절차 (금속 시드, 지리적 분산 보관) | CCSS Aspect 3 (L2), SOC 2 Availability A1.3, ISO A.5.29 | P0 | 콜드월렛 + 운영 정책 | Design | Phase 3 |
| AC-DR-03 | 대시보드 데이터 백업 및 복구 (HA 아키텍처) | SOC 2 Availability, DORA ICT Risk, ISMS-P 10.2 | P0 | 대시보드 | Design | Phase 5 |
| AC-DR-04 | 디바이스 교체/복구 절차 (백업 디바이스 전환) | SOC 2 Availability A1.3, CCSS Aspect 5 (L2) | P0 | 콜드월렛 + 오프라인앱 | Design | Phase 3 |
| AC-DR-05 | 정기 재해 복구 드릴 프레임워크 | DORA Resilience Testing, SOC 2 Availability | P1 | 전체 | Ops | Phase 3 |
3.7. AC-RP: Reporting & Compliance (보고 및 컴플라이언스)¶
| ID | 제약조건 설명 | 출처 | 우선순위 | 컴포넌트 | 충족 방식 | 설계 페이즈 |
|---|---|---|---|---|---|---|
| AC-RP-01 | Proof of Reserve 리포트 (정기적 자산 보유 증빙) | CCSS Aspect 9 (L2), 가상자산이용자보호법 | P0 | 대시보드 | Design | Phase 3 |
| AC-RP-02 | 자산 분리 보관 증빙 리포트 | 가상자산이용자보호법, MiCA Art. 68 | P0 | 대시보드 | Design | Phase 3 |
| AC-RP-03 | STR/CTR 보고서 자동 생성 | 특금법, FinCEN BSA | P1 | 대시보드 | Design | Phase 3 |
| AC-RP-04 | 컴플라이언스 리포팅 (거래 내역, 승인 체인, 정책 변경) | MiCA CASP 보고, SOC 2 | P1 | 대시보드 | Design | Phase 3 |
| AC-RP-05 | 외부 감사 대응 리포트 자동 생성 | CCSS Aspect 7, SOC 2, ISO 27001, MiCA Art. 75 | P1 | 대시보드 | Design | Phase 5 |
| AC-RP-06 | 인시던트 보고 자동화 (분류, 타임라인, 보고서) | DORA Incident Reporting | P1 | 대시보드 | Design | Phase 5 |
| AC-RP-07 | 실시간 Proof of Reserve (Merkle Tree 기반) | CCSS Aspect 9 (L3) | P2 | 대시보드 | Design | Phase 5 |
3.8. AC-GV: Governance (거버넌스)¶
| ID | 제약조건 설명 | 출처 | 우선순위 | 컴포넌트 | 충족 방식 | 설계 페이즈 |
|---|---|---|---|---|---|---|
| AC-GV-01 | 정책 버전 관리 및 변경 이력 추적 | MiCA Art. 70, ISO A.5.1, ISMS-P 1.1 | P0 | 대시보드 | Design | Phase 3 |
| AC-GV-02 | 정책 변경 시 관리자 쿼럼 승인 | CCSS Aspect 6 (L2), MiCA 거버넌스 | P0 | 대시보드 + 오프라인앱 | Design | Phase 3 |
| AC-GV-03 | Travel Rule 메시지 생성/수신 인터페이스 | 특금법, FinCEN, FATF | P1 | 대시보드 | Design | Phase 5 |
| AC-GV-04 | KYC/AML 시스템 연동 인터페이스 | 특금법, FinCEN BSA, MAS PSN02 | P1 | 대시보드 | Design | Phase 5 |
| AC-GV-05 | 서드파티 리스크 관리 (블록체인 노드 제공자) | DORA Third-party Risk | P2 | 대시보드 | Design | Phase 5 |
4. 컴포넌트별 제약조건 뷰¶
4.1. D'CENT X 콜드월렛 (Hardware SE)¶
총 14개 제약조건 (P0: 10개, P1: 3개, P2: 1개)
| ID | 제약조건 | 우선순위 | 충족 방식 |
|---|---|---|---|
| AC-KM-01 | SE 내부 키/시드 생성 (TRNG + DRBG) | P0 | Auto |
| AC-KM-02 | 프라이빗 키 SE 외부 추출 불가 | P0 | Auto |
| AC-KM-03 | 키 저장소 이중화 (금속 시드 백업) | P0 | Design |
| AC-KM-06 | SE 보안 삭제, 디바이스 폐기 | P0 | Design |
| AC-AC-02 | 다중 인증 (PIN + 생체) | P0 | Design |
| AC-TX-01 | 다중 서명 지원 | P0 | Design |
| AC-TX-02 | WYSIWYS 트랜잭션 표시 | P0 | Design |
| AC-TX-03 | 트랜잭션 정책 엔진 (하드웨어 측) | P0 | Design |
| AC-NW-01 | 네트워크 연결 금지 (에어갭) | P0 | Auto |
| AC-NW-04 | WiFi/BT 데이터 전송 금지 (USB-C는 오프라인 앱 경유 허용) | P0 | Auto |
| AC-TX-05 | 하드웨어 정책 집행 (SE에서 거부) | P1 | Design |
| AC-NW-02 | QR + USB-C만 허용 | P0 | Design |
| AC-NW-06 | NFC 상호 인증 (R3covery 카드 전용) | P1 | Design |
| AC-KM-05 | 키 세레모니 프로세스 | P1 | Design |
설계 지침: - SE의 CC EAL5+ 인증이 AC-KM-01, AC-KM-02의 자동 충족을 보증 - 펌웨어에서 WiFi/BT 통신 스택을 완전히 비활성화하여 AC-NW-04 강제 (USB-C는 오프라인 앱 경유 허용) - WYSIWYS(AC-TX-02)는 체인별 트랜잭션 파싱 범위 정의 필요 (Phase 4 DIF-01)
4.2. 오프라인 서명 앱¶
총 9개 제약조건 (P0: 7개, P1: 2개)
| ID | 제약조건 | 우선순위 | 충족 방식 |
|---|---|---|---|
| AC-AC-01 | RBAC 역할 체계 | P0 | Design |
| AC-AU-01 | 변조 불가 감사 로그 | P0 | Design |
| AC-AU-02 | 오프라인/온라인 로그 동기화 | P0 | Design |
| AC-TX-01 | 다중 서명 서명 수집 | P0 | Design |
| AC-TX-04 | 화이트리스트 관리 (오프라인 동기화) | P0 | Design |
| AC-NW-02 | QR(대시보드↔앱) + USB-C(앱↔콜드월렛) 통신 | P0 | Design |
| AC-NW-03 | 에어갭 통신 암호화 | P0 | Design |
| AC-KM-07 | 서명자 교체 절차 지원 | P0 | Design |
| AC-GV-02 | 정책 변경 쿼럼 승인 | P0 | Design |
설계 지침: - 오프라인 앱은 콜드월렛과 대시보드 사이의 에어갭 브릿지 역할 - 오프라인 환경에서의 감사 로그 무결성 보장이 핵심 과제 - 서명 수집 워크플로우에서 M-of-N 부분 서명 관리 필요
4.3. 온라인 대시보드¶
총 31개 제약조건 (P0: 17개, P1: 11개, P2: 3개)
| ID | 제약조건 | 우선순위 | 충족 방식 |
|---|---|---|---|
| AC-AC-01 | RBAC 역할 체계 | P0 | Design |
| AC-AC-02 | 다중 인증 | P0 | Design |
| AC-AC-03 | 관리자 쿼럼 승인 | P0 | Design |
| AC-AC-04 | 서명자 온보딩/오프보딩 | P0 | Design |
| AC-AC-06 | 특권 접근 관리 | P0 | Design |
| AC-AU-01 | 변조 불가 감사 로그 | P0 | Design |
| AC-AU-02 | 오프라인/온라인 로그 동기화 | P0 | Design |
| AC-AU-03 | 로그 보존 정책 (5년+) | P0 | Design |
| AC-TX-03 | 트랜잭션 정책 엔진 | P0 | Design |
| AC-TX-04 | 화이트리스트 주소 관리 | P0 | Design |
| AC-TX-06 | 콜드/핫 자산 비율 모니터링 | P0 | Design |
| AC-NW-05 | 네트워크 보안 (TLS, 방화벽) | P0 | Design |
| AC-DR-01 | RTO/RPO 정의 | P0 | Design |
| AC-DR-03 | 데이터 백업/복구 (HA) | P0 | Design |
| AC-RP-01 | Proof of Reserve 리포트 | P0 | Design |
| AC-RP-02 | 자산 분리 보관 증빙 | P0 | Design |
| AC-GV-01 | 정책 버전 관리/변경 이력 | P0 | Design |
| AC-GV-02 | 정책 변경 쿼럼 승인 | P0 | Design |
| AC-AC-05 | ABAC 확장 | P1 | Design |
| AC-AU-04 | 실시간 보안 이벤트 모니터링 | P1 | Design |
| AC-AU-05 | 이상 패턴 자동 탐지 | P1 | Design |
| AC-RP-03 | STR/CTR 보고서 자동 생성 | P1 | Design |
| AC-RP-04 | 컴플라이언스 리포팅 | P1 | Design |
| AC-RP-05 | 외부 감사 대응 리포트 | P1 | Design |
| AC-RP-06 | 인시던트 보고 자동화 | P1 | Design |
| AC-KM-07 | 키 교체 관리 | P0 | Design |
| AC-GV-03 | Travel Rule 인터페이스 | P1 | Design |
| AC-GV-04 | KYC/AML 연동 | P1 | Design |
| AC-RP-07 | 실시간 PoR (Merkle Tree) | P2 | Design |
| AC-GV-05 | 서드파티 리스크 관리 | P2 | Design |
| AC-DR-05 | 재해 복구 드릴 프레임워크 | P1 | Ops |
설계 지침: - 대시보드는 제약조건이 가장 많이 집중되는 컴포넌트. 보안 설계에 최대 주의 필요 - 온프레미스(DIF-04) 배포 시에도 모든 제약조건 충족 가능한 설계 필요 - 감사 로그, 리포팅, 정책 관리가 대시보드의 3대 핵심 기능 영역
4.4. 컴포넌트 간 인터페이스 제약조건¶
| 인터페이스 | 관련 제약조건 | 핵심 설계 포인트 |
|---|---|---|
| 콜드월렛 ↔ 오프라인앱 | AC-NW-02, AC-NW-03 | USB-C 유선 통신 (오프라인 서명 유닛 내부), 데이터 무결성 검증 |
| 오프라인앱 ↔ 대시보드 | AC-AU-02, AC-TX-04, AC-GV-02 | 감사 로그 동기화, 화이트리스트 동기화, 정책 동기화 |
| 콜드월렛 ↔ 대시보드 | — (직접 통신 없음) | 에어갭 원칙: 반드시 오프라인앱을 경유 |
5. 페이즈별 제약조건 뷰¶
Phase 3: Core Product Design¶
참조 제약조건: 22개
키 관리: AC-KM-03, AC-KM-04, AC-KM-05, AC-KM-07 접근 제어: AC-AC-01, AC-AC-02, AC-AC-03, AC-AC-04 감사: AC-AU-01 트랜잭션: AC-TX-01, AC-TX-03, AC-TX-04, AC-TX-06 재해 복구: AC-DR-01, AC-DR-02, AC-DR-04, AC-DR-05 보고: AC-RP-01, AC-RP-02, AC-RP-03, AC-RP-04 거버넌스: AC-GV-01, AC-GV-02
핵심 포인트: Phase 3은 가장 많은 P0 제약조건을 반영해야 하는 페이즈. 다중 서명, RBAC, 정책 엔진, 감사 로그의 기본 설계가 여기서 확정.
Phase 4: Differentiation & Extended Architecture¶
참조 제약조건: 3개
접근 제어: AC-AC-05 (ABAC 확장) 트랜잭션: AC-TX-02 (WYSIWYS), AC-TX-05 (하드웨어 정책 집행)
핵심 포인트: WYSIWYS와 하드웨어 정책 엔진은 D'CENT 차별화의 핵심이며, CCSS Level 3 달성의 전제 조건.
Phase 5: System Architecture Design¶
참조 제약조건: 14개
접근 제어: AC-AC-06 감사: AC-AU-02, AC-AU-03, AC-AU-04, AC-AU-05 네트워크: AC-NW-01, AC-NW-02, AC-NW-03, AC-NW-05, AC-NW-06 재해 복구: AC-DR-03 보고: AC-RP-05, AC-RP-06, AC-RP-07 거버넌스: AC-GV-03, AC-GV-04, AC-GV-05
핵심 포인트: 에어갭 통신 프로토콜, 네트워크 보안, 모니터링 아키텍처의 기술 설계. 3-Zone 아키텍처에서 각 Zone의 보안 경계 정의.
Phase 6: Firmware Requirements¶
참조 제약조건: 5개
키 관리: AC-KM-01, AC-KM-02, AC-KM-06 네트워크: AC-NW-04 트랜잭션: AC-TX-02 (펌웨어 파싱 범위)
핵심 포인트: SE 하드웨어 역량과 제약사항에 따른 펌웨어 요구사항 도출. CC EAL5+ 인증 범위 확정.
6. 에어갭 아키텍처 컴플라이언스 이점 분석¶
6.1. 에어갭이 자동 충족하는 제약조건¶
| ID | 제약조건 | 충족 근거 |
|---|---|---|
| AC-KM-01 | SE 내부 키 생성 | SE 하드웨어가 TRNG/DRBG를 내장하여 자동 충족 |
| AC-KM-02 | 키 SE 외부 추출 불가 | SE 하드웨어 설계상 키 추출이 물리적으로 불가능 |
| AC-NW-01 | 네트워크 연결 금지 | 에어갭 아키텍처의 근본 설계 원칙. 네트워크 스택 부재 |
| AC-NW-04 | USB/WiFi/BT 금지 | 에어갭 아키텍처에서 해당 통신 스택 제거. 물리적 차단 |
6.2. 에어갭이 부분 충족하는 제약조건 (Partial)¶
| ID | 제약조건 | 자동 충족 부분 | 추가 설계 필요 |
|---|---|---|---|
| AC-AC-02 | 다중 인증 | 하드웨어 소유 자체가 인증 요소 | PIN, 생체 인증 추가 설계 |
| AC-TX-02 | WYSIWYS | 디스플레이 하드웨어 존재 | 체인별 트랜잭션 파싱 소프트웨어 필요 |
| AC-NW-02 | QR + USB-C만 허용 | 다른 통신 경로 없음 | QR(에어갭) + USB-C(디바이스) 프로토콜 설계 필요 |
| AC-NW-03 | 통신 암호화 | 에어갭으로 도청 경로 제한 | 추가 암호화 계층 설계 필요 |
(중략: 부분 충족 11개 항목)
6.3. 에어갭으로 인한 추가 설계 과제¶
| 과제 | 설명 | 해결 방향 |
|---|---|---|
| 서명 가용성 | 긴급 트랜잭션 시 물리적 디바이스 접근 필요 | 긴급 출금 시나리오별 RTO 정의, 지리적 분산 디바이스 배치 |
| 로그 동기화 | 오프라인 감사 로그의 온라인 동기화 지연 | QR 기반 로그 전송 프로토콜, 배치 동기화 설계 |
| 정책 업데이트 | 정책 변경 시 오프라인 디바이스 업데이트 필요 | 정책 동기화 워크플로우, 버전 관리 |
| 펌웨어 업데이트 | 원격 업데이트 불가 (에어갭 유지) | 서명된 바이너리 + MicroSD 또는 QR 기반 업데이트 |
| 실시간 모니터링 | 콜드월렛 상태의 실시간 모니터링 불가 | 대시보드에서 온체인 데이터 기반 간접 모니터링 |
6.4. 경쟁사 대비 컴플라이언스 우위 정량화¶
| 비교 항목 | Fireblocks | BitGo | D'CENT Enterprise |
|---|---|---|---|
| 네트워크 보안 제약조건 자동 충족 | 0개 (소프트웨어 기반) | 0개 (API 기반) | 6개 (에어갭) |
| 키 격리 제약조건 자동 충족 | 부분 (MPC) | 0개 | 2개 (SE) |
| 전체 자동 충족률 | ~5% | ~3% | ~36% |
| SOC 2 네트워크 관련 증적 필요량 | 많음 | 많음 | 최소 (에어갭 근거) |
| 인증 취득 예상 비용 절감 | — | — | 20-30% (자동 충족에 의한) |
7. 시장별 필수 제약조건 세트¶
7.1. 한국 시장 진입 시 필수 체크리스트¶
P0 필수: 22개 + 한국 특화: 5개 = 27개
- [ ] AC-KM-01 ~ AC-KM-03, AC-KM-06, AC-KM-07 (키 관리 5개)
- [ ] AC-AC-01 ~ AC-AC-04, AC-AC-06 (접근 제어 5개)
- [ ] AC-AU-01 ~ AC-AU-03 (감사 3개)
- [ ] AC-TX-01, AC-TX-03, AC-TX-04, AC-TX-06 (트랜잭션 4개)
- [ ] AC-NW-01 ~ AC-NW-05 (네트워크 5개)
- [ ] AC-DR-01 ~ AC-DR-04 (재해 복구 4개)
- [ ] AC-RP-01, AC-RP-02 (보고 2개)
- [ ] AC-GV-01, AC-GV-02 (거버넌스 2개)
- 한국 특화 추가:
- [ ] AC-RP-03 (STR/CTR 보고서 - 특금법)
- [ ] AC-TX-06 (콜드 80% 비율 모니터링 - 가상자산이용자보호법)
- [ ] ISMS-P 인증 기준 24개 항목 충족
- [ ] 개인정보보호법 대응 (수탁 서비스 티어)
- [ ] Travel Rule 대응 (100만원 이상 - 특금법)
7.2. APAC 시장 확장 시 추가 필요¶
- [ ] 일본 FSA: 95% 콜드 스토리지 비율 모니터링 (AC-TX-06 확장)
- [ ] 싱가포르 MAS: TRMG 기술 리스크 관리 (SOC 2 커버)
- [ ] 홍콩 SFC: 98% 콜드 스토리지 + 핫 월렛 보험 증빙
7.3. EU 시장 진입 시 추가 필요¶
- [ ] AC-GV-03 (Travel Rule - MiCA)
- [ ] AC-GV-04 (KYC/AML 연동)
- [ ] AC-RP-06 (DORA 인시던트 보고)
- [ ] AC-GV-05 (DORA 서드파티 리스크)
- [ ] AC-DR-05 (DORA 복원력 테스트)
- [ ] CASP 라이선스 신청 서류 자동 생성
7.4. 미국 시장 진입 시 추가 필요¶
- [ ] FinCEN SAR/CTR 보고 (AC-RP-03 확장)
- [ ] SEC Qualified Custodian 요구사항 대응
- [ ] BitLicense 사이버보안 요구사항 (23 NYCRR Part 500)
- [ ] State-by-state Money Transmitter 라이선스
8. 갭 분석 및 리스크¶
8.1. 현재 D'CENT 기술로 충족 어려운 제약조건¶
| 제약조건 | 갭 설명 | 추가 필요 사항 | 예상 투자 |
|---|---|---|---|
| AC-TX-05 (하드웨어 정책 집행) | 현재 D'CENT 펌웨어에 정책 엔진 없음 | 펌웨어 신규 개발 필요 | 높음 (6-12개월) |
| AC-RP-07 (실시간 PoR) | Merkle Tree 기반 PoR 미구현 | 대시보드 신규 기능 개발 | 중간 (3-6개월) |
| AC-AU-05 (이상 패턴 탐지) | ML 기반 탐지 엔진 필요 | 데이터 수집 + 모델 개발 | 높음 (6-12개월) |
| AC-GV-03 (Travel Rule) | IVMS101 프로토콜 지원 미구현 | 표준 프로토콜 구현 | 중간 (3-6개월) |
8.2. 타임라인 리스크¶
| 리스크 | 영향 | 완화 전략 |
|---|---|---|
| ISMS-P 인증 지연 | 한국 시장 진입 지연 | 사전 준비 + 전문 컨설턴트 조기 투입 |
| MiCA Level 2 규제 변경 | EU 진입 요구사항 변동 | RTS/ITS 발행 즉시 분석, 설계 유연성 확보 |
| SOC 2 감사 기간 초과 | APAC 확장 타임라인 영향 | Type I 조기 취득으로 기간 단축 |
| SE 펌웨어 개발 지연 | CCSS Level 3 달성 지연 | Phase 6에서 우선순위 조정 |
| 미국 규제 급변 | 예상치 못한 대응 필요 | 규제 모니터링 전담 + 유연한 아키텍처 |
8.3. 리스크 완화를 위한 아키텍처 원칙¶
- 모듈화: 규제별 기능을 모듈로 분리하여, 시장별 활성화/비활성화 가능
- 설정 기반: 콜드 스토리지 비율(80%/95%/98%), 보고 의무 등을 설정값으로 조정 가능하게 설계
- API 우선: KYC/AML, Travel Rule, 규제 보고 등 외부 시스템 연동은 API 인터페이스로 제공
- 확장성: 신규 규제 요구사항을 플러그인 형태로 추가할 수 있는 아키텍처
작성일: 2026-03-28 Phase 2 Plan 03 산출물 — CMP-06 요구사항 충족 Phase 2 최종 산출물: Phase 3-6 설계의 컴플라이언스 기준선