공격은 매일 들어온다
서버가 인터넷에 노출되는 순간부터 스캔은 시작된다. 봇넷은 열려 있는 포트와 취약한 로그인 페이지를 자동으로 찾아다니고, 관리자가 신경 쓰지 않은 사이 오래된 계정 하나가 침입 경로가 되는 경우가 많다. 대규모 침해 사고의 상당수는 화려한 해킹 기술이 아니라 방치된 포트, 재사용된 비밀번호, 미적용 패치처럼 기본적인 허점에서 시작된다. 아래 다섯 가지는 규모와 예산에 관계없이 우선 적용할 수 있는 조치다.
1. 방화벽으로 불필요한 노출을 줄인다
서비스에 실제로 필요한 포트만 열어두는 것이 가장 기본이면서 효과가 큰 조치다. 웹서버라면 80·443 포트, 관리용 접속이라면 SSH 포트 정도만 외부에 노출하고 나머지는 전부 차단한다. 리눅스라면 ufw나 firewalld, iptables로 인바운드 규칙을 화이트리스트 방식으로 구성하고, 클라우드 환경이라면 보안 그룹(Security Group)에서 같은 원칙을 적용한다. 데이터베이스 포트(3306, 5432 등)를 외부에 그대로 열어두는 실수가 특히 흔한데, 이런 포트는 애초에 내부 네트워크에서만 접근 가능하도록 막아야 한다.
2. SSH 접근을 통제한다
비밀번호 로그인을 끄고 키 기반 인증으로 전환하는 것만으로 무차별 대입 공격(brute force)의 상당수를 무력화할 수 있다. 여기에 SSH 기본 포트(22번)를 다른 포트로 변경하면 자동화된 스캔 트래픽을 줄이는 데 도움이 된다. fail2ban 같은 도구를 함께 쓰면 로그인 실패가 반복되는 IP를 자동으로 차단할 수 있고, root 계정의 직접 로그인을 금지하고 sudo 권한을 가진 별도 계정을 쓰는 것도 기본 원칙이다.
3. 패치와 취약점 점검을 정기적으로 한다
운영체제와 웹서버, 애플리케이션 프레임워크는 취약점이 공개되는 즉시 공격 대상이 된다. 보안 업데이트는 발표 후 최대한 빠르게 적용하는 것이 원칙이고, 자동 업데이트를 켜둘 수 있는 항목은 켜두는 편이 안전하다. 점검 도구도 용도별로 나눠 쓸 수 있다. TLS 설정은 testssl.sh나 SSL Labs로, 보안 헤더는 securityheaders.com이나 curl -I 명령으로, 열려 있는 포트는 nmap으로, 알려진 CVE는 nuclei 같은 스캐너로 확인하는 식이다. 한국인터넷진흥원(KISA)도 주요 정보통신기반시설을 대상으로 기술적 취약점 분석·평가 가이드를 배포하고 있어 점검 항목을 구성할 때 참고할 만하다.
4. 다단계 인증(MFA)을 적용한다
관리자 계정 하나가 뚫리면 서버 전체가 위험해진다. 아이디와 비밀번호만으로 접근을 허용하는 대신, OTP 앱이나 하드웨어 보안키를 이용한 2단계 인증을 관리 콘솔·호스팅 패널·서버 접속 계정에 적용하면 계정 탈취로 인한 피해를 크게 줄일 수 있다. 특히 여러 관리자가 같은 계정을 공유하는 구조라면, 계정을 개별화하고 각자 MFA를 적용하는 것이 사고 발생 시 원인 추적에도 유리하다.
5. 트래픽을 모니터링하고 DDoS에 대비한다
SK쉴더스 등 보안 업체들은 최근 몇 년간 디도스(DDoS) 공격 시도가 꾸준히 증가하는 추세라고 밝히고 있다. 디도스 대응의 핵심은 장비를 갖추는 것 자체가 아니라, 트래픽 이상 징후를 실시간으로 탐지하고 즉시 대응할 수 있는 체계를 갖추는 데 있다. 평소 서비스가 사용하는 대역폭과 요청량의 평균치를 파악해두면 이상 트래픽을 훨씬 빠르게 알아챌 수 있다. 자체 대응이 어려운 규모라면 CDN이나 트래픽 스크러빙 서비스를 통해 공격 트래픽을 오리진 서버 앞단에서 걸러내는 방식도 널리 쓰인다.
호스팅 업체와 관리자의 책임을 구분한다
클라우드로 옮겼다고 서버 안의 보안까지 공급자가 모두 맡는 것은 아니다. AWS의 ‘공동 책임 모델’은 데이터센터의 물리 시설과 기반 인프라를 보호하는 일, 고객이 사용하는 데이터와 설정을 보호하는 일을 나눈다. 가상 서버인 EC2에서는 고객이 게스트 운영체제와 설치한 애플리케이션을 관리한다. 여기서 게스트 운영체제란 가상 서버 안에서 직접 사용하는 운영체제를 뜻한다.
서비스 형태가 바뀌면 책임의 경계도 달라진다. AWS는 S3 같은 추상화된 서비스에서는 인프라뿐 아니라 운영체제와 플랫폼도 운영하지만, 고객은 데이터의 관리와 접근 권한을 책임진다고 설명한다. 따라서 ‘관리형’이라는 이름만 보고 모든 보안 업무가 포함됐다고 판단해서는 안 된다. 이용 중인 상품의 문서에서 공급자가 관리하는 계층과 고객이 설정해야 하는 항목을 구분해두는 편이 좋다.
독자가 확인할 것은 작업별 담당자다. 운영체제 관리, 데이터 권한 설정, 암호화 설정을 누가 맡는지 서비스별로 기록하고, 담당자가 바뀔 때도 그 기록을 함께 넘겨야 한다. 이는 AWS가 설명하는 책임 분담을 실제 운영에 적용하는 방법이다. 서버 상품을 변경하거나 외부 운영 업체에 맡길 때도 같은 표를 다시 확인하면 관리 범위를 구체적으로 협의할 수 있다.
백업은 복구 시험까지 해야 의미가 있다
침입을 막는 조치와 함께 데이터가 훼손됐을 때 되돌릴 경로도 준비해야 한다. 미국 사이버보안·인프라보안국(CISA)의 2023년 랜섬웨어 대응 가이드는 중요 데이터의 오프라인 암호화 백업과 정기적인 복구 시험을 권고한다. 랜섬웨어가 접근 가능한 백업까지 찾아 삭제하거나 암호화할 수 있기 때문이다. 운영 서버에서 바로 접근할 수 있는 사본만 두는 것으로는 이 위험을 줄이기 어렵다.
복구 계획에는 두 가지 목표를 적어두면 좋다. 복구시간목표(RTO)는 서비스 중단부터 복구까지 허용할 수 있는 최대 시간이고, 복구시점목표(RPO)는 손실을 허용할 수 있는 데이터의 시간 범위다. AWS 지침은 이 목표를 업무 영향에 따라 정하고 복구 전략을 선택하도록 설명한다. 백업 주기만 정하기보다 주문이나 게시물처럼 어떤 데이터의 손실이 업무에 영향을 주는지 먼저 판단해야 한다.
점검할 때는 백업 작업의 성공 표시에서 멈추지 말고 실제로 데이터를 복원해 사용할 수 있는지 확인해야 한다. CISA는 복구 상황에서 백업의 가용성과 무결성을 시험하고, 시스템을 다시 구성할 운영체제·애플리케이션 이미지도 유지하도록 권고한다. 이를 바탕으로 복구 시험에서는 필요한 파일과 시스템 구성이 함께 준비됐는지, 실제 소요 시간이 정해둔 목표에 맞는지를 기록해두는 것이 좋다.
정리
서버 보안은 한 번의 설정으로 끝나는 작업이 아니다. 방화벽, 접근 통제, 패치, 인증, 모니터링을 겹겹이 쌓아두면 한 겹이 뚫려도 다음 겹에서 피해를 막을 수 있다. 예산이 크지 않은 서비스라도 위 다섯 가지는 대부분 추가 비용 없이 설정만으로 적용할 수 있는 조치이므로, 아직 점검하지 않았다면 우선순위를 두고 하나씩 확인해보는 것이 좋다.
