v0.0

RBAC 역할 체계 정의서¶

1. Executive Summary¶

본 문서는 D'CENT 엔터프라이즈 콜드월렛 커스터디 솔루션의 역할 기반 접근 제어(RBAC) 체계를 정의한다. 엔터프라이즈 환경에서 요구되는 직무 분리, 최소 권한 원칙, 계층적 거버넌스를 반영한 5개 기본 역할과 커스텀 역할 확장 메커니즘을 설계한다.

핵심 설계 원칙: - 최소 권한 원칙 (Principle of Least Privilege): 각 역할에 필요한 최소한의 권한만 부여 - 직무 분리 원칙 (Separation of Duties): 트랜잭션 생성자(Initiator)와 승인자(Approver) 반드시 분리 - Deny-by-Default: 명시적으로 허용되지 않은 모든 접근은 차단

규제 근거: | 제약조건 | 출처 | 요구사항 | |----------|------|---------| | AC-AC-01 | CCSS Aspect 6, SOC 2, ISO A.5.2-3, ISMS-P 4.1 | RBAC 기반 역할 체계 | | AC-AC-02 | SOC 2 CC6.2, ISO A.8.5, ISMS-P 4.3 | 다중 인증 | | AC-AC-03 | CCSS Aspect 6, MiCA Art. 70 | 관리자 쿼럼 승인 기반 권한 변경 | | AC-AC-04 | CCSS Aspect 6, ISO A.6.1-2 | 정형화된 온보딩/오프보딩 |

2. 역할 체계 설계 원칙¶

2.1. 계층적 역할 vs 플랫 역할¶

모델	설명	장점	단점
계층적 (Hierarchical)	상위 역할이 하위 역할의 권한 상속	관리 용이, 승계 자연스러움	과다 권한 축적 위험
플랫 (Flat)	각 역할이 독립적 권한 보유	최소 권한 원칙 엄격 준수	관리 복잡도 증가

선택: 제한적 계층 모델 - Super Admin > Admin > (Initiator, Approver, Viewer)는 독립 - Super Admin은 Admin 권한을 포함하되, Initiator/Approver/Viewer는 상호 독립 - 한 사용자가 복수 역할을 가질 수 없음 (직무 분리 강제) — 단, Admin + Viewer는 예외 허용

2.2. 직무 분리 매트릭스¶

역할 조합	허용	사유
Initiator + Approver	금지	자기 승인 방지 (핵심 통제)
Initiator + Admin	금지	정책 조작 + 트랜잭션 생성 방지
Approver + Admin	금지	서명 + 정책 변경 동시 보유 방지
Admin + Viewer	허용	관리자의 조회 권한은 합리적
Initiator + Viewer	허용	트랜잭션 생성자의 조회 권한은 합리적
Approver + Viewer	허용	승인자의 조회 권한은 합리적

3. 기본 역할 정의 (5개)¶

3.1. Super Admin¶

항목	설명
대상 인원	1-2명 (CEO, CTO 등 최고 경영진)
핵심 역할	시스템 초기 설정, 역할 생성/삭제, 긴급 복구
콜드월렛 소유	필수 (마스터 키 세트 보유)
활성화 조건	초기 설정 및 긴급 상황에만 활성화 (일상적 사용 자제)
쿼럼 승인 필수	시스템 설정 변경, Admin 역할 부여/해제, 긴급 복구 실행

권한 범위: - 시스템 초기화 (최초 키 세레모니 주관) - Admin 역할 부여/해제 (쿼럼 필수 — Super Admin 간) - 긴급 복구 실행 (시스템 잠금, 긴급 자산 이전) - M-of-N 구성 변경 (최고 수준 변경) - 감사 로그 전체 접근 (읽기 전용)

3.2. Admin¶

항목	설명
대상 인원	2-5명 (CISO, 재무 책임자, 운영 관리자)
핵심 역할	정책 설정, 사용자 관리, 화이트리스트 관리
콜드월렛 소유	선택 (정책 서명 시 필요할 수 있음)
쿼럼 기반	중요 변경 시 최소 2명 Admin 합의 필수 (AC-AC-03)

권한 범위: - 정책 CRUD (생성, 수정, 삭제 — 쿼럼 승인) - 사용자 CRUD (Initiator, Approver, Viewer 역할 부여/해제) - 화이트리스트 관리 (주소 등록/삭제 승인) - 서명자 온보딩/오프보딩 주관 - 컴플라이언스 리포트 접근 및 생성 - 감사 로그 전체 접근

3.3. Initiator¶

