# 보안대책서 HWP 수정·추가 검토서 검토 대상: `(Y수정)_(20260528)_IoT_기반_모니터링_체계_구축을_위한_보안대책서.hwp` (최신 리비전) 검토 기준: 현재 프로젝트 구현 상태(서버실 SHT30 온습도 모니터링 + 임계 SMS 경보 + 장비 오프라인 알림), 서버/STM32 단말 설치 구조, 대시보드·임계 경보·월간보고 기능 > ⚠️ HWP 바이너리는 직접 편집할 수 없습니다. 이 문서는 운영자가 HWP 본문에 반영하는 것을 전제로 한 **before → after 갱신 가이드**입니다. 인용한 라인 번호는 `docs/assets/security_plan/hwp_extracted_text.txt`(현재 HWP 추출본, 편집 금지) 기준이며 참고용입니다. 심사 대응 수준의 상세 보완안은 [SECURITY_PLAN_PASS_READINESS.md](SECURITY_PLAN_PASS_READINESS.md)를 함께 적용합니다. ## 1. 요약 판단 현재 HWP 보안대책서는 사업 목적, 추진체계, 관리적·물리적·기술적 보안대책의 큰 틀은 갖추고 있습니다. 다만 실제 구현된 시스템과 비교하면 본문이 과거 범위(화재·누수·현장 사진·사고 대응)를 기준으로 작성되어 있어, 현재 구현 범위인 **서버실 온습도(SHT30) 모니터링 + 임계 SMS 경보 + 장비 오프라인 알림**으로 정정해야 합니다. - 사업 범위가 `화재/누수/장비 전원 이상`으로 넓게 쓰여 있으나, 현재 구현은 `서버실 온습도(SHT30) 측정 + 임계(고온/저온/고습/저습) SMS 경보 + 정상복귀 SMS + 장비 오프라인/복구 SMS + 대시보드`입니다. 누수센서·카메라·현장 사진 기능은 제거되었습니다. - 구성도에는 큰 흐름이 있으나, 실제 구성요소인 STM32 보드, SHT30 온습도 센서, Cafe24 PHP API, MySQL, 측정 이력 테이블(`sensor_metric`), SMS 이력(`sms_log`), 월간 보고서가 명확히 표현되어 있지 않습니다. - API 키, 서명 검증, `config.local.php`, `firmware/common/secrets.h`(`APP_API_KEY`), 서버 임계 판정(`config.php`의 `METRIC_*`), 관리자 TOTP MFA, 관리자 감사로그 같은 실제 보안 구현 항목이 본문에 구체적으로 반영되어야 합니다. - 로그 보관기간, SMS 수신자 개인정보 관리, `retention_cleanup.php` 기반 정리 절차, 백업/복구 증빙, 장애 대응 절차가 선언 수준에 머물러 있어 운영 기준표가 필요합니다. - '현장 사진/시설정보'는 더 이상 처리하지 않으므로 해당 절은 삭제하고, 통제 공백처럼 보이지 않도록 **온습도 임계 경보 + 오발송 방지(30분 쿨다운 / 복구 히스테리시스)**로 대체 서술합니다. - 설치 후 검증 증적, 보안 점검 결과, 테스트 SMS 결과, DB 마이그레이션 적용 여부, MFA 등록 증빙, 보관기간 정리 dry-run, 백업 증빙을 첨부할 수 있는 증적 목록이 필요합니다. 운영 서버 반영 후 `security_evidence.php?format=md`, STM32 USART3 부팅 콘솔 로그(링크업/DHCP/SNTP/TLS/서버 200) 캡처, `scripts/backup_evidence.php` 결과를 함께 첨부하면 코드 기반 통제와 실제 장비 상태를 연결할 수 있습니다. ## 2. HWP에서 바로 수정해야 할 부분 (before → after) 아래 라인 번호는 `hwp_extracted_text.txt` 기준 참고값입니다. | 위치(추출본 라인) | before (현재 HWP 문구) | after (수정 방향) | 우선순위 | |---|---|---|---| | 사업목적 (L9) | "전산실 내 **화재, 누수, 장비 전원 이상** 상태를 실시간으로 감지" | "전산실(서버실) 내 **온습도 이상 및 장비 통신 이상** 상태를 실시간으로 감지" (5.1 교체안 적용) | 높음 | | 구축범위 (L11, L15~L20) | "화재 및 누수, 장비 오프라인 등 이상상태", "**감지 센서(화재/누수)**", "**카메라 연계 / 현장 사진 캡처**" | `SHT30 온습도 센서`, `STM32 보드`, `Cafe24 PHP API`, `MySQL`, `임계 SMS`, `대시보드`, `월간 보고서`로 재작성. 카메라·현장 사진 행 삭제 | 높음 | | 구축방식 (L29, L31~L37) | "화재·누수 감지센서가 이상상태를 감지하면 IoT 보드로 전달", "**카메라(현장 사진 캡처)**" | "SHT30 온습도 센서 측정 → STM32 보드 수집·보고 → 서버 임계 판정 → SMS/대시보드"로 교체 (5.2 교체안 적용). 카메라/현장 사진 박스 삭제 | 높음 | | 모니터링 시스템 구성 (L30~L38) | 감지센서(화재/누수) → IoT 보드 → 웹호스팅 서버 → SMS, 카메라(현장 사진) | `security_plan_target_architecture.png` / `security_plan_data_flow.png`로 교체. SHT30→STM32→서버 임계 판정→SMS/대시보드 흐름 | 높음 | | 네트워크 구성도 설명 (L45) | "IoT 보드에서 웹호스팅 서버로 감지 정보 및 **현장 사진**을 전송" | "STM32 단말로 들어오는 인바운드 포트는 열지 않고, 단말이 서버로 **온습도 측정값**만 아웃바운드 HTTPS POST" — '현장 사진' 문구 삭제 | 높음 | | 사진정보 및 개인정보 보호대책 (L102~L105) | "**현장 사진**은 화재·누수 등 이벤트 확인 목적으로만 수집", "**사진정보**는 암호화 저장/접근권한 제한" | **사진 관련 2개 행(L103, L104) 삭제.** SMS 수신자 전화번호 보호 문구(L105)만 유지하고, 그 자리에 '온습도 임계 경보 + 오발송 방지(30분 쿨다운/복구 히스테리시스)' 통제 추가 (5.3 교체안 적용) | 높음 | | 권한 및 계정관리 (L106~L110) | 관리자 계정 최소 부여, 비밀번호 정책 | `ADMIN_PASSWORD_HASH`, `ADMIN_TOTP_SECRET`, `MFA_SETUP_TOKEN`, 세션 쿠키 옵션, 로그인 실패 잠금, 감사로그, 비밀번호/TOTP 교체 절차 추가 | 높음 | | 단말기 보안대책 (L135~L143) | 기본 계정 변경, 하드코딩 금지 | 비밀값은 `firmware/common/secrets.h`(`APP_API_KEY`)에 두고 미커밋(.gitignore)으로 빌드 머신에서만 보관, API 키 서버 `config.php`의 `API_KEY`와 일치, 불필요 기능 비활성화 추가. (카메라 권한 관리 문구 불필요) | 높음 | | 플랫폼/서비스 보안대책 (L150~L156) | 인증, 패치, 기본 서비스 제거 | API 서명 검증, 측정값 범위 검증(온도 -40~125℃ / 습도 0~100%), DB prepared statement, TOTP MFA, `config.local.php` 비공개 관리 추가. (사진 업로드/MIME/매직바이트 검증 문구 삭제) | 높음 | | 로그관리 (L94~L95) | 로그 보관기간 정의, 위변조 방지 | `sensor_log`, `sensor_metric`, `sms_log`, 서버 `php/var/admin_audit.log`, `retention_cleanup.php` 기준으로 보관·점검 기준 추가. (`leak_incident`/`leak_photo`/Pi 로그 삭제) | 높음 | | 장비 설치·보호 (L114, L118~L120) | "화재·누수 감지센서, IoT 보드 및 **카메라**" | "SHT30 온습도 센서, STM32 보드"로 교체. 카메라 문구 삭제. 자산대장 등록은 유지 | 높음 | ## 3. HWP에 추가해야 할 장·절 ### 3.1 실제 시스템 구성요소 표 다음 표를 `사업내용` 또는 `시스템 구성도` 앞에 추가합니다. | 구성요소 | 실제 파일/기능 | 보안 통제 | |---|---|---| | STM32 보드 | 펌웨어 측정·보고, `config.py`(연계 설정) | 환경파일 기반 비밀값 관리, 로컬 로그, 불필요 서비스 차단 | | SHT30 온습도 센서 | I2C 온습도 측정(5분 주기) | 서버실 고정 설치, 임의 탈거 방지, 자산대장 등록 | | PHP API | `api/sensor_data.php` | API 키 서명 검증, HTTPS, 측정값 범위 검증, 서버 임계 판정 | | 임계 판정 | `config.php`의 `METRIC_*` 상수 | 고온30/저온10℃·고습70/저습20% 임계, 복구 히스테리시스(1.0℃/3.0%), 30분 쿨다운 | | MySQL DB | `sensor_log`, `sensor_status`, `sensor_metric`, `sms_log` | 최소 권한 DB 계정, 백업, 보관기간 관리 | | 대시보드 | `dashboard.php` | 관리자 로그인, TOTP MFA, 세션 보호, 온습도/경보 현황 표시 | | MFA 등록 | `setup_mfa.php` | 임시 등록 토큰, 인증 앱 등록 검증, 외부 QR/API 미사용 | | 설치 점검 | `setup_wizard.php` | DB/권한/SMS/임계 설정 점검 | | 보안 증적 | `security_evidence.php` | 보안통제 매트릭스, 운영 점검 결과, Markdown 다운로드 | | 월간 보고 | `monthly_report.php` | 월별 온습도 경보·SMS·오프라인 현황 출력 | | SMS 발송 | `sms_send.php` | 발신 계정 보호, 수신자 최소화, 발송 로그 관리 | | 오프라인 감지 | `cron_heartbeat.php` | heartbeat 타임아웃 기준 오프라인/복구 SMS | | 보관기간 정리 | `retention_cleanup.php` | SMS 로그, 센서 로그, 측정 이력, 관리자 감사로그 정리 대상 확인 및 실행 | | 백업 증빙 | `scripts/backup_evidence.php` | 백업 파일 목록, 설정/감사로그 존재, 복구 테스트 결과 출력 | ### 3.2 데이터 흐름 및 보호조치 다음 흐름을 본문에 추가합니다. 1. SHT30 센서가 서버실 온도·습도를 5분 주기로 측정한다. 2. STM32 보드가 측정값을 수집하여 정상 보고(`periodic`/`startup`)를 구성한다. 3. 단말이 HTTPS로 PHP API에 측정값을 전송한다(인바운드 포트 미개방, 아웃바운드 POST만). 4. 서버가 API 서명, API 키 일치, 필수 필드, 측정값 범위(온도 -40~125℃ / 습도 0~100%)를 검증한다. 5. 서버가 운영 임계(`METRIC_*`)로 고온/저온/고습/저습을 재판정하여 `sensor_metric`에 저장하고, 정상 보고는 `sensor_status`를 갱신한다. 6. 임계 이탈 시 30분 쿨다운과 복구 히스테리시스를 적용하여 종류별 SMS를 발송하고, 임계 안쪽으로 회복하면 정상복귀 SMS를 발송한다. 7. heartbeat 타임아웃이 지나면 장비 오프라인 SMS를, 보고 재개 시 복구 SMS를 발송한다. 8. 대시보드와 월간 보고서에서 온습도·경보·SMS·오프라인 현황을 표시한다. 삽입 이미지: ![데이터 흐름 및 보호조치](assets/security_plan/generated/security_plan_data_flow.png) > 참고: 위 PNG는 `scripts/generate_security_plan_images.py`로 생성합니다. 스크립트는 온습도 흐름으로 갱신되었으나 **PNG 재생성은 운영자 몫**입니다(`python scripts/generate_security_plan_images.py`). ### 3.3 임계 경보·오프라인 대응 절차 현재 HWP에는 보안대책은 있으나 온습도 임계 발생 후의 운영 절차가 부족합니다. 다음 절차를 추가합니다(기존 '누수 사고 대응 절차'는 삭제). | 단계 | 처리 내용 | 증적 | |---|---|---| | 측정 | SHT30 측정값 수신, `sensor_metric` 기록, 임계 판정 | `sensor_metric.metric_status` | | 경보 | 임계 이탈 시 종류별 SMS 발송(쿨다운 적용) | `sms_log` (`[고온경보]`/`[저온경보]`/`[고습경보]`/`[저습경보]`) | | 확인 | 담당자가 대시보드에서 온습도/경보 상태 확인 | 대시보드 캡처 | | 조치 | 공조/환기 등 현장 점검 및 환경 정상화 | 운영 점검 기록 | | 복구 | 임계 안쪽으로 회복 시 정상복귀 SMS | `sms_log` 복구 메시지 | | 오프라인 | heartbeat 타임아웃 시 오프라인 SMS, 복구 시 복구 SMS | `cron_heartbeat.php` 실행 로그, `sms_log` | | 보고 | 월간 보고서에 경보·SMS·오프라인 현황 반영 | `monthly_report.php` | ### 3.4 설치·운영 점검 절차 `setup_wizard.php`와 `security_evidence.php`를 운영 점검 도구로 명시합니다. | 점검 항목 | 확인 방법 | 불합격 시 조치 | |---|---|---| | DB 연결 | 설치 점검 화면 | `config.local.php` DB 설정 수정 | | 필수 테이블 | 설치 점검 화면 | `sql/schema_sht30.sql` 또는 `sql/migration_drop_leak.sql` 적용 | | 측정 이력 테이블 | 설치 점검 화면 | `sensor_metric` 생성 확인 | | 임계 설정 | 설치 점검 화면 | `config.php`/`config.local.php`의 `METRIC_*` 값 확인 | | API 키 | 설치 점검 화면 | 서버와 단말의 키 일치 확인 | | 관리자 해시 | 설치 점검 화면 | `php setup_hash.php`로 해시 생성 | | 관리자 MFA | MFA 등록 화면 | `setup_mfa.php`에서 인증 앱 등록 후 `ADMIN_TOTP_SECRET` 반영 | | 관리자 감사로그 | 보안 증적 화면 또는 파일 확인 | `php/var/admin_audit.log` 생성 및 로그인 기록 확인 | | SMS 수신자 | 설치 점검 화면 | 운영 담당자 번호 현행화 | | 테스트 SMS | 설치 점검 화면 | Cafe24 SMS 계정·잔액·발신번호 확인 | | 보안통제 매트릭스 | 보안 증적 화면 | `security_evidence.php?format=md` 결과를 HWP 부록에 첨부 | | 보관기간 정리 | CLI 실행 결과 | `php retention_cleanup.php --dry-run` 결과를 HWP 부록에 첨부 | | 백업·복구 증빙 | CLI 실행 결과 | `php scripts/backup_evidence.php --backup-dir ...` 결과를 HWP 부록에 첨부 | | 단말 운영 증적 | STM32 USART3 부팅 콘솔 로그 | 링크업/DHCP/SNTP/TLS/서버 200 캡처를 HWP 부록에 첨부 | ### 3.5 보관기간 및 파기 기준 HWP의 "보관기간은 최소한으로 설정" 문구를 아래처럼 구체화합니다. | 데이터 | 보관 위치 | 권장 보관기간 | 파기/정리 기준 | |---|---|---:|---| | 센서 이벤트 로그 | `sensor_log` | 365일 | 백업 후 기간 초과분 삭제(`retention_cleanup.php`) | | 온습도 측정 이력 | `sensor_metric` | 365일 | 기간 초과분 삭제 | | SMS 발송 로그 | `sms_log` | 365일 | 개인정보 최소화 후 기간 초과분 삭제 | | 관리자 감사로그 | `php/var/admin_audit.log` | 365일 | 기간 초과분 정리 | | 설정 비밀값 | `config.local.php`, `firmware/common/secrets.h`(`APP_API_KEY`, 미커밋) | 운영 중 | 담당자 변경 또는 유출 의심 시 즉시 교체 | 기관 내부 규정이 별도로 있으면 내부 규정을 우선 적용합니다. ### 3.6 백업·복구 기준 다음 항목을 `플랫폼/서비스 보안대책` 또는 별도 `백업 및 복구` 절에 추가합니다. - MySQL DB는 정기 백업을 수행하고 월 1회 이상 복구 가능 여부를 점검한다. - 서버 설정 파일 `config.local.php`는 별도 암호화 저장소에 보관한다. - 단말 비밀값 헤더 `firmware/common/secrets.h`(`APP_API_KEY`)는 저장소에 커밋하지 않고(.gitignore), 빌드 머신의 운영자만 접근 가능한 위치에 보관·백업한다. - 복구 훈련 시 API 연결, 측정값 수신, 임계 SMS 발송, 대시보드 로그인, 월간 보고서 조회를 함께 검증한다. ## 4. HWP에 삽입할 이미지 파일 ### 4.1 HWP 원본에서 추출한 이미지 다음 이미지는 HWP 내부 `BinData`에서 추출했습니다. BMP 스트림은 HWP 압축을 해제해 정상 이미지 파일로 저장했습니다. | 파일 | 용도 판단 | |---|---| | [bin0001.png](assets/security_plan/hwp_embedded/bin0001.png) | 기존 모니터링 시스템 구성도 | | [bin0002.png](assets/security_plan/hwp_embedded/bin0002.png) | 표지/타이틀 이미지 일부 | | [bin0003.png](assets/security_plan/hwp_embedded/bin0003.png) | 표지/타이틀 이미지 일부 | | [bin0004.png](assets/security_plan/hwp_embedded/bin0004.png) | 기관 슬로건 이미지 | | [bin0005.png](assets/security_plan/hwp_embedded/bin0005.png) | 기관 슬로건 이미지 | | [bin0006.png](assets/security_plan/hwp_embedded/bin0006.png) | 한국우편사업진흥원 로고 | > 기존 구성도 이미지(bin0001)는 과거 범위(화재/누수/카메라) 기준이므로, 아래 4.2의 온습도 구성도/흐름도로 교체하는 것을 권장합니다. ### 4.2 새로 생성한 보완 이미지 아래 이미지는 수정 HWP에 추가 삽입할 목적으로 생성합니다. 스크립트는 온습도 흐름으로 갱신되었으며 **PNG 재생성은 운영자가 수행**합니다. | 파일 | HWP 삽입 위치 | |---|---| | [security_plan_target_architecture.png](assets/security_plan/generated/security_plan_target_architecture.png) | `시스템 구성도` 절 | | [security_plan_data_flow.png](assets/security_plan/generated/security_plan_data_flow.png) | `데이터 흐름 및 보호조치` 신규 절 | | [security_plan_document_update_map.png](assets/security_plan/generated/security_plan_document_update_map.png) | 내부 검토용 또는 부록 | ## 5. 원본 HWP 문구 교체 예시 ### 5.1 사업목적 교체안 (추출본 L9) 기존 문구: > 전산실 내 화재, 누수, 장비 전원 이상 상태를 실시간으로 감지할 수 있는 IoT 기반 모니터링 체계를 구축 교체 문구: > 전산실(서버실) 내 온도·습도 이상 및 장비 통신 이상 상태를 실시간으로 감지하는 IoT 기반 모니터링 체계를 구축하고, 임계 초과 시 SMS 알림과 웹 대시보드를 통해 신속한 확인 및 환경 정상화 체계를 마련한다. 별도 센서를 이용한 화재·누수 감지는 향후 확장 범위로 별도 보안성 검토 및 통제대책 수립 후 반영한다. ### 5.2 구축방식 교체안 (추출본 L29) 기존 문구: > 전산실 내 설치된 화재·누수 감지센서가 이상상태를 감지하면, 해당 신호를 IoT 보드로 전달하고 IoT 보드가 감지정보를 수집·처리하여 웹호스팅 서버로 전송 교체 문구: > 전산실 내 설치된 SHT30 온습도 센서가 온도·습도를 주기적으로 측정하면 STM32 보드가 측정값을 수집하여 정상 보고를 구성한다. 단말은 기관 내부 업무망으로 인바운드 접속을 허용하지 않고, 승인된 Cafe24 웹호스팅 서버의 PHP API로 HTTPS/TLS 기반 아웃바운드 POST만 수행한다. 서버는 API 키 기반 서명과 측정값 범위를 검증한 후 운영 임계(고온/저온/고습/저습)로 재판정하여 MySQL에 저장하고, 임계 초과 시 담당자에게 SMS를 발송하며 대시보드와 월간 보고서를 제공한다. ### 5.3 사진정보 보호대책 절 교체안 (추출본 L102~L105) 기존 절(현장 사진 관련 L103·L104 행)은 **삭제**하고, 절 제목을 `개인정보 및 경보 오발송 방지 대책`으로 바꾼 뒤 아래로 대체합니다. 기존 문구: > 현장 사진은 화재·누수 등 이벤트 발생 확인 목적으로만 수집 / 사진정보는 웹호스팅 서버에 암호화 저장하거나 접근권한을 제한하여 관리, 보관기간은 최소한으로 설정 교체 문구: > 본 시스템은 현장 사진 등 시설정보를 수집·저장하지 않으며, 처리하는 개인정보는 SMS 수신자 휴대전화번호로 한정한다. 수신자 번호는 알림 발송 목적에 한하여 최소 수집·이용하고, 담당자 변경 시 즉시 현행화한다. 온습도 임계 경보는 동일 종류 30분 쿨다운과 복구 히스테리시스(온도 1.0℃, 습도 3.0%)를 적용하여 경계 채터링과 SMS 오발송을 방지한다. SMS 발송 이력(`sms_log`)은 장애 대응·감사 목적 범위에서만 열람하고, 보관기간 경과 시 삭제 또는 비식별 처리한다. ## 6. 추가 증적 목록 HWP 최종본 또는 부록에 다음 증적을 첨부하는 것을 권장합니다. - 서버 설치 경로 캡처 - `setup_wizard.php` 점검 통과 화면 - `security_evidence.php?format=md` 보안 증적 보고서 - `docs/evidence/security_plan_mfa_evidence.html` 관리자 MFA 및 운영 보안 보완 증빙 - 대시보드 정상/임계 경보/오프라인 상태 화면 - 테스트 SMS 수신 화면 - 월간 보고서 화면 - 관리자 감사로그 파일 존재 및 마스킹된 이벤트 일부 - DB 테이블 생성 또는 마이그레이션 적용 결과 - `php retention_cleanup.php --dry-run` 보관기간 정리 대상 확인 결과 - `php scripts/backup_evidence.php --backup-dir ...` 백업·복구 증빙 보고서 - 단말 STM32 USART3(PD8/PD9, 115200) 부팅 콘솔 로그(링크업/DHCP/SNTP/TLS 핸드셰이크) 캡처 - 단말 콘솔의 서버 200 OK 정상 POST 응답 로그 캡처 - `docs/SECURITY_EVIDENCE_PACKAGE.md` 기준 제출 패키지 목록 - `docs/OPERATIONS_SECURITY_CHECKLIST.md` 월간 점검표 - 운영 담당자 및 SMS 수신자 현행화 확인표 ## 7. 반영 순서 1. 원본 HWP의 사업범위를 현재 구현 범위(서버실 온습도 + 임계 SMS)에 맞게 수정한다. 2. 기존 구성도(화재/누수/카메라 기준)는 온습도 구성도(`security_plan_target_architecture.png`)와 흐름도(`security_plan_data_flow.png`)로 교체한다. 3. 관리적 보안대책에 보관기간, 개인정보 최소수집, 담당자 변경 절차를 추가한다. 4. 물리적 보안대책에서 카메라 문구를 삭제하고 STM32 보드·SHT30 센서 고정, 자산대장, 탈거 방지 항목을 구체화한다. 5. 기술적 보안대책에 API 서명, 환경파일 비밀값 분리, 측정값 범위 검증, 서버 임계 판정, 관리자 TOTP MFA, 감사로그, 로그/보관기간/백업 기준을 추가한다. 6. 사진정보 절을 삭제하고 개인정보 + 경보 오발송 방지 절로 대체한다. 임계 경보·오프라인 대응 절차와 설치 점검 절차를 신규 절로 추가한다. 7. 최종본 부록에 `security_evidence.php?format=md`, 단말 증적 보고서, 설치·검증 증적 목록을 첨부한다. 8. 법령·지침 명칭과 조문 번호는 제출 직전 최신 원문 기준으로 재확인한다. ## 8. 남은 확인 필요사항 | 확인 항목 | 이유 | |---|---| | 온습도 임계값의 기관 운영 기준 | 고온30/저온10℃·고습70/저습20%가 해당 서버실 운영 기준과 맞는지 확인 필요 | | 화재·누수 감지를 향후 확장 범위로 명시할지 | 현재 코드 기준으로는 온습도 모니터링 중심이므로 문서 범위 과대 기재 위험 | | Cafe24 서버에서 HTTPS 강제 적용 여부 | API와 관리자 페이지 보호 근거 | | 기관 경계 방화벽에서 허용할 목적지·포트 | 네트워크 구성도와 보안대책의 핵심 통제 | | `security_evidence.php` 실제 점검 결과의 실패 항목 | 실패 항목이 있으면 조치 결과 또는 예외 승인 근거 필요 | | DB 백업 주기와 복구 담당자 | 운영 단계 보안관리 증적 필요 | | 월간 점검 담당자와 점검 주기 | 보안대책 이행 여부 확인 근거 |