2026 웹 보안 실전 가이드

부록 A. 통합 보안 체크리스트

모든 챕터의 실행 항목을 한곳에. 신규 서버 구축 시 그대로 따라 하는 순서.

본문을 다시 펼치지 않고도 핵심을 실천할 수 있도록, 이 책의 모든 실행 항목을 한곳에 모았습니다. 각 항목 끝의 장 번호로 본문을 참조하십시오.

A.0 이 체크리스트를 쓰는 법

이 부록은 두 부분으로 구성됩니다.

첫째, 신규 서버 구축 순서 — 새 서버를 안전하게 띄울 때, 무엇을 어떤 순서로 해야 하는지를 단계별로 정리했습니다. 순서가 중요합니다. 특히 접속 경로를 다루는 부분은, 6장의 안전 원칙(자기 자신을 잠그지 않기)을 반드시 지켜야 합니다.

둘째, 정기 점검 체크리스트 — 이미 운영 중인 시스템을 주기적으로 점검할 때 쓰는 목록입니다.

각 항목은 점검의 출발점이며, 자세한 방법과 이유는 괄호 안의 장에서 다룹니다. 모든 것을 한 번에 하려 하지 말고(15장), 효과가 크고 노력이 적은 것부터 시작하십시오.

도구를 곁들인 이유: 이 부록의 여러 항목에는 그 자리에서 바로 확인할 수 있는 무료 점검 도구 링크를 달아 두었습니다. 도메인 주소만 넣으면 등급이나 빠진 헤더를 알려주는 것들이라, 설정을 마친 직후 또는 정기 점검 때 "내가 한 게 실제로 먹혔는지"를 외부 시선에서 확인하는 용도입니다. 내가 운영하는 서버를 점검할 때도 사람의 눈으로 설정 파일을 다시 읽기 전에, 이런 외부 측정부터 한 번 돌려 보는 편입니다 — 빠뜨린 것을 가장 빠르게 잡아 줍니다.

안전 원칙(반복): 방화벽과 원격 접속 설정을 변경하는 작업은 자기 자신을 서버에서 잠가 버릴 수 있습니다. 새 경로를 먼저 검증하고 옛 경로를 나중에 닫으며, 두 번째 세션을 유지하고, 자동 롤백을 걸고, 비상 콘솔을 확인하십시오(6장 6.5).

합법성 원칙(반복): 모든 스캔과 점검은 자신이 소유하거나 서면 허가를 받은 자산에만 수행하십시오. 타인 자산의 무허가 스캔은 불법입니다.

A.1 신규 서버 구축 순서

새 서버를 안전하게 구축하는 권장 순서입니다. 단계 사이에 의존 관계가 있으므로 순서를 지키는 것이 좋습니다.

1단계: 기본 설정과 인벤토리

  • [ ] 운영체제를 최신 상태로 업데이트한다. (4장)
  • [ ] 설치된 소프트웨어와 그 버전을 파악하여 인벤토리를 만든다. (5장)
  • [ ] 애플리케이션의 의존성 목록을 파악하고 알려진 취약점을 점검한다. (4장, 5장)

- 도구: 패키지에 알려진 취약점이 있는지 OSV나 GitHub Advisory Database에서 확인할 수 있습니다. 침해의 상당수는 새로운 공격이 아니라, 패치가 이미 나온 n-day(공개된 기존 취약점)를 안 막아서 일어납니다 — 2024년 xz-utils 백도어(CVE-2024-3094)처럼 의존성 하나가 통째로 위험이 되기도 합니다.

  • [ ] 불필요하게 설치된 소프트웨어와 서비스를 제거하거나 끈다(공격면 축소). (5장)

2단계: 접근 경로 확보 — SSH 공개키 전용

  • [ ] 로컬 기기에서 키 페어를 생성한다(Ed25519 권장). (7장)
  • [ ] 개인키에 강한 패스프레이즈를 설정한다. (7장)
  • [ ] 공개키를 서버에 등록한다. (7장)
  • [ ] 공개키 접속이 작동함을 별도 세션으로 확인한다(필수). (7장)
  • [ ] 확인 후, 비밀번호 인증을 비활성화한다(PasswordAuthentication no). (7장)
  • [ ] 설정 문법을 검증하고(sshd -t), 새 세션으로 접속을 재확인한다. (7장)

