v0.0

온프레미스 / 제로클라우드 아키텍처 설계서¶

1. Executive Summary¶

본 문서는 D'CENT 엔터프라이즈 온라인 대시보드의 셀프호스팅 아키텍처와 클라우드 의존성 제거 방안을 설계한다. 기업이 클라우드 서비스에 의존하지 않고 전체 커스터디 인프라를 자체 운영할 수 있는 제로클라우드(Zero Cloud) 배포 모델을 정의하며, 기업의 규모와 IT 역량에 따라 선택 가능한 3가지 배포 모델을 제시한다.

1.1. 왜 제로클라우드가 엔터프라이즈 커스터디에 필요한가¶

동인	설명
데이터 주권	트랜잭션 데이터, 정책 설정, 감사 로그가 기업 통제 하에 보관
규제 대응	ISMS-P(국내 데이터 저장), GDPR/MiCA(EU 데이터 레지던시), 금융 규제(제3자 리스크)
보안 심화	클라우드 제공자의 보안 사고가 커스터디 시스템에 영향을 미치지 않음
벤더 독립	클라우드 벤더(AWS/Azure/GCP)에 대한 종속 제거
감사 투명성	전체 인프라가 기업 통제 → 규제 감사 시 완전한 접근 제공

2. 배포 모델 3가지 정의¶

2.1. Model A: 완전 온프레미스 (Zero Cloud)¶

┌─────────────────────────────────────────────────────────┐
│                  기업 데이터센터                           │
│                                                          │
│  ┌──────────────┐  ┌──────────────┐  ┌──────────────┐  │
│  │ 대시보드 서버  │  │ 데이터베이스  │  │ 블록체인 노드  │  │
│  │ (Web + API)   │  │ (PostgreSQL) │  │ (BTC/ETH)    │  │
│  └──────────────┘  └──────────────┘  └──────────────┘  │
│                                                          │
│  ┌──────────────┐  ┌──────────────┐                     │
│  │ 감사 로그 저장 │  │ 백업 저장소   │                     │
│  └──────────────┘  └──────────────┘                     │
│                                                          │
│  ── 방화벽 ──────────────────── VPN ──                   │
│                                                          │
│  인터넷 접근: 블록체인 노드 P2P + 승인자 VPN 접속만       │
│  클라우드 의존: 제로                                      │
└─────────────────────────────────────────────────────────┘

적합 기업: 대기업, 금융기관, 규제 엄격 산업, 높은 IT 역량 보유 장점: 완전한 데이터 주권, 최고 보안, 규제 자동 충족 단점: 높은 초기 투자, IT 인력 필요, 운영 복잡도 높음

2.2. Model B: 하이브리드¶

┌──────────────────────────────────────┐
│           기업 인프라 (온프레미스)       │
│                                       │
│  ┌──────────────┐  ┌──────────────┐  │
│  │ 오프라인 서명  │  │ 콜드월렛 관리  │  │
│  │ 앱 서버       │  │ (키/정책)     │  │
│  └──────────────┘  └──────────────┘  │
│                                       │
│  ── 암호화 채널 ──                     │
│         │                             │
│         ▼                             │
│  ┌──────────────────────┐            │
│  │ 클라우드 (Private VPC) │            │
│  │                       │            │
│  │  ┌─────────┐         │            │
│  │  │대시보드   │         │            │
│  │  │API 서버  │         │            │
│  │  └─────────┘         │            │
│  │  ┌─────────┐         │            │
│  │  │ DB      │         │            │
│  │  └─────────┘         │            │
│  └──────────────────────┘            │
└──────────────────────────────────────┘

적합 기업: 중견 기업, IT 인력 제한적, 유연성 필요 장점: 서명/키 관리는 온프레미스 보안, 대시보드 운영 부담 경감 단점: 클라우드 부분 의존, 데이터 일부 외부 저장 핵심 원칙: 프라이빗 키와 서명은 절대 클라우드에 존재하지 않음. 대시보드(TX 생성, 상태 관리)만 클라우드.

2.3. Model C: 매니지드 SaaS¶

