Day 67 & 68 (Business Continuity Planning_사업 연속성 기획)

<목차>

1. 사업 연속성 기획 
2. BCP와 DRP
3. BCP
  1) 범위와 계획 초기화 
  2) 사업 영향 평가 (BIA) 
  3) 사업 지속 개발 계획 
  4) 구성 요소 
4. DRP
  1) 목표 시점과 목표 시간
  2) 재해 복구 계획 프로세스 
    ① 데이터 처리 지속 계획
    ② 데이터 복구 계획 유지 보수
  3) 재해 복구 계획 테스트 
  4) 재해 복구 프로시저 

---

1. 사업 연속성 기획 

BCP 프로세스	DRP	재해
• 범위와 계획의 초기화 • 사업 영향 평가 (Business Impact Assessment : BIA) • 사업 지속 개발 계획	• 재해 복구 계획 프로세스 • 재해 복구 계획 테스트 • 재해 복구 절차	• 자연재해 : 정보 처리 시설에 직접적인 피해 • 통신, 전기, 가스등의 기반 서비스 중단 • 테러, 바이러스 등으로 인한 재해 • 실수(직원,…)

재해는 정보 자원의 사용 불능으로 발생하는 비즈니스 중단 사태를 의미한다.
재해 상황이 BCP를 실행할 심각한 중단 상황인지 판단하기 위해서 위험 기반의 분류 시스템(risk classification system)이 필요하다.

재해 복구 기획은 정보보안에서 확인한다. 재해 복구 기획은 BCP 프로세스의 하부에 위치 심각하게 되면 DRP을 운영한다.

 

2. BCP와 DRP 
BCP는 범위, 계획, 사업영향평가(BIA 업무 중단시 기업이 입는 피해 크기)를 상세하게 세워져야 한다. 

DRP 사업지속 개발 계획 / BCP안에 포함된다. 
시스템이 멈추는 상황에서도 수작업이 가능한 업무 많다. 금융기관은 PC가 멈춰도 업무에 큰 지장이 없다. 
계획의 요소는 다음과 같다.

• 재해 이전 준비
• 대피 절차
• 재해 선언 절차
• 재해 선언 상황 판단 기준
• 책임 및 책임자
• 명확한 계약 정보
• 복구 대안의 단계별 설명
• 복구 및 지속 운영에 필요한 자원 식별

재해복구계획 테스트는 재해발생전에 수행하는 것이 당연하다. 항상 확인 마지막 일자를 기록하여 최대한 최신 정보를 가진다. 
재해가 발생하게 되면 선수행후보고를 원칙으로 한다. 복구시에 백업데이터가 현 사이트에 없으니 유출이나 오염의 문제가 발생 할수있다. 정량적 평가에 의해 사람이 먼저 대피해야 손실이 적어진다. 

3. BCP

- BCP는 risk management로서 핵심적인 기능 및 운영이 예기치 못한 중단으로 부터 보호되게 하는것이다. 정량적 측정이 되지 않는다면 손실이 아니다.

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

 

- BCP의 책임 : 고위 경영진이 주주로부터 회사의 생존과 자산보호의 책임을 위임 받는다. 

- BCP의 구성 : 재해 복구 계획과 사업 운영 연속성 확보 계획으로 이루어진다. 재해 복구 계획은 허용 가능한 범위 내까지 복구를 의미한다. 사업 운영 연속성 확보 계획은 어떻게 연속성을 확보할것인가가 중점이다. 다른 업무에서는 재해 복구 계획과 사업 운영 연속성 확보 계획의 구별이 어렵지만 IT에서는 구별이 쉽다.

 

- 중점 고려 사항은 조직의 생존에 가장 필요한 핵심 사업 영역과 핵심 사업 영역을 지원하는 물적, 인적 자원을 고려한다. 

- 사업 연속성 계획은 위험분석을 기반으로 수행하며 이를 위해서 자산을 고려한 위협 식별작업이 필요하다.

- 위험은 자산 가치와 인지된 위협이 발생될 비율에 비례한다. 수식으로 표현하면 손실액(SL) * 발생가능성(ARO)으로 표현이 가능하다. 

- IT 재해 복구 계획은 사업 연속성 계획의 하위 요소, 기술문서이다.

- 모든 복구 계획의 기준은 비용편익(ALE)이다. 통제이기 때문에 절대 비용(cost)가 편익(benefit)을 초과해서는 안 된다.

 

