BCP와 DRP

인프라 7기/정보보안거버넌스

BCP와 DRP

킹버거 2023. 4. 26. 09:26

BCP(Business Continuty Planning)

- 규모가 큰 기업 전체의 재해와 관련된 여러가지 계획

* 업무 영향 평가 (Business Impact Assessment: BIA)

업무가 미치는 영향과 업무가 중지됐을 때 조직에 어떤 피해를 줄 수 있는지 분석

업무 분석이 선행되어야 함

업무 분석이 되어 있지 않은 기업을 가면 어떻게 해야 할까?

> Baseline 기법을 쓴다.

* Baseline: '보안 통제'를 할 수준이 되지 않는 기업이 최소한으로 행해야 하는 지침

* 우리 나라에 1990년대에 도입

DRP(Disaster Recovery Planning)

- 부서별 운영

- IS와 관련된 DRP

- 재해 복구 계획 프로세스

: 재해 복구를 어떻게 할 것인지에 대한 다양한 업무 프로세스가 포함

- 재해 복구 계획 테스트

일정 수준 이상의 고객 정보를 가지고 있는 기업은 DRP 감사함.

예전에는 인증서 다운로드

재해: 정보 자원의 사용 불능으로 발생하는 업무(Business) 중단 사태

ex) 자연재해(BCP,DRP의 중요성이 높아지는 가장 큰 원인), 테러, 바이러스 등으로 인한 재해,

통신,전기,가스 등의 기반 서비스 중단, 실수

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

BCP(사업 연속성 계획)과 DCP(재해 복구 계획)은 BIA(업무 영향 평가)의 내용을 근거로 상세하게 세워져야 한다.

* 계획의 요소

1. 재해 이전 준비

2. 대피 절차

* 대피 절차가 재해 선언보다 선행되는 이유: 사람 구하는 게 가장 중요하기 때문이다.

* 인사 피해가 정량적으로 따졌을 때 큰 손실이다.

* 사람 목숨 값은 법률에 의해 결정된다.

* 문제점) 대피 명령을 믿지 않고 통제를 따르지 않음.

3. 재해 선언 절차

4. 재해 선언 상황 판단 기준

5. 책임 및 책임자

6. 명확한 계약 정보

7. 복구 대안의 단계별 설명

8. 복구 및 지속 운영에 필요한 자원 식별

BCP의 목적

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

발생 가능한 여러 종류의 위험

고객 서비스 중단
이미지 및 브랜드 손실
지적, 인적 자산 보호 실패
비즈니스 통제 상실
법률적 요구 사항 위반

BCP의 책임

1 고위 경영진 :회사의 생존과 자산보호의 책임을 위임 받음

2 소유자(주주)

중점 고려 사항

조직의 생존에 가장 필요한 핵심 사업 영역
핵심 사업 영역을 지원하는 물적, 인적 자원 (* IT 포함)

BCP는 위험분석을 기반으로 수행하며 이를 위해서 자산을 고려한 위협 식별작업이 필요하다.

BCP의 네가지 구성 요소

• 범위와 계획의 초기화

*역할과 책임을 식별

*최고 경영진 – 프로젝트의 개시, 최종승인, 지속적인 지원 책임
*BCP위원회 – 계획 구현, 테스트를 지휘

*단위 사업 관리자 - 핵심 프로세스(구체적인 실제 업무)의 정의와 우선순위 부여

모든 인사 권한을 가지고 있음. (**외국인 경우** 우리나라는 아님**)

*기능 사업부서 – 구현과 테스트에 참여

• 사업 영향 평가 (Business Impact Assessment : BIA)

* 세가지 주요 요소.
1. 핵심 우선 순위 결정
• 모든 핵심적인 단위 프로세스를 식별하고 파괴적 사건에 대한 영향을 평가해야 한다.
2. 중단시간 산정
• 핵심 프로세스가 중단된 채로 조직이 회생불능에 빠지기 까지 견딜 수 있는 시간을 산정
• MTD : Maximum Tolerable Downtime

> 어떻게 측정할까? 그냥 관련된 사람들 인터뷰 모아서 평균냄.(황당)
• 일반적인 측정치는 기대치에 비해서 무척 짧다.

> 1년 버틸 수 있어도 6개월 밖에 못 간다고 답변하기 때문에.
3. 지원 요구사항
• 핵심 프로세스를 복구하는데 필요한 자원요구 사항

* BIA 수행하는 접근 방법
• 설문지
• 인터뷰 (설문지보다 인터뷰가 효과가 더 좋음.)
• 회의
• 시스템 관련 BIA에서는 과거의 트랜잭션량을 분석하고 결과는 인터뷰단계에서 실증해야 한다.

* 취약성 평가
• 위험 평가 방법
- 정량적 : 경제적 측면

- 정성적 평가 x
• 정량적 손실 기준
- 매출 손실 및 추가 부채에 대한 비용
- 사건 복구 비용
- 법적인 비용 (계약의 위반, 법률 위반 ..)

- 시장 점유율 감소
- 신뢰나 공신력 감소

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

인력이 가장 핵심 ** (자본 제외)

