[인프라진단] #CA-18 백업 사용 여부
1. 항목 설명
클라우드 중요 데이터와 가상 리소스가 조직 정책에 따라 정기적으로 백업되고 복구 가능한지 점검하는 항목입니다.
판단 기준은 조직 정책에 따라 주기적으로 백업하는 경우 양호, 그렇지 않은 경우 취약입니다.
2026 가이드 근거

2. 점검 목적
사용자 실수, 악성 변경, 장애와 데이터 손상 발생 시 필요한 시점의 데이터로 복구해 업무 중단과 정보 손실을 줄이는 것이 목적입니다.
3. 실습 환경
- 클라우드: 개인 AWS 실습 계정
- 작업 도구: AWS Management Console, AWS CloudShell, AWS CLI
- 점검 대상: 기존 CA 실습용 비공개 S3 버킷의 테스트 객체
- 최초 상태: 버전 관리 미설정, 복구 가능한 버전 없음
- 조치 상태: 버전 관리 활성화, 동일 객체 2개 버전과 삭제 마커 생성
- 안전 통제: 비민감 테스트 파일만 사용
- 비용 주의: 이전 버전도 저장 용량과 요청 비용이 발생할 수 있어 수명 주기 정책 필요
실습·비용·안전 고지
S3 버전 관리는 객체의 변경·삭제 복구를 보여 주는 실습 통제이며 완전한 백업 전략과 동일하지 않습니다. 운영 환경에서는 별도 계정·리전, 불변성, 백업 일정과 복구 시험을 포함한 정책으로 보완해야 합니다.
4. 취약 상태 구성
실습 버킷의 버전 관리 상태와 객체 버전 목록을 조회해 버전 관리가 설정되지 않았고 복구 가능한 이전 버전도 없는 상태를 확인합니다.
aws s3api get-bucket-versioning --bucket <LAB_BUCKET>
aws s3api list-object-versions \
--bucket <LAB_BUCKET> \
--prefix <RECOVERY_TEST_KEY>
버전 관리가 없는 버킷에서는 같은 키를 덮어쓰거나 삭제했을 때 이전 내용으로 되돌릴 수 없습니다.
5. 최초진단 결과
- 최초진단 판정: 취약
- 실제 확인 결과: 버킷 버전 관리 상태 미설정
- 테스트 객체 버전: 없음
- 삭제 마커: 없음
- 영향: 덮어쓰기·삭제 이전 상태의 객체 복구를 검증할 수 없음
- 실제 최초진단 증적 파일: ca11_ca19_initial_diagnosis.txt

6. 조치 방법
버킷 버전 관리를 활성화하고 비민감 테스트 객체를 두 번 저장한 뒤 삭제해 이전 버전과 삭제 마커가 남는지 확인합니다.
aws s3api put-bucket-versioning \
--bucket <LAB_BUCKET> \
--versioning-configuration Status=Enabled
aws s3api put-object \
--bucket <LAB_BUCKET> --key <RECOVERY_TEST_KEY> --body <TEST_FILE_V1>
aws s3api put-object \
--bucket <LAB_BUCKET> --key <RECOVERY_TEST_KEY> --body <TEST_FILE_V2>
aws s3api delete-object \
--bucket <LAB_BUCKET> --key <RECOVERY_TEST_KEY>
aws s3api list-object-versions \
--bucket <LAB_BUCKET> --prefix <RECOVERY_TEST_KEY>
클라우드 콘솔 경로: S3 → 버킷 → 속성 → 버킷 버전 관리

UI 증적 수집(2026-08-25): 실제 S3 콘솔에서 실습 버킷의 버전 관리가 활성화된 상태를 확인했습니다.
7. 이행진단 결과
- 이행진단 판정: 실습 범위 양호
- 실제 확인 결과: 버킷 버전 관리 Enabled
- 복구 시험 객체: 서로 다른 2개 버전 생성
- 삭제 시험: 최신 삭제 마커 1개 생성
- 복구 가능성: 삭제 마커 아래의 이전 객체 버전이 유지됨
- 범위 제한: 단일 버킷 객체 복구 시험이며 조직 전체 백업 체계 판정은 아님
- 실제 이행진단 증적 파일: ca11_ca19_after_diagnosis.txt

8. 실무 주의사항
버전 관리는 동일 계정의 권한 오용, 계정 침해, 리전 장애와 보존 정책 오류까지 독립적으로 방어하지 못합니다. MFA Delete나 Object Lock은 제약과 사전 조건이 있으므로 도입 전에 운영 절차를 검토해야 합니다.
컨설턴트 조언
- 자산별 RPO·RTO와 데이터 등급을 기준으로 백업 주기, 보존 기간, 복사 계정·리전과 복구 우선순위를 정합니다.
- 버전 관리, 스냅샷, AWS Backup, 애플리케이션 백업의 보호 범위와 실패 시나리오를 구분해 설계합니다.
- 백업 관리자와 원본 관리자 권한을 분리하고 가능하면 별도 계정과 불변 저장소에 복사합니다.
- 백업 작업 성공 상태만 보지 말고 정기적으로 격리 환경에 복원해 데이터 정합성과 실제 RTO를 측정합니다.
- 이전 버전과 스냅샷의 저장 비용, 수명 주기, 암호화 키 보존과 삭제 보호를 함께 관리합니다.
9. 마무리
이번 실습에서는 S3 버전 관리와 삭제 복구 가능성을 실제 객체 버전으로 확인했습니다. 운영 환경의 양호 판정에는 별도 백업, 불변성, 교차 계정·리전 보호와 복구 시험까지 필요합니다.
'2026 주요정보통신기반시설 가이드 > Cloud(AWS)' 카테고리의 다른 글
| [인프라진단] #CA-19 가상 리소스 이상징후 알림 설정 (0) | 2026.08.27 |
|---|---|
| [인프라진단] #CA-17 로그 보관 기간 설정 (0) | 2026.08.27 |
| [인프라진단] #CA-16 오브젝트 스토리지 버킷 로깅 설정 (0) | 2026.08.27 |
| [인프라진단] #CA-15 관계형 데이터베이스 로깅 설정 (0) | 2026.08.26 |
| [인프라진단] #CA-14 인스턴스 로깅 설정 (0) | 2026.08.26 |