- BCP 프로세스는 범위와 계획의 초기화, 사업영향 평가(BIA), 사업 지속 개발 계획(통제개발), 계획 승인과 구현을 포함한다.

 

-  BCP 구현및 운영 과정

1. 사업 연속성/재해 복구 정책 수립
2. 사업 영향 분석
3. 사업 연속성 계획과 재해 복구 절차 수립
4. 훈련과 인식 프로그램
5. 계획 테스트및 실행 : 테스트 실행은 walk-through업무 시뮬레이션)로 진행한다.
6. 정상 수행이 가능한가를 모니터링하여 확인

 

1) 범위와 계획 초기화
- BCP 프로세스의 개시
- 역할과 책임을 식별

• 최고 경영진은 프로젝트의 개시, 최종승인, 지속적인 지원 책임을 가진다.
• BCP위원회는 내부 위험은 배제하고 계획 구현 및 테스트를 지휘한다.
• 단위 사업 관리자는 사업체 이사진으로서 핵심 프로세스의 정의와 우선순위 부여한다.
• 기능 사업부서는 각 부서 부서장으로서 구현과 테스트에 참여한다.

2) 사업 영향 평가 (BIA)
- 세가지 주요 요소

핵심 우선 순위 결정	모든 핵심적인 단위 프로세스를 식별하고 파괴적 사건에 대한 영향을 평가해야 한다. 사업영향평가 혹은 업무 영향평가로 지정 가능하다.
중단시간 산정	핵심 프로세스가 중단된 채로 조직이 회생불능에 빠지기 까지 견딜 수 있는 시간을 산정한다. MTD(Maximum Tolerable Downtime)라고도 한다. 일반적인 측정치는 기대치에 비해서 무척 짧다.
지원 요구사항	핵심 프로세스를 복구하는데 필요한 자원요구 사항을 가진다. 실제로 인적 자원 확보가 가장 어렵기 때문에 상호 협력 조약을 맺는다.

- BIA 수행하는 접근 방법

 설문지, 인터뷰, 회의, 시스템 관련 BIA에서는 과거의 트랜잭션 량을 분석하고 결과는 인터뷰단계에서 실증해야 한다.

- 취약성 평가

위험 평가 방법	정량적 : 경제적 측면 정성적 : 운영 측면 두가지를 모두 봐야 한다.
정량적 손실 기준	매출 손실 및 추가 부채에 대한 비용 사건 복구 비용 법적인 비용 (계약의 위반, 법률 위반 등)
정성적 손실 기준	시장 점유율 감소 신뢰나 공신력 감
취약성 평가를 기반으로 한 핵심 지원 영역에 대한 정의가 중요하다.

- 문서화

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

 

3) 사업 지속 개발 계획
BIA로부터 도출된 핵심 사업기능을 지원하기 위한 비상계획과 전략을 세운다.

두 가지 중요한 단계를 포함한다.

지속 전략 계획	컴퓨팅 계획(전략) 설비 계획 인력 계획 지원과 장비 계획
지속적인 문서 전략	지속 전략 계획의 각각의 결과에 대한 완전한 문서화

사고 복구는 개개인의 노력에 의존하기 때문에 계획의 전사적 파급을 위한 인지도 향상이 필요하며 양질의 훈련과 교육을 통해 달성한다.

계획의 유지 보수는 컴퓨팅 환경의 변화등이 원인이 다양하게 변화가 가능하기 때문에 최신의 버전이 유지되도록 최소 6개월 ~ 최대 1년단위로 주기적 업데이트를 수행해야 한다.

 

4) 구성 요소
BCP 구성 문서에는 사업 복구 계획, 운영 계획 연속성, IT 비상 계획 지원의 연속성, 위급 상황 시 통신 계획, 사고 대응 계획, 재해 복구 계획, 거주자 비상계획등 시스템, 사용자, 네트워크 복구 전략 등을 공급하기 위한 절차가 포함되어 있다.

BCP 구성 문서는 보통 배포가 가능해야 하기 때문에 인쇄된 종이 문서로 한다. 전자문서도 가능하지만 장비나 전기가 있어야 하는 등의 제약조건이 발생한다. 무엇보다 전자문서의 가장 큰 단점은 부서에서 필요한 부분이 다 다르기 때문에 발췌가 필요한데 전자문서는 문서의 제단 혹은 발췌가 어렵다.
계획 사본은 핵심 의사 결정자의 사택이나 복구 시설이나 저장 시설(오프 사이트)에 저장한다. BCP는 기업 전략등의 내용이 있고 DRP는 패스워드 정보까지 포함되어 있는다. 다른 문서의 자택보관은 물리적 보안이 어렵기 때문에 할 수 없다. 하지만 BCP는 보안등급이 높은 문서임에도 불구하고 담당 부서혹은 업무만을 발췌해서 보관한다.

 