• 사업 지속 개발 계획

• 계획 승인과 구현

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

BCP 구성 문서 (보안 등급이 높은 문서)
• 사업 복구 계획
• 운영 계획 연속성
• IT 비상 계획 지원의 연속성
• 위급 상황 시 통신 계획
• 사고 대응 계획
• 재해 복구 계획
• 거주자 비상계획

* 자택 근무가 불가능한 이유: 자택에서는 물리 보안이 불가능하기 때문이다.

계획 사본 저장
• 핵심 의사 결정자의 사택 > 기업에서 안전하게 보관할 수 있는 수단을 제공해줘야 함. ex) 금고
• 복구 시설이나 저장 시설(오프 사이트) ex) 쿨사이트,웜사이트,핫사이트 같은 것

DRP의 구성과 목적
• 컴퓨터 및 네트워크 시스템 장애로 부터 조직을 보호 (IS와 관련)
• 업무 서비스 제공 지연으로 인한 위험의 최소화 (기업 전산실/정보시스템의 목적)
• 재해 중 직원들의 안전한 행동 요령과 의사결정의 최소화
• 테스트를 통한 대기 시스템의 안정성 보장

회사 내부에서 업무 관련 문제가 생기면 콜센터에 전화함. 그 콜센터는 외부 고객을 위한 콜센터가 아닌 내부 직원을 위한 콜센터. 엔지니어가 받는다.

* 보통 같은 장애가 반복적으로 발생

* HDD/SDD 같은 저장매체, 전원 기기, 비디오 카드 등으로 인한 장애 빈번하게 발생

MTBF(Mean Time Between Failure) : 장애 사이 기간(길수록 좋아)

MTTR(Mean Time TO Repair) : 장애 교정 기간(짧을수록 좋아)

복원이란? : 날아갈 데이터를 안전하게 저장하는 것도 복원

원래 형태로 되돌리는 것도 복원

여기서는 '업무 시스템'을 원하는 수준까지 되돌리는 것.

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

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

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

* RPO와 RTO는 짧을 수록 좋다.

* 비용(피해액수)이 용인할 수 없는 수준으로 증가하기 이전에 복구해야 한다.

RPO (Recovery Point Objective, 복구 목표 시점)
• 장애 발생시 복구 시점(현재로 부터 과거 시점, 짧을 수록 비용이 많이 든다.)
• RPO가 매우 짧다라는 건 손실 데이터의 양이 작다라는 걸 의미한다.
• 가장 이상적인 경우 : 재해시점 = RPO시점 : 데이터 손실이 없다.
• 미러링, 듀플렉싱 < 백업 < 릴 백업 (클수록 운영 비용이 적다)

날마다 백업을 받으면, 최악의 경우 하루 분량의 데이터가 날아갈 수 있다.

한 시간마다 백업을 받으면, 최악의 경우 한 시간 분량의 데이터가 날아갈 수 있다.

그러나 비용은 많이 들겠지.

아예 데이터가 날아가지 않게 하려면 다중화를 해야지. 하지만 비용은 정말 많이 들겠지

그래서 redo를 archiving(작업 내용을 저장)을 하는 경우가 많다.

RTO(복구 목표 시간)
• 복구 가능 최단 시간(허용 시간)
• 적을 수록 복구 비용이 많이 든다.

우선적으로 복원해야 하는 업무 : 민감한 업무

*** 민감한 업무 : 수작업이 안 되는 업무

수작업이 아예 안 되는 업무 - 수작업이 일시적으로 가능한 업무 - 수작업이 가능한 업무

production: 정보 처리 시설

데이터 처리 지속 계획
• 상호 지원 계약 (가장 현실성 없음, 다른 회사끼리는 production 공유하면 안 됨)
- 가장 적은 비용
- 호환성의 문제
- 동시 재해 시 복구 불능
- 복구에 다른 대안이 없는 경우에만 고려하는 것이 좋다.

*** 위의 조건이 가능하려면

1) 플랫폼 상 호환 가능

2) 직렬 상에 있는 상위 회사 A가 하청 업체 B 지원 가능 (단, B가 A와만 거래하는 경우)

3) 본래 기업에서 독립한 기업인 경우 (ex. 롯데와 롯데 계열사들)

• 가입 서비스

* 서버를 임대해주기는 함.

* 사막이 최적의 장소

* 사람이 식별하기 어렵게 만든다.

- 핫사이트(Hot site) : 고가, 동일한 보안 이슈, 자원 집약적, 최신의 데이터나 응용을 유지

> PC방이라고 보면 됨. But, 서버는 들고 가야 됨.
- 웜사이트(Warm site) : 경제적, 위치 선정이 유연, 관리자원 낭비가 적다

> 네트워크 설비 완, 컴퓨터&서버만 들고 가면 됨
- 쿨사이트(Cold site) : 가장 저렴한 구성, 재해복구 성공에 확신이 어렵다.

> 전기 콘센트, 책상, 의자, 에어컨, 수도 시설, 휴게실 밖에 없음.

* 결정 요인: RTO

