개인 NAS·홈서버 보안 체크리스트 10가지｜Cloudflare Tunnel·Vaultwarden·Docker 운영자 기준

개인 NAS에 서비스를 하나씩 올리다 보면 어느 순간 이런 생각이 듭니다. “이거, 외부에서 접속되는데 보안은 괜찮은 걸까?”

저는 NAS에서 Docker 컨테이너로 워드프레스, Vaultwarden, Jellyfin, AdGuard Home, Uptime Kuma 같은 서비스를 운영하고 있습니다. 최근 PHP 원격 코드 실행(RCE) 취약점 긴급 점검 글을 쓰면서, 취약점 하나가 터질 때마다 허둥대지 않으려면 개별 대응보다 평소에 갖춰 둔 기본 체계가 더 중요하다는 걸 다시 느꼈습니다.

그래서 이 글에서는 개인 NAS·홈서버 운영자가 정기적으로 확인하면 좋은 보안 체크리스트 10가지를 정리합니다. 접근 통제, 패치 관리, 백업, 로그·모니터링, 사고 대응이라는 보안 관리의 기본 틀을 집에서 쓰는 규모에 맞게 풀어 쓴 개인 환경용 운영 원칙이며, ISO 27001 같은 공식 인증의 통제 항목을 그대로 축약한 것은 아닙니다.

1. 공유기 포트포워딩부터 닫기

가장 먼저 확인할 것은 공유기에 열려 있는 포트입니다. 외부 공개를 위해 80, 443, 5000, 5001 같은 포트를 NAS로 포워딩해 두었다면 인터넷 전체에 서비스가 노출된 상태입니다. 노출된 서버는 스캐너와 봇이 수시로 두드립니다.

Cloudflare Tunnel은 NAS 쪽에서 Cloudflare로 나가는(outbound) 연결을 만들어 서비스를 공개하는 방식이라, 공유기에서 인바운드 포트를 열 필요가 없습니다. 그래서 Tunnel로 전환했다면 다음을 꼭 확인하세요.

공유기 포트포워딩, UPnP 자동 개방 규칙이 남아 있지 않은지
DSM 관리 포트(5000/5001)가 외부에서 접근되지 않는지
Tunnel을 거치지 않고 NAS의 공인 IP로 직접 접속되는 경로가 없는지
IPv4뿐 아니라 IPv6 경로와 NAS 자체 방화벽 설정도 열려 있지 않은지

점검 팁: 모바일 데이터(Wi-Fi 끔)로 공인IP:포트에 접속해 보면 노출 여부를 간단히 확인할 수 있습니다. 다만 이 결과만으로 외부 노출이 없다고 단정할 수는 없으니, IPv4와 IPv6 모두 공유기 규칙과 NAS 방화벽까지 함께 확인하세요. 또 Tunnel로 공개한 호스트네임으로는 외부 요청이 그대로 도달하므로, 2번 이후의 인증·접근 통제가 여전히 필요합니다.

2. 관리자 경로는 Cloudflare Access로 한 겹 더 막기

Tunnel은 “포트를 닫아 주는” 장치일 뿐, 공개한 주소 자체에 대한 인증까지 해 주지는 않습니다. 워드프레스의 /wp-admin, /wp-login.php처럼 나만 쓰는 경로는 Cloudflare Access(Zero Trust)로 앞단 인증을 걸어 두는 것이 좋습니다.

Access 애플리케이션을 만들고 경로를 /wp-admin*, /wp-login.php로 지정
허용 정책은 내 이메일(원타임 PIN) 또는 Google 같은 IdP 로그인으로 제한
공개 페이지에서 /wp-admin/admin-ajax.php를 쓰는 테마·플러그인이 있다면 이 경로까지 막혀 기능이 깨질 수 있습니다. 무조건 우회(Bypass)로 열지 말고, 실제로 필요한 기능과 접근 범위를 먼저 검토한 뒤 필요한 경우에만 제한적으로 예외를 두세요.

