공개: KoTalk 최신 기준선

문서/03-보안-프라이버시-운영-리스크-기획안.md

@@ -0,0 +1,298 @@
+# 보안·프라이버시·운영 리스크 기획안
+
+## 문서 목적
+
+이 문서는 Windows PC 기준 메신저 사이드 프로젝트의 보안, 프라이버시, 악용 방지, 운영 하드닝, 비밀정보 관리, 인증, 암호화, Windows 클라이언트 시크릿 처리, 백업 민감도, 법적/컴플라이언스 리스크만 다룬다. 범위 밖인 UI, 브랜드, 세부 기능 정의는 제외한다.
+
+전제는 다음과 같다.
+
+- 채팅 백엔드는 현재 보유한 VPS에 자체 구축한다.
+- 현재 VPS 접속 방식은 `root + 비밀번호 SSH`다.
+- 현재 VPS는 다른 서비스 운영 흔적이 있는 단일 서버다.
+- 프로젝트는 개인 사이드 프로젝트이지만, 실제 사용자 데이터가 들어오는 순간 보안 기준은 "취미"가 아니라 "운영" 기준으로 올라간다.
+
+## 핵심 판단
+
+현재 VPS 상태를 그대로 둔 채 메신저 백엔드를 올리는 것은 권장하지 않는다. 가장 큰 이유는 `root 비밀번호 SSH`가 서버 전체 장악으로 직결되기 때문이다. 메신저는 계정, 대화, 첨부파일, 접속 로그, 알림 토큰, 백업본까지 한 번에 민감정보가 쌓이는 유형이라서, 일반 웹사이트보다 침해 시 피해 범위가 훨씬 넓다.
+
+특히 현재 VPS가 이미 다른 서비스 용도로 사용된 이력이 있다면, 같은 머신에 메신저를 같이 올리는 것은 초기 프로토타입까지만 허용하고, 비공개 알파 이후에는 분리하는 방향이 가장 안전하다. 동일 VPS 공용 운영은 한 서비스의 침해가 다른 서비스 전체로 번지는 구조다.
+
+## 우선순위 권고
+
+### P0. 배포 전 바로 수정할 항목
+
+1. `root` 비밀번호 SSH 로그인을 중단한다.
+2. 운영용 관리자 계정을 새로 만들고 `sudo`만 허용한다.
+3. SSH는 공개키 인증만 허용하고 비밀번호 로그인은 끈다.
+4. 현재 `root` 비밀번호는 이미 노출된 것으로 간주하고 즉시 교체한다.
+5. SSH 접근 대상을 고정 IP 또는 최소한 국가/대역 제한 가능한 범위로 좁힌다.
+6. 방화벽은 `22`, `80`, `443`만 열고 DB, Redis, 오브젝트 스토리지 포트는 외부 공개를 금지한다.
+7. 실패 로그인 차단 도구와 기본 침입 탐지 로그를 켠다.
+8. 메신저용 런타임 계정과 기존 서비스 계정을 분리한다.
+9. 기존 서비스와 메신저 서비스의 비밀정보 파일, 로그, 백업 저장 위치를 분리한다.
+10. 패치 가능한 OS 및 패키지는 먼저 최신 보안 패치 상태로 올린다.
+
+### P1. 첫 비공개 테스트 전 완료할 항목
+
+1. 관리자 콘솔에 최소 `2단계 인증`을 넣는다.
+2. 일반 사용자 가입은 공개 가입보다 초대 기반 또는 승인 기반으로 시작한다.
+3. 세션 강제 만료, 기기별 로그아웃, 리프레시 토큰 회전을 넣는다.
+4. 첨부파일 업로드 제한, MIME 검증, 악성 파일 차단 정책을 둔다.
+5. 백업 암호화와 복구 리허설을 최소 1회 수행한다.
+6. 개인정보 처리방침, 이용약관, 신고/삭제 요청 절차를 문서화한다.
+
+### P2. 베타 이후 고도화 항목
+
+1. 서비스별 서버 분리 또는 최소한 별도 VPS/별도 프로젝트 네트워크로 이관한다.
+2. 비정상 행위 탐지, 속도 제한, 디바이스 신뢰도 점수화를 붙인다.
+3. 감사 로그, 보안 경보, 비밀정보 자동 회전 체계를 만든다.
+4. 고급 프라이버시 기능과 E2EE 도입 여부를 별도 제품 결정으로 분리 검토한다.
+
+## 현재 VPS에 대한 명시적 경고와 조치
+
+### 현재 상태의 위험
+
+- `root + 비밀번호 SSH`는 자격 증명 하나만 유출되어도 서버 전체가 끝난다.
+- 동일 VPS에서 기존 서비스와 메신저를 함께 운영하면 침해 반경이 너무 넓다.
+- 루트 계정으로 운영 작업을 계속하면 실수도 곧 전면 장애가 된다.
+- 메신저 데이터는 일반 게시판보다 민감해서 백업 탈취, 로그 노출, DB 덤프 유출의 피해가 크다.
+
+### 생산환경 수준으로 가기 전 최소 조치
+
+- `root` 원격 로그인 비활성화
+- SSH 비밀번호 인증 비활성화
+- 관리자 공개키 인증 강제
+- `sudo` 가능한 비루트 운영 계정 생성
+- SSH 접속 허용 IP 제한
+- 침입 차단과 접속 로그 모니터링 활성화
+- 루트 및 운영 비밀정보 전면 교체
+- 기존 서비스와 메신저의 런타임 사용자, 디렉터리, 백업 분리
+
+이 조치 전에는 "실사용 데이터가 들어오는 테스트"도 사실상 운영으로 보면 안 된다. 내부 목업 수준까지만 허용하는 것이 맞다.
+
+## 위협 모델 요약
+
+### 보호해야 할 자산
+
+- 사용자 계정 정보
+- 비밀번호 해시 및 인증 토큰
+- 대화 내용과 메타데이터
+- 첨부파일 원본과 썸네일
+- 푸시 토큰, 기기 식별자
+- 관리자 계정 및 운영 콘솔
+- DB 덤프, 오브젝트 스토리지 백업
+- 에러 로그, 접근 로그, 감사 로그
+
+### 주요 공격자 유형
+
+- 인터넷 상의 무차별 스캐너 및 봇
+- 비밀번호 재사용 공격자
+- 악성 사용자 및 스팸 발송자
+- 첨부파일 업로드 악용자
+- 토큰 탈취형 악성코드
+- VPS 또는 백업 저장소 접근 권한을 얻은 침해자
+
+### 가장 현실적인 사고 시나리오
+
+1. SSH 자격 증명 노출로 서버 전체 탈취
+2. 관리자 세션 탈취로 사용자 데이터 조회
+3. 리프레시 토큰 유출로 장기 세션 악용
+4. 오브젝트 스토리지 공개 설정 실수로 첨부파일 노출
+5. 암호화되지 않은 백업 유출
+6. Windows 클라이언트 로컬 캐시나 로그에서 토큰/대화 일부 유출
+7. 대량 가입 및 메시지 발송을 통한 스팸/피싱 플랫폼화
+
+## 인증과 계정 보안
+
+### 권장 방향
+
+- 초기에는 공개 회원가입보다 `초대형 비공개 베타`가 낫다.
+- 비밀번호 기반 로그인을 쓸 경우, 강한 해시 정책과 로그인 시도 제한이 필수다.
+- 관리자와 일반 사용자의 인증 정책은 반드시 분리한다.
+- 관리자 계정에는 `2단계 인증`을 강제한다.
+- 세션은 기기 단위로 관리하고, 사용자는 모든 기기 세션을 확인하고 종료할 수 있어야 한다.
+- 리프레시 토큰은 장기 고정값으로 두지 말고 회전형으로 설계한다.
+- 비밀번호 재설정과 이메일 변경은 재인증이 필요해야 한다.
+
+### 실무적 권고
+
+- 사이드 프로젝트라면 소셜 로그인 남발보다 이메일+비밀번호 또는 초대코드 기반이 단순하다.
+- 단, 비밀번호만 쓴다면 로그인 방어, 차단, 복구 흐름을 반드시 넣어야 한다.
+- 운영자용 관리자 콘솔은 일반 사용자 앱과 별도 서브도메인/별도 접근 정책으로 분리하는 편이 안전하다.
+
+## 암호화와 데이터 보호
+
+### 전송 구간
+
+- 모든 트래픽은 HTTPS만 허용한다.
+- 관리자 콘솔, API, 파일 다운로드 모두 TLS 강제 대상이다.
+- 개발 중이라도 실데이터가 오가는 환경은 평문 HTTP를 허용하면 안 된다.
+
+### 저장 구간
+
+- 비밀번호는 복호화 불가능한 단방향 해시로만 저장한다.
+- 리프레시 토큰, 이메일 인증 토큰, 비밀번호 재설정 토큰은 평문 저장을 피한다.
+- 첨부파일은 저장소 접근 제어와 만료 가능한 서명 URL 중심으로 설계한다.
+- DB와 파일 백업은 별도 암호화가 필요하다.
+
+### E2EE 관련 주의
+
+- 종단간암호화(E2EE)를 구현하지 않았다면 절대 그렇게 홍보하면 안 된다.
+- "서버 저장 시 암호화"와 "진짜 E2EE"는 완전히 다르다.
+- 사이드 프로젝트 1단계에서는 E2EE를 억지로 넣기보다, 서버 보안과 접근 제어를 먼저 제대로 하는 편이 낫다.
+
+## Windows 클라이언트 시크릿 처리
+
+### 저장 원칙
+
+- 액세스 토큰, 리프레시 토큰, 기기 키는 평문 파일로 저장하지 않는다.
+- Windows 사용자 컨텍스트 기반 보호 저장소를 사용해 OS에 묶어 보관하는 방향이 적절하다.
+- 앱 설정 파일, 로그 파일, 크래시 덤프에 토큰이 남지 않도록 한다.
+
+### 주의할 점
+
+- 클라이언트 안에 마스터 시크릿이나 서버 관리자 키를 절대 넣지 않는다.
+- API 키가 필요해도 클라이언트에 박아 넣는 구조는 지양한다.
+- 로컬 메시지 캐시를 둘 경우, 최소한 캐시 범위와 보관 기간을 제한한다.
+- 공용 PC나 가족 PC 사용 가능성을 고려해 자동 로그인과 로컬 캐시의 민감도를 분리 설정한다.
+
+### 현실적 권고
+
+- 처음부터 모든 채팅을 장기 로컬 보관하지 말고, 최근 대화 일부만 안전하게 캐시하는 쪽이 낫다.
+- 로그아웃 시 토큰 삭제와 민감 캐시 파기를 명확히 정의한다.
+- 디버그 빌드와 릴리스 빌드의 로깅 수준을 분리한다.
+
+## 비밀정보 관리
+
+### 반드시 지킬 원칙
+
+- 비밀정보는 Git 저장소에 넣지 않는다.
+- 개발, 스테이징, 운영 비밀정보를 분리한다.
+- 서버 관리자 비밀번호, DB 비밀번호, JWT 비밀키, SMTP 자격 증명, 푸시 인증서는 각각 분리한다.
+- 비밀정보 접근 권한은 사람 기준이 아니라 역할 기준으로 최소화한다.
+
+### 사이드 프로젝트에 맞는 실용안
+
+- 비밀정보 원장은 개인 패스워드 매니저에 둔다.
+- 서버에는 최소 권한 파일로만 배치한다.
+- 비밀정보 목록, 용도, 회전 주기, 누가 접근 가능한지를 한 문서로 관리한다.
+- 유출 의심이 생기면 전체 교체가 가능한 구조를 초기부터 잡는다.
+
+## 악용 방지와 스팸/남용 대응
+
+### 초기 정책
+
+- 공개 오픈보다는 초대 기반으로 시작한다.
+- 계정 생성, 로그인 시도, 메시지 발송, 첨부 업로드에 속도 제한을 둔다.
+- 새 계정의 대량 메시지 발송은 기본적으로 제한한다.
+- 신고, 차단, 대화방 퇴장, 운영자 제재 수단을 최소 기능으로라도 넣는다.
+
+### 필요한 운영 시야
+
+- 메신저는 피싱 링크, 음란물, 불법 촬영물, 저작권 침해 파일, 스팸 유통 통로가 되기 쉽다.
+- 단순 채팅 서버라 해도 신고 접수와 대응 절차가 없으면 운영이 금방 어려워진다.
+- 관리자는 신고 확인, 계정 정지, 메시지 메타데이터 확인 범위를 명확히 가져야 한다.
+
+## 백업 민감도와 복구 전략
+
+### 백업은 원본과 동일하게 민감하다
+
+- DB 백업에는 대화, 계정, 이메일, 세션 관련 정보가 들어간다.
+- 파일 백업에는 첨부 원본이 들어간다.
+- 로그 백업에도 IP, 사용자 식별자, 에러 문맥이 들어갈 수 있다.
+
+### 권장 정책
+
+- 백업은 암호화해서 저장한다.
+- 운영 서버와 동일 자격 증명으로 백업 저장소에 접근하지 않는다.
+- 복구 테스트를 실제로 해본 백업만 백업으로 인정한다.
+- 보관 기간은 길수록 좋은 것이 아니라, 필요한 만큼만 둔다.
+- 탈퇴/삭제 정책과 백업 보존 정책이 충돌하지 않도록 설계한다.
+
+## 운영 하드닝
+
+### 인프라
+
+- 인터넷에 직접 노출되는 것은 리버스 프록시와 SSH 정도로 최소화한다.
+- DB, 캐시, 내부 API는 사설 네트워크 또는 로컬 바인딩만 사용한다.
+- 메신저용 서비스 계정과 파일 권한을 기존 서비스와 분리한다.
+- 컨테이너를 쓴다면 네트워크와 볼륨 권한도 서비스별로 분리한다.
+
+### 관측성
+
+- 보안 이벤트 로그와 애플리케이션 에러 로그를 구분한다.
+- 토큰, 비밀번호, 대화 본문이 로그에 남지 않게 마스킹한다.
+- 로그인 실패 급증, 업로드 폭주, 5xx 급증, 저장소 사용량 급증에 경보를 건다.
+
+### 배포
+
+- 직접 서버에서 수동 수정하는 운영 습관은 줄인다.
+- 배포 단위와 롤백 경로를 정의한다.
+- 운영 배포 전에 최소한 인증, 메시지 송수신, 첨부 업로드, 세션 만료를 점검하는 체크리스트를 둔다.
+
+## 법적·컴플라이언스 리스크
+
+### 핵심 원칙
+
+- 수집하는 개인정보를 최소화한다.
+- 왜 수집하는지, 얼마나 보관하는지, 어떻게 삭제하는지 설명 가능해야 한다.
+- 과장된 프라이버시 문구를 쓰지 않는다.
+
+### 현실적인 리스크
+
+- 개인정보 처리방침 없이 이메일, IP, 접속기록을 모으면 운영 리스크가 커진다.
+- 메시지/첨부 저장 방식이 불명확하면 사용자 기대와 실제가 어긋난다.
+- 불법 콘텐츠 신고 창구와 처리 프로세스가 없으면 플랫폼 책임 이슈가 생긴다.
+- 미성년자 사용, 국제 사용자, 외부 알림 서비스 사용 시 추가 고려가 붙는다.
+
+### 사이드 프로젝트용 최소 문서
+
+- 개인정보 처리방침
+- 이용약관
+- 신고/차단/삭제 요청 처리 안내
+- 운영자 연락 수단
+- 보안 사고 대응 메모
+
+## 단계별 보안 게이트
+
+### 1단계. 로컬 프로토타입
+
+- 실사용 데이터 금지
+- 테스트 계정만 사용
+- 현재 VPS 미사용 또는 내부 검증용만 사용
+
+### 2단계. 비공개 알파
+
+- SSH 하드닝 완료
+- 관리자 계정 분리 완료
+- 백업 암호화 완료
+- 초대형 가입만 허용
+
+### 3단계. 비공개 베타
+
+- 운영 로그/경보 적용
+- 신고/차단 기능 적용
+- 약관/개인정보 문서 공개
+- 복구 리허설 완료
+
+### 4단계. 공개 테스트
+
+- 기존 서비스와 인프라 분리 검토 완료
+- 계정 남용 방지 체계 적용
+- 토큰/세션/첨부 정책 검증 완료
+- 침해 대응 절차 문서화 완료
+
+## 최종 권고안
+
+이 프로젝트의 최선은 "빠른 기능 개발"보다 "초기 보안 경계 설정"을 먼저 하는 것이다. 특히 현재 VPS의 `root 비밀번호 SSH`는 가장 먼저 없애야 한다. 이 한 가지가 그대로 남아 있으면 인증, 암호화, 백업, 프라이버시 설계를 아무리 잘 적어도 실제 위험 수준은 낮아지지 않는다.
+
+사이드 프로젝트 기준으로 가장 현실적인 방향은 다음과 같다.
+
+1. 현재 VPS는 프로토타입 또는 내부 테스트까지만 사용한다.
+2. 실사용 테스트 전에는 SSH 하드닝과 계정 분리를 끝낸다.
+3. 초기 사용자 모집은 초대 기반으로 제한한다.
+4. 토큰, 첨부파일, 백업을 대화 본문만큼 민감하게 취급한다.
+5. E2EE는 마케팅 문구가 아니라 별도 제품 단계로 다룬다.
+6. 기존 서비스와 공존하는 단일 VPS 구조는 오래 끌지 않는다.
+
+이 문서는 사이드 프로젝트에 맞춘 실무형 기준선이다. 더 강한 보안을 원하면, 다음 단계는 `서버 분리`, `관리자 접근 제어 강화`, `비밀정보 회전 자동화`, `감사 로그 체계화` 순서로 잡는 것이 맞다.