v0.2

Layer 2 수탁 사업자 세그먼트 델타 (Custody Service Provider Segment Delta)¶

1. Executive Summary¶

본 문서는 D'CENT Enterprise의 Layer 2 수탁 사업자(CSP) 세그먼트 델타이다. e2e-core-flow.md(Layer 1)에서 정의한 5단계 E2E 플로우를 변경하지 않고, 수탁 서비스 사업자(S5~S6)에 고유한 차별화 요소를 [CSP Delta] {단계명} Step N: 형식으로 기술한다.

적용 시나리오:

시나리오	조합	특성	예상 비중
S5	CSP + Zero Cloud + 콜드룸	규제 준수 대형 수탁 사업자. 자체 데이터센터 + 콜드룸. CCSS Level 3	5-10%
S6	CSP + Hybrid + 비콜드룸	신규 진입 수탁 사업자. 서명 온프레미스 + 대시보드 클라우드	5-8%

CSP 세그먼트의 핵심 특성: - 타사 자산 관리: 고객사의 자산을 수탁하므로 규제/보험/멀티테넌시 요건이 가장 복잡 - 이중 승인 체계: 수탁 사업자 + 고객사가 TX 승인에 공동 참여 (Level 0~3) - 테넌트 격리: 보안 경계 수준의 격리 (DB 필터가 아닌 에어갭과 동급) - VASP 라이선스: 수탁 서비스 제공을 위한 가상자산 사업자 라이선스 필수 - 고빈도 다양 TX: 일 10~100건+, 다수 고객사의 다양한 금액/유형

SC/TI 세그먼트와의 근본적 차이:

차원	SC (셀프 커스터디)	CSP (수탁 사업자)	TI (토큰 발행)
자산 소유	자사 자산	타사 자산	프로젝트 트레저리
거버넌스	내부 단일 체계	이중 승인 (내부+고객)	분산 거버넌스
테넌시	단일 테넌트	멀티테넌트	단일 테넌트
규제	업종별 상이	VASP 필수	불명확
사고 통보	내부만	고객사+규제기관	커뮤니티

2. 도입 델타 (Adoption Delta)¶

[CSP Delta] Adoption Step 1: 보안 요건 평가 -- VASP 라이선스 전제¶

Layer 1의 A-Step 1에서 CSP는 다음이 다르다:

CSP 필수 전제조건: VASP 라이선스 보유 또는 획득 계획

라이선스 확인: 관할권별 VASP(Virtual Asset Service Provider) 라이선스 보유 확인. 미보유 시 취득 계획과 일정 수립
규제 기관 보고 체계: 라이선스 조건에 따른 정기 보고 체계 구축 계획 (SAR, 대량 거래 보고, 자산 증명 등)
보험 요건: 수탁 자산에 대한 보험 가입 요건 확인 (사이버 보험, 범죄 보험, E&O 보험)
CCSS Level 2+ 필수: 수탁 사업자는 CCSS Level 2 이상 인증이 사실상 필수 (고객 신뢰 + 규제 기대)

[CSP Delta] Adoption Step 2: 배포 모델 선택 -- 규제 제약¶

CSP의 배포 모델 선택은 SC와 달리 규제 요건이 가장 큰 제약:

배포 모델	CSP 적합성	근거
Zero Cloud	적합 (S5)	인프라 완전 통제. 규제/감사/보험 최적. CCSS Level 3 가능
Hybrid	조건부 적합 (S6)	서명/키 온프레미스로 핵심 보안 확보. 대시보드 클라우드 의존 리스크 존재하나 신규 진입 수탁 사업자에게 현실적
SaaS	부적합	수탁 사업자가 SaaS에 의존하면 인프라 통제 부족으로 규제/보험 요건 미충족

