블로그에 뭘 쓰면 안 되나 — 셀프호스팅 글의 개인정보 검열

셀프호스팅 구축기 10편. 서버를 막는 것만큼, 그 서버 이야기를 쓴 글을 막는 것도 중요하다.

← 이전 편: 9편 — 보이지 않는 다리: Cloudflare Tunnel
→ 다음 편: 11편 — 공짜로 워드프레스 지키기 (Wordfence)

요약

• 셀프호스팅 글은 본질적으로 내 서버 구조를 공개한다 — 튜토리얼 가치와 정찰 정보 사이의 줄타기
• 내가 실제로 흘린 것: 리눅스 계정명, 미니PC 내부 IP, 개인 이메일 (비번·토큰은 다행히 안 샘)
• 가려야 할 5가지: 시크릿 · 개인정보 · 내부 네트워크 · 파일 경로 · frontmatter
• 시크릿은 한 번 새면 교체밖에 답이 없다 — 검색엔진이 이미 긁어간 뒤다
• 발행 전 grep 한 줄이면 기계가 대신 훑어준다

1. 내가 실제로 흘린 것

9편까지 신나게 써놓고 다시 보니, 글 곳곳에 이런 게 박혀 있었다.

• /home/내계정/... — 리눅스 계정명이 경로에 그대로. SSH 무차별 대입(brute force)의 표적이 된다.
• http://192.168.x.x:3001 — 미니PC 내부 IP. 내 홈 네트워크 구조를 알려주는 셈.
• 도메인 설명하다 슬쩍 들어간 개인 Gmail 주소 한 줄.

비밀번호·토큰은 운 좋게 변수 placeholder나 <openssl rand -hex 24> 같은 예시값으로 써둬서 안 샜다. 하지만 위 셋은 진짜였다.

문제는 공개 블로그가 영구적이라는 점이다. 검색엔진이 인덱싱하고 캐시가 남는다. 지운다고 없던 일이 되지 않는다. 그래서 시크릿이 한 번 샜다면, 지우는 게 아니라 즉시 재발급해야 한다.

2. 가려야 할 5가지

⑤번이 의외다. 마크다운으로 쓰면 글 맨 위에 ---로 둘러싼 메타데이터(frontmatter, 작성자·날짜·파일명 등)가 있는데, 발행 변환이 한 번 어긋나면 이게 본문에 코드블록으로 통째 노출된다. 실제로 내 글 하나가 그렇게 frontmatter를 다 드러내고 있었다.

3. 지우지 말고 일반화하라

핵심은 삭제가 아니라 치환이다. 튜토리얼 가치는 살리되 내 진짜 정보만 가린다.

<openssl rand -hex 24>처럼 여기에 직접 생성한 값을 넣으세요라고 명시하면, 읽는 사람도 따라 하기 더 좋다. 일반화가 오히려 더 친절한 튜토리얼이 되는 셈이다.

4. 발행 전 자동 검사 (grep 한 줄)

눈으로 매번 잡으면 결국 샌다. 발행 전에 기계로 훑는다.

grep -rEn "/home/[a-z]+|[0-9.]+|@(gmail|naver)\.com|_TOKEN=|_KEY=|PASSWORD=" 내-글-폴더/

계정 경로·IP·개인 메일·시크릿 흔적을 한 번에 잡는다. 결과가 0줄이어야 발행. 변수·꺾쇠 플레이스홀더만 남으면 통과다.

발행한 뒤엔 실제 공개된 페이지도 한 번 더 본다. 캐시 때문에 옛 화면이 남아 있을 수 있어서다.

curl -s https://내도메인/글-주소/ | grep -E "/home/|192.168.|@gmail"

5. 더 큰 질문 — 애초에 공개할까?

개인정보를 다 가려도 남는 문제가 있다. 글 자체가 내 인프라 지도라는 것.

나는 글로 쓰지 않는 비공개 운영 도구를 따로 돌린다. 키와 IP를 아무리 가려도 이런 구조의 관리 도구가 여기 있다는 사실 자체가 정찰 정보이기 때문이다.

그래서 순서가 중요하다. 이 시리즈를 공개할까?를 먼저 정하고, 공개하기로 한 것만 앞의 검열을 거친다. 가릴 수 있는 정보와, 애초에 쓰면 안 되는 주제는 다른 층위의 문제다.

한 줄 정리

서버를 막는 P0가 있다면, 글을 막는 P0도 있다. 계정명·내부 IP·개인 메일·시크릿·frontmatter 다섯 가지를 플레이스홀더로 일반화하고, 발행 전 grep 한 줄로 검사하자. 시크릿은 새면 교체뿐이니, 처음부터 안 쓰는 게 가장 싸다.