랜섬웨어 공격 중 NAS 백업이 실패하는 이유: RAID, 스냅샷, 공유 액세스 설명

NAS의 RAID가 정상이고, 스냅샷이 예약대로 생성되며, 백업 작업이 성공하더라도 랜섬웨어 공격 후 사용할 수 있는 복구 경로가 없을 수 있습니다. 결정적인 질문은 손상되지 않은 이전 상태가 남아 있는지, 공격자가 그 상태를 변경할 수 있는지, 손상된 자격 증명이나 시스템에 의존하지 않고 복원할 수 있는지입니다.

2026년 10월 Synology 랜섬웨어 보도는 시의적절한 출발점이지만, 이는 모든 피해 사례에 대한 주장이 아니라 스토리지 아키텍처에 관한 분석입니다. RAID, 스냅샷, 동기화, 독립 백업은 서로 다른 문제를 해결합니다. 복구 경계를 잘못 이해하거나 겉보기에 분리된 복사본이 동일한 권한을 공유하면 복구에 실패합니다.

헤더 사진: Korrupt / Wikimedia Commons, CC BY 4.0. 자르고 크기를 조정했으며, 사진의 크롭된 부분에도 해당 라이선스가 적용됩니다. 문맥을 위한 NAS 하드웨어 사진이며, 피해가 확인된 기기나 사고 현장 사진은 아닙니다.

NAS 스토리지가 랜섬웨어의 표적이 되는 이유는 무엇인가요?

NAS는 네트워크를 통해 정보를 제공하며, 보통 여러 사람이나 애플리케이션, 컴퓨터가 이용합니다. 이것이 NAS의 목적입니다. 또한 원치 않는 변경이 파일에 적용될 수 있는 경로가 여러 개라는 뜻이기도 합니다. 공격자는 NAS 자체를 침해하거나, 승인된 계정을 탈취하거나, 쓰기 권한이 있는 네트워크 공유 폴더에 접근할 수 있는 워크스테이션을 장악할 수 있습니다.

이러한 침투 경로에 똑같은 방어책이 필요한 것은 아닙니다. 관리 서비스의 취약점을 패치해도 감염된 워크스테이션에 이미 부여된 공유 폴더 권한은 사라지지 않습니다. 반대로, 사용자가 쓰기 가능한 폴더를 제한해도 취약한 관리 애플리케이션이 수정되지는 않습니다. C3RB3R 및 DSM 관련 기사의 사고 분석에서는 접근 경로를 구분하는 것이 왜 중요한지 설명합니다.

복구를 위해서는 두 번째 질문이 필요합니다. 나중에 도움이 되도록 보관한 복사본까지 같은 계정이나 제어 플레인이 손상시킬 수 있나요? 그렇다면 디스크, 인클로저 또는 클라우드 저장 위치의 수가 실제 분리 수준을 과장할 수 있습니다. 복사본 수만큼이나 독립적인 장애 경계도 세심하게 따져 보세요.

RAID는 랜섬웨어로부터 데이터를 보호하나요?

중복 RAID 구성은 지정된 디스크 장애를 견디도록 설계되었습니다. 하지만 정상적으로 보이는 쓰기 작업에 유용한 문서가 들어 있는지, 암호화된 쓰레기 데이터가 들어 있는지는 판단하지 않습니다. RAID 1의 경우, 승인된 애플리케이션이 파일을 덮어쓰면 미러에도 해당 쓰기가 그대로 반영됩니다. 어레이는 정상 상태를 유지하면서도 파일은 사용할 수 없게 될 수 있습니다.

이 메커니즘은 특별한 랜섬웨어 우회 수단이 아닙니다. 미러링은 정상적인 역할을 수행합니다. 즉, 구성원 간에 현재 스토리지 상태를 유지합니다. 그렇다고 어제의 정상 버전을 선택해 복원할 수 있도록 보존하는 것은 아닙니다. RAID 0은 중복 구성이 아니며, RAID 레벨마다 장애 허용 능력이 동일한 것처럼 취급해서는 안 됩니다.

RAID는 여전히 유용합니다. 제대로 작동하는 중복 구성이라면 일반 작업 중 디스크가 고장 나더라도 서비스 중단으로 이어질 필요는 없습니다. 디스크 복원력이 과거 시점 복구, 접근 권한 분리 또는 인클로저 전체 손실에 대한 보호까지 제공한다고 기대하는 것이 문제입니다. RAID와 백업 가이드에서 이러한 차이를 더 자세히 살펴봅니다. Synology의 NAS 백업 가이드 역시 복구 사본을 별도의 계획 항목으로 다룹니다.

랜섬웨어가 NAS 스냅샷을 삭제하거나 암호화할 수 있나요?