Access를 적용하면 보호한 관리자 경로에 대한 접근을 인증된 사용자로 제한할 수 있어 로그인 경로를 노린 무차별 대입 공격과 불필요한 관리자 접근을 줄이는 데 도움이 됩니다. 다만 공개 페이지와 플러그인 취약점, 별도로 노출된 API 경로까지 모두 보호하는 것은 아니므로 워드프레스 코어와 플러그인 업데이트, 서버 측 인증·인가 점검은 계속 필요합니다. 요금제와 무료 사용 범위는 바뀔 수 있으니 Cloudflare 대시보드에서 현재 조건을 확인하세요.

3. 모든 로그인에 2단계 인증 적용하기

외부에서 접근 가능한 계정에는 비밀번호만으로는 부족합니다. 우선순위를 정하면 다음과 같습니다.

DSM 관리자 계정: 2단계 인증 필수, 기본 admin 계정이 활성화되어 있다면 비활성화하고 별도 이름의 관리자 계정 사용
Vaultwarden 계정: 마스터 비밀번호는 길게(문장형), TOTP 인증 앱 또는 보안 키 2FA 설정
워드프레스 관리자: 2FA 플러그인 적용, 계정 이름과 표시 이름 분리
Cloudflare 계정 자체: 터널과 DNS를 쥐고 있는 계정이므로 2FA와 복구 코드 보관이 필수

특히 Cloudflare 계정이 탈취되면 터널과 DNS를 통째로 넘겨주는 셈입니다. 가능하면 SMS가 아닌 인증 앱이나 하드웨어 키를 사용하세요.

Vaultwarden에 저장한 TOTP를 같은 Vaultwarden에서 꺼내 쓰면, 계정이 탈취된 상황에서 두 번째 인증 요소가 독립적이라는 이점이 줄어듭니다. 가능하면 별도의 인증 앱이나 보안 키를 함께 사용하세요.

4. Vaultwarden은 “공개할지 말지”부터 다시 판단하기

비밀번호 저장소는 홈서버에서 가장 가치가 큰 표적입니다. 다음을 점검하세요.

가입 허용 해제: 계정 생성을 마친 뒤 SIGNUPS_ALLOWED=false로 설정
관리자 페이지(/admin): ADMIN_TOKEN을 강력한 값(해시 형태 권장)으로 설정하거나, 평소에는 아예 비활성화
외부 공개가 꼭 필요한지 재검토: 집 밖에서 자주 쓰지 않는다면 VPN(WireGuard, Tailscale 등)으로만 접근하게 하는 편이 더 안전
백업: Vaultwarden 데이터 디렉터리는 별도 백업 대상에 반드시 포함

외부에서 사용할 필요가 없다면 VPN을 통해서만 접근하도록 제한하는 방법이 가장 단순한 선택지입니다. 공개 상태로 운영한다면 Vaultwarden 자체 인증과 2단계 인증을 유지하고, 관리자 페이지는 별도로 보호하며, WAF와 속도 제한은 추가 방어 수단으로 활용하세요. WAF는 특정 공격 패턴을 걸러내고 속도 제한은 요청 빈도를 제한할 뿐, VPN처럼 접근 자체를 통제해 주지는 않습니다. 또 Cloudflare Access를 서비스 전체 앞단에 적용하면 브라우저 확장과 모바일 앱의 동기화가 막힐 수 있으므로, 클라이언트 호환성을 먼저 확인하세요.

5. 컨테이너 이미지 업데이트 전략 세우기 (Watchtower의 장단점)

PHP 취약점 같은 이슈가 나오면 결국 이미지를 얼마나 빨리 최신 상태로 만드느냐가 승부입니다. 자동 업데이트 도구로 많이 쓰인 Watchtower는 주의가 필요합니다. 기존 containrrr/watchtower 저장소는 2025년 12월 17일에 아카이브되어 현재 읽기 전용 상태이며, 원 프로젝트에서는 더 이상 유지보수를 기대하기 어렵습니다. 이미 설치한 컨테이너가 아카이브만으로 즉시 중단되는 것은 아닙니다. 다만 Docker 환경 변화에 대한 호환성 개선이나 보안 이슈 대응을 기대하기 어려우므로, 신규 설치보다는 정기적인 수동 업데이트나 유지보수 상태를 검증한 대안을 검토하는 편이 좋습니다. Watchtower 사용기는 NAS 구축기 8부에서 다뤘고, 여기서는 보안 관점의 업데이트 전략만 정리합니다.

