D9 Business Continuity Planning

ㅇ ㅂㅇ

1. BCP와 DRP

 BCP 프로세스는 다음을 포함한다.
 • 범위와 계획의 초기화
 • 사업 영향 평가 (Business Impact Assessment : BIA)
 • 사업 지속 개발 계획

 DRP는 다음을 포함한다.
 • 재해 복구 계획 프로세스
 • 재해 복구 계획 테스트
 • 재해 복구 절차

 재해 – 정보 자원의 사용 불능으로 발생하는 비즈니스 중단 사태
 • 자연재해 : 정보 처리 시설에 직접적인 피해
 • 통신, 전기, 가스등의 기반 서비스 중단
 • 테러, 바이러스 등으로 인한 재해
 • 실수(직원,…)

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

 > BCP (=위기 대응 메뉴얼)
  - 전략 기획실에서 하며, 보안 상 상당히 중요한 문서를 말함 -> 유지 보수 정도 해야 함

 사업 연속성 계획과 재해 복구 계획은 BIA에 내용을 근거로 상세하게 세워져야 된다
 계획의 요소
 • 재해 이전 준비
 • 대피 절차
 • 재해 선언 절차
 • 재해 선언 상황 판단 기준
 • 책임및 책임자
 • 명확한 계약 정보
 • 복구 대안의 단계별 설명
 • 복구및 지속 운영에 필요한 자원 식별

2. BCP

 BCP의 목적
 조직의 생존을 위해서 핵심적인 기능 및 운영이 예기치 못한 중단으로부터 보호 될 수 있도록 하는 것.
 발생 가능한 여러 종류의 위험
 • 고객 서비스 중단
 • 이미지 및 브랜드 손실
 • 지적. 인적 자산 보호 실패
 • 비즈니스 통제 상실
 • 법률적 요구 사항 위반 <- i="">
 BCP의 책임
 • 고위 경영진 – 회사의 생존과 자산보호의 책임을 위임 받음
 BCP의 구성
 • 재해 복구 계획 + 사업 운영 연속성 확보 계획

 중점 고려 사항 > BIA에 의해 구분됨
 • 조직의 생존에 가장 필요한 핵심 사업 영역
 • 핵심 사업 영역을 지원하는 물적, 인적 자원

 > 핵심적/비핵심적업무를 나눈 뒤 비핵심적업무를 아웃소싱 or 파견직으로 고용하여 비용을 절감 하는 것

 사업 연속성 계획은 위험분석을 기반으로 수행하며 이를 위해서 자산을 고려한 위협식별작업이 필요하다.
 위험은 자산 가치와 인지된 위협이 발생될 비율에 비례한다.
 • 손실액 * 발생가능성
 IT 재해 복구 계획 – 사업 연속성 계획의 하위 요소, 기술문서이다.
 모든 복구 계획의 기준은 비용편익 이다.
 • 절대 비용(cost)가 편익(benefit)(피해액수)을 초과해서는 안 된다.

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

 BCP 구현및 운영 과정
 1. 사업 연속성/재해 복구 정책 수립
 2. 사업 영향 분석
 3. 사업 연속성 계획과 재해 복구 절차 수립
 4. 훈련과 인식 프로그램
 5. 계획 테스트및 실행
 6. 모니터링

 > BCP ⊃ DRP
  - DRP는 기술자들이 만들며 주로 IS 설비와 관련된 문서들임

 -- 범위와 계획 초기화

 BCP 프로세스의 개시

 역할과 책임을 식별
 • 최고 경영진 – 프로젝트의 개시, 최종승인, 지속적인 지원 책임
 • BCP위원회 – 계획 구현, 테스트를 지휘
 • 단위 사업 관리자 – 핵심 프로세스의 정의와 우선순위 부여
 • 기능 사업부서 – 구현과 테스트에 참여

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

 BCP 프로세스의 개시
 역할과 책임을 식별
 • 최고 경영진 – 프로젝트의 개시, 최종승인, 지속적인 지원 책임
 • BCP위원회 – 계획 구현, 테스트를 지휘 > IS 전략 위원회가 포함된다
 • 단위 사업 관리자 – 핵심 프로세스의 정의와 우선순위 부여
 • 기능 사업부서 – 구현과 테스트에 참여

 -- 사업 영향 평가 (BIA)

 세가지 주요 요소.
1. 핵심 우선 순위 결정
 • 모든 핵심적인 단위 프로세스를 식별하고 파괴적 사건에 대한 영향을 평가해야 한다.
2. 중단시간 산정
 • 핵심 프로세스가 중단된 채로 조직이 회생불능에 빠지기 까지 견딜 수 있는 시간을 산정
 • MTD : Maximum Tolerable Downtime
 • 일반적인 측정치는 기대치에 비해서 무척 짧다.
