infraurp 2a2ab99d10 개인정보보호 기능개선 사업 구현 (SFR-001~004, 권한관리·인증체계·접속기록)

권한관리(SFR-001):
- getAuthorities() 구현(EgovUserAuthorityDAO), AuthorityInterceptor 역할별 URL 접근제어
  (COMTNMENUCREATDTLS×COMTNMENUINFO×COMTNPROGRMLIST 메뉴권한 기반, 캐시/TTL, ROLE_ADMIN 바이패스)
- 권한 신청·승인 워크플로 + AUTHOR_CHANGE_HISTORY 이력(3년 보관), 조회·다운로드
계정관리(SFR-002): 계정관리정책, 장기미사용(휴면) 확장(취급자 포함)·사전알림, 계정잠금 5회
인증체계(SFR-003): 로그인 통합 2단계 인증(SecondFactorInterceptor+SecondFactorController),
  OTP QR 등록(ZXing)·비밀키 DB 영속(OTP_DEVICE, AES-GCM), 세션재발급(고정공격 방지), 자동로그아웃 30분
접속기록(SFR-004): PERSONAL_DATA_ACCESS_LOG(월파티션), PersonalDataLogAspect 한정수집,
  SHA-256 해시체인 무결성, 업무유형매핑, IP 취득보정, 비정상접근 탐지, 정기점검 리포트
DB: privacy DDL 11종 + 설치용 통합 SQL(privacy.install_mysql.sql, DDL+시드 DML)
빌드복구: pom.xml 시스템 jar/JAXB 선언, iBatis2 SQL주석 '#'→'No.' 정정

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

2026-07-22 18:03:02 +09:00

5.2 KiB

Raw Permalink Blame History

