공인 VPS 최소 보안 기준선: 업데이트, 권한, 방화벽, 비상 구난 통로

VPS에 공인 IP가 할당되는 순간부터 전 세계에서의 무차별 자동 포트 스캔과 로그인 시도가 시작됩니다. 초보자가 흔히 저지르는 두 가지 극단은 "아무도 내 IP를 모른다"며 방치하거나, 수십 줄의 보안 명령어를 무작정 복사해 넣다가 스스로 서버에서 쫓겨나는 것입니다.

신뢰할 수 있는 운영을 위해서는 명확한 최소 보안 기준선을 수립하고, 비상 구난 수단을 유지한 채 단계별로 적용해 나가야 합니다.

1. 보안은 상호 보완하는 다계층 방어 모델이다

어느 한 계층도 단독으로 완벽한 방패가 되지 못합니다. 포트 번호 변경이 강력한 키 인증을 대신하지 못하고, 방화벽이 애플리케이션 취약점을 막아주지 못하며, 스냅샷이 독립된 외부 백업을 대체하지 못합니다.

2. 호스팅 업체 관리 계정부터 보호한다

VPS를 발급받은 후 가장 먼저 해야 할 일은 서버 내부 설정이 아니라, 가상화 인프라 전체를 쥐고 있는 호스팅 계정을 보호하는 것입니다:

• 다른 사이트와 공유하지 않는 길고 강력한 비밀번호 설정;
• 다중 요소 인증(MFA/2FA)을 활성화하고 복구 코드를 안전한 오프라인에 보관;
• 비밀번호 재설정 메일이 도착하는 계정 이메일 자체의 보안 상태 확인;
• 업체의 웹 콘솔, 구난 모드(Rescue Mode), 고객센터 URL 메모;
• 사용하지 않는 API 토큰을 삭제하고 기존 토큰 권한을 최소화.

호스팅 관리 패널이 뚫리면 OS 내부에서 설정한 모든 방어선이 무력화됩니다.

3. 공식 지원 대상 OS를 사용하고 지속적으로 패치한다

과거 블로그의 명령어가 똑같다는 이유로 이미 지원 종료(EOL)된 구버전을 설치하지 마세요. Ubuntu 등의 공식 지원 주기를 확인하여 보안 패치가 활발히 제공되는 배포판을 선택합니다.

업데이트 전 확인 사항:

1. 현재 OS 배포판 및 핵심 애플리케이션 버전; 2. 디스크 여유 공간이 충분한가; 3. 저장되지 않은 중요 데이터나 설정의 백업이 있는가; 4. 커널이나 핵심 라이브러리 업데이트 후 재부팅이 필요한가; 5. 업데이트 완료 후 서비스를 검증할 방법.

자동 보안 업데이트(unattended-upgrades)는 유용하지만, 재부팅 필요 여부와 소프트웨어 호환성 영향은 정기적으로 점검해야 합니다.

4. 일상적인 작업에서 root 계정을 계속 쓰지 않는다

root는 시스템 전체를 수정할 수 있는 절대 권한을 가집니다. 안전한 운영 원칙:

• 일반 관리용 사용자를 생성;
• 시스템 관리가 필요할 때만 sudo로 권한 승격;
• 웹 데몬이나 DB는 전용 비특권 시스템 계정으로 구동;
• 여러 서비스 간에 단일 특권 계정을 공유하지 않음;
• 퇴사자 계정, 불필요한 SSH 키, sudo 권한을 주기적으로 정리.

최소 권한의 원칙은 단일 프로세스나 자격 증명이 유출되었을 때의 피해 반경(Blast Radius)을 최소화하기 위해 존재합니다.

5. 스스로 접속 차단되는 것을 막는 SSH 강화 절차

안전한 작업 순서:

1. 호스팅 웹 콘솔에서 정상 조작 가능한지 확인; 2. 현재 접속 중인 SSH 세션을 닫지 않고 유지; 3. 일반 관리용 사용자를 생성하고 SSH 공개키를 설치; 4. 새 터미널 창을 열어 키 로그인과 sudo 권한이 정상 동작하는지 테스트; 5. sshd_config 및 인증 로그를 확인; 6. 비밀번호 인증 및 root 직접 로그인을 단계적으로 비활성화; 7. 설정 변경 시마다 새 세션을 열어 확인.

키 인증 동작이 검증되기 전에 비밀번호 로그인을 끄거나, 포트·방화벽·사용자·인증 설정을 한 번에 바꾸지 마세요.

6. 방화벽은 정말 필요한 포트만 개방한다

웹 서버와 SSH 관리만 제공하는 VPS라면 외부에 노출할 포트는 매우 적습니다. 일반적인 포트 목록을 무조건 복사하지 말고 자신의 실제 서비스에 맞게 설정하세요.

