somang4819/arko_renual
1
0
Fork 0
Code Issues Pull Requests 1 Actions Packages Projects Releases Wiki Activity
feature/privacy-access-control-policy
arko_renual/발주기관 확인 항목.txt
infraurp 722fd978ce 관리자 알림 테스트 발송 버튼 + 발주기관 확인 항목 정리 
· 테스트 발송 버튼 — [계정 관리 정책] 화면의 관리자 수신 이메일 옆
  실제 알림은 월 1회 배치에서만 나가서, 수신 주소를 바꾼 관리자가 그것이
  맞는지 한 달을 기다려야 확인할 수 있었다. 같은 발송 경로(수신주소 조회 →
  메일 모듈 적재·발송)를 그대로 타는 테스트를 눌러 즉시 결과를 본다.
  경로가 다르면 테스트가 통과해도 실제 알림은 실패할 수 있으므로 반드시
  같은 경로여야 한다.

  - 성공·실패 모두 서버가 준 사유를 그대로 화면에 띄운다.
    "실패했습니다"만 뜨면 주소 미설정인지 메일서버 문제인지 구분할 수 없다.
  - 메일 모듈이 예외 없이 false 를 반환하는 경우도 실패로 잡는다
    (insertSndngMail 은 적재 후 곧바로 전송하고 실패 시 결과코드를 'F' 로 갱신한다.
     예외가 없다고 발송된 것이 아니다).
  - 상태를 바꾸지는 않지만 외부로 메일이 나가므로 POST·동일출처만 받는다.

· 발주기관 확인 항목.txt 신규
  제안요청서·제안서만으로 결정할 수 없어 발주기관 확인이 필요한 항목을
  근거 문구·현재 구현 상태·미확정 시 영향과 함께 정리했다. A(개발 완료 조건) /
  B(운영정보 필요) / C(문서에 명시 없음) / D(사업관리)로 나눴고, 확인 없이
  진행한 값은 근거를 명시해 [참고] 절에 따로 적었다.

검증: mvn compile EXIT=0, JSP Jasper 오류 0건, 로컬 반영·재기동 정상
(빈 생성 오류 0건), 정책화면 302→로그인.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-27 18:18:23 +09:00

295 lines
19 KiB
Plaintext
Raw Permalink Blame History