4. DRP

DRP는 재해복구계획 프로세스, 재해복구 계획 테스트, 재해복구 절차를 포함하는 IS에 대한 것이다. 재해는 정보 자원의 사용 불능으로 발생하는 비즈니스 중단 사태이다. 자연재해, 통신, 전기등의 기반 서비스 중단, 테러, 바이러스 등으로 인한 재해, 실수등의 인적 문제가 있다. 실질적으로는 인적 문제로 인한 재해가 가장 빈번하다. 

DRP의 목적은 컴퓨터 혹은 네트워크 시스템 장애로부터 조직을 보호하는 것이다. 문제가 발생했을시 민감도가 높은 작업 복구환경을 구축하는 것을 얼마나 빠르게 수행할 것 인가가 중요하다. 

궁극적인 목표는 업무서비스 제공 지연으로 인한 위험 최소화와 재해 중 직원들의 안전한 행동 요령과 의사결정의 최소화, 테스트를 통한 대기 시스템의 안정성 보장이다. 의사결정 최소화는 판단이나 결정하는 선택지를 줄여 빠른 결정을 하게 하는 것이다. 테스트를 통한 대기 시스템의 안정성 보장이 되려면 문서의 성숙도가 높아야 한다.

 

문서의 성숙도가 높기 위해서는 주체의 문제와 프로세서의 문제가 해결되어야 한다. 주체의 문제는 숙련도가 높게 선행되어야 하기 때문에 교육 훈련을 통해 해결한다. 프로세서의 문제는 숙련된 사용자가 봤을때 프로세스를 사용함에 있어 문제가 없게 하는 것이다.

DRP영역은 재해 복구 계획 프로세스, 재해 복구 계획 테스트, 재해 복구 프로시저가 있다. 재해 복구 계획 테스트는 테스트를 통해 유효한지 적절한지 판단하기위해 필요하다.

MTBF (Mean Time between Failure)는 일반적으로는 장애 발생후 같은 장애가 발생할때까지의 시간을 의미하지만, 정확히는 장애 발생 후 장애 처리 후 같은 장애가 발생할때까지의 시간을 의미한다. 길수록 좋다.
MTTR (Mean time to Repair)는 장애 발생후 장애 복구까지 걸리는 시간, 시스템 마다 다르다. 민감도가 높은 업무용 서버와 데이텉 베이스 서버가 보통은 최우선으로 한다. 내부 장애는 비교적 빠르게 해결되지만 외부 장애는 소요시간이 길다. 3~4주가 일반적으로 소요된다.

복구 전략은 합리적인 비용으로 수용 가능한 복구 시간대를 제공 할 수 있어야한다. 합리적인 비용이란 경영진이 수용 가능한 비용을 의미한다.

 

복원력은 대체 경로나 여분의 시스템을 이용 위협에 대처하는 능력이기 때문에 여분의 시스템에 따라 달라진다. 복원력에 의해 복구 되지 않아 손실되거나 피해를 입은 시스템에 대한 대책은 재해 복구 절 차에서 고려한다.
교정통제이기 때문에 잔존 위험(잔여 위험)이 존재한다. 잔존 위험은 복구 전략이 선택된 이후 남아있는 위험으로서 보험 혹은 수작업등으로 피해를 최소화 할 수 있다. 가장 적절한 복구 전략은 BIA에서 식별된 상대적 위험도를 바탕으로 선택 되어진다

1) 목표 시점과 목표 시간

