v0.4
배포 모델별 데이터 소재지 및 통제 주체 매핑¶
1. Executive Summary¶
본 문서는 D'CENT 엔터프라이즈 콜드월렛 커스터디 솔루션의 7개 데이터 유형이 3개 배포 모델(Model A/B/C)에서 각각 어디에 물리적으로 저장되고 누가 통제하는지를 매핑하는 21셀 매트릭스를 작성한다. Phase 20(한국 금융 규제 심층 조사)과 Phase 21(EU 규제 조사)에서 "이 데이터가 어디에 있고 누가 통제하는가"를 기준으로 배포 모델별 규제 적합성을 평가하기 위한 입력 문서이다.
입력 문서:
- Plan 01 산출물: data-sensitivity-classification.md (민감도 등급 및 등급별 통제 요구사항)
- on-premise-zero-cloud.md (3가지 배포 모델 정의)
- dashboard-backend-architecture.md (Data Layer 구조 및 배포 모델별 구성 차이)
- three-zone-security-architecture.md (3-Zone 보안 아키텍처)
핵심 결과: - 21셀(7유형 x 3모델) 물리적 소재지 매트릭스 완성 - 21셀 통제 주체(고객/D'CENT/공동) 매트릭스 완성 - 배포 모델별 데이터 주권 수준 비교 평가 - Phase 20-21 규제 평가 입력 사항 요약
2. 배포 모델 개요¶
2.1. Model A: 완전 온프레미스 (Zero Cloud)¶
| 항목 | 내용 |
|---|---|
| 배포 위치 | 전체 기업 데이터센터 |
| 인프라 운영 | 기업 IT 팀 완전 자체 운영 |
| 클라우드 의존 | 없음 (제로) |
| 네트워크 | 블록체인 P2P + 승인자 VPN만 외부 연결 |
| 적합 기업 | 대기업, 금융기관, 규제 엄격 산업, 높은 IT 역량 보유 |
| 데이터 주권 | 완전 (모든 데이터 기업 통제) |
2.2. Model B: 하이브리드 (Hybrid)¶
| 항목 | 내용 |
|---|---|
| 배포 위치 | 서명/키 관리: 기업 온프레미스 / 대시보드/DB: 클라우드 Private VPC |
| 인프라 운영 | 서명 인프라: 기업 / 대시보드: 클라우드 IaaS 자체 운영 |
| 클라우드 의존 | 부분 (IaaS: AWS/Azure/GCP Private VPC) |
| 핵심 원칙 | 프라이빗 키와 서명은 절대 클라우드에 존재하지 않음 |
| 적합 기업 | 중견기업, IT 인력 제한적, 유연성 필요 |
| 데이터 주권 | 부분 (서명 데이터 기업 통제, 대시보드 데이터 클라우드) |
2.3. Model C: 매니지드 SaaS¶
| 항목 | 내용 |
|---|---|
| 배포 위치 | D'CENT 호스팅 멀티테넌트 인프라 |
| 인프라 운영 | D'CENT 전담 운영 |
| 기업 보유 | D'CENT X 콜드월렛 + 오프라인 서명 앱만 보유 |
| 핵심 원칙 | SaaS에서도 프라이빗 키는 기업 콜드월렛에만 존재 |
| 적합 기업 | 소규모 기업, 스타트업, 초기 도입 |
| 데이터 주권 | 제한적 (대시보드 데이터 D'CENT 인프라 의존) |
3. 통제 주체 정의¶
| 통제 주체 | 영문 | 정의 | 권한 범위 |
|---|---|---|---|
| 고객 단독 통제 | Customer | 물리적 접근, 논리적 접근, 암호화 키 모두 고객 소유. 인프라 운영·관리·접근 권한이 전적으로 고객에게 있음. | 데이터 생성/조회/수정/삭제, 백업/복구, 암호화 키 관리, 물리적 서버 접근, 네트워크 구성 |
| D'CENT 단독 통제 | D'CENT | D'CENT이 인프라 운영·접근 관리. 고객은 API/UI를 통해 데이터에 접근하되, 물리적 인프라와 논리적 접근 권한은 D'CENT이 보유. | 인프라 운영, 시스템 관리, 데이터 백업, 보안 패치 적용. 고객은 API/UI 통해 자기 데이터만 접근 |
| 공동 통제 | Shared | 인프라는 D'CENT이 운영하되, 고객이 추가 통제 메커니즘을 보유. 예: 고객 관리 암호화 키(Customer-Managed Encryption Key, CMEK)로 데이터 암호화, 또는 접근 통제 이중화(D'CENT 관리자 + 고객 승인 필요). | D'CENT: 인프라 운영, 시스템 관리. 고객: CMEK 보유, 접근 승인 권한, 감사 로그 독립 검증 |
통제 주체 배정 원칙 (민감도 등급 기반):
| 민감도 등급 | Model A | Model B | Model C |
|---|---|---|---|
| 극비 (Critical) | 고객 단독 통제 필수 | 고객 통제 필수 (SE 사본) + 클라우드 CMEK | 공동 통제 최소 보장 (CMEK + 격리 + 감사) |
| 기밀 (Confidential) | 고객 단독 통제 | 고객 통제 권장, 공동 통제 허용 | 공동 통제 허용 (CMEK + 격리 스키마) |
| 내부 (Internal) | 고객 단독 통제 | 공동 통제 허용 | D'CENT 통제 조건부 허용 |
| 공개 (Public) | 제한 없음 | 제한 없음 | 제한 없음 |
4. 21셀 매트릭스 -- 물리적 소재지¶
| 데이터 유형 | 민감도 | Model A (Zero Cloud) | Model B (Hybrid) | Model C (SaaS) |
|---|---|---|---|---|
| 트랜잭션 이력 | 극비 | 기업 온프레미스 Event Store (PostgreSQL) + Read DB (PostgreSQL) | 클라우드 Private VPC Event Store (RDS PostgreSQL) + Read DB (RDS) | D'CENT 호스팅 Event Store (격리 스키마 PostgreSQL) + Read DB (격리 스키마) |
| 승인 기록 | 극비 | 기업 온프레미스 Event Store (PostgreSQL) + Read DB (approval_view) | 클라우드 Private VPC Event Store (RDS) + Read DB (RDS, approval_view) | D'CENT 호스팅 Event Store (격리 스키마) + Read DB (격리 스키마, approval_view) |
| 정책 규칙 | 극비 | 기업 온프레미스 Event Store (PostgreSQL) + Read DB + Redis Cache + SE(하드웨어, 기업 보관) | 클라우드 Private VPC Event Store (RDS) + Read DB (RDS) + ElastiCache (Redis) + SE(하드웨어, 기업 보관) | D'CENT 호스팅 Event Store (격리 스키마) + Read DB + Redis (격리 키스페이스) + SE(하드웨어, 기업 보관) |
| 화이트리스트 | 극비 | 기업 온프레미스 PostgreSQL + SE(Merkle Root, 기업 보관) | 클라우드 Private VPC RDS + SE(Merkle Root, 기업 보관) | D'CENT 호스팅 DB (격리 스키마) + SE(Merkle Root, 기업 보관) |
| 잔액 정보 | 기밀 | 기업 온프레미스 Read DB (balance_view) + Redis Cache + 기업 셀프호스팅 블록체인 풀노드 | 클라우드 Private VPC RDS (balance_view) + ElastiCache + 하이브리드 블록체인 노드(외부 RPC + 인증서 피닝) | D'CENT 호스팅 DB (격리 스키마) + Redis (격리 키스페이스) + D'CENT 공유 블록체인 노드 |
| 사용자 정보 | 기밀 | 기업 온프레미스 PostgreSQL (Read DB) + Redis (세션/토큰 캐시) | 클라우드 Private VPC RDS + ElastiCache (세션/토큰) | D'CENT 호스팅 DB (격리 스키마) + Redis (격리 키스페이스, 세션/토큰) |
| 감사 로그 | 극비 | 기업 온프레미스 전용 Blob Storage (NAS/MinIO) + Event Store (PostgreSQL) | 클라우드 S3 (Private, 버킷 격리) + 기업 온프레미스 미러(옵션) + RDS (Event Store) | D'CENT 호스팅 Object Storage (테넌트 격리) + Event Store (격리 스키마) |
소재지 매트릭스 핵심 포인트:
- SE 하드웨어 사본: 정책 규칙(하드웨어 정책 엔진용)과 화이트리스트(Merkle Root)는 모든 배포 모델에서 SE에 사본이 존재한다. SE는 기업이 물리적으로 보관하므로, D'CENT SaaS 모델에서도 이 데이터의 물리적 사본은 기업 통제 하에 있다.
- 블록체인 노드: Model A는 기업 셀프호스팅 풀노드, Model B는 하이브리드(외부 RPC + 인증서 피닝), Model C는 D'CENT 공유 노드를 사용한다. 잔액 정보의 정확성은 블록체인 노드의 독립성에 직결된다.
- 격리 수준: Model C에서는 멀티테넌트 인프라의 격리 스키마(PostgreSQL), 격리 키스페이스(Redis), 테넌트 격리(Object Storage)로 논리적 분리를 보장한다.
5. 21셀 매트릭스 -- 통제 주체¶
| 데이터 유형 | 민감도 | Model A (Zero Cloud) | Model B (Hybrid) | Model C (SaaS) |
|---|---|---|---|---|
| 트랜잭션 이력 | 극비 | 고객 (기업 인프라 완전 통제) | 공동 (클라우드 IaaS 기업 운영 + CMEK 적용. 기업이 VPC 네트워크·DB 접근 권한 관리) | 공동 (D'CENT 인프라 운영, CMEK + 격리 스키마 + 고객 감사 권한) |
| 승인 기록 | 극비 | 고객 (기업 인프라 완전 통제) | 공동 (클라우드 IaaS 기업 운영 + CMEK. 승인 로직은 기업 관리 대시보드에서 실행) | 공동 (D'CENT 인프라 운영, CMEK + 격리 스키마 + 고객 감사 권한) |
| 정책 규칙 | 극비 | 고객 (DB + SE 모두 기업 통제) | 공동 (클라우드 DB: 기업 VPC + CMEK / SE 사본: 기업 물리 통제) | 공동 (DB: D'CENT 운영 + CMEK / SE 사본: 기업 물리 통제. SE가 최종 방어선으로 기업 통제 보장) |
| 화이트리스트 | 극비 | 고객 (DB + SE Merkle Root 모두 기업 통제) | 공동 (클라우드 DB: 기업 VPC + CMEK / SE Merkle Root: 기업 물리 통제) | 공동 (DB: D'CENT 운영 + CMEK / SE Merkle Root: 기업 물리 통제) |
| 잔액 정보 | 기밀 | 고객 (기업 풀노드 + DB 완전 통제) | 공동 (클라우드 DB: 기업 VPC 운영 / 블록체인 노드: 외부 RPC 의존) | D'CENT (D'CENT 공유 노드 + DB. 고객은 API/UI로만 접근. 단, 블록체인 공개 데이터이므로 고객이 독립 검증 가능) |
| 사용자 정보 | 기밀 | 고객 (기업 인프라 완전 통제) | 공동 (클라우드 DB: 기업 VPC + CMEK / 세션: ElastiCache 기업 관리) | 공동 (D'CENT 운영 + CMEK + 격리 스키마. GDPR/개인정보보호법 준수를 위한 DPA 체결 필수) |
| 감사 로그 | 극비 | 고객 (기업 전용 Blob Storage 완전 통제) | 공동 (클라우드 S3: 기업 VPC + CMEK + WORM 설정 / 온프레미스 미러 옵션으로 이중화) | 공동 (D'CENT 운영 + CMEK + 테넌트 격리 + 고객 독립 무결성 검증 인터페이스 제공) |
통제 주체 매트릭스 핵심 포인트:
-
Model A -- 전면 고객 통제: 모든 데이터가 고객 단독 통제 하에 있다. 극비/기밀 등급의 최소 통제 요구사항을 자동 충족한다.
-
Model B -- 공동 통제 중심: 클라우드 IaaS 위에 기업이 VPC를 구성하므로, 기업이 네트워크·DB 접근 권한을 직접 관리한다. CMEK 적용으로 D'CENT/클라우드 제공자가 데이터를 복호화할 수 없다. SE 사본이 있는 정책 규칙/화이트리스트는 기업의 물리적 통제가 추가로 보장된다.
-
Model C -- 공동 통제 + D'CENT 통제 혼합:
- 극비 데이터: CMEK + 격리 스키마 + 감사 권한으로 공동 통제를 보장한다.
- 잔액 정보: D'CENT 단독 통제이나, 블록체인 공개 데이터이므로 고객이 독립적으로 검증 가능하다.
- 정책 규칙/화이트리스트: SE에 사본이 있어 기업의 물리적 통제가 일부 보장된다.
- 사용자 정보: GDPR/개인정보보호법 준수를 위해 Data Processing Agreement(DPA) 체결이 필수이다.
- 감사 로그: 고객이 해시 체이닝 무결성을 독립적으로 검증할 수 있는 API/인터페이스를 제공해야 한다.
6. 배포 모델별 데이터 주권 수준 비교¶
| 평가 항목 | Model A (Zero Cloud) | Model B (Hybrid) | Model C (SaaS) |
|---|---|---|---|
| 데이터 물리적 통제 | 완전 -- 모든 데이터 기업 데이터센터 | 부분 -- 서명/SE 데이터 기업 통제, 대시보드 데이터 클라우드 VPC | 제한 -- 대시보드 데이터 D'CENT 인프라, SE 데이터만 기업 통제 |
| 제3자 접근 가능성 | 없음 -- 기업 IT 인력만 접근 | 클라우드 제공자 -- IaaS 수준 접근 가능(CMEK로 복호화 차단) | D'CENT + 클라우드 제공자 -- 운영 목적 접근 가능(CMEK로 복호화 차단) |
| 규제 감사 시 접근 제공 | 즉시 가능 -- 기업이 직접 감사인에게 접근 부여 | 조건부 -- 기업 VPC 접근 부여 가능, 클라우드 제공자 협조 필요 시 절차 소요 | D'CENT 협조 필요 -- DPA/SLA에 감사 접근 조항 포함 필수 |
| 데이터 삭제 실행 | 즉시 -- 기업이 직접 삭제 실행 | 부분 즉시 -- DB 삭제 기업 실행, 백업/아카이브 삭제 클라우드 절차 필요 | 요청 기반 -- D'CENT에 삭제 요청, SLA 내 처리 |
| 벤더 종속 | 없음 -- 완전 독립 | 클라우드 IaaS -- AWS/Azure/GCP 종속(IaaS 수준, 이전 가능) | D'CENT 의존 -- 대시보드 운영 전체가 D'CENT에 의존 |
| 국외 이전 리스크 | 없음 -- 국내 데이터센터 배치 | 클라우드 리전 선택 -- 국내/EU 리전 선택으로 통제 가능 | D'CENT 인프라 위치 -- D'CENT 서버 소재지에 따라 국외 이전 발생 가능 |
| Exit Strategy | 해당 없음 -- 기업 자체 인프라 | 클라우드 이전 -- 표준 데이터 Export/Import 절차 | 데이터 Export -- SLA에 Exit Strategy 조항 포함 필수 (DORA Art. 28 요구) |
| 독립 무결성 검증 | 완전 -- 기업이 직접 해시 체이닝 검증 | 가능 -- 기업 VPC 내 직접 검증 + 온프레미스 미러 옵션 | 제한적 -- D'CENT 제공 API를 통한 검증, 독립 검증 인터페이스 필요 |
데이터 주권 등급:
| 모델 | 데이터 주권 등급 | 적합 고객 유형 |
|---|---|---|
| Model A | 최고 (Sovereign) | 금융기관, 대기업, 규제 엄격 환경 |
| Model B | 높음 (Controlled) | 중견기업, IT 역량 보유, 유연성 필요 |
| Model C | 제한 (Managed) | 소규모 기업, 스타트업, 초기 도입 |
7. 민감도 등급별 소재지 제약 요약¶
7.1. 극비 (Critical) 데이터 -- 5개 유형¶
| 배포 모델 | 충족 수준 | 조건 |
|---|---|---|
| Model A | 완전 충족 | 모든 극비 데이터가 기업 인프라에 고객 단독 통제로 저장. 추가 조치 불필요. |
| Model B | 조건부 충족 | 클라우드 VPC에 저장되나 다음 조건 필수: (1) CMEK 적용으로 복호화 권한 고객 독점, (2) SE 사본 존재 데이터(정책/화이트리스트)는 기업 물리 통제 추가 보장, (3) 감사 로그 온프레미스 미러 옵션 권장, (4) VPC 네트워크 접근 통제 기업 관리. |
| Model C | 추가 보호 필수 | D'CENT 인프라에 저장되므로 다음 조치 필수: (1) CMEK 적용, (2) 격리 스키마(논리적 분리), (3) 고객 감사 권한(독립 무결성 검증 API), (4) DPA/SLA에 접근 제한·삭제 의무·Exit Strategy 명시, (5) SE 사본(정책/화이트리스트)으로 최소한의 기업 통제 보장. |
7.2. 기밀 (Confidential) 데이터 -- 2개 유형¶
| 배포 모델 | 충족 수준 | 조건 |
|---|---|---|
| Model A | 완전 충족 | 기업 인프라 고객 단독 통제. |
| Model B | 충족 | 클라우드 VPC + CMEK로 충분한 보호 수준. 잔액 정보는 외부 RPC 의존 시 다중 소스 교차 검증 필요. |
| Model C | 조건부 충족 | 격리 스키마 + CMEK 적용 필요. 사용자 정보(PII)는 GDPR/개인정보보호법 준수를 위한 DPA 체결 필수. 잔액 정보는 블록체인 공개 데이터이므로 고객 독립 검증으로 보완. |
8. Phase 20-21 규제 평가 입력 사항¶
8.1. 한국 규제 평가 시 참조할 핵심 데이터 소재지 제약¶
| 규제 | 핵심 쟁점 | 배포 모델별 영향 |
|---|---|---|
| 특금법 | 금감원 현장 검사 시 데이터 즉시 접근 | Model A: 즉시 가능 / Model B: VPC 접근 부여 절차 / Model C: D'CENT 협조 필요 (SLA 조항) |
| ISMS-P | 개인정보(사용자 정보) 국내 저장 의무 | Model A: 자동 충족 / Model B: 국내 리전 선택 / Model C: D'CENT 서버 국내 배치 필요 |
| 망분리 | 암호화폐 커스터디 데이터의 "중요업무" 해당 여부 | Model A: 물리적 분리로 충족 / Model B-C: 망분리 완화 적용 가능성 검토 필요 |
8.2. EU 규제 평가 시 참조할 핵심 데이터 소재지 제약¶
| 규제 | 핵심 쟁점 | 배포 모델별 영향 |
|---|---|---|
| GDPR | 데이터 레지던시 + 삭제 요청 대응 | Model A: EU 데이터센터 배치 가능 / Model B: EU 리전 선택 / Model C: D'CENT EU 서버 필요 |
| MiCA | CASP 제3자 위탁 보고 의무 | Model A: 해당 없음 / Model B: 클라우드 위탁 보고 / Model C: D'CENT이 CASP에 해당할 가능성 |
| DORA | ICT 제3자 리스크 관리 (exit strategy, audit rights, data location) | Model A: 해당 없음 / Model B: 클라우드 제공자 계약 / Model C: D'CENT 계약에 DORA 조항 필수 |
8.3. 데이터 처리자(Processor) vs 데이터 통제자(Controller) 역할 정의¶
GDPR/DORA 맥락에서 배포 모델별 역할 정의:
| 역할 | Model A | Model B | Model C |
|---|---|---|---|
| 데이터 통제자 (Controller) | 고객 단독 | 고객 단독 | 고객 (법적 통제자) |
| 데이터 처리자 (Processor) | 해당 없음 | 클라우드 IaaS 제공자 (Sub-processor) | D'CENT (Processor) + 클라우드 IaaS (Sub-processor) |
| D'CENT 역할 | 소프트웨어 제공자 (라이선스) | 소프트웨어 제공자 (라이선스) | 데이터 처리자 (Processor) -- DPA 체결 의무 |
| 필요 계약 | 소프트웨어 라이선스 계약 | 소프트웨어 라이선스 + 클라우드 DPA | D'CENT DPA + 클라우드 Sub-processor DPA |
핵심 시사점: - Model C에서만 D'CENT이 GDPR 상 데이터 처리자(Processor)로서 법적 의무를 부담한다. - Model B에서 클라우드 IaaS 제공자는 Sub-processor이나, 기업이 직접 계약하므로 D'CENT의 법적 책임은 제한적이다. - Model A에서 D'CENT은 순수 소프트웨어 제공자로서 데이터 처리에 관여하지 않는다.
9. 데이터 흐름 다이어그램 (모델별)¶
9.1. Model A (Zero Cloud) 데이터 흐름¶
┌─────────────────────────────────────────────────────────────────┐
│ 기업 데이터센터 (전체 고객 통제) │
│ │
│ [사용자] ──HTTPS/VPN──▶ [Nginx 리버스 프록시] │
│ │ │
│ ┌─────────▼─────────┐ │
│ │ 대시보드 API 서버 │ │
│ │ (서비스 레이어) │ │
│ └─────────┬─────────┘ │
│ │ │
│ ┌─────────────────┼─────────────────┐ │
│ │ │ │ │
│ ┌──────▼──────┐ ┌──────▼──────┐ ┌──────▼──────┐ │
│ │ PostgreSQL │ │ Redis │ │ Blob Storage│ │
│ │ │ │ │ │ (MinIO/NAS) │ │
│ │ ● Event │ │ ● 세션 캐시 │ │ │ │
│ │ Store │ │ ● 정책 캐시 │ │ ● 감사 로그 │ │
│ │ ● Read DB │ │ ● 토큰 캐시 │ │ ● 백업 │ │
│ │ │ │ │ │ │ │
│ │ [극비/기밀] │ │ [극비/기밀] │ │ [극비] │ │
│ │ 고객 통제 │ │ 고객 통제 │ │ 고객 통제 │ │
│ └─────────────┘ └─────────────┘ └─────────────┘ │
│ │
│ ┌─────────────┐ │
│ │ 블록체인 노드 │ ← P2P 인바운드 │
│ │ (BTC/ETH │ │
│ │ 풀노드) │ [기밀] 고객 통제 │
│ └─────────────┘ │
│ │
│ ══════════════════ 에어갭 (TB-3) ══════════════════ │
│ │
│ ┌─────────────────┐ ┌─────────────────┐ │
│ │ 오프라인 서명 앱 │──QR/USB-C─│ D'CENT X 콜드월렛│ │
│ │ (Zone 2) │ │ SE (Zone 3) │ │
│ │ │ │ │ │
│ │ │ │ ● 정책 규칙 사본 │ │
│ │ │ │ ● Merkle Root │ │
│ │ │ │ ● 프라이빗 키 │ │
│ │ │ │ [극비] 고객 통제 │ │
│ └─────────────────┘ └─────────────────┘ │
└─────────────────────────────────────────────────────────────────┘
9.2. Model B (Hybrid) 데이터 흐름¶
┌─────────────────────────────────────────────────────────────────┐
│ │
│ ┌────────────────── 클라우드 Private VPC (기업 관리) ──────────┐│
│ │ ││
│ │ [사용자] ──HTTPS──▶ [ALB/NLB] ││
│ │ │ ││
│ │ ┌───────────▼───────────┐ ││
│ │ │ 대시보드 API 서버 │ ││
│ │ │ (컨테이너) │ ││
│ │ └───────────┬───────────┘ ││
│ │ │ ││
│ │ ┌───────────────────┼───────────────────┐ ││
│ │ │ │ │ ││
│ │ ┌───▼────────┐ ┌──────▼──────┐ ┌─────────▼───┐ ││
│ │ │ RDS │ │ ElastiCache │ │ S3 (Private) │ ││
│ │ │ PostgreSQL │ │ Redis │ │ │ ││
│ │ │ │ │ │ │ ● 감사 로그 │ ││
│ │ │ ● Event │ │ ● 세션 캐시 │ │ │ ││
│ │ │ Store │ │ ● 정책 캐시 │ │ [극비] │ ││
│ │ │ ● Read DB │ │ │ │ 공동 통제 │ ││
│ │ │ │ │ [극비/기밀] │ │ (CMEK+WORM) │ ││
│ │ │ [극비/기밀] │ │ 공동 통제 │ └──────────────┘ ││
│ │ │ 공동 통제 │ └─────────────┘ ││
│ │ │ (CMEK) │ ││
│ │ └────────────┘ ┌─────────────┐ ││
│ │ │ 블록체인 노드 │ ← 외부 RPC ││
│ │ │ (하이브리드) │ + 인증서 피닝 ││
│ │ │ [기밀] │ ││
│ │ │ 공동 통제 │ ││
│ │ └─────────────┘ ││
│ └──────────────────────────────────────────────────────────────┘│
│ │
│ ── 암호화 채널 ───────────────────────────────────── │
│ │
│ ┌────────────────── 기업 온프레미스 ──────────────────────────┐ │
│ │ │ │
│ │ ┌──────────────────┐ │ │
│ │ │ 감사 로그 미러 │ ← 온프레미스 이중화 (옵션) │ │
│ │ │ [극비] 고객 통제 │ │ │
│ │ └──────────────────┘ │ │
│ │ │ │
│ │ ══════════ 에어갭 (TB-3 / TB-4) ══════════ │ │
│ │ │ │
│ │ ┌─────────────────┐ ┌─────────────────┐ │ │
│ │ │ 오프라인 서명 앱 │──QR/USB-C─│ D'CENT X 콜드월렛│ │ │
│ │ │ (Zone 2) │ │ SE (Zone 3) │ │ │
│ │ │ │ │ ● 정책 규칙 사본 │ │ │
│ │ │ │ │ ● Merkle Root │ │ │
│ │ │ │ │ [극비] 고객 통제 │ │ │
│ │ └─────────────────┘ └─────────────────┘ │ │
│ └──────────────────────────────────────────────────────────────┘ │
└─────────────────────────────────────────────────────────────────┘
9.3. Model C (SaaS) 데이터 흐름¶
┌─────────────────────────────────────────────────────────────────┐
│ │
│ ┌────────────────── D'CENT 호스팅 인프라 ────────────────────┐ │
│ │ │ │
│ │ [사용자] ──HTTPS──▶ [D'CENT 인프라 LB] │ │
│ │ │ │ │
│ │ ┌───────────▼───────────┐ │ │
│ │ │ 대시보드 API 서버 │ │ │
│ │ │ (멀티테넌트) │ │ │
│ │ └───────────┬───────────┘ │ │
│ │ │ │ │
│ │ ┌───────────────────┼───────────────────┐ │ │
│ │ │ │ │ │ │
│ │ ┌───▼────────┐ ┌──────▼──────┐ ┌─────────▼───┐ │ │
│ │ │ PostgreSQL │ │ Redis │ │ Object │ │ │
│ │ │ (격리 │ │ (격리 │ │ Storage │ │ │
│ │ │ 스키마) │ │ 키스페이스) │ │ (테넌트 │ │ │
│ │ │ │ │ │ │ 격리) │ │ │
│ │ │ [극비/기밀] │ │ [극비/기밀] │ │ [극비] │ │ │
│ │ │ 공동 통제 │ │ 공동 통제 │ │ 공동 통제 │ │ │
│ │ │ (CMEK) │ │ │ │ (CMEK) │ │ │
│ │ └────────────┘ └─────────────┘ └──────────────┘ │ │
│ │ │ │
│ │ ┌─────────────┐ │ │
│ │ │ 블록체인 노드 │ ← D'CENT 공유 인프라 │ │
│ │ │ (공유) │ │ │
│ │ │ [기밀] │ │ │
│ │ │ D'CENT 통제 │ │ │
│ │ └─────────────┘ │ │
│ │ │ │
│ │ ┌──────────────────────────────────────────────────────┐ │ │
│ │ │ 고객 독립 검증 인터페이스 │ │ │
│ │ │ ● 감사 로그 해시 체이닝 검증 API │ │ │
│ │ │ ● Proof of Reserve 독립 확인 API │ │ │
│ │ └──────────────────────────────────────────────────────┘ │ │
│ └──────────────────────────────────────────────────────────────┘ │
│ │
│ ┌────────────────── 기업 보관 ──────────────────────────────┐ │
│ │ │ │
│ │ ══════════ 에어갭 (TB-3 / TB-4) ══════════ │ │
│ │ │ │
│ │ ┌─────────────────┐ ┌─────────────────┐ │ │
│ │ │ 오프라인 서명 앱 │──QR/USB-C─│ D'CENT X 콜드월렛│ │ │
│ │ │ (Zone 2) │ │ SE (Zone 3) │ │ │
│ │ │ │ │ ● 정책 규칙 사본 │ │ │
│ │ │ │ │ ● Merkle Root │ │ │
│ │ │ │ │ ● 프라이빗 키 │ │ │
│ │ │ │ │ [극비] 고객 통제 │ │ │
│ │ └─────────────────┘ └─────────────────┘ │ │
│ └──────────────────────────────────────────────────────────────┘ │
└─────────────────────────────────────────────────────────────────┘
다이어그램 핵심 포인트: - 모든 모델에서 프라이빗 키와 SE 데이터(정책 규칙 사본, Merkle Root)는 기업의 물리적 통제 하에 있다. - Model B/C에서 CMEK(Customer-Managed Encryption Key)를 적용하여 인프라 운영자(클라우드/D'CENT)가 데이터를 복호화할 수 없도록 보장한다. - Model C에서는 고객 독립 검증 인터페이스를 통해 감사 로그 무결성과 자산 현황을 독립적으로 확인할 수 있어야 한다.
본 문서는 Phase 19 데이터 민감도 분류 및 데이터 주권 매핑의 두 번째 산출물로, Phase 20(한국 금융 규제 심층 조사)과 Phase 21(EU 규제 조사 및 경쟁사 벤치마킹)의 배포 모델별 규제 적합성 평가 기준을 제공한다. data-sensitivity-classification.md(민감도 4등급 분류), on-premise-zero-cloud.md(3가지 배포 모델), dashboard-backend-architecture.md(Data Layer 구조), three-zone-security-architecture.md(3-Zone 보안 아키텍처)를 참조하여 작성되었다.
관련 문서¶
- 데이터 민감도 분류 및 규제별 취급 요구사항 -- 규제 준수