정보 보안 거버넌스 8. Business Continuity Planning(업무 연속성 계획)

목차

1. BCP와 DRP

1-1. BCP와 DRP

2. BCP(업무 연속 계획)

2-1. BCP

2-2. 범위와 계획 초기화

2-3. 사업 영향 평가(BIA)

2-4. 사업 지속 개발 계획

2-5. 구성 요소

3. DRP(재해 복구 계획)

3-1. DRP

3-2. 복구 목표 시점(RPO)과 복구 목표 시간(RTO)

3-3. 재해 복구 계획 프로세스

3-4. 재해 복구 계획 테스트

3-4. 재해 복구 프로시저

 

1. BCP와 DRP

1-1 .BCP와 DRP

BCP 프로세스에 포함되는 요소 
- 범위와 계획의 초기화
- 사업 영향 평가 (Business Impact Assessment : BIA)

  -> BSP와 DRP는 BIA의 내용을 근거로 상세하게 세워져야 함 
- 사업 지속 개발 계획

 

DRP는 프로세스에 포함되는 요소 
- 재해 복구 계획 프로세스
- 재해 복구 계획 테스트
- 재해 복구 절차

 

재해(정보 자원의 사용 불능으로 발생하는 비즈니스 중단 사태)

- 자연 재해 : 정보 처리 시설에 직접적인 피해
- 통신, 전기, 가스등의 기반 서비스 중단
- 테러, 바이러스(현실 세계의) 등으로 인한 재해
- 사람에 의한 예측 불가능한 실수  

- 재해 상황이 BCP나 DRP를 실행할 심각한 중단 상황인지 판단하기 위해 위험 기반 분류 시스템(risk classification system) 필요.

  -> BCP와 DRP는 선조치 후보고 시스템

 

계획의 요소
- 재해 이전 준비
- 대피 절차

  -> 가장 비용이 크고 손실시 피해가 큰 자원이 사람이기 때문에 

- 재해 선언 절차
- 재해 선언 상황 판단 기준 
- 책임 및 책임자
- 명확한 계약 정보

  -> BCP와 DRP는 계약에 의해서 움직임
- 복구 대안의 단계별 설명
- 복구 및 지속 운영에 필요한 자원 식별

 

2. BCP(업무 연속 계획)

2-1. BCP

목적
- 조직의 생존을 위해서 핵심적인 기능 및 운영이 예기치 못한 중단으로부터 보호 될 수 있도록 하는 것.

 

발생 가능한 여러 종류의 위험
- 고객 서비스 중단
- 이미지 및 브랜드 손실
- 지적. 인적 자산 보호 실패
- 비즈니스 통제 상실
- 법률적 요구 사항 위반

  -> 준법 감시인이 담당

- 위험은 모두 정량적 측정 가능

 

BCP의 책임
- 고위 경영진

  -> 회사의 생존과 자산보호의 책임을 위임 받음

 

BCP의 구성
- 재해 복구 계획 + 사업 운영 연속성 확보 계획

 

중점 고려 사항
- 조직의 생존에 가장 필요한 핵심 사업 영역(identity) 

- 핵심 사업 영역을 지원하는 물적, 인적 자원

- 사업 연속성 계획은 위험 분석을 기반으로 수행하며 이를 위해서 자산을 고려한 위협 식별작업이 필요.
- 위험은 자산 가치와 인지된 위협이 발생될 비율에 비례한다.
  -> 손실액(SL) * 발생 가능성(ARO) 
- IT 재해 복구 계획

  -> 사업 연속성 계획의 하위 요소, 기술문서.
- 모든 복구 계획의 기준은 비용 편익이다.
  -> 절대 비용(cost)이 편익(benefit)을 초과해서는 안 된다.

 

BCP의 네가지 구성 요소
- 범위와 계획의 초기화
- 사업 영향 평가 (Business Impact Assessment : BIA)
- 사업 지속 개발 계획
- 계획 승인과 구현

  -> 구현은 계속해서 개선해 나가는 일련의 과정을 의미

 

BCP 구현 및 운영 과정
1. 사업 연속성/재해 복구 정책 수립
2. 사업 영향 분석
3. 사업 연속성 계획과 재해 복구 절차 수립
4. 훈련과 인식 프로그램

  -> work through : 무엇을 할지 연습해 보는 것(가장 비용 효과적)
