랜섬웨어 대비 : 백업 저장소 권한 분리(Immutable 개념)

• 도메인/관리자 계정 탈취 → 백업 서버/스토리지 접속

• 백업 스케줄·정책 변경 → 보존기간 단축, 스냅샷 삭제

• 백업 파일 암호화 또는 삭제 → 복구 실패 유도

• 최종 암호화 실행 → 운영 중단 + 몸값 요구

• ① 백업 계정이 “관리자급” 권한을 가지면 공격자가 동일 권한으로 백업을 삭제할 수 있다.

• ② 백업 저장소가 운영망과 동일 인증/동일 관리 도메인에 있으면 횡이동 경로가 짧아진다.

• ③ 스냅샷·버전이 있어도 “삭제 권한”이 공격자에게 넘어가면 보존 체인이 끊긴다.

• ④ Immutable(오브젝트 락/WORM) 같은 강제 제약이 없으면 정책은 설정값일 뿐이라 변경으로 무력화된다.

• ⑤ 복구 테스트를 안 하면 RPO/RTO가 문서에만 존재하고 실제로는 복구 불가 상태가 된다.

• ⑥ 이상징후 알림이 없으면 “백업 정책 변경/대량 삭제”를 사후에야 발견해 대응이 늦어진다.

1. 계정 분리(Identity 분리)

• 운영 관리자(운영 서버 관리) ≠ 백업 운영자(백업 정책 관리) ≠ 감사/승인자(보존 변경 승인)

• 특히 백업 작업 계정은 “쓰기(put)”만 갖고 “삭제(delete)”는 갖지 않는다.

2. 경로 분리(Network 분리)

• 운영망에서 백업 저장소로의 접근은 백업 서버/백업 프록시 1개 경로만 허용

• 백업 저장소 관리 콘솔/관리 API는 운영망이 아닌 별도 관리망(VPN/PAW)에서만 접근

3. 권한 분리(Storage 권한 분리)

• 저장소 버킷/볼륨은 “백업 전용”으로 만들고, 운영 서버 계정이 직접 마운트/열람하지 못하게 한다.

• 백업 리포지토리에는 “변경 정책(Immutable/락)”을 강제 적용한다.

• 오브젝트 스토리지: Object Lock / WORM / Compliance 모드(보존기간 동안 관리자도 삭제 불가 구성 가능)

• 파일/스토리지: 스냅샷 보호(삭제 제한), “보존 기간 잠금”, 리포지토리 잠금

• 백업 솔루션: Immutable Repository, Hardened Repository(전용 OS/계정), Air-gapped 기능

버전관리는 Immutable을 보조한다.

• 버전(Versioning) : 같은 파일이 변경돼도 이전 버전이 남아 복구 지점을 확보한다.

• 다중 사본(3-2-1 확장) : 로컬 1 + 별도 스토리지 1 + 오프사이트/클라우드 1 (최소 3복제)

• 보존 기간 분리 : 일간(14일) / 주간(8주) / 월간(12개월)처럼 공격자가 한 번에 지우기 어렵게 계층화

1. 백업 전용 계정 새로 만들기(최소 권한)

• 권한: 백업 쓰기(업로드/쓰기)만 부여, 삭제·정책변경 권한 제거

• 로그인: MFA 필수, 비대화형(키/토큰) 사용 시 주기 30일 로테이션

• 분리: 운영 관리자 계정과 동일 비밀번호/동일 SSO 그룹 금지

2. 리포지토리에 Immutable/버전관리 켜기

• 보존 기간: 일간 14일, 주간 8주, 월간 12개월(예시처럼 계층화)

• Immutable 모드: “보존기간 동안 삭제 불가”가 강제되는 모드로 적용

• 버전관리: 버킷/리포지토리 버전 활성화 + 수명주기 정책(Lifecycle)로 자동 정리

3. 이상징후 알림 + 변경 승인 흐름 넣기

• 알림 대상: “보존기간 변경”, “백업 정책 비활성화”, “대량 삭제”, “실패율 급증”

• 승인: 보존기간 단축/락 해제는 2인 승인(백업 운영자 + 승인자)

• 로그: 백업 저장소 접근 로그를 중앙 로그(SIEM/로그 서버)로 전송

• RPO 목표: 24시간(일간 백업 기준) / 중요 시스템은 4시간(증분·스냅샷 기준)

• RTO 목표: 핵심 서비스 2시간 내 기동, 전체 복구 24시간 내(예시)

• 복구 리허설 주기: 월 1회(최소), 분기 1회는 “격리된 테스트 존”에서 랜섬웨어 가정 복구

테스트 절차(최소 30분 코스)

1. 랜덤 백업 1개 선택 → “삭제/변경 시도”가 거부되는지 확인(Immutable 검증)

2. 파일 100개 복구 → 해시(예: SHA-256) 10개 샘플로 무결성 확인

3. 복구 시간 측정 → 10GB 복구에 걸린 시간(분) 기록, 목표 대비 편차 10% 이내 유지

• 백업 보존기간이 단축되거나 Immutable 정책이 변경됨

• 10분 내 삭제/만료 이벤트가 평균 대비 5배 급증

• 백업 실패율이 연속 3회 발생

• 백업 계정 로그인 지역/기기 지문이 평소와 다름

• 백업 정책이 비활성화되거나 스케줄이 비정상적으로 변경됨

• 관리 작업은 전용 단말(PAW)로만 : 백업 콘솔 접근은 이메일/웹서핑용 PC에서 금지

• Break-glass 계정은 오프라인 보관 : 비상 계정은 평소 로그인 금지 + 금고 보관 + 사용 시 기록

• 백업 저장소는 “읽기”도 최소화 : 운영 서버가 백업을 열람할 이유가 없게 설계

• 락/보존 변경은 티켓 필수 : 변경 이력(누가/언제/왜)을 남기면 내부 사고도 줄어든다

• 오프사이트 1개는 ‘다른 인증 체계’ : 같은 SSO/같은 AD에 묶이면 분리 효과가 급감한다

• 백업 전용 계정을 새로 만들고 삭제 권한을 제거했다

• 백업 저장소에 Immutable(변경 불가) 보존기간을 적용했다

• 버전관리/스냅샷을 켜고 보존 계층(일/주/월)을 분리했다

• 보존기간 변경·대량 삭제·실패율 급증 알림을 설정했다

• 월 1회 복구 리허설로 RPO/RTO를 기록하고 있다

• “백업 서버 관리자 = 도메인 관리자”로 두는 실수: 한 번 뚫리면 백업까지 같이 뚫린다.

• Immutable 보존기간을 너무 짧게 설정: 최소 14일은 강제하고, 주간/월간은 더 길게 가져간다.

• 알림을 ‘백업 실패’만 두는 실수: 랜섬웨어는 실패가 아니라 정책 변경/삭제로 먼저 흔든다.

• 복구 테스트를 생략: 백업은 “있다”가 아니라 “복구된다”가 기준이다.

• 계정 분리만 하고 네트워크/관리 경로를 그대로 두기: 콘솔이 같은 망이면 공격 표면이 커진다.

• 백업은 저장 위치가 아니라 권한 구조와 Immutable(변경 불가) 제약으로 지킨다

• 백업 전용 최소 권한 계정 + 보존기간 락 + 버전관리로 삭제/덮어쓰기를 구조적으로 차단한다

• 정책 변경/대량 삭제/실패율 급증 알림과 월 1회 복구 테스트로 “복구 가능”을 숫자로 유지한다