COMTNSYSLOG 7일 삭제정책 분리 분석노트 (#38)

문화품앗이 개인정보보호 기능개선 사업 (SFR-004 / DBR-001 / SER-002) 개발항목 #38 — 담당: Fork C | 작성일: 2026-07-21 목적: 기존 시스템로그(COMTNSYSLOG) 7일 삭제정책이 신규 개인정보 접속기록 (PERSONAL_DATA_ACCESS_LOG, 730일 보관)에 오적용되지 않도록 분리 상태를 진단·보강한다.

1. 기존 7일 삭제정책 실측 (파일:라인)

계층	위치	내용
SQL(삭제문)	`src/main/resources/egovframework/sqlmap/com/sym/log/lgm/EgovSysLog_SQL_Mysql.xml:159~165`	`DELETE FROM COMTNSYSLOG WHERE OCCRRNC_DE < DATE_FORMAT(ADDDATE(SYSDATE(), -7), '%Y%m%d')`
DAO	`src/main/java/egovframework/com/sym/log/lgm/service/impl/SysLogDAO.java:47~50`	`logInsertSysLogSummary()` 내부에서 요약 INSERT 직후 삭제 DELETE를 한 메서드로 묶어 호출
Service	`.../service/impl/EgovSysLogServiceImpl.java:60~64`	`logInsertSysLogSummary()` 위임
Scheduling	`.../service/EgovSysLogScheduling.java:36~38`	`sysLogSummary()` → 서비스 호출
스케줄 설정	`src/main/resources/egovframework/spring/com/context-scheduling-sym-log-lgm.xml:6~28`	Quartz `MethodInvokingJobDetailFactoryBean`+`SimpleTriggerBean`(1시간 주기). 단, `SchedulerFactoryBean`(L22~28)은 주석 처리 → 현재 비활성
타 DB 동일본	`EgovSysLog_SQL_{Oracle,Altibase,Cubrid,Tibero}.xml`의 동일 `SysLogDAO.logDeleteSysLogSummary`	MySQL과 동일 구조

대상: COMTNSYSLOG 단일 테이블. 삭제 기준 컬럼 OCCRRNC_DE(발생일자, YYYYMMDD 문자열). 보관 7일. 주기: 정의상 매 1시간(요약 배치에 종속) — 요약 INSERT가 실행될 때마다 7일 경과분 삭제. 현재 활성 여부: 비활성. 트리거를 물고 있는 SchedulerFactoryBean이 주석 처리되어 스케줄러에 등록되지 않음(context-scheduling-sym-log-lgm.xml:22~28).

2. 개인정보 접속기록 오적용 위험 판정

판정: 직접 오적용 위험 낮음(구조적 분리됨). 단, 결합 설계로 인한 잠재적 혼동 리스크 있음.

삭제문이 테이블명 COMTNSYSLOG에 하드코딩되어 있어 PERSONAL_DATA_ACCESS_LOG를 물리적으로 건드릴 수 없다. namespace도 SysLogDAO로 분리되어 있다.
신규 접속기록의 유일한 삭제 경로는 **파티션 DROP 방식 730일 파기 배치(#37, Fork A 담당)**로 별도 설계되어, 개별 DELETE 및 7일 정책과 경로가 완전히 다르다.
다만 잠재 리스크 2가지:
1. 결합(coupling) 리스크 — 7일 DELETE가 logInsertSysLogSummary()(요약 INSERT)에 묶여 있어, 향후 이 메서드를 재사용·확장하는 개발자가 삭제 부작용을 인지하지 못할 수 있다. 요약과 파기는 관심사가 다르므로 분리가 바람직.
2. 오해 리스크 — 신규 접속기록 보관/파기를 구현하며 기존 SysLogDAO/EgovSysLog_SQL_*.xml에 접속기록용 statement를 추가하면 두 로그 체계가 한 namespace에 섞여 7일 정책이 잘못 상속될 수 있다.

3. 분리 보강 권고

namespace 절대 분리(필수): 개인정보 접속기록 관련 SQL은 절대 SysLogDAO/EgovSysLog_SQL_*.xml에 추가하지 않는다. 신규 PrivacyAccessLog*/전용 sqlmap namespace로만 관리한다. (Fork A #30/#37 산출물이 이미 별도 DDL/파일로 분리됨 — 이 원칙 유지.)
PERSONAL_DATA_ACCESS_LOG에 UPDATE/DELETE statement 미정의(필수): 애플리케이션 계층에 개별 DELETE를 만들지 않는다(위·변조 방지 + 보관정책 일원화). 유일 삭제 경로 = 파티션 DROP 파기 배치(#37).
방어 주석 추가(권고): EgovSysLog_SQL_Mysql.xml의 logDeleteSysLogSummary 및 SysLogDAO.logInsertSysLogSummary()에 "이 7일 삭제정책은 COMTNSYSLOG 전용이며 PERSONAL_DATA_ACCESS_LOG(730일)에 적용 금지" 주석을 남겨 혼동 차단. (본 노트는 진단 중심이라 소스 미수정 — 방어 주석은 후속 반영 권고.)
요약/파기 분리(선택·개선): 7일 삭제를 요약 INSERT 메서드에서 떼어 별도 메서드로 분리하면 결합 리스크 해소. 단 기존 동작 변경이므로 운영 영향 검토 후 진행.
활성화 시 주의(운영): 현재 시스템로그 요약/삭제 스케줄러가 비활성 상태다. 향후 활성화(SchedulerFactoryBean 주석 해제) 시 7일 삭제가 함께 켜지므로, 접속기록 파기 배치(#37)와 주기·대상이 독립적으로 동작하는지 재확인한다.

4. 결론

기존 7일 삭제정책은 COMTNSYSLOG 전용으로 물리·논리적으로 분리되어 있어 신규 접속기록에 직접 오적용될 위험은 낮으며, 현재 스케줄러 자체가 비활성이다. 다만 삭제가 요약 배치에 결합된 구조라 향후 혼동을 막기 위해 ① 접속기록 SQL의 namespace 절대 분리, ② 접속기록 DELETE statement 미정의, ③ 방어 주석을 유지·반영할 것을 권고한다. 이 원칙은 Fork A의 #30(DDL)/#37(파티션 파기 배치) 산출물이 별도 파일·namespace로 이미 준수하고 있다.