3단계: SSH 데몬 하드닝

  • [ ] root 직접 로그인을 차단한다(PermitRootLogin no). (7장)
  • [ ] 인증 시도 횟수와 타임아웃을 제한한다(MaxAuthTries, LoginGraceTime). (7장)
  • [ ] 유휴 세션 자동 종료를 설정한다(ClientAliveInterval). (7장)
  • [ ] SSH 접근 가능 사용자를 명시적으로 제한한다(AllowUsers). (7장)
  • [ ] 약한 암호 알고리즘을 비활성화한다. (7장)
  • [ ] 빈 비밀번호를 금지하고, 불필요한 전달 기능을 검토한다. (7장)

위 SSH 항목들의 권장 설정값은 Mozilla OpenSSH 가이드에 정리돼 있어 그대로 참고하기 좋습니다. 무차별 대입 시도를 자동 차단하려면 fail2ban을 함께 두십시오. ⚠️ SSH 설정 변경은 자기 자신을 잠글 수 있으니 위 안전 원칙(별도 세션 유지, 새 경로 먼저 검증)을 반드시 지키십시오.

4단계: 공격면 축소 — 포트 닫기

  • [ ] 내부 서비스(데이터베이스, 캐시 등)를 로컬(127.0.0.1)에만 바인딩한다. (5장, 6장)
  • [ ] 웹 서비스를 Cloudflare Tunnel로 구성한다(또는 동등한 방식). (6장)

- Cloudflare Tunnel은 서버의 인바운드 포트를 열지 않고도 외부에서 접속하게 해 주는 방식입니다. 설정은 Cloudflare Zero Trust 문서를 참고하십시오.

  • [ ] 터널 접속이 작동함을 확인한 뒤, 안전 절차에 따라 인바운드 웹 포트를 닫는다. (6장 6.5)
  • [ ] SSH를 Zero Trust Access 뒤로 옮긴다(7단계 안전 순서 준수). (6장 6.5, 6.6)
  • [ ] 자동 롤백 안전장치를 걸고 비상 콘솔을 확인한 상태에서 진행한다. (6장 6.5)
  • [ ] 오리진 IP 누출 경로(과거 DNS, 이메일 헤더, 직접 가리키는 서브도메인)를 점검하고 막는다. (6장)

- 오리진 IP란 터널·프록시 뒤에 가려져 있어야 할 실제 서버 주소입니다. 이 주소가 새어 나가면 보호막을 건너뛰어 직접 공격당할 수 있습니다. 과거 인증서 기록으로 노출된 적이 없는지 crt.sh에서, 외부에 보이는 서비스는 Shodan에서 도메인·IP로 확인할 수 있습니다.

  • [ ] 외부 포트 스캔으로 인바운드 포트가 0개임을 검증한다. (5장, 10장)

- 도구: Nmap. ⚠️ 포트 스캔은 반드시 본인 소유이거나 서면 허가를 받은 자산에만 수행하십시오(위 합법성 원칙).

5단계: 전송 계층 보안 — TLS

  • [ ] TLS 1.2 이상만 허용하고 이전 버전을 명시적으로 비활성화한다. (8장)
  • [ ] 강한 암호 스위트만 허용한다(신뢰할 수 있는 도구로 최신 권장 설정 생성). (8장)

- 도구: Mozilla SSL Configuration Generator에서 웹서버 종류와 버전을 고르면 붙여 넣어 쓸 수 있는 설정이 나옵니다. 암호 스위트(cipher suite)란 서버와 브라우저가 암호화에 합의해 쓰는 알고리즘 묶음으로, 약한 것을 끄는 일이 핵심입니다.

  • [ ] 인증서를 발급하고 자동 갱신을 설정한다(ACME). (8장)