방식	장점	주의점
자동 업데이트	패치 적용을 놓칠 가능성이 줄어듦	호환성 문제와 예기치 않은 변경, 데이터 손상 위험이 있음
알림 후 수동 업데이트	변경 시점과 적용 버전을 직접 통제할 수 있음	알림을 무시하면 패치가 지연됨
완전 수동 점검	적용 전 변경 내용을 검토하기 쉬움	정기적으로 확인하지 않으면 업데이트가 밀림

현실적인 운영 기준을 제안하면 이렇습니다.

신규 설치에는 containrrr/watchtower를 기본 선택지로 쓰지 않습니다. 이미 사용 중이라면 대체 방안을 정해 두세요.
자동 업데이트는 호환성 문제와 데이터 손상 위험을 감수해야 하므로, 알림을 받고 직접 업데이트하는 방식도 좋은 대안입니다.
자동 업데이트를 유지하려면 유지보수되는 대안 도구의 출처와 최신 상태를 먼저 확인하세요.
인터넷에 노출된 서비스(워드프레스, 리버스 프록시 등)는 패치 우선순위를 가장 높게 두고 빠르게 적용합니다.
데이터베이스 같은 상태 저장 서비스는 자동 업데이트 대상에서 제외합니다(메이저 버전 업그레이드는 데이터 마이그레이션이 필요할 수 있음).
이미지 태그는 latest만 쓰지 말고 주요 서비스는 메이저 버전까지 고정해 의도하지 않은 대형 변경을 막습니다.
업데이트 전에 백업이나 스냅샷을 먼저 확보합니다.
어떤 도구를 쓰든 Docker 소켓 접근에 따른 권한 위험은 6번 항목에서 별도로 평가합니다.

6. 컨테이너 권한과 네트워크 최소화하기

컨테이너는 격리되어 있어서 안전하다고 생각하기 쉽지만, 설정에 따라 호스트까지 영향을 줄 수 있습니다.

privileged: true 사용 금지: 정말 필요한 경우가 아니면 쓰지 않기
/var/run/docker.sock 마운트는 최소화: 소켓에 접근하는 컨테이너는 사실상 호스트 관리자 권한을 가진 것과 비슷함
컨테이너 안의 프로세스는 가능하면 root가 아닌 일반 사용자로 실행
포트 게시는 필요한 것만: 컨테이너끼리만 쓰는 서비스는 포트를 호스트에 게시하지 않고 필요한 Docker 네트워크에만 연결하는 방식을 우선 고려하세요. 호스트에서 실행되는 cloudflared가 로컬 서비스에 접속하는 구조라면 127.0.0.1:포트:포트 바인딩을 쓸 수 있지만, cloudflared도 컨테이너로 실행한다면 그 컨테이너의 localhost는 NAS 호스트의 localhost와 다르므로 Docker 네트워크와 서비스 주소를 따로 확인해야 합니다. 설정을 바꾼 뒤에는 반드시 접속 테스트를 하세요.
워드프레스와 DB는 전용 내부 네트워크로 묶고, DB 포트는 호스트에 게시하지 않기
비밀번호와 토큰은 compose 파일에 그대로 쓰지 말고 .env 파일이나 secrets로 분리하세요. 다만 .env는 파일을 분리하는 수단일 뿐 암호화된 시크릿 저장소는 아닙니다. Git 저장소에서 제외하고, 파일 권한을 제한하고, 백업할 때는 암호화까지 함께 고려하세요.
볼륨 마운트는 필요한 디렉터리만 연결(NAS 공유 폴더 전체를 통째로 마운트하지 않기)

7. 워드프레스 자체 보안 설정 점검하기

PHP 런타임을 패치해도 워드프레스 계층이 허술하면 소용없습니다.

