SHT30 온습도 모니터링 시스템 전체 소스(서버 PHP, STM32 펌웨어, SQL, 테스트). 전체 코드리뷰에서 도출된 보안 하드닝 10건 반영: - 요청 서명 HMAC-SHA256 전환(펌웨어 sig.c/서버 config.php/호스트 패리티 동시) - 재전송 방어 + 기본 API_KEY fail-closed + 디바이스 문자열 정제(api/sensor_data.php) - 오프라인 SMS 중복 발송 경합 제거(cron_heartbeat.php, 원자적 선점) - CSV 수식 주입 방지(monthly_report.php), 감사로그 회전 락(retention_cleanup.php) - 브루트포스 카운터 원자화(login.php), 예시 TOTP 비밀키 무효화, 마이그레이션 멱등화 _backup/(하드코딩 실 비밀값 포함)·config.local.php·런타임 상태는 .gitignore 제외.
388 lines
29 KiB
Markdown
388 lines
29 KiB
Markdown
# 보안대책서 통과 준비도 심화 보완안
|
|
|
|
검토 대상: `(Y수정)_(20260528)_IoT_기반_모니터링_체계_구축을_위한_보안대책서.hwp` (최신 리비전)
|
|
작성일: 2026-05-19
|
|
목적: 현재 HWP 보안대책서가 기관 보안성 검토 또는 국정원 검토 관점에서 설득력을 갖추도록, 수정해야 할 내용과 구체적 해결책을 제시한다.
|
|
|
|
## 1. 결론
|
|
|
|
현재 HWP는 **완벽하지 않습니다.**
|
|
현재 상태 그대로는 “국정원에 통과 가능한 수준”이라고 보기 어렵습니다.
|
|
|
|
이유는 보안대책의 큰 항목은 있으나, 심사자가 확인하려는 다음 질문에 대한 답이 부족하기 때문입니다.
|
|
|
|
1. 이 사업이 정말 보안성 검토 생략 또는 자체 보안대책 대상인지 근거가 명확한가?
|
|
2. 실제 구축 범위와 문서의 사업 범위가 일치하는가?
|
|
3. 기관 업무망과 IoT 장비·외부 웹호스팅 서버 사이의 경계가 명확한가?
|
|
4. 데이터가 어디서 생성되고, 어디로 이동하고, 어디에 저장되고, 누가 보는지 명확한가?
|
|
5. API 키, 관리자 계정, SMS 수신자 번호 같은 민감 요소를 어떻게 보호하는가?
|
|
6. 보안대책이 실제 시스템에서 구현되었고, 증적으로 확인 가능한가?
|
|
7. 온습도 임계 경보·미확인·장비 오프라인 상황에서 누가 무엇을 하는가?
|
|
8. 남은 위험을 기관이 알고 수용하거나 추가 조치하는가?
|
|
|
|
현재 문서는 **선언형 보안대책서**에 가깝습니다. 통과 가능성을 높이려면 **구현 기반 보안대책서 + 운영 증적 목록 + 잔여위험 수용표** 형태로 바꿔야 합니다.
|
|
|
|
## 2. 객관적 점수
|
|
|
|
| 평가 항목 | 현재 수준 | 보완 후 목표 |
|
|
|---|---:|---:|
|
|
| 사업 범위 명확성 | 55 | 90 |
|
|
| 네트워크/시스템 구성 명확성 | 60 | 90 |
|
|
| 관리적 보안대책 | 70 | 85 |
|
|
| 물리적 보안대책 | 70 | 85 |
|
|
| 기술적 보안대책 | 55 | 90 |
|
|
| 개인정보 보호(SMS 수신자) | 50 | 85 |
|
|
| 운영 절차/경보 대응 | 50 | 85 |
|
|
| 증적 준비도 | 35 | 85 |
|
|
| 전체 통과 준비도 | 55~60 | 80~85 |
|
|
|
|
## 3. 통과 리스크가 큰 차단 이슈
|
|
|
|
### 3.1 사업 범위 과대 기재
|
|
|
|
현재 HWP는 “화재, 누수, 장비 전원 이상”을 감지한다고 표현합니다. 그러나 현재 프로젝트 구현은 서버실 온습도(SHT30) 측정, 임계(고온/저온/고습/저습) SMS 경보, 정상복귀 SMS, 장비 오프라인/복구 감지, 대시보드 중심입니다.
|
|
|
|
**위험:**
|
|
문서가 실제 시스템보다 넓은 보안범위를 주장하면, 심사자는 화재 센서, 누수 센서, 전원 이상 감지, 해당 센서의 보안통제와 검증 증적을 요구할 수 있습니다.
|
|
|
|
**해결책:**
|
|
HWP 본문에서 1차 구축 범위를 다음처럼 명확히 제한합니다.
|
|
|
|
> 본 사업의 1차 구축 범위는 전산실(서버실) 내 온습도 모니터링, 임계 초과 시 SMS 경보, 정상복귀 알림, 장비 통신 이상 감지, 웹 대시보드 및 월간 운영 보고 체계 구축으로 한정한다. 화재·누수 감지 및 장비 전원 이상 감지는 향후 센서 추가 연계 시 별도 보안성 검토 또는 자체 보안대책 보완 후 반영한다.
|
|
|
|
### 3.2 보안성 검토 생략 사유의 불충분
|
|
|
|
HWP는 국가 정보보안 기본지침 제16조를 인용하지만, 왜 이 사업이 생략 대상인지에 대한 연결 논리가 약합니다.
|
|
|
|
**위험:**
|
|
기관 내부망, 외부 웹서버, SMS 개인정보가 포함되면 단순 장비 도입으로 보기 어렵다는 지적을 받을 수 있습니다.
|
|
|
|
**해결책:**
|
|
HWP에는 “검토 생략”을 단정하지 말고 아래 중 하나로 정리해야 합니다.
|
|
|
|
| 선택지 | 사용 조건 | 문서 표현 |
|
|
|---|---|---|
|
|
| A. 자체 보안대책 수립 | 기관 보안담당자가 자체 검토 가능하다고 판단한 경우 | “본 사업은 기관 보안담당 부서의 판단에 따라 자체 보안대책을 수립·시행하고, 필요 시 상급기관 또는 국가정보원 보안성 검토 대상 여부를 확인한다.” |
|
|
| B. 보안성 검토 의뢰 | 외부망 연계 성격이 크다고 판단한 경우 | “본 사업은 정보통신망 구성 및 외부 연계가 포함되므로 사업계획 단계에서 보안성 검토 대상 여부를 확인하고, 필요 시 보안성 검토를 의뢰한다.” |
|
|
| C. 검토 생략 | 기존 검토 완료 사업의 망 구성 변경 없는 후속 운영 등으로 명확한 경우 | “기존 보안성 검토 결과를 준수하며, 정보통신망 구성을 변경하지 않는 범위에서 후속 운영으로 수행한다.” |
|
|
|
|
**권장:**
|
|
현재 구조는 외부 웹호스팅, IoT 단말, SMS를 포함하므로 **“검토 생략” 단정은 위험**합니다. 최소한 “보안성 검토 대상 여부를 기관 보안담당 부서와 사전 확인” 문구를 넣어야 합니다.
|
|
|
|
### 3.3 외부 웹호스팅 사용의 보안 근거 부족
|
|
|
|
Cafe24 웹호스팅 서버가 기관 내부망 밖에 있으므로 신뢰 경계가 큽니다.
|
|
|
|
**위험:**
|
|
심사자는 “왜 기관 내부 서버가 아닌 외부 호스팅인가”, “기관 업무망과 어떤 방식으로 분리되는가”, “외부 서버 침해 시 기관에 영향이 없는가”를 물을 수 있습니다.
|
|
|
|
**해결책:**
|
|
외부 웹호스팅 사용 사유와 통제 기준을 문서화합니다.
|
|
|
|
HWP 추가 문구:
|
|
|
|
> 웹호스팅 서버는 기관 내부 업무망과 분리된 인터넷 영역에 위치하며, IoT 단말은 기관 업무망으로의 접속 권한을 갖지 않는다. IoT 단말은 승인된 웹호스팅 서버 API로 HTTPS 기반 아웃바운드 통신만 수행하고, 기관 내부망으로부터의 인바운드 접속이나 원격제어 경로는 구성하지 않는다. 웹호스팅 서버에는 업무자료를 저장하지 않으며, 온습도 측정 이력, 임계 경보·SMS 발송 이력 등 운영 목적상 필요한 최소 정보만 저장한다.
|
|
|
|
## 4. HWP에 반드시 추가해야 할 보안통제 매트릭스
|
|
|
|
아래 표는 “관리적/물리적/기술적 대책”을 심사자가 확인 가능한 구조로 바꾼 것입니다. HWP에 그대로 표로 넣는 것을 권장합니다.
|
|
|
|
이 표를 채우기 위해 사용자가 제공해야 하는 자료는 [SECURITY_PLAN_ATTACHMENT_GUIDE.md](SECURITY_PLAN_ATTACHMENT_GUIDE.md)에 정리했습니다.
|
|
소스코드에서 확인 가능한 API·인증·업로드 검증 근거는 [SOURCE_SECURITY_EVIDENCE.md](SOURCE_SECURITY_EVIDENCE.md)에 정리했습니다.
|
|
운영 서버 반영 후에는 `php/security_evidence.php?format=md`에서 아래 매트릭스의 코드 기반 증적을 Markdown으로 내려받고, STM32 단말에서는 USART3(PD8/PD9, 115200) 부팅 콘솔 로그(링크업/DHCP/SNTP/TLS/서버 200)를 캡처해 장비 증적으로 사용합니다. 제출 패키지 순서는 [SECURITY_EVIDENCE_PACKAGE.md](SECURITY_EVIDENCE_PACKAGE.md)를 기준으로 정리합니다.
|
|
|
|
| 영역 | 위험 | 보안대책 | 구현 위치 | 확인 증적 |
|
|
|---|---|---|---|---|
|
|
| 사업 범위 | 문서 범위와 실제 구현 불일치 | 1차 구축 범위를 온습도·임계 SMS·오프라인·대시보드로 한정 | 보안대책서 사업개요 | 범위 정의 문구 |
|
|
| 네트워크 | 단말이 기관망 침해 경로가 될 위험 | 단말 인바운드 차단, 서버로 HTTPS 아웃바운드만 허용 | STM32 펌웨어, 기관 방화벽 | 방화벽 정책, STM32 USART3 콘솔 로그(아웃바운드 HTTPS만 수행 확인) |
|
|
| 전송구간 | 센서 데이터 탈취·변조 | HTTPS/TLS 사용, API 서명 검증 | `sensor_data.php`, 단말 펌웨어 | 실제 HTTPS 화면, `security_evidence.php?format=md` |
|
|
| API 인증 | 임의 측정값 주입 | 공유 API 키와 요청 서명 검증 | PHP API, `firmware/common/secrets.h`(`APP_API_KEY`) | 403 테스트 결과, 보안 증적 보고서 |
|
|
| 측정값 검증 | 비정상 측정값 저장 | 필수 필드·측정값 범위(온도 -40~125℃ / 습도 0~100%) 검증 | `sensor_data.php` | 비정상 요청 차단 테스트 결과 |
|
|
| 임계 경보 | 오발송·미발송 | 서버 임계 판정(`METRIC_*`), 30분 쿨다운, 복구 히스테리시스 | `config.php`, `sensor_data.php` | `sms_log`, `sensor_metric` 상태 |
|
|
| 비밀값 | DB/SMS/API 키 유출 | 서버는 `config.local.php`, STM32 단말은 `firmware/common/secrets.h`(`APP_API_KEY`)로 분리, 저장소 미포함(.gitignore) | 서버/단말 설정 | STM32 콘솔 로그, .gitignore 설정, 저장소 검색 결과 |
|
|
| 관리자 인증 | 대시보드 무단 접근 | 비밀번호 해시, TOTP MFA, 세션 쿠키 보호, 로그인 실패 제한, 감사로그 | `login.php`, `setup_mfa.php`, `admin_security.php`, `dashboard.php`, `security_evidence.php` | 로그인 화면, MFA 등록 증빙, 감사로그, 보안 증적 보고서 |
|
|
| 개인정보 | SMS 수신자 번호 노출 | 최소 수집, 담당자 변경 시 현행화, 로그 접근 제한 | `config.local.php`, `sms_log` | 수신자 목록 관리대장 |
|
|
| 로그관리 | 추적 불가 | 센서/측정/SMS 로그와 관리자 감사로그 저장, 보관기간 정리 | MySQL, `php/var/admin_audit.log`, `retention_cleanup.php` | 월간 보고서, 단말 증적 보고서, 감사로그, retention dry-run 결과 |
|
|
| 백업 | 장애 시 복구 불가 | DB·설정 파일 백업, 복구 점검, 백업 증빙 생성 | 운영 절차, `scripts/backup_evidence.php` | 백업 이력, 복구 테스트 결과, backup-evidence 보고서 |
|
|
| 패치 | 취약한 OS/PHP 사용 | 단말 OS, PHP, DB 정기 업데이트 | 운영 절차 | `OPERATIONS_SECURITY_CHECKLIST.md`, 월간 점검표 |
|
|
| 물리보안 | 센서/보드 탈거·조작 | 서버실 통제구역 설치, 함체 고정, 자산대장 등록 | 서버실 | 설치 사진, 자산대장 |
|
|
| 장애대응 | 경보 미확인/오프라인 방치 | 미확인 경보 재알림, 장비 오프라인 감지 | `cron_heartbeat.php` | SMS 로그, 오프라인 이력 |
|
|
|
|
## 5. 기술적 보안대책 상세 보완 문구
|
|
|
|
### 5.1 API 인증 및 무결성
|
|
|
|
HWP에 아래 문구를 추가합니다.
|
|
|
|
> IoT 단말과 서버 간 API 호출은 HTTPS/TLS 통신을 기본으로 하며, 요청 본문에는 장비 ID, 센서 ID, 이벤트 유형, 온도/습도 측정값, 타임스탬프를 포함한다. 서버는 사전에 등록된 API 키를 기반으로 요청 서명을 검증하고, 서명 불일치 또는 API 키 불일치 요청은 저장하지 않고 거부한다. 이를 통해 임의의 외부 사용자가 허위 측정값이나 경보를 주입하는 위험을 낮춘다.
|
|
|
|
확인 증적:
|
|
|
|
- 정상 API 호출 결과
|
|
- API 키 불일치 시 403 거부 결과
|
|
- PHP API 코드 또는 테스트 로그
|
|
|
|
### 5.2 측정값 검증 및 서버 임계 판정
|
|
|
|
> 센서 데이터 API는 POST JSON 요청과 필수 필드(장비 ID·센서 ID·이벤트 유형·타임스탬프)를 검증하고, 온도(-40~125℃)·습도(0~100%) 범위를 벗어난 값은 무효 처리한다. 임계 판정은 펌웨어가 아니라 서버 `config.php`의 운영 임계(`METRIC_*`: 고온30/저온10℃, 고습70/저습20%)로 재수행하여 `sensor_metric`에 상태를 기록한다. 동일 종류 경보는 30분 쿨다운, 복구는 히스테리시스(온도 1.0℃, 습도 3.0%)를 적용하여 SMS 오발송을 방지한다.
|
|
|
|
확인 증적:
|
|
|
|
- 정상 측정값 저장 결과(`sensor_metric`)
|
|
- 비정상 메소드/필드 누락/범위 초과 차단 결과
|
|
- 임계 초과 시 종류별 SMS, 회복 시 정상복귀 SMS 발송 이력(`sms_log`)
|
|
|
|
### 5.3 관리자 페이지 접근통제
|
|
|
|
> 웹 대시보드, 설치 점검, 월간 보고서 등 관리자 기능은 로그인된 관리자 세션에서만 접근 가능하도록 구성한다. 관리자 비밀번호는 평문으로 저장하지 않고 `password_hash` 기반 해시값으로 저장하며, 비밀번호 검증 후 Google Authenticator 등 표준 TOTP 인증 앱의 6자리 일회용 코드를 추가로 검증한다. 세션 쿠키는 HttpOnly, Secure, SameSite 속성을 적용하고, 로그인 성공·실패, 로그아웃, MFA 등록 검증 이벤트는 관리자 감사로그에 기록한다. 관리자 권한은 운영 담당자에게만 부여하고 담당자 변경 시 비밀번호와 TOTP 비밀키를 모두 교체한다.
|
|
|
|
> 최초 MFA 등록 또는 담당자 교체 시에는 임시 `MFA_SETUP_TOKEN`으로 `setup_mfa.php`에 접근하여 Base32 수동 입력 키 또는 `otpauth://` URI를 인증 앱에 등록한다. 등록 화면은 외부 Google API 또는 외부 QR 생성 API로 비밀키를 전송하지 않으며, 등록 완료 후 `ADMIN_TOTP_SECRET`을 운영 설정에 반영하고 `MFA_SETUP_TOKEN`은 삭제 또는 빈 값으로 변경한다.
|
|
|
|
추가 권장 구현:
|
|
|
|
- 로그인 실패 횟수 제한
|
|
- 관리자 접속 IP 제한. Cafe24 웹호스팅 등에서 IP 제한 적용이 어렵다면 MFA, 강한 비밀번호, 실패 제한, 감사로그 월간 점검으로 보완
|
|
- HTTPS 강제 리다이렉트
|
|
- 세션 유휴시간 만료
|
|
|
|
### 5.4 비밀값 관리
|
|
|
|
> DB 계정, API 키, SMS 인증키, 관리자 비밀번호 해시는 소스 코드에 직접 저장하지 않는다. 서버는 `config.local.php` 또는 환경변수에서 운영 비밀값을 읽고, STM32 단말은 `firmware/common/secrets.h`의 `APP_API_KEY`(컴파일 타임 고정)를 사용한다. 해당 파일은 저장소에 커밋하지 않고(.gitignore) 빌드 머신에만 보관하며, 문서·공유폴더에 업로드하지 않는다.
|
|
|
|
권장 파일 권한:
|
|
|
|
```text
|
|
서버 config.local.php: 웹서버 계정만 읽기 가능
|
|
STM32 단말 firmware/common/secrets.h: 저장소 미커밋(.gitignore), 빌드 머신에서만 보관
|
|
```
|
|
|
|
### 5.5 장비 오프라인 감지
|
|
|
|
> IoT 단말은 주기적으로 정상 상태를 서버에 보고하며, 서버는 마지막 보고 시각을 기준으로 장비 오프라인 상태를 판정한다. 일정 시간 이상 보고가 없으면 SMS를 통해 담당자에게 장비 이상을 통지하고, 대시보드에 오프라인 상태를 표시한다.
|
|
|
|
확인 증적:
|
|
|
|
- `sensor_status` 마지막 보고 시각
|
|
- `cron_heartbeat.php` 실행 로그
|
|
- 오프라인 SMS 발송 이력
|
|
|
|
## 6. 관리적 보안대책 상세 보완 문구
|
|
|
|
### 6.1 운영 책임과 RACI
|
|
|
|
HWP에 아래 책임표를 추가합니다.
|
|
|
|
| 업무 | 정보기반팀 | 우편혁신AI연구팀 | 정보보안센터 | 운영 담당자 |
|
|
|---|---|---|---|---|
|
|
| 보안대책서 승인 | A | R | C | I |
|
|
| 서버 계정 및 DB 관리 | R | C | C | I |
|
|
| 단말 장비 설치·교체 | C | R | C | I |
|
|
| 보안 점검 | C | I | A/R | C |
|
|
| SMS 수신자 현행화 | C | R | C | A/R |
|
|
| 경보 대응 기록 | C | C | I | A/R |
|
|
| 백업·복구 점검 | A/R | C | C | I |
|
|
|
|
범례:
|
|
|
|
- R: 수행
|
|
- A: 최종 책임
|
|
- C: 협의
|
|
- I: 통보
|
|
|
|
### 6.2 월간 보안점검 항목
|
|
|
|
| 점검 항목 | 주기 | 기준 | 증적 |
|
|
|---|---:|---|---|
|
|
| 대시보드 로그인 계정 확인 | 월 1회 | 불필요 계정 없음 | 계정 점검표 |
|
|
| 관리자 MFA 설정 확인 | 월 1회 | `ADMIN_TOTP_SECRET` 설정 및 인증 앱 등록 완료 | MFA 등록 확인표 |
|
|
| 관리자 감사로그 확인 | 월 1회 | 로그인 실패, 설정 변경 이상 없음 | `php/var/admin_audit.log` |
|
|
| SMS 수신자 확인 | 월 1회 | 현 담당자 번호만 등록 | 수신자 목록 |
|
|
| 단말 동작 상태 | 월 1회 | 주기 보고·서버 200 정상 | STM32 USART3 콘솔 로그 |
|
|
| 최근 오프라인 이벤트 | 월 1회 | 반복 장애 없음 | 대시보드 캡처 |
|
|
| 임계 설정 확인 | 월 1회 | `METRIC_*` 운영 기준과 일치 | 설치 점검 화면 |
|
|
| 측정 이력 용량 | 월 1회 | 보관기간 초과분 없음 | retention dry-run |
|
|
| DB 백업 | 월 1회 이상 | 백업 생성 및 복구 가능 | 백업 파일, 복구 테스트 |
|
|
| 보안 패치 | 월 1회 | OS/PHP/Python 업데이트 확인 | 패치 점검표 |
|
|
| API 키 변경 필요성 | 분기 1회 | 유출 의심 없음 | 점검 결과 |
|
|
|
|
### 6.3 보관기간과 파기
|
|
|
|
| 데이터 | 개인정보/민감도 | 보관기간 권장 | 파기 방법 |
|
|
|---|---|---:|---|
|
|
| SMS 수신자 번호 | 개인정보 | 담당자 재직/업무 담당 기간 | 담당자 변경 즉시 삭제·수정 |
|
|
| SMS 발송 로그 | 개인정보 포함 가능 | 1년 | DB 삭제 또는 비식별 처리 |
|
|
| 온습도 측정 이력 | 운영 데이터 | 1년 | 기간 초과 DB 삭제(`sensor_metric`) |
|
|
| 센서 로그 | 운영 로그 | 1년 | 기간 초과 DB 삭제 |
|
|
| 관리자 감사로그 | 감사/운영 이력 | 1년 | 기간 초과분 정리 |
|
|
| API 키/SMS 인증키 | 인증정보 | 운영 중 | 교체 후 구 키 폐기 |
|
|
|
|
기관 내부 개인정보·기록물 관리 기준이 더 엄격하면 내부 기준을 우선 적용합니다.
|
|
|
|
## 7. 물리적 보안대책 상세 보완 문구
|
|
|
|
> STM32 보드와 SHT30 온습도 센서는 서버실 내 지정 위치에 고정 설치하고, 임의 탈거 또는 포트 접근이 어렵도록 함체 또는 보호 케이스에 수용한다. 장비에는 자산번호를 부여하고 모델명, 일련번호, MAC 주소, 설치 위치, 설치일, 관리 담당자를 자산대장에 기록한다. 장비 점검·교체 시에는 사전 승인된 작업자만 출입하고 작업 완료 후 설치 상태와 센서 동작을 확인한다.
|
|
|
|
추가 증적:
|
|
|
|
- 설치 위치 사진
|
|
- 자산관리대장
|
|
- 출입기록
|
|
- 장비 점검표
|
|
- 센서 측정 테스트 결과
|
|
|
|
## 8. 네트워크 보안대책 상세 보완
|
|
|
|
### 8.1 권장 네트워크 설명
|
|
|
|
> IoT 단말은 기관 내부 업무망에 접속하지 않고, 별도 인터넷 연결 또는 분리된 IoT 통신 경로를 사용한다. 기관 경계 방화벽에서는 승인된 Cafe24 웹호스팅 서버의 HTTPS 포트로 향하는 통신만 허용하고, IoT 단말로 들어오는 외부 접속은 허용하지 않는다.
|
|
|
|
### 8.2 네트워크 정책표
|
|
|
|
| 출발지 | 목적지 | 포트 | 방향 | 허용 사유 | 통제 |
|
|
|---|---|---:|---|---|---|
|
|
| STM32 단말 | Cafe24 PHP API | TCP 443 | Outbound | 온습도 측정값 전송 | 목적지 도메인/IP 제한 |
|
|
| 운영자 PC | Cafe24 대시보드 | TCP 443 | Outbound | 상태 확인/경보 처리 | 관리자 인증 |
|
|
| Cafe24 서버 | Cafe24 SMS API | TCP 443 | Outbound | SMS 발송 | SMS 계정 인증 |
|
|
| 외부 인터넷 | STM32 단말 | - | Inbound | 불필요 | 차단 |
|
|
| STM32 단말 | 기관 업무망 | - | Any | 불필요 | 차단 |
|
|
|
|
### 8.3 심사 대응 포인트
|
|
|
|
심사자 질문:
|
|
|
|
> IoT 장비가 침해되면 기관 내부망으로 들어올 수 있습니까?
|
|
|
|
권장 답변:
|
|
|
|
> 본 구성에서 STM32 단말은 기관 내부 업무망과 라우팅되지 않으며, 서버 API로 아웃바운드 HTTPS POST만 수행한다. 단말에 대한 외부 인바운드 접속은 허용하지 않고, 원격관리가 필요한 경우 현장 접속 또는 승인된 관리 절차를 따른다.
|
|
|
|
## 9. 개인정보 영향 보완
|
|
|
|
이 시스템은 주민등록번호 등 고유식별정보를 처리하지 않으며, 현장 사진 등 시설정보도 수집하지 않습니다. 처리하는 개인정보는 SMS 수신자 휴대전화번호로 한정되므로, 해당 개인정보 보호대책과 경보 오발송 방지 대책을 별도 항목으로 분리합니다.
|
|
|
|
### 9.1 처리 정보 목록
|
|
|
|
| 정보 | 예시 | 목적 | 접근자 | 저장 위치 |
|
|
|---|---|---|---|---|
|
|
| 담당자 휴대전화번호 | SMS 수신자 번호 | 이상상태 알림 | 운영 관리자 | `config.local.php`, `sms_log` |
|
|
| 온습도 측정값 | 온도, 습도, 시각, 임계 상태 | 환경 모니터링 | 운영 관리자 | `sensor_metric`, MySQL |
|
|
| 센서 이벤트 | 센서 ID, 상태, 시각 | 장애 감지 | 운영 관리자 | `sensor_log`, MySQL |
|
|
| 관리자 계정 | 관리자 ID, 비밀번호 해시, TOTP 비밀키 | 대시보드 접근 | 운영 관리자 | `config.local.php`, `php/var/admin_audit.log` |
|
|
| 장비 식별자 | Device ID, 위치명 | 장비 관리 | 운영 관리자 | 단말 설정, DB |
|
|
|
|
### 9.2 개인정보 보호 문구
|
|
|
|
> SMS 수신자 휴대전화번호는 이상상태 알림 발송 목적에 한해 최소한으로 수집·이용한다. 담당자 변경, 전보, 퇴직, 업무 변경 시 수신자 목록을 즉시 현행화하며, 불필요한 번호는 삭제한다. SMS 발송 로그는 장애 대응 및 감사 목적 범위에서만 열람하고, 보관기간 경과 시 삭제 또는 비식별 처리한다.
|
|
|
|
### 9.3 경보 오발송 방지 문구
|
|
|
|
> 본 시스템은 현장 사진 등 시설정보를 수집·저장하지 않는다. 온습도 임계 경보는 서버에서 운영 임계(`METRIC_*`)로 판정하며, 동일 종류 경보는 30분 쿨다운, 정상복귀 판정은 히스테리시스(온도 1.0℃, 습도 3.0%)를 적용하여 경계 채터링과 SMS 오발송을 방지한다. 임계 초과·정상복귀·장비 오프라인·복구 이력은 `sms_log`에 기록하며, 보관기간 경과 시 정리한다.
|
|
|
|
## 10. 보안성 검토 제출 관점의 필수 첨부물
|
|
|
|
공개 안내 기준으로 보안성 검토 요청에는 사업 개요, 사업계획서, 제안요청서, 정보통신망 구성도, 체크리스트, 자체 보안대책 등이 요구되는 경우가 있습니다. 현재 HWP에는 일부만 있으므로 아래 부록을 추가해야 합니다.
|
|
|
|
| 첨부물 | 현재 준비 상태 | 보완 필요 |
|
|
|---|---|---|
|
|
| 정보화사업 개요 | 있음 | 실제 구축 범위 정정 |
|
|
| 사업계획서 요약 | 일부 있음 | 일정, 운영주체, 범위 명확화 |
|
|
| 정보통신망 구성도 | 있음 | 업무망 분리, 외부 호스팅, 포트 정책 추가 |
|
|
| 시스템 구성도 | 있음 | 실제 파일/서버/DB/SMS 구성 반영 |
|
|
| 보안성 검토 체크리스트 | 없음 | 자체 점검표 추가 |
|
|
| 자체 보안대책 | 있음 | 구현·증적 기반으로 구체화 |
|
|
| 개인정보 처리표 | 부족 | 처리항목, 보관기간, 접근자 추가 |
|
|
| 운영·장애 대응 절차 | 부족 | 임계 경보/오프라인/미확인 대응 절차 추가 |
|
|
| 보안 증적 보고서 | 생성 가능 | `php/security_evidence.php?format=md` 결과 첨부 |
|
|
| 단말 운영 증적 | 생성 가능 | STM32 USART3 부팅 콘솔 로그(링크업/DHCP/SNTP/TLS/서버 200) 캡처 첨부 |
|
|
| 설치·검증 증적 | 없음 | 화면 캡처와 테스트 로그 첨부 |
|
|
|
|
## 11. 자체 보안점검 체크리스트
|
|
|
|
HWP 부록에 아래 체크리스트를 넣습니다.
|
|
|
|
| 번호 | 점검 항목 | 기준 | 결과 | 증적 |
|
|
|---:|---|---|---|---|
|
|
| 1 | 사업 범위가 실제 구현과 일치하는가 | 온습도/임계 SMS/오프라인 중심으로 명시 | | |
|
|
| 2 | 업무망과 IoT 구간이 분리되어 있는가 | 단말에서 업무망 접근 없음 | | |
|
|
| 3 | API 통신이 HTTPS인가 | `https://` URL 사용 | | |
|
|
| 4 | API 키와 서명 검증이 적용되었는가 | 비정상 키 403 거부 | | |
|
|
| 5 | 비밀값이 코드에 하드코딩되어 있지 않은가 | `config.local.php`, env 사용 | | |
|
|
| 6 | 관리자 비밀번호가 해시로 저장되는가 | `password_hash` 사용 | | |
|
|
| 7 | 대시보드 접근에 로그인과 MFA가 필요한가 | 미로그인 접근 차단, TOTP 6자리 코드 검증 | | |
|
|
| 8 | 측정값 범위 검증이 있는가 | 온도 -40~125℃ / 습도 0~100% 범위 검증 | | |
|
|
| 9 | 서버 임계 판정·쿨다운이 동작하는가 | `METRIC_*` 임계, 30분 쿨다운, 복구 히스테리시스 | | |
|
|
| 10 | SMS 수신자가 최신인가 | 현 담당자 번호만 존재 | | |
|
|
| 11 | 장비 오프라인 감지가 동작하는가 | heartbeat 기준 알림 | | |
|
|
| 12 | DB 백업과 복구 점검을 수행했는가 | 복구 테스트 완료 | | |
|
|
| 13 | 단말이 부팅 후 자동 보고를 시작하는가 | 전원 인가 시 startup 보고·주기 보고 동작 | | |
|
|
| 14 | 온습도 측정·저장이 검증되었는가 | `sensor_metric` 측정 이력 저장 | | |
|
|
| 15 | 월간 보고서가 생성되는가 | 월별 조회/CSV 가능 | | |
|
|
| 16 | 관리자 감사로그가 남는가 | 로그인 성공/실패, 로그아웃 기록 | | |
|
|
| 17 | 보관기간 정리 절차가 있는가 | `retention_cleanup.php --dry-run` 결과 확인 | | |
|
|
| 18 | 백업 증빙을 생성했는가 | `scripts/backup_evidence.php` 결과 첨부 | | |
|
|
|
|
## 12. HWP에 넣을 “보안대책 이행 증적” 부록 문구
|
|
|
|
> 본 사업은 보안대책의 이행 여부를 확인하기 위해 구축 완료 시 다음 증적을 보관한다. 증적은 사업 산출물 또는 운영 인수인계 자료로 관리하며, 보안담당 부서 요청 시 제출한다.
|
|
|
|
| 증적 | 확인 내용 |
|
|
|---|---|
|
|
| 설치 점검 화면 캡처 | DB, 테이블, 권한, SMS, API 키 설정 확인 |
|
|
| 보안 증적 Markdown | 운영 점검 결과와 보안통제 매트릭스 확인 |
|
|
| MFA 등록 증빙 | 관리자 TOTP 등록 절차와 임시 토큰 제거 기준 확인 |
|
|
| 대시보드 화면 캡처 | 온습도 상태, 임계 경보, 오프라인 현황 확인 |
|
|
| 월간 보고서 화면 캡처 | 경보 처리 및 SMS/온습도 현황 확인 |
|
|
| API 정상/비정상 테스트 로그 | 정상 요청 저장, 비정상 키 거부 확인 |
|
|
| 테스트 SMS 수신 화면 | 담당자 알림 경로 확인 |
|
|
| 측정값 저장 결과 | `sensor_metric` 기록 및 임계 상태 확인 |
|
|
| 임계 경보/복구 SMS 결과 | 종류별 경보·정상복귀 SMS 발송(`sms_log`) 확인 |
|
|
| 관리자 감사로그 | 로그인 성공/실패, 로그아웃 기록 확인 |
|
|
| 보관기간 정리 dry-run | 측정/로그/감사로그 정리 대상 확인 |
|
|
| 백업·복구 증빙 보고서 | 백업 파일 목록, 설정/감사로그 존재, 복구 테스트 결과 |
|
|
| 단말 증적(USART3 콘솔 로그) | 부팅 자동 보고, 링크업/DHCP/SNTP/TLS 핸드셰이크, 서버 200 OK 확인 |
|
|
| DB 마이그레이션 결과 | 필수 테이블과 컬럼 생성 확인 |
|
|
| 자산관리대장 | STM32 보드, SHT30 센서 등록 확인 |
|
|
| 백업/복구 점검표 | 장애 시 복구 가능성 확인 |
|
|
|
|
## 13. 잔여위험 및 수용 방안
|
|
|
|
보안대책서에는 모든 위험이 제거된 것처럼 쓰면 안 됩니다. 남은 위험과 수용 또는 보완 계획을 명시하는 편이 더 신뢰도가 높습니다.
|
|
|
|
| 잔여위험 | 영향 | 현재 통제 | 추가 조치 |
|
|
|---|---|---|---|
|
|
| 외부 웹호스팅 서버 침해 | 측정·로그 노출 가능 | 관리자 MFA, API 검증, 최소정보 저장 | 정기 백업, 감사로그 점검 |
|
|
| 단말 장비 물리 탈취 | API 키 노출 가능 | 서버실 출입통제, 환경파일 권한 | 키 주기 교체, 장비 함체 잠금 |
|
|
| SMS 계정 유출 | 오발송·비용 발생 | 설정파일 분리, 30분 쿨다운 | SMS 계정 비밀번호 주기 변경, 발송량 모니터링 |
|
|
| 임계 오판정 | 불필요 경보 또는 누락 | 서버 임계 판정, 복구 히스테리시스 | 운영 기준에 맞춘 `METRIC_*` 주기 점검 |
|
|
| 오프라인 감지 실패 | 환경 감시 공백 | heartbeat 감지 | 월간 서비스 상태 점검 |
|
|
| 단일 서버 장애 | 대시보드/알림 중단 | Cafe24 운영 | 백업, 복구 절차, 대체 알림 절차 |
|
|
|
|
## 14. 최우선 수정 순서
|
|
|
|
1. **사업 범위 정정**: 화재/누수/전원 이상을 현재 구축 범위에서 제외하거나 향후 확장으로 분리하고 온습도 모니터링으로 명시한다.
|
|
2. **검토 생략 표현 완화**: 국정원 통과를 확정하듯 쓰지 말고 보안성 검토 대상 여부 확인 문구를 넣는다.
|
|
3. **네트워크 구성도 보강**: 단말 아웃바운드 HTTPS, 기관 업무망 분리, 외부 웹호스팅 경계를 표시한다.
|
|
4. **기술대책 구체화**: API 서명, 비밀값 분리, 관리자 인증, 측정값 범위 검증, 서버 임계 판정을 구현 기반으로 쓴다.
|
|
5. **개인정보 처리표 추가**: SMS 번호의 목적, 접근자, 보관기간을 명시한다(현장 사진 항목 없음).
|
|
6. **운영 절차 추가**: 임계 경보, 미확인, 오프라인, 정상복귀 흐름을 넣는다.
|
|
7. **증적 부록 추가**: `security_evidence.php?format=md`, 단말 증적 보고서, 설치 점검, 테스트 SMS, DB, 측정값 저장, 대시보드 캡처를 첨부한다.
|
|
8. **잔여위험 표 추가**: 외부 호스팅, 단말 탈취, 임계 오판정, 단일 서버 장애 위험을 수용/보완 계획과 함께 쓴다.
|
|
|
|
### 14.1 최종 제출 전 운영자가 제공해야 할 자료
|
|
|
|
아래 항목은 코드나 문서만으로 확정할 수 없으므로 운영자가 실제 환경 기준으로 제공해야 합니다.
|
|
|
|
1. 실제 서버 도메인과 HTTPS 접속 화면, 인증서 정보
|
|
2. 단말 네트워크 분리 또는 방화벽 정책 확인 자료
|
|
3. STM32 보드, SHT30 센서 설치 위치 사진과 자산 정보
|
|
4. DB, 설정파일 백업 주기와 담당자
|
|
5. SMS 수신자 현행화 확인표
|
|
|
|
## 15. 참고한 공개 자료
|
|
|
|
- 국가정보원 보안적합성 검증 안내: https://www.nis.go.kr/AF/1_7_2_1.do
|
|
- 국가정보원 보안적합성 검증 FAQ: https://www.nis.go.kr/AF/1_7_2_5.do
|
|
- 울산광역시교육청 보안성 검토 안내: https://use.go.kr/www/eduinfo/protect/security/security03.jsp
|
|
- 개인정보보호위원회 개인정보 포털, 안전성 확보조치 관련 안내: https://www.privacy.go.kr/per/his/impactAssessmentItemPopup.do?itemCd=ITEMCD00000000000375
|
|
|
|
주의: 국가 정보보안 기본지침 원문과 기관 내부 보안업무 지침은 제출 직전 보안담당 부서가 최신본으로 재확인해야 합니다.
|