┌──────────────────────────────────────┐
│        D'CENT 호스팅 인프라            │
│                                       │
│  ┌──────────────┐  ┌──────────────┐  │
│  │ 대시보드 서버  │  │ 데이터베이스  │  │
│  │ (멀티테넌트)   │  │ (격리 스키마) │  │
│  └──────────────┘  └──────────────┘  │
│                                       │
│  ┌──────────────┐                    │
│  │ 블록체인 노드  │                    │
│  │ (공유 인프라)  │                    │
│  └──────────────┘                    │
└──────────────────────────────────────┘

기업 측: D'CENT X 콜드월렛 + 오프라인 서명 앱만 보유
서명/키: 여전히 기업 콜드월렛에서 수행 (SaaS에 키 없음)

적합 기업: 소규모 기업, 스타트업, 초기 도입 단계 장점: 즉시 시작, 인프라 투자 불필요, 운영 부담 제로 단점: 대시보드 데이터 D'CENT 인프라 의존, 데이터 주권 제한 핵심 원칙: SaaS 모델에서도 프라이빗 키는 기업 콜드월렛에만 존재. D'CENT는 키에 접근 불가.

3. 온라인 대시보드 셀프호스팅 아키텍처¶

3.1. 최소 하드웨어 요구사항¶

Model A (완전 온프레미스) 최소 사양:

컴포넌트	최소 사양	권장 사양	비고
대시보드 서버	4 CPU, 16GB RAM, 100GB SSD	8 CPU, 32GB RAM, 500GB SSD	이중화 권장
데이터베이스 서버	4 CPU, 16GB RAM, 500GB SSD	8 CPU, 32GB RAM, 1TB SSD	Primary + Replica
BTC 풀노드	4 CPU, 8GB RAM, 1TB SSD	8 CPU, 16GB RAM, 2TB SSD	초기 동기화 수일 소요
ETH 풀노드	8 CPU, 32GB RAM, 2TB NVMe	16 CPU, 64GB RAM, 4TB NVMe	Execution + Consensus
감사 로그 저장소	-	500GB+ (5년 보존)	별도 스토리지 권장
방화벽/VPN	전용 어플라이언스	이중화 구성	기업 기준 네트워크 보안

총 초기 하드웨어 투자: 약 $30,000-80,000 (사양/이중화에 따라)

3.2. 소프트웨어 스택 (오픈소스 기반)¶

레이어	소프트웨어	선택 이유	라이선스
OS	Ubuntu Server 24.04 LTS / RHEL 9	장기 지원, 보안 패치	무료 / 상용
컨테이너	Docker + Docker Compose	배포 표준화, 환경 일관성	Apache 2.0
오케스트레이션	K8s (대규모) / Docker Compose (소규모)	확장성 vs 단순성	Apache 2.0
웹 서버	Nginx (리버스 프록시)	성능, TLS 종단	BSD 2-clause
애플리케이션	Node.js / Go (대시보드 백엔드)	비동기 처리, 성능	MIT / BSD
데이터베이스	PostgreSQL 16	ACID, 확장성, 오픈소스	PostgreSQL License
캐시	Redis	세션/캐시, 실시간 알림	BSD 3-clause
메시지 큐	RabbitMQ / NATS	이벤트 기반 아키텍처	MPL 2.0 / Apache 2.0
모니터링	Prometheus + Grafana	메트릭 수집, 대시보드	Apache 2.0
로그	Loki + Promtail	로그 집계, 검색	AGPLv3

클라우드 독점 서비스 대체:

클라우드 서비스	온프레미스 대체	비고
AWS RDS	PostgreSQL (자체 운영)	백업/복구 자동화 스크립트 제공
AWS SES	자체 SMTP (Postfix)	이메일 알림용
AWS KMS	HashiCorp Vault (Community)	대시보드 암호화 키 관리
CloudWatch	Prometheus + Grafana	모니터링/알림
S3	MinIO	오브젝트 스토리지 (백업)

3.3. 블록체인 노드 연결 방식¶

방식	보안	비용	복잡도	권장 모델
자체 풀노드	최고 (완전 독립)	높음 (하드웨어 + 운영)	높음	Model A
외부 RPC + 인증서 피닝	높음 (TLS 피닝)	중간 (RPC 서비스 비용)	낮음	Model B
D'CENT 공유 노드	중간	포함 (SaaS 비용)	최저	Model C