SaaS 배제 사유: 수탁 사업자는 고객 자산에 대한 관리 의무가 있으므로, 인프라를 제3자에게 의존하면 수탁 책임을 온전히 이행할 수 없다. scenario-matrix.md에서 CSP-SA-CR(#11)과 CSP-SA-NCR(#12) 모두 비유효로 판정됨

[CSP Delta] Adoption Step 3: 물리 환경 -- 테넌트 격리 물리 설계¶

S5(콜드룸): 콜드룸 내 테넌트별 격리 구역 설계 가능 (물리적 분리 강화)
S6(비콜드룸): Grade A 보완 조치 필수 (Grade B/C는 수탁 사업자에게 불충분). 테넌트별 독립 보안 캐비닛 권장

[CSP Delta] Adoption Step 5: 킥오프 -- 멀티테넌트 아키텍처 계획¶

테넌트 수용 계획: 초기 테넌트 수, 목표 테넌트 수, 확장 일정
SLA 등급 정의: 테넌트별 SLA 등급 (Premium / Standard / Basic) 구조 설계
요금 체계: 테넌트별 과금 모델 (자산 규모 기반, TX 건수 기반, 월정액 등)
규제 기관 사전 협의: 솔루션 도입을 규제 기관에 사전 통보/협의 (필요 시)

3. 온보딩 델타 (Onboarding Delta)¶

CSP의 온보딩은 2개 레벨로 구분된다: - (a) CSP 자체 온보딩: 수탁 사업자 자신의 인프라/정책 설정 (1회) - (b) 고객사(테넌트) 온보딩: 새 고객사를 테넌트로 추가하는 반복 플로우 (고객마다 반복)

3.1. CSP 자체 온보딩¶

[CSP Delta] Onboarding Step 1: 인프라 설정 -- 멀티테넌트 아키텍처¶

Layer 1의 O-Step 1에 추가:

테넌트 관리 시스템: 멀티테넌트 관리 레이어 구축 (테넌트 생성/삭제/일시정지 API)
데이터 파티셔닝: 테넌트별 독립 데이터 파티션 구성 (5.1 테넌트 격리 설계 참조)
테넌트별 독립 모니터링: 테넌트별 SLA 모니터링, 알림, 리포팅 파이프라인 구성
규제 리포팅 인프라: SAR 자동 생성, 대량 거래 자동 탐지, 자산 증명 리포트 생성 시스템

[CSP Delta] Onboarding Step 3: 키 세레모니 -- 마스터 키 세레모니¶

CSP 자체 온보딩 시 수행하는 키 세레모니는 Layer 1 O-Step 3와 구조적으로 동일하되, 수탁 사업자의 마스터 키 세트를 생성:

마스터 서명자: CSP 내부 직원으로만 구성 (고객사 참여 없음)
마스터 M-of-N: CSP 운영의 최고 권한 서명 구성 (예: 5-of-7)
용도: 테넌트 관리 정책 변경, CSP 자체 자산 관리, 비상 시 테넌트 자산 보호 조치
마스터 키와 테넌트 키 완전 분리: 마스터 키로 테넌트 자산에 직접 접근 불가 (보안 경계)

[CSP Delta] Onboarding Step 5: 정책 초기 설정 -- CSP 레벨 정책¶

테넌트 온보딩 기본 정책 템플릿: 새 테넌트 추가 시 적용될 기본 정책 세트
이중 승인 기본 레벨: 신규 테넌트의 기본 이중 승인 레벨 설정 (Level 0~3 중 기본값)
규제 준수 기본 정책: SAR 임계값, 대량 거래 보고 기준, 본인 확인(KYC) 요건
SLA 기본 설정: 응답 시간, 서명 완료 시간, 가용성 목표

3.2. 고객사(테넌트) 온보딩 -- 반복 플로우¶

[CSP Delta] Onboarding Step 3-T: 테넌트 키 세레모니¶

새 고객사(테넌트)를 추가할 때마다 수행하는 반복 플로우:

테넌트 온보딩 절차:

단계	액션	참여자	산출물
T-1	고객 계약 체결 + KYC/AML 완료	CSP 영업 + 컴플라이언스	고객 프로필, KYC 기록
T-2	테넌트 생성 (시스템에 격리 공간 할당)	CSP Admin	테넌트 ID, 격리 파티션
T-3	이중 승인 레벨 결정 (Level 0~3, 아래 상세)	CSP + 고객 합의	이중 승인 설정 문서
T-4	테넌트 전용 키 세레모니	CSP 서명자 + 고객 서명자 (Level 2~3)	테넌트 월렛 주소
T-5	테넌트 정책 설정 (화이트리스트/한도/M-of-N)	CSP Admin + 고객 합의	정책 설정 문서
T-6	테스트 TX	CSP + 고객 (Level에 따라)	테스트 결과
T-7	테넌트 활성화 + SLA 모니터링 개시	CSP	활성 테넌트

테넌트별 D'CENT X 세트: 각 테넌트에 독립된 D'CENT X 디바이스 세트 할당 (테넌트 격리 원칙). 하나의 D'CENT X가 여러 테넌트의 키를 보유하지 않음
이중 승인 레벨은 고객사와 합의: 고객사의 참여 의지, 기술 역량, 규제 요건에 따라 Level 0~3 중 결정

4. 이중 승인 체계 (Dual Approval System) -- SEG-04 상세 설계¶

수탁 사업자(CSP)의 가장 핵심적인 차별화 요소. 고객사가 자신의 자산에 대한 TX 승인에 참여하는 수준을 4단계로 정의한다.

4.1. Level 0: 완전 위임 (Full Delegation)¶

항목	내용
고객사 참여	없음. 수탁 사업자에 완전 위임
M-of-N 구성	예: 3-of-5, 전원 CSP 서명자
적용 대상	소규모 기관, 운영 편의 우선, 기술 역량 없는 고객
고객 편의	최대 (아무것도 안 해도 됨)
고객 통제	최소 (수탁 사업자 신뢰에 전적 의존)

Level 0 서명 플로우 (signing-core-flow.md 참조):

Step 1 (TX 생성): CSP Initiator가 고객 요청 또는 자동 규칙에 의해 TX 생성
Step 2 (정책 검증): CSP 내부 Approver M명이 승인. 고객사 참여 없음
Step 3~7 (에어갭 서명): CSP 서명자가 CSP 환경에서 서명 수행
Step 8~9 (브로드캐스트): 통상 절차
고객 통보: TX 완료 후 고객사에 결과 통보 (사후 통보)

리스크: 고객사가 비인가 TX를 사전에 차단할 수 없음. CSP 내부 부정 행위에 대한 방어 최소.

4.2. Level 1: 통보형 (Notification with Veto)¶

항목	내용
고객사 참여	TX 알림 수신 + 거부권만 보유 (시한 내 거부 없으면 자동 진행)
M-of-N 구성	예: 3-of-5, CSP 서명자 전원 + 고객 거부 타이머
적용 대상	중견 기관, 감시만 원하는 고객, 자체 서명 역량은 없으나 통제는 원하는 고객
고객 편의	높음 (알림 확인만)
고객 통제	제한적 (거부만 가능, 승인은 CSP)

Level 1 서명 플로우:

Step 1 (TX 생성): CSP Initiator가 TX 생성
Step 2 (정책 검증): CSP 내부 Approver 승인 시작 + 동시에 고객사에 TX 알림 발송
[CSP Delta] Step 2 거부 타이머: 고객사에게 거부 시한 부여 (기본 2시간, 설정 가능)
고객사가 시한 내 거부(Veto) -> TX 즉시 취소, CSP에 거부 사유 전달
고객사가 시한 내 무응답 -> 자동 승인으로 진행
고객사가 명시적 승인 -> 즉시 진행 (시한 소진 불필요)
Step 3~9: CSP 서명자가 서명 수행 (통상 절차)

타이머 설정:

TX 금액	기본 거부 타이머	연장 가능
소액 ($10K 미만)	30분	불가
중액 ($10K-500K)	2시간	1회, +2시간
대액 ($500K 이상)	4시간	2회, 각 +4시간

4.3. Level 2: 공동 승인 (Co-Approval)¶

항목	내용
고객사 참여	M-of-N 중 최소 1개를 고객사 서명자가 서명
M-of-N 구성	예: 3-of-5 = CSP 서명자 2명 + 고객사 서명자 1명
적용 대상	대형 기관, 능동적 참여 원하는 고객, 자체 D'CENT X 보유 의지 있는 고객
고객 편의	중간 (서명 행위 필요)
고객 통제	높음 (거부권 + 능동적 참여)

Level 2 서명 플로우:

Step 1 (TX 생성): CSP Initiator가 TX 생성 (고객 요청 기반)
Step 2 (정책 검증): CSP Approver K명 + 고객사 Approver (M-K)명이 모두 승인해야 완료
예: 3-of-5에서 K=2(CSP), M-K=1(고객) -> CSP 2명 + 고객 1명 = 3명 승인 필요
Step 3~4 (에어갭 전달/수신): CSP 서명자와 고객사 서명자가 각자의 환경에서 QR/USB-C 수신
Step 5 (WYSIWYS): 고객사 서명자도 자신의 D'CENT X 디스플레이에서 TX 내용 확인 -- 이것이 Level 2의 핵심 가치. 고객사가 직접 하드웨어 레벨에서 TX를 검증
Step 6 (SE 서명): CSP 서명자 + 고객사 서명자 각각 자신의 D'CENT X에서 서명
Step 7 (서명 반환): 각자의 부분 서명을 대시보드로 반환
Step 8~9: 서명 집계 후 브로드캐스트

M-of-N 구성 예시:

총 서명자	M-of-N	CSP 서명자	고객 서명자	설명
5명	3-of-5	3명 (CSP) + 2명 (고객) 중 CSP 2 + 고객 1 필수	최소 1명	표준 구성
5명	3-of-5	2명 (CSP) + 3명 (고객) 중 CSP 1 + 고객 2 필수	최소 2명	고객 통제 강화
7명	4-of-7	4명 (CSP) + 3명 (고객) 중 CSP 2 + 고객 2 필수	최소 2명	대형 기관

고객사 D'CENT X 관리: - 고객사 서명자에게 D'CENT X 디바이스 제공 (CSP 구매 후 제공 또는 고객 직접 구매) - 고객사 D'CENT X의 키는 고객사만 알고 있는 PIN으로 보호 - CSP는 고객사 D'CENT X의 키에 접근 불가 (에어갭 + SE + PIN)

4.4. Level 3: 고객 주도 (Client-Led)¶

항목	내용
고객사 참여	M-of-N 중 과반을 고객사 서명자가 서명
M-of-N 구성	예: 3-of-5 = CSP 서명자 1명 + 고객사 서명자 2명
적용 대상	규제 기관, 중앙은행, 최대 통제 원하는 고객, "수탁하되 실질적으로는 셀프 커스터디에 가까운" 고객
고객 편의	낮음 (높은 참여 필요)
고객 통제	최대 (CSP 단독으로는 TX 불가)

Level 3 서명 플로우:

Step 1 (TX 생성): 고객사 Initiator가 CSP 대시보드에서 TX 생성 (CSP도 생성 가능하나, 고객 확인 필수)
Step 2 (정책 검증): 고객사 Approver 과반 + CSP Approver 소수가 승인
예: 3-of-5에서 고객 2명 + CSP 1명 = 3명 승인 필요
CSP 단독 승인 불가: CSP 서명자만으로는 M에 도달할 수 없음
Step 3~7: Level 2와 동일하되, 고객사 서명자가 과반 참여
Step 8~9: 통상 절차

Level 3 설계 핵심: CSP의 역할 재정의

Level 3에서 CSP는 "자산을 관리하는 주체"가 아닌 "인프라와 운영 전문성을 제공하는 서비스 제공자"로 역할이 변한다:

CSP 역할	Level 0~2	Level 3
서명 주체	주도 또는 공동	소수 참여
인프라 운영	O	O
정책 관리	CSP 주도	고객 합의 필수
규제 리포팅	CSP 수행	CSP 수행 (대행)
사고 대응	CSP 주도	고객과 공동 대응

4.5. 이중 승인 레벨 비교 매트릭스¶

차원	Level 0	Level 1	Level 2	Level 3
고객 D'CENT X 필요	X	X	O	O
고객 기술 역량 필요	X	최소	중간	높음
CSP 단독 TX 가능	O	O (타이머 후)	X	X
고객 단독 TX 가능	X	X	X	X
WYSIWYS 고객 검증	X	X	O	O
규제 선호도	낮음	중간	높음	최고
보험 프리미엄	높음	중간	낮음	최저
운영 복잡도	낮음	낮음	중간	높음

권장 시나리오: - Level 0: CSP가 소수 소규모 고객을 완전 수탁할 때 - Level 1: 고객이 통제를 원하나 기술 역량이 없을 때 (가장 일반적 진입 레벨) - Level 2: 대형 기관, 규제 기관 감사 대비 시 (규제 환경에서 가장 권장) - Level 3: 중앙은행, 국부펀드 등 최대 통제 필요 시

5. 테넌트 격리 설계 -- 보안 경계¶

5.1. 격리 원칙: 에어갭과 동급의 보안 경계¶

테넌트 격리는 단순 데이터베이스 필터(WHERE tenant_id = ?)가 아니다. D'CENT Enterprise의 테넌트 격리는 에어갭과 동등한 수준의 보안 경계(Security Boundary)로 설계된다.

DB 필터 vs 보안 경계 비교:

차원	DB 필터 (일반 SaaS)	D'CENT Enterprise 테넌트 격리
키 격리	같은 HSM, 논리적 분리	테넌트별 독립 D'CENT X 세트
데이터 격리	`WHERE tenant_id = ?`	암호학적 분리 또는 물리적 분리
정책 격리	테넌트 컬럼 필터	독립 정책 인스턴스
세션 격리	세션 변수 체크	서명 세션 자체가 테넌트 경계 내
감사 격리	로그 필터링	테넌트별 독립 감사 스트림
장애 격리	공유 인프라	한 테넌트 장애가 다른 테넌트에 전파 불가

5.2. 5가지 격리 차원 상세¶

(1) 키 격리 (Key Isolation)¶

원칙: 한 테넌트의 키가 다른 테넌트의 서명 요청에 사용될 수 없음
구현:
테넌트별 독립 D'CENT X 디바이스 세트 할당
또는 SE 내 독립 키 슬롯 (키 슬롯 간 교차 접근 불가, SE 하드웨어 레벨 보장)
한 D'CENT X가 여러 테넌트에 동시 사용 금지 (1 디바이스 = 1 테넌트 원칙)
검증: 서명 요청 시 테넌트 ID와 디바이스/키 슬롯 매핑 확인. 불일치 시 SE가 서명 거부

(2) 정책 격리 (Policy Isolation)¶

원칙: 테넌트별 독립 화이트리스트, 한도, M-of-N 정책. 교차 적용 불가
구현:
테넌트별 독립 정책 인스턴스
정책 변경은 해당 테넌트의 이중 승인을 거쳐야만 유효
HW 정책 엔진에서도 테넌트별 Merkle Root 독립 관리
검증: 정책 적용 시 테넌트 경계 확인. 다른 테넌트의 화이트리스트가 적용되는 것 불가

(3) 데이터 격리 (Data Isolation)¶

원칙: 테넌트별 독립 데이터 파티션. 다른 테넌트의 데이터(잔고, TX 이력, 주소)에 접근 불가
구현 옵션:
물리적 분리: 테넌트별 독립 DB 인스턴스 (S5, 대형 테넌트)
암호학적 분리: 테넌트별 독립 암호화 키로 데이터 암호화, 다른 테넌트의 복호화 키 없이 접근 불가 (S6, 다수 테넌트)
DB 필터와의 차이: 소프트웨어 버그로 tenant_id 필터가 누락되어도, 암호학적 분리에 의해 데이터가 보호됨

(4) 세션 격리 (Session Isolation)¶

원칙: 서명 세션이 테넌트 경계를 넘지 않음
구현:
서명 세션 생성 시 테넌트 ID 바인딩 (세션 생성 후 변경 불가)
세션 내 TX 목록이 모두 같은 테넌트 소속인지 검증
한 서명 세션에서 다른 테넌트의 TX가 노출되지 않음
CSP 의미: 콜드룸 서명 세션에서 테넌트 A의 TX를 처리할 때, 테넌트 B의 TX 정보가 화면에 표시되지 않음

(5) 감사 격리 (Audit Isolation)¶

원칙: 테넌트별 독립 감사 로그. 다른 테넌트의 감사 로그 접근 불가
구현:
테넌트별 독립 감사 로그 스트림
고객사 Auditor는 자신의 테넌트 로그만 열람 가능
CSP Admin은 전체 테넌트 로그 열람 가능 (운영 목적)
규제 기관 감사 시 특정 테넌트 로그만 선택적 제공 가능
고객 가치: 고객사가 자신의 감사 로그를 직접 조회하여, CSP의 운영을 독립적으로 검증 가능

6. 일상 운영 델타 (Daily Operations Delta)¶

[CSP Delta] Daily Step 1: TX 생성 -- 고빈도 멀티테넌트 처리¶

특성	CSP 패턴	SC 패턴
TX 빈도	일 10~100건+ (모든 테넌트 합산)	일 0~5건
TX 유형	고객별 입출금, 리밸런싱, 수수료 정산	거래소 입출금, OTC
배치 처리	필수 (테넌트별 배치 묶음)	불필요
이중 승인	Level 0~3에 따라 분기	내부 승인만

배치 처리 최적화: 같은 테넌트의 다수 TX를 배치로 묶어 서명 세션 효율화. 단, 배치 내 TX는 반드시 동일 테넌트 (세션 격리 원칙)
우선순위 큐: SLA 등급에 따라 TX 처리 우선순위 차등 (Premium 테넌트 우선)

[CSP Delta] Daily Step 4: 정기 리포팅 -- 고객별 + 규제 리포팅¶

CSP 리포팅은 3가지 수신자 유형:

수신자	리포트 내용	주기
고객사 (테넌트별)	해당 테넌트 자산 현황, TX 이력, 수수료 정산	일간/주간/월간
CSP 내부	전체 테넌트 합산 운영 현황, SLA 준수율, 수익 분석	일간/주간
규제 기관	SAR(의심거래보고), 대량거래보고, 자산증명(Proof of Reserve)	수시/분기

자산 증명 리포트 (Proof of Reserve): 수탁 자산의 온체인 증명. 전체 테넌트 합산 잔고와 온체인 잔고 일치 확인을 주기적으로 수행

7. 관리 델타 (Administration Delta)¶

[CSP Delta] Admin Step 1/2: 테넌트 관리¶

Layer 1의 M-Step 1(서명자 추가)과 M-Step 2(서명자 교체)에 테넌트 추가/삭제/일시정지 기능이 추가:

테넌트 라이프사이클:

상태	설명	전이 조건
생성 (Created)	온보딩 진행 중	계약 체결 + KYC 완료
활성 (Active)	정상 운영	온보딩 완료 + 테스트 TX 통과
일시 정지 (Suspended)	TX 중단, 데이터 유지	SLA 위반, 규제 동결, 고객 요청
해지 (Terminated)	자산 전부 인출 + 데이터 보관 기간 후 삭제	계약 종료, 규제 폐지

[CSP Delta] Admin Step 3: 정책 변경 -- 이중 승인 필수¶

테넌트 정책 변경은 해당 이중 승인 레벨에 따라 고객사 동의 필요:
Level 0: CSP 단독 변경 가능 (고객 통보)
Level 1: CSP 변경 + 고객 거부 타이머
Level 2~3: CSP + 고객 공동 승인 필수

[CSP Delta] Admin Step 6: 감사 대응 -- 규제 감사 + 고객 감사¶

감사 유형	주관	CSP 특이사항
규제 감사 (VASP)	금융 감독 기관	수탁 자산 관리 적정성, AML/KYC 준수, 자산 증명
SOC 2 Type II	외부 감사 법인	멀티테넌트 격리 효과성이 핵심 감사 항목
CCSS Level 2/3	인증 기관	S5는 Level 3 추진 가능
고객 감사	고객사 감사팀	대형 고객사가 CSP 운영을 직접 감사. 해당 테넌트 로그 제공

테넌트 격리 감사: SOC 2 감사에서 테넌트 격리의 효과성이 가장 중요한 감사 항목. 키 격리, 데이터 격리, 세션 격리가 설계대로 작동하는지 검증

8. 긴급 대응 델타 (Emergency Response Delta)¶

[CSP Delta] Emergency Step 1: 키 손상 대응 -- 고객사 통보 의무¶

Layer 1의 E-Step 1에서 CSP는 다음이 추가:

영향 테넌트 식별: 키 손상의 영향 범위를 테넌트 단위로 파악
고객사 즉시 통보: 영향받는 테넌트의 고객사에 법적 의무 기한 내 통보 (통상 24-72시간, 관할권별 상이)
규제 기관 보고: 보안 사고 발생 시 규제 기관에 법적 의무 보고 (SAR과 별개)
보험사 통보: 사이버 보험 약관에 따른 사고 통보 (보험금 청구 전제)

[CSP Delta] Emergency Step 1: 테넌트 격리 긴급 강화¶

한 테넌트 손상 시 다른 테넌트 보호:
손상 의심 테넌트의 모든 TX 즉시 동결
다른 테넌트의 정상 운영 유지 (격리 효과 검증)
손상 테넌트와 다른 테넌트 간 교차 접근 재검증
격리 실패 시 (최악 시나리오): 전체 시스템 동결 -> 테넌트별 순차 검증 -> 안전 확인된 테넌트부터 순차 해제

[CSP Delta] Emergency Step 5: 규제 긴급 동결 -- 테넌트 단위¶

Layer 1의 E-Step 5에서 CSP는 테넌트 단위 동결이 가능:

특정 테넌트만 동결: 규제 기관이 특정 고객의 자산 동결을 명령한 경우, 해당 테넌트만 동결하고 다른 테넌트는 정상 운영 유지
전체 동결: CSP 자체에 대한 동결 명령 시 전체 테넌트 동결
동결 기록: 테넌트별 동결/해제 이력을 별도 관리 (규제 감사 대비)

9. 시나리오별 차이 매트릭스 (S5~S6)¶

차원	S5 (ZC+CR)	S6 (HY+NCR)
도입 복잡도	매우 높음	높음
온보딩 기간 (CSP 자체)	8-12주	4-8주
테넌트 온보딩 기간	2-4주/테넌트	1-3주/테넌트
인프라	전체 자체 운영 + 콜드룸	서명환경 자체 + 대시보드 클라우드
보안 등급	콜드룸 (CCSS L3 가능)	Grade A 필수
테넌트 격리 수준	물리적 + 논리적	암호학적 + 논리적
최대 테넌트 수	5-20 (물리 콜드룸 제약)	20-100 (클라우드 확장)
이중 승인 전 레벨	Level 0~3 모두 지원	Level 0~3 모두 지원
규제 인증	CCSS L3, SOC 2, VASP	CCSS L2, SOC 2, VASP
대상 고객	대형 규제 준수 수탁사	신규 진입 / 중소 수탁사

작성일: 2026-03-28 Phase 14 Plan 02 산출물 -- Layer 2 Custody Service Provider Segment Delta 적용 범위: S5~S6 (수탁 서비스 사업자) 참조: e2e-core-flow.md (Layer 1 E2E Core Flow), signing-core-flow.md (Layer 1 Signing Core Flow)