본 문서는 고객이 관할을 선택하면 해당 규제 요건이 자동으로 적용되는 사전 구성 정책 프로파일(JurisdictionProfile)을 설계한다. 한국은 Phase 1 상세 설계, EU와 일본은 구조 설계를 포함한다.
핵심 가치:
- 고객이 관할을 선택하기만 하면 Core 10개 + 해당 Delta 규칙이 자동으로 PolicyUpdateBundle에 포함
- 규제 전문가가 아닌 운영자도 규제 준수 상태를 즉시 달성 가능
- 관할 간 규제 충돌(보존 기간, 삭제권 등)이 프로파일 수준에서 사전 해소
; ====================================================================; D'CENT Enterprise JurisdictionProfile Schema; 관할별 사전 구성 정책 프로파일; Phase: 31-hardware-policy-engine; ====================================================================JurisdictionProfile={profile_id:bstr.size16,; UUID v7jurisdiction_code:JurisdictionCode,; 관할 코드 (policy-update-bundle.md 참조)profile_version:uint.size2,; 프로파일 버전 (관할 규제 갱신 시 증가)profile_name:tstr,; 프로파일 명칭 (한국/EU/일본 등)base_rules:[+PolicyRule],; Core 10개 규칙 (모든 프로파일 공통)delta_rules:[*PolicyRule],; 관할별 Delta 규칙active_reg_tags:RegulationTagBitmap,; 활성화되는 규제 태그 비트맵retention_period_days:uint.size4,; 기본 보존 기간 (일)?cold_ratio_percent:uint.size1,; 콜드 보관 비율 (%, nullable)conflict_resolutions:[*ConflictResolution],; 규제 충돌 사전 해소 규칙effective_date:uint.size4,; 프로파일 발효일 (epoch seconds)?notes:tstr,; 프로파일 비고}ConflictResolution={conflict_id:tstr,; 충돌 식별자 (예: "GDPR-vs-MiCA-retention")conflicting_regs:[+tstr],; 충돌하는 규제 ID 목록resolution_method:ResolutionMethod,; 해소 방법legal_basis:tstr,; 법률 근거applied_value:tstr,; 적용되는 값 (예: "5년 보존 + 가명처리")}ResolutionMethod=&(resolution-legal-exception:1,; 법률 근거 예외 적용resolution-stricter-applies:2,; 더 엄격한 기준 적용resolution-parameterized:3,; 관할별 파라미터 분리resolution-process-based:4,; 프로세스로 해소 (시스템 외))
서명 요청 시 SE 내부 로직:
1. SE 관리 자산 총액 확인 (SE가 알고 있는 UTXO/잔액 합계)
2. 오프라인 앱이 전달한 "전체 자산 총액" 확인
3. cold_ratio = SE_assets / total_assets
4. cold_ratio >= 80% 확인
5. 미달 시 서명 거부 + AuditRecord(POLICY_VIOLATION) 생성
제약: SE는 자체 관리 자산만 직접 알 수 있음.
전체 자산 총액은 오프라인 앱에서 전달 (신뢰 경계 주의)
대안: Proof of Cold Storage 보고서로 사후 검증 보강 (Phase 30)
금감원 검사 데이터 추출 (rule_id=0x0105):
금감원 현장 검사 시:
1. 대시보드에서 금감원 검사 모드 활성화
2. 검사 기간 지정 (시작일 ~ 종료일)
3. 해당 기간의 AuditRecord 전체 추출
4. OCSF/금감원 포맷으로 변환
5. SE 서명으로 데이터 무결성 증명 첨부
6. 추출 이벤트 자체도 AuditRecord로 기록
Zone 배치: Zone 1(대시보드)에서 처리.
SE는 서명 증명만 제공.
ConflictResolution = {
conflict_id: "GDPR-vs-MiCA-retention",
conflicting_regs: ["DELTA-EU-03", "DELTA-EU-06"],
resolution_method: resolution-legal-exception (1),
legal_basis: "GDPR Art. 17(3)(b): 법적 의무 이행을 위한 삭제 예외",
applied_value: "MiCA 5년 보존 기간 중에는 삭제 거부. 보존 기간 종료 후 가명처리(pseudonymization) 적용",
}
적용 로직:
1. EU 고객 삭제 요청 수신 (Zone 1 대시보드)
2. 해당 데이터의 보존 기간 확인 (retention_days=1825)
3. 보존 기간 내: 삭제 거부 + Art. 17(3)(b) 법률 근거 고지
4. 보존 기간 후: 개인 식별 데이터를 가명처리, 감사 로그의 해시 체인은 유지
5. 삭제 요청/거부/처리 이벤트 자체도 AuditRecord로 기록
멀티 관할 PolicyUpdateBundle 생성:
1. 대시보드에서 고객이 관할 목록 선택 (예: [KR, EU])
2. 각 관할 JurisdictionProfile 로드
3. Core 규칙: 모든 프로파일 공통 (1벌만 포함)
4. Delta 규칙: 모든 선택 관할의 Delta 합집합
5. active_reg_tags: 모든 프로파일의 비트맵 OR
6. 파라미터 충돌 해소:
a. cold_ratio: max(KR.80, EU.null) = 80%
b. retention: 관할별 태그로 분리 (KR 5년 + EU 5년 공존)
c. 고유 충돌: ConflictResolution 배열에 포함
7. PolicyUpdateBundle 조립 -> 쿼럼 서명 -> SE 적용
초기 배포 워크플로우:
1. 고객이 D'CENT Enterprise 도입 계약
2. 대시보드 초기 설정에서 관할 선택 (필수 단계)
- 관할 목록 제시: 한국 / EU / 일본 / 글로벌(Core만)
- 멀티 관할 선택 가능
3. 선택된 관할의 JurisdictionProfile 기반 PolicyUpdateBundle 자동 생성
4. Org Owner + Vault Admin 초기 쿼럼 서명
5. QR/NFC로 SE에 전달 -> APPLY_POLICY
6. SE에서 정책 적용 완료 -> SEAuditDigest.active_jurisdictions 갱신
7. POLICY_CHANGE AuditRecord 생성 (초기 적용)
관할 변경 워크플로우:
1. Policy Admin이 대시보드에서 관할 변경 요청
- 추가: 기존 관할 + 새 관할
- 제거: 기존 관할 - 제거 관할
- 전환: 기존 관할 -> 새 관할
2. 병합 규칙 적용하여 새 PolicyUpdateBundle 생성
3. 쿼럼 승인 (관할 변경은 최소 쿼럼 요건)
4. SE 적용 -> active_jurisdictions 갱신
5. POLICY_CHANGE AuditRecord에 jurisdictions_before/after 기록
프로파일의 active_reg_tags가 Phase 32 컴플라이언스 체크리스트 자동 생성의 입력이 된다:
Phase 32 연결 흐름:
1. 현재 SE의 active_jurisdictions 확인 (SEAuditDigest에서 읽기)
2. 해당 관할의 JurisdictionProfile 로드
3. active_reg_tags의 각 비트 → 해당 규제 조항 식별
4. 규제 조항 → 통제 항목 매핑 (Compliance-as-Code 엔진)
5. 통제 항목별 충족 상태 = AuditRecord + 정책 상태에서 자동 판단
6. 컴플라이언스 체크리스트 출력 (ISMS-P / MiCA / CCSS / SOC 2)