워드프레스 코어, 테마, 플러그인 업데이트 유지, 안 쓰는 플러그인과 테마는 삭제(비활성화가 아니라 삭제)
wp-config.php에 DISALLOW_FILE_EDIT를 설정해 관리자 화면에서의 코드 편집 차단
쓰지 않는다면 xmlrpc.php 접근 차단(이를 쓰는 앱이나 플러그인이 있으면 먼저 확인)
불필요한 사용자 정보 노출 줄이기: ?author=1 같은 사용자 열거와 REST API의 사용자 목록 노출을 줄이는 방향으로 설정하세요. REST API 전체를 막으면 블록 에디터나 일부 플러그인이 동작하지 않을 수 있습니다.
Cloudflare WAF와 속도 제한(Rate Limiting)으로 로그인 시도 제한
업로드 디렉터리에서 PHP 실행 차단: 설정 방법은 웹 서버(Apache, Nginx 등) 구성에 따라 다르므로 사용 중인 이미지의 방식에 맞게 적용

사이트가 여러 개라면(저는 3개를 운영합니다) 사이트마다 플러그인 구성이 달라 점검 누락이 생기기 쉬우므로, 한 번에 한 사이트씩 돌아가며 확인하는 목록을 만들어 두면 좋습니다.

8. 백업은 3-2-1 원칙으로, 그리고 복구까지 테스트하기

보안 사고의 최후 방어선은 백업입니다. 랜섬웨어든, 잘못된 업데이트든, 디스크 고장이든 복구 가능한 사본이 있어야 합니다.

3-2-1 원칙: 사본 3개, 서로 다른 매체 2종류, 그중 1개는 NAS 밖(오프사이트)
NAS 안의 RAID나 같은 장비의 스냅샷은 고장 대비일 뿐 침해·삭제 사고 대비로는 부족
외부 클라우드나 별도 외장 디스크로 보내는 사본은 NAS에서 쓰기·삭제가 쉽게 되지 않도록 분리(오프라인 보관 또는 별도 자격 증명)
워드프레스는 파일과 함께 DB 덤프를 별도로 백업
Vaultwarden 데이터, compose 파일, .env 설정 백업 포함. compose와 .env에는 시크릿이 들어 있을 수 있으므로 NAS 밖으로 보낼 때는 암호화와 접근 권한을 함께 고려
복구 테스트: 분기에 한 번은 다른 환경(임시 컨테이너나 테스트 폴더)에 실제로 복원해서 사이트가 뜨는지 확인

“백업이 있다”와 “복구가 된다”는 전혀 다른 이야기입니다. 복구해 본 적 없는 백업은 아직 검증되지 않은 백업입니다.

9. Uptime Kuma와 로그로 이상 징후 감지하기

Uptime Kuma는 서비스가 살아 있는지 확인하는 가용성 모니터링 도구입니다. 침입 탐지 도구는 아니므로 역할을 구분해서 쓰세요.

Uptime Kuma: 각 사이트의 HTTP 응답, 인증서 만료일, 컨테이너 포트 상태 감시 후 텔레그램이나 이메일로 알림
응답 시간이 평소보다 급격히 느려지거나 사이트가 갑자기 내려가는 경우도 보안 이상 신호일 수 있으니 알림 임계값을 설정
DSM 로그 센터와 보안 설정: 로그인 실패 알림, 자동 차단(Auto Block), 신규 관리자 로그인 알림 활성화
Cloudflare 대시보드의 보안 이벤트(Security Events)와 Access 로그를 주 1회 훑어보기
워드프레스 로그인 실패나 의심스러운 요청이 늘어나는지 확인

로그는 쌓아 두기만 하면 의미가 없습니다. 알림 → 확인 → 조치로 이어지는 흐름이 있어야 모니터링이라고 부를 수 있습니다.

10. 침해를 가정한 대응 절차 미리 만들어 두기

마지막 항목은 “뚫렸을 때 무엇을 할지”를 미리 적어 두는 것입니다. 사고가 터진 뒤에는 판단력이 흐려지기 때문에, 순서를 미리 정해 두면 피해를 크게 줄일 수 있습니다.