복구하는데 시간이 쿨사이트 1달 , 웜사이트 15일, 핫사이트 7일 소요

우리 회사의 RTO가 16일이면 웜사이트로 결정함.

• 다중센터
- 여러 운영 센터로 처리를 나누어 운영

백업사이트: 주로 교통이 편리한 곳에 위치

* 서울 > 대전, 대구, 광주, 부산

서비스업체
- DRP에 대한 외주 (법원에서 당장 서류 가져오라 할 때 필요)
- 대규모 재해시에 자원에 대한 경합 (SLA를 통해서 어느정도 해소 가능..)

기타 백업 대안
- 이중정보처리시설
- 모바일사이트 : Sun(블랙박스), IBM(PMDC)

> 모바이 사이트는 급하게 정보 처리 시설을 옮겨야 할 때 사용한다.

IBM은 IT 회사가 아님. 특허 사용료로 돈 벌음. 전기 공급/설비에 대한 특허 다 있음.

외부 전기 중 어떤 전기를 꽂아도 사용할 수 있게 만들어줌. 현장에서 데이터 처리 가능.

근데 Sun사는 입찰에서 탈락함. 일본에서 Sun사 제품 사려고 함. 근데 Sun사 망함.

트랜잭션 중복 구현

> redo 정보를 중복해서 구현
- 전자볼팅(Electronic Vaulting) * 해당 용어 사용하지 않음. 요즘에는 로그 정보라고 함.
: 대체 사이트로 트랜잭션을 덤프하는 배치 프로세스
: 원격저널링(Remote Journaling)
. 로그정보를 원격에 저장하는 것
. 백업된 로그정보는 장애시 트랜잭션 복구에 이용된다.
- 데이터베이스 쉐도우잉(Database Shadowing)
: 다중 DB서버 운영으로 완전 이중화

* RECOVERY 안 되고 RESTORE만 되는 DB : mySQL, 마리아DB

RECOVERY : 데이터 손실 없이 망가진 거 완전 복구

RESTORE : 일부만 복구되는 거

로그 정보 만들 때 의외로 시스템 리소스를 많이 씀.

오버레인 네트워크를 만드세요ㅛ? 패킷이 서로 혼용되지 않도록.. 브롣캐스트 시그널 발생ㅎ마ㅕㄴ

스위치허브에서 전부 통과되죠 근데 얘네들이 서로 스위칭 허브를 토하더라도 서로 발생하ㅡㄴ

브로드캐스트 시그널 받지 않도록. 그럼 뭘 나눠야 해? 스이칭 허브에 ? 스위칠르 무러 나누면 브로드캐르트

시그널이 ㅇ통과되지 ㅏㅇㄶ지? vlan!

db는 wait라는 이벤트도 관리함.

네트워크도 관리함. 되는데 안 하는거임 근데. db 엔지니어 가르칠 때, 원인은 못 찾겠으면 (어디서 임계값이 넘어가는지 찾기 힘들면) 네트워크에 문제가 있는 것 같다고 말해. 그러고나서 진단을 함.

복구 테스트 유형
• 체크리스트(Checklist)

* 반드시 '루브릭(Rubric)'을 만듬. 평가자가 행함.

* 비용이 가장 적게 든다.
- 계획이 조직의 모든 영역에 해당되는지 확인및 검토하는것
• 구조적 점검(Structured walk-through)

* = 준거성 테스트

* 대본 리딩과 비슷함.

* 순서가 있는 프로세스: task

* 시간이 가장 많이 소요되는 경로 : critical path

* 가장 비용 효과적임.
- 사업 단위 관리자들이 계획이 복구능력을 제공하는지 검토하고 확인하는것
• 시뮬레이션(Simulation)
- 재해에 대한 직원의 능력을 테스트
- 실재 복구 프로세스나 대체 응용을 기동하지는 않는다.
• 병렬 테스트(Parallel)

* 병렬 테스트 이후 출력 통제가 중요하다. 테스트 결과물에 대한 통제가 중요하기 때문.
- 가장 많이 수행되는 재해 복구 테스트
- 핵심적인 기능이 대체 복구 사이트에서 수행되는지 확인
- 트랜잭션 결과를 비교함으로써 정확성과 안정성을 확인
• 전체 시스템 중단 테스트(Full-interruption)

* 한국에서 많이 함. (ex. 민방위 훈련)
- 극히 드물지만 절대적으로 최선의 테스트
- 실제 재해 상황처럼 조직의 기능을 중단시키고 복구 계획을 실행

네트워크팀(조직 간의 의사소통을 원활히 하기 위한 조치를 담당) vs 커뮤니케이션팀(네트워크를 복구하는 업무 담당)

* 이름과 업무가 서로 뒤바뀐 것 같지만 놀랍게도 이게 맞음.

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

복구팀(Recovery Team)
• 백업 사이트에서 핵심적인 기능의 운영을 담당

* 인원이 적어서 '직무 분리'에 문제가 생길 수 있음.

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

정상운영 재개

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

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

* 이런 과정을 거치지 않으면 나중에는 사람들이 진실을 믿지 않는 현상이 발생함.