- ACME는 인증서를 자동으로 발급·갱신하는 표준 절차입니다. 무료 발급은 Let's Encrypt를 쓰면 됩니다.

  • [ ] 자동 갱신이 작동함을 검증한다(--dry-run). (8장)
  • [ ] OCSP 스테이플링을 활성화한다. (8장)
  • [ ] 오리진 통신도 암호화되도록 한다(프록시 사용 시). (8장)
  • [ ] SSL Labs로 측정하여 등급과 지적 사항을 확인한다. (8장)

- 도구: SSL Labs SSL Test에 도메인을 넣으면 A+~F 등급과 고칠 점을 알려줍니다. 명령줄로 확인하려면 testssl.sh도 좋습니다.

6단계: 보안 헤더

  • [ ] 즉시 효과를 보는 헤더를 적용한다: X-Content-Type-Options, X-Frame-Options, Referrer-Policy, Permissions-Policy. (9장)

- 각 헤더가 무엇을 막는지와 정확한 값은 MDN 웹 문서에서 헤더 이름으로 검색하면 됩니다.

  • [ ] HSTS를 단계적으로 적용한다(짧은 max-age부터). (9장)
  • [ ] CSP를 관찰 모드로 도입하여 다듬은 뒤 강제한다. (9장)

- CSP(Content Security Policy)는 페이지가 불러올 수 있는 스크립트·이미지 출처를 제한해 XSS 피해를 줄이는 헤더입니다. 작성한 정책이 빈틈없는지 CSP Evaluator로 점검하십시오.

  • [ ] 모든 헤더에 always를 붙이고, 응답 헤더를 검증한다(curl -sI). (9장)

- 도구: securityheaders.com에 도메인을 넣으면 빠진 헤더를 한눈에 보여 줍니다. 더 자세한 점검은 Mozilla Observatory를 함께 쓰십시오.

  • [ ] (HSTS 적용 후) SSL Labs에서 A+를 확인한다. (8장, 9장)

7단계: 노출된 파일과 설정 차단

  • [ ] .git, .svn 등 버전 관리 디렉터리 접근을 차단한다. (11장)
  • [ ] .env, 백업 파일, 설정 파일 백업본의 접근을 차단한다. (11장)
  • [ ] 디렉터리 목록 표시(indexing)를 비활성화한다. (11장)
  • [ ] 운영 환경에서 디버그 모드를 끈다. (11장)

- 디버그 모드를 켠 채 배포하면 오류 화면으로 내부가 새는 데 그치지 않고, 원격 코드 실행까지 이어질 수 있습니다. 예컨대 Laravel Ignition의 디버그 모드 RCE(CVE-2021-3129)가 그랬습니다 — 운영 환경에서는 APP_DEBUG=false가 기본입니다.

  • [ ] 상세 오류 메시지가 외부에 노출되지 않게 하고, 진단·정보 페이지(server-status 등)를 제거하거나 보호한다. (11장)
  • [ ] 흔한 민감 경로의 노출 여부를 자가 점검한다. (5장, 10장)

- 도구: 알려진 노출 경로·설정 오류를 자동으로 훑어보려면 nuclei나 OWASP ZAP을 본인 자산에 쓸 수 있습니다.

8단계: 자격 증명과 권한

  • [ ] 모든 기본 자격 증명을 강한 것으로 변경한다. (11장)

- 쓰려는 비밀번호나 이메일이 과거 유출에 포함됐는지 Have I Been Pwned에서 확인하고, 길고 유일한 암호를 Bitwarden·1Password 같은 비밀번호 관리자로 생성·보관하십시오. 비밀번호 정책 기준은 NIST SP 800-63B를 따릅니다(주기적 강제 변경보다 길이와 유출 여부가 중요).

  • [ ] 하드코딩된 비밀 정보를 제거하고 환경 변수/비밀 관리로 분리한다. (11장)
  • [ ] 최소 권한 원칙을 적용한다(계정, 프로세스, 애플리케이션). (7장, 11장, 12장)
  • [ ] 민감한 파일의 권한을 엄격히 제한한다. (7장, 11장)
  • [ ] 다단계 인증(MFA)을 적용한다(가능하면 하드웨어 키). (7장, 14장)

