90f121e14c
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 제외.
193 lines
9.2 KiB
Markdown
193 lines
9.2 KiB
Markdown
# 누수감지 시스템 운영·보안 완성형 개선 요구사항
|
|
|
|
> 참고: 이 문서는 누수감지 시절의 기록(레거시)이며, 현재 시스템은 SHT30 온습도 전용으로 전환되었습니다.
|
|
|
|
작성일: 2026-05-20
|
|
상태: 사용자 승인 방향 기반 초안
|
|
대상 프로젝트: `leak_sms_v2` v2605
|
|
|
|
## 1. 배경
|
|
|
|
현재 프로젝트는 누수 감지, Raspberry Pi 전송, Cafe24 PHP API, MySQL 저장, SMS 알림, 사진 업로드, 대시보드, 사고 대응, 월간 보고서까지 기본 운영 흐름을 갖췄다.
|
|
|
|
다음 개선의 목표는 기능을 무작정 확장하는 것이 아니라, **제출 가능한 보안대책서와 현장 운영 가능한 시스템**으로 완성도를 올리는 것이다. 화재 감지, 전원 이상, 다중 지점 같은 확장은 지금 바로 구현하지 않고 향후 확장 범위로 분리한다.
|
|
|
|
## 2. 목표
|
|
|
|
1. 보안성 검토 또는 기관 보안검토에 대응할 수 있는 제출 패키지를 만든다.
|
|
2. 실제 현장 운영 중 실패할 수 있는 지점(API, SMS, 카메라, Pi, DB)을 더 잘 드러내고 대응 가능하게 만든다.
|
|
3. 운영자가 대시보드와 보고서에서 현재 위험, 미확인 사고, 사진, SMS 실패, 장비 상태를 빠르게 판단하게 한다.
|
|
4. 설치·운영·보안 증적을 수동 설명이 아니라 시스템과 문서에서 뽑을 수 있게 한다.
|
|
5. 향후 화재/전원/다중 Pi 확장을 위해 문서상 경계와 재검토 조건을 정리한다.
|
|
|
|
## 3. 비목표
|
|
|
|
- 이번 단계에서 화재 감지 센서를 실제 구현하지 않는다.
|
|
- 이번 단계에서 전원 이상 감지 회로를 실제 구현하지 않는다.
|
|
- 이번 단계에서 다중 기관/다중 고객용 제품 구조로 전환하지 않는다.
|
|
- 이번 단계에서 Cafe24 외 별도 클라우드, 앱, 푸시 알림을 추가하지 않는다.
|
|
- 이번 단계에서 HWP 파일을 직접 자동 편집하지 않는다. HWP에 붙일 문구, 표, 이미지, 첨부자료를 준비한다.
|
|
|
|
## 4. 사용자와 이해관계자
|
|
|
|
| 사용자 | 필요한 것 |
|
|
|---|---|
|
|
| 운영 담당자 | 누수, 장비 오프라인, SMS 실패, 사진 상태를 빠르게 확인하고 조치 기록 |
|
|
| 보안 담당자 | 보안통제, 구현 근거, 증적, 잔여위험을 확인 |
|
|
| 사업/관리 담당자 | 제출 가능한 보안대책서와 설치·운영 산출물 |
|
|
| 현장 점검자 | Pi, 센서, 카메라, 네트워크 상태 점검 절차 |
|
|
|
|
## 5. 개선 접근
|
|
|
|
선택한 접근은 **운영·보안 완성형**이다.
|
|
|
|
### 5.1 Phase 1: 심사 대응 패키지
|
|
|
|
보안대책서와 실제 구현 사이의 간극을 줄인다.
|
|
|
|
요구사항:
|
|
|
|
- 보안대책서에 넣을 보안통제 매트릭스를 완성한다.
|
|
- 소스코드 기반 보안근거 문서를 유지한다.
|
|
- 사용자가 제공해야 할 자료와 코드에서 이미 설명 가능한 자료를 분리한다.
|
|
- HTTPS, API 서명, 사진 업로드 검증, 관리자 인증, 비밀값 분리, 로그관리, 백업, 물리보안을 각각 증적과 연결한다.
|
|
- 최종 제출 전 “첨부자료 체크리스트”를 운영자가 따라갈 수 있게 한다.
|
|
|
|
성공 기준:
|
|
|
|
- 보안대책서 본문에 넣을 표와 문구가 준비되어 있다.
|
|
- 제출용 첨부자료 목록이 명확하다.
|
|
- API/HTTPS/인증/사진정보 관련 질문에 코드 근거로 답할 수 있다.
|
|
- 사용자가 제공해야 하는 자료가 10개 내외의 실무 항목으로 정리되어 있다.
|
|
|
|
### 5.2 Phase 2: 현장 운영 안정성
|
|
|
|
실패 상황을 숨기지 않고 운영자가 볼 수 있게 한다.
|
|
|
|
요구사항:
|
|
|
|
- Pi 오프라인 상태가 대시보드에서 명확히 보여야 한다.
|
|
- SMS 발송 실패가 대시보드와 월간 보고서에 드러나야 한다.
|
|
- 카메라 촬영 실패 또는 사진 업로드 실패가 Pi 로그에만 묻히지 않도록 운영 점검 항목에 포함해야 한다.
|
|
- API 실패, DB 실패, SMS 실패, 사진 실패를 장애 유형별 대응 절차와 연결한다.
|
|
- 백업·복구 점검 기준을 문서와 운영 체크리스트에 반영한다.
|
|
|
|
성공 기준:
|
|
|
|
- 운영자가 “지금 감시가 정상인지” 1분 안에 판단할 수 있다.
|
|
- 장애 유형별로 확인 위치와 조치가 문서화되어 있다.
|
|
- 월간 보고서에서 SMS 실패와 사고 처리 상태를 확인할 수 있다.
|
|
|
|
### 5.3 Phase 3: 관리자 UX와 보고서 품질
|
|
|
|
대시보드와 보고서를 심사자·운영자 관점에서 읽기 쉽게 만든다.
|
|
|
|
요구사항:
|
|
|
|
- 대시보드 첫 화면은 위험 상태, 미확인 사고, 오프라인 장비, 최근 사진을 우선 보여준다.
|
|
- 설치 점검 화면은 통과/경고/실패를 명확히 구분한다.
|
|
- 월간 보고서는 출력물로 제출해도 의미가 있도록 요약, 사고 내역, SMS/사진 현황을 정리한다.
|
|
- 사진 타임라인은 사고별로 묶어 누수 상황을 이해하기 쉽게 표시한다.
|
|
- 모바일에서도 운영자가 핵심 상태를 확인할 수 있어야 한다.
|
|
|
|
성공 기준:
|
|
|
|
- 대시보드만 보고도 현재 위험 우선순위를 알 수 있다.
|
|
- 월간 보고서 출력물이 보안대책서 증적 또는 운영 보고 자료로 쓸 수 있다.
|
|
- 설치 점검 결과를 캡처하면 보안 증적으로 이해 가능하다.
|
|
|
|
### 5.4 Phase 4: 자동 증적 생성
|
|
|
|
운영자가 보안대책서 첨부자료를 반복 수작업으로 만들지 않게 한다.
|
|
|
|
요구사항:
|
|
|
|
- 설치 점검 결과를 HTML 또는 CSV로 저장할 수 있게 한다.
|
|
- API 연결 테스트 결과를 문서에 붙일 수 있는 형태로 출력한다.
|
|
- SMS 테스트 결과와 최근 SMS 실패 현황을 확인 가능하게 한다.
|
|
- Pi 상태 확인 명령과 결과 양식을 문서화한다.
|
|
- 보안통제 매트릭스의 각 항목이 어떤 증적으로 확인되는지 연결한다.
|
|
|
|
성공 기준:
|
|
|
|
- 보안대책서 첨부자료를 준비할 때 “무엇을 캡처해야 하는지”가 명확하다.
|
|
- 운영자는 실제 비밀번호/API 키를 노출하지 않고 증적을 만들 수 있다.
|
|
- 최소 증적 5개만으로도 시스템 보안구조를 설명할 수 있다.
|
|
|
|
### 5.5 Phase 5: 확장 준비
|
|
|
|
확장은 설계상 가능하게 두되, 현 단계 심사 범위를 늘리지 않는다.
|
|
|
|
요구사항:
|
|
|
|
- 화재 감지, 전원 이상, 다중 Pi, 다중 위치는 “향후 확장”으로 분리한다.
|
|
- 확장 시 보안성 재검토 조건을 명확히 한다.
|
|
- 현재 HWP에는 1차 구축 범위를 누수/오프라인 중심으로 제한한다.
|
|
- 센서 추가 시 필요한 보안통제 항목을 별도 표로 남긴다.
|
|
|
|
성공 기준:
|
|
|
|
- 현재 제출 범위가 과대 기재되지 않는다.
|
|
- 확장 요구가 생겨도 보안대책서에서 어떤 절차를 따라야 하는지 설명 가능하다.
|
|
|
|
## 6. 우선순위
|
|
|
|
| 순위 | 개선 항목 | 이유 |
|
|
|---:|---|---|
|
|
| 1 | 보안대책서/증적 패키지 | 승인·심사 리스크가 가장 큼 |
|
|
| 2 | 운영 실패 가시화 | 실제 누수 상황에서 신뢰성에 직결 |
|
|
| 3 | 대시보드/보고서 품질 | 운영자와 심사자 모두에게 중요 |
|
|
| 4 | 자동 증적 생성 | 반복 작업과 제출 준비 부담 감소 |
|
|
| 5 | 확장 준비 | 범위를 늘리지 않고 향후 대응력 확보 |
|
|
|
|
## 7. 산출물
|
|
|
|
이미 존재하거나 보완할 산출물:
|
|
|
|
- `docs/SECURITY_PLAN_HWP_REVIEW.md`
|
|
- `docs/SECURITY_PLAN_PASS_READINESS.md`
|
|
- `docs/SECURITY_PLAN_ATTACHMENT_GUIDE.md`
|
|
- `docs/SOURCE_SECURITY_EVIDENCE.md`
|
|
- `docs/INSTALL_PI_SERVER.md`
|
|
- `docs/assets/security_plan/generated/*.png`
|
|
|
|
추가로 만들 산출물:
|
|
|
|
- 운영 점검 체크리스트
|
|
- 보안대책서 최종 첨부자료 패키지 목차
|
|
- 설치 점검 결과 저장 기능
|
|
- API/사진 업로드 테스트 결과 저장 양식
|
|
- 월간 보고서 제출용 출력 개선안
|
|
- 장애 대응 절차표
|
|
|
|
## 8. 주요 위험과 대응
|
|
|
|
| 위험 | 대응 |
|
|
|---|---|
|
|
| HWP 사업 범위가 실제 구현보다 넓음 | 1차 범위를 누수/오프라인 중심으로 정정 |
|
|
| HTTPS 적용이 코드만으로 증명되지 않음 | 실제 도메인 인증서/SSL 설정 화면을 증적으로 요구 |
|
|
| API 키 원문 노출 위험 | 문서에는 원문 미기재, 일치 여부만 증명 |
|
|
| 외부 웹호스팅에 대한 심사 질문 | 업무망 분리, 아웃바운드 HTTPS, 최소정보 저장 원칙 명시 |
|
|
| 사진정보가 민감 시설정보로 해석될 위험 | 목적 제한, 접근 제한, 보관기간, 삭제 기준 명시 |
|
|
| 기능 확장이 심사 범위를 키움 | 화재/전원/다중 Pi는 향후 확장으로 분리 |
|
|
|
|
## 9. 성공 상태
|
|
|
|
이 개선이 끝났다고 볼 수 있는 상태는 다음과 같다.
|
|
|
|
- HWP 보안대책서에 넣을 문구, 표, 이미지, 첨부자료가 준비되어 있다.
|
|
- 사용자는 어떤 자료를 직접 제공해야 하는지 알고 있다.
|
|
- 코드 기반 보안대책은 문서화되어 있다.
|
|
- 대시보드와 보고서는 운영·심사 증적으로 쓸 수 있다.
|
|
- 현장 장애 상황별 대응 절차가 문서화되어 있다.
|
|
- 확장 기능은 현재 범위와 분리되어 보안성 검토 리스크를 키우지 않는다.
|
|
|
|
## 10. 다음 단계
|
|
|
|
다음 단계에서는 이 요구사항을 아래 순서의 구현 계획으로 분해한다.
|
|
|
|
1. 보안대책서 제출 패키지 정리
|
|
2. 운영 실패 가시화 개선
|
|
3. 대시보드/보고서 증적 품질 개선
|
|
4. 자동 증적 생성 기능
|
|
5. 확장 범위 문서화
|