스냅샷은 원치 않는 파일 변경에 효과적으로 대응할 수 있습니다. 많은 스냅샷 구현에서는 활성 파일을 수정해도 스냅샷에 보존된 이전 블록을 덮어쓰지 않습니다. 따라서 일반 파일 공유 권한을 가진 멀웨어가 스냅샷 관리 권한도 갖고 있다고 단정해서는 안 됩니다.

The important distinction is between changing files and controlling the mechanism that preserves earlier states. Ordinary snapshots may be deletable by a sufficiently privileged administrator. Others have additional protection. Synology documents immutable snapshots for supported systems, with time-bound restrictions that also protect containing storage structures from deletion during the applicable period. It would be inaccurate to claim administrators can always delete every snapshot.

어떤 스냅샷이 있는지, 어떤 제어 기능으로 보호되는지, 보호 기간은 언제 끝나는지 확인하세요. 보존 기간이 짧으면 피해를 알아챌 때쯤 암호화된 이후의 버전만 남아 있을 수 있습니다. 로컬 스냅샷도 별도의 물리적 장치를 만들어 주지는 않습니다. 도난, 물리적 파손 또는 기반 스토리지의 손실은 여전히 별개의 복구 문제입니다.

네트워크 백업이 함께 침해될 수 있는 이유는 무엇일까요?

주 NAS가 매일 밤 파일을 두 번째 NAS로 복사한다고 가정해 보세요. 주 시스템에 대상 위치를 덮어쓰고 이전 버전을 삭제할 수 있는 자격 증명이 저장되어 있다면, 주 시스템이 침해될 경우 두 사본 모두 위험에 처할 수 있습니다. 별도의 케이스를 사용하면 하드웨어는 분리되지만 관리 권한까지 분리되는 것은 아닐 수 있습니다.

클라우드 스토리지에도 같은 논리가 적용됩니다. 저장소가 지리적으로 멀리 떨어져 있더라도 삭제 자격 증명이 침해된 호스트에 저장되어 있을 수 있습니다. 영국 NCSC의 오프라인 백업 지침은 연결된 로컬 및 클라우드 사본과 클라이언트 접근 제어의 중요성을 다룹니다. 물리적 거리만으로는 권한이 있는 API 요청이 삭제할 수 있는 대상을 제한하지 못합니다.

네트워크 세분화는 접근 가능한 서비스를 줄이는 데 도움이 되지만, 폭넓은 권한으로 허용된 연결은 여전히 위험할 수 있습니다. 실제 작업 계정, 저장소 관리 권한, 보존 권한을 평가하세요. “다른 네트워크”와 “다른 계정”은 유용한 출발점이지만, 파괴적인 요청이 거부된다는 증거는 아닙니다.

동기화와 백업: 무엇이 다를까요?

동기화는 일반적으로 대상 위치가 원본의 변경 사항을 반영하도록 합니다. 노트북 디렉터리를 NAS와 동기화한다고 가정해 보세요. 악성코드가 노트북의 파일을 암호화하고 동기화 클라이언트가 변경된 콘텐츠를 업로드합니다. 동기화가 성공했다는 상태는 복구에 실패한 상황을 정확하게 설명할 수 있습니다. 대상 위치에 손상된 최신 파일이 그대로 저장된 것입니다.

버전 기록이나 삭제 복구 기능은 이런 결과를 개선할 수 있지만, 관련된 이전 버전에 계속 접근할 수 있어야 합니다. 보존 기간, 급격한 변경을 처리하는 방식, 공격자가 기록을 삭제할 수 있는지, 애플리케이션이 실제로 중요한 폴더를 보호하는지 확인하세요. “동기화”라는 표시만으로는 이 질문에 하나도 답할 수 없습니다.

유용한 백업 구성은 의도적으로 복구 가능한 상태를 보존하며, 이 상태는 현재 원본과 다를 수 있습니다. 문제를 발견하고 대응할 때까지 백업이 유지되어야 합니다. 계속 덮어쓰는 폴더 복사본은 이전 버전을 별도로 보호되는 제어 체계 아래 보존하는 저장소와 같지 않습니다.

3-2-1 백업 전략은 왜 중요할까요?

CISA의 데이터 백업 옵션은 익숙한 기본 원칙을 설명합니다. 작업용 사본을 포함해 중요한 정보의 사본을 3개 만들고, 저장 매체 유형을 2가지 사용하며, 사본 1개는 오프사이트에 보관하는 것입니다. 목적은 한 번의 로컬 장애로 모든 사본이 사라지는 상황을 방지하는 것입니다. 이는 유용한 목록 작성 기준이지만, 모든 공격으로부터 보호를 보장하지는 않습니다.

오프사이트는 위치를 나타냅니다. 오프라인은 연결 상태를 나타냅니다. 불변은 정해진 기간 동안 변경이 제한됨을 뜻합니다. 클라우드 저장소는 오프사이트에 있으면서 계속 접근 가능할 수 있고, 분리된 USB 드라이브는 오프라인이지만 NAS 옆에 보관될 수 있습니다. 어느 한 설명도 다른 설명을 대신할 수 없습니다.

