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

# 보안·프라이버시·운영 리스크 기획안

## 문서 목적

이 문서는 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 구조는 오래 끌지 않는다.

이 문서는 사이드 프로젝트에 맞춘 실무형 기준선이다. 더 강한 보안을 원하면, 다음 단계는 `서버 분리`, `관리자 접근 제어 강화`, `비밀정보 회전 자동화`, `감사 로그 체계화` 순서로 잡는 것이 맞다.