두 계층의 방화벽을 함께 점검합니다:

• 클라우드 호스팅 업체의 보안 그룹(Security Group) / 클라우드 방화벽;
• VPS 내부의 OS 방화벽 (ufw, nftables 등).

방화벽 규칙을 활성화하기 전에 현재 SSH 관리 포트가 허용되어 있는지 반드시 확인하세요. 백엔드 앱이 로컬 리버스 프록시를 통해서만 호출된다면 127.0.0.1에 바인드하고 공인 포트를 열지 않는 것이 기본입니다.

7. 포트 변경과 차단 툴은 보안의 전부가 아니다

SSH 포트를 22번에서 다른 포트로 변경하면 자동 스캐너의 무차별 대입 로그 노이즈를 줄일 수 있지만, 취약한 비밀번호를 강화하거나 시스템 취약점을 고쳐주지는 않습니다. 포트 스캐너를 돌리면 실제 리슨 포트는 금방 드러납니다.

Fail2ban 같은 도구는 반복 실패 IP를 일시 차단하는 훌륭한 보조 수단이지만, 키 인증, 시스템 업데이트, 최소 권한, 올바른 방화벽 설정을 대신할 수는 없습니다.

8. 로그, 백업, 비상 구난 통로 역시 보안의 일부다

보안 사고와 관리자 실수는 모두 "시스템이 정상 상태에서 벗어남"이라는 형태로 나타납니다:

• 최근의 의심스러운 로그인 시도나 성공 이력이 있는가;
• 핵심 데몬이 비정상 종료를 반복하고 있지 않은가;
• 디스크 사용량이 갑자기 급증하지 않았는가;
• 누가 언제 설정을 변경했는가;
• OS가 부팅되지 않을 때 웹 콘솔로 복구할 수 있는가;
• VPS가 완전히 삭제되었을 때 다른 환경에서 복원 가능한가.

동일 데이터센터 내부의 스냅샷은 편리하지만 계정이나 리전 장애의 위험을 공유합니다. 중요 데이터는 암호화하여 호스팅 외부로 격리 백업하고 복구 훈련을 거쳐야 합니다.

9. VPS 구축 후 30분 초기 보안 점검표

• [ ] 호스팅 계정에 고유 비밀번호와 MFA를 적용했는가;
• [ ] 웹 콘솔, 구난 부팅, 복구 코드를 확인했는가;
• [ ] OS가 공식 지원 기간 내임을 확인했는가;
• [ ] 보안 업데이트를 적용하고 재부팅 필요 여부를 확인했는가;
• [ ] 관리용 일반 계정을 생성하고 SSH 키 인증을 설정했는가;
• [ ] 별도 터미널에서 키 로그인과 sudo 권한을 검증했는가;
• [ ] 불필요한 포트를 닫고 최소한의 포트만 개방했는가;
• [ ] 서비스 로그와 디스크 사용량을 확인할 수 있는가;
• [ ] 외부 백업 경로와 복구 절차를 수립했는가;
• [ ] 출처 불명의 root 일괄 스크립트 실행을 지양했는가.

10. 요약

VPS의 최소 보안 기준선은 마법의 스크립트가 아니라 검증 가능한 6가지 상태입니다: 계정이 쉽게 탈취되지 않고, OS가 패치되며, 권한이 최소화되고, 인입구가 좁으며, 이상 징후가 보이고, 재해에서 복구될 수 있는 상태입니다.

구난 수단을 확보하고, 작게 수정하며, 독립 세션에서 검증한다. 동작 검증이 없는 보안 설정은 한낱 희망 사항에 불과합니다.

자주 묻는 질문 (FAQ)

개인 학습용이라 데이터가 없어도 백업이 필요한가요?

시스템 재구축 인벤토리(OS 버전, 설정 파일, 개방 포트, DNS 정의 등)는 기록해 두어야 합니다. 그렇지 않으면 장애 시 원래 환경을 신속하게 재현할 수 없습니다.

방화벽을 켜두면 모든 공격을 막을 수 있나요?

아닙니다. 방화벽은 미사용 포트를 막아줄 뿐, 개방된 웹 포트의 애플리케이션 취약점이나 계정 탈취 공격은 막지 못합니다.

유명한 원클릭 보안 강화 스크립트를 써도 되나요?

스크립트의 내용, 수정 범위, 롤백 절차를 스스로 완전히 검토하고 이해할 수 있을 때만 사용해야 합니다. 검증되지 않은 스크립트를 root로 실행하는 것은 서버의 전권을 스크립트 작성자에게 넘겨주는 것과 같습니다.

참고 자료

• Ubuntu Security: Security Updates
• Ubuntu Server: Firewalls
• Ubuntu Release Notes: 지원 릴리스
• OpenSSH: sshd_config 매뉴얼
• CISA: StopRansomware 가이드