랜섬웨어에 대비하려면 각 사본을 누가 변경할 수 있는지, 그리고 사고 기간 내내 정상 버전이 보존되는지를 확인하는 질문을 목록에 추가하세요. CISA의 랜섬웨어 지침은 오프라인 암호화 백업과 정기적인 복구 테스트를 권장합니다. 백업 암호화는 기밀성을 보호하지만, 그 자체만으로 권한이 있는 공격자가 암호화된 저장소를 삭제하지 못하게 하지는 않습니다.

백업을 진정으로 독립적으로 만드는 요소는 무엇인가요?

독립성은 복구 사본과 특정 장애 간의 관계이지, 디스크를 하나 더 구매한다고 생기는 속성이 아닙니다. 프로덕션 관리 권한이 침해되었다고 가정하는 것부터 시작하세요. 해당 관리자가 저장소를 지우거나, 보존 기간을 줄이거나, 복구 접근 권한을 취소하거나, 암호화 키의 유일한 사본을 없앨 수 있나요?

별도의 ID와 강제 적용되는 권한으로 접근 범위를 제한할 수 있습니다. 백업 작성자에게는 새 복구 지점을 만들 권한을 부여하되, 보호된 이전 복구 지점을 삭제할 권한은 부여하지 않을 수 있습니다. 저장소 관리 권한과 복구 자격 증명을 프로덕션과 분리해 보관할 수 있습니다. 제품의 실제 권한 모델을 확인하세요. 모든 프로토콜이 이러한 분리를 지원하는 것은 아닙니다.

백업 서버에서 데이터를 가져오면 일부 자격 증명을 프로덕션 NAS에서 분리할 수 있지만, “가져오기”가 본질적으로 안전한 것도 아니고 “보내기”가 본질적으로 위험한 것도 아닙니다. 자격 증명이 어디에 있는지, 각 자격 증명으로 무엇을 할 수 있는지 살펴보세요. 오프라인 상태로 순환 백업을 하려면 통제된 재연결 절차도 필요합니다. 한때 격리되었던 드라이브도 다음 백업 세션 중에는 다시 접근 가능해집니다.

백업을 복원할 수 있는지 어떻게 알 수 있을까요?

작업 완료는 작업이 완료되었다는 증거이지, 의도한 서비스를 복구할 수 있다는 증거가 아닙니다. 깨끗한 대상 환경에 복원해 테스트하세요. 대표 문서를 열어 보고, 중요한 권한을 복구하며, 애플리케이션 데이터베이스가 관련 파일과 일치하는지 확인하세요. 또한 선택한 복구 지점이 원치 않는 변경보다 이전인지 확인하세요.

복구 시점 목표(RPO)는 허용 가능한 데이터 손실 기간을 나타냅니다. 복구 시간 목표(RTO)는 서비스 복구에 허용되는 시간을 나타냅니다. 복구 지점이 손상되었거나 사용할 수 없다면, 매시간 백업을 실행한다고 해서 1시간 RPO가 보장되는 것은 아닙니다. 파일을 빠르게 복원할 수 있다고 해서 서비스 전체가 RTO를 충족하는 것도 아닙니다.

대략적인 하한 예시로, 1 Gbit/s 링크에서 10진수 기준 데이터 2 TB를 전송하는 데 완벽한 회선 이용률을 가정해도 약 4.4시간이 걸립니다. 실제 복구에는 추가 작업, 검증, 소용량 파일 처리, 애플리케이션 작업이 더해집니다. 이 계산은 NAS 벤치마크가 아닙니다. 복구 목표를 전체 워크플로와 비교해 측정해야 하는 이유를 보여 줍니다.

NIST의 백업 계획 간행물은 백업을 수행하고, 유지 관리하며, 테스트하는 일을 강조합니다. 또한 데이터 무결성 복구 가이드는 복구된 정보를 신뢰할 수 있는 상태로 만드는 것도 목표로 다룹니다. 바이트를 사용할 수 있는 것과 그 바이트를 신뢰할 수 있는 것은 서로 연관되어 있지만 별개의 결과입니다.

랜섬웨어 복원력을 갖춘 NAS 아키텍처란 어떤 모습일까요?

실용적인 설계는 하나의 기능만으로 충분하다고 선언하는 대신 여러 계층을 결합합니다. 프로덕션 공유 폴더의 쓰기 권한은 제한합니다. 지원되는 중복 RAID는 적절한 디스크 장애에 대응합니다. 스냅샷은 이전 상태를 유용하게 복구할 수 있도록 하며, 가능한 경우 보호된 보존 정책을 적용합니다. 별도로 제어하는 백업 저장소와 격리되었거나 적절히 변경 불가능한 복사본은 추가 복구 선택지를 보존합니다.

