v0.5
운영 시나리오 v2 — 2단계 서명 아키텍처 기반 역할 재배치¶
1. Executive Summary¶
Phase 24에서 확정된 옵션 A(오프체인 승인 + 온체인 마스터 서명 분리) 아키텍처 채택과 Plan 01에서 재정의된 RBAC v2 역할 체계에 따라, 기존 12개 운영 시나리오(S-01~S-12)의 역할을 재배치한다.
1.1. 핵심 변경¶
- Approver: 개인 기기(Zone 3+)에서 오프체인 승인 서명 → 콜드룸 집결 불필요
- Operator (신규): 콜드룸에서 콜드월렛(Zone 3)으로 온체인 서명 실행
- 5단계 TX 파이프라인: Request(Initiator) → Approve(Approver) → Collect(시스템) → Sign(Operator) → Broadcast(시스템)
1.2. 콜드룸 집결 필요 시나리오 요약표¶
| 분류 | 시나리오 | v1 콜드룸 필요 인원 | v2 콜드룸 필요 인원 | Approver 콜드룸? |
|---|---|---|---|---|
| 일상 | S-01 일상 BTC 출금 | 3명 (Approver) | 1명 (Operator) | 불필요 |
| 일상 | S-02 배치 스테이블코인 전송 | 2명 (Approver) | 1명 (Operator) | 불필요 |
| 일상 | S-03 내부 월렛 이체 | 2명 (Approver) | 1명 (Operator) | 불필요 |
| 일상 | S-04 화이트리스트 등록 | 0명 | 0명 | 불필요 (변경 없음) |
| 긴급 | S-05 긴급 출금 | 2명 (축소 쿼럼) | 1명 (Operator) | 불필요 |
| 긴급 | S-06a Approver 비가용 | N/A (대체 Approver) | 0명 | 불필요 |
| 긴급 | S-06b Operator 비가용 | N/A | 1명 (대체 Operator) | 불필요 |
| 긴급 | S-07a approval_sk 유출 | N/A | 0명 | 불필요 |
| 긴급 | S-07b master_sk 유출 | 전원 | 전원 (키 세레모니) | 필요 (키 세레모니) |
| 관리 | S-08a Approver 교체 | 3명+ (키 세레모니) | 0명 | 불필요 |
| 관리 | S-08b Operator 교체 | N/A | 2명+ (물리 인수인계) | 불필요 |
| 관리 | S-09 정책 변경 | 0명 | 0명 | 불필요 (변경 없음) |
| 관리 | S-10 감사 대응 | 0명 | 0명 | 불필요 (변경 없음) |
| 복구 | S-11a 개인 기기 복구 | N/A | 0명 | 불필요 |
| 복구 | S-11b 콜드월렛 복구 | 1명 (Approver) | 1명 (Operator) | 불필요 |
| 복구 | S-12 초기 설정 (Day-1) | 5명 (Approver 전원) | 1~2명 (Operator) + 원격 승인 | 부분 불필요 |
2. 역할 재배치 원칙¶
2.1. 5단계 TX 파이프라인 기준 역할 매핑¶
| 단계 | 역할 | 컴포넌트 | Zone | 물리 위치 | 콜드룸 필요 |
|---|---|---|---|---|---|
| Request | Initiator | 대시보드 | Zone 1 | 원격 가능 | 불필요 |
| Approve | Approver (M-of-N) | 개인 기기 | Zone 3+ | 원격 가능 | 불필요 |
| Collect | 시스템 (자동) | 대시보드 + 오프라인 앱 | Zone 1→2 | 자동 | N/A |
| Sign | Operator | 오프라인 앱 + 콜드월렛 | Zone 2→3 | 콜드룸 필수 | 필수 |
| Broadcast | 시스템 (자동) | 대시보드 | Zone 1 | 자동 | N/A |
2.2. 콜드룸 인원 비교 원칙¶
- v1: Sign 단계에서 M명 Approver가 각자 콜드월렛을 가져와 콜드룸에서 MuSig2 서명
- v2: Approve 단계에서 Approver가 원격 승인 → Sign 단계에서 Operator 1~2명만 콜드룸 진입
- 결과: 콜드룸 필요 인원이 M명 → 1~2명으로 대폭 감소
3. 일상 운영 시나리오 재배치 (S-01~S-04)¶
S-01: 일상 BTC 출금 (v2)¶
분류: 일상 운영 전제 조건: 3-of-5 Approver 설정. Operator 1명 지정. 화이트리스트 등록된 거래소 주소. 일일 한도 $200,000 이내. 관련 역할: Initiator, Approver 3명, Operator 1명
| Step | 컴포넌트 | 역할 | Zone | 액션 | v1 대비 변경 |
|---|---|---|---|---|---|
| 1 | 대시보드 | Initiator | Zone 1 | MFA 로그인 → BTC 출금 TX 생성 (수신: 거래소 주소, 금액: 2 BTC) + ApprovalBundle 요청 생성 | ApprovalBundle 요청 추가 |
| 2 | 대시보드 (정책엔진) | 시스템 | Zone 1 | 화이트리스트 확인 → 통과. 금액 한도 → Tier 2 (3-of-5). 시간 확인 → 영업시간 | 변경 없음 |
| 3 | 대시보드 | 시스템 | Zone 1 | PSBT 생성 (BIP-370 v2). 승인 요청을 5명 Approver에게 발송 | MuSig2 세션 시작 → 승인 요청 발송으로 변경 |
| 4 | 개인 기기 | Approver 1 | Zone 3+ | 대시보드/오프라인앱에서 TX 해시 수신 (QR/NFC) → 개인 기기 WYSIWYS 확인 (주소, 금액, 수수료) → 생체인증 → approval_sig_1 생성 → NFC/QR 반환 | 신규 (콜드룸 불필요, 원격 승인) |
| 5 | 개인 기기 | Approver 2 | Zone 3+ | 동일 과정 → approval_sig_2 생성 | 신규 |
| 6 | 개인 기기 | Approver 3 | Zone 3+ | 동일 과정 → approval_sig_3 생성. 3/3 승인 충족 | 신규 |
| 7 | 대시보드+오프라인앱 | 시스템 | Zone 1→2 | 3개 승인 서명 수집 → ApprovalBundle(CBOR UR 45052) 생성 | 신규 (Approval Signature Collector) |
| 8 | 오프라인앱→콜드월렛 | Operator | Zone 2→3 | ApprovalBundle + PSBT를 콜드월렛에 전달 (QR/NFC/USB-C) → Approval Verifier가 3개 서명 검증 → WYSIWYS 확인 → 물리 버튼 → master_sk로 Schnorr 서명 (BIP-340) → 서명된 TX 반환 | 변경 (Approver 3명 → Operator 1명, MuSig2 24회 QR → 단일 서명) |
| 9 | 대시보드 | 시스템 | Zone 1 | 서명된 TX 수신 → 블록체인 전파 → 6 확인 대기 → CONFIRMED. 감사 로그 기록 | 변경 없음 |
핵심 변경점: - v1: Approver 3명이 콜드룸에 집결 → MuSig2 2라운드 × 3명 = 12+회 QR 교환 - v2: Approver 3명이 원격에서 비동기 승인 → Operator 1명만 콜드룸에서 단일 서명 - 소요 시간: v1(30분+, M명 집결 대기) → v2(5~10분, 비동기 승인 후 Operator 실행) - 콜드룸 인원: v1(3명) → v2(1명)
S-02: 대량 배치 스테이블코인 전송 (v2)¶
분류: 일상 운영 전제 조건: 2-of-3 Approver 설정. Operator 1명. 급여일 USDC 20건 배치 전송. 일일 한도 $500,000. 관련 역할: Initiator (HR 재무), Approver 2명, Operator 1명
| Step | 컴포넌트 | 역할 | Zone | 액션 | v1 대비 변경 |
|---|---|---|---|---|---|
| 1 | 대시보드 | Initiator | Zone 1 | 배치 전송 생성: 20개 수신 주소 + 금액 CSV 업로드 + ApprovalBundle 요청 | ApprovalBundle 요청 추가 |
| 2 | 대시보드 (정책엔진) | 시스템 | Zone 1 | 20개 주소 화이트리스트 일괄 확인. 총액 합산 한도 확인. USDC 자산 필터 | 변경 없음 |
| 3 | 대시보드 | 시스템 | Zone 1 | 20건 배치 TX 해시 생성. 배치 승인 요청을 3명 Approver에게 발송 | 개별 EIP-712 → 배치 TX 해시 승인으로 변경 |
| 4 | 개인 기기 | Approver 1 | Zone 3+ | 배치 목록 WYSIWYS 확인 (20건 요약) → 생체인증 → approval_sig 생성 | 신규 (원격 승인) |
| 5 | 개인 기기 | Approver 2 | Zone 3+ | 동일 → 2/2 승인 충족 | 신규 |
| 6 | 대시보드+오프라인앱 | 시스템 | Zone 1→2 | 승인 서명 수집 → ApprovalBundle 생성 | 신규 |
| 7 | 오프라인앱→콜드월렛 | Operator | Zone 2→3 | ApprovalBundle + 20건 TX 데이터 전달 → Approval Verifier 검증 → 20건 순차 서명 (Animated QR 배치) → 서명 반환 | 변경 (Approver 2명 각각 20건 서명 → Operator 1명 단일 키 20건 서명) |
| 8 | 대시보드 | 시스템 | Zone 1 | 20건 execTransaction 호출 → 블록체인 전파. Gas 집계. 감사 로그 20건 | 변경 없음 |
핵심 변경점: - v1: Approver 2명이 각각 20건 × 서명 = 40회 서명 (콜드룸 1~2시간) - v2: Approver 2명 원격 승인(각 1회) + Operator 1명 20건 서명 (콜드룸 15~20분) - 콜드룸 인원: v1(2명) → v2(1명) - 콜드룸 소요 시간: v1(1~2시간) → v2(15~20분)
S-03: 내부 월렛 간 자산 재배분 (v2)¶
분류: 일상 운영 전제 조건: 콜드월렛 → 웜월렛 ETH 이체. 내부 주소 자동 화이트리스트. 2-of-3 Approver. 관련 역할: Initiator (트레저리 매니저), Approver 2명, Operator 1명
| Step | 컴포넌트 | 역할 | Zone | 액션 | v1 대비 변경 |
|---|---|---|---|---|---|
| 1 | 대시보드 | Initiator | Zone 1 | 내부 이체 생성: 콜드월렛 → 웜월렛, 50 ETH | 변경 없음 |
| 2 | 대시보드 (정책엔진) | 시스템 | Zone 1 | 내부 주소 확인 → 간소화 승인 적용 (한도 완화) | 변경 없음 |
| 3 | 개인 기기 | Approver 1, 2 | Zone 3+ | 각각 WYSIWYS 확인 → 승인 서명 생성 | 변경 (대시보드 승인 → 개인 기기 승인) |
| 4 | 대시보드+오프라인앱 | 시스템 | Zone 1→2 | 승인 서명 수집 → ApprovalBundle 생성 | 신규 |
| 5 | 오프라인앱→콜드월렛 | Operator | Zone 2→3 | ApprovalBundle + TX 전달 → 검증 → Safe execTransaction 서명 | 변경 (Approver → Operator) |
| 6 | 대시보드 | 시스템 | Zone 1 | 전파 → 확인. 내부 이체 감사 로그 | 변경 없음 |
콜드룸 인원: v1(2명) → v2(1명)
S-04: 신규 화이트리스트 주소 등록 (v2)¶
분류: 일상 운영 전제 조건: 새 파트너사 BTC 수신 주소 등록. 48시간 쿨다운. 관련 역할: Initiator (요청), Admin 2명 (승인)
| Step | 컴포넌트 | 역할 | Zone | 액션 | v1 대비 변경 |
|---|---|---|---|---|---|
| 1 | 대시보드 | Initiator | Zone 1 | 화이트리스트 등록 요청: 주소 bc1p..., 라벨, BTC 체인 | 변경 없음 |
| 2 | 대시보드 | 시스템 | Zone 1 | 주소 포맷 검증 (Bech32m). 블랙리스트 대조. 중복 확인 | 변경 없음 |
| 3 | 대시보드 | Admin 1, 2 | Zone 1 | 주소 확인 → 쿼럼 승인 | 변경 없음 |
| 4 | 대시보드 | 시스템 | Zone 1 | 쿨다운 48시간 → 상태 active | 변경 없음 |
핵심 변경점: 없음. 화이트리스트 등록은 Admin 대시보드 작업이므로 2단계 서명과 무관.
4. 긴급 상황 시나리오 재배치 (S-05~S-07)¶
S-05: 긴급 출금 (보안 위협 감지) (v2)¶
분류: 긴급 상황 전제 조건: 비정상 접근 패턴 감지. 자산 긴급 이전 필요. 3-of-5 → 축소 쿼럼 2-of-5. Operator 대기. 관련 역할: Admin (긴급 발동), Initiator, Approver 2명 (축소 쿼럼), Operator 1명
| Step | 컴포넌트 | 역할 | Zone | 액션 | v1 대비 변경 |
|---|---|---|---|---|---|
| 1 | 대시보드 | 시스템 | Zone 1 | 비정상 접근 패턴 감지 → 보안 경고 | 변경 없음 |
| 2 | 대시보드 | Admin | Zone 1 | 긴급 프로토콜 발동: priority "urgent" | 변경 없음 |
| 3 | 대시보드 (정책엔진) | 시스템 | Zone 1 | 긴급 모드: 시간 제한 해제, 타임아웃 2시간, 축소 쿼럼 | 변경 없음 |
| 4 | 대시보드 | Initiator | Zone 1 | 긴급 TX 생성: 전체 자산 → 긴급 월렛 + ApprovalBundle 요청 | ApprovalBundle 추가 |
| 5 | 개인 기기 | Approver 1, 2 | Zone 3+ | 긴급 승인 (WYSIWYS에 "URGENT" 표시) → 승인 서명 (병렬, 즉시 응답) | 변경 (콜드룸 → 원격 즉시 승인) |
| 6 | 대시보드+오프라인앱 | 시스템 | Zone 1→2 | 승인 서명 수집 → ApprovalBundle 생성 | 신규 |
| 7 | 오프라인앱→콜드월렛 | Operator | Zone 2→3 | ApprovalBundle + TX 전달 → 검증 → 긴급 서명 | 변경 (Approver → Operator) |
| 8 | 대시보드 | 시스템 | Zone 1 | 전파 → 확인. 긴급 TX 감사 로그 | 변경 없음 |
| 9 | 대시보드 | Admin | Zone 1 | 24시간 내 전체 Admin/Super Admin에 긴급 보고. 72시간 내 사후 감사 | 변경 없음 |
핵심 변경점: - v1: 축소 쿼럼 Approver 2명이 콜드룸에 긴급 소집 (20분+ 소요) - v2: Approver 2명이 즉시 원격 승인 (2~5분) → Operator가 대기 중인 콜드룸에서 서명 (3~5분) - 긴급 응답 시간: v1(20~30분) → v2(5~10분) - 콜드룸 인원: v1(2명 긴급 소집) → v2(1명 상시 대기)
S-06a: Approver 비가용 (장기 부재) (v2)¶
분류: 긴급 상황 전제 조건: 3-of-5 설정. Approver C 30일 이상 부재. 대체 Approver D 사전 지정. 관련 역할: Admin (대체 활성화), Approver D (대체)
| Step | 컴포넌트 | 역할 | Zone | 액션 | v1 대비 변경 |
|---|---|---|---|---|---|
| 1 | - | Admin | - | Approver C 비가용 확인. 대체 승인자 활성화 결정 | 변경 (서명자 → 승인자) |
| 2 | 대시보드 | Admin (2명) | Zone 1 | Approver D를 대체 Approver로 활성화 (쿼럼 승인) | 변경 최소 |
| 3 | 개인 기기 | Approver D | Zone 3+ | 사전 등록된 개인 기기 활성화 → approval_sk 즉시 사용 가능 | 변경 (콜드월렛 할당 → 개인 기기 활성화) |
| 4 | 개인 기기 | Approver D | Zone 3+ | 대체 승인자로서 원격 승인 수행 (최대 30일) | 변경 (콜드룸 집결 → 원격 승인) |
| 5 | (복귀 시) | Admin | - | Approver C 복귀 → Approver D 대체 비활성화 | 변경 없음 |
| 6 | (미복귀 시) | Admin | - | 30일 경과 → Approver 교체 (S-08a 참조) | 변경 없음 |
핵심 변경점: - v1: 대체 서명자에게 별도 콜드월렛 할당 필요 (키 세레모니 소요) - v2: 대체 Approver의 개인 기기가 사전 등록되어 있으면 즉시 활성화 가능 - 대체 활성화 시간: v1(수 시간, 콜드월렛 프로비저닝) → v2(수 분, 시스템 활성화) - 콜드룸 필요: v1(콜드월렛 할당 시 필요) → v2(불필요)
S-06b: Operator 비가용 (v2, 신규 세분화)¶
분류: 긴급 상황 전제 조건: Operator A가 비가용. 대체 Operator B 사전 지정. 관련 역할: Admin (대체 활성화), Operator B (대체)
| Step | 컴포넌트 | 역할 | Zone | 액션 | v1 대비 변경 |
|---|---|---|---|---|---|
| 1 | - | Admin | - | Operator A 비가용 확인. 대체 Operator 활성화 결정 | 신규 (v1에 해당 시나리오 없음) |
| 2 | 대시보드 | Admin (2명) | Zone 1 | Operator B를 대체 Operator로 활성화 (쿼럼 승인) | 신규 |
| 3 | - | Operator B | Zone 3 | 콜드룸 접근 권한 활성화. 콜드월렛 접근 PIN 인수 (보안 채널) | 신규 |
| 4 | 오프라인앱→콜드월렛 | Operator B | Zone 2→3 | 콜드룸 입실 → 정상 서명 실행 업무 수행 | 신규 |
| 5 | (복귀 시) | Admin | - | Operator A 복귀 → Operator B 대체 비활성화 | 신규 |
핵심 사항: - Operator 비가용은 콜드룸 서명 실행이 불가능한 상황 → TX 파이프라인 Sign 단계 차단 - 대체 Operator는 콜드월렛 물리 접근이 가능해야 하므로, 콜드룸 입실 권한 + PIN 인수 필요 - v1에는 해당 시나리오가 없었음 (v1의 Approver가 서명까지 수행했으므로)
S-07a: 보안 침해 — approval_sk 유출 (v2, 신규 세분화)¶
분류: 긴급 상황 전제 조건: Approver 1명의 개인 기기 키(approval_sk) 유출 의심. 관련 역할: Admin, 해당 Approver
| Step | 컴포넌트 | 역할 | Zone | 액션 | v1 대비 변경 |
|---|---|---|---|---|---|
| 1 | - | 탐지자 | - | 개인 기기 분실/도난 또는 키 노출 의심 보고 | 신규 |
| 2 | 대시보드 | Admin | Zone 1 | 해당 Approver의 승인 권한 즉시 정지 (시스템에서 approval_pk 비활성화) | 신규 (기기 교체만으로 대응) |
| 3 | - | Admin | - | 해당 Approver의 개인 기기 회수 또는 원격 와이프 | 신규 |
| 4 | 개인 기기 | Approver | Zone 3+ | 새 개인 기기에서 approval_sk 재생성 | 신규 |
| 5 | 콜드월렛 | Super Admin | Zone 3 | 콜드월렛 SE에서 기존 approval_pk 삭제 + 새 approval_pk 등록 | 신규 |
| 6 | 개인 기기 | Approver | Zone 3+ | 테스트 승인 수행 → 정상 확인 | 신규 |
핵심 변경점: - 온체인 자산 영향: 없음 (키 독립성 — approval_sk 유출이 master_sk에 영향 없음) - 긴급 키 세레모니: 불필요 (블록체인 주소 변경 없음, 자산 이전 없음) - 대응 수준: 개인 기기 교체 + 공개키 재등록으로 완료 (수 시간 이내) - v1에서는 서명 키 유출 시 전체 키 세레모니 + 자산 이전이 필요했음 - 콜드룸 필요: Super Admin의 공개키 재등록 시에만 잠시 필요 (Approver 콜드룸 불필요)
S-07b: 보안 침해 — master_sk 유출 (v2)¶
분류: 긴급 상황 전제 조건: 콜드월렛 마스터 키(master_sk) 유출 의심. 전체 자산 보호 필요. 관련 역할: Super Admin, Admin, Approver 전원 (원격 승인), Operator
| Step | 컴포넌트 | 역할 | Zone | 액션 | v1 대비 변경 |
|---|---|---|---|---|---|
| 1 | - | 탐지자 | - | master_sk 유출 의심 보고 (콜드룸 물리 보안 위반 등) | 변경 최소 |
| 2 | 대시보드 | Admin | Zone 1 | 즉시 격리: 해당 콜드월렛 서명 차단, 대기 TX 동결 | 변경 최소 |
| 3 | 대시보드 | Initiator | Zone 1 | 긴급 자산 이전 TX 생성 + ApprovalBundle 요청 | ApprovalBundle 추가 |
| 4 | 개인 기기 | Approver (축소 쿼럼) | Zone 3+ | 긴급 승인 (원격) | 변경 (콜드룸 → 원격) |
| 5 | 오프라인앱→콜드월렛 | Operator | Zone 2→3 | 긴급 서명 (별도 안전한 콜드월렛 사용) | 변경 (Approver → Operator) |
| 6 | 대시보드 | 시스템 | Zone 1 | 전파 → 자산 안전 확보 | 변경 없음 |
| 7 | - | Super Admin + Admin | Zone 3 | 긴급 키 세레모니 실행 (새 master_sk 생성) | 변경 최소 |
| 8 | - | Approver 전원 | Zone 3+ | 새 콜드월렛 SE에 기존 approval_pk 재등록 (기존 개인 기기 유지) | 변경 (새 키 생성 → 공개키 재등록) |
| 9 | 대시보드 | 시스템 | Zone 1 | 긴급 월렛 → 새 영구 월렛 자산 최종 이전 | 변경 없음 |
핵심 변경점: - v1: 서명 키 유출 = 전체 Approver 키 세레모니 + 콜드룸 전원 소집 - v2: master_sk 유출 시 긴급 자산 이전은 Approver 원격 승인으로 신속 대응, 키 세레모니는 Operator만 콜드룸 - Approver 키 영향: 없음 (개인 기기 키는 유지, 공개키만 새 콜드월렛에 재등록) - 긴급 응답 속도: v1(1시간+, 전원 소집) → v2(10~20분, 원격 승인 + Operator 실행)
5. 관리 작업 시나리오 재배치 (S-08~S-10)¶
S-08a: Approver 교체 (퇴사) (v2)¶
분류: 관리 작업 전제 조건: 3-of-5 설정. Approver B 퇴사. 신규 Approver E 합류. 관련 역할: Admin, Approver B (퇴임), Approver E (신규)
| Step | 컴포넌트 | 역할 | Zone | 액션 | v1 대비 변경 |
|---|---|---|---|---|---|
| 1 | 대시보드 | Admin | Zone 1 | Approver E 온보딩 시작 (계정 생성, 역할 부여 — 쿼럼 승인) | 변경 최소 |
| 2 | 개인 기기 | Approver E | Zone 3+ | 새 개인 기기에서 approval_sk 생성 + approval_pk 추출 | 변경 (콜드월렛 키 세레모니 → 개인 기기 키 생성) |
| 3 | 콜드월렛 | Super Admin | Zone 3 | 콜드월렛 SE에 Approver E의 approval_pk 등록 + Approver B의 approval_pk 삭제 | 변경 (다중 서명 재구성 → 공개키 레지스트리 변경) |
| 4 | 대시보드 | Admin | Zone 1 | Approver B 오프보딩: 대시보드 접근 차단, 개인 기기 회수 | 변경 (콜드월렛 회수 → 개인 기기 회수) |
| 5 | - | Admin | - | Approver B 개인 기기 SE 보안 삭제 (approval_sk 파기) | 변경 (콜드월렛 SE 삭제 → 개인 기기 SE 삭제) |
| 6 | 개인 기기 | Approver E | Zone 3+ | 테스트 승인 수행 → 정상 확인 | 변경 최소 |
핵심 변경점: - 온체인 영향: BTC — Taproot 트리 변경 불필요 (Approver 키는 오프체인), EVM — Safe owner 변경 불필요 - 자산 이전: 불필요 (마스터 키 변경 없음, 블록체인 주소 유지) - 콜드룸 필요: Super Admin의 콜드월렛 SE 공개키 등록 시에만 (Step 3), Approver E는 콜드룸 불필요 - v1: 키 세레모니 + Taproot 재구성 + 전체 자산 이전 (수 시간~반나절) - v2: 개인 기기 키 생성 + 공개키 등록 (1~2시간)
S-08b: Operator 교체 (v2, 신규 세분화)¶
분류: 관리 작업 전제 조건: Operator A 퇴사. 신규 Operator B 임명. 관련 역할: Admin, Super Admin, Operator A (퇴임), Operator B (신규)
| Step | 컴포넌트 | 역할 | Zone | 액션 | v1 대비 변경 |
|---|---|---|---|---|---|
| 1 | 대시보드 | Admin (쿼럼) | Zone 1 | Operator B 역할 부여 승인 | 신규 |
| 2 | - | Admin + Super Admin | Zone 3 | 콜드월렛 접근 권한 이전: PIN 변경, 물리 접근 카드 재발급 | 신규 |
| 3 | - | Operator B | Zone 3 | 콜드룸 입실 교육, 콜드월렛 운용 실습 | 신규 |
| 4 | 오프라인앱→콜드월렛 | Operator B | Zone 2→3 | 테스트 서명 수행 → 정상 확인 | 신규 |
| 5 | 대시보드 | Admin | Zone 1 | Operator A 오프보딩: 접근 권한 완전 해제, 콜드룸 출입 카드 회수 | 신규 |
핵심 사항: - Operator 교체는 물리적 인수인계가 핵심 (콜드룸 접근, 콜드월렛 PIN) - 블록체인 키/주소에 영향 없음 (Operator는 기존 master_sk를 사용) - v1에는 해당 시나리오가 없었음
S-09: 정책 변경 (일일 출금 한도 인상) (v2)¶
분류: 관리 작업 전제 조건: 일일 출금 한도 $200,000 → $500,000 인상. 관련 역할: Admin 2명
| Step | 컴포넌트 | 역할 | Zone | 액션 | v1 대비 변경 |
|---|---|---|---|---|---|
| 1 | 대시보드 | Admin 1 | Zone 1 | 정책 수정 요청: 일일 한도 $200,000 → $500,000 | 변경 없음 |
| 2 | 대시보드 | 시스템 | Zone 1 | 정책 시뮬레이션 실행 | 변경 없음 |
| 3 | 대시보드 | Admin 1 | Zone 1 | 시뮬레이션 검토 → 제출 | 변경 없음 |
| 4 | 대시보드 | Admin 2 | Zone 1 | 검토 → 승인 (쿼럼 2/2) | 변경 없음 |
| 5 | 대시보드 | 시스템 | Zone 1 | 정책 버전 업데이트. 오프라인 앱 + 콜드월렛 SE 정책 동기화 예약 | 변경 (콜드월렛 Approval Verifier 정책 동기화 추가) |
| 6 | 대시보드 | 시스템 | Zone 1 | 감사 로그 기록 | 변경 없음 |
핵심 변경점: - 정책 변경 시 콜드월렛 SE의 Approval Verifier 정책(M-of-N 임계값 등)도 동기화 필요 - 기존 대시보드+오프라인 앱 동기화에 콜드월렛 SE 동기화가 추가됨 - 콜드룸 필요: 정책 동기화 시 Operator가 콜드월렛에 정책 업데이트 전달 (다음 서명 세션에서)
S-10: 외부 감사 대응 (v2)¶
분류: 관리 작업 전제 조건: SOC 2 Type II 감사. 외부 감사인에게 6개월 데이터 제공. 관련 역할: Admin, Viewer (감사인), Compliance Officer
| Step | 컴포넌트 | 역할 | Zone | 액션 | v1 대비 변경 |
|---|---|---|---|---|---|
| 1 | 대시보드 | Admin | Zone 1 | 외부 감사인 계정 생성 (External Auditor 역할) | 변경 없음 |
| 2 | 대시보드 | Compliance Officer | Zone 1 | 컴플라이언스 리포트 + Proof of Reserve 생성 | 변경 없음 |
| 3 | 대시보드 | 외부 감사인 | Zone 1 | 리포트 조회: 거래 내역, 승인 서명 체인, 정책 변경 로그 | 변경 (승인 서명 로그 추가) |
| 4 | 대시보드 | 외부 감사인 | Zone 1 | 감사 로그 조회 + 해시 체인 무결성 검증 | 변경 없음 |
| 5 | 대시보드 | 외부 감사인 | Zone 1 | Approver/Operator 직무 분리 증적 검증 | 추가 (v2 듀얼 컨트롤 증적) |
| 6 | 대시보드 | Admin | Zone 1 | 감사 완료 → 외부 감사인 계정 비활성화 | 변경 없음 |
핵심 변경점: - 승인 서명 로그(어떤 Approver가 언제 어떤 기기로 승인했는지)가 감사 자료에 추가 - Approver/Operator 직무 분리 증적이 SOC 2 CC6.1/CCSS 듀얼 컨트롤 충족 근거로 활용 - 콜드룸 필요: 없음
6. 복구 상황 시나리오 재배치 (S-11~S-12)¶
S-11a: 개인 기기 복구 (v2, 신규 세분화)¶
분류: 복구 상황 전제 조건: Approver A의 개인 기기 고장. 개인 기기 키(approval_sk) 사용 불가. 관련 역할: Admin, Approver A
| Step | 컴포넌트 | 역할 | Zone | 액션 | v1 대비 변경 |
|---|---|---|---|---|---|
| 1 | - | Approver A | - | 개인 기기 고장 보고 | 신규 |
| 2 | - | Admin | - | 복구 방법 결정: 옵션 C(교체 우선) 전략 적용 | 신규 (Phase 25 결정 반영) |
| 3 | - | Admin | - | 새 개인 기기 수령 | 신규 |
| 4 | 개인 기기 | Approver A | Zone 3+ | 새 기기에서 approval_sk 재생성 → 새 approval_pk 추출 | 신규 (시드 복원이 아닌 키 재생성) |
| 5 | 콜드월렛 | Super Admin | Zone 3 | 콜드월렛 SE에서 기존 approval_pk 삭제 + 새 approval_pk 등록 | 신규 |
| 6 | 개인 기기 | Approver A | Zone 3+ | 테스트 승인 → 정상 확인 → 정상 운영 재개 | 신규 |
핵심 변경점: - 시드 복원 불필요: 옵션 C(교체 우선) 전략에 따라 새 키 생성이 기본 (approval_sk는 SE 외부 비존재) - 마스터 키 영향: 없음 (approval_sk와 master_sk는 독립) - 블록체인 영향: 없음 (온체인 주소/키 변경 없음) - RTO: v1(2~4시간, 시드 복원 + 키 검증) → v2(30분~1시간, 키 재생성 + 공개키 등록)
S-11b: 콜드월렛 복구 (v2)¶
분류: 복구 상황 전제 조건: Operator가 사용하는 콜드월렛 고장. master_sk 사용 불가. 관련 역할: Admin, Operator, Super Admin
| Step | 컴포넌트 | 역할 | Zone | 액션 | v1 대비 변경 |
|---|---|---|---|---|---|
| 1 | - | Operator | - | 콜드월렛 고장 보고 | 변경 (Approver → Operator 보고) |
| 2 | - | Admin | - | 고장 원인 평가. 복구 방법 결정: 시드 복원 (옵션 A) | 변경 최소 |
| 3 | - | Super Admin | Zone 3 | 백업 디바이스 수령 (Site B) + 금속 시드 백업 수령 (Site A 금고) | 변경 최소 |
| 4 | - | Operator | Zone 3 | 백업 디바이스에 시드 입력 → master_sk 복원 | 변경 (Approver → Operator) |
| 5 | - | Admin | - | 복원 키 주소 검증: 기존 주소 일치 확인 | 변경 없음 |
| 6 | 콜드월렛 | Super Admin | Zone 3 | 기존 Approver 전원의 approval_pk 재등록 (콜드월렛 SE Approval Verifier 재설정) | 추가 (공개키 레지스트리 복원) |
| 7 | 오프라인앱→콜드월렛 | Operator | Zone 2→3 | 테스트 서명 수행 → 정상 확인 | 변경 (Approver → Operator) |
핵심 변경점: - 콜드월렛 복원 후 Approval Verifier의 공개키 레지스트리 재설정 필요 (Step 6 추가) - Approver들의 개인 기기는 영향 없음 (키 유지) - 콜드룸 인원: v1(Approver 1명) → v2(Operator 1명 + Super Admin)
S-12: 초기 시스템 설정 Day-1 (v2)¶
분류: 복구 상황 (초기 설정) 전제 조건: D'CENT 엔터프라이즈 최초 도입. 3-of-5 Approver, Operator 1명 구성 목표. 관련 역할: Super Admin, Admin 3명, Approver 5명, Operator 1명, 증인 2명
| Step | 컴포넌트 | 역할 | Zone | 시간 | 액션 | v1 대비 변경 |
|---|---|---|---|---|---|---|
| 1 | 대시보드 | Super Admin | Zone 1 | 1h | 시스템 초기화: 대시보드 설치/설정, 조직 프로필 | 변경 없음 |
| 2 | 대시보드 | Super Admin | Zone 1 | 30m | Admin 3명 계정 생성 + 역할 부여 | 변경 없음 |
| 3 | - | Super Admin + 증인 | Zone 3 | 2~3h | 콜드월렛 키 세레모니 (축소): master_sk 생성, 시드 백업 (Operator용 콜드월렛 1대만) | 변경 (5대 → 1대, 대폭 축소) |
| 4 | 개인 기기 | Approver 5명 | Zone 3+ | 1~2h | 개인 기기 온보딩 (원격 가능): 각자 개인 기기에서 approval_sk 생성 → approval_pk 추출 | 신규 (콜드룸 불필요) |
| 5 | 콜드월렛 | Super Admin | Zone 3 | 1h | 5명의 approval_pk를 콜드월렛 SE에 등록. M-of-N(3-of-5) 설정 | 신규 (Approval Verifier 초기화) |
| 6 | - | Admin | Zone 3 | 30m | Operator 1명 역할 부여 + 콜드룸 접근 권한 설정 | 신규 |
| 7 | 대시보드 | Admin | Zone 1 | 30m | Initiator 계정 생성 (재무팀 2명) | 변경 없음 |
| 8 | 대시보드 | Admin | Zone 1 | 30m | Viewer 계정 생성 (감사팀, 경영진) | 변경 없음 |
| 9 | 대시보드 | Admin (쿼럼) | Zone 1 | 1h | 정책 설정: 금액 한도, 시간 제한, 자산 필터 | 변경 없음 |
| 10 | 대시보드 | Admin (쿼럼) | Zone 1 | 30m | 화이트리스트 초기 등록 | 변경 없음 |
| 11 | 대시보드+개인기기+콜드월렛 | Initiator + Approver 3명 + Operator | 전체 | 30m | 전체 파이프라인 테스트: Request → Approve(원격) → Collect → Sign(콜드룸) → Broadcast (BTC 소액) | 변경 (에어갭 흐름 → 5단계 파이프라인) |
| 12 | 대시보드 | Initiator | Zone 1 | 30m | 테스트 TX 2: ETH/USDC (EVM 흐름 검증) | 변경 최소 |
| 13 | 대시보드 | Admin | Zone 1 | 30m | 감사 로그 확인. 복구 드릴 일정 수립 | 변경 없음 |
총 소요 시간: v1(약 10~12시간, 1.5 영업일) → v2(약 8~10시간, 1 영업일)
핵심 변경점: - 키 세레모니 축소: v1(Approver 5명 각각 콜드월렛 키 생성 = 5대) → v2(마스터 콜드월렛 1대만) - Approver 온보딩: 개인 기기 키 생성은 원격으로 가능 (콜드룸 집결 불필요) - 콜드룸 집결 인원: v1(Super Admin + Approver 5명 + 증인 = 8명+) → v2(Super Admin + Operator 1명 + 증인 = 4명) - 공개키 등록: 5명의 approval_pk를 콜드월렛 SE에 등록하는 별도 단계 추가
7. 콜드룸 비집결 시나리오 분석표¶
7.1. 전체 시나리오 비교¶
| 시나리오 | v1 콜드룸 인원 | v2 콜드룸 인원 | Approver 콜드룸? | 개선 효과 |
|---|---|---|---|---|
| S-01 일상 BTC 출금 | M명 (3명) | 1명 (Operator) | 불필요 | 소요 시간 30분+ → 5~10분 |
| S-02 배치 스테이블코인 전송 | M명 (2명) | 1명 (Operator) | 불필요 | 콜드룸 1~2시간 → 15~20분 |
| S-03 내부 월렛 이체 | M명 (2명) | 1명 (Operator) | 불필요 | 동일 패턴 |
| S-04 화이트리스트 등록 | 0명 | 0명 | 불필요 | 변경 없음 |
| S-05 긴급 출금 | M명 (2명) | 1명 (Operator) | 불필요 | 긴급 응답 20~30분 → 5~10분 |
| S-06a Approver 비가용 | 1명 (대체) | 0명 | 불필요 | 활성화 수 시간 → 수 분 |
| S-06b Operator 비가용 | N/A | 1명 (대체) | 불필요 | 신규 시나리오 |
| S-07a approval_sk 유출 | N/A | 0~1명 | 불필요 | 키 세레모니 불필요 |
| S-07b master_sk 유출 | 전원 | 전원 | 필요 (키 세레모니) | 긴급 응답만 원격화 |
| S-08a Approver 교체 | 3명+ | 0~1명 | 불필요 | 수 시간~반나절 → 1~2시간 |
| S-08b Operator 교체 | N/A | 2명+ | 불필요 | 신규 시나리오 |
| S-09 정책 변경 | 0명 | 0명 | 불필요 | 변경 최소 |
| S-10 감사 대응 | 0명 | 0명 | 불필요 | 승인 로그 추가 |
| S-11a 개인 기기 복구 | N/A | 0~1명 | 불필요 | RTO 2~4시간 → 30분~1시간 |
| S-11b 콜드월렛 복구 | 1명 | 1~2명 | 불필요 | 공개키 재등록 추가 |
| S-12 초기 설정 | 8명+ | 4명 | 부분 불필요 | 키 세레모니 대폭 축소 |
7.2. 정량적 개선 효과¶
| 지표 | v1 | v2 | 개선율 |
|---|---|---|---|
| Approver 콜드룸 집결이 필요한 시나리오 수 | 7/12 (S-01~03, S-05, S-07, S-08, S-12) | 1/16 (S-07b만) | 93.8% 감소 (v2 세분화 포함) |
| 일상 출금(S-01) 콜드룸 인원 | M명 (3~5명) | 1명 | 67~80% 감소 |
| 일상 출금(S-01) 소요 시간 | 30분+ (집결 대기 포함) | 5~10분 | 67~83% 단축 |
| 긴급 출금(S-05) 응답 시간 | 20~30분 (긴급 소집) | 5~10분 (원격 즉시) | 50~67% 단축 |
| Day-1(S-12) 콜드룸 인원 | 8명+ | 4명 | 50% 감소 |
| Day-1(S-12) 총 소요 시간 | 10~12시간 | 8~10시간 | 17~20% 단축 |
| Approver 교체(S-08a) 소요 시간 | 수 시간~반나절 | 1~2시간 | 50~80% 단축 |
| Approver 교체 시 자산 이전 | 필수 (BTC 전체) | 불필요 | 리스크 완전 제거 |
7.3. 콜드룸 여전히 필요한 시나리오¶
다음 시나리오에서는 v2에서도 콜드룸이 필요하다:
- S-07b (master_sk 유출): 긴급 키 세레모니 시 콜드룸에서 새 콜드월렛 키 생성 필수
- 모든 Sign 단계: Operator가 콜드월렛을 운용하는 모든 경우 (S-01, S-02, S-03, S-05 등)
- S-12 초기 설정: 콜드월렛 키 세레모니 + Approval Verifier 초기화
단, 콜드룸 필요 인원은 모든 경우에서 v1 대비 감소한다.
8. 시나리오-역할 트레이서빌리티 매트릭스 (v2)¶
| 시나리오 | Super Admin | Admin | Initiator | Approver | Operator | Viewer |
|---|---|---|---|---|---|---|
| S-01 일상 BTC 출금 | - | - | P | P | P | - |
| S-02 배치 스테이블코인 전송 | - | - | P | P | P | - |
| S-03 내부 월렛 이체 | - | - | P | P | P | - |
| S-04 화이트리스트 등록 | - | P | S | - | - | - |
| S-05 긴급 출금 | - | P | P | P | P | - |
| S-06a Approver 비가용 | - | P | - | P | - | - |
| S-06b Operator 비가용 | - | P | - | - | P | - |
| S-07a approval_sk 유출 | S | P | - | P | - | - |
| S-07b master_sk 유출 | P | P | S | P | P | - |
| S-08a Approver 교체 | S | P | - | P | - | - |
| S-08b Operator 교체 | S | P | - | - | P | - |
| S-09 정책 변경 | - | P | - | - | - | - |
| S-10 감사 대응 | - | S | - | - | - | P |
| S-11a 개인 기기 복구 | S | P | - | P | - | - |
| S-11b 콜드월렛 복구 | P | S | - | - | P | - |
| S-12 초기 설정 (Day-1) | P | P | S | P | P | S |
P = Primary (주요 역할), S = Secondary (보조 역할), - = 미참여
역할별 참여 시나리오 수: | 역할 | Primary | Secondary | 총 참여 | |------|---------|-----------|---------| | Super Admin | 2 | 4 | 6 | | Admin | 10 | 2 | 12 | | Initiator | 4 | 2 | 6 | | Approver | 9 | 0 | 9 | | Operator | 8 | 0 | 8 | | Viewer | 1 | 1 | 2 |
9. v1 -> v2 변경 영향 요약¶
9.1. 변경 통계¶
| 지표 | 수치 |
|---|---|
| 변경된 시나리오 수 | 10/12 (S-04, S-09 제외 전부) |
| 세분화된 시나리오 수 | 4개 → 8개 (S-06, S-07, S-08, S-11 각각 a/b 분리) |
| 총 시나리오 수 | v1: 12개 → v2: 16개 |
| Approver 콜드룸 불필요로 전환 | 7개 시나리오 (일상 3 + 긴급 2 + 관리 1 + 복구 1) |
| 신규 Operator 참여 시나리오 | 8개 (일상 3 + 긴급 3 + 관리 1 + 복구 1) |
9.2. 세분화 목록¶
| v1 시나리오 | v2 세분화 | 근거 |
|---|---|---|
| S-06 서명자 비가용 | S-06a Approver 비가용 + S-06b Operator 비가용 | Approver/Operator 역할 분리로 비가용 유형 구분 |
| S-07 보안 침해 | S-07a approval_sk 유출 + S-07b master_sk 유출 | 키 독립성으로 유출 영향 범위 상이 |
| S-08 서명자 교체 | S-08a Approver 교체 + S-08b Operator 교체 | 교체 절차 완전 상이 (기기 vs 물리 인수인계) |
| S-11 디바이스 복구 | S-11a 개인 기기 복구 + S-11b 콜드월렛 복구 | 복구 전략 상이 (교체 우선 vs 시드 복원) |
9.3. Phase 28 반영 필요 사항¶
본 문서의 결과는 Phase 28(사용자 플로우 재설계)에서 다음과 같이 반영되어야 한다:
- 4대 핵심 플로우 재설계: 일상출금(S-01), 키세레모니(S-12), 서명자교체(S-08a/b), 긴급출금(S-05)의 UI/UX 플로우에 5단계 파이프라인 + Operator 역할 반영
- 기존 산출물 수정: operational-scenarios.md(v1)를 본 문서(v2)로 교체하거나 참조 전환
- 대시보드 UI: 승인 상태 추적(5단계 파이프라인), Approver 원격 승인 알림, Operator 서명 실행 인터페이스
- 오프라인 앱: Approval Signature Collector 컴포넌트, ApprovalBundle 생성/전달 기능
- 개인 기기 UX: WYSIWYS 승인 화면, 긴급 승인("URGENT" 표시), 배치 승인 요약
본 문서는 Phase 26 Plan 02의 산출물로, Plan 01 rbac-v2-role-definitions.md의 역할 정의를 12개 운영 시나리오에 적용한 결과이다. 기존 operational-scenarios.md (Phase 3)의 v1 시나리오를 2단계 서명 아키텍처에 맞게 재배치한 v2 문서이다.
관련 문서¶
- RBAC v2 역할 체계 정의서 — 2단계 서명 아키텍처 기반 -- 제품 설계