9단계: 웹 애플리케이션 보안

  • [ ] 인젝션 방어: 매개변수화된 질의를 쓰고, 사용자 입력을 명령에 직접 잇지 않는다. (12장)
  • [ ] XSS 방어: 출력 인코딩을 적용하고, 프레임워크의 자동 인코딩을 우회하지 않는다. (12장)
  • [ ] 접근 제어: 모든 자원 접근에 서버 측 인가 확인을 두고, 기본 거부 원칙을 따른다. (12장)
  • [ ] SSRF 방어: 서버가 임의 주소로 요청하지 못하게 제한하고, 클라우드 메타데이터 접근을 보호한다. (12장)
  • [ ] 비즈니스 로직을 공격자 관점에서 검토한다. (12장)
  • [ ] 프레임워크와 의존성을 최신 패치 상태로 유지한다. (4장, 12장)

이 항목들은 OWASP Top 10의 핵심 위험과 맞닿아 있습니다. 각 방어의 구체적 코드 패턴은 OWASP Cheat Sheet Series에서 주제별로 찾아보십시오 — 현장에서 "이 입력을 어떻게 막더라"가 막힐 때 가장 먼저 펴 보는 자료입니다.

10단계: 침해 대비

  • [ ] 의미 있는 보안 사건을 로깅한다(인증, 권한, 접근, 애플리케이션, 시스템). (13장)
  • [ ] 로그를 보호하고(민감 정보 제거, 무결성, 충분한 보존) 모니터링을 갖춘다. (13장)
  • [ ] 3-2-1 규칙으로 백업한다(사본 셋, 매체 둘, 한 벌은 분리). (13장)
  • [ ] 백업을 공격으로부터 분리한다(불변/오프라인). (13장)
  • [ ] 백업 복구를 테스트한다. (13장)
  • [ ] 사고 대응의 첫 단계를 미리 정하고, 법적 신고 의무를 파악한다. (13장)

11단계: 물리·사람·자동화

  • [ ] 저장 장치를 암호화한다. (14장)
  • [ ] 소셜 엔지니어링 방어를 절차와 문화로 만든다(대역 외 확인, 빠른 보고 장려). (14장)
  • [ ] 신뢰하는 서드파티를 파악하고 그 접근을 최소화한다. (14장)
  • [ ] 정기 점검·취약점 추적·로그 분석을 자동화한다. (15장, 부록 E)
  • [ ] 정기·새 CVE·모델 업그레이드를 재점검 트리거로 설정한다. (부록 E)

12단계: 최종 검증

  • [ ] 자가 진단 다섯 영역을 모두 점검한다: TLS, 심층 TLS, 헤더, 포트·노출, 알려진 취약점. (10장)
  • [ ] 외부 시선에서 자신의 공격면을 재확인한다. (5장, 10장)
  • [ ] 인벤토리와 설정을 문서로 남긴다. (5장)

A.2 정기 점검 체크리스트

이미 운영 중인 시스템을 주기적으로 점검할 때 쓰는 목록입니다. 주기는 자원과 위험에 따라 정하되, 자동화를 적극 활용하십시오(15장, 부록 E).

매주 / 수시 (자동화 권장)

  • [ ] 보안 업데이트를 확인하고 적용한다(우선순위 높은 것 신속히). (4장, 15장)
  • [ ] 의존성의 새 취약점을 점검한다. (4장)
  • [ ] 자가 진단 다섯 영역을 자동 스캔한다. (10장)
  • [ ] 로그에서 이상 징후와 공격 패턴을 점검한다(자동 분류 + 사람 검토). (13장)
  • [ ] 인증 로그에서 비정상적 접근 시도를 확인한다. (1장, 13장)