항목	설명
대상 인원	2-10명 (재무팀, 트레저리 담당)
핵심 역할	트랜잭션 생성 및 요청
콜드월렛 소유	불필요 (서명 권한 없음)
제한	정책 범위 내에서만 TX 생성 가능

권한 범위: - 트랜잭션 생성 및 제출 (정책 사전 검증 통과 필수) - 자산 잔액 조회 (자신의 담당 월렛만) - 트랜잭션 상태 추적 (자신이 생성한 TX) - 화이트리스트 등록 요청 (승인은 Admin) - 트랜잭션 초안(Draft) 저장 및 삭제

3.4. Approver¶

항목	설명
대상 인원	3-9명 (경영진, 보안팀, 재무 임원)
핵심 역할	트랜잭션 승인 및 서명
콜드월렛 소유	필수 (M-of-N 서명 참여)
서명 방식	에어갭 환경에서 콜드월렛으로 서명

권한 범위: - 트랜잭션 승인/거부/보류 결정 - 콜드월렛을 통한 트랜잭션 서명 (에어갭) - 트랜잭션 상세 조회 (승인 대상 TX) - 자산 잔액 조회 (서명 대상 월렛)

3.5. Viewer¶

항목	설명
대상 인원	무제한 (감사팀, 컴플라이언스 담당, 외부 감사인)
핵심 역할	읽기 전용 조회
콜드월렛 소유	불필요
제한	어떤 데이터도 생성/수정/삭제 불가

권한 범위: - 트랜잭션 이력 조회 (전체 또는 필터링) - 자산 잔액 조회 (전체) - 감사 로그 조회 (전체) - 컴플라이언스 리포트 조회 (생성은 Admin/커스텀 역할만) - 정책 현황 조회

4. 커스텀 역할¶

4.1. 커스텀 역할 설계 원칙¶

기본 5개 역할을 기반으로 권한을 세분화하여 새 역할 구성
ABAC(Attribute-Based Access Control) 확장은 Phase 4 (DIF) 범위에서 심화
커스텀 역할 생성/수정/삭제는 Admin 쿼럼 승인 필수

4.2. 예시 커스텀 역할¶

커스텀 역할	기반 역할	추가/제한 권한	사용 시나리오
Compliance Officer	Viewer	+ 컴플라이언스 리포트 생성 권한	컴플라이언스 팀이 직접 리포트 생성
Treasury Manager	Initiator	+ 특정 금액 이하 자동 승인 (쿼럼 면제)	소액 일상 운영의 효율 향상
External Auditor	Viewer	특정 기간/월렛의 감사 로그만 조회 (범위 제한)	외부 감사인에게 최소 필요 정보만 노출
Emergency Operator	Initiator	+ 긴급 TX 생성 권한 (시간 제한 해제)	보안 비상 시 긴급 자산 이전

4.3. 커스텀 역할 생성 워크플로우¶

Admin이 커스텀 역할 생성 요청
    │
    ├─ 역할명, 설명, 기반 역할 지정
    ├─ 권한 항목 선택 (체크리스트)
    ├─ 제한 조건 설정 (시간, 금액, 월렛 범위)
    │
    ▼
Admin 쿼럼 승인 (최소 2명)
    │
    ▼
역할 생성 → 사용자 할당 가능
    │
    ▼
감사 로그 기록 (역할 생성 이벤트)

5. 역할별 권한 매트릭스¶

5.1. 기능 영역별 CRUD 매트릭스¶

기능 영역	Super Admin	Admin	Initiator	Approver	Viewer
트랜잭션 — 생성	-	-	C	-	-
트랜잭션 — 승인/서명	-	-	-	U	-
트랜잭션 — 조회	R	R	R (자기 TX)	R (승인 대상)	R
트랜잭션 — 전파	-	-	-	-	-
정책 — 생성/수정/삭제	CUD (쿼럼)	CUD (쿼럼)	-	-	-
정책 — 조회	R	R	R (적용 정책)	R (적용 정책)	R
사용자 — 생성/수정/삭제	CUD	CUD (쿼럼)	-	-	-
사용자 — 조회	R	R	R (자기 정보)	R (자기 정보)	R
월렛 — 생성/삭제	CUD (쿼럼)	CD (쿼럼)	-	-	-
월렛 — 잔액 조회	R	R	R (담당 월렛)	R (서명 월렛)	R
화이트리스트 — 관리	CUD (쿼럼)	CUD (쿼럼)	요청만 (C)	-	-
화이트리스트 — 조회	R	R	R (담당 범위)	R	R
감사 로그 — 조회	R	R	R (자기 활동)	R (자기 활동)	R
리포트 — 생성	C	C	-	-	-
리포트 — 조회	R	R	-	-	R
시스템 설정	CUD (쿼럼)	R	-	-	-