5. 계획 테스트 및 실행
6. 모니터링

  -> 실제로 재해가 발생하는지 계속 확인

  -> 계획이 차질없이 계속 지속될 수 있는지 확인 

 

2-2. 범위와 계획 초기화

BCP 프로세스의 개시

 

역할과 책임을 식별
- 최고 경영진

  -> 프로젝트의 개시, 최종승인, 지속적인 지원 책임
- BCP 위원회

  -> 계획 구현, 테스트를 지휘
- 단위 사업 관리자

  -> 이사를 의미 

  -> 핵심 프로세스의 정의와 우선 순위 부여
- 기능 사업 부서

  -> 각 부서의 부서장을 의미

  -> 구현과 테스트에 참여

 

2-3. 사업 영향 평가(BIA)

세가지 주요 요소 
1. 핵심 우선 순위 결정
  -> 모든 핵심적인 단위 프로세스를 식별하고 파괴적 사건에 대한 영향을 평가해야 한다.
2. 중단시간 산정(MTD, Maximum Tolerable Downtime)

  -> 견딜 수 있는 시간
  -> 핵심 프로세스가 중단된 채로 조직이 회생불능에 빠지기 까지 견딜 수 있는 시간을 산정
  -> 일반적인 측정치는 기대치에 비해서 무척 짧다.
3. 지원 요구사항
  -> 핵심 프로세스를 복구하는데 필요한 자원 요구 사항

  -> 가장 중요한 자원인 인적 자원을 어떻게 확보하느냐가 중점

  -> 기업간 상호 협력 조합에 인적 자원도 포함되는 경우가 많음

 

BIA 수행하는 접근 방법
- 설문지
- 인터뷰
- 회의
- 시스템 관련 BIA에서는 과거의 트랜잭션량을 분석, 그 결과는 인터뷰 단계에서 실증.

 

취약성(위험성) 평가
- 위험 평가 방법
  -> 정량적(경제적 측면) 
  -> 정성적(운영 측면) 
- 정량적 손실 기준이 필요 
  -> 매출 손실 및 추가 부채에 대한 비용
  -> 사건 복구 비용
  -> 법적인 비용 (계약의 위반, 법률 위반)
- 정성적 손실 기준
  -> 시장 점유율 감소
  -> 신뢰도, 공신력 감소

- 취약성 평가를 기반으로한 핵심 지원 영역에 대한 정의가 중요

  -> 핵심 비지니스 영역

 

문서화
- BIA의 마지막 단계
- 모든 프로세스와 프로시저, 분석 결과의 완전한 문서화가 중요
- 적절한 고위 경영진에 대한 권고사항 프리젠테이션
- 보고서에는 식별된 핵심 지원 영역과 양적인 영향을 종합하고 권고된 복구 우선순위가 포함되어야 함

 

2-4. 사업 지속 개발 계획

- BIA로부터 도출된 핵심 사업 기능을 지원하기 위한 비상계획과 전략을 세운다.
- 두 가지 중요한 단계를 포함.
  -> 지속 전략 계획

  -> 지원과 장비 계획
- 지속적인 문서 전략

  -> 지속 전략 계획의 각각의 결과에 대한 완전한 문서화
- 계획의 전사적 파급을 위한 인지도 향상
  -> 양질의 훈련과 교육(work through) 
- 계획의 유지 보수
  -> 최신의 버전이 유지되도록 업데이트.
  -> 컴퓨팅 환경의 변화 등등 여러가지가 원인

 

2-5. 구성 요소

- 시스템, 사용자, 네트워크 복구 전략 등을 공급하기 위한 절차가 문서화가 필요

 

BCP 구성 문서

- 문서의 형태

  -> 최근에는 전자 문서로 존재하는 경우가 많음

  -> 배포할 수 있도록 인쇄되어 있어야 함

- 문서의 내용

  -> 사업 복구 계획
  -> 운영 계획 연속성
  -> IT 비상 계획 지원의 연속성
  -> 위급 상황 시 통신 계획
  -> 사고 대응 계획
  -> 재해 복구 계획
  -> 거주자 비상계획

 

계획 사본 저장
- 핵심 의사 결정자의 사택

  -> 보안 문서는 절대 사택에 보관하지 않지만 BCP만 유일하게 사택에 보관

  -> 당연히 핵심 의사 결정자와 관련된 문서만 해당

- 복구 시설이나 저장 시설(오프 사이트)

 

