v0.0
보안 인증 표준 분석: CCSS v9.0, SOC 2 Type II, ISO 27001:2022¶
1. Executive Summary¶
D'CENT 엔터프라이즈가 글로벌 엔터프라이즈 커스터디 시장에서 경쟁력을 확보하기 위해서는 업계 표준 보안 인증의 취득이 필수적이다. Fireblocks, BitGo, Ledger Enterprise 등 주요 경쟁사가 모두 SOC 2 Type II와 ISO 27001을 보유하고 있으며, CCSS(CryptoCurrency Security Standard)는 암호화폐 커스터디에 특화된 유일한 업계 표준이다.
인증 전략 요약:
| 인증 | 목표 수준 | 취득 시점 | 근거 |
|---|---|---|---|
| CCSS v9.0 | Level 2 (출시 시) → Level 3 (12개월 내) | Phase 1 GTM (한국, 0-12개월) | 암호화폐 커스터디 특화 인증, 셀프 커스터디 신뢰도 확보 |
| SOC 2 Type II | 5개 TSC 전체 | APAC 확장 전 (12-18개월) | 기관 고객 영업의 전제 조건, 경쟁사 전원 보유 |
| ISO 27001:2022 | 전체 ISMS 인증 | EU 진입 전 (18-24개월) | MiCA 컴플라이언스 기반, 글로벌 시장 신뢰도 |
핵심 시사점: 1. D'CENT의 에어갭 아키텍처는 CCSS, SOC 2, ISO 27001의 상당수 요구사항을 설계 수준에서 자동 충족한다 (네트워크 격리, 물리적 키 보호). 2. 3개 인증의 중복 컨트롤이 약 40-50% 수준이므로, "Audit once, certify for multiple" 전략이 효과적이다. 3. 설계 단계(Phase 3-5)에서 인증 요구사항을 선반영하면, 인증 취득 시 재설계 비용을 80% 이상 절감할 수 있다.
2. CCSS v9.0 분석¶
2.1. CCSS 개요¶
CCSS(CryptoCurrency Security Standard)는 CryptoCurrency Certification Consortium(C4)이 관리하는 암호화폐 시스템 전용 보안 표준이다. 2024년 12월 v9.0으로 업데이트되었으며, 암호화폐의 생성, 저장, 사용 전 과정에 대한 보안 요구사항을 정의한다.
CCSS와 일반 보안 표준(SOC 2, ISO 27001)의 차이: - SOC 2/ISO 27001은 일반 정보보안 프레임워크이며 암호화폐 특화 항목이 없음 - CCSS는 키 생성, 월렛 관리, 서명 프로세스 등 암호화폐 고유의 보안 영역을 커버 - 업계에서 CCSS + SOC 2 조합이 커스터디 보안의 골든 스탠다드로 인식됨
2.2. 3개 인증 수준¶
| 수준 | 명칭 | 핵심 요구사항 | 대상 |
|---|---|---|---|
| Level 1 | Basic Security | 각 Aspect에서 최소 보안 기준 충족. 단일 서명 허용, 기본 키 관리 | 소규모 서비스, 개인용 월렛 |
| Level 2 | Standard Security | 다중 서명 필수, 이중화된 키 저장, 정기 감사, 서명자 정책 수립 | 엔터프라이즈 커스터디, VASP |
| Level 3 | Advanced Security | 모든 Aspect 최고 수준, 지리적 분산 키 저장, 외부 감사, 자동화된 정책 집행 | 글로벌 커스터디안, 대규모 기관 |
2.3. 10개 보안 측면(Aspects)별 요구사항¶
Aspect 1: Key/Seed Generation (키/시드 생성)¶
| 수준 | 요구사항 | D'CENT 대응 |
|---|---|---|
| Level 1 | CSPRNG(암호학적으로 안전한 난수 생성기) 사용. 키 생성 환경의 기본 보안 | SE(Secure Element) 내장 TRNG(True Random Number Generator) 활용 |
| Level 2 | DRBG(결정적 난수 생성기) 검증. 키 생성 절차 문서화. 생성 환경 격리 | 에어갭 환경에서 키 생성. SE 내부 DRBG 사용 검증 필요 |
| Level 3 | 다중 엔트로피 소스 결합. 키 세레모니 프로세스 수립. 외부 감사 가능 | 하드웨어 TRNG + 사용자 엔트로피 결합. 키 세레모니 워크플로우 설계 필요 (PRD-10) |
Aspect 2: Wallet Creation (월렛 생성)¶
| 수준 | 요구사항 | D'CENT 대응 |
|---|---|---|
| Level 1 | 월렛 주소 생성 및 검증. 기본 백업 절차 | BIP-44/84/86 기반 HD 월렛 생성 |
| Level 2 | 다중 서명 월렛 생성. 서명자 구성 정책. 월렛 메타데이터 관리 | M-of-N 다중 서명 월렛 생성 플로우 설계 필요 (PRD-02) |
| Level 3 | 월렛 정책(금액 제한, 화이트리스트) 프로그래밍. 자동화된 월렛 검증 | 정책 엔진 통합 월렛 생성. 하드웨어 정책 엔진 필요 (DIF-02) |
Aspect 3: Key Storage (키 저장)¶
| 수준 | 요구사항 | D'CENT 대응 |
|---|---|---|
| Level 1 | 암호화된 키 저장. 기본 접근 제어 | SE(EAL5+) 내부 키 저장. 암호화 자동 적용 |
| Level 2 | 이중화된 키 저장(primary + backup). 물리적 보안 통제. 키 접근 로깅 | 에어갭 디바이스 + 금속 시드 백업. SE 외부 키 유출 불가 구조 |
| Level 3 | 지리적 분산 키 저장. HSM 또는 동등 수준 하드웨어. 자동 키 로테이션 정책 | 지리적 분산 디바이스 배치 운영 가이드 필요. SE가 HSM 동등 역할 수행 |
Aspect 4: Key Usage (키 사용)¶
| 수준 | 요구사항 | D'CENT 대응 |
|---|---|---|
| Level 1 | 서명 전 트랜잭션 검증. 기본 승인 절차 | WYSIWYS 디스플레이에서 트랜잭션 확인 후 물리 버튼 승인 |
| Level 2 | 다중 승인 요구(M-of-N). 서명자별 권한 분리. 트랜잭션 정책 적용 | 다중 서명 워크플로우 + RBAC. 정책 엔진 연동 필요 |
| Level 3 | 자동화된 정책 집행(금액 제한, 시간 제한). 실시간 이상 탐지. 서명 감사 추적 | 하드웨어 정책 엔진(DIF-02) + 대시보드 정책 관리 + 감사 로그(PRD-05) |
Aspect 5: Key Compromise Protocol (키 침해 대응)¶
| 수준 | 요구사항 | D'CENT 대응 |
|---|---|---|
| Level 1 | 침해 시 기본 대응 절차 문서화 | 디바이스 초기화 + 시드 백업 복구 절차 |
| Level 2 | 정형화된 인시던트 대응 계획. 키 교체 절차. 영향 범위 분석 프로세스 | 서명자 교체 워크플로우(PRD-11) + 인시던트 대응 매뉴얼 |
| Level 3 | 자동화된 침해 탐지. 키 자동 무효화. 자금 이동 자동 동결. 포렌식 지원 | 대시보드 이상 탐지 알림 + 긴급 동결 기능 설계 필요 |
Aspect 6: Keyholder Grant/Revoke Policies (키홀더 권한 정책)¶
| 수준 | 요구사항 | D'CENT 대응 |
|---|---|---|
| Level 1 | 키홀더 목록 관리. 기본 권한 부여/회수 절차 | RBAC 기반 역할 관리(PRD-03) |
| Level 2 | 정형화된 온보딩/오프보딩 절차. 다중 승인 기반 권한 변경. 권한 변경 이력 | 관리자 쿼럼 승인 기반 서명자 추가/제거. 변경 이력 감사 로그 |
| Level 3 | 자동화된 접근 제어 정책 집행. 시간 기반 권한 만료. ABAC 지원 | RBAC + ABAC 확장. 정책 엔진 자동 집행 |
Aspect 7: Third Party Audits (제3자 감사)¶
| 수준 | 요구사항 | D'CENT 대응 |
|---|---|---|
| Level 1 | 자체 보안 점검 | 내부 보안 리뷰 |
| Level 2 | 연 1회 이상 외부 보안 감사. 침투 테스트 | 외부 감사 계획 수립. 감사 대응 자료 자동 생성 기능 |
| Level 3 | 분기별 외부 감사. 실시간 모니터링. 감사 결과 공개 | 지속적 모니터링 체계. 감사 리포트 자동화 |
Aspect 8: Data Sanitization Policy (데이터 삭제 정책)¶
| 수준 | 요구사항 | D'CENT 대응 |
|---|---|---|
| Level 1 | 키 삭제 시 기본 보안 삭제 | SE 보안 삭제(제로필) 지원 |
| Level 2 | 정형화된 데이터 삭제 정책. 삭제 검증 절차. 디바이스 폐기 절차 | SE 보안 삭제 + 디바이스 초기화 검증 프로세스 |
| Level 3 | 자동화된 삭제 정책 집행. 삭제 증명서 발급. 물리적 파괴 절차 | 삭제 검증 리포트 생성 기능 |
Aspect 9: Proof of Reserve (지급 준비금 증명)¶
| 수준 | 요구사항 | D'CENT 대응 |
|---|---|---|
| Level 1 | 자산 보유량 확인 가능 | 대시보드에서 실시간 잔액 조회 |
| Level 2 | 정기적 Proof of Reserve 보고. 제3자 검증 가능 구조 | 온체인 잔액 검증 + 서명 증명 기능 |
| Level 3 | 실시간 Proof of Reserve. 자동화된 검증. 공개 감사 가능 | Merkle Tree 기반 PoR + 실시간 대시보드 |
Aspect 10: Audit Logs (감사 로그)¶
| 수준 | 요구사항 | D'CENT 대응 |
|---|---|---|
| Level 1 | 기본 트랜잭션 로그 기록 | 대시보드 트랜잭션 히스토리 |
| Level 2 | 변조 불가 감사 로그. 모든 시스템 액션 기록. 로그 보존 정책 | 변조 불가 로그 저장소(PRD-05). 오프라인/온라인 로그 동기화 |
| Level 3 | 실시간 로그 모니터링. 이상 패턴 자동 탐지. 법적 증거 수준 로그 | 실시간 모니터링 + 이상 탐지 알림 |
2.4. D'CENT 인증 목표 설정¶
목표: CCSS Level 2 (출시 시점) → Level 3 (12개월 이내)¶
Level 2 목표 설정 근거:
-
시장 진입 충분성: GTM Phase 1(한국) 진입 시 CCSS Level 2는 대부분의 국내 기관 고객이 요구하는 수준을 충족한다. 한국 시장에서 CCSS Level 3을 요구하는 고객은 극소수이며, SOC 2 Type II와 결합 시 한국/APAC 시장 커버가 가능하다.
-
경쟁사 벤치마크: Fireblocks, BitGo 등 주요 경쟁사의 보안 인증 수준은 CCSS Level 2 + SOC 2 Type II 조합이 표준이다. 출시 시점 Level 2 달성은 경쟁사 대비 동등한 인증 수준을 확보하는 것이다.
-
에어갭 아키텍처의 고유 장점: D'CENT의 에어갭 아키텍처는 Key Storage(Aspect 3), Key Usage(Aspect 4)에서 Level 2 요구사항을 설계 수준에서 자동 충족한다. 네트워크 격리가 대부분의 원격 공격 벡터를 원천 차단하기 때문이다.
-
현실적 달성 가능성: Level 2는 10개 Aspect 모두에서 중간 수준 이상을 달성해야 한다. 에어갭 아키텍처가 6-7개 Aspect에서 이미 Level 2를 충족하므로, 나머지 Aspect(Third Party Audits, Data Sanitization, Proof of Reserve)의 프로세스 수립에 집중하면 달성 가능하다.
Level 3 로드맵 (12개월 이내):
-
EU 진입 전 필수: GTM Phase 3(EU, 24-36개월) 진입 전 CCSS Level 3 달성이 목표이다. MiCA 규제 하에서 CCSS Level 3은 CASP 라이선스 심사 시 강력한 차별화 요소가 된다.
-
Level 2 → 3 갭: 주요 갭은 (a) 지리적 분산 키 저장, (b) 자동화된 정책 집행, (c) 분기별 외부 감사, (d) 실시간 PoR이다. 이 중 (a)와 (b)는 시스템 설계(Phase 5)에서 선반영하면 구현 시 갭이 최소화된다.
-
Fireblocks/BitGo 수준 달성: Level 3 달성 시 암호화폐 커스터디 업계 최고 수준의 보안 인증을 보유하게 되어, 글로벌 시장에서 D'CENT의 경쟁력이 크게 강화된다.
2.5. CCSS 아키텍처 요구사항 체크리스트¶
Level 2 필수 설계 요구사항¶
키 관리 (Aspects 1-4) - [ ] 키/시드 생성 시 DRBG 사용 검증 절차 — 컴포넌트: 콜드월렛(SE) - [ ] 최소 2-of-3 다중 서명 지원 — 컴포넌트: 콜드월렛 + 오프라인앱 - [ ] 키 저장소 이중화(primary 디바이스 + 금속 시드 백업) — 컴포넌트: 콜드월렛 - [ ] 서명 전 WYSIWYS 트랜잭션 표시 — 컴포넌트: 콜드월렛(디스플레이) - [ ] 서명자별 권한 분리 및 RBAC 적용 — 컴포넌트: 대시보드 + 오프라인앱 - [ ] 트랜잭션 정책 엔진(금액 제한, 화이트리스트) — 컴포넌트: 대시보드 + 콜드월렛
운영 보안 (Aspects 5-7) - [ ] 키 침해 대응 계획(인시던트 대응, 키 교체 절차) 수립 — 컴포넌트: 전체 - [ ] 정형화된 키홀더 온보딩/오프보딩 절차 — 컴포넌트: 대시보드 - [ ] 연 1회 이상 외부 보안 감사 계획 — 컴포넌트: 전체
데이터 관리 (Aspects 8-10) - [ ] 데이터 삭제 정책 및 디바이스 폐기 절차 — 컴포넌트: 콜드월렛 - [ ] 정기적 Proof of Reserve 보고 구조 — 컴포넌트: 대시보드 - [ ] 변조 불가 감사 로그(모든 액션 기록) — 컴포넌트: 대시보드 + 오프라인앱
Level 3 추가 설계 요구사항¶
키 관리 확장 - [ ] 다중 엔트로피 소스 결합(하드웨어 TRNG + 사용자 입력) — 컴포넌트: 콜드월렛(SE) - [ ] 키 세레모니 프로세스 자동화 — 컴포넌트: 오프라인앱 + 콜드월렛 - [ ] 지리적 분산 키 저장(최소 2개 이상 물리적 위치) — 컴포넌트: 운영 정책 - [ ] 하드웨어 수준 정책 집행(SE에서 정책 위반 트랜잭션 거부) — 컴포넌트: 콜드월렛(펌웨어)
운영 보안 확장 - [ ] 자동화된 키 침해 탐지 및 긴급 동결 — 컴포넌트: 대시보드 - [ ] ABAC(속성 기반 접근 제어) 확장 — 컴포넌트: 대시보드 + 정책 엔진 - [ ] 분기별 외부 감사 체계 — 컴포넌트: 전체
데이터 관리 확장 - [ ] 실시간 Proof of Reserve (Merkle Tree 기반) — 컴포넌트: 대시보드 - [ ] 실시간 로그 모니터링 및 이상 패턴 자동 탐지 — 컴포넌트: 대시보드 - [ ] 법적 증거 수준의 감사 로그 무결성 보장 — 컴포넌트: 대시보드
3. SOC 2 Type II 분석¶
3.1. SOC 2 Type II 개요¶
SOC 2(Service Organization Controls 2)는 AICPA(미국공인회계사협회)의 Trust Services Criteria(TSC)에 기반한 서비스 조직 보안 감사 프레임워크이다. Type II는 설계 적정성뿐만 아니라 일정 기간(통상 6-12개월) 동안의 운영 효과성을 검증한다.
엔터프라이즈 커스터디에서 SOC 2의 중요성: - Fireblocks, BitGo, Crypto.com 등 모든 주요 커스터디 사업자가 SOC 2 Type II를 보유 - 미국/APAC 기관 고객의 벤더 선정 시 SOC 2 Type II는 테이블 스테이크(최소 조건) - SOC 2 없이는 기관 고객의 실사(Due Diligence) 과정에서 탈락 - 한국 시장에서도 글로벌 기관 투자자 대응 시 요구됨
3.2. 5가지 TSC별 분석¶
3.2.1. Security (보안) — 필수¶
개요: 시스템 및 데이터의 무단 접근(물리적, 논리적) 차단
| TSC 기준 | 요구사항 | D'CENT 설계 반영사항 | 에어갭 장점 |
|---|---|---|---|
| CC6.1 | 논리적 접근 제어 | RBAC 기반 역할/권한 관리 | 에어갭으로 원격 접근 원천 차단 |
| CC6.2 | 시스템 접근 인증 | 다중 인증(PIN + 생체 + 하드웨어) | 물리적 디바이스 소유 필수 |
| CC6.3 | 접근 권한 관리 | 관리자 쿼럼 승인 기반 권한 변경 | — |
| CC6.6 | 외부 위협 관리 | 방화벽, IDS/IPS (대시보드) | 콜드월렛은 네트워크 미연결로 외부 위협 면역 |
| CC6.7 | 데이터 전송 보안 | QR/USB-C 에어갭 통신 암호화 | WiFi/BT 등 고위험 무선 통신 불사용 (USB-C는 콜드월렛 전용 허용) |
| CC6.8 | 악성코드 방지 | SE 격리 환경, 서명 앱 무결성 검증 | 에어갭으로 악성코드 주입 경로 차단 |
에어갭 아키텍처의 SOC 2 Security 고유 장점: - 공격 표면(attack surface)의 물리적 최소화: 네트워크 연결이 없으므로 원격 공격 벡터의 95% 이상이 원천 차단 - "Security by isolation" 원칙이 SOC 2 감사 시 강력한 보안 근거로 작용 - 감사인에게 "이 시스템은 네트워크에 연결되지 않습니다"는 대부분의 네트워크 관련 TSC를 자동 충족하는 근거
설계 단계 요구사항: - RBAC 역할 체계 설계 (PRD-03) - 에어갭 통신 프로토콜 암호화 설계 (SYS-02) - SE 기반 키 격리 아키텍처 설계 (SYS-01) - 대시보드 접근 제어 및 인증 설계
운영 단계 요구사항: - 접근 권한 정기 검토 프로세스 - 보안 이벤트 모니터링 및 대응 체계 - 취약점 관리 및 패치 프로세스
3.2.2. Availability (가용성)¶
개요: 서비스 가용성 목표 달성 및 재해 복구
| TSC 기준 | 요구사항 | D'CENT 설계 반영사항 | 에어갭 과제 |
|---|---|---|---|
| A1.1 | 가용성 목표 및 SLA | 대시보드 SLA 정의, 서명 프로세스 RTO/RPO | 에어갭은 "항상 가용"이 아닌 "필요 시 가용" 모델 |
| A1.2 | 환경 보호 | 데이터센터/서버 환경 보호 | 콜드월렛은 물리적 보관 환경 정의 필요 |
| A1.3 | 백업 및 복구 | 시드 백업(금속 시드), 대시보드 데이터 백업 | 에어갭 디바이스 교체/복구 절차 설계 필요 |
에어갭 환경에서의 가용성 설계 과제: 1. 서명 가용성: 에어갭 환경에서 긴급 서명 시 물리적으로 디바이스에 접근해야 함. 긴급 출금 시나리오에서의 RTO(Recovery Time Objective) 정의 필요. 2. 디바이스 장애 대응: 콜드월렛 고장 시 백업 디바이스로의 전환 절차. 금속 시드 백업에서의 복구 시간 목표 설정. 3. 대시보드 가용성: 온라인 대시보드는 일반 웹 서비스와 동일한 가용성 설계(HA, DR) 적용.
설계 단계 요구사항: - 재해 복구 시나리오별 RTO/RPO 정의 (PRD-07) - 백업 디바이스 관리 및 복구 절차 설계 - 대시보드 고가용성 아키텍처 설계 (SYS-06)
운영 단계 요구사항: - 정기 재해 복구 드릴 실시 - 백업 검증 절차 운영 - 가용성 메트릭 모니터링 및 리포팅
3.2.3. Processing Integrity (처리 무결성)¶
개요: 시스템 처리의 완전성, 정확성, 적시성, 승인 보장
| TSC 기준 | 요구사항 | D'CENT 설계 반영사항 | WYSIWYS 연결 |
|---|---|---|---|
| PI1.1 | 처리 무결성 정의 | 트랜잭션 처리 정확성 기준 정의 | WYSIWYS가 처리 무결성의 핵심 메커니즘 |
| PI1.2 | 입력 데이터 검증 | 트랜잭션 데이터 유효성 검증 | 하드웨어에서 트랜잭션 파싱 및 표시로 검증 |
| PI1.3 | 오류 처리 | 서명 실패, 통신 오류 처리 | 에어갭 통신 오류 복구 절차 |
WYSIWYS(What You See Is What You Sign) 기능과의 연결: - D'CENT X 디스플레이에서 트랜잭션의 수신 주소, 금액, 수수료를 정확히 표시한 후 물리 버튼으로 승인하는 WYSIWYS 기능은 SOC 2 Processing Integrity의 핵심 제어 수단 - 하드웨어 수준에서 트랜잭션 무결성을 검증하므로, 소프트웨어 기반 검증보다 높은 수준의 처리 무결성 보장 - DIF-01(WYSIWYS 기능 정의)이 SOC 2 PI 요구사항과 직결
설계 단계 요구사항: - WYSIWYS 트랜잭션 파싱 범위 정의 (DIF-01) - 트랜잭션 유효성 검증 규칙 설계 - 에어갭 통신 오류 복구 프로토콜 설계
운영 단계 요구사항: - 트랜잭션 처리 정확성 모니터링 - 오류 발생 시 대응 프로세스
3.2.4. Confidentiality (기밀성)¶
개요: 기밀 정보(키 데이터, 고객 정보)의 보호
| TSC 기준 | 요구사항 | D'CENT 설계 반영사항 | SE 기반 키 격리 |
|---|---|---|---|
| C1.1 | 기밀 정보 식별 | 프라이빗 키, 시드, 정책 데이터 분류 | SE 내부에서만 프라이빗 키 처리, 외부 노출 불가 |
| C1.2 | 기밀 정보 보호 | 암호화, 접근 제한 | SE 하드웨어 수준 암호화. 에어갭으로 전송 경로 없음 |
SE(Secure Element) 기반 키 격리의 SOC 2 장점: - 프라이빗 키가 SE 외부로 추출 불가능한 구조는 기밀성의 최고 수준 보장 - "키가 이 하드웨어를 떠나지 않습니다"는 SOC 2 감사에서 가장 강력한 기밀성 근거 - CC EAL5+ 인증이 SE의 기밀성 보장 수준을 제3자가 검증한 것
설계 단계 요구사항: - 데이터 분류 체계(키 데이터, 정책 데이터, 운영 데이터) 설계 - SE 기반 키 격리 아키텍처 설계 (SYS-01) - 에어갭 통신 시 데이터 최소 노출 원칙 적용
운영 단계 요구사항: - 기밀 데이터 취급 절차 운영 - 접근 로그 모니터링
3.2.5. Privacy (개인정보 보호)¶
개요: 개인 정보의 수집, 사용, 보관, 공개, 폐기 관리
| TSC 기준 | 요구사항 | D'CENT 설계 반영사항 | 적용 범위 |
|---|---|---|---|
| P1-P8 | 개인정보 처리 전 생명주기 | 고객 데이터 처리 정책 | 수탁 서비스 사업자 티어에서 주로 해당 |
적용 범위: - 셀프 커스터디 기업 티어: 개인정보 처리 범위가 제한적(관리자 계정 정보 수준). Privacy TSC의 적용 범위 최소화 가능. - 수탁 서비스 사업자 티어: 고객(최종 사용자)의 개인정보를 처리하므로 Privacy TSC 전면 적용. GDPR, 개인정보보호법 등과 연계 필요. - 시스템 설계 시 두 티어를 분리하여 Privacy 요구사항 적용 범위를 명확히 해야 함.
설계 단계 요구사항: - 개인정보 처리 범위 정의(티어별 차등) - 데이터 최소 수집 원칙 적용 설계 - 개인정보 삭제 기능 설계
운영 단계 요구사항: - 개인정보 처리 방침 수립 - 정보 주체 요청 대응 프로세스
3.3. 설계 단계 vs 운영 단계 요구사항 요약¶
| 구분 | 설계 단계 (Phase 3-6에서 반영) | 운영 단계 (제품 출시 후 반영) |
|---|---|---|
| Security | RBAC, 에어갭 프로토콜, SE 격리 아키텍처 | 접근 권한 정기 검토, 보안 이벤트 대응, 패치 관리 |
| Availability | RTO/RPO 정의, HA 아키텍처, 백업 설계 | 재해 복구 드릴, 백업 검증, 가용성 모니터링 |
| Processing Integrity | WYSIWYS 범위 정의, 유효성 검증 규칙 | 처리 정확성 모니터링, 오류 대응 |
| Confidentiality | 데이터 분류, SE 키 격리, 데이터 최소 노출 | 기밀 데이터 취급 절차, 접근 로그 모니터링 |
| Privacy | 개인정보 처리 범위, 삭제 기능 | 처리 방침, 정보 주체 요청 대응 |
핵심 포인트: 설계 단계에서 SOC 2 요구사항을 선반영하면, 운영 단계에서는 프로세스 수립과 증적 관리에 집중할 수 있다. 설계를 변경하는 것보다 프로세스를 수립하는 것이 비용이 훨씬 적으므로, Phase 3-5에서 SOC 2 설계 요구사항을 최대한 반영해야 한다.
4. ISO 27001:2022 분석¶
4.1. ISO 27001:2022 개요¶
ISO 27001:2022는 정보보안 관리체계(ISMS)의 국제 표준으로, 2022년 개정판에서 Annex A 컨트롤이 114개에서 93개로 재구성되었다. 4개 테마(Organizational, People, Physical, Technological)로 분류되며, 암호화폐 커스터디 시스템에 적용 가능한 핵심 컨트롤을 아래에 식별한다.
엔터프라이즈 커스터디에서 ISO 27001의 중요성: - MiCA 규제 하에서 CASP 라이선스 심사 시 ISO 27001 인증이 거버넌스 체계의 증거로 활용 - EU, APAC 시장에서 SOC 2와 함께 이중 인증(dual certification)으로 신뢰도 극대화 - ISMS-P(한국)와 ISO 27001의 약 70% 컨트롤이 중복되어, ISO 27001 인증 시 ISMS-P 대응 공수 절감
4.2. 핵심 컨트롤 식별 (Annex A — 테마별)¶
4.2.1. Organizational Controls (조직적 컨트롤)¶
| 컨트롤 ID | 명칭 | 커스터디 적용 | 설계 반영 방법 |
|---|---|---|---|
| A.5.1 | 정보보안 정책 | 커스터디 보안 정책 수립 | 정책 관리 기능 설계. 정책 버전 관리 및 이력 추적 |
| A.5.2 | 정보보안 역할 및 책임 | RBAC 역할별 보안 책임 정의 | PRD-03의 RBAC 역할 체계와 연계 |
| A.5.3 | 직무 분리 | 서명자, 승인자, 관리자 직무 분리 | 다중 서명에서의 역할 분리 강제 |
| A.5.10 | 정보 자산의 허용 가능한 사용 | 키/디바이스 사용 정책 | 디바이스 사용 정책 및 사용 로그 기록 |
| A.5.15 | 접근 제어 | 시스템 접근 권한 관리 | RBAC + 다중 인증 설계 |
| A.5.23 | 클라우드 서비스 보안 | 대시보드의 클라우드/온프레미스 보안 | DIF-04 온프레미스 아키텍처와 연계 |
| A.5.24 | 정보보안 인시던트 관리 계획 | 키 침해, 시스템 침해 대응 | 인시던트 대응 절차 및 에스컬레이션 설계 |
| A.5.29 | 비즈니스 연속성을 위한 정보보안 | 커스터디 서비스 연속성 | 재해 복구, 키 백업, 디바이스 교체 설계 |
| A.5.30 | 비즈니스 연속성을 위한 ICT 준비 | IT 시스템 복구 | 대시보드 DR 아키텍처, 데이터 백업 |
4.2.2. People Controls (인적 컨트롤)¶
| 컨트롤 ID | 명칭 | 커스터디 적용 | 설계 반영 방법 |
|---|---|---|---|
| A.6.1 | 심사(Screening) | 키홀더/서명자 배경 조사 | 서명자 온보딩 프로세스에 신원 확인 절차 포함 |
| A.6.2 | 고용 조건 | 키홀더의 보안 의무 | 키홀더 계약 및 보안 서약 관리 |
| A.6.3 | 인식, 교육 및 훈련 | 서명자 보안 교육 | 키 세레모니 훈련, 보안 인식 교육 추적 |
| A.6.5 | 고용 종료/변경 시 책임 | 서명자 오프보딩 | 키홀더 권한 즉시 회수, 서명자 교체 워크플로우 |
4.2.3. Physical Controls (물리적 컨트롤)¶
| 컨트롤 ID | 명칭 | 커스터디 적용 | 설계 반영 방법 |
|---|---|---|---|
| A.7.1 | 물리적 보안 경계 | 콜드월렛 보관 장소 보안 | 디바이스 보관 환경 요구사항 정의 |
| A.7.2 | 물리적 출입 통제 | 디바이스 접근 통제 | 보관 장소 출입 로그, 이중 잠금 |
| A.7.4 | 물리적 보안 모니터링 | 보관 환경 모니터링 | CCTV, 환경 센서(온도, 습도) 요구사항 |
| A.7.9 | 사무실 외부 자산 보안 | 디바이스 이동 시 보안 | 디바이스 이동 절차, 분실/도난 대응 |
| A.7.10 | 저장 매체 | 시드 백업 매체(금속 시드) 관리 | 금속 시드 보관 환경 및 접근 통제 |
4.2.4. Technological Controls (기술적 컨트롤)¶
| 컨트롤 ID | 명칭 | 커스터디 적용 | 설계 반영 방법 |
|---|---|---|---|
| A.8.1 | 사용자 엔드포인트 디바이스 | 콜드월렛, 서명 앱 디바이스 | 디바이스 보안 정책, 무결성 검증 |
| A.8.2 | 특권 접근 권한 | Admin 권한 관리 | Admin 역할 다중 승인, 특권 세션 로깅 |
| A.8.3 | 정보 접근 제한 | 키/정책 데이터 접근 제한 | 데이터 분류별 접근 제어 매핑 |
| A.8.5 | 보안 인증 | 사용자 인증 메커니즘 | PIN + 생체 + 하드웨어 다중 인증 |
| A.8.9 | 구성 관리 | 시스템 구성 보안 | 디바이스/앱/대시보드 보안 구성 기준선 |
| A.8.12 | 데이터 유출 방지 | 키 데이터 유출 차단 | SE 기반 키 격리, 에어갭 통신 제한 |
| A.8.15 | 로깅 | 시스템 이벤트 로깅 | 감사 로그 설계 (PRD-05) |
| A.8.16 | 모니터링 | 보안 이벤트 모니터링 | 실시간 모니터링 대시보드 |
| A.8.20 | 네트워크 보안 | 대시보드 네트워크 보안 | TLS, 방화벽, 네트워크 세그멘테이션 |
| A.8.24 | 암호화 사용 | 데이터 암호화 | 에어갭 통신 암호화, 저장 데이터 암호화 |
| A.8.25 | 소프트웨어 개발 보안 | 보안 개발 라이프사이클 | 펌웨어/앱 보안 개발 가이드라인 |
| A.8.28 | 보안 코딩 | 코딩 표준 | 펌웨어/서명 앱 보안 코딩 규칙 |
식별된 핵심 컨트롤 총계: 28개 (Organizational 9개, People 4개, Physical 5개, Technological 12개) — 목표 20개 초과 달성
4.3. ISMS-P와의 매핑 관계¶
ISO 27001:2022와 한국 ISMS-P 인증 기준은 약 70%가 중복된다. 아래는 주요 매핑 관계이다:
| ISO 27001 영역 | ISMS-P 대응 영역 | 중복률 | 비고 |
|---|---|---|---|
| A.5 Organizational | 관리체계 수립/운영 | 약 80% | 정책, 역할, 접근 제어 등 대부분 대응 |
| A.6 People | 인적 보안 | 약 75% | 교육, 고용 관리 대응. ISMS-P가 더 상세 |
| A.7 Physical | 물리적 보안 | 약 70% | 출입 통제, 환경 보안 대응 |
| A.8 Technological | 보호대책 요구사항 | 약 65% | ISMS-P가 개인정보 보호 항목 추가 보유 |
"Audit once, certify for multiple" 전략: - ISO 27001 인증을 먼저 취득하면, ISMS-P 인증 시 약 70%의 증적(Evidence)을 재활용 가능 - 추가로 필요한 것은 ISMS-P 고유의 개인정보 보호 항목과 한국 법규 특화 항목 - 자세한 ISMS-P 분석은 m2-02-regulatory-landscape.md에서 다룸 (CMP-04)
5. 인증 로드맵¶
5.1. GTM 타임라인 대비 인증 취득 일정¶
Month 0 6 12 18 24 30 36
|---------|---------|---------|---------|---------|---------|---------|
GTM: [ 한국 시장 진입 ][ APAC 확장 ][ EU 진입 ]
CCSS: [-- Level 2 준비 --][L2 인증][----- Level 3 준비 -----][L3 인증]
SOC2: [--- 설계 반영 ---][-- Type I --][-- Type II 감사 기간 --][인증]
ISO: [--- 설계 반영 ---][----------- ISMS 구축 -----------][인증]
ISMS-P:[-- ISMS-P 준비 --][인증]
| 인증 | 준비 시작 | 인증 취득 목표 | 소요 기간 | 연계 GTM 단계 |
|---|---|---|---|---|
| ISMS-P | Month 0 | Month 6-9 | 6-9개월 | Phase 1 (한국) — 한국 VASP 필수 인증 |
| CCSS Level 2 | Month 0 | Month 9-12 | 9-12개월 | Phase 1 (한국) — 출시 시점 |
| SOC 2 Type I | Month 6 | Month 12-15 | 6-9개월 | Phase 2 (APAC) 준비 |
| SOC 2 Type II | Month 12 | Month 18-24 | 6-12개월 | Phase 2 (APAC) — 기관 고객 필수 |
| ISO 27001 | Month 6 | Month 18-24 | 12-18개월 | Phase 3 (EU) 준비 |
| CCSS Level 3 | Month 12 | Month 24-30 | 12-18개월 | Phase 3 (EU) — 프리미엄 인증 |
5.2. 인증 간 시너지 — "Audit once, certify for multiple"¶
3개 인증의 중복 컨트롤을 분석하면, 통합 감사 전략을 통해 인증 취득 비용과 시간을 절감할 수 있다.
| 컨트롤 영역 | CCSS | SOC 2 | ISO 27001 | 중복 |
|---|---|---|---|---|
| 접근 제어 | Aspect 6 (Keyholder Policies) | CC6.1-6.3 (Security TSC) | A.5.15, A.8.2-3 | 3중 중복 |
| 키 관리 | Aspects 1-4 (Key lifecycle) | CC6.7 (Confidentiality) | A.8.24 (Cryptography) | 3중 중복 |
| 감사 로그 | Aspect 10 (Audit Logs) | CC7.1-2 (Monitoring) | A.8.15-16 (Logging) | 3중 중복 |
| 인시던트 대응 | Aspect 5 (Key Compromise) | CC7.3-4 (Response) | A.5.24-26 (Incident) | 3중 중복 |
| 사업 연속성 | — | A1.1-3 (Availability) | A.5.29-30 (Continuity) | 2중 중복 |
| 물리적 보안 | — | CC6.4 (Physical) | A.7.1-4 (Physical) | 2중 중복 |
| 변경 관리 | — | CC8.1 (Change Mgmt) | A.8.9 (Configuration) | 2중 중복 |
통합 감사 전략: 1. ISO 27001 ISMS 구축을 베이스로 삼고, CCSS와 SOC 2의 고유 항목만 추가 매핑 2. 증적(Evidence) 저장소를 단일화하여 3개 인증에 공유 3. 내부 감사 프로세스를 3개 인증 기준으로 통합 운영 4. 외부 감사 시 동일 증적을 3개 인증 기준으로 동시 평가
예상 비용 절감: - 개별 취득 대비 30-40% 비용 절감 (중복 감사 및 증적 생성 비용 제거) - 내부 인력 투입 50% 절감 (통합 운영 프로세스)
5.3. 비용 및 리소스 개략 추정¶
| 항목 | 비용 범위 | 비고 |
|---|---|---|
| CCSS Level 2 인증 | $30K-50K | 감사 비용 + 컨설팅. 연 갱신 비용 $10-15K |
| CCSS Level 3 인증 | $50K-80K | Level 2 대비 추가 감사 및 프로세스 수립 비용 |
| SOC 2 Type II | $80K-150K | Big 4 또는 전문 감사법인. 6-12개월 감사 기간 |
| ISO 27001:2022 | $50K-100K | ISMS 구축 컨설팅 + 인증 심사. 연 감시 심사 $20-30K |
| ISMS-P | ₩30M-50M | 한국 인증기관 심사. ISO 27001과 통합 시 추가 비용 최소화 |
| 내부 인력 | 전담 2-3명 | 인증 담당자, 보안 엔지니어, 컴플라이언스 오피서 |
| 총 예상 비용 (3년) | $300K-500K | 통합 전략 적용 시. 개별 취득 시 $500K-800K |
6. Phase 3-6 설계 시 참조 사항¶
6.1. 아키텍처 제약조건 요약¶
| 제약조건 | 출처 | 컴포넌트 | Must by Design | Can Add Later |
|---|---|---|---|---|
| SE 내부 키 생성/저장/사용 (키가 SE 외부로 노출 불가) | CCSS Aspects 1-4, SOC 2 Confidentiality | 콜드월렛 | Must | — |
| 최소 2-of-N 다중 서명 | CCSS Level 2, SOC 2 Security | 콜드월렛 + 오프라인앱 | Must | — |
| RBAC 기반 역할/권한 분리 | CCSS Aspect 6, SOC 2 Security, ISO A.5.2-3 | 대시보드 + 오프라인앱 | Must | — |
| WYSIWYS 트랜잭션 표시 | CCSS Aspect 4, SOC 2 Processing Integrity | 콜드월렛(디스플레이) | Must | — |
| 변조 불가 감사 로그 | CCSS Aspect 10, SOC 2 Security, ISO A.8.15 | 대시보드 + 오프라인앱 | Must | — |
| 에어갭 통신 암호화 (QR/USB-C) | SOC 2 Security CC6.7, ISO A.8.24 | 전체 | Must | — |
| 재해 복구 설계 (RTO/RPO, 백업) | SOC 2 Availability, ISO A.5.29-30 | 전체 | Must | — |
| 트랜잭션 정책 엔진 | CCSS Level 2 Aspect 4, SOC 2 Security | 대시보드 + 콜드월렛 | Must | — |
| 하드웨어 정책 엔진 (SE에서 정책 집행) | CCSS Level 3 | 콜드월렛(펌웨어) | — | Add for L3 |
| 실시간 PoR (Merkle Tree) | CCSS Level 3 Aspect 9 | 대시보드 | — | Add for L3 |
| 이상 패턴 자동 탐지 | CCSS Level 3 Aspect 10, ISO A.8.16 | 대시보드 | — | Add for L3 |
| 지리적 분산 키 저장 | CCSS Level 3 Aspect 3 | 운영 정책 | — | Add for L3 |
6.2. 페이즈별 설계 참조 가이드¶
| 페이즈 | 참조할 인증 요구사항 | 핵심 설계 포인트 |
|---|---|---|
| Phase 3 (Core Product) | CCSS Aspects 1-6 (Level 2), SOC 2 Security/PI | 다중 서명, RBAC, 정책 엔진, 감사 로그, 키 관리 |
| Phase 4 (Differentiation) | CCSS Level 3 Aspects 4,6, SOC 2 PI | WYSIWYS, 하드웨어 정책 엔진, 셀프 커스터디 구조 |
| Phase 5 (System Architecture) | SOC 2 Security/Availability, ISO 27001 A.8, CCSS Aspects 3,10 | 3-Zone 아키텍처, 에어갭 프로토콜, 모니터링 |
| Phase 6 (Firmware) | CCSS Aspects 1,3,4, SOC 2 PI | SE 키 관리, 서명 인터페이스, WYSIWYS 파싱 |
7. 부록: 용어 정의¶
| 용어 | 정의 |
|---|---|
| CCSS | CryptoCurrency Security Standard — 암호화폐 시스템 전용 보안 표준 |
| SOC 2 | Service Organization Controls 2 — AICPA 기반 서비스 보안 감사 프레임워크 |
| ISO 27001 | 정보보안 관리체계(ISMS) 국제 표준 |
| TSC | Trust Services Criteria — SOC 2의 5가지 보안 기준 |
| SE | Secure Element — 보안 전용 하드웨어 칩 |
| TRNG | True Random Number Generator — 진성 난수 생성기 |
| DRBG | Deterministic Random Bit Generator — 결정적 난수 생성기 |
| WYSIWYS | What You See Is What You Sign — 서명 내용 표시 기능 |
| RBAC | Role-Based Access Control — 역할 기반 접근 제어 |
| ABAC | Attribute-Based Access Control — 속성 기반 접근 제어 |
| PoR | Proof of Reserve — 지급 준비금 증명 |
| RTO | Recovery Time Objective — 복구 시간 목표 |
| RPO | Recovery Point Objective — 복구 시점 목표 |
| ISMS-P | 개인정보 및 정보보호 관리체계 인증 (한국) |
작성일: 2026-03-28 Phase 2 Plan 01 산출물 — CMP-01, CMP-02 요구사항 충족 다음 참조: m2-03-compliance-architecture-matrix.md (컴플라이언스-아키텍처 통합 매트릭스)
관련 문서¶
- 컴플라이언스-아키텍처 통합 매트릭스 -- 규제 준수
- 글로벌 규제 환경 분석: EU, 한국, 미국, APAC -- 규제 준수