v0.6
Compliance-as-Code 규제 매핑 엔진 설계¶
1. 개요¶
1.1. 설계 목적¶
본 문서는 Phase 29에서 추출한 36개 규제 조항(REG-XX-YY)과 Core 10 + Delta 18 분류를 기반으로, 규제 조항에서 통제 항목(Control)으로의 자동 매핑 규칙과 데이터 흐름을 설계한다. Compliance-as-Code 매핑 엔진은 규제 변경 시 통제 항목을 자동으로 갱신하고, 각 통제 항목의 충족 여부를 시스템 데이터에서 자동 판정하여 "Audit-Ready" 상태를 유지하는 것을 목표로 한다.
핵심 가치: - 규제 조항(REG-XX-YY) -> 통제 항목(Control ID) -> 증거 소스(Evidence Source) -> 판정 로직(Evaluation Logic)의 4단 자동 매핑 - 4개 인증 프레임워크(MiCA/ISMS-P/CCSS/SOC 2)별 통제 항목 매핑 테이블 제공 - Phase 30 감사 로그(AuditRecord)와 Phase 31 정책 엔진(RegulationTagBitmap, PolicyVersionRecord)의 구체적 데이터를 증거 소스로 활용 - 관할별 JurisdictionProfile의 active_reg_tags를 기준으로 해당 관할에 적용되는 통제 항목만 활성화
범위: - In Scope: 매핑 엔진 설계, 4개 프레임워크별 매핑 테이블, 자동 판정 로직, 데이터 흐름, 관할별 필터링 - Out of Scope: 인증 자체를 자동 판정하지 않음 (인증은 외부 감사인의 영역). 본 엔진은 "Audit-Ready 상태 유지"만 목표
1.2. 규제 근거¶
| 요건 | 근거 | 본 문서 대응 |
|---|---|---|
| COMP-02 | Compliance-as-Code 규제 매핑 엔진 설계 | RegulationControlMapping 4단 구조 |
| CORE-10 | 외부 감사 대응 보고서 | 매핑 엔진이 감사 보고서의 통제 항목 기반 |
| CORE-06 | IT 리스크 관리 체계 | 4개 프레임워크 통제 항목으로 구체화 |
1.3. Zone 배치 원칙¶
매핑 엔진은 Zone 1(대시보드)에서만 실행된다. 연산 복잡 로직(매핑 평가, 증거 집계, 보고서 생성)은 온라인 대시보드에서 처리하며, Zone 2/3의 데이터는 AuditSyncPayload를 통해 수신된 것만 사용한다. 에어갭 원칙을 엄격히 준수한다.
| 구성 요소 | Zone | 역할 |
|---|---|---|
| 매핑 엔진 코어 | Zone 1 | RegulationControlMapping 평가 실행 |
| 증거 수집기 | Zone 1 | AuditRecord DB + PolicyVersionRecord 체인 질의 |
| 매핑 테이블 저장소 | Zone 1 | 4개 프레임워크 매핑 정의 관리 |
| 규제 태그 수신기 | Zone 1 | AuditSyncPayload에서 RegulationTagBitmap 스냅샷 수신 |
1.4. 선행 산출물 연결점¶
| 산출물 | 연결 방식 |
|---|---|
regulatory-clause-extraction.md (Phase 29) |
36개 REG-XX-YY 조항이 매핑 엔진의 소스 규제 |
core-delta-classification.md (Phase 29) |
Core 10 + Delta 18 분류가 매핑 범위 결정 |
audit-log-record-schema.md (Phase 30) |
AuditRecord EventType이 증거 소스 |
se-audit-digest-schema.md (Phase 30) |
SEAuditDigest 필드가 하드웨어 증거 |
regulatory-tag-bitmap.md (Phase 31) |
RegulationTagBitmap 비트별 충족 상태가 판정 입력 |
jurisdiction-policy-profiles.md (Phase 31) |
JurisdictionProfile.active_reg_tags가 관할별 필터 |
policy-version-chain.md (Phase 31) |
PolicyVersionRecord가 정책 이력 증거 |
2. RegulationControlMapping 데이터 모델¶
2.1. 4단 매핑 구조¶
규제 조항 (Regulation)
└─> 통제 항목 (Control)
└─> 증거 소스 (Evidence Source)
└─> 판정 로직 (Evaluation Logic)
매핑 엔진의 핵심은 이 4단 구조를 코드화하여 자동 평가를 실행하는 것이다.
2.2. RegulationControlMapping 구조 정의¶
RegulationControlMapping:
mapping_id: string # 매핑 고유 ID (예: "RCM-ISMS-P-001")
regulation_ref: string # 규제 조항 ID (REG-XX-YY 또는 CORE-XX)
framework: FrameworkType # 대상 인증 프레임워크
control_id: string # 통제 항목 ID (프레임워크별 체계)
control_name: string # 통제 항목 명칭
control_description: string # 통제 항목 설명
evidence_sources: EvidenceSource[] # 증거 소스 목록
evaluation_logic: EvaluationLogic # 판정 로직
weight: float # 충족 가중치 (0.0~1.0)
category: ControlCategory # 통제 카테고리
FrameworkType:
- MiCA # EU Markets in Crypto-Assets
- ISMS-P # 한국 정보보호관리체계
- CCSS # CryptoCurrency Security Standard
- SOC2 # Service Organization Control 2
ControlCategory:
- ACCESS_CONTROL # 접근 통제
- AUDIT_LOGGING # 감사 로깅
- KEY_MANAGEMENT # 키 관리
- DATA_PROTECTION # 데이터 보호
- INCIDENT_RESPONSE # 인시던트 대응
- GOVERNANCE # 거버넌스
- ASSET_SEGREGATION # 자산 분리
- CHANGE_MANAGEMENT # 변경 관리
- BACKUP_RECOVERY # 백업/복구
- COMPLIANCE_REPORTING # 컴플라이언스 보고
2.3. EvidenceSource 구조¶
EvidenceSource:
source_id: string # 증거 소스 ID (예: "ES-AUDIT-TX_SIGN")
source_type: EvidenceSourceType
source_ref: string # 구체적 참조 (EventType, 비트맵 비트, 필드명)
collection_method: CollectionMethod
freshness_requirement: Duration # 증거 신선도 요건 (예: 24h, 7d, 30d)
EvidenceSourceType:
- AUDIT_RECORD # Phase 30 AuditRecord EventType
- REGULATION_TAG # Phase 31 RegulationTagBitmap 비트
- POLICY_VERSION # Phase 31 PolicyVersionRecord 필드
- SE_AUDIT_DIGEST # Phase 30 SEAuditDigest 필드
- PROOF_OF_COLD_STORAGE # Phase 30 PoCS 보고서
- SYSTEM_CONFIG # 대시보드 시스템 설정
- MANUAL_ATTESTATION # 수동 증명 (프로세스 문서 등)
CollectionMethod:
- AUTO_QUERY # DB 자동 질의
- SYNC_RECEIVE # AuditSyncPayload 수신 시 자동 수집
- PERIODIC_CHECK # 주기적 점검 (스케줄)
- MANUAL_UPLOAD # 수동 업로드 (감사인 첨부)
2.4. EvaluationLogic 구조¶
EvaluationLogic:
logic_id: string # 판정 로직 ID
logic_type: EvaluationLogicType
rule_expression: string # 판정 규칙 표현식
threshold: object # 임계값 (type별 상이)
result_mapping: ResultMapping # 결과 매핑
EvaluationLogicType:
- EXISTENCE_CHECK # 증거 존재 여부 확인
- COUNT_THRESHOLD # 건수 임계값 비교
- RATIO_CHECK # 비율 확인
- BITMAP_VERIFY # 비트맵 비트 확인
- CHAIN_INTEGRITY # 해시 체인 무결성 검증
- TEMPORAL_CHECK # 시간 기반 확인 (보존 기간 등)
- COMPOSITE # 복합 조건 (AND/OR 조합)
ResultMapping:
auto_satisfied: string # Auto-Satisfied 판정 조건
evidence_available: string # Evidence-Available 판정 조건
manual_required: string # Manual-Required 판정 조건
not_applicable: string # Not-Applicable 판정 조건
3. 판정 상태 정의¶
3.1. 4단계 판정 상태¶
| 판정 상태 | 의미 | 데이터 소스 | 감사 대응 |
|---|---|---|---|
| Auto-Satisfied | 시스템이 자동으로 충족 증명 완료 | AuditRecord, RegulationTagBitmap, SEAuditDigest, PoCS | 감사인에게 증거 자동 제시, 추가 확인 불필요 |
| Evidence-Available | 증거가 시스템에 존재하나 수동 확인 필요 | AuditRecord 패턴 존재, 정량 기준 미달 또는 해석 필요 | 감사인에게 증거 제시 + 수동 검증 요청 |
| Manual-Required | 시스템 외 프로세스로만 충족 가능 | 조직 정책 문서, 교육 기록, 물리적 보안 등 | 감사인에게 수동 증빙 제출 필요 안내 |
| Not-Applicable | 해당 관할/배포 모델에서 적용 대상 아님 | JurisdictionProfile.active_reg_tags에서 비활성 | 감사 범위에서 제외, 사유 명시 |
3.2. 판정 상태별 판정 규칙¶
Auto-Satisfied 판정 조건:
- EXISTENCE_CHECK: 해당 EventType의 AuditRecord가 평가 기간 내에 1건 이상 존재
- BITMAP_VERIFY: RegulationTagBitmap의 해당 비트가 1(활성)이고, 최근 서명 증적에 포함
- CHAIN_INTEGRITY: SEAuditDigest의 latest_log_hash와 Zone 2/1 해시 체인 검증 통과
- RATIO_CHECK: PoCS 보고서의 콜드 비율이 관할별 기준(80%/90%/95%) 이상
Evidence-Available 판정 조건: - AuditRecord 패턴이 존재하나 연속성/완전성이 부분적 - PolicyVersionRecord가 존재하나 최신 규제 변경이 미반영 - 시스템 설정값이 존재하나 운영 실효성 증명이 필요
Manual-Required 판정 조건: - 조직 거버넌스 문서(이사회 결의, 보안 정책 등) - 물리적 보안 관제(데이터센터, 장비 보관 등) - 인력 교육/훈련 기록 - 외부 감사 보고서 또는 인증서
4. 인증 프레임워크별 통제 항목 매핑 테이블¶
4.1. MiCA (Title V CASP 요건) 매핑 테이블¶
MiCA Title V에서 CASP(Crypto-Asset Service Provider)에 요구하는 통제 항목을 D'CENT Enterprise의 시스템 데이터에 매핑한다.
| Control ID | 통제 항목 | 관련 MiCA 조항 | 규제 조항 ID | Evidence Source | Evaluation Logic | 판정 가능 상태 |
|---|---|---|---|---|---|---|
| MiCA-C01 | 자산 분리 보관 | Art. 68(1) | REG-EU-02, CORE-01 | RegulationTagBitmap 비트 0 (CORE-01) | BITMAP_VERIFY: 비트 0 = 1 | Auto-Satisfied |
| MiCA-C02 | 포지션 기록 유지 | Art. 68(4) | REG-EU-02 | AuditRecord(TX_CREATE, TX_SIGN) 존재 | EXISTENCE_CHECK: TX_CREATE + TX_SIGN 쌍 존재 | Auto-Satisfied |
| MiCA-C03 | 거래 기록 5년 보존 | Art. 69(1) | REG-EU-03, CORE-03 | AuditRecord 아카이빙 상태 + 보존 기간 설정 | TEMPORAL_CHECK: retention >= 1825일 | Auto-Satisfied |
| MiCA-C04 | NCA 접근 가능 형식 | Art. 69(2) | REG-EU-03, DELTA-EU-04 | ESMA JSON 변환 기능 존재 여부 | EXISTENCE_CHECK: ESMA JSON 출력 모듈 활성 | Evidence-Available |
| MiCA-C05 | 거버넌스 체계 | Art. 67 | REG-EU-01, CORE-06 | PolicyVersionRecord(쿼럼 승인 이력) | CHAIN_INTEGRITY: 정책 해시 체인 무결성 | Auto-Satisfied |
| MiCA-C06 | ICT 리스크 관리 프레임워크 | Art. 67 + DORA | REG-EU-05, CORE-06 | SYSTEM_CONFIG(리스크 관리 설정) | COMPOSITE: 정책 존재 AND 정기 검토 기록 | Evidence-Available |
| MiCA-C07 | 핵심 기능 위탁 NCA 통지 | Art. 70 | REG-EU-04 | MANUAL_ATTESTATION(NCA 통지 기록) | EXISTENCE_CHECK: 통지 문서 업로드 | Manual-Required |
| MiCA-C08 | CASP 인가 유지 | Art. 59-62 | DELTA-EU-01 | MANUAL_ATTESTATION(인가서) | EXISTENCE_CHECK: 인가서 사본 업로드 | Manual-Required |
| MiCA-C09 | 백업 및 복구 절차 | Art. 67 + DORA Art. 12 | REG-EU-06, CORE-08 | AuditRecord(KEY_BACKUP, KEY_RECOVERY) | EXISTENCE_CHECK: 최근 12개월 내 백업 기록 | Auto-Satisfied |
| MiCA-C10 | ICT 제3자 리스크 등록부 | DORA Art. 28-30 | REG-EU-07, DELTA-EU-02 | MANUAL_ATTESTATION(등록부 문서) | EXISTENCE_CHECK: 등록부 업로드 | Manual-Required |
| MiCA-C11 | GDPR 데이터 보호 | GDPR Art. 25 | REG-EU-09, DELTA-EU-03 | SYSTEM_CONFIG(가명처리 설정) + 정책 문서 | COMPOSITE: 설정 활성 AND 정책 문서 존재 | Evidence-Available |
| MiCA-C12 | 국외 데이터 이전 통제 | GDPR Art. 44-49 | REG-EU-10, DELTA-EU-05 | SYSTEM_CONFIG(리전 설정) | EXISTENCE_CHECK: EU 리전 배포 확인 | Auto-Satisfied |
| MiCA-C13 | 변조 불가 감사 로그 | CCSS Aspect 10 | CORE-04 | SEAuditDigest.latest_log_hash 검증 | CHAIN_INTEGRITY: 3계층 해시 체인 | Auto-Satisfied |
| MiCA-C14 | 정책 변경 이력 관리 | SOC 2 CC7.2 | CORE-09 | PolicyVersionRecord 해시 체인 | CHAIN_INTEGRITY: policy_hash 체인 | Auto-Satisfied |
| MiCA-C15 | 삭제권 관리 | GDPR Art. 17 | REG-EU-08, DELTA-EU-03 | SYSTEM_CONFIG(보존 vs 삭제 엔진) | COMPOSITE: 법률 근거 관리 + 보존 기간 후 처리 | Evidence-Available |
MiCA 통제 항목 합계: 15개 - Auto-Satisfied: 8개 (53%) - Evidence-Available: 4개 (27%) - Manual-Required: 3개 (20%)
4.2. ISMS-P (2.5~2.9 보호대책) 매핑 테이블¶
ISMS-P는 한국 Phase 1 핵심 인증으로, 가장 상세하게 매핑한다.
| Control ID | 통제 항목 | ISMS-P 항목 | 규제 조항 ID | Evidence Source | Evaluation Logic | 판정 가능 상태 |
|---|---|---|---|---|---|---|
| ISMS-C01 | 사용자 계정 관리 | 2.5.1 | REG-KR-11, CORE-05 | AuditRecord(ROLE_ASSIGN, ROLE_REVOKE) | EXISTENCE_CHECK: 계정 생성/변경/삭제 기록 | Auto-Satisfied |
| ISMS-C02 | 접근 권한 관리 | 2.5.2 | REG-KR-11, CORE-05 | AuditRecord(ROLE_ASSIGN) + RBAC 설정 | COMPOSITE: RBAC 정책 설정 AND 최소 권한 검증 | Auto-Satisfied |
| ISMS-C03 | 다중 인증(MFA) | 2.5.3 | REG-KR-11, CORE-05 | AuditRecord(AUTH_SUCCESS).payload.auth_method | EXISTENCE_CHECK: MFA 인증 기록 존재 | Auto-Satisfied |
| ISMS-C04 | 반기 접근 권한 검토 | 2.5.4 | REG-KR-11 | AuditRecord(ROLE_ASSIGN/REVOKE) 패턴 | TEMPORAL_CHECK: 6개월 내 권한 검토 기록 | Evidence-Available |
| ISMS-C05 | 네트워크 접근 통제 | 2.6.1 | REG-KR-12 | SYSTEM_CONFIG(에어갭 아키텍처 설정) | BITMAP_VERIFY: 에어갭 아키텍처 = 물리적 네트워크 분리 | Auto-Satisfied |
| ISMS-C06 | 네트워크 세그먼테이션 | 2.6.2 | REG-KR-12 | SYSTEM_CONFIG(3-Zone 구조) | EXISTENCE_CHECK: Zone 분리 설정 확인 | Auto-Satisfied |
| ISMS-C07 | 암호화 적용 (저장 시) | 2.6.7 | REG-KR-13 | SYSTEM_CONFIG(AES-256 at-rest 설정) | EXISTENCE_CHECK: 암호화 설정 활성 | Auto-Satisfied |
| ISMS-C08 | 암호화 적용 (전송 시) | 2.6.7 | REG-KR-13 | SYSTEM_CONFIG(TLS 1.3 설정) | EXISTENCE_CHECK: TLS 설정 확인 | Auto-Satisfied |
| ISMS-C09 | SE 내부 암호화 | 2.6.7 | REG-KR-13 | SEAuditDigest(SE 무결성 확인) | BITMAP_VERIFY: SE 하드웨어 암호화 | Auto-Satisfied |
| ISMS-C10 | 감사 로그 기록 | 2.9.1 | REG-KR-14, CORE-04 | AuditRecord 존재 + 19개 EventType 커버리지 | COUNT_THRESHOLD: 일간 AuditRecord >= 1 | Auto-Satisfied |
| ISMS-C11 | 감사 로그 변조 방지 | 2.9.1 | REG-KR-14, CORE-04 | SEAuditDigest.latest_log_hash 검증 | CHAIN_INTEGRITY: 3계층 해시 체인 무결성 | Auto-Satisfied |
| ISMS-C12 | 접근 기록 6개월 보관 | 2.9.3 | REG-KR-15 | AuditRecord(AUTH_*) 보존 상태 | TEMPORAL_CHECK: AUTH 이벤트 6개월 이상 보존 | Auto-Satisfied |
| ISMS-C13 | 거래 기록 5년 보관 | 전자금융감독규정 13조 | REG-KR-08, CORE-03 | AuditRecord 아카이빙 설정 | TEMPORAL_CHECK: retention >= 1825일 | Auto-Satisfied |
| ISMS-C14 | RBAC 변경 이력 추적 | 전자금융감독규정 14조 | REG-KR-09 | AuditRecord(ROLE_ASSIGN, ROLE_REVOKE, QUORUM_CHANGE) | EXISTENCE_CHECK: 역할 변경 이력 | Auto-Satisfied |
| ISMS-C15 | 정보보호 최고책임자(CISO) 지정 | 특금법 시행령 | REG-KR-06 | MANUAL_ATTESTATION(CISO 지정 문서) | EXISTENCE_CHECK: CISO 지정서 업로드 | Manual-Required |
| ISMS-C16 | 보안 관제 체계 | 특금법 시행령 | REG-KR-06 | SYSTEM_CONFIG(대시보드 알림 설정) + 관제 계약 | COMPOSITE: 알림 설정 AND 관제 문서 | Evidence-Available |
| ISMS-C17 | 콜드 보관 비율 80% | 가상자산이용자보호법 시행령 | REG-KR-02, CORE-02 | PoCS 보고서(cold_ratio) | RATIO_CHECK: cold_ratio >= 80% | Auto-Satisfied |
| ISMS-C18 | 금감원 현장검사 데이터 추출 | 금감원 감독 체계 | DELTA-KR-05 | SYSTEM_CONFIG(데이터 추출 도구) | EXISTENCE_CHECK: 추출 도구 활성 | Evidence-Available |
| ISMS-C19 | 클라우드 규제 (Model B/C) | 전자금융감독규정 14조의2 | REG-KR-10, DELTA-KR-03 | SYSTEM_CONFIG(CSP 설정, 리전 확인) | COMPOSITE: CSAP CSP AND 국내 리전 | Auto-Satisfied (Model A는 N/A) |
| ISMS-C20 | 정책 변경 이력 | SOC 2 CC7.2 | CORE-09 | PolicyVersionRecord 해시 체인 | CHAIN_INTEGRITY: policy_hash 체인 무결성 | Auto-Satisfied |
ISMS-P 통제 항목 합계: 20개 - Auto-Satisfied: 15개 (75%) - Evidence-Available: 3개 (15%) - Manual-Required: 2개 (10%)
4.3. CCSS Level 2+ (10 Aspect) 매핑 테이블¶
| Control ID | Aspect | 통제 항목 | 규제 조항 ID | Evidence Source | Evaluation Logic | 판정 가능 상태 |
|---|---|---|---|---|---|---|
| CCSS-C01 | 1. Key Generation | 안전한 키 생성 (하드웨어 RNG) | CORE-01 | SYSTEM_CONFIG(SE TRNG 설정) | EXISTENCE_CHECK: SE 하드웨어 RNG | Auto-Satisfied |
| CCSS-C02 | 1. Key Generation | 키 생성 감사 기록 | CORE-01 | AuditRecord(KEY_GENERATE) | EXISTENCE_CHECK: KEY_GENERATE 이벤트 | Auto-Satisfied |
| CCSS-C03 | 2. Key Storage | 콜드 스토리지 보관 | CORE-01, CORE-02 | PoCS + RegulationTagBitmap 비트 0-1 | BITMAP_VERIFY: 비트 0, 1 활성 | Auto-Satisfied |
| CCSS-C04 | 2. Key Storage | 지리적 분산 (Level 3) | CORE-01 | SYSTEM_CONFIG(배포 구성) | EXISTENCE_CHECK: 멀티 사이트 설정 | Evidence-Available |
| CCSS-C05 | 3. Key Backup | 키 백업 존재 | CORE-08 | AuditRecord(KEY_BACKUP) | EXISTENCE_CHECK: 최근 12개월 내 백업 | Auto-Satisfied |
| CCSS-C06 | 3. Key Backup | 백업 복구 테스트 | CORE-08 | AuditRecord(KEY_RECOVERY) | TEMPORAL_CHECK: 연 1회 이상 복구 테스트 | Evidence-Available |
| CCSS-C07 | 4. Key Usage | 다중 서명 사용 | CORE-05 | RegulationTagBitmap 비트 4 + AuditRecord(TX_SIGN) | COMPOSITE: 쿼럼 정책 AND 다중 서명 기록 | Auto-Satisfied |
| CCSS-C08 | 5. Key Compromise Protocol | 키 손상 대응 절차 | CORE-06 | MANUAL_ATTESTATION(대응 절차서) + AuditRecord(SECURITY_EVENT) | COMPOSITE: 절차서 AND 훈련 기록 | Evidence-Available |
| CCSS-C09 | 6. Key Authorization | RBAC + 쿼럼 승인 | CORE-05 | AuditRecord(TX_APPROVE) + PolicyVersionRecord | EXISTENCE_CHECK: 쿼럼 승인 기록 | Auto-Satisfied |
| CCSS-C10 | 7. Data Sanitization | 민감 데이터 삭제 절차 | CORE-03 | MANUAL_ATTESTATION(삭제 절차서) | EXISTENCE_CHECK: 절차서 업로드 | Manual-Required |
| CCSS-C11 | 8. Proof of Reserve | 자산 보유 증명 | CORE-02, CORE-10 | PoCS 보고서(SE 서명 포함) | EXISTENCE_CHECK: 분기별 PoCS 발행 | Auto-Satisfied |
| CCSS-C12 | 9. Audit Logging | 변조 불가 감사 로그 | CORE-04 | SEAuditDigest + AuditRecord 해시 체인 | CHAIN_INTEGRITY: 3계층 무결성 | Auto-Satisfied |
| CCSS-C13 | 9. Audit Logging | 감사 로그 장기 보존 | CORE-03 | AuditRecord 아카이빙 설정 | TEMPORAL_CHECK: 관할별 보존 기간 충족 | Auto-Satisfied |
| CCSS-C14 | 10. Key Recovery | 키 복구 절차 문서화 | CORE-08 | MANUAL_ATTESTATION(복구 절차서) | EXISTENCE_CHECK: 절차서 업로드 | Manual-Required |
| CCSS-C15 | 10. Key Recovery | 키 복구 실행 기록 | CORE-08 | AuditRecord(KEY_RECOVERY) | EXISTENCE_CHECK: 복구 실행 이력 | Auto-Satisfied |
CCSS 통제 항목 합계: 15개 - Auto-Satisfied: 10개 (67%) - Evidence-Available: 3개 (20%) - Manual-Required: 2개 (13%)
4.4. SOC 2 Type II (Trust Service Criteria) 매핑 테이블¶
| Control ID | TSC 영역 | 통제 항목 | 규제 조항 ID | Evidence Source | Evaluation Logic | 판정 가능 상태 |
|---|---|---|---|---|---|---|
| SOC2-C01 | CC6.1 | 논리적 접근 통제 정의 | CORE-05 | SYSTEM_CONFIG(RBAC 정책) + PolicyVersionRecord | EXISTENCE_CHECK: RBAC 정책 정의 | Auto-Satisfied |
| SOC2-C02 | CC6.2 | 인증 메커니즘 (MFA) | CORE-05 | AuditRecord(AUTH_SUCCESS).payload | EXISTENCE_CHECK: MFA 인증 기록 | Auto-Satisfied |
| SOC2-C03 | CC6.3 | 접근 권한 주기적 검토 | CORE-05 | AuditRecord(ROLE_ASSIGN/REVOKE) 패턴 | TEMPORAL_CHECK: 분기별 권한 검토 | Evidence-Available |
| SOC2-C04 | CC6.6 | 시스템 경계 보호 | CORE-06 | SYSTEM_CONFIG(에어갭 + 방화벽) | EXISTENCE_CHECK: 에어갭 아키텍처 | Auto-Satisfied |
| SOC2-C05 | CC6.7 | 데이터 전송 암호화 | CORE-06 | SYSTEM_CONFIG(TLS 1.3 + QR/NFC 전용) | EXISTENCE_CHECK: 암호화 전송 | Auto-Satisfied |
| SOC2-C06 | CC6.8 | 악의적 소프트웨어 방지 | CORE-06 | SYSTEM_CONFIG(SE 펌웨어 서명 검증) | EXISTENCE_CHECK: 서명 검증 활성 | Auto-Satisfied |
| SOC2-C07 | CC7.1 | 보안 이벤트 모니터링 | CORE-04, CORE-06 | AuditRecord(SECURITY_EVENT, AUTH_FAILURE) | COUNT_THRESHOLD: 보안 이벤트 모니터링 활성 | Auto-Satisfied |
| SOC2-C08 | CC7.2 | 변경 관리 절차 | CORE-09 | PolicyVersionRecord 해시 체인 + AuditRecord(POLICY_UPDATE) | CHAIN_INTEGRITY: 정책 변경 이력 무결성 | Auto-Satisfied |
| SOC2-C09 | CC7.3 | 변경 승인 프로세스 | CORE-09 | PolicyVersionRecord.quorum_proof | EXISTENCE_CHECK: 쿼럼 승인 증명 | Auto-Satisfied |
| SOC2-C10 | CC7.4 | 무단 변경 탐지 | CORE-04 | SEAuditDigest.policy_hash 검증 | CHAIN_INTEGRITY: SE 해시 앵커 | Auto-Satisfied |
| SOC2-C11 | CC8.1 | 인시던트 대응 계획 | CORE-06 | MANUAL_ATTESTATION(인시던트 대응 계획서) | EXISTENCE_CHECK: 대응 계획서 업로드 | Manual-Required |
| SOC2-C12 | A1.1 | 시스템 가용성 모니터링 | CORE-06 | SYSTEM_CONFIG(헬스 체크 설정) | EXISTENCE_CHECK: 모니터링 활성 | Evidence-Available |
| SOC2-C13 | A1.2 | 백업 및 복구 | CORE-08 | AuditRecord(KEY_BACKUP, KEY_RECOVERY) | EXISTENCE_CHECK: 백업/복구 기록 | Auto-Satisfied |
| SOC2-C14 | A1.3 | 복구 테스트 | CORE-08 | AuditRecord(KEY_RECOVERY) 테스트 기록 | TEMPORAL_CHECK: 연 1회 이상 복구 테스트 | Evidence-Available |
| SOC2-C15 | PI1.1 | 개인정보 수집/사용 통지 | CORE-06 | MANUAL_ATTESTATION(개인정보 처리방침) | EXISTENCE_CHECK: 처리방침 업로드 | Manual-Required |
SOC 2 통제 항목 합계: 15개 - Auto-Satisfied: 9개 (60%) - Evidence-Available: 3개 (20%) - Manual-Required: 3개 (20%)
5. 매핑 엔진 데이터 흐름¶
5.1. 전체 파이프라인 아키텍처¶
[Zone 3: SE]
SEAuditDigest (128B)
RegulationTagBitmap (8B)
|
| (QR/NFC - AuditSyncPayload)
v
[Zone 2: 오프라인 앱]
AuditRecord 로컬 체인
PolicyVersionRecord 로컬 사본
|
| (QR 배치 동기화)
v
[Zone 1: 대시보드 - 매핑 엔진]
+----------------------------------+
| 1. 데이터 수집 레이어 |
| - AuditRecord 집계 DB |
| - PolicyVersionRecord 체인 |
| - RegulationTagBitmap 스냅샷 |
| - SEAuditDigest 검증 결과 |
| - PoCS 보고서 아카이브 |
+----------------------------------+
|
v
+----------------------------------+
| 2. 매핑 평가 레이어 |
| - RegulationControlMapping |
| 테이블 로드 |
| - JurisdictionProfile 기반 |
| 관할별 필터링 |
| - EvidenceSource 수집 |
| - EvaluationLogic 실행 |
+----------------------------------+
|
v
+----------------------------------+
| 3. 판정 결과 레이어 |
| - Control별 판정 상태 결정 |
| - 충족률 계산 |
| - 미충족 항목 알림 생성 |
| - ComplianceChecklist 출력 |
+----------------------------------+
5.2. 데이터 수집 상세¶
| 데이터 소스 | 수집 방법 | 수집 주기 | 데이터 경로 |
|---|---|---|---|
| AuditRecord | AuditSyncPayload 수신 시 Zone 1 DB에 적재 | 실시간 (동기화 시) | Zone 2 -> QR -> Zone 1 DB |
| PolicyVersionRecord | PolicyUpdateBundle 적용 결과 Zone 1에 동기화 | 정책 변경 시 | Zone 2 -> QR -> Zone 1 체인 |
| RegulationTagBitmap | SignatureRegTags에서 추출 | 서명 동기화 시 | Zone 3 -> Zone 2 -> Zone 1 |
| SEAuditDigest | AuditSyncPayload에 포함된 다이제스트 | 동기화 배치 | Zone 3 -> Zone 2 -> Zone 1 |
| PoCS | PoCS 생성 트리거 시 | 분기별 / 온디맨드 | Zone 3 서명 -> Zone 1 보고서 |
| SYSTEM_CONFIG | 대시보드 설정 DB | 설정 변경 시 | Zone 1 직접 |
| MANUAL_ATTESTATION | 감사인/관리자 업로드 | 수동 | Zone 1 직접 |
5.3. 매핑 평가 실행 흐름¶
1. JurisdictionProfile 로드
- active_reg_tags 비트맵 조회
- 활성 관할 확인 (최대 3개)
2. 활성 통제 항목 필터링
- 4개 프레임워크별 RegulationControlMapping 로드
- active_reg_tags에 매핑되지 않는 통제 항목 = Not-Applicable 처리
- 활성 통제 항목 목록 생성
3. 증거 수집 (각 통제 항목별)
- EvidenceSource.source_type에 따라 적절한 수집기 호출
- freshness_requirement 확인 (만료된 증거는 재수집 필요 표시)
- 수집 결과를 EvidenceRecord로 구조화
4. 판정 실행 (각 통제 항목별)
- EvaluationLogic.logic_type에 따라 판정 함수 실행
- threshold 비교 + result_mapping 적용
- 4단계 판정 상태(Auto-Satisfied / Evidence-Available / Manual-Required / Not-Applicable) 결정
5. 결과 집계
- 프레임워크별 충족률 계산 (Auto-Satisfied 비율)
- 미충족 항목(Evidence-Available + Manual-Required) 목록 생성
- ComplianceChecklist 객체 생성 -> compliance-checklist-engine.md로 전달
6. 관할별 매핑 필터링¶
6.1. 필터링 메커니즘¶
JurisdictionProfile의 active_reg_tags 비트맵을 기준으로 해당 관할에 적용되는 통제 항목만 활성화한다.
필터링 규칙:
IF RegulationControlMapping.regulation_ref의 대응 비트가
JurisdictionProfile.active_reg_tags에서 활성(=1)
THEN 해당 통제 항목 = 활성 (평가 대상)
ELSE 해당 통제 항목 = Not-Applicable (평가 제외)
6.2. 관할별 활성 통제 항목 수¶
| 관할 | active_reg_tags | MiCA 활성 | ISMS-P 활성 | CCSS 활성 | SOC 2 활성 | 총 활성 |
|---|---|---|---|---|---|---|
| 한국 | Core 10 + KR Delta 6 (비트 0~15) | 8개 (Core 매핑) | 20개 (전체) | 15개 (전체) | 15개 (전체) | 58개 |
| EU | Core 10 + EU Delta 6 (비트 0~9, 16~21) | 15개 (전체) | 8개 (Core 매핑) | 15개 (전체) | 15개 (전체) | 53개 |
| 일본 | Core 10 + JP Delta 3 (비트 0~9, 22~24) | 8개 (Core 매핑) | 8개 (Core 매핑) | 15개 (전체) | 15개 (전체) | 46개 |
| 한국+EU (멀티 관할) | Core 10 + KR 6 + EU 6 (비트 0~21) | 15개 (전체) | 20개 (전체) | 15개 (전체) | 15개 (전체) | 65개 |
6.3. 멀티 관할 매핑 병합 규칙¶
최대 3개 관할을 동시 적용할 경우: - active_reg_tags = 관할 1 OR 관할 2 OR 관할 3 (비트 OR 결합) - 충돌하는 통제 항목은 ConflictResolution 규칙으로 사전 해소 - 보존 기간 등 수치 파라미터는 더 엄격한 기준 적용 (resolution-stricter-applies)
7. 매핑 갱신 프로세스¶
7.1. 규제 변경 시 매핑 테이블 업데이트 절차¶
1. 규제 변경 감지
- 규제 모니터링 알림 (수동 또는 구독형 서비스)
- 대시보드 알림: "규제 변경 감지: [규제명] [변경 내용]"
2. 매핑 영향도 분석
- 변경된 규제 조항(REG-XX-YY)에 연결된 통제 항목 식별
- 영향받는 프레임워크/통제 항목 목록 생성
- 신규 통제 항목 추가 또는 기존 항목 수정 여부 판단
3. 매핑 테이블 갱신
- RegulationControlMapping 레코드 추가/수정
- EvidenceSource 추가 (신규 증거 소스 필요 시)
- EvaluationLogic 갱신 (판정 기준 변경 시)
4. 프로파일 갱신
- JurisdictionProfile.profile_version 증가
- active_reg_tags 비트맵 갱신 (신규 비트 할당 시)
- PolicyUpdateBundle로 SE에 전달
5. 체크리스트 재생성
- 갱신된 매핑으로 ComplianceChecklist 재생성
- 이전 버전과 diff 생성 -> 신규/변경 항목 알림
7.2. ESMA MiCA JSON 스키마 대응¶
참고: ESMA MiCA JSON 스키마 최종본은 2026-05 공표 예정 (STATE.md risk 항목). 현재 설계는 Draft 기반이며, 최종본 공표 후 아래 항목을 갱신한다.
- MiCA-C04 (NCA 접근 가능 형식)의 ESMA JSON 변환 모듈
- DELTA-EU-04 관련 통제 항목의 Evidence Source 및 Evaluation Logic
- 보고서 출력 포맷의 ESMA JSON 스키마 바인딩
갱신 일정: 2026-05 최종본 공표 -> 2주 내 영향도 분석 -> 4주 내 매핑 테이블 갱신 완료
8. 프레임워크 간 통제 항목 교차 참조¶
8.1. 교차 매핑 매트릭스¶
하나의 시스템 기능이 여러 프레임워크의 통제 항목을 동시에 충족하는 경우를 식별한다.
| 시스템 기능 | MiCA | ISMS-P | CCSS | SOC 2 | 충족 프레임워크 수 |
|---|---|---|---|---|---|
| 3계층 해시 체인 무결성 | MiCA-C13 | ISMS-C11 | CCSS-C12 | SOC2-C10 | 4개 |
| RBAC + MFA | MiCA-C05 | ISMS-C01~C03 | CCSS-C09 | SOC2-C01, C02 | 4개 |
| 정책 해시 체인 | MiCA-C14 | ISMS-C20 | - | SOC2-C08, C09 | 3개 |
| PoCS 보고서 | MiCA-C01 | ISMS-C17 | CCSS-C11 | - | 3개 |
| AuditRecord 5년 보존 | MiCA-C03 | ISMS-C13 | CCSS-C13 | - | 3개 |
| 에어갭 아키텍처 | MiCA-C12 | ISMS-C05, C06 | CCSS-C03 | SOC2-C04 | 4개 |
| 키 백업/복구 | MiCA-C09 | - | CCSS-C05, C15 | SOC2-C13 | 3개 |
8.2. 교차 참조의 의의¶
- 감사 효율성: 하나의 증거로 여러 프레임워크 통제 항목을 동시 충족 가능
- 투자 효율성: 단일 시스템 기능이 다중 인증에 활용되어 ROI 극대화
- 관할별 확장: 한국(ISMS-P 필수) + EU(MiCA 필수) 동시 대응 시 교차 영역 활용
9. 종합 매핑 통계¶
9.1. 프레임워크별 자동화율¶
| 프레임워크 | 총 통제 항목 | Auto-Satisfied | Evidence-Available | Manual-Required | Not-Applicable | 자동화율 |
|---|---|---|---|---|---|---|
| MiCA | 15개 | 8개 (53%) | 4개 (27%) | 3개 (20%) | 관할별 | 53% |
| ISMS-P | 20개 | 15개 (75%) | 3개 (15%) | 2개 (10%) | 관할별 | 75% |
| CCSS | 15개 | 10개 (67%) | 3개 (20%) | 2개 (13%) | - | 67% |
| SOC 2 | 15개 | 9개 (60%) | 3개 (20%) | 3개 (20%) | - | 60% |
| 전체 | 65개 | 42개 (65%) | 13개 (20%) | 10개 (15%) | 관할별 | 65% |
9.2. 핵심 성과 지표¶
- 전체 자동화율 65%: 65개 통제 항목 중 42개를 시스템이 자동으로 충족 증명
- ISMS-P 자동화율 75%: 한국 Phase 1 핵심 인증에서 가장 높은 자동화율 달성
- 수동 필수 15%: 10개 항목만 조직 프로세스 문서/물리적 보안 증빙이 필요
- 에어갭 아키텍처의 기여: 네트워크 분리/암호화/키 관리 관련 통제 항목이 에어갭 구조로 자동 충족
관련 문서¶
- AML/KYT 외부 연동 인터페이스 및 Travel Rule 대응 설계 -- 규제 준수
- 규제별 컴플라이언스 체크리스트 자동 생성 엔진 설계 -- 규제 준수