C = Create, R = Read, U = Update, D = Delete, 쿼럼 = Admin 2명 이상 승인 필수

5.2. 컴포넌트별 접근 범위¶

컴포넌트	Super Admin	Admin	Initiator	Approver	Viewer
온라인 대시보드	전체	관리 + 조회	TX 생성 + 조회	TX 승인 + 조회	조회만
오프라인 서명 앱	긴급 복구	정책 동기화	-	서명 수행	-
D'CENT X 콜드월렛	마스터 키	-	-	서명 키	-

6. 역할 할당 및 변경¶

6.1. 신규 사용자 온보딩 (AC-AC-04)¶

Step 1: Admin이 신규 사용자 등록 요청
 - 이름, 이메일, 조직 내 직책
 - 할당 역할 선택
    │
    ▼
Step 2: Admin 쿼럼 승인 (최소 2명)
    │
    ▼
Step 3: 계정 프로비저닝
 - 대시보드 계정 생성
 - MFA 설정 (PIN + 인증 앱)
    │
    ▼
Step 4 (Approver인 경우): 콜드월렛 프로비저닝
 - 키 세레모니 실행 (key-ceremony.md 참조)
 - 콜드월렛 할당 + 키 생성
 - 다중 서명 월렛에 공개키 등록
    │
    ▼
Step 5: 보안 교육
 - 역할별 권한/책임 설명
 - 보안 정책 서명
    │
    ▼
Step 6: 감사 로그 기록
 - 온보딩 완료 이벤트

6.2. 역할 변경¶

Admin이 역할 변경 요청
 - 대상 사용자, 현재 역할, 변경 역할
    │
    ▼
직무 분리 검증
 - 변경 후 직무 분리 위반 여부 확인
    │
    ▼
Admin 쿼럼 승인
    │
    ▼
역할 전환 실행
 - 이전 역할 권한 즉시 해제
 - 새 역할 권한 부여
 - (Approver→다른 역할): 대기 중인 승인/서명 재할당
    │
    ▼
감사 로그 기록

6.3. 오프보딩 절차¶

Admin이 오프보딩 요청 (퇴사, 역할 종료)
    │
    ▼
즉시 조치:
 ├─ 대시보드 접근 차단
 ├─ 오프라인 앱 세션 무효화
 └─ 대기 중인 승인/서명 재할당
    │
    ▼
키 관리 (Approver인 경우):
 ├─ 콜드월렛 회수
 ├─ SE 보안 삭제 (AC-KM-06)
 ├─ 키 로테이션 실행 (AC-KM-07)
 └─ 다중 서명 재구성 (해당 서명자 제거)
    │
    ▼
데이터 보존:
 - 해당 사용자의 활동 감사 로그 영구 보존
 - 계정 비활성화 (삭제하지 않음 — 감사 추적 보존)
    │
    ▼
감사 로그 기록

7. 인증 방식: 역할별 인증 수준 (AC-AC-02)¶

역할	인증 수준	인증 요소	비고
Super Admin	최고	PIN + 생체 + 콜드월렛 소유 + 2차 확인	2차 확인: 다른 Super Admin의 승인
Admin	높음	PIN + 인증 앱(TOTP) + 디바이스 인증서	관리 작업 시 추가 인증 요구
Initiator	중간	PIN + 인증 앱(TOTP)	고액 TX 생성 시 추가 인증
Approver	높음	PIN + 생체 + 콜드월렛 소유	콜드월렛 물리 버튼 = 최종 인증
Viewer	기본	PIN + 인증 앱(TOTP)	민감 리포트 접근 시 추가 인증

8. 컴플라이언스 매핑¶

제약조건 ID	설명	충족 방식
AC-AC-01	RBAC 기반 역할 체계	5개 기본 역할 + 커스텀 역할. 직무 분리 원칙 강제
AC-AC-02	다중 인증 (PIN + 생체 + 하드웨어)	역할별 인증 수준 차등 적용. Approver: PIN + 생체 + 콜드월렛
AC-AC-03	관리자 쿼럼 승인 기반 권한 변경	모든 권한 변경, 정책 변경, 사용자 관리에 Admin 쿼럼(최소 2명) 필수
AC-AC-04	정형화된 온보딩/오프보딩 절차	6단계 온보딩, 4단계 오프보딩 절차 정의

본 문서는 Phase 3 Core Product Design의 일부로, 정책 엔진(policy-engine.md)의 규칙 평가 시 역할별 권한이 컨텍스트로 사용된다. 다중 서명 워크플로우(multisig-workflow.md)의 Approver 역할 정의가 본 문서의 Approver 권한과 직접 연계된다.