3. 지원 요구사항
 • 핵심 프로세스를 복구하는데 필요한 자원요구 사항
 BIA 수행하는 접근 방법
 • 설문지
 • 인터뷰
 • 회의
 • 시스템 관련 BIA에서는 과거의 트랜잭션 량을 분석하고 결과는 인터뷰단계에서 실증해야한다.

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

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

 -- 사업 지속 개발 계획

 BIA로부터 도출된 핵심 사업기능을 지원하기 위한 비상계획과 전략을 세운다.
 두 가지 중요한 단계를 포함한다.
 • 지속 전략 계획
  - 컴퓨팅 계획(전략)
  - 설비 계획
  - 인력 계획
  - 지원과 장비 계획
 • 지속적인 문서 전략 : 지속 전략 계획의 각각의 결과에 대한 완전한 문서화

 계획의 전사적 파급을 위한 인지도 향상
 • 사고 복구는 개개인의 노력에 의존하기 때문에..
 • 양질의 훈련과 교육
 계획의 유지 보수
 • 최신의 버전이 유지되도록 업데이트를 수행해야 한다.
 • 컴퓨팅 환경의 변화등이 원인 (이외에도 많음…)

 -- 구성 요소

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

 시스템, 사용자, 네트워크 복구 전략 등을 공급하기 위한 절차
 계획 사본 저장
 • 핵심 의사 결정자의 사택
 • 복구 시설이나 저장 시설(오프 사이트)