================================================================================
2026년 문화품앗이 개인정보보호 기능개선 용역 — 발주기관 확인 항목
--------------------------------------------------------------------------------
작성일 : 2026-08-27
대상 : 한국문화원연합회 (발주기관)
근거 : 붙임2_제안요청서.hwp / 개인정보보호강화 파일럿 개발항목.pptx(제안요약서)
작성 : 개발 수행 중 소스·DB 실측으로 확인된 사항
--------------------------------------------------------------------------------
이 문서는 개발을 진행하면서 "제안요청서·제안서만으로는 결정할 수 없어 발주기관의
확인이나 결정이 필요한 항목"을 모은 것입니다. 각 항목에는 근거 문구, 현재 구현
상태, 결정이 필요한 내용, 미확정 시의 영향을 함께 적었습니다.
임의로 값을 정하지 않고 제안서 근거값(또는 법정 기준)으로 잠정 구현해 둔 상태이며,
확인 결과에 따라 설정값 변경 또는 추가 개발로 반영합니다.
================================================================================
================================================================================
[A] 확정되어야 개발이 완료되는 항목 (미확정 시 해당 기능 미완)
================================================================================
--------------------------------------------------------------------------------
A-1. 휴대폰(SMS) 인증 — 문자발송모듈 연동 규격
--------------------------------------------------------------------------------
근거 : SFR-003 "OTP, 휴대폰인증, 공동인증서 등 안전한 인증수단을 적용하여야 한다"
IAR-001 "휴대폰 인증 적용 시 기존 문자발송모듈과 연계 가능하여야 한다"
제안요청서 운영환경 : 문자발송모듈 = KT-TCS / MCSAgent3.0
현재 : 2단계 인증 3종 중
- OTP : 구현 완료 (TOTP RFC6238, 비밀키 암호화 저장, 실동작)
- 공동인증서 : 구현 완료 (기존 GPKI 자산 위임, 인증서 DN 만 대조)
- 휴대폰SMS : 인터페이스와 빈 등록까지만 되어 있고 실제 발송·검증 미구현
확인요청 : ① KT-TCS / MCSAgent3.0 연동 규격서(발송 API, 인증정보, 발신번호)
② 발송 비용 부담 주체 및 월 발송 한도
③ 인증번호 유효시간(제안 설계값 3분)과 재발송 제한 정책
미확정시 : 인증수단 3종 중 1종(휴대폰)이 미완 상태로 남습니다.
현재 OTP·공동인증서만으로도 2단계 인증은 동작하므로 SFR-003 의
"추가 인증 절차 제공"은 충족하나, "휴대폰인증 적용"은 미충족입니다.
--------------------------------------------------------------------------------
A-2. 회원정보 암호화 마스터 키 — 운영 환경 확인 필요 ★ 시급 ★
--------------------------------------------------------------------------------
근거 : 제안서 추가제안 Action4 "회원정보 암호화 저장"
개인정보 보호법 제29조 / 안전성 확보조치 기준 제7조
현재 : 회원 이름(COMTNGNRLMBER.MBER_NM)을 AES-128/GCM 으로 암호화하도록
개발 완료되어 있고, 개발 PC 기준 77,053건이 이미 암호화되어 있습니다.
그런데 암호화 키를 서버에 영구 보관하는 설정이 어느 환경에도 없습니다.
- 개발서버 기동 설정(arko-dev.service) : 키 설정 없음
- 운영 WAS 컨테이너 설정(01-was-setup.sh) : 키 설정 없음
키는 프로세스 실행 시점에만 존재하는 값이라, 서버를 재기동하면
사라지고 기존 암호문을 복호화할 수 없게 됩니다.
확인요청 : ① 운영 DB(csv)의 COMTNGNRLMBER 에 암호문이 이미 적재되어 있는지
SELECT COUNT(*), COUNT(MBER_NM_ENC) FROM COMTNGNRLMBER;
② 적재되어 있다면 그때 사용한 마스터 키/pepper 값의 보관처
③ 키 보관 방식 결정 (서버 환경변수 / 권한 600 키파일 / 별도 금고)
④ 키 관리 책임자 지정
미확정시 : 회원 이름을 표시하는 관리자 화면이 동작하지 않습니다.
※ 키를 새로 만들면 기존 암호문을 영구히 읽을 수 없습니다. 운영 데이터에
대해서는 절대 새 키로 재암호화하지 마시고, 반드시 원래 키를 확보한 뒤
적용해야 합니다.
--------------------------------------------------------------------------------
A-3. 계정 삭제 — 보존기간 및 자동 삭제 시행 여부
--------------------------------------------------------------------------------
근거 : 과업내용 가 "장기 미사용 계정 및 회원 탈퇴 후 보존기간이 경과한 계정의
삭제 기능 구현"
현재 : 삭제 기능은 개발 완료되었으나 안전을 위해 기본 비활성 상태입니다.
- 보존기간 기본값 : 365일 (ACCOUNT_MNG_POLICY.DELETE_PRESERVE_DAY)
- 자동삭제 사용여부: '아니오' (PURGE_USE_YN = 'N')
현재는 관리자가 화면에서 개별 승인해 말소하는 방식만 동작합니다.
확인요청 : ① 탈퇴 후 보존기간 일수 (내부 규정/타 시스템 기준)
② 보존기간 경과 계정을 자동 삭제할지, 관리자 승인 후 삭제할지
③ 삭제 대상에 일반회원도 포함할지, 개인정보취급자 계정만 대상으로 할지
(현재는 취급자 계정 한정으로 구현)
미확정시 : 자동 삭제가 계속 비활성으로 남습니다. 되돌릴 수 없는 처리라 임의로
켜지 않았습니다.
================================================================================
[B] 운영 환경 정보가 있어야 정확해지는 항목
================================================================================
--------------------------------------------------------------------------------
B-1. 내부망 IP 대역 / 신뢰 프록시 대역
--------------------------------------------------------------------------------
근거 : SFR-003 "개인정보취급자의 외부 접속 시 추가인증 절차를 제공하여야 한다"
SFR-004 "접속기록에는 접속지 정보(IP)가 포함되어야 한다"
현재 : 잠정값으로 사설 대역(127.0.0.0/8, 10.0.0.0/8, 172.16.0.0/12,
192.168.0.0/16)을 내부망으로 간주하고 있습니다.
판정이 불가능하면 안전측으로 '외부 접속'으로 보아 추가 인증을 요구합니다.
확인요청 : ① 실제 내부망(사내/전용선) IP 대역
② 웹서버 구성(Apache + L4 등) 및 프록시 헤더 전달 여부
- 접속기록의 IP 가 L4 장비 IP 로 고정되어 쌓이면 접속기록의
"접속지 정보"가 사실상 무의미해집니다.
미확정시 : ① 외부 접속인데 내부로 오판하여 추가 인증을 건너뛸 수 있습니다.
② 접속기록의 IP 가 전부 동일한 값으로 남을 수 있습니다.
--------------------------------------------------------------------------------
B-2. 배치 스케줄러 운영 방식
--------------------------------------------------------------------------------
근거 : SFR-002(휴면 배치), SFR-004(파기·무결성검증·정기점검 배치)
현재 : 개인정보보호 배치는 애플리케이션 스케줄러(@Scheduled)로 구현되어 있습니다.
- 매일 01:00 휴면 전환 / 06:00 휴면 사전알림
- 매월 1일 02:00 접속기록 파기 / 03:00 무결성 검증
04:00 권한이력 파기 / 05:00 정기점검 리포트
확인요청 : ① 기존 운영 배치(crontab 등)와 중복 실행 우려가 있는지
② WAS 이중화 시 배치가 양쪽에서 동시에 도는 구성인지
미확정시 : 동일 배치가 중복 실행될 수 있습니다(파기 배치는 중복 실행되어도
결과가 같도록 만들었으나, 운영 구성 확인이 필요합니다).
--------------------------------------------------------------------------------
B-3. 기존 로그인 인증 인터셉터 재활성 여부
--------------------------------------------------------------------------------
근거 : SER-001 "비인가자의 개인정보처리시스템 접근을 통제하여야 한다"
현재 : 접근통제 인터셉터는 ① 인증판정 → ② 2차 인증 → ③ 권한 판정 3단으로
설계되어 있으나, ① 인증판정(로그인 체크)은 본 사업 착수 전부터
비활성(주석) 상태였습니다. ②③은 활성화되어 동작합니다.
개인정보 관련 화면은 화면별로 로그인 여부를 다시 확인하도록 보완했습니다.
확인요청 : ① 기존에 비활성화한 사유가 있는지
② 재활성 시 영향받는 화면 범위를 함께 점검할 수 있는지
미확정시 : 개인정보 화면은 보호되지만, 그 밖의 관리자 화면은 종전 상태 그대로입니다.
================================================================================
[C] 제안서·제안요청서에 명시가 없어 판단이 필요한 항목
================================================================================
--------------------------------------------------------------------------------
C-1. "관리자 알림"의 통보 수단
--------------------------------------------------------------------------------
근거 : 제안요약서 slide15 "정기 점검 레포트 / 관리자 알림"
SFR-002 "계정 비활성화 전 관리자 알림 기능을 제공하여야 한다"
확인사항 : 두 문서 어디에도 알림 수단(메일/문자/화면)이 명시되어 있지 않습니다.
현재 : 메일로 구현했습니다.
- 계정 휴면 사전알림 : D-30 / D-7 / D-Day, 본인과 관리자에게 발송
- 접속기록 무결성 위반 탐지 시 관리자에게 발송
- 이상행위 탐지 시(정기점검 배치) 관리자에게 발송
수신 주소는 관리자가 [계정 관리 정책] 화면에서 설정합니다.
메일 본문에는 개인정보를 담지 않고 건수·기간·요약만 넣었습니다.
확인요청 : ① 메일로 충분한지, 문자(SMS) 또는 화면 알림이 필요한지
② SFR-002 의 "관리자 알림"이 가리키는 대상
- (해석1) 시스템 관리자에게 "이 계정들이 곧 비활성화된다"고 보고
- (해석2) 비활성화될 당사자에게 "곧 잠긴다"고 통지
현재는 두 해석을 모두 만족하도록 본인과 관리자 양쪽에 발송합니다.
③ 로그인 시 화면 팝업 안내가 필요한지
※ 참고 : 로그인하면 최종접속일이 갱신되어 미접속 일수가 0이 되므로,
화면 안내는 "곧 잠깁니다"가 아니라 "오랫동안 접속하지 않으셨습니다"
형태가 됩니다.
미확정시 : 메일 기준으로 유지합니다. 문자 발송은 A-1(문자발송모듈 규격) 확정
이후에만 추가할 수 있습니다.
--------------------------------------------------------------------------------
C-2. 접속·처리기록 관리 화면 구성
--------------------------------------------------------------------------------
근거 : 과업내용 다 "로그 조회 및 관리 기능 구현 — 관리자용 로그 조회 화면 개발"
제안요약서 slide14~15 화면 시안
확인사항 : 제안요청서가 요구하는 화면은 "관리자용 로그 조회 화면" 한 개이고,
제안요약서 시안도 "접속기록 조회 및 감사" 한 장만 그려져 있습니다.
다만 시안의 좌측 메뉴에는 4개 항목(① 접속기록 조회 ② 개인정보 처리기록
③ 이상행위 감사 ④ 정기 점검 리포트)이 이름만 나열되어 있습니다.
현재 : 화면 하나("접속기록 조회 및 감사")로 구성하고, 나머지 기능은 그 화면
안에서 제공합니다.
- 처리기록 조회 : 처리구분(조회/등록/수정/삭제) 필터
- 이상행위 감사 : 목록의 '감사' 칸에 이상/점검 표시
- 정기점검 : 월 1회 배치가 집계·적재
- 파기이력 : 화면 내 '파기이력' 버튼
확인요청 : 시안의 좌측 메뉴 4개를 각각 별도 화면으로 만들어야 하는지,
현재처럼 한 화면에서 제공하는 것으로 충분한지
미확정시 : 현재 구성(화면 1개)을 유지합니다. 별도 화면이 필요하면 기능은 이미
있으므로 메뉴와 화면만 분리하면 됩니다.
--------------------------------------------------------------------------------
C-3. 개인정보 처리기록의 "처리 항목"·"처리 목적"
--------------------------------------------------------------------------------
근거 : 제안요약서 slide13 처리기록 예시
처리자 / 처리 일시 / 처리 정보주체 / 처리 항목(성명·연락처·주소) /
처리 유형 / 처리 목적(봉사활동 매칭 상담)
확인사항 : 위 6개 항목 중 "처리 항목"과 "처리 목적"은 현재 접속기록에 수집되지
않습니다. 나머지 4개는 수집·저장되고 있습니다.
- 처리 항목 : 어떤 정보를 열람했는지. 화면 단위로 매핑 정의가 필요합니다.
- 처리 목적 : 시스템이 알 수 없는 값으로, 취급자가 직접 입력해야 합니다.
확인요청 : ① 두 항목을 접속기록에 반드시 남겨야 하는지
② "처리 목적"을 남긴다면, 개인정보 취급 화면에 들어갈 때마다 사유를
입력받는 방식을 수용할 수 있는지 (취급자 업무 흐름에 매번 입력이
추가됩니다)
③ 대상 화면 범위 (전 화면 / 특정 화면 한정)
미확정시 : 현재 수집 항목(접속자·일시·IP·업무유형·처리대상·처리구분·결과)을
유지합니다. 안전성 확보조치 기준 제8조의 필수 5개 항목은 충족합니다.
--------------------------------------------------------------------------------
C-4. 개인정보 마스킹 적용 범위 (추가제안)
--------------------------------------------------------------------------------
근거 : 제안요약서 slide17 "개인정보 마스킹 처리(추가제안)"
- 신청자 목록 화면과 다운로드 엑셀에 이름·휴대폰번호가 평문 노출
- 다운로드 파일이 외부 업체 전달 양식으로 추정되는 정황
현재 : 마스킹 기능(이름·휴대폰·이메일)은 개발되어 있고 회원정보 관리 화면과
2단계 인증 화면에 적용되어 있습니다.
신청자 목록·엑셀 다운로드에는 아직 적용하지 않았습니다.
확인요청 : ① 신청자 목록 화면을 마스킹할 경우 담당자 업무에 지장이 없는지
② 다운로드 엑셀의 실제 사용처(외부 업체 전달 여부)와, 마스킹 시
해당 업무가 가능한지
③ 마스킹 예외가 필요한 화면/역할이 있는지
미확정시 : 업무 영향이 커서 임의로 적용하지 않았습니다. 확인 후 반영합니다.
================================================================================
[D] 사업관리·산출물 관련
================================================================================
--------------------------------------------------------------------------------
D-1. 성능 검증 기준선
--------------------------------------------------------------------------------
근거 : PSR-001 시스템 성능 유지 / 제안요약서 slide19 "기능개선 전·후 성능 측정"
확인사항 : 제안서는 개선 전과 후의 응답속도를 비교하도록 계획하고 있으나,
개선 전 시점의 측정치가 확보되어 있지 않습니다.
확인요청 : ① 측정 대상 서비스와 시나리오
② 측정 시점 및 방법(운영 부하 영향 고려)
③ 개선 전 측정치가 없을 경우의 대안(현재 상태를 기준선으로 삼을지)
--------------------------------------------------------------------------------
D-2. 산출물 목록·양식
--------------------------------------------------------------------------------
근거 : 각 요구사항의 "산출정보" 항목
요구사항정의서 / 기능설계서 / 인터페이스설계서 / 데이터정의서 /
로그정책서 / 테스트결과서 / 적용결과보고서 등
확인요청 : ① 발주기관 표준 양식 제공 여부
② 제출 시점 및 형태(문서/전자)
③ 개인정보보호위원회 점검 대응용 조치결과보고서 양식의 필요 여부
================================================================================
[참고] 확인 없이 진행한 사항 (근거를 명시해 두었습니다)
================================================================================
· 접속기록 보관기간 : 730일(2년)
→ SFR-004 "최소 2년 이상 보관". 관리자가 화면에서 늘릴 수 있으나 2년 미만으로는
줄일 수 없도록 화면·서버·배치 세 곳에서 막았습니다.
· 권한 변경 이력 보관기간 : 1,095일(3년)
→ SFR-001 "최소 3년 이상 보관".
· 계정 잠금 임계 : 5회 / 자동 로그아웃 : 30분
→ 제안서 slide10 "잠금 5회, 로그아웃 30분으로 강화".
· 휴면 전환 기준 : 정책 테이블 설정값(기본 365일, 사전알림 D-30/D-7/D-Day)
→ 제안서 slide7 시안은 "60일 휴면예정 / 90일 자동잠금"을 예시로 들고 있어
설정값 변경만으로 시안과 동일하게 맞출 수 있습니다. 운영 기준 확정 시 반영합니다.
================================================================================
문의: 본 문서의 각 항목은 개발 소스와 DB 실측을 근거로 작성되었습니다.
항목별 상세 근거(파일·행 번호)가 필요하시면 별도로 제공해 드립니다.
================================================================================
Reference in New Issue View Git Blame Copy Permalink