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 제외.
9.2 KiB
9.2 KiB
누수감지 시스템 운영·보안 완성형 개선 요구사항
참고: 이 문서는 누수감지 시절의 기록(레거시)이며, 현재 시스템은 SHT30 온습도 전용으로 전환되었습니다.
작성일: 2026-05-20
상태: 사용자 승인 방향 기반 초안
대상 프로젝트: leak_sms_v2 v2605
1. 배경
현재 프로젝트는 누수 감지, Raspberry Pi 전송, Cafe24 PHP API, MySQL 저장, SMS 알림, 사진 업로드, 대시보드, 사고 대응, 월간 보고서까지 기본 운영 흐름을 갖췄다.
다음 개선의 목표는 기능을 무작정 확장하는 것이 아니라, 제출 가능한 보안대책서와 현장 운영 가능한 시스템으로 완성도를 올리는 것이다. 화재 감지, 전원 이상, 다중 지점 같은 확장은 지금 바로 구현하지 않고 향후 확장 범위로 분리한다.
2. 목표
- 보안성 검토 또는 기관 보안검토에 대응할 수 있는 제출 패키지를 만든다.
- 실제 현장 운영 중 실패할 수 있는 지점(API, SMS, 카메라, Pi, DB)을 더 잘 드러내고 대응 가능하게 만든다.
- 운영자가 대시보드와 보고서에서 현재 위험, 미확인 사고, 사진, SMS 실패, 장비 상태를 빠르게 판단하게 한다.
- 설치·운영·보안 증적을 수동 설명이 아니라 시스템과 문서에서 뽑을 수 있게 한다.
- 향후 화재/전원/다중 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.mddocs/SECURITY_PLAN_PASS_READINESS.mddocs/SECURITY_PLAN_ATTACHMENT_GUIDE.mddocs/SOURCE_SECURITY_EVIDENCE.mddocs/INSTALL_PI_SERVER.mddocs/assets/security_plan/generated/*.png
추가로 만들 산출물:
- 운영 점검 체크리스트
- 보안대책서 최종 첨부자료 패키지 목차
- 설치 점검 결과 저장 기능
- API/사진 업로드 테스트 결과 저장 양식
- 월간 보고서 제출용 출력 개선안
- 장애 대응 절차표
8. 주요 위험과 대응
| 위험 | 대응 |
|---|---|
| HWP 사업 범위가 실제 구현보다 넓음 | 1차 범위를 누수/오프라인 중심으로 정정 |
| HTTPS 적용이 코드만으로 증명되지 않음 | 실제 도메인 인증서/SSL 설정 화면을 증적으로 요구 |
| API 키 원문 노출 위험 | 문서에는 원문 미기재, 일치 여부만 증명 |
| 외부 웹호스팅에 대한 심사 질문 | 업무망 분리, 아웃바운드 HTTPS, 최소정보 저장 원칙 명시 |
| 사진정보가 민감 시설정보로 해석될 위험 | 목적 제한, 접근 제한, 보관기간, 삭제 기준 명시 |
| 기능 확장이 심사 범위를 키움 | 화재/전원/다중 Pi는 향후 확장으로 분리 |
9. 성공 상태
이 개선이 끝났다고 볼 수 있는 상태는 다음과 같다.
- HWP 보안대책서에 넣을 문구, 표, 이미지, 첨부자료가 준비되어 있다.
- 사용자는 어떤 자료를 직접 제공해야 하는지 알고 있다.
- 코드 기반 보안대책은 문서화되어 있다.
- 대시보드와 보고서는 운영·심사 증적으로 쓸 수 있다.
- 현장 장애 상황별 대응 절차가 문서화되어 있다.
- 확장 기능은 현재 범위와 분리되어 보안성 검토 리스크를 키우지 않는다.
10. 다음 단계
다음 단계에서는 이 요구사항을 아래 순서의 구현 계획으로 분해한다.
- 보안대책서 제출 패키지 정리
- 운영 실패 가시화 개선
- 대시보드/보고서 증적 품질 개선
- 자동 증적 생성 기능
- 확장 범위 문서화