자체 풀노드 구성: - BTC: Bitcoin Core v27+ (pruned 모드 옵션: 10GB로 축소 가능) - ETH: Geth (execution) + Prysm/Lighthouse (consensus) - 최소 2개 노드 (Primary + Failover)

외부 RPC 사용 시 보안 강화:

외부 RPC 연결 보안:
1. TLS 1.3 필수 + 인증서 피닝 (Certificate Pinning)
2. 다중 RPC 소스 (최소 2개 제공자) — 단일 소스 조작 방지
3. 응답 교차 검증 — 2개 이상 RPC 응답 비교
4. 연결 IP 화이트리스트 — RPC 접근 제한

3.4. 네트워크 아키텍처¶

┌─ 인터넷 ────────────────────────────────────────────┐
│                                                      │
│  ┌─── DMZ ───────────────────────────────────────┐  │
│  │                                                │  │
│  │  [방화벽]                                       │  │
│  │    │                                           │  │
│  │    ├─ 블록체인 P2P (BTC 8333, ETH 30303)      │  │
│  │    ├─ VPN 인바운드 (승인자 접속)                 │  │
│  │    └─ HTTPS 443 (대시보드 웹 UI)               │  │
│  │                                                │  │
│  └────────────────────────────────────────────────┘  │
│         │                                           │
│         │ (내부 방화벽)                               │
│         ▼                                           │
│  ┌─── Internal Zone ─────────────────────────────┐  │
│  │                                                │  │
│  │  [Nginx 리버스 프록시]                          │  │
│  │    │                                           │  │
│  │    ├─▶ [대시보드 API 서버]                      │  │
│  │    │     ├─▶ [PostgreSQL]                      │  │
│  │    │     ├─▶ [Redis]                           │  │
│  │    │     └─▶ [메시지 큐]                        │  │
│  │    │                                           │  │
│  │    └─▶ [블록체인 노드]                          │  │
│  │          ├─ BTC 풀노드                          │  │
│  │          └─ ETH 풀노드                          │  │
│  │                                                │  │
│  │  [감사 로그 저장소] (별도 네트워크 세그먼트)       │  │
│  │                                                │  │
│  └────────────────────────────────────────────────┘  │
└──────────────────────────────────────────────────────┘

네트워크 보안 규칙: - 인바운드: VPN + HTTPS만 허용, 모든 다른 포트 차단 - 블록체인 노드: P2P 포트만 외부 오픈, RPC는 내부만 - DB: 외부 접근 불가, 대시보드 서버에서만 접근 - 감사 로그: 별도 VLAN, 읽기 전용 접근 (변조 방지)

4. 오프라인 서명 앱 배포¶

4.1. 에어갭 환경의 앱 설치/업데이트¶

오프라인 서명 앱은 네트워크 연결 없는 디바이스에서 실행되므로, 설치와 업데이트에 특별한 절차가 필요하다.

앱 배포 흐름:

[1] D'CENT 릴리스 서버에서 설치 패키지 다운로드
     ├─ 온라인 PC에서 다운로드
     └─ SHA-256 해시 + D'CENT 서명 확인

[2] 설치 패키지를 오프라인 미디어에 복사
     ├─ USB 드라이브 (읽기 전용 권장)
     └─ 또는 microSD 카드

[3] 에어갭 디바이스에 미디어 연결
     ├─ 설치 패키지 해시 재검증
     ├─ D'CENT 서명 재검증 (내장 공개키)
     └─ 설치/업데이트 수행

[4] 미디어 제거 후 에어갭 유지

4.2. 서명된 설치 패키지 검증¶

검증 항목	방식	실패 시
파일 무결성	SHA-256 해시 비교	설치 거부
발행자 인증	D'CENT 코드 서명 (ECDSA)	설치 거부 + 경고
버전 검증	현재 버전보다 높은 버전만 수락	다운그레이드 거부
호환성 검증	대시보드/펌웨어 버전 호환 체크	호환 경고 표시

5. 데이터 저장 설계¶

5.1. 모든 데이터 로컬 저장¶

