================================================================================ 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 실측을 근거로 작성되었습니다. 항목별 상세 근거(파일·행 번호)가 필요하시면 별도로 제공해 드립니다. ================================================================================