차단: 외부 접근을 막고 의심 시스템을 격리합니다. Cloudflare 대시보드에서 터널을 중지하거나 해당 호스트 이름 라우팅을 삭제하고, 의심되는 컨테이너를 중지합니다.
증거 보존: 로그와 필요한 증거를 삭제하기 전에 사본으로 확보합니다.
깨끗한 환경에서 재구축: 신뢰할 수 있는 이미지와 구성으로 서비스를 새로 만듭니다. 컨테이너, 애플리케이션 파일, 환경 설정이 오염됐을 수 있으므로 기존 컨테이너를 그대로 되살린 뒤 패치만 적용하는 방식은 충분하지 않을 수 있습니다.
백업 복원: 백업 데이터의 무결성을 확인한 뒤 복원합니다.
자격 증명 교체: DSM, Cloudflare, 워드프레스, DB, Vaultwarden 마스터 비밀번호와 API 토큰 중 노출됐거나 노출됐을 가능성이 있는 것을 식별해 교체합니다(깨끗한 기기에서 진행).
재개와 회고: 정상 작동과 접근 통제를 확인한 뒤 서비스를 재개하고, 원인과 재발 방지책을 기록합니다.

Vaultwarden 마스터 비밀번호를 바꾼다고 저장된 모든 계정의 비밀번호가 자동으로 바뀌지는 않습니다. 실제로 노출됐거나 노출 가능성이 있는 계정 비밀번호와 API 토큰은 따로 골라서 각각 변경해야 합니다.

이 절차를 한 장짜리 문서로 NAS 밖(종이나 별도 기기)에 보관해 두세요. NAS가 침해되면 NAS 안의 문서에도 접근할 수 없을 수 있습니다.

한눈에 보는 체크리스트

번호	항목	확인할 것
1	포트 노출	포트포워딩·UPnP, DSM 포트, IPv6와 NAS 방화벽 확인
2	관리자 경로 보호	Cloudflare Access 적용, admin-ajax.php 예외 범위 확인
3	2단계 인증	DSM, Vaultwarden, 워드프레스, Cloudflare 계정 보호
4	Vaultwarden	가입 차단, ADMIN_TOKEN, VPN 접근 검토
5	업데이트 전략	Watchtower 유지보수 종료 인지, 노출 서비스 우선 패치
6	컨테이너 권한	privileged, docker.sock, 네트워크와 시크릿 관리
7	워드프레스 설정	코드 편집 제한, XML-RPC, 사용자 정보 노출, 플러그인 관리
8	백업	3-2-1, DB 덤프, 백업 암호화, 복구 테스트
9	모니터링	Uptime Kuma 알림, DSM·Cloudflare 로그 확인
10	사고 대응	접근 차단, 증거 보존, 재구축, 자격 증명 교체

월간 점검 루틴 제안

모든 항목을 매일 확인할 필요는 없습니다. 이 정도 주기면 개인 운영 환경에서는 충분히 현실적입니다.

매주: Cloudflare 보안 이벤트, DSM 로그인 기록, Uptime Kuma 알림 이력 확인
매월: 컨테이너 이미지·워드프레스 플러그인 업데이트 점검, 사용하지 않는 계정과 서비스 정리
분기마다: 백업 복구 테스트, 포트 노출 재점검, 사고 대응 문서 갱신

마무리

개인 NAS 보안은 “완벽한 방어”가 아니라 공격 면(노출 지점)을 줄이고, 빨리 알아채고, 되돌릴 수 있게 만드는 것에 가깝습니다. 포트를 닫고(1), 앞단에서 인증하고(2·3), 패치를 놓치지 않고(5·7), 복구 가능하게 만들어 두면(8) 대부분의 일반적인 위협은 충분히 줄일 수 있습니다.

이 체크리스트는 정보보안 인증을 준비하며 접했던 접근 통제, 패치, 백업, 모니터링 같은 관리 관점을 개인 환경에 맞게 풀어 쓴 것입니다. 공식 인증 통제를 그대로 축약한 것은 아니지만, ISO 27001 인증 준비 연재와 함께 보시면 “회사에서 하는 일”과 “집에서 하는 일”이 어떻게 대응되는지 비교해 보는 재미도 있을 겁니다.

본 글의 설정 항목은 사용하는 NAS 모델, DSM 버전, 컨테이너 이미지에 따라 달라질 수 있습니다. 적용 전 공식 문서를 확인하고, 변경 전에는 반드시 백업해 주세요.