랜섬웨어 예방 방법 서버에서 실천하려면

얼마 전 복구 문의를 받은 VPS는 백업 작업이 매일 성공으로 표시돼 있었다. 그런데 백업 파일이 원본 서버에 붙은 저장 공간에 있었다. 공격자가 관리자 계정을 가져가면 원본과 백업을 함께 지울 수 있는 구조였다. 랜섬웨어 예방 방법을 묻는다면 나는 백신보다 먼저 계정 권한과 백업 위치를 확인한다.

서버에 들어오는 경로부터 줄인다

작은 웹사이트라도 호스팅 관리 계정, 원격 접속 계정, CMS 관리자 계정은 따로 있다. 이 중 하나가 뚫리면 서버 파일뿐 아니라 백업 설정까지 바뀔 수 있다. 관리 계정에는 다중 인증을 켜고, 사람마다 계정을 나눠 쓴다. 퇴사자나 외주 작업자의 계정은 작업이 끝난 날 회수하는 게 좋다.

VPS라면 원격 접속을 인터넷 전체에 열어둘 이유가 있는지 확인한다. 접속할 관리 장소가 정해져 있다면 허용할 IP를 제한하고, SSH는 키 인증을 사용한다. 운영에 필요하지 않은 원격 데스크톱과 관리 포트는 닫는다. 공유 웹호스팅에서는 이런 설정을 직접 바꾸기 어려우니 호스팅 관리 화면의 다중 인증과 접속 기록부터 챙기면 된다.

권한도 좁혀야 한다. 웹서버 프로세스가 사이트 전체 파일에 쓰기 권한을 가질 필요는 없다. 업로드 폴더와 캐시 폴더처럼 실제로 기록이 필요한 곳만 허용한다. CMS 관리자에게 서버 최고 권한을 주거나 여러 사이트가 하나의 관리자 계정을 공유하면, 한 곳의 침해가 다른 곳으로 번지기 쉽다.

백업은 원본 서버와 떨어뜨려 둔다

서버 업체가 제공하는 스냅샷은 장애 복구에 유용하다. 다만 같은 관리 계정으로 스냅샷을 삭제할 수 있다면 랜섬웨어 대비책으로는 부족하다. 백업은 별도 계정이나 별도 저장소에 보내고, 원본 서버에 저장소의 삭제 권한을 주지 않는 편이 안전하다. 가능하다면 일정 기간 수정·삭제를 막는 보관 기능을 사용한다. CISA도 접근 가능한 백업이 공격 과정에서 삭제되거나 암호화될 수 있어 격리된 백업과 복구 시험을 권고한다.

웹사이트 백업에는 파일만 들어가면 안 된다. 게시글과 주문 정보가 담긴 데이터베이스, 업로드 파일, 복구에 필요한 설정을 함께 챙겨야 한다. 반대로 비밀번호와 인증 키를 백업 파일 옆에 평문으로 두면 백업이 유출됐을 때 피해가 커진다. 백업 저장소 접근 권한과 암호화 키 보관 장소도 분리한다.

주기는 사이트의 변경량으로 정한다. 하루에 글 한 편 올라오는 블로그와 주문이 계속 쌓이는 쇼핑몰의 허용 가능한 데이터 손실은 다르다. 예를 들어 하루치 손실을 감당할 수 있으면 일일 백업을 검토할 수 있지만, 주문 기록을 한 시간 이상 잃을 수 없다면 그보다 촘촘한 데이터베이스 백업이 필요하다. 백업 파일 개수보다 실제로 몇 시점까지 되돌릴 수 있는지가 중요하다.

업데이트와 복구 시험을 일정에 넣는다

운영체제, CMS, 플러그인, 관리 도구의 보안 업데이트를 미루면 알려진 취약점이 그대로 남는다. 자동 업데이트를 쓸 수 있는 범위는 켜고, 사이트 동작에 영향이 큰 업데이트는 점검 시간을 잡아 적용한다. 지원이 끝난 플러그인은 최신 서버 위에 올려도 위험하다. 사용하지 않는 구성요소는 지우는 편이 관리하기도 쉽다.

백업 성공 알림만으로 안심하지 않는다. 별도 시험 환경에 파일과 데이터베이스를 복원해 로그인, 게시글, 업로드 파일이 정상인지 확인해야 한다. 복원에 필요한 계정과 암호화 키가 실제로 준비돼 있는지도 봐야 한다. NIST가 백업뿐 아니라 복원 절차의 정기적인 시험을 강조하는 이유다. 작은 블로그라면 분기마다 한 번씩 복원해 보는 일정부터 잡아도 운영상 큰 차이가 난다.

이때 걸린 시간을 기록해 두면 장애 대응 기준이 생긴다. 20GB 백업을 내려받고 검사하고 서비스를 다시 여는 데 4시간이 걸렸다면, 요금제 설명의 ‘즉시 복구’보다 그 기록이 훨씬 현실적인 예상치다. 서버 사양을 올려도 복원 절차가 느리면 중단 시간은 크게 줄지 않는다.

의심 징후가 보이면 복구보다 범위를 먼저 확인한다

파일 확장자가 갑자기 바뀌거나, 관리자 로그인 기록에 낯선 접속이 보이거나, 백업 작업이 예고 없이 중단됐다면 침해를 의심해야 한다. 먼저 해당 서버의 외부 연결을 제한해 확산을 막고, 관리 계정과 백업 계정의 세션·접근 권한을 점검한다. 감염된 서버 위에 백업을 바로 덮어쓰면 침입 경로가 남아 다시 피해를 입을 수 있다.

로그와 감염 시점을 확인한 뒤 깨끗한 서버를 새로 만들고, 침해 이전으로 확인된 백업을 복원하는 순서가 안전하다. 그 사이 노출됐을 수 있는 비밀번호와 키도 교체한다. 고객 정보가 있었다면 유출 여부를 별도로 조사해야 한다. 암호화된 파일을 복구했다고 정보 유출 가능성까지 사라지는 것은 아니다.

비싼 서버나 보안 상품을 먼저 살 필요는 없다. 작은 사이트도 관리 계정을 나누고, 백업을 서버 밖에 두고, 한 번 복원해 보는 것부터 시작할 수 있다. 14년간 운영하며 본 사고 중에는 자원 부족보다 이 세 가지를 놓쳐 복구가 길어진 경우가 더 많았다.