v0.4
데이터 민감도 분류 및 규제별 취급 요구사항¶
1. Executive Summary¶
본 문서는 D'CENT 엔터프라이즈 콜드월렛 커스터디 솔루션의 온라인 대시보드 DB에 저장되는 7개 데이터 유형에 대해 민감도 4등급 분류를 수행하고, 각 유형별 규제 취급 요구사항을 정리한다. Phase 19의 첫 번째 산출물로서, 후속 Plan 02(배포 모델별 데이터 소재지 및 통제 주체 매핑)와 Phase 20-21(한국/EU 규제 심층 조사)의 데이터 분류 기반을 확보하는 것이 목적이다.
분류 대상 데이터 유형 (7개):
| # | 데이터 유형 | 영문명 | 주요 저장 컴포넌트 |
|---|---|---|---|
| 1 | 트랜잭션 이력 | TX History | Event Store (PostgreSQL) + Read DB |
| 2 | 승인 기록 | Approval Records | Event Store + Read DB (approval_view) |
| 3 | 정책 규칙 | Policy Rules | Event Store + Read DB + Redis Cache + SE(하드웨어) |
| 4 | 화이트리스트 | Whitelist | PostgreSQL + SE (Merkle Root) |
| 5 | 잔액 정보 | Balance Data | Read DB (balance_view) + Redis Cache + Blockchain Node |
| 6 | 사용자 정보 | User Data | PostgreSQL (Read DB) + Redis (세션) |
| 7 | 감사 로그 | Audit Logs | Blob Storage (전용 로그 저장소) + Event Store |
분류 방법론: CIA(기밀성, 무결성, 가용성) 영향 분석 기반 4등급 분류 + 메타데이터 민감성 독립 평가
핵심 원칙: "키 접근 없음 != 낮은 민감도" -- 에어갭 아키텍처에서 대시보드 데이터는 프라이빗 키에 접근하지 않지만, 메타데이터 상관 분석을 통해 자산 규모, 이동 패턴, 거래 상대방, 내부 통제 구조를 추론할 수 있으므로 독립적인 민감성 평가가 필수이다.
2. 분류 방법론¶
2.1. 민감도 4등급 정의¶
| 등급 | 영문 | 정의 | CIA 영향 기준 | 접근 통제 수준 |
|---|---|---|---|---|
| 극비 | Critical | 침해 시 자산의 직접적 유출 위험 또는 전체 보안 체계 무력화 가능. 복구 불가능하거나 극히 어려운 피해 | C=H 또는 I=H이면서 자산 보안에 직접 영향 | 최소 권한 원칙 엄격 적용, 다중 인증 필수, 쿼럼 승인 기반 접근, 암호화 필수 |
| 기밀 | Confidential | 침해 시 자산 보안에 간접 영향 또는 규제 위반, 사업적 손해 가능. 복구 가능하나 상당한 비용·시간 소요 | C=H 또는 I=H (자산 간접 영향), 또는 PII/규제 대상 데이터 | RBAC 기반 접근 통제, 암호화 저장, 접근 로그 기록 |
| 내부 | Internal | 침해 시 운영 효율성 저하 또는 제한적 사업 영향. 외부 유출 시 경쟁사에 유리한 정보 제공 가능 | C=M 또는 I=M, A=H | 인증된 내부 사용자 접근, 전송 시 암호화 |
| 공개 | Public | 침해가 발생하더라도 사업적·법적 영향 없음. 이미 공개된 정보이거나 공개 가능한 정보 | C=L, I=L, A=L | 특별 접근 통제 불필요 |
2.2. CIA 영향 수준 정의¶
| 수준 | 영문 | 기밀성(C) 침해 시 | 무결성(I) 침해 시 | 가용성(A) 침해 시 |
|---|---|---|---|---|
| High (H) | 높음 | 자산 유출 경로 노출, 규제 처벌, 고객 신뢰 상실 | 부정 거래 승인, 자산 손실, 감사 실패 | 거래 실행 불가, 자산 동결, SLA 위반 |
| Medium (M) | 중간 | 경쟁사에 전략 정보 노출, 제한적 프라이버시 침해 | 운영 비효율, 잘못된 의사결정 | 서비스 지연, 부분적 기능 제한 |
| Low (L) | 낮음 | 공개 정보 수준, 실질적 피해 없음 | 사소한 오류, 즉시 교정 가능 | 일시적 불편, 대안 경로 존재 |
2.3. 분류 원칙¶
- 등급 상향 원칙: CIA 3개 항목 중 하나라도 High이면 최소 기밀(Confidential) 이상으로 분류한다.
- 메타데이터 고려 원칙: 개별 데이터가 낮은 민감도라도, 상관 분석(cross-correlation)을 통해 고위험 정보가 도출되는 경우 상위 등급으로 재분류한다.
- 규제 상향 원칙: 적용 규제 중 가장 엄격한 요구사항을 기본으로 적용한다. 예: GDPR 개인정보 해당 시 최소 기밀 이상.
- 에어갭 아키텍처 고려: 오프라인 영역(Zone 2, Zone 3) 데이터는 물리적 접근 통제로 추가 보호되므로, 동일 데이터라도 Zone 1(온라인) 소재 시 민감도가 상대적으로 높아진다.
- "키 접근 없음 != 낮은 민감도" 원칙: 대시보드 DB의 모든 데이터는 프라이빗 키에 접근하지 않는다(에어갭 아키텍처 보장). 그러나 트랜잭션 패턴, 잔액 변동, 승인자 행동 패턴 등의 메타데이터는 자산 보안에 간접적이지만 심대한 위험을 초래할 수 있으므로, 키 접근 여부와 독립적으로 민감도를 평가한다.
3. 데이터 유형별 민감도 분류표¶
3.1. 트랜잭션 이력 (TX History)¶
데이터 설명:
대시보드 백엔드의 Event Store(PostgreSQL)에 Event Sourcing 패턴으로 저장되는 트랜잭션 전체 라이프사이클 이벤트이다. tx.created, tx.approved, tx.signed, tx.broadcast, tx.confirmed, tx.failed, tx.expired 등의 이벤트가 append-only로 기록되며, Read DB의 transaction_view에 최신 상태가 프로젝션된다. 구체적으로 TX ID, 송수신 주소, 금액, 자산 유형, 체인, 정책 검증 결과, 서명 해시, TX Hash, 블록 높이 등을 포함한다.
CIA 영향 분석:
| CIA 항목 | 영향 수준 | 근거 |
|---|---|---|
| 기밀성 (C) | High | 트랜잭션 이력 유출 시 자산 이동 패턴, 거래 금액, 거래 상대방 주소가 노출된다. 이를 통해 기업의 자산 규모, 거래 전략, 사업 파트너 관계를 추론할 수 있으며, 표적 공격의 정찰 정보로 직접 활용된다. |
| 무결성 (I) | High | 트랜잭션 이력이 변조되면 감사 추적이 무력화되고, 부정 거래의 은닉이 가능해진다. Event Store의 해시 체이닝(AC-AU-01) 무결성이 훼손되면 규제 감사 대응이 불가능하다. |
| 가용성 (A) | High | 트랜잭션 이력에 접근할 수 없으면 진행 중인 다중 서명 프로세스가 중단되고, TX 상태 확인 및 블록체인 전파가 불가능하다. 특금법 5년 보존 의무 미이행 시 규제 위반이다. |
민감도 등급: 극비 (Critical)
결정 근거: CIA 3개 항목 모두 High이다. 트랜잭션 이력은 기업의 자산 운용 전체를 재구성할 수 있는 핵심 데이터로, 침해 시 자산 보안에 직접적 위험을 초래한다. 특히 Event Sourcing 아키텍처에서 전체 이벤트 스트림이 유출되면 현재 상태뿐 아니라 모든 과거 상태까지 복원 가능하므로 피해 범위가 극대화된다.
메타데이터 민감성 독립 평가: 극히 높음 - 시간대 패턴: 트랜잭션 생성/승인 시간대 분석으로 기업의 업무 패턴, 시간대, 긴급 거래 빈도를 추론할 수 있다. - 금액 패턴: 거래 금액 분포 분석으로 자산 규모, 운용 전략(DCA, 대량 이체 등)을 파악할 수 있다. - 상대방 패턴: 반복 수신 주소 분석으로 주요 거래 파트너(거래소, OTC 데스크, 협력사)를 식별할 수 있다. - 상관 분석: 시간-금액-상대방 3차원 상관 분석 시, 기업의 재무 전략과 시장 포지션이 고도로 추론 가능하다.
프라이빗 키 접근 여부: 없음 에어갭 아키텍처에서 트랜잭션 이력은 Zone 1(온라인 대시보드)에 저장되며, 프라이빗 키는 Zone 3(SE)에만 존재한다. 그러나 키 접근이 없음에도 극비 등급인 이유는, 트랜잭션 메타데이터 자체가 표적 공격의 정찰 정보로서 자산 보안에 직접적 위험을 초래하기 때문이다.
3.2. 승인 기록 (Approval Records)¶
데이터 설명:
Event Store에 저장되는 트랜잭션 승인/거부 이벤트와 Read DB의 approval_view에 프로젝션되는 승인 현황 데이터이다. tx.approved, tx.rejected 이벤트에 승인자 ID, 승인 순서, 현재 승인 수(k/M), 거부 사유, 행위자 역할, IP 주소, 세션 ID 등이 기록된다. M-of-N 다중 서명의 쿼럼 달성 과정을 추적하는 핵심 거버넌스 데이터이다.
CIA 영향 분석:
| CIA 항목 | 영향 수준 | 근거 |
|---|---|---|
| 기밀성 (C) | High | 승인 기록 유출 시 다중 서명 쿼럼 구조(M-of-N), 각 승인자의 승인 패턴(속도, 거부율, 활동 시간대), 조직 내 의사결정 체계가 노출된다. 공격자가 소셜 엔지니어링 또는 표적 공격에 활용할 수 있다. |
| 무결성 (I) | High | 승인 기록이 변조되면 미승인 거래가 승인된 것으로 위장되거나, 정당한 승인이 삭제될 수 있다. 다중 서명 거버넌스의 신뢰 기반이 붕괴된다. |
| 가용성 (A) | High | 승인 기록에 접근할 수 없으면 진행 중인 다중 서명 프로세스의 현재 상태(몇 명이 승인했는지)를 확인할 수 없어 거래 실행이 중단된다. |
민감도 등급: 극비 (Critical)
결정 근거: CIA 3개 항목 모두 High이다. 승인 기록은 다중 서명 거버넌스의 핵심이며, 침해 시 쿼럼 구조 자체가 노출되어 보안 체계 무력화 경로를 제공한다. 특히 승인자 행동 패턴은 소셜 엔지니어링 공격의 직접적 입력이 된다.
메타데이터 민감성 독립 평가: 극히 높음 - 승인자 행동 패턴: 특정 승인자의 응답 속도, 거부율, 활동 시간대 분석으로 "가장 취약한 승인자"를 식별할 수 있다. - 쿼럼 구조 추론: 승인 순서와 승인 수 패턴으로 실제 쿼럼 구성(예: 3-of-5에서 항상 동일 3명이 승인)을 추론할 수 있다. - 의사결정 속도: 거래 금액별 승인 소요 시간 분석으로 내부 통제의 엄격도를 평가할 수 있다.
프라이빗 키 접근 여부: 없음 승인 기록은 Zone 1(온라인 대시보드)에서 관리되며 키에 접근하지 않는다. 그러나 승인 패턴 분석을 통해 다중 서명 보안 체계의 취약점을 식별할 수 있으므로 극비 등급이 적절하다.
3.3. 정책 규칙 (Policy Rules)¶
데이터 설명:
트랜잭션 정책 엔진의 규칙 데이터로, Event Store에 policy.created, policy.updated, policy.deleted 이벤트로 기록되고, Read DB에 현행 정책이 프로젝션된다. Redis에 정책 캐시가 유지되며, SE(하드웨어)에도 하드웨어 정책 엔진용 사본이 저장된다. 구체적으로 건당 한도, 일일 한도, 서명 횟수 제한, 쿨다운 기간, 화이트리스트 강제 여부, M-of-N 임계값 등을 포함한다.
CIA 영향 분석:
| CIA 항목 | 영향 수준 | 근거 |
|---|---|---|
| 기밀성 (C) | High | 정책 규칙 유출 시 공격자에게 정확한 공격 벡터를 제공한다. 건당 한도, 일일 한도, 서명 횟수 제한값을 알면 정책을 우회하는 최적 전략(한도 미만 분할 이체 등)을 설계할 수 있다. |
| 무결성 (I) | High | 정책 규칙이 변조되면 보안 한도가 상향되거나 화이트리스트 검증이 비활성화되어 부정 거래가 정책 검증을 통과할 수 있다. 특히 대시보드 정책과 SE 하드웨어 정책 간 불일치가 발생하면 이중 검증 체계가 무력화된다. |
| 가용성 (A) | High | 정책 규칙에 접근할 수 없으면 모든 트랜잭션의 정책 검증이 불가능해져 거래 처리가 전면 중단된다. |
민감도 등급: 극비 (Critical)
결정 근거: CIA 3개 항목 모두 High이며, 특히 기밀성 침해가 공격 벡터를 직접 제공한다는 점에서 극비가 적절하다. 정책 규칙은 보안 체계의 방어 로직 자체이므로, 노출 시 "방어 체계의 설계도를 공격자에게 건네주는 것"과 동일하다.
메타데이터 민감성 독립 평가: 높음 - 한도 패턴: 정책 변경 이력 분석으로 기업의 거래 규모 변화와 위험 허용 수준을 추적할 수 있다. - 정책 변경 빈도: 잦은 정책 변경은 내부 거버넌스 불안정을 시사하며, 이는 공격 시점 선택에 활용될 수 있다. - 쿨다운 설정: 쿨다운 기간은 긴급 대응 능력의 시간적 한계를 직접 노출한다.
프라이빗 키 접근 여부: 없음 정책 규칙은 키를 직접 다루지 않으나, SE 내부에도 사본이 존재하여 하드웨어 수준에서 최종 방어선 역할을 한다. 대시보드 정책이 침해되더라도 SE 정책이 독립적으로 방어하지만, 양쪽 정책이 모두 파악되면 공격자의 우회 설계가 가능해진다.
3.4. 화이트리스트 (Whitelist)¶
데이터 설명:
허용된 수신 주소 목록으로, PostgreSQL에 주소·체인·라벨이 저장되고, Merkle Tree로 구성되어 Merkle Root가 SE에 동기화된다. whitelist.added, whitelist.removed, whitelist.merkle_updated 이벤트가 Event Store에 기록된다. 쿼럼 승인 기반으로 추가/삭제가 관리되며, 변경 시 24시간 쿨다운이 적용된다.
CIA 영향 분석:
| CIA 항목 | 영향 수준 | 근거 |
|---|---|---|
| 기밀성 (C) | High | 화이트리스트 유출 시 기업의 거래 상대방(거래소, OTC 데스크, 협력사, 자회사) 전체가 노출된다. 이는 비즈니스 관계 네트워크의 직접적 유출이다. |
| 무결성 (I) | High | 화이트리스트가 변조되어 공격자 주소가 추가되면, 정당한 정책 검증을 통과하여 자산이 공격자에게 이체될 수 있다. 이는 자산의 직접적 유출 경로이다. |
| 가용성 (A) | Medium | 화이트리스트에 접근할 수 없으면 화이트리스트 강제 정책 하에서 모든 거래가 차단된다. 그러나 SE에 Merkle Root가 존재하므로 기존 등록 주소로의 거래는 SE 수준에서 검증 가능하다. |
민감도 등급: 극비 (Critical)
결정 근거: 기밀성과 무결성이 모두 High이며, 특히 무결성 침해 시 자산 유출로 직결된다. 가용성은 Medium이지만, 등급 상향 원칙(CIA 중 하나라도 High이면 최소 기밀 이상)과 무결성 침해의 심각성(직접적 자산 유출)을 고려하여 극비로 분류한다.
메타데이터 민감성 독립 평가: 높음 - 거래 상대방 네트워크: 화이트리스트 주소의 온체인 분석으로 기업의 전체 비즈니스 파트너 네트워크를 매핑할 수 있다. - 주소 추가/삭제 패턴: 새 주소 등록 빈도와 시점으로 사업 확장, 파트너 변경 등 전략적 움직임을 추적할 수 있다. - 라벨 정보: 주소에 부여된 라벨(기업명, 용도 등)이 유출되면 메타데이터 가치가 기하급수적으로 증가한다.
프라이빗 키 접근 여부: 없음 화이트리스트 자체는 키와 무관하나, Merkle Root가 SE에 동기화되어 하드웨어 수준 검증에 사용된다. 화이트리스트 변조는 키 없이도 자산 유출 경로를 생성할 수 있으므로 극비 등급이 적절하다.
3.5. 잔액 정보 (Balance Data)¶
데이터 설명:
월렛별·체인별 잔액으로, 블록체인 노드에서 동기화되어 Read DB의 balance_view에 프로젝션된다. Redis에 실시간 캐시가 유지되며, 블록 모니터링(BTC 60초/EVM 15초) 및 멤풀 모니터링으로 미확인 잔액이 반영된다. UTXO 세트(BTC), 토큰 잔액(ERC-20) 등 체인별 세부 잔액 데이터를 포함한다.
CIA 영향 분석:
| CIA 항목 | 영향 수준 | 근거 |
|---|---|---|
| 기밀성 (C) | High | 잔액 정보 유출은 기업의 자산 규모를 직접 노출한다. 이는 표적 공격의 동기를 제공하고(큰 자산 보유 확인), 피싱·소셜 엔지니어링 공격의 정밀도를 높인다. 또한 경쟁사에 재무 상태가 노출되는 사업적 피해가 발생한다. |
| 무결성 (I) | Medium | 잔액 정보가 변조되면 잘못된 잔액 기반으로 트랜잭션이 생성될 수 있으나, 실제 블록체인 전파 시점에 블록체인 노드가 잔액을 재검증하므로 자산 유출로 직결되지는 않는다. 다만 리밸런싱 엔진의 오작동을 유발할 수 있다. |
| 가용성 (A) | Medium | 잔액 정보에 접근할 수 없으면 대시보드에서 자산 현황 확인이 불가능하나, 블록체인 노드에서 직접 조회하거나 블록 탐색기를 통해 대안 확인이 가능하다. |
민감도 등급: 기밀 (Confidential)
결정 근거: 기밀성이 High이므로 등급 상향 원칙에 의해 최소 기밀 이상이다. 무결성과 가용성은 Medium으로, 잔액 변조 시 블록체인 자체의 검증 메커니즘이 최종 방어선 역할을 한다. 극비가 아닌 기밀로 분류하는 이유는, 잔액 자체는 블록체인 공개 데이터에서 파생되며(주소를 알면 누구나 잔액 조회 가능), 침해의 직접적 경로가 아니라 간접적 위험(표적 공격 동기 제공)에 해당하기 때문이다.
메타데이터 민감성 독립 평가: 높음 - 잔액 변동 패턴: 시계열 잔액 변동 분석으로 자산 운용 전략(매집, 분산, 리밸런싱 주기)을 추론할 수 있다. - Warm/Cold 비율: Warm Tier와 Cold Tier 간 잔액 비율로 운영 자금 규모와 리밸런싱 정책을 파악할 수 있다. - 멀티체인 분포: 체인별 자산 분포로 투자 포트폴리오 전략이 노출된다. - 주의: 블록체인 주소 자체가 공개 정보이므로, 주소-기업 연결(attribution)이 이루어지면 잔액은 자동으로 공개 수준이 된다. 그러나 D'CENT 시스템 내에서는 주소-기업 연결이 명시적으로 존재하므로 기밀 등급이 적절하다.
프라이빗 키 접근 여부: 없음 잔액 정보는 블록체인 공개 데이터의 캐시이며 키에 접근하지 않는다. 그러나 잔액의 크기는 표적 공격의 직접적 동기가 되므로, "키 접근 없음 != 낮은 민감도" 원칙의 대표적 사례이다.
3.6. 사용자 정보 (User Data)¶
데이터 설명:
대시보드 사용자 계정 데이터로, PostgreSQL(Read DB)에 사용자 ID, 이름, 이메일, 역할(Admin/Initiator/Approver/Viewer), 등록 디바이스 정보, MFA 설정이 저장된다. Redis에 세션 데이터(Access Token, Refresh Token, 세션 만료 시간)가 유지된다. user.created, user.role_changed, user.device_added, user.deactivated 이벤트가 Event Store에 기록된다.
CIA 영향 분석:
| CIA 항목 | 영향 수준 | 근거 |
|---|---|---|
| 기밀성 (C) | High | 사용자 정보에는 PII(개인식별정보: 이름, 이메일)가 포함되어 GDPR 및 한국 개인정보보호법의 직접 적용 대상이다. 또한 역할 정보 유출 시 각 사용자의 시스템 내 권한 수준이 노출되어, 고권한 사용자(Admin, Approver)를 표적으로 한 소셜 엔지니어링 공격에 활용된다. |
| 무결성 (I) | High | 사용자 정보가 변조되면 권한 에스컬레이션(Viewer → Admin)이 가능해지고, RBAC 기반 접근 통제 체계가 무력화된다. 특히 역할 변경은 쿼럼 승인이 필요한 고위험 작업이므로, 우회 시 거버넌스 전체가 붕괴한다. |
| 가용성 (A) | High | 사용자 정보에 접근할 수 없으면 인증/인가가 불가능하여 대시보드 접근 자체가 차단된다. Redis 세션 장애 시 모든 활성 세션이 만료되어 전체 사용자가 로그아웃된다. |
민감도 등급: 기밀 (Confidential)
결정 근거: CIA 3개 항목 모두 High이지만, 극비가 아닌 기밀로 분류하는 이유는 다음과 같다. (1) PII 침해는 규제 위반과 프라이버시 피해를 초래하지만 자산의 직접적 유출로 연결되지 않는다. (2) 역할 변조를 통한 권한 에스컬레이션은 심각하지만, 실제 자산 이동에는 추가로 다중 서명(콜드월렛 물리 승인)이 필요하므로 사용자 정보 변조만으로는 자산 유출이 불가능하다. (3) GDPR/개인정보보호법 적용으로 기밀 등급의 보호 수준이 법적으로 보장된다. 다만, CIA 3개 항목 모두 High인 점을 고려하여 기밀 등급 내 최상위(기밀-고위험)로 관리한다.
메타데이터 민감성 독립 평가: 높음 - 조직 구조 추론: 역할 분포(Admin 수, Approver 수)로 조직 규모와 거버넌스 구조를 추론할 수 있다. - 디바이스 정보: 등록 디바이스 유형과 수로 보안 인프라의 물리적 구성을 파악할 수 있다. - 세션 패턴: 로그인 시간대, 세션 지속 시간으로 운영 패턴을 분석할 수 있다.
프라이빗 키 접근 여부: 없음 사용자 정보는 대시보드 인증/인가에 사용되며 키에 접근하지 않는다. 그러나 고권한 사용자 식별은 소셜 엔지니어링 공격의 출발점이므로 기밀 등급이 적절하다.
3.7. 감사 로그 (Audit Logs)¶
데이터 설명: 전체 시스템 액션의 변조 불가(Immutable) 기록으로, Blob Storage(전용 로그 저장소)에 SHA-256 해시 체이닝으로 저장된다. Event Store의 이벤트를 기반으로 생성되되, 추가 메타데이터(행위자 IP, User Agent, 세션 ID)가 부가된다. 트랜잭션, 정책, 접근, 사용자 관리, 서명자 관리, 시스템, 보안 경고 7개 카테고리의 모든 이벤트가 기록되며, 5년 이상 보존이 법적으로 의무화되어 있다(AC-AU-03).
CIA 영향 분석:
| CIA 항목 | 영향 수준 | 근거 |
|---|---|---|
| 기밀성 (C) | High | 감사 로그는 시스템의 모든 활동을 기록하므로, 유출 시 다른 6개 데이터 유형의 메타데이터를 포괄적으로 노출한다. 트랜잭션 패턴, 승인 구조, 정책 변경 이력, 사용자 활동이 모두 포함되어 있어, 단일 데이터 소스로서 최대 정보량을 가진다. |
| 무결성 (I) | High | 감사 로그의 무결성은 전체 컴플라이언스 체계의 기반이다. 해시 체이닝이 훼손되면 규제 감사 대응이 불가능하고, 내부 부정 행위의 은닉이 가능해진다. AC-AU-01(변조 불가 감사 로그) 제약조건의 핵심 대상이다. |
| 가용성 (A) | Medium | 감사 로그에 일시적으로 접근할 수 없어도 트랜잭션 처리 자체에는 영향이 없다. 그러나 장기 미가용 시 규제 감사 대응이 불가능하고, 보안 사고 조사가 제한된다. |
민감도 등급: 극비 (Critical)
결정 근거: 기밀성과 무결성이 모두 High이며, 감사 로그는 다른 6개 데이터 유형의 메타데이터를 포괄적으로 포함하는 "메타 데이터"의 성격을 가진다. 단일 소스 유출로 전체 시스템의 운영 패턴이 노출되므로, 메타데이터 민감성 관점에서 최고 위험에 해당한다. 또한 무결성 침해 시 규제 컴플라이언스 전체가 붕괴하므로 극비가 적절하다.
메타데이터 민감성 독립 평가: 최고 - 포괄적 활동 기록: 감사 로그는 다른 모든 데이터 유형의 접근/변경/삭제 이력을 포함하므로, 단일 소스로서 시스템 전체의 운영 실태를 재구성할 수 있다. - 보안 이벤트 분석: 정책 위반 시도, WYSIWYS 불일치, 비정상 접근 시도 기록으로 보안 체계의 실제 방어 능력과 한계를 평가할 수 있다. - 시계열 상관 분석: 모든 이벤트의 시간 순서가 기록되어 있어, 복합 공격 시나리오의 설계 정보로 활용 가능하다.
프라이빗 키 접근 여부: 없음 감사 로그는 키에 접근하지 않으나, 키를 사용하는 모든 행위(서명 요청, 서명 결과)의 메타데이터를 기록한다. 이 메타데이터의 집합은 키 자체보다 넓은 정보 범위를 가지므로 극비 등급이 적절하다.
4. 민감도 분류 요약 매트릭스¶
| 데이터 유형 | C (기밀성) | I (무결성) | A (가용성) | 민감도 등급 | 메타데이터 민감성 | 키 접근 |
|---|---|---|---|---|---|---|
| 트랜잭션 이력 | H | H | H | 극비 (Critical) | 극히 높음 | 없음 |
| 승인 기록 | H | H | H | 극비 (Critical) | 극히 높음 | 없음 |
| 정책 규칙 | H | H | H | 극비 (Critical) | 높음 | 없음 |
| 화이트리스트 | H | H | M | 극비 (Critical) | 높음 | 없음 |
| 잔액 정보 | H | M | M | 기밀 (Confidential) | 높음 | 없음 |
| 사용자 정보 | H | H | H | 기밀 (Confidential) | 높음 | 없음 |
| 감사 로그 | H | H | M | 극비 (Critical) | 최고 | 없음 |
분류 결과 요약: - 극비 (Critical): 5개 -- 트랜잭션 이력, 승인 기록, 정책 규칙, 화이트리스트, 감사 로그 - 기밀 (Confidential): 2개 -- 잔액 정보, 사용자 정보 - 내부 (Internal): 0개 - 공개 (Public): 0개
시사점: 7개 데이터 유형 모두 기밀 이상이며, 공개 등급에 해당하는 데이터가 존재하지 않는다. 이는 엔터프라이즈 커스터디 시스템의 특성상 대시보드에 저장되는 모든 데이터가 자산 보안에 직간접적으로 연관되기 때문이다. 특히 "키 접근 없음"임에도 7개 중 5개가 극비로 분류되었으며, 이는 "키 접근 없음 != 낮은 민감도" 원칙을 명확히 입증한다.
5. 규제별 취급 요구사항¶
5.1. 한국 규제 프레임워크¶
5.1.1. 특금법 (가상자산이용자보호법 포함)¶
| 데이터 유형 | 보존 기간 | 암호화 요구 | 접근 통제 | 삭제 의무 | 국외 이전 제한 |
|---|---|---|---|---|---|
| 트랜잭션 이력 | 5년 (거래 기록 보존 의무) | 명시적 규정 없으나 ISMS-P 연계 시 필수 | 금감원 현장 검사 접근 권한 부여 의무 | 보존 기간 경과 후 삭제 가능 | 직접 규정 없으나 ISMS-P와 연계 |
| 승인 기록 | 5년 (거래 관련 기록) | 동일 | 금감원 접근 권한 | 보존 기간 후 삭제 가능 | 동일 |
| 정책 규칙 | 명시적 규정 없음 (내부 통제 기록으로 5년 권장) | 동일 | 내부 관리 | 제한 없음 | 직접 제한 없음 |
| 화이트리스트 | AML 기록으로 5년 | 동일 | 금감원 접근 권한 | 보존 기간 후 삭제 가능 | 동일 |
| 잔액 정보 | 5년 (자산 보유 현황 보고 의무) | 동일 | 금감원 접근 권한 (Proof of Reserve) | 보존 기간 후 삭제 가능 | 동일 |
| 사용자 정보 | 5년 (고객 확인 기록, KYC) | 동일 | 금감원 접근 권한 | 보존 기간 후 삭제 의무 | 동일 |
| 감사 로그 | 5년 (AC-AU-03) | 변조 방지 필수 (해시 체이닝) | 금감원 접근 권한 | 보존 기간 후 삭제 가능 | 동일 |
핵심 의무: - 금감원 현장 검사 시 모든 거래 관련 데이터에 대한 즉시 접근 제공 의무 - STR/CTR 보고 의무 (의심거래/고액거래) - 자산 현황 보고 의무 (Proof of Reserve)
5.1.2. ISMS-P¶
| 데이터 유형 | 보존 기간 | 암호화 요구 | 접근 통제 | 삭제 의무 | 국외 이전 제한 |
|---|---|---|---|---|---|
| 트랜잭션 이력 | 접근 기록 최소 1년, 거래 기록 5년 | AES-256 이상 at rest + TLS 1.3 전송 | RBAC 기반 접근 통제 (4.1), 접근 기록 보관 (6.2) | 보존 기간 후 안전 삭제 | 개인정보 포함 시 국내 저장 의무 |
| 승인 기록 | 5년 (접근 기록 + 거래 기록) | 동일 | 동일 | 동일 | 동일 |
| 정책 규칙 | 변경 이력 3년 이상 권장 | 동일 | 정책 변경은 쿼럼 승인 필수 (9.3 변경 관리) | 제한 없음 | 직접 제한 없음 |
| 화이트리스트 | 5년 | 동일 | 동일 | 동일 | 동일 |
| 잔액 정보 | 5년 | 동일 | 동일 | 동일 | 동일 |
| 사용자 정보 | 개인정보: 수집 목적 달성 시 즉시 파기 (8.4) | 동일 + KCMVP 고려 | 개인정보 접근 통제 강화 (8.1) | 즉시 파기 의무 (수집 목적 달성 시) | 국내 저장 의무 (개인정보) |
| 감사 로그 | 5년 | 변조 방지 + AES-256 | 별도 VLAN 격리, 읽기 전용 접근 (6.1) | 보존 기간 후 삭제 가능 | 개인정보 포함 시 국내 저장 의무 |
핵심 의무: - 개인정보(사용자 정보) 국내 저장 의무 - 접근 기록 최소 1년 보관 - 암호화 키 관리 절차 수립 (5.2) - KCMVP(국내 암호 모듈 검증) 적용 고려
5.2. EU 규제 프레임워크¶
5.2.1. GDPR¶
| 데이터 유형 | 보존 기간 | 암호화 요구 | 접근 통제 | 삭제 의무 | 국외 이전 제한 |
|---|---|---|---|---|---|
| 트랜잭션 이력 | 데이터 최소화 원칙 -- 필요한 기간만 보존 (다른 법적 보존 의무와 균형) | 적절한 기술적 조치 (Art. 32) -- 암호화 권장 | 접근 권한 최소화 원칙 | 삭제 요청 대응 의무 (Right to Erasure, Art. 17) -- 다른 법적 의무와 충돌 시 예외 가능 | 적정성 결정국 또는 적절한 보호 조치 필요 (한-EU 적정성 결정 2022.12 활용 가능) |
| 승인 기록 | 동일 | 동일 | 동일 | 동일 (승인자 PII 포함 시) | 동일 |
| 정책 규칙 | PII 미포함 시 GDPR 직접 적용 제한적 | 동일 | 동일 | PII 미포함 시 삭제 의무 제한적 | PII 미포함 시 제한 제한적 |
| 화이트리스트 | PII 연결 시 GDPR 적용 | 동일 | 동일 | PII 연결 시 삭제 의무 | 동일 |
| 잔액 정보 | PII 연결 시 GDPR 적용 | 동일 | 동일 | PII 연결 시 삭제 의무 | 동일 |
| 사용자 정보 | GDPR 핵심 적용 대상 -- 수집 목적 달성 시 즉시 삭제 또는 익명화 | 암호화 필수 (Art. 32 pseudonymisation + encryption) | DPIA 대상 가능 (Art. 35), 접근 기록 필수 | 삭제 요청 시 30일 내 대응 의무 (Art. 12) | 적정성 결정 또는 SCCs/BCRs 필수 |
| 감사 로그 | PII 포함 시 GDPR 적용 -- 감사 목적의 적법 이익(Art. 6(1)(f)) 근거 보존 가능 | 동일 | 동일 | 적법 이익 근거 시 삭제 의무 제한적 | PII 포함 시 이전 제한 |
핵심 의무: - Right to Erasure (삭제권) 대응: 사용자 정보 삭제 요청 시 30일 내 처리. 단, AML/특금법 보존 의무와 충돌 시 법적 의무 우선 - Data Protection Impact Assessment (DPIA): 대규모 PII 처리 시 사전 영향 평가 의무 - 한-EU 적정성 결정 (2022.12): 한국은 EU 적정성 결정을 받았으므로 한국-EU 간 개인정보 이전이 SCCs 없이 가능. 단, 적정성 결정 범위와 조건 확인 필요 - Data Processor vs Controller: 배포 모델에 따라 D'CENT의 역할 정의 필요 (Plan 02에서 상세화)
5.2.2. MiCA¶
| 데이터 유형 | 보존 기간 | 암호화 요구 | 접근 통제 | 삭제 의무 | 국외 이전 제한 |
|---|---|---|---|---|---|
| 트랜잭션 이력 | CASP 고객 데이터 보관 의무 (Art. 68) -- 최소 5년 | IT 시스템 보안 요구 (Art. 67) | 거버넌스 체계 요구 (Art. 70) | 보존 기간 후 삭제 가능 | 제3자 위탁 시 감독 기관 보고 의무 |
| 승인 기록 | 5년 (거버넌스 기록) | 동일 | 이사회 수준 책임 (Art. 70) | 보존 기간 후 | 동일 |
| 정책 규칙 | 거버넌스 기록으로 5년 | 동일 | 내부 통제 체계 (Art. 70) | 보존 기간 후 | 동일 |
| 화이트리스트 | 고객 자산 관리 기록으로 5년 | 동일 | 동일 | 동일 | 동일 |
| 잔액 정보 | 자산 보관 기록으로 5년 | 동일 | 분리 보관 증빙 (Art. 68) | 동일 | 동일 |
| 사용자 정보 | 고객 확인 기록으로 5년 | 동일 | 이해충돌 관리 (Art. 71) | GDPR과 병행 적용 | 동일 |
| 감사 로그 | 5년 (외부 감사 의무, Art. 75) | 동일 | 외부 감사 대응 (Art. 75) | 보존 기간 후 | 동일 |
핵심 의무: - CASP 인가 시 IT 시스템 거버넌스 요구사항 충족 증빙 - 제3자에게 데이터 처리 위탁 시 감독 기관에 사전 보고 - Model C(SaaS)에서 D'CENT이 CASP에 해당할 가능성 검토 필요 (Phase 21에서 심층 분석)
5.2.3. DORA¶
| 데이터 유형 | 보존 기간 | 암호화 요구 | 접근 통제 | 삭제 의무 | 국외 이전 제한 |
|---|---|---|---|---|---|
| 트랜잭션 이력 | ICT 리스크 관리 프레임워크 내 데이터 분류 기준 적용 | 암호화 프레임워크 수립 의무 (Art. 28-30) | ICT 리스크 관리 정책 내 접근 통제 | 보존 정책에 따름 | ICT 제3자 계약에 데이터 소재지 명시 의무 |
| 승인 기록 | 동일 | 동일 | 동일 | 동일 | 동일 |
| 정책 규칙 | 동일 | 동일 | 동일 | 동일 | 동일 |
| 화이트리스트 | 동일 | 동일 | 동일 | 동일 | 동일 |
| 잔액 정보 | 동일 | 동일 | 동일 | 동일 | 동일 |
| 사용자 정보 | 동일 | 동일 | 동일 | 동일 | 동일 |
| 감사 로그 | 동일 | 동일 | 동일 | 동일 | 동일 |
핵심 의무: - ICT 제3자 리스크 관리 (Art. 28-30): 클라우드/SaaS 제공자(D'CENT 포함 가능)에 대한 exit strategy, audit rights, 데이터 소재지 명시 의무 - 운영 복원력 테스트: 정기적인 ICT 복원력 테스트 (침투 테스트 포함) - 인시던트 보고: ICT 관련 인시던트 발생 시 감독 기관 보고 의무 (AC-RP-06) - 제3자 계약 요구사항: D'CENT이 ICT 제3자 서비스 제공자로 분류될 경우, 고객(금융기관)과의 계약에 DORA 요구 조항 포함 필수
5.3. 규제별 취급 요구사항 통합 매트릭스¶
| 데이터 유형 | 최대 보존 기간 | 암호화 (최엄격) | 접근 통제 (최엄격) | 삭제 의무 (최엄격) | 국외 이전 (최엄격) |
|---|---|---|---|---|---|
| 트랜잭션 이력 | 5년 (특금법/MiCA) | AES-256 at rest + TLS 1.3 | RBAC + 금감원 접근 권한 + DORA audit rights | 5년 후 삭제 가능 (GDPR 삭제 요청 시 법적 의무 우선) | ISMS-P 국내 저장(PII 포함 시) + DORA 소재지 명시 |
| 승인 기록 | 5년 | 동일 | 동일 | 동일 | 동일 |
| 정책 규칙 | 5년 (권장) | 동일 | 쿼럼 승인 기반 변경 통제 | 제한 없음 | DORA 소재지 명시 |
| 화이트리스트 | 5년 | 동일 | RBAC + 쿼럼 승인 | 5년 후 삭제 가능 | 동일 |
| 잔액 정보 | 5년 | 동일 | RBAC + Proof of Reserve | 5년 후 삭제 가능 | 동일 |
| 사용자 정보 | 목적 달성 시 즉시 삭제 (GDPR/ISMS-P) vs 5년 (특금법 KYC) | AES-256 + pseudonymisation(GDPR) | DPIA + 접근 기록 + RBAC | 30일 내 삭제 대응 (GDPR) -- AML 보존 의무와 균형 | 국내 저장 의무 (ISMS-P) + 적정성 결정 활용 (GDPR) |
| 감사 로그 | 5년 (AC-AU-03) | AES-256 + 해시 체이닝 + 변조 방지 | 별도 VLAN + 읽기 전용 + 외부 감사 대응 | 5년 후 삭제 가능 | ISMS-P 국내 저장(PII 포함 시) + DORA 소재지 명시 |
6. 분류 원칙 및 가이드라인¶
6.1. 등급 상향 원칙¶
CIA 3개 항목 중 하나라도 High인 경우 최소 기밀(Confidential) 이상으로 분류한다. 본 분류에서 7개 데이터 유형 모두 최소 1개 이상의 CIA 항목이 High이므로, 공개(Public) 또는 내부(Internal) 등급에 해당하는 데이터가 존재하지 않는다.
6.2. 메타데이터 고려 원칙¶
개별 데이터는 낮은 민감도라도, 상관 분석(cross-correlation) 시 높은 민감도로 재분류한다. 특히 다음 조합에 주의: - 트랜잭션 이력 + 잔액 정보: 자산 운용 전략 전체 재구성 - 승인 기록 + 사용자 정보: 다중 서명 거버넌스의 취약점 식별 - 감사 로그 (단독): 모든 유형의 메타데이터를 포괄적으로 포함
6.3. 규제 상향 원칙¶
적용 규제 중 가장 엄격한 요구사항을 기본 적용한다: - 보존 기간: 특금법/MiCA 5년 vs GDPR 최소화 원칙 → 법적 보존 의무(5년) 우선, 보존 기간 경과 후 GDPR 삭제 원칙 적용 - 암호화: ISMS-P AES-256 + GDPR pseudonymisation → 양쪽 모두 충족 - 국외 이전: ISMS-P 국내 저장 의무 + GDPR 적정성 결정 → 양쪽 기준 동시 충족 필요
6.4. 에어갭 아키텍처 고려¶
오프라인 영역(Zone 2, Zone 3) 데이터는 물리적 접근 통제로 추가 보호된다: - Zone 3 (SE): 정책 규칙(Merkle Root 포함), 화이트리스트(Merkle Root) -- 물리적 탬퍼 방지 + SE 암호화 - Zone 2 (오프라인 앱): 서명 세션 데이터(24시간 후 자동 삭제) -- 네트워크 격리 - Zone 1 (대시보드): 모든 7개 데이터 유형 -- 네트워크 노출 위험 최고, 따라서 가장 강력한 보호 필요
7. Phase 19-02 입력 사항¶
7.1. 민감도 등급별 최소 통제 요구사항¶
| 민감도 등급 | 물리적 통제 | 논리적 통제 | 암호화 | 접근 감사 |
|---|---|---|---|---|
| 극비 (Critical) | 고객 통제 필수 또는 강화된 공동 통제 | 다중 인증 + 쿼럼 승인 + RBAC | AES-256 at rest + TLS 1.3 in transit | 전 접근 기록 + 실시간 모니터링 |
| 기밀 (Confidential) | 고객 통제 권장, 공동 통제 허용 | RBAC + 다중 인증 | AES-256 at rest + TLS 1.3 in transit | 접근 기록 + 정기 감사 |
| 내부 (Internal) | 공동 통제 허용, D'CENT 통제 조건부 허용 | 인증된 사용자 접근 | 전송 암호화 필수, 저장 암호화 권장 | 접근 기록 |
| 공개 (Public) | 제한 없음 | 기본 접근 통제 | 전송 암호화 권장 | 기본 로깅 |
7.2. 등급별 데이터 소재지 제약¶
- 극비 데이터 (5개): Model A에서만 완전 충족. Model B에서는 SE 내 사본 + 클라우드 암호화로 조건부 충족. Model C에서는 추가 보호 조치(고객 관리 암호화 키, 격리 스키마, 감사 권한) 필수.
- 기밀 데이터 (2개): Model A/B에서 충족. Model C에서는 격리 스키마 + 고객 관리 암호화 키 + GDPR/개인정보보호법 준수 보장 필요.
- 내부/공개 데이터: 해당 없음 (모든 데이터가 기밀 이상).
7.3. Plan 02 매핑 시 고려사항¶
- 극비 데이터의 Model C 배치: 5개 극비 데이터가 D'CENT 호스팅 인프라에 저장될 때의 통제 주체를 "공동" 이상으로 확보하는 방안 설계 필요
- 사용자 정보의 국외 이전: ISMS-P 국내 저장 의무와 GDPR 적정성 결정을 동시에 고려한 소재지 설계
- 감사 로그의 무결성 보장: 배포 모델과 무관하게 해시 체이닝 무결성이 보장되어야 하므로, Model C에서도 고객이 독립적으로 무결성을 검증할 수 있는 메커니즘 필요
- 규제 감사 접근: 특금법 금감원 현장 검사 및 MiCA/DORA 감독 기관 접근을 배포 모델별로 어떻게 보장할지 설계
본 문서는 Phase 19 데이터 민감도 분류 및 데이터 주권 매핑의 첫 번째 산출물로, Plan 02(배포 모델별 데이터 소재지 및 통제 주체 매핑)와 Phase 20-21(한국/EU 규제 심층 조사)의 데이터 분류 기반을 제공한다. dashboard-backend-architecture.md(Data Layer 구조), regulatory-landscape.md(규제 환경), compliance-architecture-matrix.md(AC-ID 제약조건), audit-trail.md(감사 추적 체계)를 참조하여 작성되었다.
관련 문서¶
- 배포 모델별 데이터 소재지 및 통제 주체 매핑 -- 규제 준수