v0.6
규제별 컴플라이언스 체크리스트 자동 생성 엔진 설계¶
1. 개요¶
1.1. 설계 목적¶
본 문서는 compliance-as-code-mapping.md에서 정의한 Compliance-as-Code 매핑 엔진을 기반으로, 규제별 컴플라이언스 체크리스트를 자동 생성하는 엔진을 설계한다. 4개 인증 프레임워크(MiCA/ISMS-P/CCSS/SOC 2)별 체크리스트 템플릿과 자동 증거 수집, 충족 판정 파이프라인을 정의하여 고객이 "Audit-Ready" 상태를 상시 유지할 수 있게 한다.
핵심 가치: - 감사 로그(AuditRecord)와 정책 상태(PolicyVersionRecord, RegulationTagBitmap)에서 체크리스트를 자동 생성 - 인증 프레임워크별 체크리스트 템플릿이 사전 정의되어, 관할 선택만으로 적용 가능 - 자동 증거 수집 + 충족 판정으로 감사 준비 시간을 대폭 단축 - 체크리스트 버전 관리로 규제 변경 시 영향도를 추적
범위: - In Scope: ComplianceChecklist 데이터 모델, 4개 프레임워크별 체크리스트 템플릿, 자동 증거 수집, 충족 판정 파이프라인, 보고서 출력 포맷 - Out of Scope: 인증 자체를 자동 판정하지 않음. "Audit-Ready 상태 유지"가 목표이며, 최종 인증 판정은 외부 감사인의 영역
1.2. 규제 근거¶
| 요건 | 근거 | 본 문서 대응 |
|---|---|---|
| COMP-01 | 규제별 컴플라이언스 체크리스트 자동 생성 | ComplianceChecklist + 4개 프레임워크 템플릿 |
| CORE-10 | 외부 감사 대응 보고서 | 감사인용 PDF + 규제 당국용 포맷 |
| CORE-03 | 감사 로그 장기 보존 | 체크리스트가 보존 상태를 자동 확인 |
1.3. Zone 배치 원칙¶
체크리스트 자동 생성 엔진은 Zone 1(대시보드)에서만 실행된다. Zone 2/3의 데이터는 AuditSyncPayload를 통해 수신된 것만 사용하며, 에어갭 원칙을 엄격히 준수한다.
1.4. 선행 산출물 연결점¶
| 산출물 | 연결 방식 |
|---|---|
compliance-as-code-mapping.md (Plan 01 Task 1) |
RegulationControlMapping 65개 통제 항목이 체크리스트 항목의 기반 |
audit-log-record-schema.md (Phase 30) |
AuditRecord EventType 19종이 자동 증거 수집 소스 |
se-audit-digest-schema.md (Phase 30) |
SEAuditDigest 128B가 하드웨어 증거 |
proof-of-cold-storage.md (Phase 30) |
PoCS 보고서가 콜드 비율 증거 |
regulatory-tag-bitmap.md (Phase 31) |
RegulationTagBitmap 비트별 규제 충족 상태 |
policy-version-chain.md (Phase 31) |
PolicyVersionRecord 해시 체인이 정책 이력 증거 |
jurisdiction-policy-profiles.md (Phase 31) |
JurisdictionProfile이 관할별 체크리스트 필터 |
2. ComplianceChecklist 데이터 모델¶
2.1. ComplianceChecklist 구조¶
ComplianceChecklist:
checklist_id: string # UUID v7 (체크리스트 고유 ID)
framework: FrameworkType # 대상 인증 프레임워크 (MiCA/ISMS-P/CCSS/SOC2)
jurisdiction_code: string # 관할 코드 (jurisdiction-kr/eu/jp)
template_version: string # 템플릿 버전 (예: "1.0.0")
generated_at: datetime # 생성 시점 (UTC)
valid_until: datetime # 유효 기간 (생성 + 평가 주기)
prev_checklist_hash: string # SHA-256(이전 체크리스트) - 이력 추적
jurisdiction_profile_ref: string # JurisdictionProfile UUID 참조
overall_score: ComplianceScore # 전체 충족률
items: ChecklistItem[] # 체크리스트 항목 배열
metadata: ChecklistMetadata # 부가 메타데이터
ComplianceScore:
total_items: int # 총 항목 수
auto_satisfied: int # Auto-Satisfied 항목 수
evidence_available: int # Evidence-Available 항목 수
manual_required: int # Manual-Required 항목 수
not_applicable: int # Not-Applicable 항목 수
compliance_rate: float # 충족률 (auto_satisfied / (total - not_applicable))
audit_ready_rate: float # 감사 준비율 ((auto + evidence) / (total - not_applicable))
ChecklistMetadata:
evaluator: string # 평가 실행 주체 (SYSTEM / 감사인 ID)
evaluation_period_start: datetime # 평가 대상 기간 시작
evaluation_period_end: datetime # 평가 대상 기간 종료
active_reg_tags: string # RegulationTagBitmap 스냅샷 (hex)
policy_version: int # 평가 시점 정책 버전
policy_hash: string # 평가 시점 policy_hash
2.2. ChecklistItem 구조¶
ChecklistItem:
item_id: string # 항목 고유 ID (예: "CL-ISMS-C01")
control_id: string # 매핑 엔진의 Control ID 참조
control_name: string # 통제 항목 명칭
requirement_text: string # 요건 원문 (한글)
category: ControlCategory # 통제 카테고리
evidence_sources: EvidenceRef[] # 수집된 증거 참조 목록
evaluation_result: EvaluationResult # 판정 결과
last_evaluated: datetime # 최종 평가 시점
auditor_notes: string? # 감사인 코멘트 (수동 입력)
remediation_plan: string? # 미충족 시 개선 계획
priority: Priority # 우선순위 (Critical/High/Medium/Low)
EvaluationResult:
status: EvaluationStatus # Auto-Satisfied / Evidence-Available / Manual-Required / Not-Applicable
confidence: float # 판정 신뢰도 (0.0~1.0)
evidence_count: int # 수집된 증거 건수
evaluation_details: string # 판정 상세 설명
evaluated_by: string # 판정 주체 (SYSTEM / 감사인 ID)
EvaluationStatus:
- AUTO_SATISFIED # 시스템 자동 충족 증명
- EVIDENCE_AVAILABLE # 증거 존재, 수동 확인 필요
- MANUAL_REQUIRED # 시스템 외 증빙 필요
- NOT_APPLICABLE # 해당 관할에서 비적용
- PENDING_EVALUATION # 평가 대기 중
- EXPIRED # 이전 평가 만료, 재평가 필요
2.3. EvidenceRecord 구조¶
EvidenceRecord:
evidence_id: string # UUID v7
source_type: EvidenceSourceType # AuditRecord / PolicyState / SEDigest / PoCS / Manual
source_ref: string # 구체적 참조 (AuditRecord ID, PolicyVersion 번호 등)
collected_at: datetime # 수집 시점
data_hash: string # SHA-256(증거 데이터)
data_summary: string # 증거 요약 (사람이 읽을 수 있는 형태)
freshness: FreshnessStatus # 신선도 상태
EvidenceSourceType:
- AUDIT_RECORD # Phase 30 AuditRecord
- POLICY_STATE # Phase 31 PolicyVersionRecord
- SE_DIGEST # Phase 30 SEAuditDigest
- PROOF_OF_COLD_STORAGE # Phase 30 PoCS 보고서
- REGULATION_TAG # Phase 31 RegulationTagBitmap
- SYSTEM_CONFIG # 대시보드 시스템 설정
- MANUAL_UPLOAD # 수동 업로드 문서
FreshnessStatus:
- FRESH # freshness_requirement 이내
- STALE # freshness_requirement 초과, 재수집 필요
- EXPIRED # 유효 기간 만료
3. 4개 프레임워크별 체크리스트 템플릿 상세¶
3.1. MiCA 체크리스트 템플릿¶
적용 대상: EU 관할에서 CASP 인가를 유지하거나 취득하려는 고객 관련 규제 조항: REG-EU-01~10 + CORE-01~10 활성 조건: JurisdictionProfile.active_reg_tags의 EU Delta 비트(16~21) 활성
| # | 항목 ID | 체크리스트 항목 | Control ID | 증거 소스 | 판정 방식 |
|---|---|---|---|---|---|
| 1 | MCL-01 | 고객 자산과 CASP 자산이 물리적으로 분리 보관되는가? | MiCA-C01 | RegulationTagBitmap 비트 0 | Auto: SE별 키 격리 |
| 2 | MCL-02 | 모든 거래 포지션 기록이 실시간으로 유지되는가? | MiCA-C02 | AuditRecord(TX_CREATE, TX_SIGN) | Auto: 이벤트 쌍 존재 |
| 3 | MCL-03 | 거래 기록이 최소 5년간 보존되도록 설정되었는가? | MiCA-C03 | 아카이빙 설정(retention >= 1825일) | Auto: 설정 확인 |
| 4 | MCL-04 | NCA 접근 가능 형식(ESMA JSON)으로 기록 출력이 가능한가? | MiCA-C04 | ESMA JSON 변환 모듈 | Evidence: 기능 존재 확인 필요 |
| 5 | MCL-05 | ICT 거버넌스 체계와 이사회 보고 절차가 수립되었는가? | MiCA-C05 | PolicyVersionRecord 쿼럼 이력 | Auto: 해시 체인 무결성 |
| 6 | MCL-06 | ICT 리스크 관리 프레임워크가 문서화되어 있는가? | MiCA-C06 | SYSTEM_CONFIG + 정책 문서 | Evidence: 문서 존재 확인 |
| 7 | MCL-07 | 핵심 기능 위탁 시 NCA 통지가 완료되었는가? | MiCA-C07 | 통지 기록(수동) | Manual: NCA 통지서 제출 |
| 8 | MCL-08 | CASP 인가가 유효한가? | MiCA-C08 | 인가서(수동) | Manual: 인가서 사본 |
| 9 | MCL-09 | 키 백업 및 복구 절차가 수립되고 정기 테스트되는가? | MiCA-C09 | AuditRecord(KEY_BACKUP, KEY_RECOVERY) | Auto: 최근 12개월 기록 |
| 10 | MCL-10 | ICT 제3자 리스크 등록부가 관리되는가? | MiCA-C10 | 등록부 문서(수동) | Manual: DORA 등록부 |
| 11 | MCL-11 | 개인정보 보호 설계(Privacy by Design)가 적용되었는가? | MiCA-C11 | SYSTEM_CONFIG + 정책 문서 | Evidence: 가명처리 설정 |
| 12 | MCL-12 | EU 역외 데이터 이전이 통제되는가? | MiCA-C12 | SYSTEM_CONFIG(리전 설정) | Auto: EU 리전 배포 확인 |
| 13 | MCL-13 | 감사 로그가 변조 불가하게 유지되는가? | MiCA-C13 | SEAuditDigest + 해시 체인 | Auto: 3계층 무결성 |
| 14 | MCL-14 | 정책 변경 이력이 해시 체인으로 추적되는가? | MiCA-C14 | PolicyVersionRecord 체인 | Auto: 체인 무결성 |
| 15 | MCL-15 | GDPR 삭제권 요청 처리 절차가 수립되었는가? | MiCA-C15 | 보존 vs 삭제 엔진 설정 | Evidence: 처리 절차 확인 |
MiCA 체크리스트 합계: 15개 항목
3.2. ISMS-P 체크리스트 템플릿¶
적용 대상: 한국 VASP 의무 인증 대상 고객 (Phase 1 핵심) 관련 규제 조항: REG-KR-01~15 + CORE-01~10 활성 조건: JurisdictionProfile.jurisdiction_code = jurisdiction-kr
| # | 항목 ID | 체크리스트 항목 | Control ID | 증거 소스 | 판정 방식 |
|---|---|---|---|---|---|
| 1 | ICL-01 | 사용자 계정의 생성/변경/삭제가 체계적으로 관리되는가? | ISMS-C01 | AuditRecord(ROLE_ASSIGN, ROLE_REVOKE) | Auto: 이벤트 기록 존재 |
| 2 | ICL-02 | 최소 권한 원칙에 따라 접근 권한이 부여되는가? | ISMS-C02 | RBAC 정책 + AuditRecord(ROLE_ASSIGN) | Auto: RBAC 구성 확인 |
| 3 | ICL-03 | 다중 인증(MFA)이 적용되는가? | ISMS-C03 | AuditRecord(AUTH_SUCCESS).payload.auth_method | Auto: MFA 기록 확인 |
| 4 | ICL-04 | 반기 1회 이상 접근 권한 검토가 수행되는가? | ISMS-C04 | 권한 검토 기록 패턴 | Evidence: 검토 기록 확인 |
| 5 | ICL-05 | 네트워크 접근 통제가 적용되는가? | ISMS-C05 | 에어갭 아키텍처 설정 | Auto: 물리적 네트워크 분리 |
| 6 | ICL-06 | 네트워크 세그먼테이션이 적용되는가? | ISMS-C06 | 3-Zone 구조 설정 | Auto: Zone 분리 확인 |
| 7 | ICL-07 | 저장 데이터에 AES-256 이상 암호화가 적용되는가? | ISMS-C07 | SYSTEM_CONFIG(AES-256 at-rest) | Auto: 암호화 설정 |
| 8 | ICL-08 | 전송 데이터에 TLS 1.3 이상 암호화가 적용되는가? | ISMS-C08 | SYSTEM_CONFIG(TLS 1.3) | Auto: 전송 암호화 |
| 9 | ICL-09 | SE 내부 데이터가 하드웨어 수준으로 암호화되는가? | ISMS-C09 | SEAuditDigest 무결성 | Auto: SE 하드웨어 암호화 |
| 10 | ICL-10 | 보안 관련 이벤트의 감사 로그가 기록되는가? | ISMS-C10 | AuditRecord 19개 EventType | Auto: 일간 기록 존재 |
| 11 | ICL-11 | 감사 로그의 변조가 방지되는가? | ISMS-C11 | SEAuditDigest + 해시 체인 | Auto: 3계층 무결성 |
| 12 | ICL-12 | 접근 기록이 최소 6개월 이상 보관되는가? | ISMS-C12 | AUTH 이벤트 보존 상태 | Auto: 보존 기간 확인 |
| 13 | ICL-13 | 전자금융거래 기록이 5년간 보존되는가? | ISMS-C13 | 아카이빙 설정(retention >= 1825일) | Auto: 설정 확인 |
| 14 | ICL-14 | RBAC 변경 이력이 추적되는가? | ISMS-C14 | AuditRecord(ROLE_* 이벤트) | Auto: 변경 이력 존재 |
| 15 | ICL-15 | 정보보호 최고책임자(CISO)가 지정되었는가? | ISMS-C15 | CISO 지정 문서(수동) | Manual: 지정서 업로드 |
| 16 | ICL-16 | 보안 관제 체계가 운영되는가? | ISMS-C16 | 알림 설정 + 관제 계약 | Evidence: 관제 문서 확인 |
| 17 | ICL-17 | 이용자 가상자산의 80% 이상이 콜드월렛에 보관되는가? | ISMS-C17 | PoCS 보고서(cold_ratio) | Auto: cold_ratio >= 80% |
| 18 | ICL-18 | 금감원 현장검사 대응 데이터 추출이 가능한가? | ISMS-C18 | 데이터 추출 도구 | Evidence: 도구 기능 확인 |
| 19 | ICL-19 | 클라우드 이용 시 CSAP CSP/국내 리전 요건을 충족하는가? | ISMS-C19 | CSP/리전 설정 | Auto: Model B/C 해당 시 |
| 20 | ICL-20 | 정책 변경 이력이 해시 체인으로 관리되는가? | ISMS-C20 | PolicyVersionRecord 체인 | Auto: 체인 무결성 |
ISMS-P 체크리스트 합계: 20개 항목 (한국 Phase 1 가장 상세)
3.3. CCSS Level 2+ 체크리스트 템플릿¶
적용 대상: 암호화폐 커스터디 보안 인증을 취득하려는 고객 관련 규제 조항: CORE-01~10 (업계 표준) 활성 조건: 모든 관할에서 기본 활성 (CCSS는 국가별 Delta 독립)
| # | 항목 ID | 체크리스트 항목 | Control ID | 증거 소스 | 판정 방식 |
|---|---|---|---|---|---|
| 1 | CCL-01 | 하드웨어 RNG를 통한 안전한 키 생성이 수행되는가? | CCSS-C01 | SE TRNG 설정 | Auto: 하드웨어 RNG |
| 2 | CCL-02 | 키 생성 이벤트가 감사 로그에 기록되는가? | CCSS-C02 | AuditRecord(KEY_GENERATE) | Auto: 이벤트 존재 |
| 3 | CCL-03 | 프라이빗 키가 콜드 스토리지에 보관되는가? | CCSS-C03 | PoCS + RegulationTagBitmap | Auto: 비트 0, 1 활성 |
| 4 | CCL-04 | 지리적으로 분산된 키 저장소가 운영되는가? (Level 3) | CCSS-C04 | 배포 구성 | Evidence: 멀티 사이트 |
| 5 | CCL-05 | 키 백업이 정기적으로 수행되는가? | CCSS-C05 | AuditRecord(KEY_BACKUP) | Auto: 최근 12개월 |
| 6 | CCL-06 | 백업 복구 테스트가 연 1회 이상 수행되는가? | CCSS-C06 | AuditRecord(KEY_RECOVERY) | Evidence: 테스트 기록 |
| 7 | CCL-07 | 다중 서명(MuSig2/Quorum)이 적용되는가? | CCSS-C07 | RegulationTagBitmap 비트 4 + TX_SIGN | Auto: 쿼럼 서명 기록 |
| 8 | CCL-08 | 키 손상 대응 절차가 수립되고 훈련되었는가? | CCSS-C08 | 절차서 + SECURITY_EVENT | Evidence: 절차서 + 훈련 |
| 9 | CCL-09 | RBAC + 쿼럼 기반 키 사용 승인이 적용되는가? | CCSS-C09 | AuditRecord(TX_APPROVE) | Auto: 쿼럼 승인 기록 |
| 10 | CCL-10 | 민감 데이터 삭제 절차가 문서화되었는가? | CCSS-C10 | 삭제 절차서(수동) | Manual: 절차서 업로드 |
| 11 | CCL-11 | Proof of Reserve가 분기별로 발행되는가? | CCSS-C11 | PoCS 보고서(SE 서명 포함) | Auto: 분기별 PoCS |
| 12 | CCL-12 | 감사 로그가 변조 불가하게 유지되는가? | CCSS-C12 | SEAuditDigest + 해시 체인 | Auto: 3계층 무결성 |
| 13 | CCL-13 | 감사 로그가 관할별 요건에 따라 장기 보존되는가? | CCSS-C13 | 아카이빙 설정 | Auto: 보존 기간 충족 |
| 14 | CCL-14 | 키 복구 절차가 문서화되었는가? | CCSS-C14 | 복구 절차서(수동) | Manual: 절차서 업로드 |
| 15 | CCL-15 | 키 복구 실행 이력이 기록되는가? | CCSS-C15 | AuditRecord(KEY_RECOVERY) | Auto: 복구 이력 존재 |
CCSS 체크리스트 합계: 15개 항목
3.4. SOC 2 Type II 체크리스트 템플릿¶
적용 대상: 서비스 조직 통제 인증을 취득하려는 고객 (주로 SaaS/Model C) 관련 규제 조항: CORE-01~10 + Trust Service Criteria 활성 조건: 모든 관할에서 기본 활성
| # | 항목 ID | 체크리스트 항목 | Control ID | 증거 소스 | 판정 방식 |
|---|---|---|---|---|---|
| 1 | SCL-01 | 논리적 접근 통제가 정의되고 적용되는가? | SOC2-C01 | RBAC 정책 + PolicyVersionRecord | Auto: 정책 정의 확인 |
| 2 | SCL-02 | MFA 인증 메커니즘이 적용되는가? | SOC2-C02 | AuditRecord(AUTH_SUCCESS) MFA | Auto: MFA 기록 확인 |
| 3 | SCL-03 | 접근 권한이 주기적으로 검토되는가? | SOC2-C03 | 권한 검토 패턴 | Evidence: 분기별 검토 |
| 4 | SCL-04 | 시스템 경계가 보호되는가 (방화벽/에어갭)? | SOC2-C04 | 에어갭 아키텍처 | Auto: 물리적 분리 |
| 5 | SCL-05 | 데이터 전송 시 암호화가 적용되는가? | SOC2-C05 | TLS 1.3 + QR/NFC | Auto: 암호화 전송 |
| 6 | SCL-06 | 악의적 소프트웨어에 대한 방어가 적용되는가? | SOC2-C06 | SE 펌웨어 서명 검증 | Auto: 서명 검증 |
| 7 | SCL-07 | 보안 이벤트가 모니터링되는가? | SOC2-C07 | AuditRecord(SECURITY_EVENT) | Auto: 모니터링 활성 |
| 8 | SCL-08 | 변경 관리 절차가 수립되었는가? | SOC2-C08 | PolicyVersionRecord 해시 체인 | Auto: 변경 이력 무결성 |
| 9 | SCL-09 | 변경이 적절히 승인되는가? | SOC2-C09 | quorum_proof 존재 | Auto: 쿼럼 승인 증명 |
| 10 | SCL-10 | 무단 변경이 탐지되는가? | SOC2-C10 | SEAuditDigest.policy_hash | Auto: SE 해시 앵커 |
| 11 | SCL-11 | 인시던트 대응 계획이 수립되었는가? | SOC2-C11 | 대응 계획서(수동) | Manual: 계획서 업로드 |
| 12 | SCL-12 | 시스템 가용성이 모니터링되는가? | SOC2-C12 | 헬스 체크 설정 | Evidence: 모니터링 설정 |
| 13 | SCL-13 | 백업 및 복구 절차가 수립되었는가? | SOC2-C13 | AuditRecord(KEY_BACKUP) | Auto: 백업 기록 존재 |
| 14 | SCL-14 | 복구 테스트가 정기적으로 수행되는가? | SOC2-C14 | KEY_RECOVERY 테스트 기록 | Evidence: 연 1회 테스트 |
| 15 | SCL-15 | 개인정보 수집/사용에 대한 통지가 이루어지는가? | SOC2-C15 | 개인정보 처리방침(수동) | Manual: 처리방침 업로드 |
SOC 2 체크리스트 합계: 15개 항목
4. 자동 증거 수집 메커니즘¶
4.1. AuditRecord 기반 증거 수집¶
AuditRecord EventType별로 어떤 체크리스트 항목의 증거가 되는지 매핑한다.
| EventType | 증거 대상 체크리스트 항목 | 수집 방법 | 판정 기여 |
|---|---|---|---|
| TX_CREATE (0x0101) | MCL-02, ICL-10 | 존재 여부 + 건수 집계 | 거래 포지션 기록 증명 |
| TX_APPROVE (0x0102) | CCL-09, SCL-09 | 쿼럼 승인 패턴 | 다중 승인 프로세스 증명 |
| TX_SIGN (0x0104) | MCL-02, CCL-07 | 서명 기록 + RegTags 추출 | 서명 정책 준수 증명 |
| TX_BROADCAST (0x0105) | ICL-13 | 거래 완결 기록 | 거래 기록 보존 증명 |
| POLICY_UPDATE (0x0201) | MCL-14, ICL-20, SCL-08 | 정책 변경 이력 | 변경 관리 증명 |
| ROLE_ASSIGN (0x0202) | ICL-01, ICL-02, ICL-14 | 역할 부여 기록 | 접근 통제 관리 증명 |
| ROLE_REVOKE (0x0203) | ICL-01, ICL-14 | 역할 회수 기록 | 접근 권한 관리 증명 |
| QUORUM_CHANGE (0x0204) | ICL-14, SCL-08 | 쿼럼 설정 변경 | 승인 정책 변경 추적 |
| KEY_GENERATE (0x0301) | CCL-02 | 키 생성 이벤트 | 키 생성 감사 증명 |
| KEY_BACKUP (0x0302) | MCL-09, CCL-05, SCL-13 | 백업 수행 기록 | 백업 절차 준수 증명 |
| KEY_RECOVERY (0x0303) | CCL-06, CCL-15, SCL-14 | 복구 수행 기록 | 복구 능력 증명 |
| AUTH_SUCCESS (0x0401) | ICL-03, SCL-02 | MFA 인증 기록 | 인증 메커니즘 증명 |
| AUTH_FAILURE (0x0402) | SCL-07 | 실패 로그인 | 보안 이벤트 모니터링 |
| SECURITY_EVENT (0x0406) | CCL-08, SCL-07 | 보안 이벤트 기록 | 인시던트 탐지 증명 |
4.2. PolicyVersionRecord 기반 증거 수집¶
| PolicyVersionRecord 필드 | 증거 대상 체크리스트 항목 | 판정 기여 |
|---|---|---|
| version_number | MCL-14, ICL-20, SCL-08 | 정책 버전 관리 증명 |
| policy_hash + prev_version_hash | MCL-14, ICL-20, SCL-08, SCL-10 | 해시 체인 무결성 증명 |
| quorum_proof | MCL-05, SCL-09 | 쿼럼 승인 프로세스 증명 |
| reg_tags_snapshot | MCL-01, CCL-03, CCL-07 | 규제 태그 활성 상태 증명 |
| jurisdiction_id | ICL-19 | 관할별 정책 적용 증명 |
4.3. SEAuditDigest 기반 증거 수집¶
| SEAuditDigest 필드 | 크기 | 증거 대상 | 판정 기여 |
|---|---|---|---|
| sign_counter (4B) | 4B | CCL-11 (PoCS) | 100% 콜드 서명 증명 |
| latest_log_hash (32B) | 32B | ICL-11, CCL-12, SCL-10 | 3계층 해시 체인 무결성 |
| latest_sign_hash (32B) | 32B | MCL-13 | 서명 체인 무결성 |
| policy_hash (32B) | 32B | MCL-14, ICL-20, SCL-10 | SE 정책 앵커 검증 |
| digest_sig (20B) | 20B | 모든 SE 증거 항목 | SE 하드웨어 서명 신뢰성 |
4.4. PoCS 기반 증거 수집¶
| PoCS 보고서 필드 | 증거 대상 | 판정 기여 |
|---|---|---|
| cold_ratio (%) | ICL-17 (ISMS-P 80%), CCL-03, CCL-11 | 콜드 보관 비율 충족 증명 |
| sign_counter | CCL-11, MCL-01 | 콜드 환경 서명 100% 증명 |
| se_signature | 모든 PoCS 항목 | SE 서명으로 보고서 진본 증명 |
| report_period | ICL-17, CCL-11 | 보고서 주기 충족 증명 |
5. 충족 판정 파이프라인¶
5.1. 파이프라인 아키텍처¶
[스케줄 트리거]
|
v
+-------------------+
| 1. 스케줄 판단 | 일간: 기본 체크 (EXISTENCE_CHECK, BITMAP_VERIFY)
| (주기 결정) | 주간: 중간 체크 (COUNT_THRESHOLD, TEMPORAL_CHECK)
+-------------------+ 분기: 전체 체크 (CHAIN_INTEGRITY, RATIO_CHECK, COMPOSITE)
|
v
+-------------------+
| 2. 증거 수집 | EvidenceSource별 수집기 병렬 실행
| (병렬 실행) | freshness_requirement 확인
+-------------------+ EvidenceRecord 생성
|
v
+-------------------+
| 3. 판정 실행 | EvaluationLogic 타입별 판정 함수 실행
| (항목별) | threshold 비교
+-------------------+ EvaluationResult 생성
|
v
+-------------------+
| 4. 결과 집계 | ComplianceScore 계산
| (프레임워크별) | 미충족 항목 목록 생성
+-------------------+ 이전 체크리스트 대비 변화 탐지
|
v
+-------------------+
| 5. 알림 및 출력 | 미충족 항목 알림 (대시보드 + 이메일)
| | ComplianceChecklist 저장
+-------------------+ 보고서 출력 (내부/감사인/규제 당국)
5.2. 평가 스케줄¶
| 스케줄 | 실행 주기 | 평가 범위 | 대상 판정 로직 |
|---|---|---|---|
| 일간 점검 | 매일 02:00 UTC | 기본 체크 항목 | EXISTENCE_CHECK, BITMAP_VERIFY |
| 주간 점검 | 매주 월요일 03:00 UTC | 중간 체크 항목 | COUNT_THRESHOLD, TEMPORAL_CHECK |
| 분기 정밀 평가 | 분기 첫째 주 | 전체 항목 (65개) | 모든 판정 로직 (CHAIN_INTEGRITY 포함) |
| 온디맨드 평가 | 감사인 요청 시 | 선택 항목 또는 전체 | 모든 판정 로직 |
| 이벤트 트리거 | 정책 변경/보안 이벤트 시 | 관련 항목 | CHAIN_INTEGRITY, COMPOSITE |
5.3. 미충족 항목 알림¶
미충족 항목(Evidence-Available, Manual-Required) 발견 시 아래 알림을 생성한다.
| 알림 수준 | 조건 | 알림 대상 | 알림 채널 |
|---|---|---|---|
| Critical | Auto-Satisfied -> Evidence-Available로 격하 (회귀) | CISO, Compliance Officer, Org Owner | 대시보드 배너 + 이메일 즉시 |
| High | Manual-Required 항목의 증빙 만료 (감사 30일 전) | Compliance Officer | 대시보드 알림 + 이메일 |
| Medium | Evidence-Available 항목의 증거 stale 상태 | Compliance Officer | 대시보드 알림 |
| Low | 정기 평가 완료 보고 (변화 없음) | Auditor | 대시보드 로그 |
6. 보고서 출력 포맷¶
6.1. 내부용: 대시보드 UI 체크리스트 뷰¶
대시보드에서 실시간으로 조회 가능한 체크리스트 UI를 제공한다.
UI 구성 요소: - 충족률 게이지: 프레임워크별 원형 게이지 (Auto-Satisfied / 전체 비율) - 감사 준비율 게이지: (Auto-Satisfied + Evidence-Available) / 전체 - 체크리스트 테이블: 항목별 상태 아이콘, 최종 평가일, 증거 건수 - 미충족 항목 하이라이트: 빨간색 배지, 개선 계획 링크 - 필터: 프레임워크별, 카테고리별, 판정 상태별 필터링 - 이력 차트: 시간에 따른 충족률 추이 그래프
실시간 충족률 게이지 표시 예시:
ISMS-P: [=========== ] 75% (15/20 Auto-Satisfied)
감사 준비: [=============== ] 90% (18/20 Auto + Evidence)
MiCA: [======== ] 53% (8/15 Auto-Satisfied)
감사 준비: [============ ] 80% (12/15 Auto + Evidence)
CCSS: [========== ] 67% (10/15 Auto-Satisfied)
감사 준비: [============= ] 87% (13/15 Auto + Evidence)
SOC 2: [========= ] 60% (9/15 Auto-Satisfied)
감사 준비: [============ ] 80% (12/15 Auto + Evidence)
6.2. 감사인용: PDF 보고서¶
외부 감사인에게 제출하는 공식 체크리스트 보고서이다.
PDF 구조: 1. 표지: 기업명, 프레임워크, 평가 기간, 보고서 ID, SE 서명 검증 결과 2. 경영진 요약: 전체 충족률, 주요 미충족 사항, 개선 권고 3. 체크리스트 상세: 항목별 요건/증거/판정/비고 4. 증거 첨부: EvidenceRecord 목록 (data_hash 포함) 5. SE 서명 검증: SEAuditDigest 검증 결과, 3계층 해시 체인 무결성 확인 6. 정책 이력: PolicyVersionRecord 체인 요약 7. 부록: 매핑 테이블 참조, 용어 정의
보안 특성: - 보고서 자체에 SHA-256 해시 포함 (변조 탐지) - SE 서명 검증 결과가 보고서에 임베딩되어 하드웨어 수준 신뢰성 증명 - 생성 시점의 policy_hash와 reg_tags_snapshot 포함
6.3. 규제 당국용: 관할별 포맷¶
| 관할 | 규제 당국 | 출력 포맷 | 비고 |
|---|---|---|---|
| 한국 | 금융감독원 | 금감원 보고 양식 (엑셀/PDF) | 현장검사 대응 데이터 추출 도구 포함 |
| EU | NCA (ESMA) | ESMA JSON Draft 포맷 | 2026-05 최종본 공표 후 갱신 예정 |
| 일본 | JFSA | JFSA 감독 가이드라인 양식 | 구조 설계만 (Phase 1 범위 외) |
한국 금감원 보고 포맷 상세: - 자산 보유 현황표: 콜드/핫 비율, 자산 종류별 수량 - 감사 로그 요약: 기간별 이벤트 건수, 보안 이벤트 현황 - ISMS-P 체크리스트 충족 현황: 20개 항목 상태 - Travel Rule 준수 현황: 전달/수신 건수, 미처리 건수 - 의심거래보고(STR) 현황: 탐지/보고 건수
7. 체크리스트 버전 관리¶
7.1. 버전 관리 구조¶
ChecklistTemplate:
template_id: string # 템플릿 고유 ID
framework: FrameworkType # 프레임워크
version: SemVer # 시맨틱 버전 (major.minor.patch)
effective_date: datetime # 발효일
changelog: ChangelogEntry[] # 변경 이력
prev_template_hash: string # SHA-256(이전 버전 템플릿)
ChangelogEntry:
version: string # 변경 버전
date: datetime # 변경일
change_type: ChangeType # 변경 유형
affected_items: string[] # 영향받는 항목 ID
description: string # 변경 설명
regulation_trigger: string # 변경 트리거 규제
ChangeType:
- ITEM_ADDED # 신규 항목 추가
- ITEM_MODIFIED # 기존 항목 수정
- ITEM_REMOVED # 항목 삭제
- THRESHOLD_CHANGED # 임계값 변경
- EVIDENCE_SOURCE_CHANGED # 증거 소스 변경
7.2. 규제 변경 시 체크리스트 갱신 흐름¶
1. 규제 변경 감지
- compliance-as-code-mapping.md의 매핑 갱신 프로세스와 연동
- 매핑 테이블 갱신 완료 알림 수신
2. 체크리스트 템플릿 갱신
- 영향받는 프레임워크의 템플릿 식별
- 신규/수정/삭제 항목 반영
- template_version 증가 (major: 항목 추가/삭제, minor: 항목 수정, patch: 임계값 변경)
3. Diff 생성
- 이전 버전과 현재 버전의 항목별 차이 계산
- 신규 항목 강조, 삭제 항목 경고, 수정 항목 상세
4. 알림 발송
- 신규 항목 추가: "N개 신규 통제 항목이 추가되었습니다. 평가를 수행하세요."
- 항목 삭제: "N개 통제 항목이 제거되었습니다. 이전 평가 결과가 아카이빙됩니다."
- 임계값 변경: "N개 항목의 판정 기준이 변경되었습니다. 재평가를 권장합니다."
5. 재평가 실행
- 변경된 항목에 대해 온디맨드 평가 트리거
- 이전 체크리스트와 비교하여 판정 상태 변화 탐지
8. 종합 통계 및 자동화 성과¶
8.1. 프레임워크별 체크리스트 요약¶
| 프레임워크 | 총 항목 | Auto-Satisfied | Evidence-Available | Manual-Required | 자동화율 | 감사 준비율 |
|---|---|---|---|---|---|---|
| MiCA | 15개 | 8개 | 4개 | 3개 | 53% | 80% |
| ISMS-P | 20개 | 15개 | 3개 | 2개 | 75% | 90% |
| CCSS | 15개 | 10개 | 3개 | 2개 | 67% | 87% |
| SOC 2 | 15개 | 9개 | 3개 | 3개 | 60% | 80% |
| 전체 | 65개 | 42개 | 13개 | 10개 | 65% | 85% |
8.2. 자동화 성과의 의의¶
- 전체 자동화율 65%: 65개 통제 항목 중 42개를 시스템이 완전 자동으로 충족 증명
- 전체 감사 준비율 85%: 55개 항목이 시스템 증거로 커버 (Auto + Evidence)
- 수동 필수 15%만: 10개 항목만 조직 프로세스 문서/물리적 보안 증빙 필요
- ISMS-P 최고 자동화율 75%: 한국 Phase 1 핵심 인증에서 가장 높은 자동화 달성
- 에어갭 아키텍처의 고유 기여: 네트워크 분리, 키 격리, SE 해시 앵커 등 에어갭 고유 기능이 다수 통제 항목을 구조적으로 Auto-Satisfied
8.3. 경쟁사 대비 차별화¶
D'CENT Enterprise의 에어갭 아키텍처는 다음 통제 항목을 구조적으로 자동 충족한다. 이는 핫월렛 기반 경쟁사(Fireblocks, BitGo)가 소프트웨어 수준에서만 충족할 수 있는 항목이다:
| 자동 충족 근거 | 관련 통제 항목 | 경쟁사 대비 우위 |
|---|---|---|
| SE 물리적 키 격리 | MiCA-C01, ISMS-C09, CCL-03 | 하드웨어 분리 vs 소프트웨어 분리 |
| 에어갭 네트워크 분리 | ISMS-C05, ISMS-C06, SOC2-C04 | 물리적 에어갭 vs 논리적 세그먼테이션 |
| SE 해시 앵커 3계층 무결성 | ISMS-C11, CCL-12, SOC2-C10 | 하드웨어 루트 오브 트러스트 |
| 100% 콜드 서명 (sign_counter) | ICL-17, CCL-11 | 100% 증명 vs 비율 모니터링 |
관련 문서¶
- AML/KYT 외부 연동 인터페이스 및 Travel Rule 대응 설계 -- 규제 준수
- Compliance-as-Code 규제 매핑 엔진 설계 -- 규제 준수