호스팅 보안 설정 8가지: 2FA·WAF·권한 2026 실전 체크리스트
호스팅 보안 설정은 거창한 보안 솔루션 도입보다 기본 항목 8가지를 빠짐없이 켜는 것에서 시작합니다. 호스팅 사고의 상당수는 제로데이가 아니라 2FA 누락, SSL 모드 오설정, 방화벽 기본 허용, 자동 패치 미적용 같은 운영 미스에서 발생합니다. 이 글은 공유호스팅·관리형 워드프레스·VPS·클라우드 어디든 공통으로 통하는 호스팅 보안 설정 8가지를 2026년 기준으로 다시 정리한 실전 체크리스트입니다.
목차
- 호스팅 보안 설정의 우선순위: 계정 → 엣지 → 오리진 → 운영
- 1) 관리자 2FA: 호스팅 보안 설정 1순위
- 2) SSL/TLS 호스팅 보안 설정: Full(Strict) + HSTS + 자동 갱신
- 3) WAF + 레이트리밋 호스팅 보안 설정: 로그인·검색·API 분리
- 4) 방화벽·보안 그룹 호스팅 보안 설정: Deny-by-default
- 5) SSH·SFTP 호스팅 보안 설정: 키 전용 + 비밀번호 차단 + root 제한
- 6) 최소 권한 + 파일 권한 호스팅 보안 설정 (644/755)
- 7) 자동 보안 패치 호스팅 보안 설정
- 8) 백업 암호화·외부 저장 + 무차별 대입 차단 호스팅 보안 설정
- 호스팅 유형별 호스팅 보안 설정 책임 범위
- 30분 호스팅 보안 설정 실행 플랜
- 호스팅 보안 설정 FAQ
호스팅 보안 설정의 우선순위: 계정 → 엣지 → 오리진 → 운영
호스팅 보안 설정을 처음부터 모두 적용하려 하면 운영이 멈춥니다. 아래 4단계 순서를 따르면 가장 흔한 공격 표면을 최단 시간에 가립니다.
- 계정 보호 — 도메인·DNS·호스팅 콘솔·관리자 계정에 2FA
- 엣지 차단 — Cloudflare 등 CDN·WAF에서 SSL Full(Strict), 관리형 룰, 레이트리밋
- 오리진 잠그기 — 방화벽 deny-by-default, SSH 키 전용, 파일/DB 최소 권한
- 운영 자동화 — 자동 패치, 백업 암호화·외부 저장, 로그·알림
한 줄 요약: 호스팅 보안 설정은 “어떤 솔루션을 쓰느냐”가 아니라 “기본 8가지를 빠짐없이 켜고, 매월 점검하느냐”의 문제입니다.
1) 관리자 2FA: 호스팅 보안 설정 1순위
OWASP는 다단계 인증(MFA)을 비밀번호 기반 공격에 대한 가장 강력한 방어로 안내하며, Microsoft 분석을 인용해 “계정 탈취의 99.9%를 막을 수 있었을 것”이라고 적습니다(OWASP Cheat Sheet). NIST도 비밀번호만으로는 부족하다고 보고 MFA를 보안 강화 핵심 항목으로 권고합니다(NIST).
2FA를 켤 계정 (우선순위 표)
| 순위 | 대상 계정 | 탈취 시 피해 | 권장 방식 |
|---|---|---|---|
| 1 | 도메인 등록기관 (가비아·Namecheap) | DNS 통째로 이전 가능 | TOTP + 백업 코드 |
| 2 | DNS·CDN 콘솔 (Cloudflare 등) | 레코드 변경·HTTPS 우회 | TOTP + 보안 키 |
| 3 | 호스팅 콘솔 (cPanel·Plesk·Managed WP) | 파일·DB 직접 변조 | TOTP |
| 4 | 워드프레스·쇼핑몰 관리자 | 웹셸·악성 스크립트 삽입 | 플러그인 + TOTP |
| 5 | 외주·팀원 계정 | 공유 계정에서 시작되는 사고 | 개인 계정 + 권한 분리 |
2FA 적용 실수 방지 팁
- 2FA 활성화 직후 백업 코드를 비밀번호 관리자나 오프라인 금고에 분리 보관합니다.
- SMS 기반 2FA는 SIM 스왑 위험이 있어 가능하면 TOTP(Authy·1Password·구글 OTP)나 보안 키(YubiKey)를 씁니다.
- 외주 작업은 계정 공유 대신 초대(Invite) + 권한 제한으로 분리하고 작업 종료 후 권한을 회수합니다.
- 관련해 IAM 권한 설계 실수와 예방책은 IAM 권한 설계 실수 TOP 10을 참고하세요.
2) SSL/TLS 호스팅 보안 설정: Full(Strict) + HSTS + 자동 갱신
HTTPS는 호스팅 보안 설정에서 사실상 기본값입니다. Cloudflare 같은 프록시를 사용한다면 브라우저↔CDN 구간뿐 아니라 CDN↔오리진 구간까지 암호화해야 중간 가로채기 위험이 사라집니다.
- Cloudflare는 Full 또는 Full (strict) 모드를 권장합니다(Cloudflare Docs).
- Full 모드 사용 전 오리진은 443에서 인증서를 제시해야 하며, 그렇지 않으면 525 오류가 납니다(Cloudflare Full).
- Full (strict)는 오리진 인증서를 더 엄격히 검증해 “검증된 오리진” 전제를 만듭니다(Cloudflare Full Strict).
- 오리진에 설치할 수 있는 Origin CA 인증서도 Cloudflare에서 무료로 발급합니다(Origin CA).
HSTS는 왜 호스팅 보안 설정 필수인가
HSTS(Strict-Transport-Security) 헤더는 브라우저에게 “이 도메인은 항상 HTTPS로만 접근하라”고 지시합니다. 이후 접속에서는 HTTP를 자동으로 HTTPS로 승격하고, 인증서 오류 우회도 차단합니다(MDN).
주의: HSTS는 잘못 켜면 되돌리기 까다롭습니다. HTTPS가 안정적으로 동작하는 것을 충분히 확인한 뒤 적용하세요(특히 includeSubDomains 옵션).
인증서 자동 갱신은 운영 필수
Let’s Encrypt 기본 인증서는 90일 유효이며, 60일마다 갱신을 권장합니다(Let’s Encrypt FAQ). 게다가 Let’s Encrypt는 2028년까지 유효 기간을 45일로 단축한다고 공지했습니다(From 90 to 45). 수동 갱신 운영은 사이트가 늘어날수록 만료 사고로 이어지고, 만료=접속 경고=매출·SEO 동반 하락을 부릅니다.
SSL 호스팅 보안 설정 점검 명령어
# 인증서 만료일 확인 echo | openssl s_client -servername example.com -connect example.com:443 2>/dev/null | openssl x509 -noout -dates # HSTS 헤더 확인 curl -sI https://example.com | grep -i strict-transport-security # 자동 갱신 cron 점검 (certbot) sudo systemctl list-timers | grep certbot
3) WAF + 레이트리밋 호스팅 보안 설정: 로그인·검색·API 분리
WAF는 “있다·없다”가 아니라 관리형 룰이 최신이고 운영자가 쉽게 만질 수 있는지가 핵심입니다.
- Cloudflare는 사전 구성된 managed rulesets로 제로데이·OWASP Top 공격·유출 크리덴셜 악용을 차단하며 룰을 정기 업데이트합니다(Cloudflare WAF).
- Cloudflare Rate limiting rules는 특정 조건의 요청에 임계치와 액션(차단·챌린지·로그)을 정의할 수 있습니다(Rate Limiting).
- WAF·DDoS 서비스 비교는 WAF DDoS 방어 서비스 비교 2026에서 정리했습니다.
레이트리밋 효과가 큰 호스팅 보안 설정 대상
| 경로 | 위협 | 권장 임계치(시작값) |
|---|---|---|
/wp-login.php, /xmlrpc.php | 크리덴셜 스터핑·브루트포스 | 5회 / 1분 / IP |
/login, /signup, /password-reset | 봇 가입·비번 재설정 남용 | 10회 / 1분 / IP |
| 검색·필터 API | 스크래핑·DB 비용 폭탄 | 30회 / 1분 / IP |
| 관리자 패널·GraphQL·REST API | 토큰 추측·자동화 공격 | 20회 / 1분 / 토큰 |
오탐 줄이는 운영 팁
- 처음에는 즉시 차단 대신 로그·챌린지·완화 모드로 1주 운영해 정상 사용자 영향을 본 뒤 차단을 강화합니다.
- 쇼핑몰은 결제·장바구니 경로에 예외 규칙을 두지 않으면 과차단으로 매출 손실이 생깁니다.
- WAF 차단 로그를 주 1회 점검해 임계치와 IP 평판 룰을 조정합니다.
4) 방화벽·보안 그룹 호스팅 보안 설정: Deny-by-default
방화벽은 가장 단순한데도 가장 큰 효과를 주는 보안 장치입니다. NIST는 네트워크 통신에서 “기본적으로 차단하고, 예외로만 허용(deny all, permit by exception)” 원칙을 명시합니다(NIST SP 800-53 SC-7).
최소 오픈 포트(일반 웹사이트 기준)
| 포트 | 용도 | 호스팅 보안 설정 권장 |
|---|---|---|
| 80 / 443 | HTTP / HTTPS | 공개 (HTTPS는 필수) |
| 22 | SSH | 내 IP만 허용 또는 VPN 경유 |
| 3306 / 5432 / 6379 | DB·Redis | 외부 차단, 같은 VPC·내부망만 허용 |
| 21 / 23 | FTP·Telnet | 가능하면 폐쇄(SFTP로 대체) |
UFW·iptables 호스팅 보안 설정 예시
# Ubuntu UFW: 모든 인바운드 차단 후 필요한 포트만 허용 sudo ufw default deny incoming sudo ufw default allow outgoing sudo ufw allow 80/tcp sudo ufw allow 443/tcp sudo ufw allow from 203.0.113.10 to any port 22 proto tcp sudo ufw enable sudo ufw status verbose
Cloudflare 우회 직격 차단
공격자는 종종 Cloudflare를 우회해 오리진 IP를 직격합니다. Authenticated Origin Pulls(mTLS)는 Cloudflare 네트워크에서 온 요청인지 오리진에서 검증해, Full·Full(strict) 위에 추가 보안 레이어를 만듭니다(Authenticated Origin Pulls).
5) SSH·SFTP 호스팅 보안 설정: 키 전용 + 비밀번호 차단 + root 제한
VPS와 클라우드 서버를 운영한다면 SSH는 필수지만, 동시에 가장 흔한 공격 표면입니다. OpenSSH sshd_config에서 PasswordAuthentication은 비밀번호 인증 허용 여부이며 기본값은 yes로 안내됩니다(man7.org). PermitRootLogin은 root SSH 로그인 허용을 제어하며 기본값은 prohibit-password입니다(OpenBSD man).
실전 sshd_config 호스팅 보안 설정
# /etc/ssh/sshd_config Port 22 PermitRootLogin no PasswordAuthentication no PubkeyAuthentication yes ChallengeResponseAuthentication no AllowUsers deploy admin MaxAuthTries 3 LoginGraceTime 30 ClientAliveInterval 300 ClientAliveCountMax 2 # 적용 sudo sshd -t && sudo systemctl restart sshd
- SSH 키 로그인으로만 접속하고, 키 분실 대비 비상 콘솔(클라우드 콘솔·KVM)을 미리 확보합니다.
- fail2ban 또는 CrowdSec로 반복 실패 IP를 자동 차단합니다.
- SFTP 사용자만 필요한 경우
chroot디렉터리로 격리해 셸 접근을 막습니다.
경고: SSH 호스팅 보안 설정은 실수하면 원격 접속이 끊겨 본인이 서버에 못 들어가는 사고가 납니다. 변경 전 스냅샷을 만들고, 콘솔 접속 수단을 확보한 뒤 새 SSH 세션으로 검증한 다음 기존 세션을 닫습니다.
6) 최소 권한 + 파일 권한 호스팅 보안 설정 (644/755)
호스팅 보안 설정에서 권한은 거의 항상 “과잉”이 문제입니다. NIST의 AC-6(Least Privilege)는 “업무 수행에 필요한 범위로만 접근 권한을 부여”하라고 명시합니다(NIST AC-6).
최소 권한이 가장 중요한 3곳
- 사람 권한 — 운영자·개발자·마케터·외주 계정의 권한을 분리하고 관리자 남발을 막습니다.
- 서비스 계정(DB) — DB 사용자는 root나 관리자가 아니라 앱별 전용 사용자에 SELECT·INSERT·UPDATE·DELETE만 부여합니다.
- 파일 권한 — 웹서버가 쓸 필요 없는 파일은 쓰지 못하도록 644(파일) / 755(폴더) 기준을 강제합니다.
DB 별도 사용자 + 최소 권한 호스팅 보안 설정 예시
# MySQL/MariaDB - 앱 전용 사용자 + 최소 권한 CREATE USER 'wp_app'@'10.0.0.%' IDENTIFIED BY 'STRONG_RANDOM'; GRANT SELECT, INSERT, UPDATE, DELETE, CREATE, ALTER, INDEX, DROP ON wp_db.* TO 'wp_app'@'10.0.0.%'; REVOKE FILE, PROCESS, SUPER, SHUTDOWN ON *.* FROM 'wp_app'@'10.0.0.%'; FLUSH PRIVILEGES;
워드프레스 파일 권한 644/755 검증
WordPress 공식 문서는 일부 파일(특히 wp-config.php)을 더 엄격히 하드닝해야 한다고 안내하며, 운영에서는 폴더 755·파일 644 조합 + 핵심 파일 별도 강화가 표준 패턴입니다. 777 권한은 절대 금지입니다(WordPress File Permissions).
# WordPress 권한 일괄 적용 (예: /var/www/wp)
cd /var/www/wp
sudo find . -type d -exec chmod 755 {} \;
sudo find . -type f -exec chmod 644 {} \;
sudo chmod 600 wp-config.php
sudo chown -R www-data:www-data .
# 권한 점검 (777 잔존 검출)
sudo find /var/www/wp -perm -o+w -type f
7) 자동 보안 패치 호스팅 보안 설정
패치는 “나중에”가 아니라 “가능하면 자동”이 호스팅 보안 설정 기본입니다. CISA는 소프트웨어 업데이트 모범 사례로 가능하면 자동 업데이트 활성화와 지원 종료(EOL) 소프트웨어 사용 금지를 권장합니다(CISA 패치 가이드).
OS·앱별 자동 패치 적용 명령어
# Ubuntu/Debian 보안 업데이트 자동화 sudo apt install -y unattended-upgrades sudo dpkg-reconfigure --priority=low unattended-upgrades # RHEL/Rocky/AlmaLinux sudo dnf install -y dnf-automatic sudo systemctl enable --now dnf-automatic.timer # WordPress 보안 자동 업데이트 (wp-config.php) define( 'WP_AUTO_UPDATE_CORE', 'minor' ); # 플러그인 자동 업데이트 (WP-CLI) wp plugin auto-updates enable --all
- 워드프레스·플러그인은 업데이트 빈도가 잦으니 스테이징 → 본서버 순으로 적용해 회귀 위험을 줄입니다.
- VPS는 OS 보안 업데이트를 자동화하거나 매주 같은 요일·시간을 패치 데이로 고정합니다.
- 지원 종료 버전은 비용 절감이 아니라 사고 비용 선결제입니다. PHP·Node·DB 메이저 EOL 일정을 캘린더에 등록해 두세요.
8) 백업 암호화·외부 저장 + 무차별 대입 차단 호스팅 보안 설정
호스팅 보안 설정의 마지막 단계는 “막는 것”보다 “망했을 때 빨리 복구”입니다. CISA 랜섬웨어 대응 가이드는 오프라인·암호화 백업 유지와 정기 복구 테스트를 권고합니다(CISA Ransomware Guide). NIST SP 800-92는 조직 차원의 효과적인 로그 관리 지침을 제시합니다(NIST SP 800-92).
백업 + 무차별 대입(rate limit) 호스팅 보안 설정 체크표
| 항목 | 최소 기준 | 도구·플러그인 예 |
|---|---|---|
| 자동 백업 주기 | 일 1회 이상 (쇼핑몰은 시간 단위) | UpdraftPlus, BackWPup, restic, AWS Backup |
| 롤링 보관 | 7 / 14 / 30일 | S3 lifecycle, Backblaze B2, Wasabi |
| 외부 저장 (오프사이트) | 다른 클라우드·다른 계정 | S3 + 다른 리전, NAS, 콜드 스토리지 |
| 암호화 | AES-256, 키 분리 보관 | restic, BorgBackup, GPG |
| 복구 테스트 | 월 1회 리허설 | 스테이징 복원, 체크섬 검증 |
| 무차별 대입 차단 | 로그인 5회/분, IP 평판 차단 | fail2ban, CrowdSec, Wordfence, Limit Login Attempts |
로그·알림 최소 세트
- 관리자·SSH 로그인 실패 폭증 알림(Slack·이메일)
- 5xx 오류 급증 알림(서버 장애·공격 신호)
- WAF 차단·이벤트 로그 주간 점검
- 디스크 80% 초과, CPU 90% 장시간 점유 알림
- DR(재해복구) 계획과 RTO/RPO 정의는 재해복구 DR 전략 가이드 참고
호스팅 유형별 호스팅 보안 설정 책임 범위
| 호스팅 유형 | 내가 직접 챙길 것 | 호스팅이 대신 처리하는 영역 |
|---|---|---|
| 공유호스팅 (cPanel·Plesk) | 2FA, SSL, 백업, WP 권한·플러그인 업데이트 | OS 패치, 서버 방화벽 일부 |
| 관리형 워드프레스 (Kinsta·WP Engine) | 2FA, 계정·권한 분리, 앱·플러그인 정책, 백업 정책 확인 | WAF·CDN·서버 튜닝, 일부 업데이트 |
| 클라우드 VM (AWS·GCP·Azure) | 방화벽·보안 그룹, SSH, 패치, 로그, 백업, 권한 | 인프라 하드웨어, 기본 네트워크 |
| VPS (직접 관리) | 8가지 항목 전부 | 거의 없음 (자유도 최고, 책임도 최대) |
제로트러스트 관점에서 호스팅 환경을 다시 설계하고 싶다면 제로트러스트 구현 가이드를 함께 읽으면 단계별 적용이 쉬워집니다.
30분 호스팅 보안 설정 실행 플랜
- 도메인·DNS·호스팅 콘솔 계정 2FA 켜기 + 백업 코드 보관
- Cloudflare 사용 시 SSL 모드 Full(Strict) 준비(오리진 인증서 확보부터)
- WAF 활성화 + 로그인·검색 경로 1~2개에 레이트리밋 시범 적용
- 방화벽 deny-by-default + SSH 22번은 내 IP만 허용
- 워드프레스 파일 권한 644/755 일괄 적용,
wp-config.php는 600 - OS 보안 업데이트 자동화 + WP 코어·플러그인 자동 업데이트
- 백업 외부 저장 + 월 1회 복구 리허설을 캘린더에 고정
- 로그인 실패·5xx 폭증·디스크/CPU 알림 채널 연결
호스팅 보안 설정 FAQ
Q1. 2FA는 호스팅 로그인에만 켜면 되나요?
먼저 도메인 등록기관과 DNS·CDN 계정에 켭니다. DNS가 넘어가면 사이트가 통째로 다른 곳으로 연결되기 때문에 호스팅 콘솔보다 DNS 계정이 1순위입니다. OWASP는 MFA를 비밀번호 기반 공격에 대한 가장 강력한 방어로 안내합니다(OWASP).
Q2. Cloudflare SSL 모드는 Flexible로 두면 안 되나요?
Flexible은 CDN과 오리진 사이 구간이 평문이라 중간 가로채기 위험이 남습니다. Cloudflare는 Full 또는 Full(strict)을 권장하며, Full(strict)이 오리진 인증서를 더 엄격히 검증해 운영 안정성과 보안 모두에서 유리합니다(Cloudflare SSL Modes).
Q3. HSTS는 처음부터 includeSubDomains를 켜야 하나요?
HSTS는 브라우저가 항상 HTTPS만 사용하도록 강제하는 헤더입니다(MDN). includeSubDomains는 모든 서브도메인이 HTTPS로 안정 운영되는지 확인한 뒤 활성화합니다. preload 등록 전에는 max-age를 짧게 두고 운영을 점검하는 것이 안전합니다.
Q4. WAF는 무료 플랜만으로도 충분한가요?
기본 방어는 도움이 되지만, 진짜 효과는 관리형 룰과 레이트리밋 운영에서 나옵니다. Cloudflare는 managed rulesets와 rate limiting rules 기능을 문서로 제공합니다(Cloudflare WAF).
Q5. 워드프레스 파일 권한 644/755가 정답인가요?
운영에서 가장 자주 쓰이는 표준 조합은 폴더 755·파일 644이고, wp-config.php는 더 엄격하게 600 또는 640으로 제한합니다. WordPress 공식 문서도 일부 파일은 별도 하드닝이 필요하다고 안내합니다(WordPress File Permissions).
Q6. SSH 호스팅 보안 설정은 VPS만 해당되나요?
공유호스팅에는 SSH가 없거나 제한적이지만, VPS·클라우드는 SSH가 1순위 공격 표면입니다. PasswordAuthentication과 PermitRootLogin은 sshd_config에서 제어합니다(sshd_config man).
Q7. 자동 업데이트는 사이트가 깨질 수 있어 무섭습니다.
CISA는 자동 업데이트 활성화와 지원 종료 소프트웨어 미사용을 권장합니다(CISA). 실무에서는 보안 업데이트는 자동으로, 기능 업데이트는 스테이징에서 검증한 뒤 수동으로 적용하는 방식이 안정적입니다.
Q8. 백업은 단순히 매일 받아두면 되나요?
CISA는 오프라인·암호화 백업과 정기 복구 테스트를 함께 권고합니다(CISA Ransomware Guide). 백업은 복구가 검증돼야 백업이고, 복구가 안 되면 그것은 위안일 뿐입니다.
호스팅 보안 설정 8가지는 한 번에 켜는 것이 아니라, 위 30분 플랜을 시작점으로 매월 한 항목씩 점검하며 다듬는 것이 현실적입니다. 사이트 매출이 클수록 사고 비용이 커지므로, 백업·로그·알림이 받쳐 주는 상태에서 다음 단계 보안 강화를 진행하시기를 추천합니다.
 | AX 100배의 법칙 – 나와 조직의 능력을 100배 높이는 AI 경영의 실제 도서 구매 |
함께 읽으면 좋은 글:
디지털 트랜스포메이션: 조직의 습관을 바꾸는 일, 도서 구매