복구 파라미터	설명
RPO(Recovery Point Objective)	- 목표 시점으로서  장애 발생시 복구 시점(현재로 부터 과거 시점,  짧을 수록 비용이 많이 든다.) - 복구하는 양과 관련된 파라미터이다. - RPO가 매우 짧다라는 건 손실 데이터의 량이 작다라는 걸 의미한다. 가장 이상적인 경우는 재해시점 RPO시점이 동일한 RPO=0인 경우이다. 이 경우는 완전복구 즉, 데이터 손실이 없음을 의미한다. - 미러링, 듀플렉싱 < 백업 < 릴 백업 (클수록 운영 비용이 적다.)  - 운영 비용은 H/W, S/W, 인건비 등을 통합하여 사용측정한다.
RTO(Recovery Time Objective)	- 복구 가능 최단 시간(허용 시간)을 의미하며 장애시점으로 부터 복구시점까지의 시간차로 구한다. 실제 리커버리 하는 시간을 기점으로 수행한다. - 동기화 정보를 시간으로 관리한다. 적을 수록 빠르게 복구 된다는것을 의미하기 때문에 복구 비용이 많이 든다. - RTO=0 망가진 시점까지를 복구하는 것이다. 복구 시점을 정확하게 파악이 어렵기 때문에 데이터가 손상 또는 손실이 발생할 수 있다.
중단 기간	시스템 중단부터 복구까지 수용 가능한 시간 (초과시 손실비용 급격히 증가한다.)
서비스 공급 목표	대체 프로세스의 목표 서비스 수준
최대 허용 범위	대체 프로세스가 지원 가능한 최대 시간

(* 서비스 복원 정도 : 내부직원이 업무가 가능한 상태로 복원하는것)

 

2) 재해 복구 계획 프로세스 

① 데이터 처리 지속 계획 (Data Processing Continuity Planning) : 재해를 예측하고 대처하기 위한 계획 수립

- 상호 지원 계약은 다른 사이트에서 우리 시스템을 사용하는 것이다. 가장 적은 비용이 발생한다 하지만 호환성 및 보안상의 문제와 동시 재해 시 복구 불가능 하다는 단점이 있다. 따라서 복구에 다른 대안이 없는 경우에만 고려하는 것이 좋다. 

 

- 가입 서비스

핫사이트(Hot site)	- 서버만 구축되어 있지 않은 상태이다. - 고가, 동일한 보안 이슈, 자원 집약적, 최신의 데이터나 응용을 유지한다.
웜사이트(Warm site)	- 네트워크까지 구축이 되어있는 환경이며 PC만 없는 상태이다. - 경제적, 위치 선정이 유연, 관리자원 낭비가 적다. - 노트북의 사용이 급격히 늘어나면서 Warm site의 개념이 많이 퍼졌다.
쿨사이트(Cold site)	- 가장 저렴한 구성으로 기반시설과 에어컨만 준비되어 있다. - 재해복구 성공에 확신이 어렵다.
구축비용은 Cold site<Warm site<Hot site순이며 한국에서는 PC방이 많이 있기 때문에 Hot site 사용의 의미가 없다.

- 다중센터는 여러 운영 센터로 처리를 나누어 운영하는 것을 의미한다.

- 서비스업체는 DRP에 대한 외주를 통해 사용 가능하며 대규모 재해시에 자원에 대한 다른 업체와의 경합이 발생할 수 있다. (SLA(:Service Level Agreement;협약)를 통해서 어느정도 해소 가능 하다.)

 

- 기타 백업 대안으로는 이중정보처리시설을 이용하거나 Sun(블랙박스 : 변전시설 없음), IBM(PMDC : 변전시설 갖춤)와 같은 모바일 사이트를 이용하는 방법이 있다. 하지만 현재 모바일 사이트를 이용하는것은 기술되어 있지만 실제 사용하지 않는 방식이다.

 

-트랜잭션 중복 구현

- 전자볼팅(Electronic Vaulting)은 대체 사이트로 트랜잭션을 덤프하는 배치 프로세스로서 작업일지인 redolog를 이용해 원격저널링(Remote Journaling)한다. 저널링은 로그정보를 저장하는 것을 의미한다. 백업된 로그정보는 장애시 트랜잭션 복구에 이용된다.
(* 작업일지 저장하는 행위를 'achieving한다.' 라고 말한다.)
- 데이터베이스 쉐도우잉(Database Shadowing)은 다중 DB서버 운영으로 완전 이중화를 통해 실시간으로 동기화 시킨다.

 

② 데이터 복구 계획 유지 보수 (Data Recovery Plan Maintenance) : 계획이 항상 최신의 버전이도록 유지하기 위한 계획 

- 재해복구 계획의 유지 보수는 컴퓨팅 환경의 변화등이 원인이 발생할 가능성이 크므로 최신의 버전이 유지되도록 업데이트를 주기적, 지속적으로 수행해야 한다.
- 재해 복구 계획은 조직의 실재적인 복구 능력이므로 최소 6개월~ 최대 1년을 주기로 테스트되어야 한다.

 