데이터 유형	저장 위치	암호화	보존 기간
트랜잭션 이력	PostgreSQL	AES-256 at rest	무기한
감사 로그	전용 로그 저장소	AES-256 + 해시 체이닝	5년+ (AC-AU-01)
정책 설정/버전	PostgreSQL	AES-256 at rest	전 버전 영구 보존
사용자 세션	Redis	인메모리 (TTL)	세션 만료 시 삭제
블록체인 데이터	풀노드 데이터 디렉토리	미적용 (공개 데이터)	체인 동기화 범위
화이트리스트	PostgreSQL	AES-256 at rest	변경 이력 영구 보존

5.2. 백업/복구 (로컬 스토리지 기반)¶

백업 전략:

일일 백업:
  ├─ PostgreSQL: pg_dump 자동 스크립트 (매일 02:00)
  ├─ 감사 로그: 일일 아카이브 + 해시 체이닝 검증
  └─ 정책 설정: 버전별 스냅샷

주간 백업:
  ├─ 전체 시스템 스냅샷 (VM 스냅샷 또는 디스크 이미지)
  └─ 블록체인 노드 데이터 스냅샷 (선택)

백업 저장:
  ├─ 1차: 온사이트 백업 서버 (별도 물리 서버)
  ├─ 2차: 오프사이트 백업 (물리적 이격 위치)
  └─ 암호화: 백업 데이터 AES-256 암호화 후 저장

복구 절차:
  [1] 최신 백업에서 PostgreSQL 복원
  [2] 감사 로그 해시 체인 무결성 검증
  [3] 대시보드 서비스 재시작
  [4] 블록체인 노드 동기화 확인
  [5] 복구 테스트 트랜잭션 실행 (소액)

5.3. 암호화¶

암호화 유형	방식	키 관리
At Rest	AES-256-GCM (DB, 백업, 로그)	HashiCorp Vault 또는 LUKS
In Transit	TLS 1.3 (내부 통신 포함)	자체 CA 또는 구매 인증서
백업 암호화	AES-256 + 암호화 키 오프라인 보관	Admin 쿼럼 복호화

6. 운영 요구사항¶

6.1. Model A 운영 IT 인력/역량¶

역할	필요 인원	역량 요구
시스템 관리자	1-2명	Linux 서버 관리, Docker/K8s, DB 관리
네트워크 관리자	1명	방화벽, VPN, 네트워크 보안
블록체인 노드 운영	0.5명 (겸임 가능)	BTC/ETH 노드 구성, 동기화, 업그레이드
보안 담당	0.5명 (겸임 가능)	보안 모니터링, 인시던트 대응
최소 합계	2-3명	풀타임 IT 인력

6.2. 모니터링/알림 (자체 인프라 내)¶

모니터링 스택:

Prometheus (메트릭 수집)
  ├─ 대시보드 서버: CPU, 메모리, 디스크, 응답 시간
  ├─ DB: 연결 수, 쿼리 성능, 디스크 사용량
  ├─ 블록체인 노드: 동기화 상태, 블록 높이, P2P 연결
  └─ 네트워크: 트래픽, 방화벽 로그, VPN 상태

Grafana (시각화)
  ├─ 시스템 상태 대시보드
  ├─ 트랜잭션 처리 대시보드
  └─ 보안 이벤트 대시보드

알림 (자체 인프라):
  ├─ 이메일: 자체 SMTP (Postfix)
  ├─ SMS: 내부 SMS 게이트웨이 (선택)
  └─ 슬랙/Teams: 웹훅 (인터넷 필요)

6.3. 업데이트/패치 프로세스¶

대시보드 업데이트:
  [1] D'CENT 릴리스 노트 확인 (온라인 PC)
  [2] 업데이트 패키지 다운로드 + 해시/서명 검증
  [3] 스테이징 환경에서 테스트 (온프레미스 테스트 서버)
  [4] 변경 관리 승인 (IT 관리자)
  [5] 프로덕션 배포 (Docker 이미지 교체 또는 롤링 업데이트)
  [6] 배포 후 검증 (테스트 트랜잭션)

OS/DB 보안 패치:
  [1] 보안 패치 릴리스 모니터링 (CVE 추적)
  [2] 스테이징 환경 적용 + 호환성 테스트
  [3] 프로덕션 적용 (유지보수 윈도우 내)