3. DRP(재해 복구 계획)

3-1. DRP

- 기술이 아닌 환경과 관련된 복구 계획이기때문에 엄밀히 따지면 IS와 관련되어 있음

- 사건 발생시 조직이 재해를 복구하기 위한 전략적인 방법을 제공해 혼란을 줄이고 위기상황에 대처하는 조직의 능력을 향상.

- 합리적인 비용으로 수용 가능한 복구 시간대를 제공 할 수 있는 복구 전략이 필요

- 가장 적절한 복구 전략은 BIA에서 식별된 상대적 위험도를 바탕으로 선택.

 

DRP의 구성과 목적
- 컴퓨터 및 네트워크 시스템 장애로부터 조직을 보호

- 업무 서비스 제공 지연으로인한 위험의 최소화

  -> 가장 궁극적인 목적. 역시 조직을 보호 하기 위한 것

- 재해 중 직원들의 안전한 행동 요령과 의사결정의 최소화

  -> 문서의 성숙도가 높아질수록 지침대로만 행동 

- 테스트를 통한 대기 시스템의 안정성 보장

  -> 시스템은 단순히 IT 시스템이 아닌 계획을 의미

 

DRP영역
- 재해 복구 계획 프로세스
- 재해 복구 계획 테스트
- 재해 복구 프로시저

 

MTBF(Mean Time between Failure)

- 어떤 장애가 발생 후 같은 장애가 다시 발생할때까지 걸리는 시간

 

MTTR(Mean time to Repair)

- 장애 발생 후에 복구까지 걸리는 시간

 

복원력
- 대체 경로나 여분의 시스템을 이용 위협에 대처하는 능력
- 복원력에 의해 복구 되지 않아 손실되거나 피해를 입은 시스템에 대한 대책은 재해 복구 절차에서 고려.

 

잔존 위험
- 복구 전략이 선택된 이후 남아있는 위험

3-2. 복구 목표 시점(RPO)과 복구 목표 시간(RTO)
RPO(Recovery Point Objective)
- 장애 발생시 복구 시점(현재로 부터 과거 시점, 짧을 수록 비용이 많이 든다.)
- RPO가 '매우 짧다'는 것은 '손실 데이터 양이 작다;라는 걸 의미.
- 가장 이상적인 경우는 재해 시점과 RPO 시점이 같은 지점
  -> 데이터 손실이 없다.
- 미러링, 듀플렉싱 < 백업 < 릴 백업(RPO가 클수록 운영 비용이 적다)

RTO(Recovery Time Objective)
- 복구 가능 최단 시간(허용 시간)
  -> 장애 시점부터 복구 시점까지의 시간
- 실제 복구는 RTO를 기반으로 하는 경우가 많음. 
- 적을 수록 복구 비용이 많이 든다.

이외 복구 파라미터
- 중단 기간 : 시스템 중단부터 복구까지 수용 가능한 시간(초과시 손실비용 급격히 증가.)
- 서비스 공급 목표 : 대체 프로세스의 목표 서비스 수준
  -> 여기서 서비스는 내부 직원에게 업무 환경을 제공하는 것을 의미 
- 최대 허용 범위 : 대체 프로세스가 지원 가능한 최대 시간

3-3. 재해 복구 계획 프로세스
재해 복구 계획의 단계
- 데이터 처리 지속 계획(Data Processing Continuity Planning)
  -> 재해를 예측하고 대처하기 위한 계획 수립
- 데이터 복구 계획 유지 보수 (Data Recovery Plan Maintenance)
  -> 계획이 항상 최신의 버전이도록 유지하기 위한 계획

데이터 처리 지속 계획
- 상호 지원 계약
  -> 가장 적은 비용
  -> 호환성의 문제(운영체제 등등)
  -> 동시 재해시 복구 불능
  -> 복구에 다른 대안이 없는 경우(지역적인 문제)에만 고려하는 것이 좋다.
- 가입 서비스
  -> Hot site : 고가, 동일한 보안 이슈, 자원 집약적, 최신의 데이터나 응용을 유지.(서버는 없음)
  -> Warm site : 경제적, 위치 선정이 유연, 관리자원 낭비가 적다(컴퓨터가 없음)
  -> Cool site : 가장 저렴한 구성, 재해복구 성공에 확신이 어렵다(기본적인 배관 시설만 존재)