가상의 소규모 사무실에서는 실수로 편집한 내용을 복구하기 위해 짧은 간격으로 로컬 스냅샷을 만들고, 별도로 관리되는 버전 관리 저장소를 두며, 순환식으로 교체해 다른 장소에 보관하는 연결 해제된 복사본을 유지할 수 있습니다. 이 구성은 평가해 볼 만한 예시이지, 10월의 피해자에 대한 주장이나 보편적인 권장안은 아닙니다. 세부 사항은 데이터 민감도, 이용 가능한 인력, 복구 목표에 따라 달라집니다.

설계 전반에서 중요한 데이터 세트 하나를 추적해 보세요. 마지막으로 정상이라고 확인된 시점, 복원에 필요한 자격 증명, 키가 보관된 위치, 그리고 키를 읽을 수 있는 깨끗한 머신을 파악하세요. 그런 다음 프로덕션 NAS를 사용할 수 없다고 가정하고 같은 과정을 반복하세요. 빠진 단계는 백업 작업 여러 개가 초록색으로 표시된 대시보드보다 더 많은 것을 드러냅니다.

자주 묻는 질문

랜섬웨어가 파일을 변경하면 RAID 1에 암호화되지 않은 사본이 남나요?

아니요. 미러링은 일반적으로 원치 않는 변경을 포함해 충분한 접근 권한으로 수행된 현재의 쓰기 작업을 그대로 반영합니다. 미러링은 과거 시점의 사본을 자동으로 만들지 않습니다. 이전 상태를 복구하려면 남아 있는 스냅샷, 버전 관리 백업 또는 다른 적절한 소스가 필요합니다.

스냅샷은 랜섬웨어 방어에 쓸모가 없나요?

아니요. 스냅샷은 이전 상태를 보존하고 빠른 복구를 지원할 수 있습니다. 보호 수준은 권한, 보존 기간, 구현 방식 및 사용 가능한 불변성 제어 기능에 따라 달라집니다. 로컬 스냅샷은 저장 시스템과 물리적 의존성을 공유한다는 점에서 파일 수준 보호와는 다른 경계를 가집니다.

오프사이트 클라우드 백업은 자동으로 격리되나요?

아니요. 오프사이트는 다른 위치에 있다는 뜻이지, 반드시 다른 권한을 사용하거나 오프라인으로 연결되어 있다는 뜻은 아닙니다. 누가 버전을 삭제할 수 있는지, 운영 환경에서 해당 자격 증명을 보유하고 있는지, 계정이 침해된 뒤에도 보호된 백업 이력을 이용할 수 있는지 확인하세요.

백업을 암호화하면 랜섬웨어가 백업을 삭제하지 못하나요?

아니요. 암호화는 백업 내용의 기밀성을 보호합니다. 삭제 권한은 별개의 문제입니다. 저장소 권한과 보존 기간을 보호하고, 침해된 시스템에만 의존하지 않는 절차를 통해 복구 키를 사용할 수 있도록 하세요.

스냅샷과 백업 버전은 얼마나 오래 보관해야 하나요?

모든 상황에 적용되는 보편적인 기간은 없습니다. 저장 공간 제약 내에서 원치 않는 변경이 발견되지 않은 채 남아 있을 수 있는 기간, 조사에 필요한 시간 및 복구 요구 사항을 고려해 보존 기간을 정해야 합니다. 깨끗한 복구 지점을 계획하는 방법은 랜섬웨어 파일 버전 보존 가이드를 참조하세요. 선택한 정책으로 최근의 손상된 버전만이 아니라 접근 가능한 깨끗한 복구 지점을 확보할 수 있는지 테스트하세요.

가장 유용한 첫 복구 테스트는 무엇인가요?

중요한 데이터 세트를 실제 장애 상황에서 사용할 자격 증명과 도구로 깨끗한 위치에 복원해 보세요. 파일 내용, 권한, 애플리케이션 일관성 및 소요 시간을 확인합니다. 그런 다음 결과가 허용된 데이터 손실 및 서비스 중단 시간 목표를 충족하는지 확인하세요.

결론

RAID, 스냅샷 및 백업은 각각의 역할을 이해하면 여전히 유용합니다. 더 근본적인 문제는 운영 데이터와 모든 복구 수단이 하나의 파괴 권한을 공유하도록 두거나, 보관된 사본을 복원할 수 없다는 사실을 너무 늦게 발견하는 것입니다. 사본 수뿐 아니라 권한, 격리, 보존 기간 및 복구 테스트 여부도 확인하세요. Synology 사고 분석에서는 이 문제의 다른 측면, 즉 공개된 증거로 최초 접근에 관해 무엇을 확인할 수 있고 무엇을 확인할 수 없는지 살펴봅니다.