매월

  • [ ] SSL Labs 등급이 유지되는지 재측정한다. (8장) — SSL Labs
  • [ ] 보안 헤더가 올바르게 적용되어 있는지 재확인한다. (9장) — securityheaders.com
  • [ ] 외부 포트 스캔으로 노출 상태를 재확인한다(닫힌 포트가 닫혀 있는지). (5장, 6장, 10장) — Nmap (본인 자산만)
  • [ ] 서브도메인을 재열거하여 그림자 자산이 생기지 않았는지 점검한다. (5장) — crt.sh

- 그림자 자산이란 잊고 방치된 서브도메인·서버처럼 관리 밖에서 자라난 자산으로, 공격자가 가장 먼저 노리는 빈틈입니다.

  • [ ] 백업이 정상 생성되는지 확인하고, 주기적으로 복구를 테스트한다. (13장)

분기 / 반기

  • [ ] 접근 권한을 검토하고 불필요한 것을 회수한다(특히 떠난 사람의 권한). (14장)
  • [ ] 인벤토리를 갱신한다(새 자산, 제거된 자산, 변경 사항). (5장)
  • [ ] 위협 모델을 재검토한다(자산·공격자·경로·통제의 변화). (2장)
  • [ ] 신뢰하는 서드파티의 접근과 신뢰성을 재점검한다. (14장)
  • [ ] 사고 대응 준비 상태를 점검한다. (13장)

트리거 기반 (일정과 무관하게)

  • [ ] 새 고위험 CVE 공개 시: 영향받는 자산을 즉시 식별하고 재점검한다. (4장, 부록 E)

- 모든 CVE를 똑같이 급하게 볼 필요는 없습니다. 실제로 악용되고 있는 것부터 보려면 CISA KEV(실제 악용 취약점 목록)를, 상세 정보는 NVD를 확인하십시오. 2026년 현재도 가장 흔한 침해 원인은 화려한 신규 공격이 아니라 패치가 있었는데 안 올린 경우입니다 — Citrix Bleed(CVE-2023-4966)나 MOVEit Transfer(CVE-2023-34362)의 대규모 침해가 그 교훈을 남겼습니다.

  • [ ] 시스템 변경 시(새 서비스, 설정 변경, 코드 배포): 새 노출이나 취약점이 없는지 점검한다. (5장, 10장)
  • [ ] AI 모델 업그레이드 시: 전체 서버 설정과 코드를 새 모델로 재점검한다. (3장, 부록 E)
  • [ ] 침해 의심 시: 사고 대응 절차를 가동한다. (13장)
  • [ ] 기기 분실·자격 증명 유출 시: 해당 키와 자격 증명을 즉시 폐기·교체한다. (7장, 14장)

A.3 가장 먼저 해야 할 다섯 가지

시간이 매우 부족하다면, 효과가 크고 노력이 적은 다음 다섯 가지부터 시작하십시오(15장의 우선순위 정신).

  1. SSH를 공개키 전용으로 전환하고 비밀번호 인증을 끈다. 가장 흔한 공격(무차별 대입)을 원천적으로 무력화한다. (7장)
  2. 소프트웨어를 최신 패치 상태로 유지한다. 침해의 다수를 차지하는 n-day를 막는다. (4장)
  3. 노출된 파일과 디버그 모드를 차단한다. 가장 흔한 정보 노출을 막는다. (11장)
  4. TLS를 제대로 설정한다(1.2 이상, 강한 암호 스위트). 통신을 안전하게 한다. (8장)
  5. 검증된 백업을 갖춘다(3-2-1, 복구 테스트). 최악의 경우에도 회복한다. (13장)

이 다섯 가지만으로도, 당신은 대부분의 무차별 공격의 사정권에서 벗어나, 다음 사람보다 훨씬 어려운 표적이 됩니다. 그다음, 여력이 생길 때마다 위의 전체 체크리스트로 확장하십시오. 완벽을 목표로 마비되지 말고, 가장 중요한 것부터 하나씩 — 이것이 지속 가능한 보안의 길입니다.