3. DRP

 매우 파괴적인 사건 발생시 조직이 재해를 복구하기 위한 전략적인 방법을 제공함으로써 혼란을 줄이고 위기상황에 대처하는 조직의 능력을 향상시킨다.
 DRP의 구성과 목적
 • 컴퓨터 및 네트워크 시스템 장애로 부터 조직을 보호
 • 업무 서비스 제공 지연으로인한 위험의 최소화
 • 재해 중 직원들의 안전한 행동 요령과 의사결정의 최소화
 • 테스트를 통한 대기 시스템의 안정성 보장

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

 MTBF (Mean Time between Failure) : 장애 사이 기간 (길수록 좋은 것..)
 MTTR(Mean time to Repair) : 장애 교정 시간(짧을수록 좋은 것..)
 > 교정 이란 : 장애로 부터 원래 상태로 돌아와 정상 서비스가 가능 하게 하는 것

 합리적인 비용으로 수용 가능한 복구 시간대를 제공 할 수 있는 복구 전략이 필요
 복원력
 • 대체 경로나 여분의 시스템을 이용 위협에 대처하는 능력
 • 복원력에 의해 복구 되지 않아 손실되거나 피해를 입은 시스템에 대한 대책은 재해 복구 절차에서 고려한다.

 잔존 위험 (잔여 위험)
 • 복구 전략이 선택된 이후 남아있는 위험
 가장 적절한 복구 전략은 BIA에서 식별된 상대적 위험도를 바탕으로 선택 되어진다.

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

 RPO (Recovery Point Objective)
 • 장애 발생시 복구 시점(현재로 부터 과거 시점, 짧을 수록 비용이 많이 든다.)
 • RPO가 매우 짧다라는 건 손실 데이터의 량이 작다라는 걸 의미한다.
 • 가장 이상적인 경우 : 재해시점 = RPO시점 : 데이터 손실이 없다. <- 0="" i="" rpo="">
 • 미러링, 듀플렉싱 < 백업 < 릴 백업 (클수록 운영 비용이 적다)
 RTO (Recovery Time Objective)
 • 복구 가능 최단 시간(허용 시간)
 • 적을 수록 복구 비용이 많이 든다. <- i="" os="">

 > 0에 가까워지려고 하려면 비용이 상승함 (DB 제외)

 이외 복구 파라미터
 • 중단 기간 : 시스템 중단부터 복구까지 수용 가능한 시간
  (초과시 손실비용 급격히 증가.)
 • 서비스 공급 목표 : 대체 프로세스의 목표 서비스 수준
 • 최대 허용 범위 : 대체 프로세스가 지원 가능한 최대 시간

 > 민감한 프로세스(수작업을 하거나, 장기간 복구해야 하는 것들) 부터 복구함

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

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

 데이터 처리 지속 계획
 • 상호 지원 계약
  - 가장 적은 비용
  - 호환성의 문제
  - 동시 재해 시 복구 불능
  - 복구에 다른 대안이 없는 경우에만 고려하는 것이 좋다.
 • 가입 서비스
  - 핫사이트(Hot site) : 고가, 동일한 보안 이슈, 자원 집약적, 최신의 데이터나 응용을 유지
  > 모든 것이 있고, 서버만 없는 경우
  - 웜사이트(Warm site) : 경제적, 위치 선정이 유연, 관리자원 낭비가 적다
  > 기본적 설비가 되어 있고, PC가 없는 경우
  - 쿨사이트(Cold site) : 가장 저렴한 구성, 재해복구 성공에 확신이 어렵다.
  >
 • 다중센터
  - 여러 운영 센터로 처리를 나누어 운영
 • 서비스업체
  - DRP에 대한 외주
  - 대규모 재해시에 자원에 대한 경합 (SLA를 통해서 어느정도 해소 가능..)
 • 기타 백업 대안
  - 이중정보처리시설
  - 모바일사이트 : Sun(블랙박스) <- i="">, IBM(PMDC)

   > 컨테이너 안에 시스템 모든 것들이 설비 되어 있음 - 이라크 전에서 생김

 • 트랜잭션 중복 구현
  - 전자볼팅(Electronic Vaulting) <- p="">   : 대체 사이트로 트랜잭션을 덤프하는 배치 프로세스
   : 원격저널링(Remote Journaling) <- i="">
    . 로그정보를 원격에 저장하는 것
    . 백업된 로그정보는 장애시 트랜잭션 복구에 이용된다.
 - 데이터베이스 쉐도우잉(Database Shadowing) <- i="">
   : 다중 DB서버 운영으로 완전 이중화

 재해복구 계획의 유지 보수
 • 최신의 버전이 유지되도록 업데이트를 수행해야 한다.
 • 컴퓨팅 환경의 변화등이 원인 (이외에도…)
 재해 복구 계획은 조직의 실재적인 복구 능력이므로 주기적으로 테스트되어야 한다.

 -- 재해 복구 계획 테스트

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

 복구 테스트 유형
 • 체크리스트(Checklist)
  - 계획이 조직의 모든 영역에 해당되는지 확인및 검토하는것
 • 구조적 점검(Structured walk-through)
  - 사업 단위 관리자들이 계획이 복구능력을 제공하는지 검토하고 확인하는것

 > walk-through : 연기자들이 대본 연습 하는 것으로 IT 쪽에서는 연관된 사람들 끼리 대면하여 어떤 계획으로 어떻게 처리를 할지 서로 상황에 맞추어 보는 것을 말함 => 가장 비용 대비 효과적임

 • 시뮬레이션(Simulation) <- i="">
  - 재해에 대한 직원의 능력을 테스트
  - 실재 복구 프로세스나 대체 응용을 기동하지는 않는다.
 • 병렬 테스트(Parallel)
  - 가장 많이 수행되는 재해 복구 테스트
  - 핵심적인 기능이 대체 복구 사이트에서 수행되는지 확인
  - 트랜잭션 결과를 비교함으로써 정확성과 안정성을 확인
 • 전체 시스템 중단 테스트(Full-interruption)
  - 극히 드물지만 절대적으로 최선의 테스트
  - 실제 재해 상황처럼 조직의 기능을 중단시키고 복구 계획을 실행

 -- 재해 복구 프로시저

 재해복구 프로시저의 요소
 • 복구팀
 • 구조팀
 • 정상 운영 재개
 • 기타 복구 이슈
 복구팀(Recovery Team)
 • 백업 사이트에서 핵심적인 기능의 운영을 담당
 구조팀(Salvage Team)
 • 재해를 입은 주사이트의 원래 기능을 복원하기 위한 팀
 • 재해 사이트의 장비 및 시설에 대한 관리와 확인을 담당
 • 정상운영 복귀를 결정하는 권한을 갖는다.
 정상운영 재개
 • 회복팀에 의해서 구현
 • 복구단계와는 달리 가장 덜 민감하고 덜 중요한 기능부터 주사이트로 이전한다.
 • 재해상황의 종료는 모든 기능이 원래 사이트로 환원되고 데이터가 정확하다고 증명된 이후 공식적으로 종료된다.
  - 원래 사이트로 돌아가는 프로시저에는 매우 다양하고 심각한 취약성들이 존재한다.

 기타 복구 이슈
 • 외부 그룹과 인터페이스
  - 관공서와의 물리적 논리적 거리 (경찰서, 소방서, 시청…)
  - 보도 기관, 주주, 고객과의 의사 소통
 • 직원
  - 조직은 직원의 안전에 고유의 책임을 진다. (신체상, 경제적 ..)
 • 사기와 범죄행위
  - DRP는 재해시 계획적 또는 우발적으로 발생하는 약탈, 도난 등의 대해서 고려해야 한다.
 • 재정적 부담
  - DRP 운영의 제정적인 문제
  - 사고 처리 도중 발생된 제정적인 부담은 예상이나 이를 집행하는 비상관리자의 권한을 초과할 가능성에 대해서 언급되어야 한다.
 • 보도 기관과의 관계
 • 대변인 같은 공식적인 대외 채널이 필요
  - 심각한 상황에서 미리 준비된 성명서 같은 대처가 필요

 사고의 원인에 대해서 추측하지 않는다.
 책임을 추측하지 않는다.
 시스템이나 프로세스를 비난하지 않는다.
 조사가 시작되고 결과가 발표될 것임을 포함한다.
 조직내 누구도 성명을 발표해서는 않된다