모두
모두콘텐츠
얼마 전 백업이 매일 성공했다는 서버를 복구할 일이 있었다. 파일은 남아 있었지만 데이터베이스 백업은 석 달 전 것이었다. 백업 작업의 성공 표시만 보고 복구까지 된다고 믿은 셈이다. 웹서버를 오래 운영하다 보면 랜섬웨어 사고에서 가장 겁나는 순간은 암호화 화면을 봤을 때보다, 꺼내 쓸 수 있는 백업이 없다는 사실을 확인할 때다.
랜섬웨어 예방은 감염 경로를 줄이는 일과, 뚫렸을 때 서비스를 되살릴 준비를 함께 해야 한다. 비싼 보안 상품부터 살 필요는 없다. 작은 사이트라면 관리자 계정, 업데이트, 백업 권한부터 바로잡는 편이 먼저다.
서버에 들어오는 길부터 줄인다
웹호스팅은 서버 운영체제를 직접 관리하지 않는 경우가 많다. 이때는 게시판·쇼핑몰 프로그램, 플러그인, 관리자 계정이 주된 점검 대상이다. 쓰지 않는 플러그인은 비활성화만 하지 말고 삭제한다. 운영 중인 프로그램의 보안 업데이트도 미루지 않는다. 오래된 기능 하나 때문에 사이트 전체 파일에 쓰기 권한을 빼앗기는 경우가 있다.
VPS나 클라우드 서버라면 관리용 접속 범위를 더 좁힐 수 있다. 원격 관리 포트는 가능한 한 관리자가 쓰는 주소에서만 열고, 파일 전송 계정에 서버 전체 관리자 권한을 주지 않는다. 웹 서비스가 실행되는 계정에도 설정 파일과 백업 저장소를 마음대로 지울 권한이 없어야 한다. 한 계정이 뚫렸을 때 어디까지 손댈 수 있는지가 피해 범위를 가른다.
관리자 로그인에는 다중 인증을 켜고, 호스팅 관리 화면과 서버 접속 계정의 비밀번호를 따로 쓴다. 같은 비밀번호를 쓰면 사이트 관리자 화면에서 새어 나온 자격 증명이 백업까지 열 수 있다. 퇴사자나 외주 작업자의 계정도 작업이 끝나면 바로 회수한다. 접근 권한 목록을 한 달에 한 번만 확인해도 방치된 계정을 꽤 찾는다.
백업은 서버 밖에, 삭제 권한도 따로 둔다
같은 VPS 안에 백업 폴더를 만드는 것은 복구 편의를 위한 복사본에 가깝다. 운영 서버의 관리자 권한을 빼앗기면 그 폴더도 함께 지워질 수 있다. 백업은 별도 저장소로 보내고, 운영 서버가 이전 백업을 수정하거나 삭제하지 못하게 권한을 나누는 편이 안전하다. 오프라인 사본이나 일정 기간 수정·삭제를 막는 저장 방식도 선택지다. 미국 사이버보안·인프라보안국 역시 분리된 백업과 정기적인 복구 시험을 권고한다.
동기화 기능도 백업으로 오해하기 쉽다. 감염된 파일이 바로 동기화되면 정상 파일이 덮일 수 있다. 시점별 버전을 남기고 보존 기간을 정해야 사고 전 상태로 돌아갈 수 있다. 예를 들어 하루 한 번만 백업하면 사고 시 최대 하루치 변경분을 잃을 수 있다. 주문이나 예약 데이터가 그만큼 중요하다면 데이터베이스 백업 간격을 더 짧게 잡아야 한다.
백업 대상에는 업로드 파일과 데이터베이스뿐 아니라 서버 설정, 인증서 갱신 설정, 복구에 필요한 프로그램 버전도 넣는다. 다만 백업용 계정의 비밀값을 운영 서버와 같은 위치에 그대로 두면 저장소를 분리한 효과가 줄어든다. 백업 성공 알림에는 작업 완료 여부뿐 아니라 파일 크기와 최근 생성 시각을 함께 보게 해 둔다. 크기가 갑자기 작아진 백업은 성공 표시가 떠도 확인할 이유가 충분하다.
복구 시간은 실제 전송량으로 계산한다
백업이 있어도 얼마나 빨리 돌아올지는 별개다. 500GB를 실효 속도 100Mbps로 옮기면 전송에만 약 11시간이 걸린다. 여기에 새 서버 준비, 데이터베이스 복원, 파일 권한 수정, 서비스 점검 시간이 더 붙는다. 그래서 저장 용량만 보고 요금제를 고르면 장애 때 예상과 다른 복구 시간을 맞닥뜨린다.
운영 기준은 두 숫자로 적어 두면 좋다. 얼마 전 시점까지 데이터를 되돌릴 수 있어야 하는지, 서비스가 몇 시간 안에 다시 열려야 하는지다. 하루치 글 수정이 사라져도 되는 작은 블로그와 30분치 주문이 사라지면 곤란한 쇼핑몰은 백업 주기부터 달라야 한다. 비용 역시 이 기준으로 계산한다. 모든 사이트에 실시간 복제와 고가의 서버가 필요한 것은 아니다.
복구 시험은 실제로 해봐야 한다. 운영 서버와 분리된 환경에 백업을 풀고, 화면이 뜨는지뿐 아니라 로그인, 게시물, 첨부파일, 주문 기록까지 확인한다. 작은 사이트도 매달 일부 파일과 데이터베이스를 복원해 보고, 서비스 전체 복구는 정기적으로 시간을 재보면 좋다. 성공한 복구 날짜와 걸린 시간을 남기면 다음 장애 때 추측할 일이 줄어든다.
의심 징후가 보이면 확산부터 멈춘다
파일 이름이 한꺼번에 바뀌거나, 관리자 로그인이 갑자기 막히거나, 백업 삭제 알림이 뜨면 먼저 영향 범위를 확인한다. 감염이 의심되는 서버는 다른 서버와 백업 저장소에 접근하지 못하게 분리한다. 다만 무작정 초기화하면 원인과 침입 시점을 확인할 기록까지 사라질 수 있다. 접속 기록과 시스템 로그, 의심 파일의 생성 시각을 보존하고 조사한다.
비밀번호 변경은 신뢰할 수 있는 별도 기기에서 진행한다. 서버 관리자, 호스팅 관리 화면, 백업 저장소의 자격 증명을 각각 교체하고 자동 접속용 비밀값도 다시 발급한다. 복구할 때는 감염된 서버에 파일만 덮어쓰지 말고 깨끗한 환경을 만든 뒤, 침입 이전으로 확인된 백업을 가져온다. 돌아온 뒤에도 같은 취약한 플러그인이나 열린 관리 포트를 그대로 두면 다시 당할 수 있다.
제가 작은 사이트를 맡으면 먼저 백업 하나를 직접 복원해 본다. 그다음 운영 서버가 그 백업을 지울 수 있는지 확인한다. 이 두 가지가 확인되면 필요한 보안 비용과 서버 사양도 훨씬 현실적으로 잡힌다.