블록체인 노드 업그레이드:
  [1] 하드포크/소프트포크 일정 확인
  [2] 새 버전 노드 준비 (병렬 구성)
  [3] 동기화 완료 후 전환
  [4] 이전 버전 노드는 폴백으로 유지

7. 규제 대응 이점¶

7.1. ISMS-P (한국)¶

ISMS-P 요구사항	온프레미스 대응
국내 데이터 저장	자동 충족 — 모든 데이터 국내 데이터센터
접근 통제	물리적 + 네트워크 접근 통제 직접 관리
암호화	자체 암호화 정책 적용
로그 관리	자체 감사 로그 저장소, 5년+ 보존
제3자 관리	클라우드 제3자 리스크 제거

규제 요구사항	온프레미스 대응
데이터 레지던시	EU 내 데이터센터 배포 가능
데이터 처리자 계약	불필요 — 자체 처리
삭제 권리 (RTBF)	자체 DB에서 직접 삭제
데이터 이동성	자체 DB에서 직접 추출
DORA 운영 복원력	자체 BCP/DR 계획 수립

7.3. 금융 규제 (글로벌)¶

규제 관심 영역	온프레미스 이점
제3자 클라우드 리스크	클라우드 의존 제거 → 리스크 분석 간소화
운영 독립성	외부 서비스 중단 영향 최소화
감사 접근성	전체 인프라에 대한 감사인 접근 보장
데이터 관할권	기업 소재지의 법적 관할권 자동 적용

8. 배포 모델별 비교 매트릭스¶

항목	Model A (Zero Cloud)	Model B (Hybrid)	Model C (SaaS)
보안 수준	최고	높음	중간
데이터 주권	완전	부분 (대시보드 클라우드)	제한적
초기 비용	높음 ($30K-80K HW)	중간 ($10K-30K)	낮음 (월 구독)
월 운영 비용	중간 (인력 + 전기 + 유지보수)	중간 (클라우드 + 인력)	낮음 (구독료만)
IT 인력 요구	2-3명 풀타임	1-2명 풀타임	0명 (D'CENT 운영)
도입 기간	2-4주	1-2주	즉시
확장성	수동 확장 (HW 추가)	클라우드 자동 확장	자동 확장
규제 충족도	최고	높음	중간 (클라우드 리스크)
벤더 독립성	최고	높음	중간
적합 기업	대기업, 금융기관	중견기업	소규모, 스타트업
권장 AUC	$100M+	$10M-100M	< $10M
CCSS 인증 지원	Level 3 가능	Level 2	Level 1-2

8.1. 모델 전환 경로¶

SaaS(Model C) ──성장──▶ Hybrid(Model B) ──규제/보안──▶ Zero Cloud(Model A)

전환 절차:
[1] 대시보드 데이터 Export (표준 포맷)
[2] 온프레미스 인프라 구축 + 데이터 Import
[3] 병렬 운영 기간 (2주) — 양쪽에서 동시 검증
[4] DNS 전환 + SaaS 해제
[5] SaaS 데이터 영구 삭제 확인

9. Phase 5 시스템 아키텍처 연계 포인트¶

연계 항목	Phase 5 상세화 범위
대시보드 컨테이너 아키텍처	Docker Compose/K8s 매니페스트, 서비스 구성
배포 자동화	Ansible/Terraform 스크립트, IaC 정의
DB 스키마 설계	트랜잭션, 감사 로그, 정책 테이블 구조
블록체인 노드 인터페이스	RPC 엔드포인트, 구독 이벤트, Failover 로직
모니터링 메트릭 정의	Prometheus 메트릭, Grafana 대시보드 사양
보안 강화	SELinux/AppArmor 정책, 컨테이너 보안

본 문서는 Phase 4 Differentiation & Extended Architecture의 일부로, D'CENT 엔터프라이즈의 온프레미스/제로클라우드 배포 아키텍처를 설계한다. DIF-04 요구사항("대시보드 셀프호스팅 지원")을 3가지 배포 모델로 구체화하며, Phase 3의 3개 컴포넌트 구조를 배포 관점에서 확장한다.