- 다중 센터
  -> 여러 운영 센터로 처리를 나누어 운영
  -> 대기업이나 국가 기관에서만 가능한 방법
- 서비스업체
  -> DRP에 대한 외주
  -> 대규모 재해시에 자원에 대한 경합(SLA를 통해서 어느정도 해소 가능..)
- 기타 백업 대안
  -> 이중 정보 처리 시설
  -> 모바일사이트 : Sun(블랙박스), IBM(PMDC)
- 트랜잭션 중복 구현
  -> 전자 볼팅 또는 원격 저널링 : 작업 일지(로그 정보)를 원격에 저장. 백업된 로그정보는 장애시 트랜잭션 복구에 이용.
  -> 데이터베이스 쉐도우잉(Database Shadowing) : 다중 DB 서버 운영으로 완전 이중화. 백업 데이터베이스

재해복구 계획의 유지 보수
- 최신의 버전이 유지되도록 업데이트를 수행.
- 컴퓨팅 환경의 변화등이 원인 (이외에도…)

3-4. 재해 복구 계획 테스트
- 재해 복구 계획은 조직의 실재적인 복구 능력이므로 주기적으로 테스트되어야 함.
  -> 주기는 보통 6개월, 늦어도 1년

이유
- 복구 프로세스의 정확성을 검증 및 결함을 식별.
- 직원 훈련
- 백업 사이트의 처리 역량을 검증

복구 테스트 유형
- 체크 리스트(Check list)
  -> 계획이 조직의 모든 영역에 해당되는지 확인 및 검토
- 구조적 점검(Structured walk-through)
  -> 사업 단위 관리자들이 계획이 복구능력을 제공하는지 검토하고 확인
  -> 전부 모여서 하나하나 확인 
- 시뮬레이션(Simulation)
  -> 블라인드 시뮬레이션 : 예고없이 진행하는 것.
  -> 재해에 대한 직원의 능력을 테스트
  -> 실재 복구 프로세스나 대체 응용을 기동하지는 않음.
- 병렬 테스트(Parallel)
  -> 가장 많이 수행되는 재해 복구 테스트
  -> 핵심적인 기능이 대체 복구 사이트에서 수행되는지 확인
  -> 트랜잭션 결과를 비교함으로써 정확성과 안정성을 확인
  -> 실제로 진행하기 때문에 비용이 많이 소요. 
- 전체 시스템 중단 테스트(Full-interruption)
  -> 극히 드물지만 절대적으로 최선의 테스트
  -> 실제 재해 상황처럼 조직의 기능을 중단시키고 복구 계획을 실행

3-5. 재해 복구 프로시저
- 팀의 이름이 혼동되어 예전처럼 팀의 이름이 중요하지는 않음

재해복구 프로시저의 요소
- 복구팀
- 구조팀
- 정상 운영 재개
- 기타 복구 이슈

복구팀(Recovery Team)
- 백업 사이트에서 핵심적인 기능의 운영을 담당
  -> 백업 사이트는 주사이트보다 작기때문에 기존의 모든 직원이 갈 수 없음
  -> 어떤 사람이 어떤 복구 작업을 할지 담당

구조팀(Salvage Team)
- 재해를 입은 주사이트(원래 사이트)의 기능을 복원하기 위한 팀
- 재해 사이트의 장비 및 시설에 대한 관리와 확인을 담당
- 정상운영 복귀(백업 사이트에서 원래 사이트로 다시 복귀) 시점을 결정하는 권한을 갖는다.
- librarian이 여기 포함

정상 운영 재개
- 회복팀에 의해서 구현
- 복구단계와는 달리 가장 덜 민감하고 덜 중요한 기능부터 주사이트로 이전한다.
- 재해상황의 종료는 모든 기능이 원래 사이트로 환원, 데이터가 정확하다고 증명된 이후 공식적으로 종료.
  -> 원래 사이트로 돌아가는 프로시저에는 매우 다양하고 심각한 취약성들이 존재.

기타 복구 이슈
- 사고의 원인에 대해서 추측하지 않는다.
  -> 왜곡 보도로 간주될 수 있음
- 책임을 추측하지 않는다.
- 시스템이나 프로세스를 비난하지 않는다
- 조사가 시작되고 결과가 발표될 것임을 포함.
- 조직 내 누구도 성명(언론에 대해)을 발표해서는 안 됨.