2.9.3 백업 및 복구관리

1. ISMS 원본

인증기준

정보시스템의 가용성과 데이터 무결성을 유지하기 위하여 백업 대상·주기·방법·보관 등의 절차를 수립·이행하여야 한다. 아울러 사고 발생 시 적시에 복구할 수 있도록 관리하여야 한다.

주요 확인사항 (KISA 안내서)

백업 대상·주기·방법·보관기간 등 절차를 수립·이행하고 있는가?
백업을 수행·관리(성공 여부 모니터링)하고 있는가?
사고 시 적시 복구를 위한 복구 절차를 수립하고 복구 테스트를 수행하고 있는가?

핵심 통제 (KISA 안내서)

백업 정책 (대상·주기·보관·소산)
백업 작업 성공/실패 모니터링·재수행
백업 매체 보관 (소산·암호화)
복구 테스트 정기 수행

결함사례 (KISA 안내서)

사례 1: 백업 실패를 모니터링하지 않음
사례 2: 복구 테스트 미수행 — 백업은 있으나 복구 검증 안 됨
사례 3: 백업 매체 암호화·소산 미흡
사례 4: 보관기간 미준수

2. ITGC 매핑

항목	값
분류	직접 (1-direct)
ITGC 영역	CO (Computer Operations)
부영역	operations
보조 영역	2.12.x (재해복구/DR), 2.9.2 (장애관리), 2.7.1 (백업 암호화)

3. IT감사에서는 이렇게

3-A. 한국 비금융 ITGC 실무 표준 (실제 검증 범위)

ITGC CO에서 백업은 재무데이터의 가용성·무결성 통제다. 핵심 질문: "재무시스템 데이터가 백업되고, 실패 시 감지·조치되며, 실제 복구가 검증되는가." 백업의 존재만으론 부족하다 — 복구 검증이 급소.

테스트는 design(설정이 적정한가) 과 operating(운영이 적정한가) 으로 나눠 본다. 설정만 보고 끝내면 안 되고, 로그로 실제 운영을 확인해야 한다.

ISMS 요구	ITGC 테스트 절차	성격	모집단 / 샘플
백업 설정·스케줄	백업 정책(주기·대상)이 RPO·데이터 특성에 맞고, 그대로 job·스케줄이 걸렸나 (자동/수동 무관)	design	in-scope 시스템 / 설정 확인
백업 수행·실패 모니터링	기간 내 백업 로그 → 성공/실패 식별 → 실패 시 재수행·조치 증적	operating	샘플링
복구 테스트	복구 테스트 수행 증적·성공 결과	operating	복구 테스트 이력 / 일반적으로 1건임->전수
백업 보관	보관기간·소산·암호화 정책 이행	walkthrough	설정내역 캡쳐

백업 주기는 RPO(목표 복구시점)에 종속된다 — 매일이 디폴트가 아니다. 변경 잦은 재무 거래 DB는 일 백업 + 트랜잭션 로그 백업이 흔하고, 변경 드문 마스터·파일은 주간/월간으로 충분하다. 매일 백업이 과한 대상도, 일 1회론 부족한 대상도 있다. 감사인은 주기 숫자를 평가하지 않는다 — 정책이 데이터 특성·RPO에 맞게 주기를 정의했고, 실제 그대로 수행되나를 본다.

백업은 배치 스케줄링(CO operations) 과 직결된다. 백업 job이 스케줄러에서 정상 동작하고, 실패 시 알림·재수행되는 사이클이 통제의 실체다. 자동이 유리하지만 요건은 아니다 — 수동 백업도 통제로 인정되며, 다만 "수행의 완전성"확인이 필요하다.

복구 테스트가 핵심인 이유: 백업 파일이 있어도 복구가 안 되면 통제 실패다. 복구 테스트가 검증하는 건 OS의 복구 능력이 아니라 백업의 유효성·완전성이다 — 윈도우든 리눅스든 무관. 실제로 잡는 리스크:

백업 성공 로그 ≠ 복구 가능 — job이 "성공" 이나 파일이 silent corruption이거나 일부만 백업됨
백업 범위 누락 — 새로 생긴 DB·디렉토리가 대상에서 빠짐. 설정만 봐선 안 잡힘
증분 체인 끊김 — full+incremental에서 중간 백업 하나 깨지면 전체 복구 불가
암호화 키·복구 절차 분실 — 막상 복구하려니 키·절차가 없어 RTO 미달

"백업은 100% 성공인데 막상 복구하니 안 되는" 게 실무에서 제일 흔한 백업 결함이다. 그래서 감사인은 "복구를 실제로 했고 성공했는가" 증적확인이 필요함.

3-B. ISMS-P가 추가로 요구하지만 ITGC 실무 범위 밖

ISMS 요구	절차	어디 영역
백업 인프라 기술 상세	스토리지·테이프 구성	운영 영역 (기술 점검)
DR/BCP 전체 체계	재해복구 계획·모의훈련	2.12.x 재해복구
백업 데이터 암호화 알고리즘 적정성	암호화 방식·키 관리	2.7.1 암호정책

4. Q&A

Q1. 백업이 돌고 있으면 통제 OK인가?

A. 아니다. 모니터링 + 복구 테스트까지 봐야 통제가 유효.

백업 성공 모니터링(실패 감지·재수행) + 복구 테스트 둘 다 있어야 함
둘 중 하나라도 없으면 미흡 — 특히 복구 테스트 없는 백업은 "검증 안 된 백업"

Q2. 백업이 반드시 자동이어야 하나?

A. 아니다. 수동 백업도 통제로 인정된다.

ITGC는 자동/수동을 따지지 않는다 — "주기대로 수행되고 누락·실패가 감지·조치되나"가 질문
단 수동이면 검증 부담이 수행 완전성으로 옮겨간다 — 자동은 스케줄 설정 + 전체 job 로그로 완전성이 쉽게 입증되지만, 수동은 완전성 확인이 필요해서 백업 대장·확인자 서명의 완전성 확인이 필요함.

Q3. OS가 튼튼하면(윈도우 등) 복구 실패확률이 낮으니 복구 테스트 생략 가능?

A. 아니다. 복구 테스트는 OS 복구 능력이 아니라 백업의 유효성·완전성을 검증한다.

윈도우든 리눅스든 무관 — 잡는 리스크가 OS가 아니라 백업 쪽이다
백업 성공 로그 ≠ 복구 가능: silent corruption, 백업 범위 누락, 증분 체인 끊김, 암호화 키·절차 분실
"백업 100% 성공인데 복구는 안 되는" 게 제일 흔한 백업 결함
단 중요도 차등은 합리적 — 재무 핵심 DB는 복구 테스트 필수, 단순 파일서버는 경량으로. "윈도우라 생략"은 아님
주기: 법정·표준 절대 주기 없음. 회사 정책(통상 연 1회 이상). ITGC는 주기 숫자보다 "정기 수행·성공 증적"을 본다. 감사기간 내 한 번도 안 했으면 결함

Q4. 클라우드 자동백업(RDS 스냅샷 등)이면?

A. 자동백업 설정·보관주기 확인 + 복구(restore) 테스트 증적.

자동백업 활성화·보관주기·리전 설정 확인
자동이라도 복구 검증은 별도 — 스냅샷에서 실제 restore 해본 증적이 있나
"관리형 서비스라 알아서 된다"는 복구 검증을 대체하지 않는다