백업에도 보안이 필요하다

1. 백업은 제2의 원본이다

많은 사람들은 백업을 “안전한 복사본”이라고 생각한다.
하지만 실제로는 백업이야말로 정보 유출에 가장 취약한 지점이다.

• 원본보다 접근 제어가 약하거나,
• 암호화 없이 보관되거나,
• 공유 드라이브에 무방비로 저장되거나

이런 상태의 백업은 기업의 전체 데이터가 외부로 빠져나갈 수 있는 출구가 된다.
즉, 백업은 보관이 아니라 보호되어야 한다.

 

2. 백업 보안이 필요한 이유

이유 1) 백업은 외부 유출의 주요 통로

과거 실제 유출 사고 사례 중 상당수는
운영 데이터가 아닌 백업 파일을 통한 대량 정보 유출이었다.
이유는 간단하다. 백업은 모든 걸 담고 있기 때문이다.

→ 한 번 유출되면 전체 고객 정보, 내부 전략, 기술 자료가 고스란히 노출된다.

이유 2) 내부 권한 오남용

백업 디렉터리에 대한 접근 권한이 제대로 관리되지 않으면,
퇴사자, 외주업체, 비인가 직원이 복원하거나 복사할 수 있다.
백업 파일이 평문 상태라면, 데이터베이스 덤프 하나로도 모든 정보가 열려버린다.

이유 3) 백업도 랜섬웨어 대상이다

최근 랜섬웨어 공격은 운영 서버뿐 아니라 백업 볼륨까지 암호화하는 방식으로 진화했다.
백업이 보호되지 않으면, 복원 자체가 불가능해지는 ‘이중 피해’가 발생할 수 있다.

3. 백업 보안을 위한 기술 요소

1) 백업 파일 암호화

• gpg, openssl, AES256 등으로 백업 파일을 암호화
• 운영자도 키 없이는 복원할 수 없는 구조 권장

tar czf - /data | openssl enc -aes-256-cbc -salt -out backup.tar.gz.enc
openssl enc -d -aes-256-cbc -in backup.tar.gz.enc | tar xz

→ 암호화된 백업은 반드시 복호화 키 보관 정책이 함께 수립돼야 한다.

2) 접근 제어

• NAS, 외장 디스크, 클라우드 스토리지에 저장된 백업은
  백업 전용 계정만 접근 가능하도록 계정 분리
• root 사용자라고 해도 백업 디렉터리엔 바로 접근할 수 없게 하는 구조도 가능

→ 접근 제어는 기술보다 운영 정책이 핵심이다.

 

3) 접근 로그와 감사 기록

• 백업 복사, 열람, 복원 시도는 모두 로그로 남겨야 한다
• 실시간 접근 탐지 솔루션(IDS)과 연결도 고려
  
  

4. 실무 적용 전략

1) NAS 백업 보안

• 공유 폴더에 대해 IP 제한, SMB 인증, 읽기 전용 권한 설정
• 백업 스크립트는 sudo 계정 전용으로 분리
• 특정 시간 외 접근 차단 스케줄링 설정
  
  

2) 클라우드 백업 보안

• IAM 기반 접근 제어 (S3, Azure Blob 등)
• Lifecycle 설정으로 자동 암호화 및 만료 정책 적용
• 백업 파일 단위 암호화 + 객체 수준 버전 관리
  
  

3) 암호화 백업의 복구 절차도 문서화

• 암호화된 백업은 복구가 더 어렵다
• 복호화 키, 복원 명령어, 권한 확인까지 모두 체크리스트화 필요
• 키 유실 시 복구 불가하므로 키 관리 체계도 병행해야 한다
  
  

결론

백업이 있다고 해서 안전한 것이 아니다.
접근할 수 없고, 복원할 수 있어야 비로소 ‘안전한 백업’이 된다.

복원이 가능하다는 건 기술의 문제지만,
보호된 복원이 가능하다는 건 전략의 문제다.

오늘 당신의 백업은
단지 저장된 것인가, 아니면 보호되고 있는가?