3) 재해 복구 계획 테스트
- 복구 프로세스의 정확성을 검증하고 결함을 식별하고, 직원 훈련과 백업 사이트의 처리 역량을 검증을 하기위해 수행한다.

 

- 복구 테스트 유형

체크리스트(Checklist)	- 체크리스를 통해 계획이 조직의 모든 영역에 해당되는지 확인및 검토하는 것이다. - walk-through와 유사하지만, 체크리스트는 단순히 서류상으로 절차만 확인한다.
구조적 점검(Structured walk-through)	- 사업 단위 관리자들이 계획이 복구능력을 제공하는지 검토하고 확인하는 것이다. - 특정 장소에 모여 전후 관계를 파악하며 일일히 검토하는 것이다.
시뮬레이션(Simulation)	- backup site에서 재해에 대한 직원의 능력을 테스트하는 것이다. - 실제 복구 프로세스나 대체 응용을 기동하지는 않는다.
병렬 테스트(Parallel)	- 가장 많이 수행되는 재해 복구 테스트이다. - 실제 일부 data를 입력하여 핵심적인 기능이 대체 복구 사이트에서 수행되는지 확인한다. - 트랜잭션 결과를 비교함으로써 정확성과 안정성이 확인된다.
전체 시스템 중단 테스트(Full-interruption)	- 극히 드물지만 절대적으로 최선의 테스트이다. - 실제 재해 상황처럼 조직의 기능을 중단시키고 복구 계획을 실행하기 때문에 테스트 하기 어렵다.

4) 재해 복구 프로시저
- 재해복구 프로시저의 요소에는 복구팀, 구조팀, 정상 운영 재개, 기타 복구 이슈가 있다.

복구팀(Recovery Team)	- 백업 사이트에서 핵심적인 기능의 운영을 담당
구조팀(Salvage Team)	- 재해를 입은 주사이트의 원래 기능을 복원하기 위한 팀으로 라이브러리언(Librarian)이 포함되어 있다. - 재해 사이트의 장비 및 시설에 대한 관리와 확인을 담당 - backup site에서 주 site로 되돌아오는 시점을 조절한다. 즉, 정상운영 복귀를 결정하는 권한을 갖는다.
네트워크팀(Network Team)	각 부서간 정보 전달을 담당한다.
통신팀(Communication Team)	네트워크 구축을 담당한다.
현재는 네트워크팀과 통신팀을 구분없이 사용한다.

- 정상운영 재개

회복팀에 의해서 구현된다. 복구단계와는 반대로 가장 덜 민감하고 덜 중요한 기능부터 backup site에서 주 site로 이전한다. 재해상황의 종료는 모든 기능이 원래 사이트로 환원되고 데이터가 정확하다고 증명된 이후 공식적으로 종료된다. 주 site에서 backupsite로 이전할때와 마찬가지로 원래 사이트로 돌아가는 프로시저에도 매우 다양하고 심각한 취약성들이 존재한다.

 

- 기타 복구 이슈

외부 그룹과 인터페이스	- 경찰서, 소방서, 시청등 관공서와의 물리적 논리적 거리 - 보도 기관, 주주, 고객과의 의사 소통
직원	- 조직은 직원의 신체적, 경제적 안전에 고유의 책임을 진다.
사기와 범죄행위	- DRP는 재해시 계획적 또는 우발적으로 발생하는 약탈, 도난 등의 대해서 고려해야 한다. - 동양에서는 서양에 비해 비교적 덜 민감하다.
재정적 부담	- DRP 운영의 제정적인 문제 - 사고 처리 도중 발생된 제정적인 부담은 예상이나 이를 집행하는 비상관리자의 권한을 초과할 가능성 에 대해서 언급되어야 한다.
보도 기관과의 관계
대변인 같은 공식적인 대외 채널이 필요	- 심각한 상황에서 미리 준비된 성명서 같은 대처가 필요하다. - 사고의 원인에 대해서 추측하지 않는다. - 책임을 추측하지 않는다. - 시스템이나 프로세스를 비난하지 않는다. - 조사가 시작되고 결과가 발표될 것임을 포함한다. - 조직 내 누구도 언론에 성명을 발표해서는 안된다. - 한국은 정 반대의 행동을 한다.